From owner-freebsd-hackers Sun Mar 23 2:55:23 2003 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 B59F537B401; Sun, 23 Mar 2003 02:55:21 -0800 (PST) Received: from resnet.uoregon.edu (resnet.uoregon.edu [128.223.122.47]) by mx1.FreeBSD.org (Postfix) with ESMTP id A52FF43F3F; Sun, 23 Mar 2003 02:55:20 -0800 (PST) (envelope-from gurney_j@resnet.uoregon.edu) Received: by resnet.uoregon.edu (Postfix, from userid 1001) id 0D0EB1930E; Sun, 23 Mar 2003 02:55:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by resnet.uoregon.edu (Postfix) with ESMTP id DF6A41D112; Sun, 23 Mar 2003 17:55:07 +0700 (ICT) Date: Sun, 23 Mar 2003 17:55:07 +0700 (ICT) From: John-Mark Gurney To: "Matthew N. Dodd" Cc: dfr@FreeBSD.ORG, Subject: Re: bug in subr_bus.c? In-Reply-To: <20030321094447.E8716@sasami.jurai.net> Message-ID: <20030323174445.K36261-100000@resnet.uoregon.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, 21 Mar 2003, Matthew N. Dodd wrote: > On Fri, 21 Mar 2003, John-Mark Gurney wrote: > > So, the driver can: > > a) delete it's own children, but if it gets removed via > > device_delete_child, this work is already down for you. > > If you create children then you're going to be involved in removing them. > > There are helper routines that simplify some operations but I don't > believe any changes to subr_bus.c are needed. I finally got it working.. I'm not sure exactly what I did, but I can load/unload the driver w/o crashing the machine... The bus code could use some locking in it... like you can't delete_child from child_detache... and/or better docs on how to handle children... I'm not even sure how I was doing things wrong, but I think it might of been problems with my code not calling bus_generic_detach before calling device_child_delete... Hmmm.. I'm still not sure exactly why things started behaving properly... I know a few times I was trying to delete a device that was in the process of being detached (which of course would try to detach it again)... Quite confusing.. :( Thanks for your help though. later. John-Mark To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Mar 23 3: 6:42 2003 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 AD62937B404 for ; Sun, 23 Mar 2003 03:06:24 -0800 (PST) Received: from smtp.inode.at (smtp-01.inode.at [62.99.194.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2C30143FD7 for ; Sun, 23 Mar 2003 03:06:22 -0800 (PST) (envelope-from mranner@dwarf.jawa.at) Received: from line-h-153.adsl-dynamic.inode.at ([81.223.1.153]:1194 helo=dwarf.jawa.at) by smtp.inode.at with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.10) id 18x3Iv-0001WG-00; Sun, 23 Mar 2003 12:06:18 +0100 Received: from dwarf.jawa.at (localhost.jawa.at [127.0.0.1]) by dwarf.jawa.at (8.12.6/8.12.6) with ESMTP id h2NB67mC001761; Sun, 23 Mar 2003 12:06:07 +0100 (CET) (envelope-from mranner@dwarf.jawa.at) Received: by dwarf.jawa.at (8.12.6/8.12.6/Submit) id h2NB66jm001760; Sun, 23 Mar 2003 12:06:06 +0100 (CET) From: Michael Ranner To: freebsd-hackers@freebsd.org Subject: Re: generalized mergemaster(8) Date: Sun, 23 Mar 2003 12:06:06 +0100 User-Agent: KMail/1.5 References: <20030321041548.GY25577@geekpunk.net> <3E7B56B9.6050005@acm.org> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Cc: Garance A Drosihn Content-Type: Multipart/Mixed; boundary="Boundary-00=_eUZf+bj/Sm49djI" Message-Id: <200303231206.06445.mranner@inode.at> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --Boundary-00=_eUZf+bj/Sm49djI Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Content-Disposition: inline Am Freitag, 21. März 2003 20:27 schrieb Garance A Drosihn: > > > > /var/tmp/temproot/etc/rc.d/ and /etc/rc.d/ have 17 differing files. > > (I)nstall, (D)elete, or (R)ecursively examine? [R] > > > >Then I could hit 'I' and update all of /etc/rc.d at once. > > At times I've asked Doug about some kind of pattern-support in > ~/.mergemasterrc, where the user could specify filename-patterns > of files where they want the default action to be "install" > instead of "leave for later". There are pros and cons with that > idea, but that's what I was thinking of for the directories you > describe. > > Doug has suggested that people could maybe do things with the > MM_PRE_COMPARE_SCRIPT, for special processing like this. I have a small patch for pattern-support in ~/.mergemasterrc and already sent my ideas to Doug, but he said "It could/should be done with MM_PRE_COMPARE_SCRIPT" to me. Regards -- /\/\ichael Ranner mranner@jawa.at - mranner@bitonline.cc - webmaster@mariazell.at ---------------------------------------------------------------------- JAWA Management Software GmbH - http://www.jawa.at/ Liebenauer Hauptstrasse 2oo - A-8041 Graz Tel +43 316 403274 21 - Fax +43 316 403274 10 ---------------------------------------------------------------------- Mariazell Online - http://www.mariazell.at/ ---------------------------------------------------------------------- -----BEGIN GEEK CODE BLOCK----- GIT/CS/AT dx(-) s+:(++:) a- C++ UBLVS++++$ P++>+++$ L-(+)$ E--- W+++$ N+(++) o-- K- w--()$ O-(--) M@ V-(--) PS+>++ PE(-) Y+ PGP(-) t+ 5+ X+++(++++) R* tv++ b+(++) DI++ D-(--) G- e h--(*) r++ y? ------END GEEK CODE BLOCK------ --Boundary-00=_eUZf+bj/Sm49djI Content-Type: text/x-diff; charset="iso-8859-1"; name="mergemaster.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="mergemaster.patch" *** mergemaster.orig Wed Mar 5 16:35:54 2003 --- mergemaster Thu Mar 6 15:47:38 2003 *************** *** 106,115 **** diff_loop () { HANDLE_COMPFILE=v while [ "${HANDLE_COMPFILE}" = "v" -o "${HANDLE_COMPFILE}" = "V" -o \ "${HANDLE_COMPFILE}" = "NOT V" ]; do ! if [ -f "${DESTDIR}${COMPFILE#.}" -a -f "${COMPFILE}" ]; then if [ "${HANDLE_COMPFILE}" = "v" -o "${HANDLE_COMPFILE}" = "V" ]; then echo '' echo ' ====================================================================== ' --- 106,133 ---- diff_loop () { HANDLE_COMPFILE=v + AUTO_INSTALL_FILE=n + + case "${AUTO_INSTALL}" in + [Yy][Ee][Ss]) + set -f + for each in $AUTO_INSTALL_FILES + do + if expr "$COMPFILE" : ".$each\$" >/dev/null; then + AUTO_INSTALL_FILE=y + break + fi + done + set +f + ;; + *) + ;; + esac while [ "${HANDLE_COMPFILE}" = "v" -o "${HANDLE_COMPFILE}" = "V" -o \ "${HANDLE_COMPFILE}" = "NOT V" ]; do ! if [ -f "${DESTDIR}${COMPFILE#.}" -a -f "${COMPFILE}" -a \ ! "$AUTO_INSTALL_FILE" = "n" ]; then if [ "${HANDLE_COMPFILE}" = "v" -o "${HANDLE_COMPFILE}" = "V" ]; then echo '' echo ' ====================================================================== ' *************** *** 124,130 **** fi else echo '' ! echo " *** There is no installed version of ${COMPFILE}" echo '' case "${AUTO_INSTALL}" in [Yy][Ee][Ss]) --- 142,152 ---- fi else echo '' ! if [ "$AUTO_INSTALL_FILE" = "y" ]; then ! echo " *** Automatic installation of ${COMPFILE}" ! else ! echo " *** There is no installed version of ${COMPFILE}" ! fi echo '' case "${AUTO_INSTALL}" in [Yy][Ee][Ss]) --Boundary-00=_eUZf+bj/Sm49djI Content-Type: text/plain; charset="iso-8859-1"; name="mergemaster.rc" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="mergemaster.rc" AUTO_INSTALL_FILES="/etc/periodic/.*" --Boundary-00=_eUZf+bj/Sm49djI-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Mar 23 5: 2: 4 2003 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 D69ED37B405; Sun, 23 Mar 2003 05:01:55 -0800 (PST) Received: from hotmail.com (bay2-dav20.bay2.hotmail.com [65.54.246.124]) by mx1.FreeBSD.org (Postfix) with ESMTP id D2E4143FAF; Sun, 23 Mar 2003 05:01:52 -0800 (PST) (envelope-from sukhbinders@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 23 Mar 2003 05:01:52 -0800 Received: from 202.188.200.130 by bay2-dav20.bay2.hotmail.com with DAV; Sun, 23 Mar 2003 13:01:52 +0000 X-Originating-IP: [202.188.200.130] X-Originating-Email: [sukhbinders@hotmail.com] From: "Sukhbinder Singh" To: "taxman" , Cc: References: <200303222210.03869.taxman@acd.net> Subject: Re: FreeBSD Installation Problems Date: Sun, 23 Mar 2003 21:00:41 +0800 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.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Message-ID: X-OriginalArrivalTime: 23 Mar 2003 13:01:52.0808 (UTC) FILETIME=[5FD76A80:01C2F13C] Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Now I am using a new mailer not the one from hotmail, because i am not able to edit the settings in the hotmail mailer to not sent html mail. i think hotmail mailer is made to mail html mails. if anyone have an idea of how to not mail html mails from hotmail, i mean if anyone knows of how to stop or configure hotmail not to mail html mails please let me know of how to do this. anyway i hope this mailer do not mail html mails. if it is does please let me know. however now getting back to the free bsd problem can anyone give a little help in troubleshooting this problem. now when i try to setup freebsd using floopy disk method it is giving an error message like " No floppy device found consult the hardware in doc". The FTP now seems to work but however this gives a message like " Could not open FTP connection to ftp.freebsd.org: undefined error: 0" how can these 2 error message be solved. Any help will help. thanks ----- Original Message ----- From: taxman To: Sukhbinder Singh Sent: Sunday, March 23, 2003 11:10 AM Subject: Re: FreeBSD Installation Problems > > really, why do you persist in sending html mail to this list? It is nearly > unreadable on most peoples mail readers. So you will mostly get ignored. > > To answer this question we need to know more details about what you've tried > and what exact step in the process it fails at. Please send that in text > only. Modify your hotmail preferences to do that. Thank you > > Tim > > > On Saturday 22 March 2003 08:48 am, Sukhbinder Singh wrote: > >
Dear Sir,
> >
 
> >
   I am trying to install FreeBSD into my personal computer. > > I am using the FTP installation method using the standard installation. > > When I try to start the FTP installation I get message such as :- Warning: > > no /dev/tun0 device. PPP will not work !. Unable to start PPP. This > > installation cannot be used.
 
> >
Can you please help me to resolve this problem.
> >
 
> >
Thanks,
> >
 
> >
 

MSN 8 with > href="http://g.msn.com/8HMRENUS/2740">e-mail virus protection service: > > 2 months FREE* > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-questions" in the body of the message > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Mar 23 5:54:25 2003 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 3F4CC37B404 for ; Sun, 23 Mar 2003 05:54:24 -0800 (PST) Received: from rly-ip03.mx.aol.com (rly-ip03.mx.aol.com [64.12.138.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4603A43F85 for ; Sun, 23 Mar 2003 05:54:23 -0800 (PST) (envelope-from richard@voicewebsolutions.biz) Received: from logs-ntc-tj.proxy.aol.com (logs-ntc-tj.proxy.aol.com [198.81.20.131]) by rly-ip03.mx.aol.com (v89.10) with ESMTP id RELAYIN5-0323085300; Sun, 23 Mar 2003 08:53:00 -0500 Received: from 169.254.101.152 (ACACB2E6.ipt.aol.com [172.172.178.230]) by logs-ntc-tj.proxy.aol.com (8.12.8/8.12.8) with SMTP id h2NDq4xK025335 for ; Sun, 23 Mar 2003 08:52:08 -0500 Message-Id: <200303231352.h2NDq4xK025335@logs-ntc-tj.proxy.aol.com> From: "Richard Norris" To: hackers@FreeBSD.org Subject: Accessibility software Date: Sat, 22 Mar 2003 10:07:00 -0800 MIME-Version: 1.0 X-GCMulti: 1 X-Apparently-From: BiSeattle21m@aol.com Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi, My name is Richard. I saw your interest in Section 508 and Accessiblity and I just wanted to let you know that there is a new product for webmasters that uses speech recognition to make the Web sites more accessible. The Voice Web Studio software enables you to add speech as another mode of interaction with any web page using Macromedia Dreamweaver MX. You can access these speech-enabled pages from your computer or handheld wireless device with just a microphone. This new web authoring tool is available now as a free download. If you are interested, I can e-mail you a brief brochure that will show you the easiest way to start using the software. I am looking forward to hearing from you soon. Best Regards, Richard Norris Business Development Voice Web Solutions Phone: (206) 338-6632 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Mar 23 7:59: 7 2003 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 329FC37B401 for ; Sun, 23 Mar 2003 07:59:06 -0800 (PST) Received: from arpa.com (arpa.com [199.245.173.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1FD5443F85 for ; Sun, 23 Mar 2003 07:59:05 -0800 (PST) (envelope-from wd@arpa.com) Received: from localhost (localhost [127.0.0.1]) by arpa.com (Postfix) with ESMTP id 795AE20146 for ; Sun, 23 Mar 2003 09:59:04 -0600 (CST) Received: from gondolin (d14-69-64-77.nap.wideopenwest.com [69.14.77.64]) by arpa.com (Postfix) with ESMTP id C299120143 for ; Sun, 23 Mar 2003 09:59:03 -0600 (CST) From: Chip Norkus Organization: Telekinetic Industries To: hackers@freebsd.org Subject: KVM mice issues Date: Sun, 23 Mar 2003 09:57:36 -0600 User-Agent: KMail/1.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200303230957.36433.wd@arpa.com> X-Virus-Scanned: by AMaViS snapshot-20020531 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Greetings hackers, I have a KVM switch and a fairly new (Logitech MouseMan+ cordless) mouse, and I've found that while FreeBSD properly detects the mouse and all its functionality (buttons, scrollwheel, etc) upon boot if I switch to another port on the KVM and then switch back my mouse "loses" its functionality. After spending a while trying to figure out this problem (and reading PRs on the issue (esp. i386/25463)) I found that a solution was not immediately available, but might be somewhat easy to achieve. In particular, for my mouse, the mouse driver can and does detect invalid packets, and invalid packets are always received after a return to my FreeBSD system via the KVM. I found that doing a reinitialization of the device would fix the mouse, but that doing it from the interrupt handler (in sys/isa/psm.c around line 2170) caused some intermediate problems. Normally the mouse would just bounce around and generate click events for a while and then settle down, but occasionally the driver (or maybe mouse?) would lock solid and I'd have to reboot the system. Anyways, I'd like to work further on this problem and hopefully find a solution, but I'm having some trouble understanding where and what I should do. I'm not a novice C hacker, but I *am* a very novice kernel hacker and would appreciate help from anyone with knowledge of the psm (and atkbdc) code. I've considered maybe adding an ioctl to reset the mouse and adding a signal handler to moused to force a reset, but that seems kind of silly when the kernel driver can detect the problem itself and resolve it. On the other hand, maybe that's the right way to go? Advice would be greatly appreciated. -chip -- chip norkus; renaissance hacker; wd@arpa.com "question = (to) ? be : !be;" --Shakespeare http://telekinesis.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Mar 23 8:23:39 2003 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 9B86137B401; Sun, 23 Mar 2003 08:23:38 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2D20743F75; Sun, 23 Mar 2003 08:23:37 -0800 (PST) (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 h2NGNZA7064254; Sun, 23 Mar 2003 09:23:36 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Sun, 23 Mar 2003 09:23:05 -0700 (MST) Message-Id: <20030323.092305.83978540.imp@bsdimp.com> To: gurney_j@resnet.uoregon.edu Cc: mdodd@FreeBSD.ORG, dfr@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: bug in subr_bus.c? From: "M. Warner Losh" In-Reply-To: <20030323174445.K36261-100000@resnet.uoregon.edu> References: <20030321094447.E8716@sasami.jurai.net> <20030323174445.K36261-100000@resnet.uoregon.edu> X-Mailer: Mew version 2.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message: <20030323174445.K36261-100000@resnet.uoregon.edu> John-Mark Gurney writes: : The bus code could use some locking in it... like you can't delete_child : from child_detache... and/or better docs on how to handle children... I'm : not even sure how I was doing things wrong, but I think it might of been : problems with my code not calling bus_generic_detach before calling : device_child_delete... I'm doing the locking, but you can do a bus_delete_child in a child's detach routine. Cardbus does this right now and it works when you unload the cardbus bridge... Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Mar 23 8:56: 6 2003 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 5FDB437B401; Sun, 23 Mar 2003 08:56:03 -0800 (PST) Received: from paubrasil.serg.inf.puc-rio.br (paubrasil.serg.inf.puc-rio.br [139.82.16.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id 08E3743F93; Sun, 23 Mar 2003 08:55:59 -0800 (PST) (envelope-from 4200tttttfhfhghghkjktyr@ms67.hinet.net) Received: from Spooler by paubrasil.serg.inf.puc-rio.br (Mercury/32 v3.32) ID MO0049AE; 23 Mar 03 13:57:17 -0300 Received: from spooler by paubrasil.serg.inf.puc-rio.br (Mercury/32 v3.32); 23 Mar 03 13:35:55 -0300 Received: from 1-pajpti4vs84aw (218.187.109.187) by smtp.serg.inf.puc-rio.br (Mercury/32 v3.32) ID MG0049A0; 23 Mar 03 13:35:45 -0300 To: 4200tttttfhfhghghkjktyr@ms67.hinet.net From: 4200tttttfhfhghghkjktyr@ms67.hinet.net Subject: ¶W­È¦n§¥ô±z¬D¿ï!!Åwªï¨Ó¹q¬Ý³f²{³õ¬Ý³f¤ñ¸û¿ïÁÊ Date: Mon, 24 Mar 2003 00:44:51 +0800 Message-Id: <37704.031149074071400.27177@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=big5 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG ¶W­È¦n§¥ô±z¬D¿ï!!Åwªï¨Ó¹q¬Ý³f²{³õ¬Ý³f¤ñ¸û¿ïÁÊ http://www.vovo2.com/~nono/new_page_tt.htm ·s³f¤w¤W¬[¡A»°§Ö¶i¥h¬D¿ï¡I¡I¡I¡I http://vivi.liful.com/ ¤â¾÷¨C¤ÀÄÁ¶O²v3.5¤¸ ¥«­±¤W°ß¤@¥Î¤â¾÷¤Î¥«¸Ü¡A¥´°ê¤º©M°ê»Ú¹q¸Ü³£¯à¸`¶Oªº¨t²Î http://203.70.228.20/tel/index.asp 19·³¯à¤ë¤J¤Q¸U...­ì¨Ó¥L¬O°µ³o£« http://www.mymorningmusume.com/hope/new.htm ======================================================= SUPER e-Mail±M·~¹q¤l¶l¥ó¦æ¾P~¶l¥ó¥N«È¸sµo / ÁʶR¦W³æ / ======================================================= http://210.62.128.25/~cai/good/fate/index.htm ******************************************************* ******************************************************* To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Mar 23 11:20:21 2003 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 5726B37B404 for ; Sun, 23 Mar 2003 11:20:18 -0800 (PST) Received: from smtp-relay.omnis.com (smtp-relay.omnis.com [216.239.128.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id C4A7743F3F for ; Sun, 23 Mar 2003 11:20:17 -0800 (PST) (envelope-from wes@softweyr.com) Received: from softweyr.homeunix.net (66-91-236-204.san.rr.com [66.91.236.204]) by smtp-relay.omnis.com (Postfix) with ESMTP id 0DFA9445BB; Sun, 23 Mar 2003 11:20:17 -0800 (PST) From: Wes Peters Organization: Softweyr To: Daniela , Kris Kennaway Subject: Re: Lots of kernel core dumps Date: Sun, 23 Mar 2003 11:20:15 -0800 User-Agent: KMail/1.5 Cc: hackers@FreeBSD.ORG References: <200303212037.46322.dgw@liwest.at> <20030321221514.GA24787@rot13.obsecurity.org> <200303230010.38736.dgw@liwest.at> In-Reply-To: <200303230010.38736.dgw@liwest.at> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200303231120.15652.wes@softweyr.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Saturday 22 March 2003 15:10, Daniela wrote: > > I know, but 5.0-RELEASE was > > > > a) A work-in-progress, not a perfect, bug-free release > > > > b) A snapshot of 5.0-CURRENT > > > > You read the 5.0 Early Adopter's Guide, right? Bugs like this are > > expected at this stage in the development process, and if you > > encounter them then you need to either give up on 5.x and go back to > > 4.x-STABLE, or upgrade to 5.0-CURRENT if they are already fixed > > there. > > > > Kris > > Yes, I read the Early Adopter's Guide. > Is there any way to solve this without upgrading to -current? > I want a stable server, of course, but I still want to help the FreeBSD > folks to make 5.0 the best release ever. This requires testing to be > done. Yes it does, but not on a "production" machine. We admire your courage and willingness to help, but it's not helping as much as you think. ;^) The reason for creating the 5.0 release is to make it easy for more developers and testers to jump onto the 5.x bandwagon by giving them a known (relatively) good starting point. Quite a number of problems have been fixed since 5.0-RELEASE; CURRENT is now generally much more stable, and nobody is going to spend time updating 5.0 which is essentially an "early access" release. You have to decide for yourself if this machine is too critical to run CURRENT, in which case it's probably best off running STABLE or the latest 4.x release branch, or if you want to update it to CURRENT, follow the CURRENT mailing list, and update again at known stable development points. It looks like right now is pretty good if you want to jump. At any rate, thanks for your tenacity. We really do appreciate the contributions of everyone. -- Where am I, and what am I doing in this handbasket? Wes Peters wes@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Mar 24 1:57:16 2003 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 5D9CF37B401 for ; Mon, 24 Mar 2003 01:57:12 -0800 (PST) Received: from office.advantagecom.net (office.advantagecom.net [207.109.186.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 93E8043FAF for ; Mon, 24 Mar 2003 01:57:11 -0800 (PST) (envelope-from andykinney@advantagecom.net) Received: from SCSI-MONSTER (andy.advantagecom.net [207.109.186.200] (may be forged)) by office.advantagecom.net (8.9.3/8.9.3) with ESMTP id BAA15532 for ; Mon, 24 Mar 2003 01:57:10 -0800 From: "Andrew Kinney" Organization: Advantagecom Networks, Inc. To: freebsd-hackers@freebsd.org Date: Mon, 24 Mar 2003 01:57:32 -0800 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: shared mem and panics when out of PV Entries Reply-To: andykinney@advantagecom.net Message-ID: <3E7E660C.10419.ECBF5C7@localhost> X-mailer: Pegasus Mail for Win32 (v3.12c) X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hello, (very long message with background information on the issue follows) The machine discussed in this email is tracking RELENG_4_7. The machine is a well loaded web/mail/ftp server with dual Athlon MP 2000+ CPUs, 4GB of RAM, and 8GB of available swap space. The most it has ever swapped was 292KB (yes, KB not MB) and the CPUs are about 60% idle most of the time. I don't believe we're pushing the hardware all that hard given the specifications of the system. We're getting panics ("page fault" panic traced back to pmap_insert_entry) because we're running out of PV Entries. I've bumped up PMAP_SHPGPERPROC to 400, then 800, and then 1500 over the last several months in an attempt to solve this problem by increasing the PV Entries limit (per the warning in pmap_collect). Each time, we still bumped the limit and got panics due to running out of PV Entries. I've verified that maxed PV Entries are indeed the cause of the panics by logging sysctl vm.zone. Our PV Entry limit is now 11113502 (from sysctl vm.zone) and we're still running into this limit. With 1GB KVA space, I really shouldn't take PMAP_SHPGPERPROC much higher since each PV Entry takes 28 bytes of KVA space and with 11113502 PV Entries, that is nearly 300MB of KVA space used just for PV Entries. Also, from past experience, if you set PMAP_SHPGPERPROC too high, the system will not boot. I'm not 100% sure, but I believe that would happen right around PMAP_SHPGPERPROC=1600 from my calculations. Now, I could increase KVA space by way of increasing KVA_PAGES and presumably continue increasing PMAP_SHPGPERPROC until the problem goes away, but per a previous discussion, there are problems (related to pthreads) with increasing KVA_PAGES in FreeBSD 4.7. This has apparently been fixed in FreeBSD 4.8. Since moving to FreeBSD 4.8 isn't an option I can exercise in the near term, I'd like to approach this problem from a different angle and possibly solve it without needing to increase KVA_PAGES. In my opinion, increasing KVA_PAGES would only be a short term bandaid for the PV Entries issue. I'll eventually need to increase KVA_PAGES for a different reason, though, because sysctl vm.kvm_free does hit "0" sometimes after the system has been running for awhile, but I'll tackle that issue if/when it becomes a stability issue. The source of the PV Entry usage is shared memory in Apache (PHP and/or mod_perl). We know it's Apache memory sharing that causes the problem because nearly all PV Entries are freed when Apache is stopped and the problem is worst right after Apache starts when you have a lot of "clean" memory segments getting shared (10 to 11 million PV Entries used). After Apache has run for awhile and the shared memory segments become unshared due to them being "dirtied", the number of PV Entries used declines and settles in at a much lower number (3 to 5 million PV Entries used most days). Apache on this machine likes to hover right around 256 children processes, so you could see how requiring duplicate PV Entries per shared memory segment per Apache process could add up quite quickly. Under ideal circumstances, we'd correct our PHP/PERL code to avoid running into the issue at all, but this is customer code that we don't have much control over since we allow users to select and run their own CGI scripts without our intervention. So, for this instance, we have to solve it at the system level by bullet-proofing our system as much as possible. I've read that setting sysctl kern.ipc.shm_use_phys to "1" will cause shared memory segments not to use PV Entries at all. (See http://www.geocrawler.com/archives/3/159/2002/6/50/9031353/ ) However, in the real world with FreeBSD 4.7, setting kern.ipc.shm_use_phys to "1" seems to have no visible effect on the number of PV Entries consumed by Apache memory sharing. We're currently running sysctl kern.ipc.shm_use_phys=1 and are still seeing the heavy PV Entry usage after rebooting (sysctl set on boot) with no apparent difference in usage. My thoughts at this point are leaning towards setting some limits on shared memory (kern.ipc.shmmax, kern.ipc.shmseg, kern.ipc.shmall, and kern.ipc.shmmax sysctl's) to limit the number of PV Entries that Apache can consume by way of shared memory. Is that a viable approach to this problem? What kind of gotchas and caveats should I watch out for in taking this approach? Any recommendations on which one to tweak first? If I'm headed in completely the wrong direction to solve this PV Entries limit issue, I'd appreciate any alternative approaches to solving the problem that anyone is willing to offer. If you need any further information about our settings or usage, please let me know. I've been as thorough as possible in this email without getting overly verbose, but in complex issues like this I recognize that I may not have included all the information needed for the experts to make a fair assessment of the issue and suggest work arounds. Also, though I believe that the highly technical nature of this message made it suitable for posting to freebsd- hackers, if it would be better suited to a different list, please point me in the right direction. Thanks in advance for any advice or assistance you can offer. Sincerely, Andrew Kinney President and Chief Technology Officer Advantagecom Networks, Inc. http://www.advantagecom.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Mar 24 2:51:40 2003 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 26D5C37B401; Mon, 24 Mar 2003 02:51:37 -0800 (PST) Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9632243FA3; Mon, 24 Mar 2003 02:51:27 -0800 (PST) (envelope-from ru@whale.sunbay.crimea.ua) Received: from whale.sunbay.crimea.ua (ru@localhost [127.0.0.1]) by whale.sunbay.crimea.ua (8.12.8/8.12.8/Sunbay) with ESMTP id h2OAoT0J028123 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 Mar 2003 12:50:29 +0200 (EET) (envelope-from ru@whale.sunbay.crimea.ua) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.12.8/8.12.8/Submit) id h2OAoOsu028108; Mon, 24 Mar 2003 12:50:24 +0200 (EET) (envelope-from ru) Date: Mon, 24 Mar 2003 12:50:24 +0200 From: Ruslan Ermilov To: Chip Norkus Cc: Alexey Zelkin , hackers@FreeBSD.org Subject: Re: KVM mice issues Message-ID: <20030324105024.GE23857@sunbay.com> References: <200303230957.36433.wd@arpa.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3XA6nns4nE4KvaS/" Content-Disposition: inline In-Reply-To: <200303230957.36433.wd@arpa.com> User-Agent: Mutt/1.5.4i X-Spam-Status: No, hits=-19.4 required=5.0 tests=AWL,EMAIL_ATTRIBUTION,IN_REP_TO,PGP_SIGNATURE_2, QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_MUTT autolearn=ham version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --3XA6nns4nE4KvaS/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I think Alexey was having similar issues, and may have some non-production quality patches for you to try. On Sun, Mar 23, 2003 at 09:57:36AM -0600, Chip Norkus wrote: >=20 > Greetings hackers, >=20 > I have a KVM switch and a fairly new (Logitech MouseMan+ cordless) mouse,= =20 > and I've found that while FreeBSD properly detects the mouse and all its= =20 > functionality (buttons, scrollwheel, etc) upon boot if I switch to=20 > another port on the KVM and then switch back my mouse "loses" its=20 > functionality. >=20 > After spending a while trying to figure out this problem (and reading PRs= =20 > on the issue (esp. i386/25463)) I found that a solution was not=20 > immediately available, but might be somewhat easy to achieve. In=20 > particular, for my mouse, the mouse driver can and does detect invalid=20 > packets, and invalid packets are always received after a return to my=20 > FreeBSD system via the KVM. I found that doing a reinitialization of the= =20 > device would fix the mouse, but that doing it from the interrupt handler= =20 > (in sys/isa/psm.c around line 2170) caused some intermediate problems. = =20 > Normally the mouse would just bounce around and generate click events for= =20 > a while and then settle down, but occasionally the driver (or maybe=20 > mouse?) would lock solid and I'd have to reboot the system. >=20 > Anyways, I'd like to work further on this problem and hopefully find a=20 > solution, but I'm having some trouble understanding where and what I=20 > should do. I'm not a novice C hacker, but I *am* a very novice kernel=20 > hacker and would appreciate help from anyone with knowledge of the psm=20 > (and atkbdc) code. I've considered maybe adding an ioctl to reset the=20 > mouse and adding a signal handler to moused to force a reset, but that=20 > seems kind of silly when the kernel driver can detect the problem itself= =20 > and resolve it. On the other hand, maybe that's the right way to go? =20 > Advice would be greatly appreciated. >=20 > -chip > --=20 > chip norkus; renaissance hacker; wd@arpa.com > "question =3D (to) ? be : !be;" --Shakespeare http://telekinesis.org/ >=20 >=20 > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message --=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 --3XA6nns4nE4KvaS/ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE+fuLvUkv4P6juNwoRAuT8AJ9L6zyNwZoGIkyz7miz4O/ZDaUjQgCfSlKO yPTtxXHtMvrslFUWHozQ7Eg= =mI63 -----END PGP SIGNATURE----- --3XA6nns4nE4KvaS/-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Mar 24 4:27:42 2003 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 46FC137B401; Mon, 24 Mar 2003 04:27:38 -0800 (PST) Received: from relay1.cris.net (relay1.cris.net [212.110.128.64]) by mx1.FreeBSD.org (Postfix) with ESMTP id E5C1243FA3; Mon, 24 Mar 2003 04:27:32 -0800 (PST) (envelope-from phantom@phantom.cris.net) Received: from phantom.cris.net (root@phantom.cris.net [212.110.130.74]) by relay1.cris.net (8.12.6/8.12.6) with ESMTP id h2OEfdmJ020381; Mon, 24 Mar 2003 14:41:39 GMT Received: (from phantom@localhost) by phantom.cris.net (8.12.6/8.12.2) id h2OCXtxf052797; Mon, 24 Mar 2003 14:33:55 +0200 (EET) (envelope-from phantom) Date: Mon, 24 Mar 2003 14:33:55 +0200 From: Alexey Zelkin To: Ruslan Ermilov Cc: Chip Norkus , hackers@FreeBSD.org Subject: Re: KVM mice issues Message-ID: <20030324143355.A52752@phantom.cris.net> References: <200303230957.36433.wd@arpa.com> <20030324105024.GE23857@sunbay.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20030324105024.GE23857@sunbay.com>; from ru@FreeBSD.org on Mon, Mar 24, 2003 at 12:50:24PM +0200 X-Operating-System: FreeBSD 4.7-STABLE i386 X-Spam-Status: No, hits=-32.5 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_MUTT autolearn=ham version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG hi, Yep. In order to avoid moused(8) getting something crazy (after console switch) I just forced psm reset after synchronization error detection. It can be achieved by changing changing of PSM_SYNCERR_THRESHOLD1 define from 20 to 0 (in file sys/isa/psm.c). Please try to do it and let me know result, if you're also happy with solution -- I'll cleanup and commit my patch which forces such behaviour using sysctl(8). On Mon, Mar 24, 2003 at 12:50:24PM +0200, Ruslan Ermilov wrote: > I think Alexey was having similar issues, and may have some > non-production quality patches for you to try. > > On Sun, Mar 23, 2003 at 09:57:36AM -0600, Chip Norkus wrote: > > > > Greetings hackers, > > > > I have a KVM switch and a fairly new (Logitech MouseMan+ cordless) mouse, > > and I've found that while FreeBSD properly detects the mouse and all its > > functionality (buttons, scrollwheel, etc) upon boot if I switch to > > another port on the KVM and then switch back my mouse "loses" its > > functionality. > > > > After spending a while trying to figure out this problem (and reading PRs > > on the issue (esp. i386/25463)) I found that a solution was not > > immediately available, but might be somewhat easy to achieve. In > > particular, for my mouse, the mouse driver can and does detect invalid > > packets, and invalid packets are always received after a return to my > > FreeBSD system via the KVM. I found that doing a reinitialization of the > > device would fix the mouse, but that doing it from the interrupt handler > > (in sys/isa/psm.c around line 2170) caused some intermediate problems. > > Normally the mouse would just bounce around and generate click events for > > a while and then settle down, but occasionally the driver (or maybe > > mouse?) would lock solid and I'd have to reboot the system. > > > > Anyways, I'd like to work further on this problem and hopefully find a > > solution, but I'm having some trouble understanding where and what I > > should do. I'm not a novice C hacker, but I *am* a very novice kernel > > hacker and would appreciate help from anyone with knowledge of the psm > > (and atkbdc) code. I've considered maybe adding an ioctl to reset the > > mouse and adding a signal handler to moused to force a reset, but that > > seems kind of silly when the kernel driver can detect the problem itself > > and resolve it. On the other hand, maybe that's the right way to go? > > Advice would be greatly appreciated. > > > > -chip > > -- > > chip norkus; renaissance hacker; wd@arpa.com > > "question = (to) ? be : !be;" --Shakespeare http://telekinesis.org/ > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-hackers" in the body of the message > > -- > 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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Mar 24 5: 2:40 2003 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 694CB37B401 for ; Mon, 24 Mar 2003 05:02:37 -0800 (PST) Received: from park.rambler.ru (park.rambler.ru [81.19.64.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8851643FA3 for ; Mon, 24 Mar 2003 05:02:34 -0800 (PST) (envelope-from is@rambler-co.ru) Received: from is.park.rambler.ru (is.park.rambler.ru [81.19.64.102]) by park.rambler.ru (8.12.6/8.12.6) with ESMTP id h2OD2KmF090851; Mon, 24 Mar 2003 16:02:20 +0300 (MSK) Date: Mon, 24 Mar 2003 16:02:19 +0300 (MSK) From: Igor Sysoev X-Sender: is@is To: Andrew Kinney Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: shared mem and panics when out of PV Entries In-Reply-To: <3E7E660C.10419.ECBF5C7@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-25.3 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 24 Mar 2003, Andrew Kinney wrote: > The source of the PV Entry usage is shared memory in Apache > (PHP and/or mod_perl). We know it's Apache memory sharing > that causes the problem because nearly all PV Entries are freed > when Apache is stopped and the problem is worst right after > Apache starts when you have a lot of "clean" memory segments > getting shared (10 to 11 million PV Entries used). After Apache > has run for awhile and the shared memory segments become > unshared due to them being "dirtied", the number of PV Entries > used declines and settles in at a much lower number (3 to 5 million > PV Entries used most days). Apache on this machine likes to > hover right around 256 children processes, so you could see how > requiring duplicate PV Entries per shared memory segment per > Apache process could add up quite quickly. > > Under ideal circumstances, we'd correct our PHP/PERL code to > avoid running into the issue at all, but this is customer code that > we don't have much control over since we allow users to select and > run their own CGI scripts without our intervention. So, for this > instance, we have to solve it at the system level by bullet-proofing > our system as much as possible. How many Apache processes do you have and what's their size ? > I've read that setting sysctl kern.ipc.shm_use_phys to "1" will > cause shared memory segments not to use PV Entries at all. > (See > http://www.geocrawler.com/archives/3/159/2002/6/50/9031353/ ) > However, in the real world with FreeBSD 4.7, setting > kern.ipc.shm_use_phys to "1" seems to have no visible effect on > the number of PV Entries consumed by Apache memory sharing. > We're currently running sysctl kern.ipc.shm_use_phys=1 and are > still seeing the heavy PV Entry usage after rebooting (sysctl set on > boot) with no apparent difference in usage. > > My thoughts at this point are leaning towards setting some limits > on shared memory (kern.ipc.shmmax, kern.ipc.shmseg, > kern.ipc.shmall, and kern.ipc.shmmax sysctl's) to limit the number > of PV Entries that Apache can consume by way of shared > memory. Is that a viable approach to this problem? What kind of > gotchas and caveats should I watch out for in taking this approach? > Any recommendations on which one to tweak first? kern.ipc.shm_use_phys, kern.ipc.shmmax, etc are for System V shared memory. They have no relation to the memory that shared between processes via fork(). Igor Sysoev http://sysoev.ru/en/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Mar 24 7:42:13 2003 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 CBB1937B401 for ; Mon, 24 Mar 2003 07:42:04 -0800 (PST) Received: from mail.speakeasy.net (mail17.speakeasy.net [216.254.0.217]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3976343F75 for ; Mon, 24 Mar 2003 07:42:04 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: (qmail 13138 invoked from network); 24 Mar 2003 15:42:06 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) by mail17.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 24 Mar 2003 15:42:06 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.8/8.12.8) with ESMTP id h2OFg1Ov092124; Mon, 24 Mar 2003 10:42:01 -0500 (EST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.4 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200303222312.35930.soralx@cydem.org.ua> Date: Mon, 24 Mar 2003 10:42:01 -0500 (EST) From: John Baldwin To: soralx@cydem.org.ua Subject: Re: misc/41772: can't disable keybell [PATCH] Cc: freebsd-hackers@FreeBSD.ORG X-Spam-Status: No, hits=-19.5 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES autolearn=ham version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 23-Mar-2003 soralx@cydem.org.ua wrote: > >> Using kbdcontrol -b off on my laptop running current does >> turn off the sound already. > > I tested `kbdcontrol -b off` on FreeBSD 5.0-RELEASE, and it > still did not turn off the beeper. I have also checked > 'syscons.c', v. 1.399 ([0]), and foud only one change > concerning keybell: > 'if (cold || shutdown_in_progress || !enable_bell)' - > ('enable_bell' added, which must be "hw.syscons.bell" > sysctl var), that enables to turn the keybell off globally, > but not for separate vtys. > >> Incidentally, using quiet.off doesn't >> shut it up either which is very confusing since quiet sets >> SC_QUIET_BELL. > > I tested this again, and it works fine: > > `kbdcontrol -b quiet.normal` > `(sleep 2;echo -e "\x07";sleep 2)&` > When, after executing this command, i quickly switch to > another vty, I hear no bell; when I stay on the same vty, > I can hear the bell. > >> PCI ID's for the ICH4 controllere were committed prior to 4.7. > > good, found my controller's ID in the latest CVSweb ATA-PCI tree > >> This patch would inadvertently turn off visual bell's if you >> set the duration or pitch to zero manually. A better patch >> might be: >> >> Index: syscons.c >> =================================================================== >> RCS file: /usr/cvs/src/sys/dev/syscons/syscons.c,v >> retrieving revision 1.399 >> diff -u -r1.399 syscons.c >> --- syscons.c 3 Mar 2003 16:24:44 -0000 1.399 >> +++ syscons.c 22 Mar 2003 14:38:58 -0000 >> @@ -3547,7 +3547,7 @@ >> if (scp != scp->sc->cur_scp) >> scp->sc->blink_in_progress += 2; >> blink_screen(scp->sc->cur_scp); >> - } else { >> + } else if (duration != 0 && pitch != 0) { >> if (scp != scp->sc->cur_scp) >> pitch *= 2; >> sysbeep(pitch, duration); >> >> Can you verify that this fix works for you? > > yes, it does > but, I think, this may produce faster code: > + } else if (duration && pitch) { Nope, optimizing like that is the compiler's job, not the authors. Making readable code that follows style conventions leads to code that is easier to maintain. :) > I also found couple more problems: > > 00. > `kbdcontrol -b 128.800` > `(sleep 2;echo -e "\x07";sleep 2)&` > If I stay on the same vty, I hear 800Hz bell, if I switch > to another vty, I hear ~400Hz bell. > > `kbdcontrol -b normal` > `(sleep 2;echo -e "\x07";sleep 2)&` > If I stay on the same vty, I hear normal bell, if I switch > to another vty, I hear a bell with pitch twice as _high_. > > 01. > `kbdcontrol quiet.115.400` - won't set SC_QUIET_BELL flag I have no idea about these other bugs. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Mar 24 9:15:58 2003 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 CC90737B401; Mon, 24 Mar 2003 09:15:55 -0800 (PST) Received: from prioris.mini.pw.edu.pl (prioris.mini.pw.edu.pl [194.29.178.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1B0A143F3F; Mon, 24 Mar 2003 09:15:55 -0800 (PST) (envelope-from zaks@prioris.mini.pw.edu.pl) Received: from localhost (localhost.mini.pw.edu.pl [127.0.0.1]) by prioris.mini.pw.edu.pl (Postfix) with ESMTP id D9A1D243A1; Mon, 24 Mar 2003 18:15:53 +0100 (CET) Received: by prioris.mini.pw.edu.pl (Postfix, from userid 250) id C1AAF2439F; Mon, 24 Mar 2003 18:15:45 +0100 (CET) Date: Mon, 24 Mar 2003 18:15:15 +0100 From: Slawek Zak To: freebsd-current@freebsd.org Subject: MBuf use size problem on 4.8-RC Message-ID: <20030324171515.GA41416@prioris.mini.pw.edu.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Virus-Scanned: by AMaViS (prioris) X-Spam-Status: No, hits=-7.0 required=5.0 tests=AWL,RESENT_TO,USER_AGENT_MUTT version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi, netstat -m produces following output on my machine, running 4.8-RC: 21732/22336/96000 mbufs in use (current/peak/max): 21732 mbufs allocated to data 20733/21260/24000 mbuf clusters in use (current/peak/max) 48104 Kbytes allocated to network (8% of mb_map in use) 0 requests for memory denied 0 requests for memory delayed 0 calls to protocol drain routines I tracked the percentage of mb_map in use. It reached 70% and then wrapped back to 0%. Why does it happen? A bug? There seems to be a problem with booting up 4.8-RC on a 4GB machine. The kernel reaching multiuser mode produces message about unability of allocating new u_map and panics. This is HyperThreading enabled machine (2+2logical CPUs). Any ideas? Thanks. /S To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Mar 24 11:22: 6 2003 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 9917A37B401 for ; Mon, 24 Mar 2003 11:22:03 -0800 (PST) Received: from lilzcluster.liwest.at (lilzclust02.liwest.at [212.33.55.12]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1A40E43FA3 for ; Mon, 24 Mar 2003 11:22:02 -0800 (PST) (envelope-from dgw@liwest.at) Received: from CM58-27.liwest.at by lilzcluster.liwest.at (8.10.2/1.1.2.11/08Jun01-1123AM) id h2OJJU20001339912; Mon, 24 Mar 2003 20:19:32 +0100 (MET) Content-Type: text/plain; charset="iso-8859-1" From: Daniela To: Wes Peters , Kris Kennaway Subject: Re: Lots of kernel core dumps Date: Mon, 24 Mar 2003 20:18:43 +0100 User-Agent: KMail/1.4.3 Cc: hackers@FreeBSD.ORG References: <200303212037.46322.dgw@liwest.at> <200303230010.38736.dgw@liwest.at> <200303231120.15652.wes@softweyr.com> In-Reply-To: <200303231120.15652.wes@softweyr.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200303242018.43648.dgw@liwest.at> X-Spam-Status: No, hits=-31.9 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_KMAIL autolearn=ham version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sunday 23 March 2003 20:20, Wes Peters wrote: > On Saturday 22 March 2003 15:10, Daniela wrote: > > > I know, but 5.0-RELEASE was > > > > > > a) A work-in-progress, not a perfect, bug-free release > > > > > > b) A snapshot of 5.0-CURRENT > > > > > > You read the 5.0 Early Adopter's Guide, right? Bugs like this are > > > expected at this stage in the development process, and if you > > > encounter them then you need to either give up on 5.x and go back t= o > > > 4.x-STABLE, or upgrade to 5.0-CURRENT if they are already fixed > > > there. > > > > > > Kris > > > > Yes, I read the Early Adopter's Guide. > > Is there any way to solve this without upgrading to -current? > > I want a stable server, of course, but I still want to help the FreeB= SD > > folks to make 5.0 the best release ever. This requires testing to be > > done. > > Yes it does, but not on a "production" machine. We admire your courage > and willingness to help, but it's not helping as much as you think. ;^) > > The reason for creating the 5.0 release is to make it easy for more > developers and testers to jump onto the 5.x bandwagon by giving them a > known (relatively) good starting point. Quite a number of problems hav= e > been fixed since 5.0-RELEASE; CURRENT is now generally much more stable= , > and nobody is going to spend time updating 5.0 which is essentially an > "early access" release. > > You have to decide for yourself if this machine is too critical to run > CURRENT, in which case it's probably best off running STABLE or the > latest 4.x release branch, or if you want to update it to CURRENT, foll= ow > the CURRENT mailing list, and update again at known stable development > points. It looks like right now is pretty good if you want to jump. > > At any rate, thanks for your tenacity. We really do appreciate the > contributions of everyone. Well, it's just a home server. I don't mind a few crashes, but security i= s=20 important for me. What do you think, should I go back to -stable? FreeBSD is the world's best OS, I want to see it succeeding and I want to= help=20 as much as possible. Daniela To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Mar 24 12: 4:55 2003 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 BB18A37B401 for ; Mon, 24 Mar 2003 12:04:53 -0800 (PST) Received: from mx1.lphp.org (APastourelles-107-1-11-181.abo.wanadoo.fr [217.128.154.181]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6DFA543FA3 for ; Mon, 24 Mar 2003 12:04:49 -0800 (PST) (envelope-from ajacoutot@lphp.org) Received: from sta01 (sta01.lphp.org.local [192.168.0.4]) by mx1.lphp.org (8.12.6/8.12.6) with ESMTP id h2OK4kIO016464 for ; Mon, 24 Mar 2003 21:04:46 +0100 (CET) (envelope-from ajacoutot@lphp.org) From: Antoine Jacoutot To: hackers@freebsd.org Subject: ISD200 Date: Mon, 24 Mar 2003 21:04:45 +0100 User-Agent: KMail/1.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200303242104.45902.ajacoutot@lphp.org> X-Spam-Status: No, hits=1.0 required=5.0 tests=USERPASS,USER_AGENT version=2.50 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hello ! I'm hope this is the right place for asking that... I was wondering if someone could write or port (from Linux) a driver for external USB hardrive using the InSystem ISD200 cable. It doesn't work with the regular umass driver, someone told me that it seems that these are bulk/bulk/bulk transport protocol devices, but using an alternative encapsulation of the ATAPI protocol on top of that. Here is the Linux driver listing: http://linuxusb.bkbits.net:8080/usb-2.5/anno/drivers/usb/storage/isd200.c@1.33?nav=index.html|src/|src/drivers|src/drivers/usb|src/drivers/usb/storage I'm unfortunately not a developer but I would be pleased to help, so I could access my "2 months old" new USB hardrive (I was so sure it was going to work under FreeBSD, but it never did). Thank you. Antoine To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Mar 24 12:53:48 2003 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 CD26C37B401 for ; Mon, 24 Mar 2003 12:53:43 -0800 (PST) Received: from arpa.com (arpa.com [199.245.173.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3FA6543F3F for ; Mon, 24 Mar 2003 12:53:43 -0800 (PST) (envelope-from wd@arpa.com) Received: from localhost (localhost [127.0.0.1]) by arpa.com (Postfix) with ESMTP id 9760E20139; Mon, 24 Mar 2003 14:53:40 -0600 (CST) Received: from gondolin (d14-69-64-77.nap.wideopenwest.com [69.14.77.64]) by arpa.com (Postfix) with ESMTP id CD41820136; Mon, 24 Mar 2003 14:53:39 -0600 (CST) From: Chip Norkus Organization: Telekinetic Industries To: Alexey Zelkin Subject: Re: KVM mice issues Date: Mon, 24 Mar 2003 14:51:26 -0600 User-Agent: KMail/1.5 References: <200303230957.36433.wd@arpa.com> <20030324105024.GE23857@sunbay.com> <20030324143355.A52752@phantom.cris.net> In-Reply-To: <20030324143355.A52752@phantom.cris.net> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200303241429.31488.wd@arpa.com> Cc: hackers@freebsd.org Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS snapshot-20020531 X-Spam-Status: No, hits=-25.5 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT autolearn=ham version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Monday 24 March 2003 06:33 am, you wrote: > hi, > Hi Alxey, > Yep. In order to avoid moused(8) getting something crazy (after > console switch) I just forced psm reset after synchronization error > detection. It can be achieved by changing changing of > PSM_SYNCERR_THRESHOLD1 define from 20 to 0 (in file sys/isa/psm.c). > > Please try to do it and let me know result, if you're also happy > with solution -- I'll cleanup and commit my patch which forces such > behaviour using sysctl(8). > I tried this. Unfortunately it didn't work for my particular problem. I went back to my original solution (which seems to be pretty MouseMan+ centric unfortunately) of reinitializing the mouse after a protocol error, and I think I have something that works at least as well as the Windows driver. The optimal solution (for me) is to reset the mouse on protocol error and also to set PSM_SYNCERR_THRESHOLD1 to 0 (I get a lot of sync errors after I do a reset.. I imagine I'm doing something incorrectly here :). So far this solution seems to work well, at least I haven't lost my mouse wheel after switching to/from another port on the KVM. When I switch back my mouse acts a bit odd for a moment (the sync errors) and then resets itself and seems to work fine. I'm much happier with a momentarily flaky mouse *with* a mousewheel than a non-flaky mouse without one. If you're interested I can send you the patch I've got. Thanks for your help! -chip -- chip norkus; renaissance hacker; wd@arpa.com "question = (to) ? be : !be;" --Shakespeare http://telekinesis.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Mar 24 13:59:56 2003 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 D588037B405 for ; Mon, 24 Mar 2003 13:59:53 -0800 (PST) Received: from office.advantagecom.net (office.advantagecom.net [207.109.186.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1726143F75 for ; Mon, 24 Mar 2003 13:59:53 -0800 (PST) (envelope-from andykinney@advantagecom.net) Received: from SCSI-MONSTER (andy.advantagecom.net [207.109.186.200] (may be forged)) by office.advantagecom.net (8.9.3/8.9.3) with ESMTP id NAA26997; Mon, 24 Mar 2003 13:59:38 -0800 From: "Andrew Kinney" Organization: Advantagecom Networks, Inc. To: Igor Sysoev Date: Mon, 24 Mar 2003 14:00:05 -0800 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: shared mem and panics when out of PV Entries Reply-To: andykinney@advantagecom.net Cc: freebsd-hackers@FreeBSD.ORG Message-ID: <3E7F0F65.7994.11617945@localhost> References: <3E7E660C.10419.ECBF5C7@localhost> In-reply-to: X-mailer: Pegasus Mail for Win32 (v3.12c) X-Spam-Status: No, hits=-13.1 required=5.0 tests=AWL,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 24 Mar 2003, at 16:02, Igor Sysoev wrote: > How many Apache processes do you have and what's their size ? It varies between 150 and 256 Apache processes. Our MaxClients is set to 256, which seems to work well. Their size varies from 240MB to 290MB depending on how long they've been running. Their resident set size (RSS) is usually between 7MB and 90MB each, though it seems to average about 60MB each (as shown in 'top' and 'ps'). The root Apache process has the same size as the others, but the RSS is only 1.2MB. > kern.ipc.shm_use_phys, kern.ipc.shmmax, etc are for System V shared > memory. They have no relation to the memory that shared between > processes via fork(). That would explain why they've not had any effect on this issue. :-) So, what's the best approach to limiting memory shared via fork() or reducing PV Entry usage by that memory? Is there something I can do with the kernel config or sysctl to accomplish this? Sincerely, Andrew Kinney President and Chief Technology Officer Advantagecom Networks, Inc. http://www.advantagecom.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Mar 24 18: 4:52 2003 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 CF71737B401; Mon, 24 Mar 2003 18:04:47 -0800 (PST) Received: from resnet.uoregon.edu (resnet.uoregon.edu [128.223.122.47]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4207443F3F; Mon, 24 Mar 2003 18:04:47 -0800 (PST) (envelope-from gurney_j@resnet.uoregon.edu) Received: by resnet.uoregon.edu (Postfix, from userid 1001) id 4E5641930E; Mon, 24 Mar 2003 18:04:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by resnet.uoregon.edu (Postfix) with ESMTP id 2AA821D112; Tue, 25 Mar 2003 09:04:34 +0700 (ICT) Date: Tue, 25 Mar 2003 09:04:34 +0700 (ICT) From: John-Mark Gurney To: "M. Warner Losh" Cc: mdodd@FreeBSD.ORG, , Subject: Re: bug in subr_bus.c? In-Reply-To: <20030323.092305.83978540.imp@bsdimp.com> Message-ID: <20030325085519.I97066-100000@resnet.uoregon.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-19.5 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES autolearn=ham version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, 23 Mar 2003, M. Warner Losh wrote: > In message: <20030323174445.K36261-100000@resnet.uoregon.edu> > John-Mark Gurney writes: > : The bus code could use some locking in it... like you can't delete_child > : from child_detache... and/or better docs on how to handle children... I'm > : not even sure how I was doing things wrong, but I think it might of been > : problems with my code not calling bus_generic_detach before calling > : device_child_delete... > > I'm doing the locking, but you can do a bus_delete_child in a child's > detach routine. Cardbus does this right now and it works when you > unload the cardbus bridge... (btw, I'm using 1.117.2.1 as reference 5.0-R) I'm talking about child_detached (I forgot the d), not detach... so, say you have a bus driver that has a child_detached routine. When you unload the kld for the child, the kld will do a detach of the child. If you look at the device_detach, it will call the device's detach, then the parent's child_detached routine all before marking the device as NOTPRESENT. If you try to do a device_delete_child in the child_detached routine, device_delete_child will call device_detach again, and since the state is still ATTACHED, it will go through the detach procedure again, and either end up with a memory fault or a recursive loop. I just looked briefly at the cardbus code, and you don't have a child_detached routine. John-Mark To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Mar 24 18:16: 0 2003 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 A9DE737B404 for ; Mon, 24 Mar 2003 18:15:57 -0800 (PST) Received: from bsd.masp.srv.br (bsd.masp.srv.br [200.223.149.86]) by mx1.FreeBSD.org (Postfix) with SMTP id 6D9DE43F75 for ; Mon, 24 Mar 2003 18:15:55 -0800 (PST) (envelope-from fabio@isec.com.br) Received: (qmail 33739 invoked from network); 25 Mar 2003 02:17:03 -0000 Received: from unknown (HELO borg) (200.164.0.100) by bsd.masp.srv.br with SMTP; 25 Mar 2003 02:17:03 -0000 Message-ID: <000d01c2f274$50deebf0$0700000a@borg> From: "Fabio Vilan Dias" To: , , Subject: User-PPP MTU/MRU - LCP Problem Date: Mon, 24 Mar 2003 23:14:50 -0300 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 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Status: No, hits=1.8 required=5.0 tests=RCVD_IN_RFCI version=2.50 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG There is a problem in user-ppp LCP negotation that sometimes the assigned tun0 MTU is incorrectly set. I've sent this msg to brian (the freebsd user-ppp responsible), and then submited a bug report (patch example included) on Feb 17, but I haven't heard anything from him (or anyone else) since them, maybe he's away or something... http://www.freebsd.org/cgi/query-pr.cgi?pr=48378 If someone can handle this, and as 4.8-release has been postponed, can have this fixed on it, it would be great. There seems to be many users with this problem, specially regarding PPPoE and other interfaces with non-standard MTU of 1500. Read the bug report for more information about the problem and a patch example. Thanks -- Fabio Vilan "Any sufficiently advanced technology is indistinguishable from magic." Arthur C. Clarke's Third Law, from Profiles of the Future To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Mar 24 20:57:13 2003 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 F404D37B404 for ; Mon, 24 Mar 2003 20:57:10 -0800 (PST) Received: from kientzle.com (h-66-166-149-50.SNVACAID.covad.net [66.166.149.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id A81ED43FDD for ; Mon, 24 Mar 2003 20:57:08 -0800 (PST) (envelope-from kientzle@acm.org) Received: from acm.org (ugly.x.kientzle.com [66.166.149.51]) by kientzle.com (8.11.3/8.11.3) with ESMTP id h2P4v8M20501 for ; Mon, 24 Mar 2003 20:57:08 -0800 (PST) (envelope-from kientzle@acm.org) Message-ID: <3E7FE1C4.3040104@acm.org> Date: Mon, 24 Mar 2003 20:57:40 -0800 From: Tim Kientzle Reply-To: kientzle@acm.org 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 Subject: Incorrect declarations for exec* Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-5.8 required=5.0 tests=USER_AGENT_MOZILLA_UA autolearn=ham version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I believe the exec* functions are declared incorrectly. Unless I'm mistaken, execve should be declared as int execve(const char *path, const char *const argv[], const char *const envp[]); rather than int execve(const char *path, char *const argv[], char *const envp[]); (Note the additional 'const' for argv and envp.) Without this, there's no completely correct way to build an argv or envp array with constant strings, since you end up discarding a const somewhere along the way. Similar edits should be done to the other exec* declarations. Yes, GCC complains either way, since it (erroneously) warns about adding const-ness in a pointer assignment. (But only if you routinely use '-pedantic', which I doubt many people do. ;-) Tim Kientzle To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Mar 24 21:50:40 2003 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 5390C37B401 for ; Mon, 24 Mar 2003 21:50:38 -0800 (PST) Received: from puffin.mail.pas.earthlink.net (puffin.mail.pas.earthlink.net [207.217.120.139]) by mx1.FreeBSD.org (Postfix) with ESMTP id C157B43F75 for ; Mon, 24 Mar 2003 21:50:37 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from pool0249.cvx40-bradley.dialup.earthlink.net ([216.244.42.249] helo=mindspring.com) by puffin.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 18xhKT-00014S-00; Mon, 24 Mar 2003 21:50:34 -0800 Message-ID: <3E7FEDDC.61F62C30@mindspring.com> Date: Mon, 24 Mar 2003 21:49:16 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: kientzle@acm.org Cc: FreeBSD-Hackers Subject: Re: Incorrect declarations for exec* References: <3E7FE1C4.3040104@acm.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4e5378f0e50ccacd2805c28a50e1b5c06350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Spam-Status: No, hits=-21.8 required=5.0 tests=AWL,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,RCVD_IN_UNCONFIRMED_DSBL,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Tim Kientzle wrote: > I believe the exec* functions are > declared incorrectly. Unless I'm mistaken, > execve should be declared as > > int > execve(const char *path, const char *const argv[], const char *const envp[]); > > rather than > > int > execve(const char *path, char *const argv[], char *const envp[]); http://www.opengroup.org/onlinepubs/7908799/xsh/execve.html -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Mar 24 21:56:26 2003 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 65DCF37B401 for ; Mon, 24 Mar 2003 21:56:24 -0800 (PST) Received: from albatross.mail.pas.earthlink.net (albatross.mail.pas.earthlink.net [207.217.120.120]) by mx1.FreeBSD.org (Postfix) with ESMTP id D724F43FA3 for ; Mon, 24 Mar 2003 21:56:21 -0800 (PST) (envelope-from mooneer@translator.cx) Received: from pool0068.cvx18-bradley.dialup.earthlink.net ([209.179.238.68] helo=morpheus) by albatross.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18xhQ4-0002pB-00 for freebsd-hackers@freebsd.org; Mon, 24 Mar 2003 21:56:20 -0800 From: "Mooneer Salem" To: "FreeBSD Hackers" Subject: Jail seperation patch (v7) Date: Mon, 24 Mar 2003 21:56:18 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal X-Spam-Status: No, hits=-5.1 required=5.0 tests=MSGID_GOOD_EXCHANGE,RCVD_IN_OSIRUSOFT_COM autolearn=ham version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hello, I released a new version of the jail seperation patch I've been working on for FreeBSD 5.0. Changes from v6: * Ported Jared Mauch's raw IP patch over to the 5.0 tree * Added sysctl to allow/disallow ipfw use * ipfw2: it requires jailed users to use IP addresses that are inside their jails (thereby preventing interference between jails) If anyone's interested in testing it, it can be found at http://msalem.translator.cx/dist/jail_seperation.v7.patch. Thanks, -- Mooneer Salem GPLTrans: http://www.translator.cx/ lifeafterking.org: http://www.lifeafterking.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Mar 24 23:30:15 2003 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 7246A37B428 for ; Mon, 24 Mar 2003 23:29:55 -0800 (PST) Received: from cirb503493.alcatel.com.au (c18609.belrs1.nsw.optusnet.com.au [210.49.80.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id EB7134412C for ; Mon, 24 Mar 2003 23:14:23 -0800 (PST) (envelope-from peterjeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1]) by cirb503493.alcatel.com.au (8.12.8/8.12.8) with ESMTP id h2P7ELM2016102; Tue, 25 Mar 2003 18:14:21 +1100 (EST) (envelope-from jeremyp@cirb503493.alcatel.com.au) Received: (from jeremyp@localhost) by cirb503493.alcatel.com.au (8.12.8/8.12.8/Submit) id h2P7EJTL016101; Tue, 25 Mar 2003 18:14:19 +1100 (EST) Date: Tue, 25 Mar 2003 18:14:19 +1100 From: Peter Jeremy To: Daniela Cc: hackers@FreeBSD.ORG Subject: Re: Lots of kernel core dumps Message-ID: <20030325071418.GA16046@cirb503493.alcatel.com.au> References: <200303212037.46322.dgw@liwest.at> <200303230010.38736.dgw@liwest.at> <200303231120.15652.wes@softweyr.com> <200303242018.43648.dgw@liwest.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200303242018.43648.dgw@liwest.at> User-Agent: Mutt/1.4.1i X-Spam-Status: No, hits=-29.3 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_MUTT autolearn=ham version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Mar 24, 2003 at 08:18:43PM +0100, Daniela wrote: >Well, it's just a home server. I don't mind a few crashes, but security is >important for me. What do you think, should I go back to -stable? If you're willing to put up with a few crashes _and_ assist with debugging the crashes (eg trying patches) then running -CURRENT would help the Project. One option you could try is to stick with -CURRENT for a month or two and see how it pans out - if you feel it's too painful, downgrade to -STABLE. (I ran -CURRENT on my main workstation for about 3 years - I dropped back to -STABLE midway through last year because -CURRENT happened to strike an extended period of instability and it was causing me too much angst). On the topic of security, you should be aware that -CURRENT is not officially supported and therefore isn't mentioned in security advisories - in general -CURRENT will have security patches applied before -STABLE but you will need to do some detective work if you want to identify the exact time/revision affected. There have also been a couple of instances where security problems only affected -CURRENT. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Mar 25 0: 9:10 2003 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 1A75A37B401; Tue, 25 Mar 2003 00:09:06 -0800 (PST) Received: from jawa.at (jawa.at [213.229.17.146]) by mx1.FreeBSD.org (Postfix) with ESMTP id CFA7243F3F; Tue, 25 Mar 2003 00:09:04 -0800 (PST) (envelope-from mbretter@jawa.at) Received: from jawa.at (dings.jawa.at [192.168.200.60]) by jawa.at (8.12.6/8.12.6) with ESMTP id h2P8901Z029948; Tue, 25 Mar 2003 09:09:00 +0100 (CET) (envelope-from mbretter@jawa.at) Message-ID: <3E800E9E.3030408@jawa.at> Date: Tue, 25 Mar 2003 09:09:02 +0100 From: Michael Bretterklieber Organization: JAWA Management Software GmbH User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-AT; rv:1.2.1) Gecko/20021130 X-Accept-Language: de, en MIME-Version: 1.0 To: Fabio Vilan Dias Cc: freebsd-hackers@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG Subject: Re: User-PPP MTU/MRU - LCP Problem References: <000d01c2f274$50deebf0$0700000a@borg> In-Reply-To: <000d01c2f274$50deebf0$0700000a@borg> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Spam-Status: No, hits=-31.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES, SIGNATURE_LONG_DENSE,USER_AGENT_MOZILLA_UA autolearn=ham version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi, Fabio Vilan Dias schrieb: > There is a problem in user-ppp LCP negotation that sometimes the assigned > tun0 MTU is incorrectly set. > > I've sent this msg to brian (the freebsd user-ppp responsible), and then > submited a bug report (patch example included) on Feb 17, but I haven't > heard anything from him (or anyone else) since them, maybe he's away or > something... I also tried in the last 2 or 3 months 3 times to contact him because I have patches for libradius, but never got any response. It seems that userland-ppp (and some other things) are currently "un-maintained". bye, -- ------------------------------- ---------------------------------- Michael Bretterklieber - Michael.Bretterklieber@jawa.at JAWA Management Software GmbH - http://www.jawa.at Liebenauer Hauptstr. 200 -------------- privat ------------ A-8041 GRAZ GSM: ++43-(0)676-84 03 15 712 Tel: ++43-(0)316-403274-12 E-mail: michael@bretterklieber.com Fax: ++43-(0)316-403274-10 http://www.bretterklieber.com ------------------------------- ---------------------------------- "...the number of UNIX installations has grown to 10, with more expected..." - Dennis Ritchie and Ken Thompson, June 1972 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Mar 25 2:12:28 2003 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 61FB937B401 for ; Tue, 25 Mar 2003 02:12:26 -0800 (PST) Received: from mail.engr.ucsb.edu (mail.engr.ucsb.edu [128.111.53.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0444843F3F for ; Tue, 25 Mar 2003 02:12:26 -0800 (PST) (envelope-from shvetima@engineering.ucsb.edu) Received: from ecipc056.engr.ucsb.edu ([128.111.53.119]) by mail.engr.ucsb.edu with esmtp (Exim 4.12) id 18xlPm-0001EC-00 for freebsd-hackers@freebsd.org; Tue, 25 Mar 2003 02:12:18 -0800 Date: Tue, 25 Mar 2003 02:11:45 -0800 (PST) From: Shvetima Gulati X-X-Sender: To: Message-ID: MIME-Version: 1.0 Subject: learning device drivers Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-5.8 required=5.0 tests=USER_AGENT_PINE autolearn=ham version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG HI folks, I want to learn how to write device drivers for FreeBSD. How different is this from Linux? Second, is there a list of devices that need drivers written for them ? I want to take a hands-on approach to learning so a real world project would be more useful. Thanks, -Shv. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Mar 25 2:14:56 2003 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 3F54937B401 for ; Tue, 25 Mar 2003 02:14:55 -0800 (PST) Received: from mail.engr.ucsb.edu (mail.engr.ucsb.edu [128.111.53.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id DDCB843F85 for ; Tue, 25 Mar 2003 02:14:54 -0800 (PST) (envelope-from shvetima@engineering.ucsb.edu) Received: from ecipc056.engr.ucsb.edu ([128.111.53.119]) by mail.engr.ucsb.edu with esmtp (Exim 4.12) id 18xlSF-0001Lr-00 for freebsd-hackers@freebsd.org; Tue, 25 Mar 2003 02:14:51 -0800 Date: Tue, 25 Mar 2003 02:14:19 -0800 (PST) From: Shvetima Gulati X-X-Sender: To: Message-ID: MIME-Version: 1.0 Subject: 4.8-RELEASE Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-5.8 required=5.0 tests=USER_AGENT_PINE autolearn=ham version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi all, Wasn't 4.8-RELEASE supposed to hit the mirrors today? Any news / delay ? Thanks, -Shv. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Mar 25 2:37:24 2003 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 B4B9537B401 for ; Tue, 25 Mar 2003 02:37:22 -0800 (PST) Received: from falcon.midgard.homeip.net (h76n3fls20o913.telia.com [213.67.148.76]) by mx1.FreeBSD.org (Postfix) with SMTP id 950ED43F3F for ; Tue, 25 Mar 2003 02:37:20 -0800 (PST) (envelope-from ertr1013@student.uu.se) Received: (qmail 572 invoked by uid 1001); 25 Mar 2003 10:37:19 -0000 Date: Tue, 25 Mar 2003 11:37:18 +0100 From: Erik Trulsson To: Shvetima Gulati Cc: freebsd-hackers@freebsd.org Subject: Re: 4.8-RELEASE Message-ID: <20030325103718.GA541@falcon.midgard.homeip.net> Mail-Followup-To: Shvetima Gulati , freebsd-hackers@freebsd.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.3i X-Spam-Status: No, hits=-31.4 required=5.0 tests=EMAIL_ATTRIBUTION,FROM_ENDS_IN_NUMS,IN_REP_TO, MAILTO_TO_SPAM_ADDR,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_MUTT autolearn=ham version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, Mar 25, 2003 at 02:14:19AM -0800, Shvetima Gulati wrote: > > Hi all, > > Wasn't 4.8-RELEASE supposed to hit the mirrors today? Any news / delay ? Yes and yes, and if you had been bothering to read the -stable mailing list (which is where any such news can be expected to appear) you would already know this. -- Erik Trulsson ertr1013@student.uu.se To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Mar 25 5:13:36 2003 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 DABA337B401 for ; Tue, 25 Mar 2003 05:13:34 -0800 (PST) Received: from mail.renet.ru (ns.renet.ru [195.161.130.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7189F43FA3 for ; Tue, 25 Mar 2003 05:13:30 -0800 (PST) (envelope-from vys@renet.ru) Received: from renet.ru (localhost [127.0.0.1]) by mail.renet.ru (8.12.6/8.12.6) with SMTP id h2PDGwq4029113 for ; Tue, 25 Mar 2003 16:16:58 +0300 (MSK) Received: from 195.161.130.250 (proxying for 195.161.130.4) (SquirrelMail authenticated user vys@renet.ru) by mail.renet.ru with HTTP; Tue, 25 Mar 2003 16:16:58 +0300 (MSK) Message-ID: <3585.195.161.130.250.1048598218.squirrel@mail.renet.ru> Date: Tue, 25 Mar 2003 16:16:58 +0300 (MSK) Subject: Question about BPF API (PCAP not like for me) From: "Vladimir Yu. Stepanov" To: X-Priority: 3 Importance: Normal Reply-To: vys@renet.ru X-Mailer: SquirrelMail (version 1.2.11) MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hello ! I have a little question about BPF: how to determine incoming or outgoing packet given into the user level mode. Current API do not supported this or I are wrong ? Thanks. -- Vladimir Yu. Stepanov E-Mail: vys@renet.ru Phone: +7 (845) 2450450 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Mar 25 6:56:37 2003 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 7055837B401 for ; Tue, 25 Mar 2003 06:56:31 -0800 (PST) Received: from park.rambler.ru (park.rambler.ru [81.19.64.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 04D0543FA3 for ; Tue, 25 Mar 2003 06:56:30 -0800 (PST) (envelope-from is@rambler-co.ru) Received: from is.park.rambler.ru (is.park.rambler.ru [81.19.64.102]) by park.rambler.ru (8.12.6/8.12.6) with ESMTP id h2PEuKmF033137; Tue, 25 Mar 2003 17:56:20 +0300 (MSK) Date: Tue, 25 Mar 2003 17:56:20 +0300 (MSK) From: Igor Sysoev X-Sender: is@is To: Andrew Kinney Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: shared mem and panics when out of PV Entries In-Reply-To: <3E7F0F65.7994.11617945@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-25.3 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 24 Mar 2003, Andrew Kinney wrote: > On 24 Mar 2003, at 16:02, Igor Sysoev wrote: > > > How many Apache processes do you have and what's their size ? > > It varies between 150 and 256 Apache processes. Our MaxClients > is set to 256, which seems to work well. > > Their size varies from 240MB to 290MB depending on how long > they've been running. Their resident set size (RSS) is usually > between 7MB and 90MB each, though it seems to average about > 60MB each (as shown in 'top' and 'ps'). > > The root Apache process has the same size as the others, but the > RSS is only 1.2MB. > > > kern.ipc.shm_use_phys, kern.ipc.shmmax, etc are for System V shared > > memory. They have no relation to the memory that shared between > > processes via fork(). > > That would explain why they've not had any effect on this issue. :-) > > So, what's the best approach to limiting memory shared via fork() > or reducing PV Entry usage by that memory? Is there something I > can do with the kernel config or sysctl to accomplish this? No, as far as I know there's no way to do it. The irony is that you do not need the most of these PV entries because you are not swaping. I think you should try to decrease memory that shared between Apache processes. If you can not change scripts then the single method is to decrease number of Apache processes while keeping to handle the current workload: 1) disable keepalive if it enabled; 2) set Apache behind reverse-proxy server that frees Apache processes as soon as proxy get the whole responses. Igor Sysoev http://sysoev.ru/en/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Mar 25 9: 3: 6 2003 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 EA05037B401 for ; Tue, 25 Mar 2003 09:03:04 -0800 (PST) Received: from hotmail.com (f50.law14.hotmail.com [64.4.21.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9197A43F3F for ; Tue, 25 Mar 2003 09:03:04 -0800 (PST) (envelope-from aaa000111@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 25 Mar 2003 09:03:04 -0800 Received: from 69.3.176.26 by lw14fd.law14.hotmail.msn.com with HTTP; Tue, 25 Mar 2003 17:03:03 GMT X-Originating-IP: [69.3.176.26] X-Originating-Email: [aaa000111@hotmail.com] From: "af asdf" To: freebsd-hackers@freebsd.org Subject: disklabal messed, need help! Date: Wed, 26 Mar 2003 01:03:03 +0800 Mime-Version: 1.0 Content-Type: text/plain; charset=gb2312; format=flowed Message-ID: X-OriginalArrivalTime: 25 Mar 2003 17:03:04.0671 (UTC) FILETIME=[6691F6F0:01C2F2F0] X-Spam-Status: No, hits=4.0 required=5.0 tests=BODY_8BITS,FROM_ENDS_IN_NUMS,FROM_WEBMAIL_ENDS_IN_NUMS6 version=2.50 X-Spam-Level: **** X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Anyone knows how to repair disk when the freebsddisk lable is destroyed? I have a 12G HD, the 1st partition is Windows NT, the second the for FreeBSD. For some reason i installed a new disk label to it and newfs it a bit. Once I found the newfs started, I have turned power off right away, but the disk is bad now. anyone knows how to repair this? Best Regards Eric _________________________________________________________________ ÏíÓÃÊÀ½çÉÏ×î´óµÄµç×ÓÓʼþϵͳ¡ª MSN Hotmail¡£ http://www.hotmail.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Mar 25 11:19:54 2003 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 43C3837B401 for ; Tue, 25 Mar 2003 11:19:52 -0800 (PST) Received: from sdf.lonestar.org (sdf.lonestar.org [216.162.208.192]) by mx1.FreeBSD.org (Postfix) with ESMTP id D32EC43F3F for ; Tue, 25 Mar 2003 11:19:49 -0800 (PST) (envelope-from omestre@sdf.lonestar.org) Received: (from omestre@localhost) by sdf.lonestar.org (8.12.8/8.12.8) id h2PJJnGF028259; Tue, 25 Mar 2003 19:19:49 GMT Date: Tue, 25 Mar 2003 19:19:48 +0000 (UTC) From: omestre To: freebsd-hackers@freebsd.org Subject: pam_ldap + nss_ldap Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-5.8 required=5.0 tests=USER_AGENT_PINE autolearn=ham version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hello, sorry, but i need to know where can i find a how to for FreeBSD 5.0 working with pam_ldap authentication. There is pam_ldap in ports/security, but and support in the libc? i did put one /etc/pam.d/sshd file and tcpdump my ssh connection... the module is talking with the ldap server, but i have not nss (ldap) module in the Operating System. how can i make it works? I have thought that Free 5.0 should work with LDAP by default... :( Thanks very much! omestre@sdf.lonestar.org SDF Public Access UNIX System - http://sdf.lonestar.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Mar 25 17:13:24 2003 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 C673037B404 for ; Tue, 25 Mar 2003 17:13:20 -0800 (PST) Received: from Awfulhak.org (gw.Awfulhak.org [217.204.245.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id A118943F75 for ; Tue, 25 Mar 2003 17:13:19 -0800 (PST) (envelope-from brian@Awfulhak.org) Received: from mail.lan.Awfulhak.org (brian@hak.Awfulhak.org [IPv6:2001:6f8:602:1::12]) by Awfulhak.org (8.12.8/8.12.8) with SMTP id h2Q1CQTj015635; Wed, 26 Mar 2003 01:12:27 GMT (envelope-from brian@Awfulhak.org) Date: Wed, 26 Mar 2003 01:12:26 +0000 From: Brian Somers To: Maksim Yevmenkin Cc: hackers@FreeBSD.ORG, questions@FreeBSD.ORG, brian@FreeBSD.ORG, tlambert2@mindspring.com, doconnor@gsoft.com.au, imp@bsdimp.com Subject: Re: [PATCH2] PPP in -direct mode does not execute any chat scripts Message-Id: <20030326011226.051dbae9.brian@Awfulhak.org> In-Reply-To: <3E3EF111.5050401@exodus.net> References: <45258A4365C6B24A9832BFE224837D552B1283@sjdcex01.int.exodus.net> <3E3ED4DF.7090904@exodus.net> <3E3EDE11.192ABC3F@mindspring.com> <3E3EF111.5050401@exodus.net> X-Mailer: Sylpheed version 0.8.5claws (GTK+ 1.2.10; i386-portbld-freebsd5.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-26.1 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi, Yes, this looks fine, although I think this shows that the -direct description is wrong. Perhaps this is more appropriate: -direct This is used for communicating over an already established connection, usually when receiving incoming connections accepted by getty(8). ppp ignores the ``set device'' line and uses descriptor 0 as the link. ppp will ignore any configured chat scripts unless the ``force-scripts'' option has been enabled. If callback.... Do you agree with this description ? If so, I'll go ahead and commit the changes. Just to be picky, I'll re-sort the OPT_ variables too :*P And thanks for the patches. On Mon, 03 Feb 2003 14:45:37 -0800, Maksim Yevmenkin wrote: > Dear Brian and Hackers, > > Please find updated proposed version of the patch. As suggested by > Warner option has been renamed to 'force-sripts' and now works for > both 'direct' and 'dedicated' modes. Also as suggested by Terry the > man page has been updated to document side effect of 'direct'. > > -direct > This is used for receiving incoming connections. ppp ignores the > ``set device'' line and uses descriptor 0 as the link. ppp will > never use any configured chat scripts unless ``force-scripts'' > option has been enabled. > > If callback is configured, ppp will use the ``set device'' infor- > mation when dialing back. > > -dedicated > This option is designed for machines connected with a dedicated > wire. ppp will always keep the device open and will never use > any configured chat scripts unless ``force-scripts'' option has > been enabled. > > force-scripts > Default: Disabled. Forces execution of the configured chat > scripts in direct and dedicated modes. > > >>Please find attached patch that adds new option to the PPP. > >> > >>run-scripts-in-direct-mode > >> Default: Disabled. This allows to run chat scripts in > >> direct mode. > >> > >>did i miss anything? objections? comments? reviews? > > > > > > First comment: run it past Brian Somers ; it's > > his baby, and he's the active maintainer. > > I have sent him e-mail. > > > Rest of comments: > > > > Actually, why doesn't "-direct" allow a chat script by default? > > The man page doesn't document that as a side-effect of "-direct", > > only of "-dedicated", but it's been there since the import. > > > > Should this really be a "negotiate" section command, rather than > > just a command or a "set" command? > > > > Also, there are only two other commands even have a "-" in them, > > and both of them only have one (just seems a little long, compared > > to, say, "rsid" or "direct-with-script", or even "force-script"). > > > > Personal preference: don't make it conditional on "-direct", let > > it also work with "-dedicated", and call it "force-script" or > > something, instead. > > done > > > The man page should be updated -- including the undocumented > > side-effect of "-direct" disabling scripts). > > done > > thanks > max > -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Mar 25 17:15:59 2003 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 2FF1237B401 for ; Tue, 25 Mar 2003 17:15:57 -0800 (PST) Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by mx1.FreeBSD.org (Postfix) with ESMTP id BC8ED43F85 for ; Tue, 25 Mar 2003 17:15:56 -0800 (PST) (envelope-from fearow@attbi.com) Received: from god.woofcat.com (12-251-110-17.client.attbi.com[12.251.110.17]) by rwcrmhc52.attbi.com (rwcrmhc52) with SMTP id <2003032601155605200j5mp9e>; Wed, 26 Mar 2003 01:15:56 +0000 Date: Tue, 25 Mar 2003 19:15:25 -0600 From: Anti To: omestre Cc: freebsd-hackers@freebsd.org Subject: Re: pam_ldap + nss_ldap Message-Id: <20030325191525.49aa6c62.fearow@attbi.com> In-Reply-To: References: Organization: Woofcat X-Mailer: Sylpheed version 0.8.10 (GTK+ 1.2.10; i386-portbld-freebsd5.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-25.7 required=5.0 tests=AWL,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,RCVD_IN_UNCONFIRMED_DSBL,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 25 Mar 2003 19:19:48 +0000 (UTC) omestre wrote: > > Hello, > sorry, but i need to know where can i find a how to for > FreeBSD 5.0 working with pam_ldap authentication. > There is pam_ldap in ports/security, but and support in > the libc? i did put one /etc/pam.d/sshd file and tcpdump my > ssh connection... the module is talking with the ldap server, > but i have not nss (ldap) module in the Operating System. > how can i make it works? I have thought that Free 5.0 should > work with LDAP by default... :( > Thanks very much! > omestre@sdf.lonestar.org > SDF Public Access UNIX System - http://sdf.lonestar.org nss_ldap doesn't work with freebsd... pam_ldap works fine though... most of the features of nss_ldap can be achieved using an nis/ldap gateway... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 26 00:55: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 E40DB37B405 for ; Wed, 26 Mar 2003 00:55:25 -0800 (PST) Received: from puffin.mail.pas.earthlink.net (puffin.mail.pas.earthlink.net [207.217.120.139]) by mx1.FreeBSD.org (Postfix) with ESMTP id 68BB443FBD for ; Wed, 26 Mar 2003 00:55:25 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from pool0122.cvx21-bradley.dialup.earthlink.net ([209.179.192.122] helo=mindspring.com) by puffin.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 18y6gs-00078F-00; Wed, 26 Mar 2003 00:55:22 -0800 Message-ID: <3E816AA7.1B6A02C@mindspring.com> Date: Wed, 26 Mar 2003 00:53:59 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: alex@dynaweb.ru References: <3E815D53.6010404@dynaweb.ru> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4ed3e4f265b2a4d256a336581b8e6cc063ca473d225a0f487350badd9bab72f9c350badd9bab72f9c X-Spam-Status: No, hits=-15.0 required=5.0 tests=AWL,QUOTED_EMAIL_TEXT,RCVD_IN_OSIRUSOFT_COM, RCVD_IN_UNCONFIRMED_DSBL,REFERENCES autolearn=ham version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) cc: FreeBSD hackers list Subject: Re: Some specific questions about 5.x 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, 26 Mar 2003 08:55:26 -0000 Alex wrote: > I was so much enthusiastic about kernel threads implemented in 5.x but > some ugly rumors spoiled my dreams :0) > So I want to get if these rumors are myths or not. 5.x does not implement traditional "kernel threads" like you appear to be thinking about them. Instead, it implements a variation of scheduler activations. Traditional "kernel threads" have a lot of unnecessary overhead problems, including CPU affinity and thread group negaffinity, necessary for increased single application concurrency. See the KSE documentation for more information. > 1. Is it true that kernel threads are more "heavy" than userspace > ones (pthread) and hence application with hundreds of threads will work > evidently slower than that using pthreads due to more switching penalties? Yes and No. See the KSE documentation for more information. > 2. Is it true that even 5.x has no implementation for inter-process > semaphores that are blocking calling thread only not the whole process > as usually in FreeBSD? No, for values of x > 0. See the KSE documentation for more information. -- Terry From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 25 17:36: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 0EAB537B412; Tue, 25 Mar 2003 17:36:11 -0800 (PST) Received: from scl8owa02.int.exodus.net (scl8out02.exodus.net [66.35.230.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4F1CB4404B; Tue, 25 Mar 2003 17:29:04 -0800 (PST) (envelope-from Maksim.Yevmenkin@cw.com) Received: from scl8owa01.int.exodus.net ([66.35.230.241]) by scl8owa02.int.exodus.net with Microsoft SMTPSVC(5.0.2195.5329); Tue, 25 Mar 2003 17:28:58 -0800 Received: from exodus.net ([165.193.27.35]) by scl8owa01.int.exodus.net over TLS secured channel with Microsoft SMTPSVC(5.0.2195.5329); Tue, 25 Mar 2003 17:28:58 -0800 Message-ID: <3E81018F.70805@exodus.net> Date: Tue, 25 Mar 2003 17:25:35 -0800 From: Maksim Yevmenkin User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021126 X-Accept-Language: ru, en-us, en MIME-Version: 1.0 To: Brian Somers References: <45258A4365C6B24A9832BFE224837D552B1283@sjdcex01.int.exodus.net> <3E3ED4DF.7090904@exodus.net> <3E3EDE11.192ABC3F@mindspring.com> <3E3EF111.5050401@exodus.net> <20030326011226.051dbae9.brian@Awfulhak.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Mar 2003 01:28:58.0398 (UTC) FILETIME=[12CD23E0:01C2F337] X-Spam-Status: No, hits=-15.6 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,USER_AGENT_MOZILLA_UA autolearn=ham version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) cc: hackers@FreeBSD.ORG cc: brian@FreeBSD.ORG cc: questions@FreeBSD.ORG Subject: Re: [PATCH2] PPP in -direct mode does not execute any chat scripts 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, 26 Mar 2003 01:36:23 -0000 X-List-Received-Date: Wed, 26 Mar 2003 01:36:23 -0000 Hello Brian, > Yes, this looks fine, although I think this shows that the -direct > description is wrong. Perhaps this is more appropriate: > > -direct > This is used for communicating over an already established connection, > usually when receiving incoming connections accepted by getty(8). ppp > ignores the ``set device'' line and uses descriptor 0 as the link. ppp > will ignore any configured chat scripts unless the ``force-scripts'' > option has been enabled. > > If callback.... > > Do you agree with this description ? If so, I'll go ahead and commit the yes, this is more accurate description. i missed it. > changes. Just to be picky, I'll re-sort the OPT_ variables too :*P no problem :) > And thanks for the patches. thank you for reviewing them :) max > On Mon, 03 Feb 2003 14:45:37 -0800, Maksim Yevmenkin wrote: > >>Dear Brian and Hackers, >> >>Please find updated proposed version of the patch. As suggested by >>Warner option has been renamed to 'force-sripts' and now works for >>both 'direct' and 'dedicated' modes. Also as suggested by Terry the >>man page has been updated to document side effect of 'direct'. >> >>-direct >> This is used for receiving incoming connections. ppp ignores the >> ``set device'' line and uses descriptor 0 as the link. ppp will >> never use any configured chat scripts unless ``force-scripts'' >> option has been enabled. >> >> If callback is configured, ppp will use the ``set device'' infor- >> mation when dialing back. >> >>-dedicated >> This option is designed for machines connected with a dedicated >> wire. ppp will always keep the device open and will never use >> any configured chat scripts unless ``force-scripts'' option has >> been enabled. >> >>force-scripts >> Default: Disabled. Forces execution of the configured chat >> scripts in direct and dedicated modes. >> >> >>>>Please find attached patch that adds new option to the PPP. >>>> >>>>run-scripts-in-direct-mode >>>> Default: Disabled. This allows to run chat scripts in >>>> direct mode. >>>> >>>>did i miss anything? objections? comments? reviews? >>> >>> >>>First comment: run it past Brian Somers ; it's >>>his baby, and he's the active maintainer. >> >>I have sent him e-mail. >> >> >>>Rest of comments: >>> >>>Actually, why doesn't "-direct" allow a chat script by default? >>>The man page doesn't document that as a side-effect of "-direct", >>>only of "-dedicated", but it's been there since the import. >>> >>>Should this really be a "negotiate" section command, rather than >>>just a command or a "set" command? >>> >>>Also, there are only two other commands even have a "-" in them, >>>and both of them only have one (just seems a little long, compared >>>to, say, "rsid" or "direct-with-script", or even "force-script"). >>> >>>Personal preference: don't make it conditional on "-direct", let >>>it also work with "-dedicated", and call it "force-script" or >>>something, instead. >> >>done >> >> >>>The man page should be updated -- including the undocumented >>>side-effect of "-direct" disabling scripts). >> >>done >> >>thanks >>max >> > > > From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 25 17:54: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 AEE3537B405 for ; Tue, 25 Mar 2003 17:54:29 -0800 (PST) Received: from office.advantagecom.net (office.advantagecom.net [207.109.186.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id E3BA943FAF for ; Tue, 25 Mar 2003 17:54:27 -0800 (PST) (envelope-from andykinney@advantagecom.net) Received: from SCSI-MONSTER (andy.advantagecom.net [207.109.186.200] (may be forged)) by office.advantagecom.net (8.9.3/8.9.3) with ESMTP id RAA22108; Tue, 25 Mar 2003 17:54:22 -0800 From: "Andrew Kinney" Organization: Advantagecom Networks, Inc. To: Igor Sysoev Date: Tue, 25 Mar 2003 17:54:28 -0800 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Message-ID: <3E8097D4.22759.A3FC35@localhost> Priority: normal References: <3E7F0F65.7994.11617945@localhost> In-reply-to: X-mailer: Pegasus Mail for Win32 (v3.12c) X-Spam-Status: No, hits=-26.7 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) cc: freebsd-hackers@FreeBSD.ORG Subject: Re: shared mem and panics when out of PV Entries X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: andykinney@advantagecom.net List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2003 01:54:31 -0000 X-List-Received-Date: Wed, 26 Mar 2003 01:54:31 -0000 On 25 Mar 2003, at 17:56, Igor Sysoev wrote: > > So, what's the best approach to limiting memory shared via fork() or > > reducing PV Entry usage by that memory? Is there something I can do > > with the kernel config or sysctl to accomplish this? > > No, as far as I know there's no way to do it. > The irony is that you do not need the most of these PV entries because > you are not swaping. > My thoughts exactly. I suppose not all that many people run well used web servers with 4GB of RAM, so there wouldn't be any reason for this issue to come up on a regular basis. I'm going to expose my newbness here with respect to BSD memory management, but could the number of files served and filesystem caching have something to do with the PV Entry usage by Apache? We've got around 1.2 million files served by this Apache. Could it be that the extensive PV Entry usage has something to do with that? Obviously, not all are accessed all the time, but it wouldn't take a very large percentage of them being accessed to cause issues if filesystem caching is in any way related to PV Entry usage by Apache. I remember reading somewhere (sorry, didn't keep track of the link) that someone running a heavily used Squid proxy had a very similar issue with running out of PV Entries as they got more and more files in the cache. Squid is basically a modified Apache with proxy caching turned on. > I think you should try to decrease memory that shared between Apache > processes. If you can not change scripts then the single method is to > decrease number of Apache processes while keeping to handle the > current workload: 1) disable keepalive if it enabled; 2) set Apache > behind reverse-proxy server that frees Apache processes > as soon as proxy get the whole responses. We had keepalive set to the default of "on" (at least default for this install) with the default keepalive timeout of 15 seconds. Dropping the keepalive timeout down to 3 seconds has dramatically reduced the number of Apache processes required to serve the load. With the new settings, we're averaging 30 to 80 Apache processes, which is much more manageable in terms of memory usage, though we weren't anywhere near running out of physical RAM prior to this. We're servicing a little over 1000 requests per minute, which by some standards isn't a huge amount. We're still seeing quite heavy PV Entry usage, though. The reduced number of Apache processes (by more than half) doesn't seem to have appreciably reduced PV Entry usage versus the previous settings, so I suspect I may have been wrong about memory sharing as the culprit for the PV Entry usage. This observation may just be coincidence, but the average PV Entry usage seems to have gone up by a couple million entries since the changes to the Apache config. Time will tell if the PV Entries are still getting hit hard enough to cause panics due to running out of them. They're supposed to get forcibly recycled at 90% utilization from what I see in the kernel code, so if we never get above 90% utilization I guess I could consider the issue resolved. What other things in Apache (besides memory sharing via PHP and/or mod_perl) could generate PV Entry usage on a massive scale? Sincerely, Andrew Kinney President and Chief Technology Officer Advantagecom Networks, Inc. http://www.advantagecom.net From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 25 19:29:59 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 30C8837B401 for ; Tue, 25 Mar 2003 19:29:59 -0800 (PST) Received: from bluejay.mail.pas.earthlink.net (bluejay.mail.pas.earthlink.net [207.217.120.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id 63B0F43FA3 for ; Tue, 25 Mar 2003 19:29:58 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from pool0212.cvx21-bradley.dialup.earthlink.net ([209.179.192.212] helo=mindspring.com) by bluejay.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 18y1bq-0001qB-00; Tue, 25 Mar 2003 19:29:51 -0800 Message-ID: <3E811E52.198972EB@mindspring.com> Date: Tue, 25 Mar 2003 19:28:18 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: andykinney@advantagecom.net References: <3E7F0F65.7994.11617945@localhost> <3E8097D4.22759.A3FC35@localhost> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a43e3971fd4cf643b022f60a4173f74d3b350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Spam-Status: No, hits=-22.1 required=5.0 tests=AWL,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) cc: freebsd-hackers@FreeBSD.ORG Subject: Re: shared mem and panics when out of PV Entries 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, 26 Mar 2003 03:30:03 -0000 X-List-Received-Date: Wed, 26 Mar 2003 03:30:03 -0000 Andrew Kinney wrote: > On 25 Mar 2003, at 17:56, Igor Sysoev wrote: > > > So, what's the best approach to limiting memory shared via fork() or > > > reducing PV Entry usage by that memory? Is there something I can do > > > with the kernel config or sysctl to accomplish this? > > > > No, as far as I know there's no way to do it. > > The irony is that you do not need the most of these PV entries because > > you are not swaping. > > My thoughts exactly. I suppose not all that many people run well > used web servers with 4GB of RAM, so there wouldn't be any > reason for this issue to come up on a regular basis. You need the pv_entry_t's because there is one on each vm_page_t for each virtual mapping for the page. This is necessary to correctly mark things clean or dirty, and to deal with copy-on-write. What is *actually* ironic is that, for the most part, these things *may* be able to be shared, if they were made slightly more complex and reference counted, and you were willing to split some of the copy-on-write code a little bit further between machine-dependent and machine-independent. Matt Dillon would be the person to talk to about this; I could do it, but he'd do it faster. > I'm going to expose my newbness here with respect to BSD > memory management, but could the number of files served and > filesystem caching have something to do with the PV Entry usage > by Apache? We've got around 1.2 million files served by this > Apache. Could it be that the extensive PV Entry usage has > something to do with that? Obviously, not all are accessed all the > time, but it wouldn't take a very large percentage of them being > accessed to cause issues if filesystem caching is in any way > related to PV Entry usage by Apache. When you fork, you copy the address space, which means you copy the pv_entry_t's, so the answer is a tentative "yes". But files which are not open are not mapped, so unless you have a lot of mmap's hanging around, this shouldn't be an issue with System V shared memory. > We had keepalive set to the default of "on" (at least default for this > install) with the default keepalive timeout of 15 seconds. > > Dropping the keepalive timeout down to 3 seconds has > dramatically reduced the number of Apache processes required to > serve the load. With the new settings, we're averaging 30 to 80 > Apache processes, which is much more manageable in terms of > memory usage, though we weren't anywhere near running out of > physical RAM prior to this. We're servicing a little over 1000 > requests per minute, which by some standards isn't a huge amount. > > We're still seeing quite heavy PV Entry usage, though. The > reduced number of Apache processes (by more than half) doesn't > seem to have appreciably reduced PV Entry usage versus the > previous settings, so I suspect I may have been wrong about > memory sharing as the culprit for the PV Entry usage. This > observation may just be coincidence, but the average PV Entry > usage seems to have gone up by a couple million entries since the > changes to the Apache config. > > Time will tell if the PV Entries are still getting hit hard enough to > cause panics due to running out of them. They're supposed to get > forcibly recycled at 90% utilization from what I see in the kernel > code, so if we never get above 90% utilization I guess I could > consider the issue resolved. > > What other things in Apache (besides memory sharing via PHP > and/or mod_perl) could generate PV Entry usage on a massive > scale? Basically, you don't really care about pv_entry_t's, you care about KVA space, and running out of it. In a previous posting, you suggested increasing KVA_PAGES fixed the problem, but caused a pthreads problem. What you meant to say is that it caused a Linux threads kernel module mailbox location problem for the user space Linux threads library. In other words, it's because you are using the Linux threads implementation, that you have this problem, not FreeBSD's pthreads. Probably, the Linux threads kernel module should be modified to provide the mailbox location, and then the user space Linux threads library should be modified to utilize sysctl to talk to the kernel module, and establish the locations, so that they don't have to be agreed upon at compile time for programs using the code. In any case, the problem you are having is because the uma_zalloc() (UMA) allocator is feeling KVA space pressure. One way to move this pressure somewhere else, rather than dealing with it in an area which results in a panic on you because the code was not properly retrofit for the limitations of UMA, is to decide to preallocate the UMA region used for the "PV ENTRY" zone. The way to do this is to modify /usr/src/sys/i386/i386/pmap.c at about line 122, where it says: #define MINPV 2048 to say instead: #ifndef MINPV #define MINPV 2048 /* default, if not specified in config */ #endif And to realize that there is an "opt_pmap.h". To activate this, you will need to add this line to /usr/src/sys/conf/options.i386: MINPV opt_pmap.h With this in place, you will be able to adjust the initial minimum allocations upward by saying: options MINPV=4096 (or whatever) in your kernel config file. Note: you may want to "#if 0" out the #define in pmap.c altogether, to reassure yourself that this is working; it's easy to make a mistake in this part of the kernel. -- Terry From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 25 23:55: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 AFD9B37B404 for ; Tue, 25 Mar 2003 23:55:01 -0800 (PST) Received: from undead.dnn.ru (dnn.ru [212.158.164.253]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3CA2243FA3 for ; Tue, 25 Mar 2003 23:55:00 -0800 (PST) (envelope-from alex@dynaweb.ru) Received: from dynaweb.ru (dynaweb.dnn.ru [212.158.164.112]) by undead.dnn.ru (8.9.3/8.9.3) with ESMTP id KAA52543 for ; Wed, 26 Mar 2003 10:57:21 +0300 (MSK) (envelope-from alex@dynaweb.ru) Message-ID: <3E815D53.6010404@dynaweb.ru> Date: Wed, 26 Mar 2003 10:57:07 +0300 From: Alex User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: FreeBSD hackers list Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-5.8 required=5.0 tests=USER_AGENT_MOZILLA_UA autolearn=ham version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Subject: Some specific questions about 5.x X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: alex@dynaweb.ru List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2003 07:55:02 -0000 X-List-Received-Date: Wed, 26 Mar 2003 07:55:02 -0000 Hi everybody! I was so much enthusiastic about kernel threads implemented in 5.x but some ugly rumors spoiled my dreams :0) So I want to get if these rumors are myths or not. 1. Is it true that kernel threads are more "heavy" than userspace ones (pthread) and hence application with hundreds of threads will work evidently slower than that using pthreads due to more switching penalties? 2. Is it true that even 5.x has no implementation for inter-process semaphores that are blocking calling thread only not the whole process as usually in FreeBSD? Alex From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 26 00:18: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 330C737B404 for ; Wed, 26 Mar 2003 00:18:26 -0800 (PST) Received: from energyhq.homeip.net (213-97-200-73.uc.nombres.ttd.es [213.97.200.73]) by mx1.FreeBSD.org (Postfix) with ESMTP id 92C0B43FBD for ; Wed, 26 Mar 2003 00:18:24 -0800 (PST) (envelope-from flynn@energyhq.homeip.net) Received: from christine.energyhq.tk (christine.energyhq.tk [192.168.100.1]) by energyhq.homeip.net (Postfix) with SMTP id 68515AF584; Wed, 26 Mar 2003 09:18:23 +0100 (CET) Date: Wed, 26 Mar 2003 09:18:45 +0100 From: Miguel Mendez To: alex@dynaweb.ru Message-Id: <20030326091845.36425fad.flynn@energyhq.homeip.net> In-Reply-To: <3E815D53.6010404@dynaweb.ru> References: <3E815D53.6010404@dynaweb.ru> X-Mailer: Sylpheed version 0.8.11claws (GTK+ 1.2.10; i386--netbsdelf) 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 Subject: Re: Some specific questions about 5.x 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, 26 Mar 2003 08:18:27 -0000 X-List-Received-Date: Wed, 26 Mar 2003 08:18:27 -0000 --=.N0y:iHrl5Oj6r3 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Wed, 26 Mar 2003 10:57:07 +0300 Alex wrote: Howdy. > 1. Is it true that kernel threads are more "heavy" than userspace > ones (pthread) and hence application with hundreds of threads will > work evidently slower than that using pthreads due to more switching > penalties? AFAIK, not in a hybrid model. Systems that do 1:1 thread mapping (Like Gah! Nu/Linux) will suffer from this kind of situation, also will use more kernel memory. In hybrid implementations based on Scheduler Activations, like FreeBSD's KSE, and NetBSD's SA, there's a balance between the number of kernel virtual processors available and the number of userland threads, it's an N:M model. Nathan Williams' paper on the subject suggests that context switch is not much slower than a pure userland implementation. Also, keep in mind that pure userland has other problems, like when one thread blocks on I/O. In pure userland threading systems this means the whole process is blocked, whereas in KSE and SA only that thread is stopped. > 2. Is it true that even 5.x has no implementation for inter-process > semaphores that are blocking calling thread only not the whole process > as usually in FreeBSD? That I don't know, perhaps the local KSE guru, Julian might have an answer for this. Cheers, -- Miguel Mendez - flynn@energyhq.homeip.net GPG Public Key :: http://energyhq.homeip.net/files/pubkey.txt EnergyHQ :: http://www.energyhq.tk Tired of Spam? -> http://www.trustic.com --=.N0y:iHrl5Oj6r3 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (NetBSD) iD8DBQE+gWJpnLctrNyFFPERAjBRAJ9XdUgcfg8DMVqRVKq3cposKYuMqQCgrNhC XfQS2H+jgl9hNTe2vtJp1go= =4k59 -----END PGP SIGNATURE----- --=.N0y:iHrl5Oj6r3-- From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 26 01:35: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 6176D37B405 for ; Wed, 26 Mar 2003 01:35:18 -0800 (PST) Received: from smtp.netli.com (ip2-pal-focal.netli.com [66.243.52.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id A2AC543FAF for ; Wed, 26 Mar 2003 01:35:17 -0800 (PST) (envelope-from vlm@netli.com) Received: (qmail 17826 invoked by uid 84); 26 Mar 2003 09:35:17 -0000 Received: from vlm@netli.com by l3-1 with qmail-scanner-0.96 (uvscan: v4.1.40/v4121. . Clean. Processed in 0.127617 secs); 26 Mar 2003 09:35:17 -0000 Received: from unknown (HELO netli.com) (172.17.1.38) by mx01-pal-lan.netli.lan with SMTP; 26 Mar 2003 09:35:17 -0000 Message-ID: <3E817469.4030403@netli.com> Date: Wed, 26 Mar 2003 01:35:37 -0800 From: Lev Walkin Organization: Netli, Inc. User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.2.1) Gecko/20030125 X-Accept-Language: ru, en-us, en MIME-Version: 1.0 To: Miguel Mendez References: <3E815D53.6010404@dynaweb.ru> <20030326091845.36425fad.flynn@energyhq.homeip.net> In-Reply-To: <20030326091845.36425fad.flynn@energyhq.homeip.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-31.9 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA autolearn=ham version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) cc: FreeBSD hackers list Subject: Re: Some specific questions about 5.x 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, 26 Mar 2003 09:35:21 -0000 Miguel Mendez wrote: > On Wed, 26 Mar 2003 10:57:07 +0300 > Alex wrote: > > Howdy. > > >>1. Is it true that kernel threads are more "heavy" than userspace >>ones (pthread) and hence application with hundreds of threads will >>work evidently slower than that using pthreads due to more switching >>penalties? > > > AFAIK, not in a hybrid model. Systems that do 1:1 thread mapping (Like > Gah! Nu/Linux) will suffer from this kind of situation, also will use > more kernel memory. In hybrid implementations based on Scheduler > Activations, like FreeBSD's KSE, and NetBSD's SA, there's a balance > between the number of kernel virtual processors available and the number > of userland threads, it's an N:M model. Nathan Williams' paper on the > subject suggests that context switch is not much slower than a pure > userland implementation. Also, keep in mind that pure userland has other > problems, like when one thread blocks on I/O. In pure userland threading > systems this means the whole process is blocked, whereas in KSE and SA > only that thread is stopped. What about Solaris' migration towards 1:1 model from the N:M one they had supported for years already? Who are insane, Solaris folks (moving towards Linux) or Free/NetBSD ones (migrating to the old Solaris' behavior)? -- Lev Walkin vlm@netli.com From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 26 01:38: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 CACE237B404 for ; Wed, 26 Mar 2003 01:38:08 -0800 (PST) Received: from smtp.netli.com (ip2-pal-focal.netli.com [66.243.52.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3A5CC43F3F for ; Wed, 26 Mar 2003 01:38:08 -0800 (PST) (envelope-from vlm@netli.com) Received: (qmail 17789 invoked by uid 84); 26 Mar 2003 09:31:27 -0000 Received: from vlm@netli.com by l3-1 with qmail-scanner-0.96 (uvscan: v4.1.40/v4121. . Clean. Processed in 0.122759 secs); 26 Mar 2003 09:31:27 -0000 Received: from unknown (HELO netli.com) (172.17.1.38) by mx01-pal-lan.netli.lan with SMTP; 26 Mar 2003 09:31:27 -0000 Message-ID: <3E817383.6010405@netli.com> Date: Wed, 26 Mar 2003 01:31:47 -0800 From: Lev Walkin Organization: Netli, Inc. User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.2.1) Gecko/20030125 X-Accept-Language: ru, en-us, en MIME-Version: 1.0 To: vys@renet.ru References: <3585.195.161.130.250.1048598218.squirrel@mail.renet.ru> In-Reply-To: <3585.195.161.130.250.1048598218.squirrel@mail.renet.ru> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-31.9 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA autolearn=ham version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) cc: freebsd-hackers@freebsd.org Subject: Re: Question about BPF API (PCAP not like for me) 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, 26 Mar 2003 09:38:13 -0000 Vladimir Yu. Stepanov wrote: > Hello ! > > I have a little question about BPF: how to determine incoming or outgoing > packet given into the user level mode. Current API do not supported this > or I are wrong ? Unfortunately, there is no way of determining this fact. However, there is a flag names BIOCSSEESENT that enables you to skip over locally generated packets on the interface in question. See ports/net/ipcad. -- Lev Walkin vlm@netli.com From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 26 01:42: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 D107D37B404 for ; Wed, 26 Mar 2003 01:42:05 -0800 (PST) Received: from energyhq.homeip.net (213-97-200-73.uc.nombres.ttd.es [213.97.200.73]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6857043FA3 for ; Wed, 26 Mar 2003 01:42:04 -0800 (PST) (envelope-from flynn@energyhq.homeip.net) Received: from christine.energyhq.tk (christine.energyhq.tk [192.168.100.1]) by energyhq.homeip.net (Postfix) with SMTP id 64F03AF584; Wed, 26 Mar 2003 10:42:03 +0100 (CET) Date: Wed, 26 Mar 2003 10:42:26 +0100 From: Miguel Mendez To: Lev Walkin Message-Id: <20030326104226.3ff7686b.flynn@energyhq.homeip.net> In-Reply-To: <3E817469.4030403@netli.com> References: <3E815D53.6010404@dynaweb.ru> <20030326091845.36425fad.flynn@energyhq.homeip.net> <3E817469.4030403@netli.com> X-Mailer: Sylpheed version 0.8.11claws (GTK+ 1.2.10; i386--netbsdelf) 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 Subject: Re: Some specific questions about 5.x 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, 26 Mar 2003 09:42:08 -0000 --=.GA?d2FPKTHzZtJ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Wed, 26 Mar 2003 01:35:37 -0800 Lev Walkin wrote: Hi, > What about Solaris' migration towards 1:1 model from the N:M one they > had supported for years already? Who are insane, Solaris folks (moving > towards Linux) or Free/NetBSD ones (migrating to the old Solaris' > behavior)? I haven't done Solaris development for a while, but iirc, Sun's statement on the matter is that developers have to consider which paradigm fits their application best. Solaris supports both schemes, 1:1 and N:M. Certain applications benefit from the former, other from the latter. I don't they're going to drop N:M anytime soon. I think the reason why Linux does 1:1 is that it started as a hack of the process creation code. Implementing a real N:M system is more complicated. Perhaps it should be interesting to study in which cases a 1:1 threading system is better. Cheers, -- Miguel Mendez - flynn@energyhq.homeip.net GPG Public Key :: http://energyhq.homeip.net/files/pubkey.txt EnergyHQ :: http://www.energyhq.tk Tired of Spam? -> http://www.trustic.com --=.GA?d2FPKTHzZtJ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (NetBSD) iD8DBQE+gXYGnLctrNyFFPERAq1eAJ9/94Zpqk+27E8MW48LZ95aC09LjwCfeiIL NITdCz6U2FaBAgpT31OvAw0= =MLBo -----END PGP SIGNATURE----- --=.GA?d2FPKTHzZtJ-- From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 26 01:54: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 2888337B404; Wed, 26 Mar 2003 01:54:18 -0800 (PST) Received: from hotmail.com (bay2-dav22.bay2.hotmail.com [65.54.246.79]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9D97943FBD; Wed, 26 Mar 2003 01:54:17 -0800 (PST) (envelope-from sukhbinders@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 26 Mar 2003 01:54:17 -0800 Received: from 219.93.221.38 by bay2-dav22.bay2.hotmail.com with DAV; Wed, 26 Mar 2003 09:54:17 +0000 X-Originating-IP: [219.93.221.38] X-Originating-Email: [sukhbinders@hotmail.com] From: "Sukhbinder Singh" To: , Date: Wed, 26 Mar 2003 17:53:04 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Message-ID: X-OriginalArrivalTime: 26 Mar 2003 09:54:17.0517 (UTC) FILETIME=[AA678DD0:01C2F37D] X-Spam-Status: No, hits=0.9 required=5.0 tests=HTML_30_40,HTML_MESSAGE version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.1 cc: Sukhbinder Singh Subject: FreeBSD Installation Problems 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, 26 Mar 2003 09:54:19 -0000 Hello, I am trying to install FreeBSD into my personal computer, = however I am receiving error messages during the course of my = installation. When I am trying to install using the floppy method at the = final prompt where the istallation program requests me to put in floppy = disk in drive a and press enter. After putting in the disk and pressing = enter I receive a warning or error message like "Error mounting floppy = fd0 (/dev/fd0) on /dist: Invalid argument".=20 When I try to install it via FTP, at the end of the = installation procedure I receive a message like "Couldn't open FTP = connection to ftp.freebsd.org: undefined error : 0" Can someone please = help me troubleshoot this problems which I had been facing with the = installation of FreeBSD into my personal computer. Thanks, =20 =20 From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 26 02:29: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 ACC7837B404 for ; Wed, 26 Mar 2003 02:29:47 -0800 (PST) Received: from park.rambler.ru (park.rambler.ru [81.19.64.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id C094E43FA3 for ; Wed, 26 Mar 2003 02:29:46 -0800 (PST) (envelope-from is@rambler-co.ru) Received: from is.park.rambler.ru (is.park.rambler.ru [81.19.64.102]) by park.rambler.ru (8.12.6/8.12.6) with ESMTP id h2QATgmF058030; Wed, 26 Mar 2003 13:29:42 +0300 (MSK) Date: Wed, 26 Mar 2003 13:29:42 +0300 (MSK) From: Igor Sysoev X-Sender: is@is To: Andrew Kinney In-Reply-To: <3E8097D4.22759.A3FC35@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-25.6 required=5.0 tests=AWL,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) cc: freebsd-hackers@FreeBSD.ORG Subject: Re: shared mem and panics when out of PV Entries 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, 26 Mar 2003 10:29:49 -0000 On Tue, 25 Mar 2003, Andrew Kinney wrote: > I'm going to expose my newbness here with respect to BSD > memory management, but could the number of files served and > filesystem caching have something to do with the PV Entry usage > by Apache? We've got around 1.2 million files served by this > Apache. Could it be that the extensive PV Entry usage has > something to do with that? Obviously, not all are accessed all the > time, but it wouldn't take a very large percentage of them being > accessed to cause issues if filesystem caching is in any way > related to PV Entry usage by Apache. I think the most of these PV entries related to forked Apaches. As far as I know PV entries used for files only if these files are mmap()ed. > I remember reading somewhere (sorry, didn't keep track of the link) > that someone running a heavily used Squid proxy had a very > similar issue with running out of PV Entries as they got more and > more files in the cache. Squid is basically a modified Apache with > proxy caching turned on. No, Squid is not modified Apache. It's completely different animal. Apache uses preforked model while Squid uses select()/poll() in the single process. > > I think you should try to decrease memory that shared between Apache > > processes. If you can not change scripts then the single method is to > > decrease number of Apache processes while keeping to handle the > > current workload: 1) disable keepalive if it enabled; 2) set Apache > > behind reverse-proxy server that frees Apache processes > > as soon as proxy get the whole responses. > > We had keepalive set to the default of "on" (at least default for this > install) with the default keepalive timeout of 15 seconds. > > Dropping the keepalive timeout down to 3 seconds has > dramatically reduced the number of Apache processes required to > serve the load. With the new settings, we're averaging 30 to 80 > Apache processes, which is much more manageable in terms of > memory usage, though we weren't anywhere near running out of > physical RAM prior to this. We're servicing a little over 1000 > requests per minute, which by some standards isn't a huge amount. I strongly recommend to disable keepalive at all. Keepalive mostly make a sense only to download HTML with the inline images. With heavy mod_perl server it's simply waste of the resources - megabytes of a physical memory (usually) or PV entries (in your rare case). Furthermore heavy Apache processes should not handle images or another static files. Heavy Apache should generate dynamic responses only and should be set behind reverse-proxy (though not mod_proxy). Let's see a modem user that gets 50K response. FreeBSD 4.4+ default in-kernel TCP send buffer is 32K and Apache would quickly fill it and need to wait for the freeing space for the rest 18K. A modem user gets 18K for 6 seconds at 3K/s. So while mod_perl can generate answer in 0.1 seconds it needs to wait 6 seconds for transfer this answer. All your megabytes and PV entries are bound to this transer. But this long transfer can be made by reverse-proxy that gets response from heavy server in 0.1 seconds or so. Furthermore if responses is small enough to fill completely in in-kernel TCP buffer there is Apache lingering close 2-second timeout. Before closing the connection Apache calls shutdown(SHUT_WR) and then calls select() with 2 seconds timeout. Slow client would not close the connection on its side because it's still getting response so Apache waits these 2 seconds and then close() the connection. So you spend at least 2 seconds for a slow client even your server can generate responses in a fraction of a second. > We're still seeing quite heavy PV Entry usage, though. The > reduced number of Apache processes (by more than half) doesn't > seem to have appreciably reduced PV Entry usage versus the > previous settings, so I suspect I may have been wrong about > memory sharing as the culprit for the PV Entry usage. This > observation may just be coincidence, but the average PV Entry > usage seems to have gone up by a couple million entries since the > changes to the Apache config. If you have 200M shared memory it takes about 50,000 PV entries per process. 20 processes takes 1 million PV entries. > Time will tell if the PV Entries are still getting hit hard enough to > cause panics due to running out of them. They're supposed to get > forcibly recycled at 90% utilization from what I see in the kernel > code, so if we never get above 90% utilization I guess I could > consider the issue resolved. > > What other things in Apache (besides memory sharing via PHP > and/or mod_perl) could generate PV Entry usage on a massive > scale? The file mmap()s. But they should not descreased because they alwayes shared as compared with copy-on-write fork()ed pages. Igor Sysoev http://sysoev.ru/en/ From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 26 02:30: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 6A2F437B404 for ; Wed, 26 Mar 2003 02:30:12 -0800 (PST) Received: from stork.mail.pas.earthlink.net (stork.mail.pas.earthlink.net [207.217.120.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id C734543FAF for ; Wed, 26 Mar 2003 02:30:11 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from pool0122.cvx21-bradley.dialup.earthlink.net ([209.179.192.122] helo=mindspring.com) by stork.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 18y8AZ-00003X-00; Wed, 26 Mar 2003 02:30:07 -0800 Message-ID: <3E8180C6.A2C6E266@mindspring.com> Date: Wed, 26 Mar 2003 02:28:22 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Lev Walkin References: <3E815D53.6010404@dynaweb.ru><3E817469.4030403@netli.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4957892169a87bb5ed3bdadad081663a1350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Spam-Status: No, hits=-21.5 required=5.0 tests=AWL,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) cc: FreeBSD hackers list Subject: Re: Some specific questions about 5.x 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, 26 Mar 2003 10:30:13 -0000 Lev Walkin wrote: > What about Solaris' migration towards 1:1 model from the N:M one they > had supported for years already? Who are insane, Solaris folks (moving > towards Linux) or Free/NetBSD ones (migrating to the old Solaris' > behavior)? It's not the same N:M model as Solaris. The Solaris model derives from work done in 1993/1994, jointly, by USL and Sun Micrososystems, on the SVR4.2 release code. That's why the UnixWare and Solaris models are so similar, up until the last few years, when the Solaris model changed. FWIW, I think the Solaris model changed in order to better support NUMA, without needing extensive scheduler changes, not because it really has no bugs now. 8-). -- Terry From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 26 04:44: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 B145D37B404 for ; Wed, 26 Mar 2003 04:44:27 -0800 (PST) Received: from honolulu.procergs.com.br (honolulu.procergs.com.br [200.198.128.103]) by mx1.FreeBSD.org (Postfix) with ESMTP id F19C343FA3 for ; Wed, 26 Mar 2003 04:44:23 -0800 (PST) (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 4CC3CAE06 for ; Wed, 26 Mar 2003 09:44:21 -0300 (BRT) Received: by ws-tor-0004.procergs (Postfix, from userid 1000) id 388DE10160; Wed, 26 Mar 2003 09:44:20 -0300 (BRT) Received: from procergs.rs.gov.br (localhost [127.0.0.1]) by ws-tor-0004.procergs (Postfix) with ESMTP id 188D110068 for ; Wed, 26 Mar 2003 09:44:20 -0300 (BRT) From: omestre@freeshell.org To: freebsd-hackers@freebsd.org Date: Wed, 26 Mar 2003 09:44:14 -0300 Sender: marcelo-leal@procergs.rs.gov.br Message-Id: <20030326124420.388DE10160@ws-tor-0004.procergs> X-Spam-Status: No, hits=0.7 required=5.0 tests=NO_REAL_NAME version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Subject: pam_ldap... 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, 26 Mar 2003 12:44:30 -0000 Thanks for the answers, but why pam_ldap in FreeBSD, if i can't authenticate in ldap servers? Sorry, but i can't understand... You did give me solutions with nis.. nis/gateway... where can i find a "official" howto? The FreeBSD team do not talk about it. The last question? Why FreeBSD do not support ldap authentication? (nss_ldap) files, nis, hesiod??? do we live in the past? One of great things in 5.0 release for me, should be this! :) Thanks again, and sorry by the english. --- From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 26 07:01: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 6879737B404 for ; Wed, 26 Mar 2003 07:01:53 -0800 (PST) Received: from gw.nectar.cc (gw.nectar.cc [208.42.49.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id C49C043F75 for ; Wed, 26 Mar 2003 07:01:52 -0800 (PST) (envelope-from nectar@celabo.org) Received: from madman.celabo.org (madman.celabo.org [10.0.1.111]) by gw.nectar.cc (Postfix) with ESMTP id 4B011A3; Wed, 26 Mar 2003 09:01:52 -0600 (CST) Received: by madman.celabo.org (Postfix, from userid 1001) id 3917B78C43; Wed, 26 Mar 2003 09:01:52 -0600 (CST) Date: Wed, 26 Mar 2003 09:01:52 -0600 From: "Jacques A. Vidrine" To: omestre@freeshell.org Message-ID: <20030326150152.GG33671@madman.celabo.org> Mail-Followup-To: "Jacques A. Vidrine" , omestre@freeshell.org, freebsd-hackers@freebsd.org References: <20030326124420.388DE10160@ws-tor-0004.procergs> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030326124420.388DE10160@ws-tor-0004.procergs> X-Url: http://www.celabo.org/ User-Agent: Mutt/1.5.3i-ja.1 X-Spam-Status: No, hits=-32.0 required=5.0 tests=AWL,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT autolearn=ham version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) cc: freebsd-hackers@freebsd.org Subject: Re: pam_ldap... 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, 26 Mar 2003 15:01:56 -0000 On Wed, Mar 26, 2003 at 09:44:14AM -0300, omestre@freeshell.org wrote: > > Thanks for the answers, but why pam_ldap in FreeBSD, if i > can't authenticate in ldap servers? You _can_ authenticate. Pluggable _Authentication_ Modules (PAM). In the PAM model, authenticating is more or less just the act of confirming a username and password. > Sorry, but i can't understand... The part you are missing is that before you can authenticate, you must have account and authorization information. For UNIX services, this means that e.g. getpwnam() needs to find you. This is the job that NSS does. As you have noted, FreeBSD 5.0's NSS only does files, NIS, and Hesiod. One can mix and match ... users can be managed via NIS (using NSS), while authentication is handled by LDAP (using PAM), for example. i.e. PAM and NSS are two different, orthogonal systems, and any attempt to make assumptions on one based on the other will only result in confusion :-) > You did give me solutions with nis.. nis/gateway... where can > i find a "official" howto? The FreeBSD team do not talk about it. , perhaps. > The last question? > Why FreeBSD do not support ldap authentication? (nss_ldap) > files, nis, hesiod??? do we live in the past? One of great > things in 5.0 release for me, should be this! :) Wait for FreeBSD 5.1. > Thanks again, and sorry by the english. Your English is easily understood, don't be sorry. But maybe don't use so many multiple-punctuation marks, such as ??? !!! It comes across rudely and I don't think that is what you wished. Cheers, -- Jacques A. Vidrine http://www.celabo.org/ NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos jvidrine@verio.net . nectar@FreeBSD.org . nectar@kth.se From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 26 08:02: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 3385137B404 for ; Wed, 26 Mar 2003 08:02:06 -0800 (PST) Received: from office.advantagecom.net (office.advantagecom.net [207.109.186.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4CC1A43F75 for ; Wed, 26 Mar 2003 08:02:05 -0800 (PST) (envelope-from andykinney@advantagecom.net) Received: from SCSI-MONSTER (andy.advantagecom.net [207.109.186.200] (may be forged)) by office.advantagecom.net (8.9.3/8.9.3) with ESMTP id IAA02631; Wed, 26 Mar 2003 08:01:58 -0800 From: "Andrew Kinney" Organization: Advantagecom Networks, Inc. To: Terry Lambert Date: Wed, 26 Mar 2003 08:02:08 -0800 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Message-ID: <3E815E80.18738.3AC0E20@localhost> Priority: normal In-reply-to: <3E811E52.198972EB@mindspring.com> X-mailer: Pegasus Mail for Win32 (v3.12c) X-Spam-Status: No, hits=-23.0 required=5.0 tests=AWL,EMAIL_ATTRIBUTION,IN_REP_TO,LARGE_COLLECTION, QUOTED_EMAIL_TEXT,REPLY_WITH_QUOTES autolearn=ham version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) cc: freebsd-hackers@FreeBSD.ORG Subject: Re: shared mem and panics when out of PV Entries X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: andykinney@advantagecom.net List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2003 16:02:08 -0000 On 25 Mar 2003, at 19:28, Terry Lambert wrote: > Basically, you don't really care about pv_entry_t's, you care > about KVA space, and running out of it. > > In a previous posting, you suggested increasing KVA_PAGES fixed > the problem, but caused a pthreads problem. Will running out of KVA space indirectly cause PV Entries to hit its limit as shown in sysctl vm.zone? To my knowledge, I've never seen a panic on this system directly resulting from running out of KVA space. They've all been traced back to running out of available PV Entries. I'm invariably hitting the panic in pmap_insert_entry() and I only get the panic when I run out of available PV Entries. I've seen nothing to indicate that running out of KVA space is causing the panics, though I'm still learning the ropes of the BSD memory management code and recognize that there are many interactions with different portions of the memory management code that could have unforeseen results. Regarding the other thread you mentioned, increasing KVA_PAGES was just a way to make it possible to squeeze a higher PV Entry limit out of the system because it would allow a higher value for PMAP_SHPGPERPROC while still allowing the system to boot. I have not determined if it "fixed the problem" because I had to revert to an old kernel when MySQL wigged out on boot, apparently due to the threading issue in 4.7 that shows up with increased KVA_PAGES. I never got a chance to increase PMAP_SHPGPERPROC after increasing KVA_PAGES because MySQL is an important service on this system and I had to get it back up and running. > What you meant to say is that it caused a Linux threads kernel > module mailbox location problem for the user space Linux threads > library. In other words, it's because you are using the Linux > threads implementation, that you have this problem, not > FreeBSD's pthreads. I may have misspoken in the previous thread about pthreads having a problem when KVA_PAGES was increased. I was referencing a previous thread in which the author stated pthreads had a problem when KVA_PAGES was increased and had assumed that the author knew what he was talking about. At any rate, this was apparently patched and included into the RELENG_4 tree after 4.7- RELEASE. I plan on grabbing RELENG_4_8 once it's officially released. That should give me room to play with KVA_PAGES, if necessary, without breaking MySQL. Also worth reiterating is that resource usage by Apache is the source of the panics. The version I'm using is 1.3.27, so it doesn't even make use of threading, at least not like Apache 2.0. I would just switch to Apache 2.0, but it doesn't support all the modules we need yet. Threads were only an issue with MySQL when KVA_PAGES>256, which doesn't appear to be related to the panics happening while KVA_PAGES=256. > In any case, the problem you are having is because the uma_zalloc() > (UMA) allocator is feeling KVA space pressure. > > One way to move this pressure somewhere else, rather than dealing with > it in an area which results in a panic on you because the code was not > properly retrofit for the limitations of UMA, is to decide to > preallocate the UMA region used for the "PV ENTRY" zone. I haven't read up on that section of the source, but I'll go do so now and determine if the changes you suggested would help in this case. I know in some other posts you're a strong advocate for mapping all physical RAM into KVA right up front rather than messing around with some subset of physical RAM getting mapped into KVA. That approach seems to make sense, at least for large memory systems, if I understand all the dynamics of the situation correctly. > The way to do this is to modify /usr/src/sys/i386/i386/pmap.c > at about line 122, where it says: > > #define MINPV 2048 > If I read the code correctly in pmap.c, MINPV just guarantees that the system will have at least *some* PV Entries available by preallocating the KVA (28 bytes each on my system) for those PV Entries specified by MINPV. See the section of /usr/src/sys/i386/i386/pmap.c labelled "init the pv free list". I'm not certain it makes a lot of sense to preallocate KVA space for 11,113,502 PV Entries when we don't appear to be completely KVA starved. As I understand it (and as you seem to have suggested), increasing MINPV would only be useful if we were running out of KVA due to other KVA consumers (like buffers, cache, mbuf clusters, and etc.) before we could get enough PV Entries on the "free" list. I don't believe that is what's happening here. Here's some sysctl's that are pertinent: vm.zone_kmem_kvaspace: 350126080 vm.kvm_size: 1065353216 vm.kvm_free: 58720256 vm.zone_kmem_kvaspace indicates (if I understand it correctly) that kmem_alloc() allocated about 334MB of KVA at boot. vm.kvm_free indicates that KVM is only pressured after the system has been running awhile. The sysctl's above were read after running for about 90 minutes after a reboot during non-peak usage hours. At that time, there were 199MB allocated to buffers, 49MB allocated to cache, and 353MB wired. During peak usage, we will typically have 199MB allocated to buffers, ~150MB allocated to cache, and 500MB to 700MB wired. If I understand things correctly, that would mean we're peaking around the 1GB KVM mark and there's probably some recycling of memory used by cache to free up KVM for other uses when necessary. However, I don't believe we're putting so much pressure on KVA/KVM as to run out of 28 byte chunks for PV Entries to be made. Assuming, once again, that I understand things correctly, if we were putting that much pressure on KVA/KVM, cache would go nearer to zero while the system attempted to make room for those 28 byte PV Entries. Even during peak usage and just prior to panic, the system still has over 100MB of cache showing. I have a 'systat -vm' from a few seconds prior to one of the panics that showed over 200MB of KVM free. So, I don't think the memory allocation in KVA/KVM associated with PV Entries is the culprit of our panics. Here's a copy of one of the panics and the trace I did on it. Fatal trap 12: page fault while in kernel mode mp_lock = 01000002; cpuid = 1; lapic.id = 00000000 fault virtual address = 0x4 fault code = supervisor write, page not present instruction pointer = 0x8:0xc02292bd stack pointer = 0x10:0xed008e0c frame pointer = 0x10:0xed008e1c 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 = 61903 (httpd) interrupt mask = net tty bio cam <- SMP: XXX trap number = 12 panic: page fault mp_lock = 01000002; cpuid = 1; lapic.id = 00000000 boot() called on cpu#1 Instruction pointer trace: # nm -n /kernel | grep c02292bd # nm -n /kernel | grep c02292b # nm -n /kernel | grep c02292 c022929c t pmap_insert_entry exact line number of instruction: ---------------------------------- (kgdb) l *pmap_insert_entry+0x21 0xc02292bd is in pmap_insert_entry (/usr/src/sys/i386/i386/pmap.c:1636). 1631 int s; 1632 pv_entry_t pv; 1633 1634 s = splvm(); 1635 pv = get_pv_entry(); 1636 pv->pv_va = va; 1637 pv->pv_pmap = pmap; 1638 pv->pv_ptem = mpte; 1639 1640 TAILQ_INSERT_TAIL(&pmap->pm_pvlist, pv, pv_plist); The instruction pointer is always the same on these panics and is almost invariably in a httpd process during the panic. My interpretation is that it is actually failing on line 1635 of pmap.c in get_pv_entry(). Here's the code for get_pv_entry(): get_pv_entry(void) { pv_entry_count++; if (pv_entry_high_water && (pv_entry_count > pv_entry_high_water) && (pmap_pagedaemon_waken == 0)) { pmap_pagedaemon_waken = 1; wakeup (&vm_pages_needed); } return zalloci(pvzone); } Now, unless it does it somewhere else, there is no bounds checking on pv_entry_count in that function. So, when the pv_entry_count exceeds the limit on PV Entries (pv_entry_max as defined in pmap_init2() in pmap.c), it just panics with a "page not present" when it goes to process line 1636 because it is impossible for a page to be present for a PV Entry with that pv_entry_count number being greater than pv_entry_max as defined in pmap_init2() in pmap.c. I suppose, that if nobody is worried about this issue, then a quick and dirty way to handle it would be to add bounds checking to pv_entry_count in get_pv_entry() and if pv_entry_count is outside the bounds, then produce a panic with a more informative message. At least, with a useful panic, the problem would be readily identified on other systems and you guys would have a better opportunity to see how many other people run into this issue. Now, that's my synopsis of the problem, though I'm still a newb with regard to my understanding of the BSD memory management system. Based on the information I've given you, do you still think this panic was caused by running out of KVA/KVM? If I'm wrong, I'd love to know it so I can revise my understanding of what is going on to cause the panic. For now, I've solved the problem by limiting the number of Apache processes that are allowed to run based on my calculations of how many PV Entries are required by each child process, but it's painful to have all that RAM and not be able to put it to use because of an issue in the memory management code that shows up on large memory systems (>2GB). IMHO, Apache shouldn't be able crash an OS before it ever starts using swap. The only reason the problem doesn't show on systems with the typical amounts of RAM (2GB or less) is that if those systems ran Apache like we do, they'd spiral to a crash as swap usage increased and eventually swap was completely filled. Sincerely, Andrew Kinney President and Chief Technology Officer Advantagecom Networks, Inc. http://www.advantagecom.net From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 26 08:24: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 006C237B404 for ; Wed, 26 Mar 2003 08:24:31 -0800 (PST) Received: from office.advantagecom.net (office.advantagecom.net [207.109.186.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id D50E143FB1 for ; Wed, 26 Mar 2003 08:24:29 -0800 (PST) (envelope-from andykinney@advantagecom.net) Received: from SCSI-MONSTER (andy.advantagecom.net [207.109.186.200] (may be forged)) by office.advantagecom.net (8.9.3/8.9.3) with ESMTP id IAA02979; Wed, 26 Mar 2003 08:24:26 -0800 From: "Andrew Kinney" Organization: Advantagecom Networks, Inc. To: Igor Sysoev Date: Wed, 26 Mar 2003 08:24:37 -0800 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Message-ID: <3E8163C5.3024.3C0A1A9@localhost> Priority: normal References: <3E8097D4.22759.A3FC35@localhost> In-reply-to: X-mailer: Pegasus Mail for Win32 (v3.12c) X-Spam-Status: No, hits=-24.6 required=5.0 tests=AWL,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) cc: freebsd-hackers@FreeBSD.ORG Subject: Re: shared mem and panics when out of PV Entries X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: andykinney@advantagecom.net List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2003 16:24:32 -0000 On 26 Mar 2003, at 13:29, Igor Sysoev wrote: > If you have 200M shared memory it takes about 50,000 PV entries per > process. 20 processes takes 1 million PV entries. We've got about 11.1 million PV entries to play with, so I went ahead and made MaxClients 150 just to ensure Apache couldn't panic the system at will. That combined with minimizing the KeepAliveTimeout has solved the problem for now, though I'm still not happy about letting all that RAM sit idle. I guess I'll just have to live with it. Eventually, I may be forced to turn off KeepAlive and make use of FreeBSD's accept filters or put in a reverse proxy as you recommend. For now, though, we are serving the whole gammut from this Apache. Static pages, images, mod_perl, PHP, Apache::ASP, and most anything else a customer might want or need to serve from a web server. I know it isn't the most efficient way to use Apache, but nobody has any complaints about performance at this point. Sincerely, Andrew Kinney President and Chief Technology Officer Advantagecom Networks, Inc. http://www.advantagecom.net From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 26 08:50: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 7624B37B404 for ; Wed, 26 Mar 2003 08:50:34 -0800 (PST) Received: from smtp-relay.omnis.com (smtp-relay.omnis.com [216.239.128.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id AE5A343F75 for ; Wed, 26 Mar 2003 08:50:33 -0800 (PST) (envelope-from wes@softweyr.com) Received: from softweyr.homeunix.net (66-91-236-204.san.rr.com [66.91.236.204]) by smtp-relay.omnis.com (Postfix) with ESMTP id 6E5A24368D; Wed, 26 Mar 2003 08:50:32 -0800 (PST) From: Wes Peters Organization: Softweyr To: Daniela , Kris Kennaway Date: Wed, 26 Mar 2003 08:50:30 -0800 User-Agent: KMail/1.5 References: <200303212037.46322.dgw@liwest.at> <200303231120.15652.wes@softweyr.com> <200303242018.43648.dgw@liwest.at> In-Reply-To: <200303242018.43648.dgw@liwest.at> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200303260850.30970.wes@softweyr.com> X-Spam-Status: No, hits=-26.1 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT autolearn=ham version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) cc: hackers@FreeBSD.ORG Subject: Re: Lots of kernel core dumps 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, 26 Mar 2003 16:50:35 -0000 On Monday 24 March 2003 11:18, Daniela wrote: > On Sunday 23 March 2003 20:20, Wes Peters wrote: > > > > The reason for creating the 5.0 release is to make it easy for more > > developers and testers to jump onto the 5.x bandwagon by giving them > > a known (relatively) good starting point. Quite a number of problems > > have been fixed since 5.0-RELEASE; CURRENT is now generally much more > > stable, and nobody is going to spend time updating 5.0 which is > > essentially an "early access" release. > > > > You have to decide for yourself if this machine is too critical to > > run CURRENT, in which case it's probably best off running STABLE or > > the latest 4.x release branch, or if you want to update it to > > CURRENT, follow the CURRENT mailing list, and update again at known > > stable development points. It looks like right now is pretty good if > > you want to jump. > > > > At any rate, thanks for your tenacity. We really do appreciate the > > contributions of everyone. > > Well, it's just a home server. I don't mind a few crashes, but security > is important for me. What do you think, should I go back to -stable? > FreeBSD is the world's best OS, I want to see it succeeding and I want > to help as much as possible. I have two machines at home and run STABLE on my workstation, which is also our 'group server' for the home. I have current on a crash test box that used to be my workstation 6 years ago, a K6/233 I can't imagine not having. If you're similarly hardware-rich, I'd recommend a similar approach. If you have only the one box, I personally would probably run CURRENT and be careful about when to run CVSup. Good luck! -- Where am I, and what am I doing in this handbasket? Wes Peters wes@softweyr.com From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 26 09:08: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 5BD0637B404 for ; Wed, 26 Mar 2003 09:08:51 -0800 (PST) Received: from mx10.mail.ru (mx10.mail.ru [194.67.57.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id A2EB143FA3 for ; Wed, 26 Mar 2003 09:08:49 -0800 (PST) (envelope-from dm_list@mail.ru) Received: from [212.46.253.124] (helo=inco) by mx10.mail.ru with esmtp (Exim SMTP.A) id 18yEOJ-0001Kh-00 for freebsd-hackers@freebsd.org; Wed, 26 Mar 2003 20:08:43 +0300 Date: Wed, 26 Mar 2003 20:08:32 +0300 From: SkiEr X-Mailer: The Bat! (v1.60h) Organization: Damage Inc. X-Priority: 3 (Normal) Message-ID: <125612343.20030326200832@mail.ru> To: "freebsd-hackers-request@freebsd.org" In-Reply-To: <20030326093532.E6ED537B405@hub.freebsd.org> References: <20030326093532.E6ED537B405@hub.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=Windows-1251 Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=-24.6 required=5.0 tests=BODY_8BITS,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Subject: Re: freebsd-hackers Digest, Vol 1, Issue 1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: SkiEr List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2003 17:08:54 -0000 Çäðàâñòâóéòå, freebsd-hackers-request. Òû çàäîëáàë!!!!!!!!!!!!!!!!!! Ïðîâåðü-êà ïðàâèëüíîñòü îòñûëêè ñâîèõ ñîîáùåíèé Âû ïèñàëè 26 ìàðòà 2003 ã., 12:35:32: fhrfo> Send freebsd-hackers mailing list submissions to fhrfo> freebsd-hackers@freebsd.org fhrfo> To subscribe or unsubscribe via the World Wide Web, visit fhrfo> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers fhrfo> or, via email, send a message with subject or body 'help' to fhrfo> freebsd-hackers-request@freebsd.org fhrfo> You can reach the person managing the list at fhrfo> freebsd-hackers-owner@freebsd.org fhrfo> When replying, please edit your Subject line so it is more specific fhrfo> than "Re: Contents of freebsd-hackers digest..." fhrfo> Today's Topics: fhrfo> 1. Re: [PATCH2] PPP in -direct mode does not execute any chat fhrfo> scripts (Maksim Yevmenkin) fhrfo> 2. Re: shared mem and panics when out of PV Entries (Andrew Kinney) fhrfo> 3. Re: shared mem and panics when out of PV Entries (Terry Lambert) fhrfo> 4. Some specific questions about 5.x (Alex) fhrfo> 5. Re: Some specific questions about 5.x (Miguel Mendez) fhrfo> 6. Re: Some specific questions about 5.x (Terry Lambert) fhrfo> 7. Re: Some specific questions about 5.x (Lev Walkin) fhrfo> ---------------------------------------------------------------------- fhrfo> Message: 1 fhrfo> Date: Tue, 25 Mar 2003 17:25:35 -0800 fhrfo> From: Maksim Yevmenkin fhrfo> Subject: Re: [PATCH2] PPP in -direct mode does not execute any chat fhrfo> scripts fhrfo> To: Brian Somers fhrfo> Cc: hackers@FreeBSD.ORG fhrfo> Message-ID: <3E81018F.70805@exodus.net> fhrfo> Content-Type: text/plain; charset=us-ascii; format=flowed fhrfo> Hello Brian, >> Yes, this looks fine, although I think this shows that the -direct >> description is wrong. Perhaps this is more appropriate: >> >> -direct >> This is used for communicating over an already established connection, >> usually when receiving incoming connections accepted by getty(8). ppp >> ignores the ``set device'' line and uses descriptor 0 as the link. ppp >> will ignore any configured chat scripts unless the ``force-scripts'' >> option has been enabled. >> >> If callback.... >> >> Do you agree with this description ? If so, I'll go ahead and commit the fhrfo> yes, this is more accurate description. i missed it. >> changes. Just to be picky, I'll re-sort the OPT_ variables too :*P fhrfo> no problem :) >> And thanks for the patches. fhrfo> thank you for reviewing them :) fhrfo> max >> On Mon, 03 Feb 2003 14:45:37 -0800, Maksim Yevmenkin wrote: >> >>>Dear Brian and Hackers, >>> >>>Please find updated proposed version of the patch. As suggested by >>>Warner option has been renamed to 'force-sripts' and now works for >>>both 'direct' and 'dedicated' modes. Also as suggested by Terry the >>>man page has been updated to document side effect of 'direct'. >>> >>>-direct >>> This is used for receiving incoming connections. ppp ignores the >>> ``set device'' line and uses descriptor 0 as the link. ppp will >>> never use any configured chat scripts unless ``force-scripts'' >>> option has been enabled. >>> >>> If callback is configured, ppp will use the ``set device'' infor- >>> mation when dialing back. >>> >>>-dedicated >>> This option is designed for machines connected with a dedicated >>> wire. ppp will always keep the device open and will never use >>> any configured chat scripts unless ``force-scripts'' option has >>> been enabled. >>> >>>force-scripts >>> Default: Disabled. Forces execution of the configured chat >>> scripts in direct and dedicated modes. >>> >>> >>>>>Please find attached patch that adds new option to the PPP. >>>>> >>>>>run-scripts-in-direct-mode >>>>> Default: Disabled. This allows to run chat scripts in >>>>> direct mode. >>>>> >>>>>did i miss anything? objections? comments? reviews? >>>> >>>> >>>>First comment: run it past Brian Somers ; it's >>>>his baby, and he's the active maintainer. >>> >>>I have sent him e-mail. >>> >>> >>>>Rest of comments: >>>> >>>>Actually, why doesn't "-direct" allow a chat script by default? >>>>The man page doesn't document that as a side-effect of "-direct", >>>>only of "-dedicated", but it's been there since the import. >>>> >>>>Should this really be a "negotiate" section command, rather than >>>>just a command or a "set" command? >>>> >>>>Also, there are only two other commands even have a "-" in them, >>>>and both of them only have one (just seems a little long, compared >>>>to, say, "rsid" or "direct-with-script", or even "force-script"). >>>> >>>>Personal preference: don't make it conditional on "-direct", let >>>>it also work with "-dedicated", and call it "force-script" or >>>>something, instead. >>> >>>done >>> >>> >>>>The man page should be updated -- including the undocumented >>>>side-effect of "-direct" disabling scripts). >>> >>>done >>> >>>thanks >>>max >>> >> >> >> fhrfo> ------------------------------ fhrfo> Message: 2 fhrfo> Date: Tue, 25 Mar 2003 17:54:28 -0800 fhrfo> From: "Andrew Kinney" fhrfo> Subject: Re: shared mem and panics when out of PV Entries fhrfo> To: Igor Sysoev fhrfo> Cc: freebsd-hackers@FreeBSD.ORG fhrfo> Message-ID: <3E8097D4.22759.A3FC35@localhost> fhrfo> Content-Type: text/plain; charset=US-ASCII fhrfo> On 25 Mar 2003, at 17:56, Igor Sysoev wrote: >> > So, what's the best approach to limiting memory shared via fork() or >> > reducing PV Entry usage by that memory? Is there something I can do >> > with the kernel config or sysctl to accomplish this? >> >> No, as far as I know there's no way to do it. >> The irony is that you do not need the most of these PV entries because >> you are not swaping. >> fhrfo> My thoughts exactly. I suppose not all that many people run well fhrfo> used web servers with 4GB of RAM, so there wouldn't be any fhrfo> reason for this issue to come up on a regular basis. fhrfo> I'm going to expose my newbness here with respect to BSD fhrfo> memory management, but could the number of files served and fhrfo> filesystem caching have something to do with the PV Entry usage fhrfo> by Apache? We've got around 1.2 million files served by this fhrfo> Apache. Could it be that the extensive PV Entry usage has fhrfo> something to do with that? Obviously, not all are accessed all the fhrfo> time, but it wouldn't take a very large percentage of them being fhrfo> accessed to cause issues if filesystem caching is in any way fhrfo> related to PV Entry usage by Apache. fhrfo> I remember reading somewhere (sorry, didn't keep track of the link) fhrfo> that someone running a heavily used Squid proxy had a very fhrfo> similar issue with running out of PV Entries as they got more and fhrfo> more files in the cache. Squid is basically a modified Apache with fhrfo> proxy caching turned on. >> I think you should try to decrease memory that shared between Apache >> processes. If you can not change scripts then the single method is to >> decrease number of Apache processes while keeping to handle the >> current workload: 1) disable keepalive if it enabled; 2) set Apache >> behind reverse-proxy server that frees Apache processes >> as soon as proxy get the whole responses. fhrfo> We had keepalive set to the default of "on" (at least default for this fhrfo> install) with the default keepalive timeout of 15 seconds. fhrfo> Dropping the keepalive timeout down to 3 seconds has fhrfo> dramatically reduced the number of Apache processes required to fhrfo> serve the load. With the new settings, we're averaging 30 to 80 fhrfo> Apache processes, which is much more manageable in terms of fhrfo> memory usage, though we weren't anywhere near running out of fhrfo> physical RAM prior to this. We're servicing a little over 1000 fhrfo> requests per minute, which by some standards isn't a huge amount. fhrfo> We're still seeing quite heavy PV Entry usage, though. The fhrfo> reduced number of Apache processes (by more than half) doesn't fhrfo> seem to have appreciably reduced PV Entry usage versus the fhrfo> previous settings, so I suspect I may have been wrong about fhrfo> memory sharing as the culprit for the PV Entry usage. This fhrfo> observation may just be coincidence, but the average PV Entry fhrfo> usage seems to have gone up by a couple million entries since the fhrfo> changes to the Apache config. fhrfo> Time will tell if the PV Entries are still getting hit hard enough to fhrfo> cause panics due to running out of them. They're supposed to get fhrfo> forcibly recycled at 90% utilization from what I see in the kernel fhrfo> code, so if we never get above 90% utilization I guess I could fhrfo> consider the issue resolved. fhrfo> What other things in Apache (besides memory sharing via PHP fhrfo> and/or mod_perl) could generate PV Entry usage on a massive fhrfo> scale? fhrfo> Sincerely, fhrfo> Andrew Kinney fhrfo> President and fhrfo> Chief Technology Officer fhrfo> Advantagecom Networks, Inc. fhrfo> http://www.advantagecom.net fhrfo> ------------------------------ fhrfo> Message: 3 fhrfo> Date: Tue, 25 Mar 2003 19:28:18 -0800 fhrfo> From: Terry Lambert fhrfo> Subject: Re: shared mem and panics when out of PV Entries fhrfo> To: andykinney@advantagecom.net fhrfo> Cc: freebsd-hackers@FreeBSD.ORG fhrfo> Message-ID: <3E811E52.198972EB@mindspring.com> fhrfo> Content-Type: text/plain; charset=us-ascii fhrfo> Andrew Kinney wrote: >> On 25 Mar 2003, at 17:56, Igor Sysoev wrote: >> > > So, what's the best approach to limiting memory shared via fork() or >> > > reducing PV Entry usage by that memory? Is there something I can do >> > > with the kernel config or sysctl to accomplish this? >> > >> > No, as far as I know there's no way to do it. >> > The irony is that you do not need the most of these PV entries because >> > you are not swaping. >> >> My thoughts exactly. I suppose not all that many people run well >> used web servers with 4GB of RAM, so there wouldn't be any >> reason for this issue to come up on a regular basis. fhrfo> You need the pv_entry_t's because there is one on each vm_page_t fhrfo> for each virtual mapping for the page. fhrfo> This is necessary to correctly mark things clean or dirty, fhrfo> and to deal with copy-on-write. fhrfo> What is *actually* ironic is that, for the most part, these fhrfo> things *may* be able to be shared, if they were made slightly fhrfo> more complex and reference counted, and you were willing to fhrfo> split some of the copy-on-write code a little bit further fhrfo> between machine-dependent and machine-independent. fhrfo> Matt Dillon would be the person to talk to about this; I fhrfo> could do it, but he'd do it faster. >> I'm going to expose my newbness here with respect to BSD >> memory management, but could the number of files served and >> filesystem caching have something to do with the PV Entry usage >> by Apache? We've got around 1.2 million files served by this >> Apache. Could it be that the extensive PV Entry usage has >> something to do with that? Obviously, not all are accessed all the >> time, but it wouldn't take a very large percentage of them being >> accessed to cause issues if filesystem caching is in any way >> related to PV Entry usage by Apache. fhrfo> When you fork, you copy the address space, which means you copy fhrfo> the pv_entry_t's, so the answer is a tentative "yes". But files fhrfo> which are not open are not mapped, so unless you have a lot of fhrfo> mmap's hanging around, this shouldn't be an issue with System V fhrfo> shared memory. >> We had keepalive set to the default of "on" (at least default for this >> install) with the default keepalive timeout of 15 seconds. >> >> Dropping the keepalive timeout down to 3 seconds has >> dramatically reduced the number of Apache processes required to >> serve the load. With the new settings, we're averaging 30 to 80 >> Apache processes, which is much more manageable in terms of >> memory usage, though we weren't anywhere near running out of >> physical RAM prior to this. We're servicing a little over 1000 >> requests per minute, which by some standards isn't a huge amount. >> >> We're still seeing quite heavy PV Entry usage, though. The >> reduced number of Apache processes (by more than half) doesn't >> seem to have appreciably reduced PV Entry usage versus the >> previous settings, so I suspect I may have been wrong about >> memory sharing as the culprit for the PV Entry usage. This >> observation may just be coincidence, but the average PV Entry >> usage seems to have gone up by a couple million entries since the >> changes to the Apache config. >> >> Time will tell if the PV Entries are still getting hit hard enough to >> cause panics due to running out of them. They're supposed to get >> forcibly recycled at 90% utilization from what I see in the kernel >> code, so if we never get above 90% utilization I guess I could >> consider the issue resolved. >> >> What other things in Apache (besides memory sharing via PHP >> and/or mod_perl) could generate PV Entry usage on a massive >> scale? fhrfo> Basically, you don't really care about pv_entry_t's, you care fhrfo> about KVA space, and running out of it. fhrfo> In a previous posting, you suggested increasing KVA_PAGES fixed fhrfo> the problem, but caused a pthreads problem. fhrfo> What you meant to say is that it caused a Linux threads kernel fhrfo> module mailbox location problem for the user space Linux threads fhrfo> library. In other words, it's because you are using the Linux fhrfo> threads implementation, that you have this problem, not FreeBSD's fhrfo> pthreads. fhrfo> Probably, the Linux threads kernel module should be modified to fhrfo> provide the mailbox location, and then the user space Linux fhrfo> threads library should be modified to utilize sysctl to talk fhrfo> to the kernel module, and establish the locations, so that they fhrfo> don't have to be agreed upon at compile time for programs using fhrfo> the code. fhrfo> In any case, the problem you are having is because the uma_zalloc() fhrfo> (UMA) allocator is feeling KVA space pressure. fhrfo> One way to move this pressure somewhere else, rather than dealing fhrfo> with it in an area which results in a panic on you because the code fhrfo> was not properly retrofit for the limitations of UMA, is to decide fhrfo> to preallocate the UMA region used for the "PV ENTRY" zone. fhrfo> The way to do this is to modify /usr/src/sys/i386/i386/pmap.c fhrfo> at about line 122, where it says: fhrfo> #define MINPV 2048 fhrfo> to say instead: fhrfo> #ifndef MINPV fhrfo> #define MINPV 2048 /* default, if not specified in config */ fhrfo> #endif fhrfo> And to realize that there is an "opt_pmap.h". To activate this, fhrfo> you will need to add this line to /usr/src/sys/conf/options.i386: fhrfo> MINPV opt_pmap.h fhrfo> With this in place, you will be able to adjust the initial minimum fhrfo> allocations upward by saying: fhrfo> options MINPV=4096 fhrfo> (or whatever) in your kernel config file. fhrfo> Note: you may want to "#if 0" out the #define in pmap.c altogether, fhrfo> to reassure yourself that this is working; it's easy to make a mistake fhrfo> in this part of the kernel. fhrfo> -- Terry fhrfo> ------------------------------ fhrfo> Message: 4 fhrfo> Date: Wed, 26 Mar 2003 10:57:07 +0300 fhrfo> From: Alex fhrfo> Subject: Some specific questions about 5.x fhrfo> To: FreeBSD hackers list fhrfo> Message-ID: <3E815D53.6010404@dynaweb.ru> fhrfo> Content-Type: text/plain; charset=windows-1251; format=flowed fhrfo> Hi everybody! fhrfo> I was so much enthusiastic about kernel threads implemented in 5.x but fhrfo> some ugly rumors spoiled my dreams :0) fhrfo> So I want to get if these rumors are myths or not. fhrfo> 1. Is it true that kernel threads are more "heavy" than userspace fhrfo> ones (pthread) and hence application with hundreds of threads will work fhrfo> evidently slower than that using pthreads due to more switching penalties? fhrfo> 2. Is it true that even 5.x has no implementation for inter-process fhrfo> semaphores that are blocking calling thread only not the whole process fhrfo> as usually in FreeBSD? fhrfo> Alex fhrfo> ------------------------------ fhrfo> Message: 5 fhrfo> Date: Wed, 26 Mar 2003 09:18:45 +0100 fhrfo> From: Miguel Mendez fhrfo> Subject: Re: Some specific questions about 5.x fhrfo> To: alex@dynaweb.ru fhrfo> Cc: FreeBSD hackers list fhrfo> Message-ID: <20030326091845.36425fad.flynn@energyhq.homeip.net> fhrfo> Content-Type: text/plain; charset="us-ascii" fhrfo> On Wed, 26 Mar 2003 10:57:07 +0300 fhrfo> Alex wrote: fhrfo> Howdy. >> 1. Is it true that kernel threads are more "heavy" than userspace >> ones (pthread) and hence application with hundreds of threads will >> work evidently slower than that using pthreads due to more switching >> penalties? fhrfo> AFAIK, not in a hybrid model. Systems that do 1:1 thread mapping (Like fhrfo> Gah! Nu/Linux) will suffer from this kind of situation, also will use fhrfo> more kernel memory. In hybrid implementations based on Scheduler fhrfo> Activations, like FreeBSD's KSE, and NetBSD's SA, there's a balance fhrfo> between the number of kernel virtual processors available and the number fhrfo> of userland threads, it's an N:M model. Nathan Williams' paper on the fhrfo> subject suggests that context switch is not much slower than a pure fhrfo> userland implementation. Also, keep in mind that pure userland has other fhrfo> problems, like when one thread blocks on I/O. In pure userland threading fhrfo> systems this means the whole process is blocked, whereas in KSE and SA fhrfo> only that thread is stopped. >> 2. Is it true that even 5.x has no implementation for inter-process >> semaphores that are blocking calling thread only not the whole process >> as usually in FreeBSD? fhrfo> That I don't know, perhaps the local KSE guru, Julian might have an fhrfo> answer for this. fhrfo> Cheers, fhrfo> -- fhrfo> Miguel Mendez - flynn@energyhq.homeip.net fhrfo> GPG Public Key :: http://energyhq.homeip.net/files/pubkey.txt fhrfo> EnergyHQ :: http://www.energyhq.tk fhrfo> Tired of Spam? -> http://www.trustic.com fhrfo> -------------- next part -------------- fhrfo> A non-text attachment was scrubbed... fhrfo> Name: not available fhrfo> Type: application/pgp-signature fhrfo> Size: 186 bytes fhrfo> Desc: not available fhrfo> Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20030326/6b59980f/attachment-0001.bin fhrfo> ------------------------------ fhrfo> Message: 6 fhrfo> Date: Wed, 26 Mar 2003 00:53:59 -0800 fhrfo> From: Terry Lambert fhrfo> Subject: Re: Some specific questions about 5.x fhrfo> To: alex@dynaweb.ru fhrfo> Cc: FreeBSD hackers list fhrfo> Message-ID: <3E816AA7.1B6A02C@mindspring.com> fhrfo> Content-Type: text/plain; charset=us-ascii fhrfo> Alex wrote: >> I was so much enthusiastic about kernel threads implemented in 5.x but >> some ugly rumors spoiled my dreams :0) >> So I want to get if these rumors are myths or not. fhrfo> 5.x does not implement traditional "kernel threads" like you appear fhrfo> to be thinking about them. Instead, it implements a variation of fhrfo> scheduler activations. Traditional "kernel threads" have a lot of fhrfo> unnecessary overhead problems, including CPU affinity and thread fhrfo> group negaffinity, necessary for increased single application fhrfo> concurrency. fhrfo> See the KSE documentation for more information. >> 1. Is it true that kernel threads are more "heavy" than userspace >> ones (pthread) and hence application with hundreds of threads will work >> evidently slower than that using pthreads due to more switching penalties? fhrfo> Yes and No. fhrfo> See the KSE documentation for more information. >> 2. Is it true that even 5.x has no implementation for inter-process >> semaphores that are blocking calling thread only not the whole process >> as usually in FreeBSD? fhrfo> No, for values of x > 0. fhrfo> See the KSE documentation for more information. fhrfo> -- Terry fhrfo> ------------------------------ fhrfo> Message: 7 fhrfo> Date: Wed, 26 Mar 2003 01:35:37 -0800 fhrfo> From: Lev Walkin fhrfo> Subject: Re: Some specific questions about 5.x fhrfo> To: Miguel Mendez fhrfo> Cc: FreeBSD hackers list fhrfo> Message-ID: <3E817469.4030403@netli.com> fhrfo> Content-Type: text/plain; charset=us-ascii; format=flowed fhrfo> Miguel Mendez wrote: >> On Wed, 26 Mar 2003 10:57:07 +0300 >> Alex wrote: >> >> Howdy. >> >> >>>1. Is it true that kernel threads are more "heavy" than userspace >>>ones (pthread) and hence application with hundreds of threads will >>>work evidently slower than that using pthreads due to more switching >>>penalties? >> >> >> AFAIK, not in a hybrid model. Systems that do 1:1 thread mapping (Like >> Gah! Nu/Linux) will suffer from this kind of situation, also will use >> more kernel memory. In hybrid implementations based on Scheduler >> Activations, like FreeBSD's KSE, and NetBSD's SA, there's a balance >> between the number of kernel virtual processors available and the number >> of userland threads, it's an N:M model. Nathan Williams' paper on the >> subject suggests that context switch is not much slower than a pure >> userland implementation. Also, keep in mind that pure userland has other >> problems, like when one thread blocks on I/O. In pure userland threading >> systems this means the whole process is blocked, whereas in KSE and SA >> only that thread is stopped. fhrfo> What about Solaris' migration towards 1:1 model from the N:M one they fhrfo> had supported for years already? Who are insane, Solaris folks (moving fhrfo> towards Linux) or Free/NetBSD ones (migrating to the old Solaris' fhrfo> behavior)? -- Ñ óâàæåíèåì, SkiEr mailto:dm_list@mail.ru From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 26 10:28: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 E99AB37B404; Wed, 26 Mar 2003 10:28:25 -0800 (PST) Received: from man-97-187.ResHall.Berkeley.EDU (man-97-187.Reshall.Berkeley.EDU [169.229.97.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3F84843F75; Wed, 26 Mar 2003 10:28:25 -0800 (PST) (envelope-from lou@man-97-187.ResHall.Berkeley.EDU) Received: from man-97-187.ResHall.Berkeley.EDU (localhost.ResHall.Berkeley.EDU [127.0.0.1])h2QIPoOj000910; Wed, 26 Mar 2003 10:25:50 -0800 (PST) (envelope-from lou@man-97-187.ResHall.Berkeley.EDU) Received: from localhost (lou@localhost)id h2QIPopD000907; Wed, 26 Mar 2003 10:25:50 -0800 (PST) Date: Wed, 26 Mar 2003 10:25:48 -0800 (PST) From: Tak Pui LOU To: "Jacques A. Vidrine" In-Reply-To: <20030326150152.GG33671@madman.celabo.org> Message-ID: <20030326102330.V892@man-97-187.ResHall.Berkeley.EDU> References: <20030326124420.388DE10160@ws-tor-0004.procergs> <20030326150152.GG33671@madman.celabo.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-19.9 required=5.0 tests=AWL,IN_REP_TO,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) cc: freebsd-hackers@freebsd.org Subject: Re: pam_ldap... 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, 26 Mar 2003 18:28:28 -0000 > > Why FreeBSD do not support ldap authentication? (nss_ldap) > > files, nis, hesiod??? do we live in the past? One of great > > things in 5.0 release for me, should be this! :) > > Wait for FreeBSD 5.1. Does that mean there will be official support for nss_ldap in FBSD 5.1? Is it on the -current right now? I would like to test it. --- Lou From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 26 10: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 B777537B404 for ; Wed, 26 Mar 2003 10:38:25 -0800 (PST) Received: from lilzcluster.liwest.at (lilzclust02.liwest.at [212.33.55.12]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2939A43FB1 for ; Wed, 26 Mar 2003 10:38:24 -0800 (PST) (envelope-from dgw@liwest.at) Received: from CM58-27.liwest.at by lilzcluster.liwest.at (8.10.2/1.1.2.11/08Jun01-1123AM) id h2QIc3m0001124636; Wed, 26 Mar 2003 19:38:11 +0100 (MET) Content-Type: text/plain; charset="iso-8859-1" From: Daniela To: Peter Jeremy Date: Wed, 26 Mar 2003 19:36:13 +0100 User-Agent: KMail/1.4.3 References: <200303212037.46322.dgw@liwest.at> <200303242018.43648.dgw@liwest.at> <20030325071418.GA16046@cirb503493.alcatel.com.au> In-Reply-To: <20030325071418.GA16046@cirb503493.alcatel.com.au> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200303261936.13694.dgw@liwest.at> X-Spam-Status: No, hits=-31.9 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_KMAIL autolearn=ham version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) cc: hackers@FreeBSD.ORG Subject: Re: Lots of kernel core dumps 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, 26 Mar 2003 18:38:29 -0000 On Tuesday 25 March 2003 08:14, Peter Jeremy wrote: > On Mon, Mar 24, 2003 at 08:18:43PM +0100, Daniela wrote: > >Well, it's just a home server. I don't mind a few crashes, but securit= y is > >important for me. What do you think, should I go back to -stable? > > If you're willing to put up with a few crashes _and_ assist with > debugging the crashes (eg trying patches) then running -CURRENT would > help the Project. One option you could try is to stick with -CURRENT > for a month or two and see how it pans out - if you feel it's too > painful, downgrade to -STABLE. (I ran -CURRENT on my main workstation > for about 3 years - I dropped back to -STABLE midway through last year > because -CURRENT happened to strike an extended period of instability > and it was causing me too much angst). > > On the topic of security, you should be aware that -CURRENT is not > officially supported and therefore isn't mentioned in security > advisories - in general -CURRENT will have security patches applied > before -STABLE but you will need to do some detective work if you > want to identify the exact time/revision affected. There have also > been a couple of instances where security problems only affected > -CURRENT. In short, if I keep my eyes open, security isn't bad, right? I'll give -current a try, thanks for your advice. Daniela From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 26 12:53: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 4F6C237B409 for ; Wed, 26 Mar 2003 12:53:24 -0800 (PST) Received: from titan.kleipool.org (e137166.upc-e.chello.nl [213.93.137.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id 652DB43FBD for ; Wed, 26 Mar 2003 12:53:20 -0800 (PST) (envelope-from Reinier@Kleipool.org) Received: from io (io.ovs.kleipool.org [192.168.1.82]) by titan.kleipool.org (8.12.6/8.12.6) with SMTP id h2QKrGXp067385 for ; Wed, 26 Mar 2003 21:53:18 +0100 (CET) (envelope-from Reinier@Kleipool.org) From: "Reinier Kleipool" To: Date: Wed, 26 Mar 2003 21:53:14 +0100 Message-ID: <001d01c2f3d9$b8f741e0$5201a8c0@ovs.kleipool.org> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20030326102330.V892@man-97-187.ResHall.Berkeley.EDU> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4920.2300 Importance: Normal X-Spam-Status: No, hits=-10.2 required=5.0 tests=IN_REP_TO,ORIGINAL_MESSAGE,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1 autolearn=ham version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Subject: RE: pam_ldap... 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, 26 Mar 2003 20:53:27 -0000 Yes me too! I have always found the lack of pam_nss a big omission in FreeBSD. Is this under development for 5.1??? I really hope! Kind Regards, Reinier Kleipool -----Original Message----- From: owner-freebsd-hackers@freebsd.org [mailto:owner-freebsd-hackers@freebsd.org]On Behalf Of Tak Pui LOU Sent: woensdag 26 maart 2003 19:26 To: Jacques A. Vidrine Cc: freebsd-hackers@freebsd.org Subject: Re: pam_ldap... > > Why FreeBSD do not support ldap authentication? (nss_ldap) > > files, nis, hesiod??? do we live in the past? One of great > > things in 5.0 release for me, should be this! :) > > Wait for FreeBSD 5.1. Does that mean there will be official support for nss_ldap in FBSD 5.1? Is it on the -current right now? I would like to test it. --- Lou _______________________________________________ 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 Wed Mar 26 14:07: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 1C2A937B408 for ; Wed, 26 Mar 2003 14:07:19 -0800 (PST) Received: from heron.mail.pas.earthlink.net (heron.mail.pas.earthlink.net [207.217.120.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6609143FB1 for ; Wed, 26 Mar 2003 14:07:14 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from pool0166.cvx22-bradley.dialup.earthlink.net ([209.179.198.166] helo=mindspring.com) by heron.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 18yJ2r-00077R-00; Wed, 26 Mar 2003 14:06:54 -0800 Message-ID: <3E822424.C0D6E8E9@mindspring.com> Date: Wed, 26 Mar 2003 14:05:24 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: andykinney@advantagecom.net References: <3E815E80.18738.3AC0E20@localhost> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4ae97b284e56ea66813d86019e898f4ffa8438e0f32a48e08350badd9bab72f9c350badd9bab72f9c X-Spam-Status: No, hits=-21.4 required=5.0 tests=AWL,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) cc: freebsd-hackers@FreeBSD.ORG Subject: Re: shared mem and panics when out of PV Entries 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, 26 Mar 2003 22:07:22 -0000 Andrew Kinney wrote: > On 25 Mar 2003, at 19:28, Terry Lambert wrote: > > Basically, you don't really care about pv_entry_t's, you care > > about KVA space, and running out of it. > > > > In a previous posting, you suggested increasing KVA_PAGES fixed > > the problem, but caused a pthreads problem. > > Will running out of KVA space indirectly cause PV Entries to hit its > limit as shown in sysctl vm.zone? Yes. The UMA code preallocates only a small set of entries in a zone, and then allocates more on an as-needed basis. Previously, the zalloci() code was used (the "i" stands for "interrupt"). This allocator preestablished page mappings (bt not necessarily pages) for every object that could be allocated in the zone. The zalloci() had the benefit of preallocating mappings, so you could not run out, but has the disadvantage that you can now run out unexpectedly, if something else puts pressure on the number of page mappings, and runs you out first. The main problem that causes this is that memory allocations in the zone allocation case are type-stable, which means that if they are allocated to be of a particular type, they remain of that type. By giving a larger "minimum", you are effectively reverting to the old behaviour of defining a "maximum", by allocating higher than any possible usage. Note that you can still run out, if you go over this number, and that running out of some things is fatal. Basically, when the new allocation policies went in, the code that it was applied to was not checked for low end failure cases, so there are some introduced bugs that are slowly being beat out of old code that never had to deal with an allocation failure under normal conditions, ever before. The code changes I posted only work around the introduced bugs in this one case; I expect that if you push your hernia in with a girdle, it will pop out somewhere else. But at least you will be doing valuable work, identifying where the introduced bugs live. 8-). > To my knowledge, I've never seen a panic on this system > directly resulting from running out of KVA space. They've > all been traced back to running out of available PV Entries. But ask yourself "Why did the allocation of new PV Entries fail this time?". The answer is that you ran out of page mappings for the new page you wanted to allocate to contain the new entries. As I said, it's an introduced bug, and a side effect of the change in zone allocation policy implementation. The patch I posted lets you work around it by pushing the number of "PV Entries", specifically above the number you will ever need, at the expense of you maybe running out of page mappings somewhere else. Technically, the code should have been changes to attempt to prereserve all necessary mappings on a fork(), and, if it was not possible, then to fail the fork(). Probably this would require counted lists, so you could lock, know how many were free, unlock, attempt to allocate blocks until there were enough more free, relock, verify the count, and then complete the operation and unlock. > I'm invariably hitting the panic in pmap_insert_entry() and I only get > the panic when I run out of available PV Entries. I've seen nothing > to indicate that running out of KVA space is causing the panics, > though I'm still learning the ropes of the BSD memory management > code and recognize that there are many interactions with different > portions of the memory management code that could have > unforeseen results. You need to look at the traceback, and the function where the panic is actually called from. Neither pmap_insert_entry() nor get_pv_entry() call panic directly. Once you understand who is calling who, you can understand why the panic is called, rather than merely returning an error to the caller. Basically, it boils down to the caller being unable to accept an allocation failure. > Regarding the other thread you mentioned, increasing > KVA_PAGES was just a way to make it possible to squeeze a > higher PV Entry limit out of the system because it would allow a > higher value for PMAP_SHPGPERPROC while still allowing the > system to boot. I have not determined if it "fixed the problem" > because I had to revert to an old kernel when MySQL wigged out > on boot, apparently due to the threading issue in 4.7 that shows up > with increased KVA_PAGES. I never got a chance to increase > PMAP_SHPGPERPROC after increasing KVA_PAGES because > MySQL is an important service on this system and I had to get it > back up and running. Yes. I also suggested how to crank up the initial number of pv_entry_t's in the first place, so that the allocation failure won't happen in the code path that calls panic() in event of an allocation failure it's not expecting. 8-). The MySQL problem is the threads mailbox issue. You can fix it the way I suggested, so you can use a larger KVA_PAGES, without the threading issue showing up. I just didn't go into detail on the lines of code to change to do it, but it's conceptually very easy. Frankly, I would suggest using FreeBSD pthreads, instead. > > What you meant to say is that it caused a Linux threads kernel > > module mailbox location problem for the user space Linux threads > > library. In other words, it's because you are using the Linux > > threads implementation, that you have this problem, not > > FreeBSD's pthreads. > > I may have misspoken in the previous thread about pthreads having > a problem when KVA_PAGES was increased. I was referencing a > previous thread in which the author stated pthreads had a problem > when KVA_PAGES was increased and had assumed that the > author knew what he was talking about. At any rate, this was > apparently patched and included into the RELENG_4 tree after 4.7- > RELEASE. It's not a FreeBSD problem, is what I was saying here. I just chose an ironic way to say it; sorry. 8-). > Also worth reiterating is that resource usage by Apache is the > source of the panics. The version I'm using is 1.3.27, so it doesn't > even make use of threading, at least not like Apache 2.0. I would > just switch to Apache 2.0, but it doesn't support all the modules we > need yet. Threads were only an issue with MySQL when > KVA_PAGES>256, which doesn't appear to be related to the > panics happening while KVA_PAGES=256. Resource usage should *NEVER* cause a panic. *NEVER*. The worst it should cause is load shedding (denial of service for new processes while being overworked by old processes). > > In any case, the problem you are having is because the uma_zalloc() > > (UMA) allocator is feeling KVA space pressure. > > > > One way to move this pressure somewhere else, rather than dealing with > > it in an area which results in a panic on you because the code was not > > properly retrofit for the limitations of UMA, is to decide to > > preallocate the UMA region used for the "PV ENTRY" zone. > > I haven't read up on that section of the source, but I'll go do so now > and determine if the changes you suggested would help in this > case. I know in some other posts you're a strong advocate for > mapping all physical RAM into KVA right up front rather than > messing around with some subset of physical RAM getting > mapped into KVA. That approach seems to make sense, at least > for large memory systems, if I understand all the dynamics of the > situation correctly. Likely they will move the problem to some other code path, and we can do this again, until some point, when instead of a panic, you will get an Apache log message telling you the fork failed. That's the ideal situation (IMO): no user space process, no matter how terrible, should be able to panic the kernel, no matter how high the load average goes. At that point, you will be safe from the global denial of service that you get following the panic, which is (IMO) "good enough". If you need more after that point, you can throw resources at the problem ("just add machines"). > > The way to do this is to modify /usr/src/sys/i386/i386/pmap.c > > at about line 122, where it says: > > > > #define MINPV 2048 > > If I read the code correctly in pmap.c, MINPV just guarantees that > the system will have at least *some* PV Entries available by > preallocating the KVA (28 bytes each on my system) for those PV > Entries specified by MINPV. See the section of > /usr/src/sys/i386/i386/pmap.c labelled "init the pv free list". I'm not > certain it makes a lot of sense to preallocate KVA space for > 11,113,502 PV Entries when we don't appear to be completely > KVA starved. It's to ensure an allocation of a PV Entry *DOES NOT FAIL*, even when you *are* completely starved. That's the whole point: to move the KVA space pressure off onto some *other* system that *also* does not preallocate its resources, and expect that that failure will turn into a benign "Apache: fork failed" log message, instead of being a panic. We want to get rid of the panic. Once we know what works around something, we can fix it later, but the important part is to know what the something *is*, first. Make sense? > As I understand it (and as you seem to have suggested), > increasing MINPV would only be useful if we were running out of > KVA due to other KVA consumers (like buffers, cache, mbuf > clusters, and etc.) before we could get enough PV Entries on the > "free" list. I don't believe that is what's happening here. It is. There is no other way the allocation can fail. See the traceback you are getting. Compile the kernel with DDB and BREAK_TO_DEBUGGER, and then when it blows up, get a backtrace. > Here's some sysctl's that are pertinent: > vm.zone_kmem_kvaspace: 350126080 > vm.kvm_size: 1065353216 > vm.kvm_free: 58720256 The kmem space is available memory not merely consumed by the kernel. The kvm_size is the size of the KVA space (4G minus what's reserved for user space). The kvm_free is the available kernel virtual memory. The name of "zone_kmem_kvaspace" is misleading, and doesn't correspond to "KVA space", which is the address space available for exclusive use of the kernel virtual address space. Also, these are not the values they have after the panic, because you can't run sysctl after a panic. 8-). If you could, you would see that kvm_free is zero, and the other two have not changed. > vm.zone_kmem_kvaspace indicates (if I understand it correctly) > that kmem_alloc() allocated about 334MB of KVA at boot. > vm.kvm_free indicates that KVM is only pressured after the system > has been running awhile. The sysctl's above were read after > running for about 90 minutes after a reboot during non-peak usage > hours. At that time, there were 199MB allocated to buffers, 49MB > allocated to cache, and 353MB wired. During peak usage, we will > typically have 199MB allocated to buffers, ~150MB allocated to > cache, and 500MB to 700MB wired. If I understand things > correctly, that would mean we're peaking around the 1GB KVM > mark and there's probably some recycling of memory used by > cache to free up KVM for other uses when necessary. It has to do with page mappings. But you must have one page for each 4M of memory. If you are out of pages to map pages, then it doesn't matter how many are free: you get no more mappings. Note that there are page mappings for pages in the kernel, and page mappings for pages in each of the user processes, and that these page s mapping pages aren't swappable, so you can run out (and you did!). When you run out, all additional attempts to allocate memory will fail, because you can't map it, even if you have it. Basically, the KVA_PAGES controls the KVA space size, which is basically how much total memory you can map into the kernel at one time. In your case, this is 1G. > However, I don't believe we're putting so much pressure on > KVA/KVM as to run out of 28 byte chunks for PV Entries to be > made. Assuming, once again, that I understand things correctly, if > we were putting that much pressure on KVA/KVM, cache would go > nearer to zero while the system attempted to make room for those > 28 byte PV Entries. Even during peak usage and just prior to > panic, the system still has over 100MB of cache showing. I have a > 'systat -vm' from a few seconds prior to one of the panics that > showed over 200MB of KVM free. I have to say you are wrong. Here's why: o If you are not running out of KVA space to map pages (pages available to map pages); AND o If you are not running out of pages for those pages to map (allocable kernel memory); AND o You are calling get_pv_entry(); AND o Therefore the uma_zalloc() is not failing THEN You aren't getting the panic you are seeing. BUT You are seeing a panic. So: something has to give: either your beliefs, or the evidence of your eyes. > So, I don't think the memory allocation in KVA/KVM associated > with PV Entries is the culprit of our panics. Here's a copy of one of > the panics and the trace I did on it. > > Fatal trap 12: page fault while in kernel mode [ ... ] > (/usr/src/sys/i386/i386/pmap.c:1636). > 1635 pv = get_pv_entry(); > 1636 pv->pv_va = va; get_pv_entry() returned 0, meaning it failed, and the code did not expect a failure; it expected it to block the process until it succeeded, or until the planet Earth was orbiting inside the heliopause of a great, big, Red Giant star. > Now, unless it does it somewhere else, there is no bounds > checking on pv_entry_count in that function. Yes. Exactly. It wasn't necessary before, because the entries were preallocated larger than they would ever need to be, and now they are allocated on the fly, and it's possible for the allocation to fail. SO... your workaround, which I gave you, is to *preallocate* them onto the free list, so that when you go to get one of them, uma_zalloc() is never called, because *there's always one there on the free list*. > So, when the > pv_entry_count exceeds the limit on PV Entries (pv_entry_max as > defined in pmap_init2() in pmap.c), it just panics with a "page not > present" when it goes to process line 1636 because it is > impossible for a page to be present for a PV Entry with that > pv_entry_count number being greater than pv_entry_max as > defined in pmap_init2() in pmap.c. You could check this by calling panic there. Or by setting vm.pmap.pv_entries large enough you continue allocating forever (I suggest max int). Or by preallocating it, and not worrying about the maximum, since it will never be enforced (my own suggestion, which reverts to historical behaviour). > I suppose, that if nobody is worried about this issue, then a quick > and dirty way to handle it would be to add bounds checking to > pv_entry_count in get_pv_entry() and if pv_entry_count is outside > the bounds, then produce a panic with a more informative > message. At least, with a useful panic, the problem would be > readily identified on other systems and you guys would have a > better opportunity to see how many other people run into this issue. No amount of system load should be able to result in a panic. Period. > Now, that's my synopsis of the problem, though I'm still a newb > with regard to my understanding of the BSD memory management > system. Based on the information I've given you, do you still think > this panic was caused by running out of KVA/KVM? If I'm wrong, > I'd love to know it so I can revise my understanding of what is going > on to cause the panic. I think it was. If you don't, then set vm.pmap.pv_entries to an outrageously large value in the boot loader, and see if the problem goes away (like you think) or if it persists (like I think). I will hazard a guess: it will not go away, because that tunable didn't just appear out of thin air, and what's happening is the return uma_zalloc(pvzone, M_NOWAIT); is failing, not because of the administrative limit (which was there in the zalloci() case, too), but because you are out of memory for it to allocate. If you care, extern the pvzone, and instrument failure returns from uma_zalloc() only for that zone. In other words, go to /usr/src/sys/vm/uma_core.c, and change uma_zalloc_internal to: extern uma_zone_t pvzone; /* from pmap.c */ static void * uma_zalloc_internal(uma_zone_t zone, void *udata, int flags) { uma_slab_t slab; void *item; item = NULL; /* * This is to stop us from allocating per cpu buckets while we're * running out of UMA_BOOT_PAGES. Otherwise, we would exhaust the * boot pages. */ if (bucketdisable && zone == bucketzone) return (NULL); #ifdef UMA_DEBUG_ALLOC printf("INTERNAL: Allocating one item from %s(%p)\n", zone->uz_name, zon e); #endif ZONE_LOCK(zone); slab = uma_zone_slab(zone, flags); if (slab == NULL) { ZONE_UNLOCK(zone); if (zone == pvzone) panic("pvzone: uma_zone_slab failed"); return (NULL); } item = uma_slab_alloc(zone, slab); ZONE_UNLOCK(zone); if (zone->uz_ctor != NULL) zone->uz_ctor(item, zone->uz_size, udata); if (flags & M_ZERO) bzero(item, zone->uz_size); return (item); } and uma_slab_alloc to: static __inline void * uma_slab_alloc(uma_zone_t zone, uma_slab_t slab) { void *item; u_int8_t freei; freei = slab->us_firstfree; slab->us_firstfree = slab->us_freelist[freei]; item = slab->us_data + (zone->uz_rsize * freei); slab->us_freecount--; zone->uz_free--; #ifdef INVARIANTS uma_dbg_alloc(zone, slab, item); #endif /* Move this slab to the full list */ if (slab->us_freecount == 0) { LIST_REMOVE(slab, us_link); LIST_INSERT_HEAD(&zone->uz_full_slab, slab, us_link); if (item == NULL && zone == pvzone) panic( "pvzone: full"); } if (item == NULL && zone == pvzone) panic( "pvzone: out of memory"); return (item); } > For now, I've solved the problem by limiting the number of Apache > processes that are allowed to run based on my calculations of how > many PV Entries are required by each child process, but it's > painful to have all that RAM and not be able to put it to use > because of an issue in the memory management code that shows > up on large memory systems (>2GB). IMHO, Apache shouldn't be > able crash an OS before it ever starts using swap. Agreed. You need to know *why* the panic happens. See the above. I think you can disable the "pvzone: full" panic by cranking up the limits in the loader, and you will still panic. > The only reason the problem doesn't show on systems with the > typical amounts of RAM (2GB or less) is that if those systems ran > Apache like we do, they'd spiral to a crash as swap usage > increased and eventually swap was completely filled. I doubt it. You aren't swapping at all, and you have gigs and gigs of swap. If you would crash at 4G, you would crash at 4G, even if half of it was swap. -- Terry From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 26 14:28: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 0F96F37B404 for ; Wed, 26 Mar 2003 14:28:51 -0800 (PST) Received: from garple.migus.org (pcp243391pcs.howard01.md.comcast.net [68.55.83.143]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0B2D543F75 for ; Wed, 26 Mar 2003 14:28:50 -0800 (PST) (envelope-from amigus@migus.org) Received: from migus.org (ganyopa.migus.org [192.168.4.2]) by garple.migus.org (8.12.7/8.12.7) with ESMTP id h2QMSlea037831 for ; Wed, 26 Mar 2003 17:28:48 -0500 (EST) (envelope-from amigus@migus.org) Message-ID: <3E8229A0.2030207@migus.org> Date: Wed, 26 Mar 2003 17:28:48 -0500 From: Adam Migus Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3b) Gecko/20030302 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-5.8 required=5.0 tests=USER_AGENT_MOZILLA_UA autolearn=ham version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Subject: usbd/devd 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, 26 Mar 2003 22:28:52 -0000 Folks, Some were chatting and think that adding some features to usb might be nice. Mentioned specifically was fixing it so it loads the right driver on the fly. :-) Also I was thinking we might be able to use mostly or all devd to catagorize devices in some sensable fashion, thus making the former, easier. Given overlap with NetBSD I was thinking extending with as little modifcation would be easier. So: 1) Any thoughts? 2) Anyone think we should start a project for this? If everyone would like, I can summarize what people say into something sensable and put it somewhere? Or if anyone else would like to... The general idea I have to rationalize the effort is that FreeBSD is now well equipped to adapt to the desktop. Great USB support is a very good step in the direction. Of course its a server, so I'm not sure how much effort is appropriate. Thus question 1)... :-) -- Adam Migus - Research Scientist Network Associates Laboratories (http://www.nailabs.com) TrustedBSD (http://www.trustedbsd.org) FreeBSD (http://www.freebsd.org) From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 26 15:47: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 B254837B404 for ; Wed, 26 Mar 2003 15:47:23 -0800 (PST) Received: from shared10.hosting.flyingcroc.net (shared10.hosting.flyingcroc.net [207.246.149.144]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3277E43F3F for ; Wed, 26 Mar 2003 15:47:23 -0800 (PST) (envelope-from dpk@dpk.net) Received: from shared10.hosting.flyingcroc.net (localhost [127.0.0.1]) h2QNlM8I040237 for ; Wed, 26 Mar 2003 15:47:22 -0800 (PST) Received: from localhost (dpk@localhost)id h2QNlMBX040234 for ; Wed, 26 Mar 2003 15:47:22 -0800 (PST) X-Authentication-Warning: shared10.hosting.flyingcroc.net: dpk owned process doing -bs Date: Wed, 26 Mar 2003 15:47:22 -0800 (PST) From: dpk X-Sender: dpk@shared10.hosting.flyingcroc.net To: hackers@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-7.3 required=5.0 tests=USER_AGENT_PINE,X_AUTH_WARNING autolearn=ham version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Subject: RFA: Keeping sysadmin programs resident/available 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, 26 Mar 2003 23:47:24 -0000 Hi all, I was wondering if anyone here knows of a way to force specific programs to stay resident (not swap) - specifically, I'm trying to see if there's a way one could keep sshd out of swap, and then execute a shell and some basic sysadmin tools (ps, top, etc), with the same swap-prevention, so when an end-user inevitably runs a system out of swap certain processes would still be available. (I'm thinking that it'd only need a few MB reserved, so the impact to the system would be minimal). So far my search has led me to mlock(), which seems to work on address ranges. In my tests I haven't actually been able to prevent pages from swapping, but I was able to cause the RSS of a test binary to grow by modifying rtld to mlock() everything it mmap()s. Obviously I'm grasping at straws there - idealy the solution would work on static executables as well. I've also heard of madvise - same results. Has anyone here dealt with this issue? Any tips/leads I could follow? - dpk From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 26 16:49: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 58FC437B404 for ; Wed, 26 Mar 2003 16:49:24 -0800 (PST) Received: from cauchy.axista.com (cauchy.axista.com [209.61.216.58]) by mx1.FreeBSD.org (Postfix) with ESMTP id E8DD543F93 for ; Wed, 26 Mar 2003 16:49:23 -0800 (PST) (envelope-from cce@cauchy.axista.com) Received: by cauchy.axista.com (Postfix, from userid 1000) id CB0196D0B1; Thu, 27 Mar 2003 01:07:09 +0000 (GMT) Date: Thu, 27 Mar 2003 01:07:09 +0000 From: "Clark C. Evans" To: hackers@freebsd.org Message-ID: <20030327010709.GB58770@doublegemini.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i Sender: cce+pub@clarkevans.com X-Spam-Status: No, hits=-6.4 required=5.0 tests=USER_AGENT_MUTT autolearn=ham version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Subject: trouble with DHCP and ipfw -1 fragment rule 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, 27 Mar 2003 00:49:25 -0000 Hello. I've got a box which is booting up just fine with an IP address, but as soon as I change my adapter to DHCP and reboot it hangs during the initial network setup. It seems that my router (a LinkSys 4 port DSL hub) is sending bad packets and triggering the -1 rule. Then, the DHCP process just hangs; I can do a CTRL+C to break out and continue setup. I'm not sure how to proceed debugging this bugger. Any suggestions? Clark From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 26 19:09:21 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 6D4C037B404 for ; Wed, 26 Mar 2003 19:09:21 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id AAC2743F75 for ; Wed, 26 Mar 2003 19:09:20 -0800 (PST) (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 h2R39JA7091650; Wed, 26 Mar 2003 20:09:19 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Wed, 26 Mar 2003 20:08:56 -0700 (MST) Message-Id: <20030326.200856.100423015.imp@bsdimp.com> To: amigus@migus.org From: "M. Warner Losh" In-Reply-To: <3E8229A0.2030207@migus.org> References: <3E8229A0.2030207@migus.org> X-Mailer: Mew version 2.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-9.9 required=5.0 tests=AWL,IN_REP_TO,REFERENCES autolearn=ham version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) cc: hackers@freebsd.org Subject: Re: usbd/devd 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, 27 Mar 2003 03:09:24 -0000 usbd is going away in FreeBSD. It will be replaced by devd. Some support is needed in the usb stack for this to happen, and there may be some hidden bugs in devd that might preclude it working with usb (but I kinda doubt it). It is on my list, but if someone wants to help out, that would be great. Warner From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 26 19:44: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 E56D737B404 for ; Wed, 26 Mar 2003 19:44:41 -0800 (PST) Received: from sabre.velocet.net (sabre.velocet.net [216.138.209.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id 01E3D43F3F for ; Wed, 26 Mar 2003 19:44:41 -0800 (PST) (envelope-from dgilbert@velocet.ca) Received: from trooper.velocet.ca (trooper.velocet.net [216.138.242.2]) by sabre.velocet.net (Postfix) with ESMTP id 89CB4139B3F; Wed, 26 Mar 2003 22:44:38 -0500 (EST) Received: by trooper.velocet.ca (Postfix, from userid 66) id 51A8774CF7; Wed, 26 Mar 2003 22:44:37 -0500 (EST) Received: by canoe.velocet.net (Postfix, from userid 101) id 8FC7C56762E; Wed, 26 Mar 2003 19:03:34 -0500 (EST) From: David Gilbert MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16002.16342.476020.510769@canoe.velocet.net> Date: Wed, 26 Mar 2003 19:03:34 -0500 To: Kirill Ponomarew In-Reply-To: <20030306145022.GA31433@krion> References: <007c01c2e3ef$3483d8a0$0229c80a@abtec412> <20030306145022.GA31433@krion> X-Mailer: VM 7.07 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid X-Spam-Status: No, hits=-25.1 required=5.0 tests=DATE_IN_PAST_03_06,EMAIL_ATTRIBUTION,IN_REP_TO, QUOTED_EMAIL_TEXT,RCVD_IN_UNCONFIRMED_DSBL,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) cc: freebsd-hackers@freebsd.org Subject: [hackers] Re: Realtek 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, 27 Mar 2003 03:44:43 -0000 >>>>> "Kirill" == Kirill Ponomarew writes: Kirill> Hi, On Thu, Mar 06, 2003 at 11:46:43AM -0300, Pablo Morales Kirill> wrote: >> Someone said that the realtek 8029 and 8139 ethernet cards are the >> worst cards ever made. My boss is planning to make a great buy of >> this cards for a communication project ( the reasons is obius, the >> cost of this cards ) I'm trying to persuade him to by 3com ethernet >> cards, but I need technical information to demostrate him that it's >> not a good inversion to buy those kind of cards. >> >> Can someone give a good explanation of that or at least where can I >> find information about it? Kirill> please read comments in /usr/src/sys/pci/if_rl.c It's worth noting that there's a scale to all this. The driver comments imply that the card will push 100Mb if you have enough power in the CPU ... defined as 400Mhz. Given the price of this card ... and the fact that less-than-400Mhz CPU's are rather rare, and that this is only an issue for high bandwidth applications ... the rl cards might fit for you. We use them extensively in workstations... even diskless. The reason being that with modern processors, they perform adequately ... and although they take up extra CPU ... CPUs are rather under-utilized resources in most workstations. Dave. -- ============================================================================ |David Gilbert, Velocet Communications. | Two things can only be | |Mail: dgilbert@velocet.net | equal if and only if they | |http://daveg.ca | are precisely opposite. | =========================================================GLO================ From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 26 21:38:22 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 ABE3637B404 for ; Wed, 26 Mar 2003 21:38:22 -0800 (PST) Received: from undead.dnn.ru (dnn.ru [212.158.164.253]) by mx1.FreeBSD.org (Postfix) with ESMTP id D1BF243F75 for ; Wed, 26 Mar 2003 21:38:20 -0800 (PST) (envelope-from alex@dynaweb.ru) Received: from dynaweb.ru (dynaweb.dnn.ru [212.158.164.112]) by undead.dnn.ru (8.9.3/8.9.3) with ESMTP id IAA58578 for ; Thu, 27 Mar 2003 08:40:39 +0300 (MSK) (envelope-from alex@dynaweb.ru) Message-ID: <3E828ECC.1040903@dynaweb.ru> Date: Thu, 27 Mar 2003 08:40:28 +0300 From: Alex User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: FreeBSD hackers list References: <007c01c2e3ef$3483d8a0$0229c80a@abtec412> <20030306145022.GA31433@krion> <16002.16342.476020.510769@canoe.velocet.net> X-Spam-Status: No, hits=-11.8 required=5.0 tests=AWL,EMAIL_ATTRIBUTION,HTML_10_20,HTML_MESSAGE,REFERENCES, USER_AGENT_MOZILLA_UA autolearn=ham version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: Re: [hackers] Re: Realtek X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: alex@dynaweb.ru List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2003 05:38:25 -0000 Hi Kirill! That's a real myth about Realtek :0) We're using them on all our FreeBSD machines for over 5 years without any problems. Driver is working fine. Speed and reliability is OK. So I for one can even offer to choose them instead of 3COM as in Russia you can easily get 2 from the 3 3COM cards that is not 3COM indeed :0) Not so for cheap Realteks :0) Good luck David Gilbert wrote: >>>>>>"Kirill" == Kirill Ponomarew writes: >>>>>> >>>>>> > >Kirill> Hi, On Thu, Mar 06, 2003 at 11:46:43AM -0300, Pablo Morales >Kirill> wrote: > > > >>>Someone said that the realtek 8029 and 8139 ethernet cards are the >>>worst cards ever made. My boss is planning to make a great buy of >>>this cards for a communication project ( the reasons is obius, the >>>cost of this cards ) I'm trying to persuade him to by 3com ethernet >>>cards, but I need technical information to demostrate him that it's >>>not a good inversion to buy those kind of cards. >>> >>>Can someone give a good explanation of that or at least where can I >>>find information about it? >>> >>> > >Kirill> please read comments in /usr/src/sys/pci/if_rl.c > >It's worth noting that there's a scale to all this. The driver >comments imply that the card will push 100Mb if you have enough power >in the CPU ... defined as 400Mhz. Given the price of this card >... and the fact that less-than-400Mhz CPU's are rather rare, and that >this is only an issue for high bandwidth applications ... the rl cards >might fit for you. > >We use them extensively in workstations... even diskless. The reason >being that with modern processors, they perform adequately ... and >although they take up extra CPU ... CPUs are rather under-utilized >resources in most workstations. > >Dave. > > > From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 27 01:21: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 6C0FF37B404 for ; Thu, 27 Mar 2003 01:21:06 -0800 (PST) Received: from mail.halplant.com (ip68-98-167-210.nv.nv.cox.net [68.98.167.210]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6B42543F3F for ; Thu, 27 Mar 2003 01:21:05 -0800 (PST) (envelope-from A.J.Caines@halplant.com) Received: by mail.halplant.com (Postfix, from userid 1001) id C92E3BD; Thu, 27 Mar 2003 04:21:04 -0500 (EST) Date: Thu, 27 Mar 2003 04:21:04 -0500 From: Andrew J Caines To: hackers@freebsd.org Message-ID: <20030327092104.GS19108@hal9000.halplant.com> Mail-Followup-To: hackers@freebsd.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: H.A.L. Plant X-PGP-Fingerprint: C59A 2F74 1139 9432 B457 0B61 DDF2 AA61 67C3 18A1 X-Powered-by: FreeBSD 4.8-RC X-URL: http://halplant.com:88/ X-Yahoo-Profile: AJ_Z0 Importance: Normal User-Agent: Mutt/1.5.3i X-Spam-Status: No, hits=-26.0 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_MUTT autolearn=ham version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Subject: Re: RFA: Keeping sysadmin programs resident/available X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Andrew J Caines List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2003 09:21:10 -0000 dpk, > I was wondering if anyone here knows of a way to force specific programs > to stay resident (not swap) Back when this was a good idea, setting the sticky bit would do the trick, but reading sticky(8) and chmod(2), it appears that it's ignored on anything except directories. How about sshd.ko? [I've no idea if this suggestion is even sane] -Andrew- -- _______________________________________________________________________ | -Andrew J. Caines- Unix Systems Engineer A.J.Caines@halplant.com | | "They that can give up essential liberty to obtain a little temporary | | safety deserve neither liberty nor safety" - Benjamin Franklin, 1759 | From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 27 01:45: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 BB62837B401 for ; Thu, 27 Mar 2003 01:45:52 -0800 (PST) Received: from park.rambler.ru (park.rambler.ru [81.19.64.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 02C7543FA3 for ; Thu, 27 Mar 2003 01:45:49 -0800 (PST) (envelope-from is@rambler-co.ru) Received: from is.park.rambler.ru (is.park.rambler.ru [81.19.64.102]) by park.rambler.ru (8.12.6/8.12.6) with ESMTP id h2R9jfmF091067; Thu, 27 Mar 2003 12:45:41 +0300 (MSK) Date: Thu, 27 Mar 2003 12:45:41 +0300 (MSK) From: Igor Sysoev X-Sender: is@is To: freebsd-hackers@FreeBSD.ORG In-Reply-To: <3E8163C5.3024.3C0A1A9@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-25.5 required=5.0 tests=AWL,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Subject: Re: shared mem and panics when out of PV Entries 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, 27 Mar 2003 09:45:55 -0000 On Wed, 26 Mar 2003, Andrew Kinney wrote: > Eventually, I may be forced to turn off KeepAlive and make use of If you disable keepalive I believe clients would not see much difference. Keepalive is a good feature for clients but it should be enabled if you have enough resources to support it. It can be enabled on light-weight server that uses kqueue and designed to handle the tens of thousands simultaneous connections. An overhead per connection would be several tens of kilobytes or less. A plain Apache without heavy modules spends hunderds of kilobytes of physical memory per connection. mod_perl spends megabytes or tens of megabytes of phycical memory per connection. In your untypical case Apache spends about 1.5M per connection of a kernel memory. > FreeBSD's accept filters My measurements on the loaded enough web sites show that the accept filters allow to save about 5-10% of Apaches. Of course they are the most effective without keepalives. But be sure use them only in between 4.1.1-RELEASE - 4.4-RELEASE, or 4.6-RELEASE and above. 4.5-RELEASE and -STABLE around have the syncache related bug that leads to DoS. > or put in a reverse proxy as you recommend. I can even recommend you one proxy - mod_accel - http://sysoev.ru/en/ > For now, though, we are serving the whole gammut > from this Apache. Static pages, images, mod_perl, PHP, > Apache::ASP, and most anything else a customer might want or > need to serve from a web server. I know it isn't the most efficient > way to use Apache, but nobody has any complaints about > performance at this point. You have too much overhead per connection and if the worload would grow you will have perfomance problems. Igor Sysoev http://sysoev.ru/en/ From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 27 02:43: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 0F01A37B401; Thu, 27 Mar 2003 02:43:39 -0800 (PST) Received: from hotmail.com (bay2-dav16.bay2.hotmail.com [65.54.246.120]) by mx1.FreeBSD.org (Postfix) with ESMTP id 54F0043FAF; Thu, 27 Mar 2003 02:43:38 -0800 (PST) (envelope-from sukhbinders@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 27 Mar 2003 02:43:38 -0800 Received: from 219.94.125.200 by bay2-dav16.bay2.hotmail.com with DAV; Thu, 27 Mar 2003 10:43:37 +0000 X-Originating-IP: [219.94.125.200] X-Originating-Email: [sukhbinders@hotmail.com] From: "Sukhbinder Singh" To: "John Vender" , , References: <370EFEC0-5F79-11D7-B4F7-00039369D83A@jmv.com.au> Date: Thu, 27 Mar 2003 16:57:20 +0800 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.00.2615.200 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Message-ID: X-OriginalArrivalTime: 27 Mar 2003 10:43:38.0224 (UTC) FILETIME=[B9895700:01C2F44D] X-Spam-Status: No, hits=-12.9 required=5.0 tests=ORIGINAL_MESSAGE,QUOTED_EMAIL_TEXT,REFERENCES autolearn=ham version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) cc: sukhbinders@hotmail.com Subject: Re: FreeBSD Installation Problems 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, 27 Mar 2003 10:43:41 -0000 First, I made the 2 image floppy disk for the 2 image files by downloading them from ftp.freebsd.org. These 2 files are kern.flp and msfroot.flp. I also downloaded and made an image disk for drvivers.flp just to download the drivers at the installation process. Then I reboot the computer and I put the kern.flp disk. Then the computer automatically reads drive a: and process this disk. Then it comes to a point where it asks me to insert MFS root floppy and press enter by prompting me a message like " Please insert MFS root floppy and press enter: " I then insert the MFS root floppy disk and pressed enter and the computer starts processing this diskette then it comes to a point where it displays a message like "Hit [Enter] to boot immediately or press anykey for prompt" while this installation program counts down from 10 to 0 and automatically boots after reaching 0. Then, the next message that I get is "Would you like to load kernel modules from the driver floppy ? Yes No", I pressed yes and I loaded the drivers which I had copied from the drivers floppy from the driver.flp file from ftp.freebsd.org. Then I get a message like "probing devices please wait ......" and then it pops up a window called Sysinstall Main Menuand it gives me several options to select the installation type. I selected the "Standard" installation type and pressed enter to proceed to the next step. After doing this I get a message saying "in the next menu, you will need to set up a dos style ("fdisk") partitioning scheme for your hard disk. After pressing enter at this prompt it takes me to the Fdisk Partition Editor. Where I have 2 MB of my hard disk space devoted to FreeBSD. I made the dos partition active, by moving the cursor to the partition and pressing S to set it Bootable. Then I press Q which means finished and moved to the next screen. In the next screen I got the Boot Manager Window to install the Boot Manager. Then, I moved the highlighted cursor to the "install the FreeBSD Boot Manager" and pressed enter. Then the installation program takes me to another message window where it states that "Now you need to create a BSD Partition inside the FDisk partition just created ...." I pressed enter to proceed. Now the installation program takes me to the FreeBSD Disklabel Editor window. Here the highlighted cursor is at top most area of the screen at Disk : ad 0 partition name : ad 0S2 Free : 3924585 blocks (1916MB). I pressed A which means auto at the time when the highlighted cursor was at the top most area of the screen at Disk : ad 0 partition name : ad 0S2 Free : 3924585 blocks (1916MB). By pressing A at this point I get the partition for FreeBSD partitioned into its own chunks. These pieces were for / ("root), /swap , /var, /usr. The root partition is assigned 256 MB, the swap partition is assigned 176 MB, the /var partition is assigned 256 MB, the /tmp partition is assigned 256 MB and the /usr partition is assigned 991 MB respectively. Then from here again I press Q which means finish and I moved to the next screen. The next screen is called the "Choice Distribution" window here I selected the minimal option which stands for the smallest configuration possible and pressed ok. Then it takes me to the "choice installation media" window. I selected FTP from here and pressed enter. Then it takes me to the "Please select a FeeeBSD FTP distribution site" and I selected the primary site called ftp.freebsd.org and pressed enter. Then the installation program took me to the "Network Interface Information Required" window. Where here I selected the PPP option. Then after selecting the PPP option and pressing enter I was prompted another message window called the "User Confirmation Requested" window. When it ask me "DO you want to try IPv6 configuration of the interface? " I selected no and pressed enter to proceeded to the next screen. Then in the next screen I get another window with a request message like "Do you want to try DHCP configuration at the Interface ? Yes No ". I selected No and proceeded to the next level of the installation process. In this next level, I get a big screen called the "Network Configuration" window to proceed with my ftp. I think or suspect this is where the problem is. This window has 7 fields which it requires me to enter. These 7 fields are host, domain, ipv4 gateway, name server, IPv4 address netmask :, extra option to ifconfig. I do not know any information regarding any of the fields. If I leave all of these fields empty, the installation program prompts me with an error message like "must specify a host name of some sort !" Then I just entered a host name for the host, like foo.com and pressed enter to proceed all the way through the 7 fields to the OK button. Then, the installation program brings me to another window to enter the IP address of my service provider and then it prompts another window asking me "Does your ISP support PAP or CHAP ppp logins ? Yes No" I pressed Yes and it requested me to enter the login name for my service provider. I then entered my login name, then it requested me to enter my password to my service provider and I entered my password to my service provider and then it requested the provider's login phone number and I entered the provider login phone number. Then this installation program asks me if my telephone line supports tone dialing ? I selected yes and pressed enter and proceeded further. Then, the installation program brings me to a window saying PPP command is already started on VTY3. I pressed enter at the OK highlighted button and then I get the final message saying "Couldn't open FTP connection to ftp.freebsd.org: Undefined error : 0." Then at this point I get another message saying killing previous PPP process 76 and after pressing enter here I get another message saying "unable to adjust your media configuration and try again : " This is my installation process. It fails to download freebsd automatically from the freebsd ftp site like it should. Any help will be helpful. thanks, Sukh. ----- Original Message ----- From: John Vender To: Sukhbinder Singh Sent: Wednesday, March 26, 2003 6:53 PM Subject: Re: FreeBSD Installation Problems > On Wednesday, March 26, 2003, at 08:53 PM, Sukhbinder Singh wrote: > > > Hello, > > > > I am trying to install FreeBSD into my personal computer, > > however I am receiving error messages during the course of my > > installation. When I am trying to install using the floppy method at > > the final prompt where the istallation program requests me to put in > > floppy disk in drive a and press enter. After putting in the disk and > > pressing enter I receive a warning or error message like "Error > > mounting floppy fd0 (/dev/fd0) on /dist: Invalid argument". > > > > When I try to install it via FTP, at the end of the > > installation procedure I receive a message like "Couldn't open FTP > > connection to ftp.freebsd.org: undefined error : 0" Can someone > > please help me troubleshoot this problems which I had been facing with > > the installation of FreeBSD into my personal computer. > > > > Thanks, > > from what you write I assume you made the installation floppies and the > first floppy boots the system and starts the installation process. > Please describe step by step what what is happening while you are trying > to do the install from the point the system boots and starts the > installation process including the options you select at any point where > you are asked to select options. > > Cheers...John > > From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 27 03:31: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 156C637B401 for ; Thu, 27 Mar 2003 03:31:46 -0800 (PST) Received: from office.advantagecom.net (office.advantagecom.net [207.109.186.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4B3B843F75 for ; Thu, 27 Mar 2003 03:31:45 -0800 (PST) (envelope-from andykinney@advantagecom.net) Received: from SCSI-MONSTER (andy.advantagecom.net [207.109.186.200] (may be forged)) by office.advantagecom.net (8.9.3/8.9.3) with ESMTP id DAA22305; Thu, 27 Mar 2003 03:31:39 -0800 From: "Andrew Kinney" Organization: Advantagecom Networks, Inc. To: Terry Lambert Date: Thu, 27 Mar 2003 03:31:48 -0800 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Message-ID: <3E8270A4.12784.2592605@localhost> Priority: normal In-reply-to: <3E822424.C0D6E8E9@mindspring.com> X-mailer: Pegasus Mail for Win32 (v3.12c) X-Spam-Status: No, hits=-21.8 required=5.0 tests=AWL,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES autolearn=ham version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) cc: freebsd-hackers@FreeBSD.ORG Subject: Re: shared mem and panics when out of PV Entries X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: andykinney@advantagecom.net List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2003 11:31:47 -0000 On 26 Mar 2003, at 14:05, Terry Lambert wrote: > It's to ensure an allocation of a PV Entry *DOES NOT FAIL*, even > when you *are* completely starved. That's the whole point: to > move the KVA space pressure off onto some *other* system that > *also* does not preallocate its resources, and expect that that > failure will turn into a benign "Apache: fork failed" log message, > instead of being a panic. > > We want to get rid of the panic. > > Once we know what works around something, we can fix it later, > but the important part is to know what the something *is*, first. > > Make sense? Ok. Now it makes perfect sense. I guess I didn't understand the point of preallocating via MINPV until now. My thanks to you and Mr. Sysoev for all the assistance you've provided. In particular, thanks for the in depth lesson in memory management. It's not like there's much in the way of documentation out there, so all the information and explanations that you have provided have given me much more insight into the BSD memory mangement system than I had before. At this point, I'm not so certain that I was right with regards to the root cause of the panic as you have provided a very thorough argument to the contrary. I do think it is sound advice to take the approach you have suggested even if for no other reason than to determine definitively what is the root cause of the panic. So, I think I'll do that little preallocation trick you showed me, turn on crash dumps (4GB crash dumps are a royal pain, but useful in this case), and unleash Apache. If you're right, then I'll get some other panic or non-panic error message at some point. I'll let you know how it goes. It may be a few days until I get back to the list with results since I have to schedule this kind of work in advance due to the downtime involved. As far as MySQL goes, I'll look into compiling it with FreeBSD native threads and replacing the prepackaged binary we're currently using. That should allow me to bump up KVA_PAGES without incident if I understand correctly. That appears to be much easier than recoding the Linux threads module. Sincerely, Andrew Kinney President and Chief Technology Officer Advantagecom Networks, Inc. http://www.advantagecom.net From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 27 03:32: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 281C237B401 for ; Thu, 27 Mar 2003 03:32:24 -0800 (PST) Received: from gw.nectar.cc (gw.nectar.cc [208.42.49.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5DA2D43FA3 for ; Thu, 27 Mar 2003 03:32:23 -0800 (PST) (envelope-from nectar@celabo.org) Received: from madman.celabo.org (madman.celabo.org [10.0.1.111]) by gw.nectar.cc (Postfix) with ESMTP id CF88B69; Thu, 27 Mar 2003 05:32:22 -0600 (CST) Received: by madman.celabo.org (Postfix, from userid 1001) id B480A78C43; Thu, 27 Mar 2003 05:32:22 -0600 (CST) Date: Thu, 27 Mar 2003 05:32:22 -0600 From: "Jacques A. Vidrine" To: Tak Pui LOU Message-ID: <20030327113222.GD98283@madman.celabo.org> Mail-Followup-To: "Jacques A. Vidrine" , Tak Pui LOU , freebsd-hackers@freebsd.org References: <20030326124420.388DE10160@ws-tor-0004.procergs> <20030326150152.GG33671@madman.celabo.org> <20030326102330.V892@man-97-187.ResHall.Berkeley.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030326102330.V892@man-97-187.ResHall.Berkeley.EDU> X-Url: http://www.celabo.org/ User-Agent: Mutt/1.5.3i-ja.1 X-Spam-Status: No, hits=-32.0 required=5.0 tests=AWL,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT autolearn=ham version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) cc: freebsd-hackers@freebsd.org Subject: Re: pam_ldap... 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, 27 Mar 2003 11:32:25 -0000 On Wed, Mar 26, 2003 at 10:25:48AM -0800, Tak Pui LOU wrote: > Does that mean there will be official support for nss_ldap in FBSD 5.1? It is expected that a FreeBSD Port of nss_ldap will be available by FreeBSD 5.1. > Is > it on the -current right now? I would like to test it. It is not in -CURRENT yet. Cheers, -- Jacques A. Vidrine http://www.celabo.org/ NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos jvidrine@verio.net . nectar@FreeBSD.org . nectar@kth.se From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 27 07:58: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 3CC2D37B401 for ; Thu, 27 Mar 2003 07:58:36 -0800 (PST) Received: from c81-48.cable.netissat.bg (c81-48.cable.netissat.bg [213.130.81.48]) by mx1.FreeBSD.org (Postfix) with ESMTP id 79D1E43F75 for ; Thu, 27 Mar 2003 07:58:34 -0800 (PST) (envelope-from vladimir.terziev@sun-fish.com) Received: from sun-fish.com (postfix@fs.cmotd.com [192.168.33.253]) h2RDnSQo019335 for ; Thu, 27 Mar 2003 14:49:29 +0100 (CET) Received: from 127.0.0.1 (localhost [127.0.0.1]) by antivirus.software (Postfix) with SMTP id 30D5014A07 for ; Thu, 27 Mar 2003 14:49:27 +0100 (CET) Received: from daemon.cmotd.com (daemon.cmotd.com [192.168.33.170]) by sun-fish.com (Postfix) with SMTP id 5D66A14A05 for ; Thu, 27 Mar 2003 14:49:26 +0100 (CET) Date: Thu, 27 Mar 2003 15:49:27 +0200 From: Vladimir Terziev To: hackers@freebsd.org Message-Id: <20030327154927.7273f224.vlady@sun-fish.com> Organization: SunFish Ltd. X-Mailer: Sylpheed version 0.8.6claws (GTK+ 1.2.10; ) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Subject: Parallel port cards support 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, 27 Mar 2003 15:58:38 -0000 Hi, does FreeBSD support parallel-port PCI cards? If the answer is ``yes'', via which driver? regards, Vladimir From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 28 10:38:58 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 618) id 7B2DB37B401; Fri, 28 Mar 2003 10:38:58 -0800 (PST) To: hackers@freebsd.org Date: Fri, 28 Mar 2003 10:38:58 -0800 (PST) X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20030328183858.7B2DB37B401@hub.freebsd.org> From: wpaul@FreeBSD.ORG (Bill Paul) X-Spam-Status: No, hits=-3.1 required=5.0 tests=AWL version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) cc: ticso@cicely9.cicely.de Subject: Ax88172 vs FreeBSD USB stack 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, 28 Mar 2003 18:38:59 -0000 So. I picked up a Linksys USB200M USB 2.0 ethernet adapter that uses the ASIX Electronics AX88172 chip, and I started cobbling together a driver. This chip uses a series of vendor specific commands to do things like read/write the MII management interface on the MAC, read/write the SROM, set the RX filter, multicast hash table, etc. I can do all this no problem. The Linksys NIC uses a RealTek 8201L PHY, and I can attach it and negotiate a link. However I can't send or receive any packets. Like all the other USB NICs, packet transfer is supposed to done via bulk in/bulk out endpoints, and I can open these endpoints and initiate transfers just fine, but nothing ever happens. Transmit attempts don't yield any packets on the wire, and I never get any RX transfer completions. (I can see the activity LED on the NIC blink when a frame arrives though.) One thing I have not attempted to do yet (but may try this weekend) is to directly read the RX or TX SRAM (there are commands to let you do this). Frankly, I'm a bit stumped. It looks as though I'm doing everything correctly, but I can't explain why the bulk transfers don't work. Clearly, the control endpoint works, since I can issue commands. There doesn't appear to be any special command that one has to issue to enable/disable the receiver or transmitter on the MAC. I have only one possible explanation. The manual for the AX88172 (http://www.freebsd.org/~wpaul/ASIX/Ax88172.PDF) says the following: "The AX88172 supports 2 interfaces, the interface 0 is Data Interface and interface 1 is for Communication interface." However the USB stack disagrees with the manual on this point: it steadfastly insists that configuration 1 has only 1 interface. So my question, for any USB gurus out there, is: is it possible that the USB stack is wrong on this point, and I really need to be using interface 1 for bulk in/out transfers? I'm a little suspicious at this point, because the stack can't seem to even read the device ID string correctly. (It identifies the chip only as "vendor 0x77b, device 0x2226".) -Bill -- ============================================================================= -Bill Paul (510) 749-2329 | Senior Engineer, Master of Unix-Fu wpaul@windriver.com | Wind River Systems ============================================================================= "If stupidity were a handicap, you'd have the best parking spot." ============================================================================= From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 28 10:57: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 17C8F37B401; Fri, 28 Mar 2003 10:57:23 -0800 (PST) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 67C1D43F93; Fri, 28 Mar 2003 10:57:21 -0800 (PST) (envelope-from ticso@cicely9.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.8/8.12.8) with ESMTP id h2SIv1gt095727 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Fri, 28 Mar 2003 19:57:15 +0100 (CET) (envelope-from ticso@cicely9.cicely.de) Received: from cicely9.cicely.de (cicely9.cicely.de [IPv6:3ffe:400:8d0:301:210:5aff:fe30:1c1a]) by cicely5.cicely.de (8.12.8/8.12.8) with ESMTP id h2SIuvGA050896 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Mar 2003 19:56:58 +0100 (CET) (envelope-from ticso@cicely9.cicely.de) Received: from cicely9.cicely.de (localhost [127.0.0.1]) by cicely9.cicely.de (8.12.8/8.12.8) with ESMTP id h2SIuqkv033668; Fri, 28 Mar 2003 19:56:53 +0100 (CET) (envelope-from ticso@cicely9.cicely.de) Received: (from ticso@localhost) by cicely9.cicely.de (8.12.8/8.12.8/Submit) id h2SIupCg033667; Fri, 28 Mar 2003 19:56:52 +0100 (CET) Date: Fri, 28 Mar 2003 19:56:50 +0100 From: Bernd Walter To: Bill Paul Message-ID: <20030328185650.GK23168@cicely9.cicely.de> References: <20030328183858.7B2DB37B401@hub.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030328183858.7B2DB37B401@hub.freebsd.org> X-Operating-System: FreeBSD cicely9.cicely.de 5.0-CURRENT alpha User-Agent: Mutt/1.5.3i X-Spam-Status: No, hits=-32.5 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_MUTT autolearn=ham version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) cc: ticso@cicely9.cicely.de cc: hackers@FreeBSD.ORG Subject: Re: Ax88172 vs FreeBSD USB stack 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: Fri, 28 Mar 2003 18:57:26 -0000 On Fri, Mar 28, 2003 at 10:38:58AM -0800, Bill Paul wrote: > > So. I picked up a Linksys USB200M USB 2.0 ethernet adapter that uses > the ASIX Electronics AX88172 chip, and I started cobbling together a > driver. This chip uses a series of vendor specific commands to do > things like read/write the MII management interface on the MAC, > read/write the SROM, set the RX filter, multicast hash table, etc. > I can do all this no problem. The Linksys NIC uses a RealTek 8201L > PHY, and I can attach it and negotiate a link. > > However I can't send or receive any packets. > > Like all the other USB NICs, packet transfer is supposed to done > via bulk in/bulk out endpoints, and I can open these endpoints > and initiate transfers just fine, but nothing ever happens. Transmit > attempts don't yield any packets on the wire, and I never get any > RX transfer completions. (I can see the activity LED on the NIC > blink when a frame arrives though.) One thing I have not attempted > to do yet (but may try this weekend) is to directly read the RX or > TX SRAM (there are commands to let you do this). > > Frankly, I'm a bit stumped. It looks as though I'm doing everything > correctly, but I can't explain why the bulk transfers don't work. > Clearly, the control endpoint works, since I can issue commands. There > doesn't appear to be any special command that one has to issue to > enable/disable the receiver or transmitter on the MAC. > > I have only one possible explanation. The manual for the AX88172 > (http://www.freebsd.org/~wpaul/ASIX/Ax88172.PDF) says the following: > > "The AX88172 supports 2 interfaces, the interface 0 is Data Interface > and interface 1 is for Communication interface." If that is true - the device has a strange design. Normaly devices use single interfaces with multiple commucations channels. An interface in USB wording is something like a virtual device - similar to functions on pci. E.g. you can have an umass device on interface 0 and a keyboard on interface 1. The FreeBSD USB stack supports mutltiple interfaces, but currently doesn't support probing different drivers for different interfaces on the same device. However you can try usbctl from usbutils to get an overview of the device. I have made a port, it is actually being reviewed by a port commiter, which you can get on: http://www.cosmo-project.de/~bernd/usbutil.tgz > However the USB stack disagrees with the manual on this point: it > steadfastly insists that configuration 1 has only 1 interface. So > my question, for any USB gurus out there, is: is it possible that > the USB stack is wrong on this point, and I really need to be > using interface 1 for bulk in/out transfers? I'm a little suspicious > at this point, because the stack can't seem to even read the > device ID string correctly. (It identifies the chip only as "vendor > 0x77b, device 0x2226".) Strange - let us see what usbctl says - it never failed for me. BTW: I doubt that USB 1.x vs USB 2.0 make a difference in the problem you are seeing, but in case you want to test later. The EHCI patch is available under: http://www.cosmo-project.de/~bernd/ehci.patch It is currently not tested against any device, but the controller probes fine and scanning the root hub (without devices) did not fail. -- B.Walter BWCT http://www.bwct.de ticso@bwct.de info@bwct.de From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 28 11:23: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 5C91637B407; Fri, 28 Mar 2003 11:23:23 -0800 (PST) Received: from scl8owa02.int.exodus.net (scl8out02.exodus.net [66.35.230.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id E26594414B; Fri, 28 Mar 2003 11:21:08 -0800 (PST) (envelope-from Maksim.Yevmenkin@cw.com) Received: from scl8owa01.int.exodus.net ([66.35.230.241]) by scl8owa02.int.exodus.net with Microsoft SMTPSVC(5.0.2195.5329); Fri, 28 Mar 2003 11:20:25 -0800 Received: from exodus.net ([165.193.27.35]) by scl8owa01.int.exodus.net over TLS secured channel with Microsoft SMTPSVC(5.0.2195.5329); Fri, 28 Mar 2003 11:20:25 -0800 Message-ID: <3E849FA7.1000400@exodus.net> Date: Fri, 28 Mar 2003 11:16:55 -0800 From: Maksim Yevmenkin User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021126 X-Accept-Language: en-us, ru, en MIME-Version: 1.0 To: ticso@cicely.de References: <20030328183858.7B2DB37B401@hub.freebsd.org> <20030328185650.GK23168@cicely9.cicely.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Mar 2003 19:20:25.0101 (UTC) FILETIME=[157D0BD0:01C2F55F] X-Spam-Status: No, hits=-22.1 required=5.0 tests=AWL,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA autolearn=ham version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) cc: Bill Paul cc: hackers@freebsd.org cc: ticso@cicely9.cicely.de Subject: Re: Ax88172 vs FreeBSD USB stack 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, 28 Mar 2003 19:23:27 -0000 Just FYI ng_ubt(4) (/sys/netgraph/bluetooth/drivers/ubt) driver (Bluetooth USB devices) makes use of two interfaces. thanks, max Bernd Walter wrote: > On Fri, Mar 28, 2003 at 10:38:58AM -0800, Bill Paul wrote: > >>So. I picked up a Linksys USB200M USB 2.0 ethernet adapter that uses >>the ASIX Electronics AX88172 chip, and I started cobbling together a >>driver. This chip uses a series of vendor specific commands to do >>things like read/write the MII management interface on the MAC, >>read/write the SROM, set the RX filter, multicast hash table, etc. >>I can do all this no problem. The Linksys NIC uses a RealTek 8201L >>PHY, and I can attach it and negotiate a link. >> >>However I can't send or receive any packets. >> >>Like all the other USB NICs, packet transfer is supposed to done >>via bulk in/bulk out endpoints, and I can open these endpoints >>and initiate transfers just fine, but nothing ever happens. Transmit >>attempts don't yield any packets on the wire, and I never get any >>RX transfer completions. (I can see the activity LED on the NIC >>blink when a frame arrives though.) One thing I have not attempted >>to do yet (but may try this weekend) is to directly read the RX or >>TX SRAM (there are commands to let you do this). >> >>Frankly, I'm a bit stumped. It looks as though I'm doing everything >>correctly, but I can't explain why the bulk transfers don't work. >>Clearly, the control endpoint works, since I can issue commands. There >>doesn't appear to be any special command that one has to issue to >>enable/disable the receiver or transmitter on the MAC. >> >>I have only one possible explanation. The manual for the AX88172 >>(http://www.freebsd.org/~wpaul/ASIX/Ax88172.PDF) says the following: >> >>"The AX88172 supports 2 interfaces, the interface 0 is Data Interface >>and interface 1 is for Communication interface." > > > If that is true - the device has a strange design. > Normaly devices use single interfaces with multiple commucations > channels. > An interface in USB wording is something like a virtual device - > similar to functions on pci. > E.g. you can have an umass device on interface 0 and a keyboard on > interface 1. > The FreeBSD USB stack supports mutltiple interfaces, but currently > doesn't support probing different drivers for different interfaces on > the same device. > > However you can try usbctl from usbutils to get an overview of the > device. > I have made a port, it is actually being reviewed by a port commiter, > which you can get on: http://www.cosmo-project.de/~bernd/usbutil.tgz > > >>However the USB stack disagrees with the manual on this point: it >>steadfastly insists that configuration 1 has only 1 interface. So >>my question, for any USB gurus out there, is: is it possible that >>the USB stack is wrong on this point, and I really need to be >>using interface 1 for bulk in/out transfers? I'm a little suspicious >>at this point, because the stack can't seem to even read the >>device ID string correctly. (It identifies the chip only as "vendor >>0x77b, device 0x2226".) > > > Strange - let us see what usbctl says - it never failed for me. > > BTW: I doubt that USB 1.x vs USB 2.0 make a difference in the problem > you are seeing, but in case you want to test later. > The EHCI patch is available under: > http://www.cosmo-project.de/~bernd/ehci.patch > It is currently not tested against any device, but the controller > probes fine and scanning the root hub (without devices) did not fail. > From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 28 11:39: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 1821A37B66A; Fri, 28 Mar 2003 11:39:46 -0800 (PST) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1D31F4402A; Fri, 28 Mar 2003 11:37:44 -0800 (PST) (envelope-from ticso@cicely9.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.8/8.12.8) with ESMTP id h2SJbTgt096712 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Fri, 28 Mar 2003 20:37:37 +0100 (CET) (envelope-from ticso@cicely9.cicely.de) Received: from cicely9.cicely.de (cicely9.cicely.de [IPv6:3ffe:400:8d0:301:210:5aff:fe30:1c1a]) by cicely5.cicely.de (8.12.8/8.12.8) with ESMTP id h2SJbOGA051205 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Mar 2003 20:37:25 +0100 (CET) (envelope-from ticso@cicely9.cicely.de) Received: from cicely9.cicely.de (localhost [127.0.0.1]) by cicely9.cicely.de (8.12.8/8.12.8) with ESMTP id h2SJbNkv033771; Fri, 28 Mar 2003 20:37:24 +0100 (CET) (envelope-from ticso@cicely9.cicely.de) Received: (from ticso@localhost) by cicely9.cicely.de (8.12.8/8.12.8/Submit) id h2SJbLi5033770; Fri, 28 Mar 2003 20:37:21 +0100 (CET) Date: Fri, 28 Mar 2003 20:37:20 +0100 From: Bernd Walter To: Maksim Yevmenkin Message-ID: <20030328193719.GN23168@cicely9.cicely.de> References: <20030328183858.7B2DB37B401@hub.freebsd.org> <20030328185650.GK23168@cicely9.cicely.de> <3E849FA7.1000400@exodus.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E849FA7.1000400@exodus.net> X-Operating-System: FreeBSD cicely9.cicely.de 5.0-CURRENT alpha User-Agent: Mutt/1.5.3i X-Spam-Status: No, hits=-30.9 required=5.0 tests=AWL,EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_MUTT autolearn=ham version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) cc: Bill Paul cc: hackers@freebsd.org cc: ticso@cicely.de cc: ticso@cicely9.cicely.de Subject: Re: Ax88172 vs FreeBSD USB stack 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: Fri, 28 Mar 2003 19:39:54 -0000 On Fri, Mar 28, 2003 at 11:16:55AM -0800, Maksim Yevmenkin wrote: > Just FYI > > ng_ubt(4) (/sys/netgraph/bluetooth/drivers/ubt) driver > (Bluetooth USB devices) makes use of two interfaces. >From a look into the driver these interfaces serve different protocols. I asume they are unrelated from a logical standpoint, but I don't know bluetooth technology. We have a similar situation with ulpt, where we usually have up to three interfaces with different capabilities. ulpt currently pics one of them, but we could also have three different ulpt instances taking each one of them. Well the AC88172 PDF is very clear about having 2 interfaces. The document also speaks about 4 endpoints, which I expect to be on interface 0 as they also have listed endpoint number 0 - they don't tell in the document. What I currently don't know is why there are 2 interfaces. The document also mentions some homenet capabilities on RJ11 - whatever it means. Maybe it's an hardware optional interface, which is disabled in this special device. For the ID strings - it seems that the hardware vendor just left the string empty in the eeprom. -- B.Walter BWCT http://www.bwct.de ticso@bwct.de info@bwct.de From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 28 12:12: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 0757537B401; Fri, 28 Mar 2003 12:12:01 -0800 (PST) Received: from scl8owa02.int.exodus.net (scl8out02.exodus.net [66.35.230.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6A59343F85; Fri, 28 Mar 2003 12:11:56 -0800 (PST) (envelope-from Maksim.Yevmenkin@cw.com) Received: from scl8owa01.int.exodus.net ([66.35.230.241]) by scl8owa02.int.exodus.net with Microsoft SMTPSVC(5.0.2195.5329); Fri, 28 Mar 2003 12:11:56 -0800 Received: from exodus.net ([165.193.27.35]) by scl8owa01.int.exodus.net over TLS secured channel with Microsoft SMTPSVC(5.0.2195.5329); Fri, 28 Mar 2003 12:11:55 -0800 Message-ID: <3E84ABB9.4090708@exodus.net> Date: Fri, 28 Mar 2003 12:08:25 -0800 From: Maksim Yevmenkin User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021126 X-Accept-Language: en-us, ru, en MIME-Version: 1.0 To: ticso@cicely.de References: <20030328183858.7B2DB37B401@hub.freebsd.org> <20030328185650.GK23168@cicely9.cicely.de> <3E849FA7.1000400@exodus.net> <20030328193719.GN23168@cicely9.cicely.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Mar 2003 20:11:55.0898 (UTC) FILETIME=[47BF3DA0:01C2F566] X-Spam-Status: No, hits=-16.9 required=5.0 tests=AWL,QUOTED_EMAIL_TEXT,REFERENCES,USER_AGENT_MOZILLA_UA autolearn=ham version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) cc: Bill Paul cc: hackers@freebsd.org cc: ticso@cicely9.cicely.de Subject: Re: Ax88172 vs FreeBSD USB stack 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, 28 Mar 2003 20:12:02 -0000 >>ng_ubt(4) (/sys/netgraph/bluetooth/drivers/ubt) driver >>(Bluetooth USB devices) makes use of two interfaces. > > From a look into the driver these interfaces serve different > protocols. not sure what do you mean by protocol here. interface 0 has control, interrupt, bulk-in and bulk-out endpoints. interface 1 has isoc-in and isoc-out endpoints. also interface 1 has 5 different configurations (w/different packet sizes) allowing isoc. bandwidth scaling. > I asume they are unrelated from a logical standpoint, but I don't > know bluetooth technology. they are. interface 0 is used to control device (control/interrupt transfers) and to transfer data (via bulk-in/out transfers). interface 1 is used to transfer voice (via isoc. transfers). > We have a similar situation with ulpt, where we usually have up > to three interfaces with different capabilities. > ulpt currently pics one of them, but we could also have three different > ulpt instances taking each one of them. it is not exactly the same here. the device can only perform 1) data transfers 2) data transfers + voice transfers > Well the AC88172 PDF is very clear about having 2 interfaces. > The document also speaks about 4 endpoints, which I expect to be on > interface 0 as they also have listed endpoint number 0 - they don't > tell in the document. > What I currently don't know is why there are 2 interfaces. > The document also mentions some homenet capabilities on RJ11 - whatever > it means. > Maybe it's an hardware optional interface, which is disabled in this > special device. in Bluetooth case they decided to put isoc. endpoints on the another interface so you can scale isoc. bandwidth (via max. packet size) without affecting the other transfers. thanks, max From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 28 12:54:46 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 618) id BB79B37B401; Fri, 28 Mar 2003 12:54:46 -0800 (PST) In-Reply-To: <20030328193719.GN23168@cicely9.cicely.de> from Bernd Walter at "Mar 28, 2003 08:37:20 pm" To: ticso@cicely.de Date: Fri, 28 Mar 2003 12:54:46 -0800 (PST) X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20030328205446.BB79B37B401@hub.freebsd.org> From: wpaul@FreeBSD.ORG (Bill Paul) X-Spam-Status: No, hits=-6.1 required=5.0 tests=AWL,IN_REP_TO,QUOTED_EMAIL_TEXT autolearn=ham version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) cc: hackers@freebsd.org cc: ticso@cicely.de Subject: Re: Ax88172 vs FreeBSD USB stack 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, 28 Mar 2003 20:54:47 -0000 > On Fri, Mar 28, 2003 at 11:16:55AM -0800, Maksim Yevmenkin wrote: > > Just FYI > > > > ng_ubt(4) (/sys/netgraph/bluetooth/drivers/ubt) driver > > (Bluetooth USB devices) makes use of two interfaces. > > >From a look into the driver these interfaces serve different > protocols. > I asume they are unrelated from a logical standpoint, but I don't > know bluetooth technology. > We have a similar situation with ulpt, where we usually have up > to three interfaces with different capabilities. > ulpt currently pics one of them, but we could also have three different > ulpt instances taking each one of them. The uplcom driver also uses two interfaces, but in that case, they put the interrupt endpoint on interface 0 and the bulk in/out endpoints on interface 1. When I saw that the AX88172 manual said that the device was supposed to have two interfaces, I wondered if maybe it had a similar setup, but I couldn't figure out how to access the second interface structure. For that matter, I didn't know for sure how to tell if it actually had one. (Sometimes manuals lie.) Hopefully when I try usbutils when I get home after work, I will learn more. > Well the AC88172 PDF is very clear about having 2 interfaces. > The document also speaks about 4 endpoints, which I expect to be on > interface 0 as they also have listed endpoint number 0 - they don't > tell in the document. > What I currently don't know is why there are 2 interfaces. > The document also mentions some homenet capabilities on RJ11 - whatever > it means. The AX88172 supports both regular ethernet and HomePNA (ethernet over cat3 telephone wiring) transceivers. You don't need a second USB interface for this though: you send/receive packets the same way regardless of what kind of transceiver you have. (The ADMtek Pegasus (if_aue) supports the same feature and only uses one set of endpoints.) > Maybe it's an hardware optional interface, which is disabled in this > special device. > > For the ID strings - it seems that the hardware vendor just left the > string empty in the eeprom. There is a UQ_NO_STRINGS quirk for this. Perhaps I should use it. -Bill -- ============================================================================= -Bill Paul (510) 749-2329 | Senior Engineer, Master of Unix-Fu wpaul@windriver.com | Wind River Systems ============================================================================= "If stupidity were a handicap, you'd have the best parking spot." ============================================================================= From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 28 14:05: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 EB10A37B405; Fri, 28 Mar 2003 14:05:38 -0800 (PST) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id D493A43FCB; Fri, 28 Mar 2003 14:05:36 -0800 (PST) (envelope-from ticso@cicely9.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.8/8.12.8) with ESMTP id h2SM5Ugt098769 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Fri, 28 Mar 2003 23:05:33 +0100 (CET) (envelope-from ticso@cicely9.cicely.de) Received: from cicely9.cicely.de (cicely9.cicely.de [IPv6:3ffe:400:8d0:301:210:5aff:fe30:1c1a]) by cicely5.cicely.de (8.12.8/8.12.8) with ESMTP id h2SM5QGA051960 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Mar 2003 23:05:27 +0100 (CET) (envelope-from ticso@cicely9.cicely.de) Received: from cicely9.cicely.de (localhost [127.0.0.1]) by cicely9.cicely.de (8.12.8/8.12.8) with ESMTP id h2SM5Okv034109; Fri, 28 Mar 2003 23:05:25 +0100 (CET) (envelope-from ticso@cicely9.cicely.de) Received: (from ticso@localhost) by cicely9.cicely.de (8.12.8/8.12.8/Submit) id h2SM5Na8034108; Fri, 28 Mar 2003 23:05:23 +0100 (CET) Date: Fri, 28 Mar 2003 23:05:22 +0100 From: Bernd Walter To: Bill Paul Message-ID: <20030328220521.GP23168@cicely9.cicely.de> References: <20030328193719.GN23168@cicely9.cicely.de> <20030328205446.BB79B37B401@hub.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030328205446.BB79B37B401@hub.freebsd.org> X-Operating-System: FreeBSD cicely9.cicely.de 5.0-CURRENT alpha User-Agent: Mutt/1.5.3i X-Spam-Status: No, hits=-32.4 required=5.0 tests=AWL,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT autolearn=ham version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) cc: hackers@FreeBSD.ORG cc: ticso@cicely.de Subject: Re: Ax88172 vs FreeBSD USB stack 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: Fri, 28 Mar 2003 22:05:42 -0000 On Fri, Mar 28, 2003 at 12:54:46PM -0800, Bill Paul wrote: > > On Fri, Mar 28, 2003 at 11:16:55AM -0800, Maksim Yevmenkin wrote: > > > Just FYI > > > > > > ng_ubt(4) (/sys/netgraph/bluetooth/drivers/ubt) driver > > > (Bluetooth USB devices) makes use of two interfaces. > > > > >From a look into the driver these interfaces serve different > > protocols. > > I asume they are unrelated from a logical standpoint, but I don't > > know bluetooth technology. > > We have a similar situation with ulpt, where we usually have up > > to three interfaces with different capabilities. > > ulpt currently pics one of them, but we could also have three different > > ulpt instances taking each one of them. > > The uplcom driver also uses two interfaces, but in that case, they > put the interrupt endpoint on interface 0 and the bulk in/out endpoints > on interface 1. When I saw that the AX88172 manual said that the device My PL2303 has only one interface: DEVICE addr 3 DEVICE descriptor: bLength=18 bDescriptorType=device(1) bcdUSB=1.10 bDeviceClass=0 bDeviceSubClass=0 bDeviceProtocol=0 bMaxPacketSize=8 idVendor=0x067b idProduct=0x2303 bcdDevice=200 iManufacturer=0() iProduct=0() iSerialNumber=0() bNumConfigurations=1 CONFIGURATION descriptor 0: bLength=9 bDescriptorType=config(2) wTotalLength=39 bNumInterface=1 bConfigurationValue=1 iConfiguration=0() bmAttributes=a0 bMaxPower=100 mA INTERFACE descriptor 0: bLength=9 bDescriptorType=interface(4) bInterfaceNumber=0 bAlternateSetting=0 bNumEndpoints=3 bInterfaceClass=255 bInterfaceSubClass=0 bInterfaceProtocol=0 iInterface=0() ENDPOINT descriptor: bLength=7 bDescriptorType=endpoint(5) bEndpointAddress=1-in bmAttributes=interrupt wMaxPacketSize=10 bInterval=1 ENDPOINT descriptor: bLength=7 bDescriptorType=endpoint(5) bEndpointAddress=2-out bmAttributes=bulk wMaxPacketSize=64 bInterval=0 ENDPOINT descriptor: bLength=7 bDescriptorType=endpoint(5) bEndpointAddress=3-in bmAttributes=bulk wMaxPacketSize=64 bInterval=0 current configuration 1 Do you know which uplcom chip uses two interfaces? It's interesting, because for the long run we really need to support mutiple devices drivers for single devices and I don't want to break support for such special devices. > was supposed to have two interfaces, I wondered if maybe it had a > similar setup, but I couldn't figure out how to access the second > interface structure. For that matter, I didn't know for sure how to > tell if it actually had one. (Sometimes manuals lie.) Hopefully when I > try usbutils when I get home after work, I will learn more. The number of interfaces is in the configuration descriptor. After USB_ATTACH_START you should see it in uaa->nifaces. > > Well the AC88172 PDF is very clear about having 2 interfaces. > > The document also speaks about 4 endpoints, which I expect to be on > > interface 0 as they also have listed endpoint number 0 - they don't > > tell in the document. > > What I currently don't know is why there are 2 interfaces. > > The document also mentions some homenet capabilities on RJ11 - whatever > > it means. > > The AX88172 supports both regular ethernet and HomePNA (ethernet > over cat3 telephone wiring) transceivers. You don't need a second > USB interface for this though: you send/receive packets the same > way regardless of what kind of transceiver you have. (The ADMtek > Pegasus (if_aue) supports the same feature and only uses one set > of endpoints.) > > > Maybe it's an hardware optional interface, which is disabled in this > > special device. > > > > For the ID strings - it seems that the hardware vendor just left the > > string empty in the eeprom. > > There is a UQ_NO_STRINGS quirk for this. Perhaps I should use it. I asume it's only for devices that hang when asked. I have an ulpt device without strings that works fine: port 2 addr 3: full speed, power 98 mA, config 1, product 0x0002(0x0002), vendor 0x3980(0x3980), rev 0.06 Well - transfered data corrupts sometimes, but I doubt it hast anything to do with the strings. -- B.Walter BWCT http://www.bwct.de ticso@bwct.de info@bwct.de From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 28 17:28: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 0257137B401 for ; Fri, 28 Mar 2003 17:28:31 -0800 (PST) Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 450B243FCB for ; Fri, 28 Mar 2003 17:28:30 -0800 (PST) (envelope-from bmah@employees.org) Received: from bmah.dyndns.org (12-240-204-110.client.attbi.com[12.240.204.110]) by rwcrmhc53.attbi.com (rwcrmhc53) with ESMTP id <20030329012829053005kul4e>; Sat, 29 Mar 2003 01:28:29 +0000 Received: from intruder.bmah.org (localhost [127.0.0.1]) by bmah.dyndns.org (8.12.8/8.12.8) with ESMTP id h2T1STv5032988; Fri, 28 Mar 2003 17:28:29 -0800 (PST) (envelope-from bmah@intruder.bmah.org) Received: (from bmah@localhost) by intruder.bmah.org (8.12.8/8.12.8/Submit) id h2T1SSJp032987; Fri, 28 Mar 2003 17:28:28 -0800 (PST) Date: Fri, 28 Mar 2003 17:28:28 -0800 From: "Bruce A. Mah" To: Tim Kientzle Message-ID: <20030329012828.GA32891@intruder.bmah.org> References: <3E42C148.4050807@acm.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="KsGdsel6WgEHnImy" Content-Disposition: inline In-Reply-To: <3E42C148.4050807@acm.org> User-Agent: Mutt/1.4.1i X-Image-Url: http://www.employees.org/~bmah/Images/bmah-cisco-small.gif X-url: http://www.employees.org/~bmah/ cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Making pkg_XXX tools smarter about file types... 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: Sat, 29 Mar 2003 01:28:32 -0000 --KsGdsel6WgEHnImy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable If memory serves me right, Tim Kientzle wrote: > The attached patch modifies the pkg_install > tools to inspect the file contents--rather than the > filename extension--to determine the > compression method in use. It then feeds the data > into the correct invocation of 'tar'. > I've also modified exec.c/lib.h to > factor out and expose some common code that > formats shell command lines. >=20 > This approach makes it possible, for instance, to > fix a single file extension (e.g. '.freebsd' > or '.package') that would not have to change > even if the internal format of a package were > to change (as has already occurred once, with > the transition from gzip to bzip2 compression). >=20 > Note that this could also be fairly easily extended > to support a variety of alternative archive > types. (E.g., the pkg_XXX tools could be > modified to support 'zip' or 'tar' archives > transparently to the user.) (A month and a half passes...I meant to get back to you earlier but didn't have any time to play with this before. Actually I still don't, but...) The concept is good, and it's something we've needed for awhile. I suspect you followed the various adventures of pkg_add and sysinstall when we tried supporting both bzip2 and gzip packages for various releases and developer previews, before we settled on the current "bzip2 for 5.X and gzip for 4.X" as something that actually worked. A little feedback on the patch itself (functionality only): Basically, it works great for the case of a package coming in on stdin. If the package comes from a file, then pkg_add wants to make two passes over the package, first to get the +CONTENTS file and second to actually unpack everything. When the first tar process finishes reading the +CONTENTS file, it closes its pipe (due to the --fast-read argument). However, pkg_add still seems to be writing to the pipe...this seems to be bad. An example with pkg_add built with CFLAGS=3D-DDEBUG: tomcat:add# cat ~/tmp/bash.pkg | ./pkg_add - Piping package '-' to cmd 'tar -xpjf - ' updating /etc/shells Executing /usr/sbin/mtree -U -f +MTREE_DIRS -d -e -p /usr/local >/dev/null Executing mkdir /var/db/pkg/bash-2.05b.004 Executing chmod a+rx /var/db/pkg/bash-2.05b.004 Executing mv ./+DESC /var/db/pkg/bash-2.05b.004 Executing mv ./+COMMENT /var/db/pkg/bash-2.05b.004 Executing mv ./+MTREE_DIRS /var/db/pkg/bash-2.05b.004 Executing rm -rf /var/tmp/instmp.BGdXjm tomcat:add# ./pkg_add ~/tmp/bash.pkg Piping package '/usr/users/bmah/tmp/bash.pkg' to cmd 'tar -xpjf - --fast-re= ad - +CONTENTS' Broken pipe It works if I remove the --fast-read flag from the tar, but that's not the right answer. Bruce. --KsGdsel6WgEHnImy Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE+hPa72MoxcVugUsMRAilNAJ48GXwd1KIxnJbfs02MKBXocZMD2ACfTZI7 vVuJWX6DWbkyBrnVbh3BA7Q= =I+ts -----END PGP SIGNATURE----- --KsGdsel6WgEHnImy-- From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 28 21:03: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 6CAD037B401; Fri, 28 Mar 2003 21:03:46 -0800 (PST) Received: from puffin.mail.pas.earthlink.net (puffin.mail.pas.earthlink.net [207.217.120.139]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7B83343F75; Fri, 28 Mar 2003 21:03:45 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from pool0191.cvx21-bradley.dialup.earthlink.net ([209.179.192.191] helo=mindspring.com) by puffin.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 18z8V2-0004uE-00; Fri, 28 Mar 2003 21:03:25 -0800 Message-ID: <3E8528CF.DC42164A@mindspring.com> Date: Fri, 28 Mar 2003 21:02:07 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: ticso@cicely.de References: <20030328183858.7B2DB37B401@hub.freebsd.org> <3E849FA7.1000400@exodus.net> <20030328193719.GN23168@cicely9.cicely.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a46d4fb99f91a96aa47514aa4c2c429621a8438e0f32a48e08350badd9bab72f9c350badd9bab72f9c cc: Bill Paul cc: hackers@freebsd.org cc: ticso@cicely9.cicely.de Subject: Re: Ax88172 vs FreeBSD USB stack 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: Sat, 29 Mar 2003 05:03:48 -0000 Bernd Walter wrote: > Well the AC88172 PDF is very clear about having 2 interfaces. > The document also speaks about 4 endpoints, which I expect to be on > interface 0 as they also have listed endpoint number 0 - they don't > tell in the document. > What I currently don't know is why there are 2 interfaces. > The document also mentions some homenet capabilities on RJ11 - whatever > it means. > Maybe it's an hardware optional interface, which is disabled in this > special device. Maybe it's running in "Home PNA" mode by default, so the connector (identical to an ethernet connector) isn't talking ethernet? Personally, I think the bul transfers have to happen over the other interface. I've seen this once before, a while ago. If there's a Linux driver that works, maybe you can crib from it, where the documentation is fuzzy? It also occurs to me that you might try it under Windows, if you have a recording USB monitor, and see what's different between your usage and Windows. One particularly nasty thing might be it needing a firmware download from the driver (it's possible). Doug Ambrisko could probably help you out; I remember he did a driver for a similar USB dongle (two interfaces) at Whistle. -- Terry From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 28 22:47: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 B7D0237B401; Fri, 28 Mar 2003 22:47:08 -0800 (PST) Received: from kientzle.com (h-66-166-149-50.SNVACAID.covad.net [66.166.149.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id B5F4243FB1; Fri, 28 Mar 2003 22:47:07 -0800 (PST) (envelope-from kientzle@acm.org) Received: from acm.org (ugly.x.kientzle.com [66.166.149.51]) by kientzle.com (8.11.3/8.11.3) with ESMTP id h2T6l7v35333; Fri, 28 Mar 2003 22:47:07 -0800 (PST) (envelope-from kientzle@acm.org) Message-ID: <3E85418F.8010201@acm.org> Date: Fri, 28 Mar 2003 22:47:43 -0800 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: "Bruce A. Mah" References: <3E42C148.4050807@acm.org> <20030329012828.GA32891@intruder.bmah.org> Content-Type: multipart/mixed; boundary="------------070001080502070007020104" cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Making pkg_XXX tools smarter about file types... 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: Sat, 29 Mar 2003 06:47:11 -0000 This is a multi-part message in MIME format. --------------070001080502070007020104 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce A. Mah wrote: > If memory serves me right, Tim Kientzle wrote: > >>The attached patch modifies the pkg_install >>tools to inspect the file contents--rather than the >>filename extension--to determine the >>compression method in use. > > The concept is good, and it's something we've needed for awhile. I > suspect you followed the various adventures of pkg_add and sysinstall > when we tried supporting both bzip2 and gzip packages ... Yes, those adventures were a large part of what motivated me to implement this auto-detect logic. > ... If the > package comes from a file, then pkg_add wants to make two passes over > the package, first to get the +CONTENTS file and second to actually > unpack everything. When the first tar process finishes reading the > +CONTENTS file, it closes its pipe (due to the --fast-read argument). > However, pkg_add still seems to be writing to the pipe...this seems to > be bad. > > It works if I remove the --fast-read flag from the tar, but that's not > the right answer. No. That's clearly not the right answer. Seems I forgot to check for an error return from fwrite(). Easy enough to fix; near the end of unpack() in lib/file.c, change the read/write loop to the following: while(buff_size > 0) { if(buff_size < fwrite(buff,1,buff_size,out_pipe)) break; buff_size = fread(buff,1,buff_allocation,pkg_file); } This aborts the passthrough if the pipe is closed. Modified diff attached. Tim P.S. It's galled me for a while that pkg_add has to fork 'tar' to extract the archive. I've started piecing together a library that reads/writes tarfiles. With this, it should be possible to make pkg_add considerably more efficient. In particular, rather than extracting to a temp directory, then parsing important information, then moving the files, it should be possible using this library to read the initial entries ("+CONTENTS", in particular) directly into memory, process the information there, then extract the remainder of the package files directly into their final locations. So far, I have a library API outlined, and functional read support implemented. Next step is to hack up a minimal tar implementation that uses it to make sure everything's working correctly. So far, the library automatically detects compression formats (using techniques like those in my pkg_install patch) and has some rough support for detecting the archive format as well. (One goal of mine: support for 'pax extended archives', which I understand can handle ACLs.) Of course, such a library could also form the basis for a BSD-licensed tar to replace GNU tar. I understand a few people have wanted such a thing. --------------070001080502070007020104 Content-Type: text/plain; name="kientzle_pkg_install-2.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="kientzle_pkg_install-2.diff" Index: lib/exec.c =================================================================== RCS file: /usr/src/cvs/src/usr.sbin/pkg_install/lib/exec.c,v retrieving revision 1.10 diff -c -r1.10 exec.c *** lib/exec.c 1 Apr 2002 09:39:07 -0000 1.10 --- lib/exec.c 29 Mar 2003 06:00:36 -0000 *************** *** 25,59 **** #include /* ! * Unusual system() substitute. Accepts format string and args, ! * builds and executes command. Returns exit code. */ ! ! int ! vsystem(const char *fmt, ...) { ! va_list args; char *cmd; - int ret, maxargs; maxargs = sysconf(_SC_ARG_MAX); maxargs -= 32; /* some slop for the sh -c */ cmd = malloc(maxargs); if (!cmd) { ! warnx("vsystem can't alloc arg space"); ! return 1; } - - va_start(args, fmt); if (vsnprintf(cmd, maxargs, fmt, args) > maxargs) { ! warnx("vsystem args are too long"); ! return 1; } #ifdef DEBUG printf("Executing %s\n", cmd); #endif ret = system(cmd); - va_end(args); free(cmd); return ret; } --- 25,83 ---- #include /* ! * Format a command, allocating a buffer along the way. */ ! static char * ! va_system_cmd(const char *fmt, va_list args) { ! int maxargs; char *cmd; maxargs = sysconf(_SC_ARG_MAX); maxargs -= 32; /* some slop for the sh -c */ cmd = malloc(maxargs); if (!cmd) { ! warnx("can't allocate memory to format program command line"); ! return NULL; } if (vsnprintf(cmd, maxargs, fmt, args) > maxargs) { ! warnx("argument list is too long"); ! return NULL; } + return cmd; + } + + char * + system_cmd(const char *fmt, ...) + { + va_list args; + char *cmd; + + va_start(args, fmt); + cmd = va_system_cmd(fmt,args); + va_end(args); + return cmd; + } + + /* + * Unusual system() substitute. Accepts format string and args, + * builds and executes command. Returns exit code. + */ + int + vsystem(const char *fmt, ...) + { + va_list args; + char *cmd; + int ret; + + va_start(args, fmt); + cmd = va_system_cmd(fmt,args); + va_end(args); + if(cmd == NULL) return 1; #ifdef DEBUG printf("Executing %s\n", cmd); #endif ret = system(cmd); free(cmd); return ret; } *************** *** 63,69 **** { FILE *fp; char *cmd, *rp; - int maxargs; va_list args; rp = malloc(MAXPATHLEN); --- 87,92 ---- *************** *** 71,94 **** warnx("vpipe can't alloc buffer space"); return NULL; } ! maxargs = sysconf(_SC_ARG_MAX); ! maxargs -= 32; /* some slop for the sh -c */ ! cmd = alloca(maxargs); ! if (!cmd) { ! warnx("vpipe can't alloc arg space"); ! return NULL; ! } - va_start(args, fmt); - if (vsnprintf(cmd, maxargs, fmt, args) > maxargs) { - warnx("vsystem args are too long"); - return NULL; - } #ifdef DEBUG fprintf(stderr, "Executing %s\n", cmd); #endif fflush(NULL); fp = popen(cmd, "r"); if (fp == NULL) { warnx("popen() failed"); return NULL; --- 94,110 ---- warnx("vpipe can't alloc buffer space"); return NULL; } ! va_start(args,fmt); ! cmd = va_system_cmd(fmt,args); ! va_end(args); ! if(cmd == NULL) return NULL; #ifdef DEBUG fprintf(stderr, "Executing %s\n", cmd); #endif fflush(NULL); fp = popen(cmd, "r"); + free(cmd); if (fp == NULL) { warnx("popen() failed"); return NULL; *************** *** 97,103 **** #ifdef DEBUG fprintf(stderr, "Returned %s\n", rp); #endif - va_end(args); if (pclose(fp) || (strlen(rp) == 0)) { free(rp); return NULL; --- 113,118 ---- Index: lib/file.c =================================================================== RCS file: /usr/src/cvs/src/usr.sbin/pkg_install/lib/file.c,v retrieving revision 1.64 diff -c -r1.64 file.c *** lib/file.c 6 Jan 2003 07:39:02 -0000 1.64 --- lib/file.c 29 Mar 2003 06:12:55 -0000 *************** *** 27,32 **** --- 27,36 ---- #include #include + static int file_is_gzip(const unsigned char *, size_t); + static int file_is_bzip2(const unsigned char *, size_t); + + /* Quick check to see if a file exists */ Boolean fexists(const char *fname) *************** *** 42,48 **** isdir(const char *fname) { struct stat sb; ! if (lstat(fname, &sb) != FAIL && S_ISDIR(sb.st_mode)) return TRUE; else if (lstat(strconcat(fname, "/."), &sb) != FAIL && S_ISDIR(sb.st_mode)) --- 46,52 ---- isdir(const char *fname) { struct stat sb; ! if (lstat(fname, &sb) != FAIL && S_ISDIR(sb.st_mode)) return TRUE; else if (lstat(strconcat(fname, "/."), &sb) != FAIL && S_ISDIR(sb.st_mode)) *************** *** 328,362 **** int unpack(const char *pkg, const char *flist) { ! char args[10], suff[80], *cp; ! args[0] = '\0'; ! /* ! * Figure out by a crude heuristic whether this or not this is probably ! * compressed and whichever compression utility was used (gzip or bzip2). ! */ if (strcmp(pkg, "-")) { ! cp = strrchr(pkg, '.'); ! if (cp) { ! strcpy(suff, cp + 1); ! if (strchr(suff, 'z') || strchr(suff, 'Z')) { ! if (strchr(suff, 'b')) ! strcpy(args, "-j"); ! else ! strcpy(args, "-z"); ! } ! } } ! else ! /* XXX: need to handle .tgz also */ ! strcpy(args, "-j"); ! strcat(args, " -xpf"); ! if (vsystem("tar %s '%s' %s", args, pkg, flist ? flist : "")) { warnx("tar extract of %s failed!", pkg); return 1; } return 0; } /* * Using fmt, replace all instances of: --- 332,411 ---- int unpack(const char *pkg, const char *flist) { ! char *cmd; ! char *compression; ! FILE *pkg_file; ! FILE *out_pipe; ! unsigned char *buff; ! size_t buff_allocation; ! size_t buff_size; ! buff_allocation = 8*1024; ! ! buff = (unsigned char *)malloc(buff_allocation); ! /* Determine compression by inspecting file signature */ if (strcmp(pkg, "-")) { ! pkg_file = fopen(pkg,"r"); ! } else { ! pkg_file = stdin; } ! if(pkg_file == NULL) { ! warnx("couldn't open %s",pkg); ! return 1; ! } ! ! /* Select appropriate compression argument for tar by ! * inspecting file signature */ ! buff_size = fread(buff,1,buff_allocation,pkg_file); ! if(file_is_gzip(buff,buff_size)) { ! compression = "z"; ! } else if(file_is_bzip2(buff,buff_size)) { ! compression = "j"; ! } else { ! compression = ""; ! } ! ! cmd = system_cmd("tar -xp%sf - %s",compression,flist ? flist : ""); ! if(cmd == NULL) return 1; ! ! /* Cat entire file through tar */ ! #ifdef DEBUG ! printf("Piping package '%s' to cmd '%s'\n", pkg,cmd); ! #endif ! out_pipe = popen(cmd,"w"); ! free(cmd); ! ! if(out_pipe == NULL) return 1; ! while(buff_size > 0) { ! if(buff_size < fwrite(buff,1,buff_size,out_pipe)) ! break; ! buff_size = fread(buff,1,buff_allocation,pkg_file); ! } ! if(pclose(out_pipe)) { warnx("tar extract of %s failed!", pkg); return 1; } return 0; } + + /* + * Returns 1 if buffer holds initial bytes of a gzipped file + */ + static int + file_is_gzip(const unsigned char *head, size_t s) { + if(s < 2) return 0; + return (head[0]==0037 && head[1]==0213); + } + + /* + * Returns 1 if buffer holds initial bytes of a bzip2-ed file + */ + static int + file_is_bzip2(const unsigned char *head, size_t s) { + if(s < 3) return 0; + return (head[0]=='B' && head[1]=='Z' && head[2]=='h'); + } + /* * Using fmt, replace all instances of: Index: lib/lib.h =================================================================== RCS file: /usr/src/cvs/src/usr.sbin/pkg_install/lib/lib.h,v retrieving revision 1.47 diff -c -r1.47 lib.h *** lib/lib.h 6 Jan 2003 07:39:02 -0000 1.47 --- lib/lib.h 29 Mar 2003 06:00:36 -0000 *************** *** 137,142 **** --- 137,143 ---- /* Prototypes */ /* Misc */ int vsystem(const char *, ...); + char * system_cmd(const char *, ...); char *vpipe(const char *, ...); void cleanup(int); char *make_playpen(char *, off_t); --------------070001080502070007020104-- From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 28 23:17: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 E682637B401; Fri, 28 Mar 2003 23:17:52 -0800 (PST) Received: from kientzle.com (h-66-166-149-50.SNVACAID.covad.net [66.166.149.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id DE03643FCB; Fri, 28 Mar 2003 23:17:51 -0800 (PST) (envelope-from kientzle@acm.org) Received: from acm.org (ugly.x.kientzle.com [66.166.149.51]) by kientzle.com (8.11.3/8.11.3) with ESMTP id h2T7Hov35403; Fri, 28 Mar 2003 23:17:50 -0800 (PST) (envelope-from kientzle@acm.org) Message-ID: <3E8548C3.90209@acm.org> Date: Fri, 28 Mar 2003 23:18:27 -0800 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: "Bruce A. Mah" References: <3E42C148.4050807@acm.org> <20030329012828.GA32891@intruder.bmah.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Making pkg_XXX tools smarter about file types... 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: Sat, 29 Mar 2003 07:17:54 -0000 Bruce A. Mah wrote: >>The attached patch modifies the pkg_install >>tools to inspect the file contents--rather than the >>filename extension--to determine the >>compression method in use. > > ... it works great for the case of a package coming in on stdin. If the > package comes from a file, ... Oh, bloody hell. I overlooked 'pkg_add -r', too, didn't I? Shouldn't take too long to add the auto-detect logic to the remote fetch handling, as well. Tim From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 28 23:21: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 6F79937B401; Fri, 28 Mar 2003 23:21:52 -0800 (PST) Received: from geekpunk.net (adsl-32-212-96.bna.bellsouth.net [67.32.212.96]) by mx1.FreeBSD.org (Postfix) with ESMTP id 49E1543FAF; Fri, 28 Mar 2003 23:21:51 -0800 (PST) (envelope-from bandix@geekpunk.net) Received: from localhost.my.domain (taran [127.0.0.1]) by geekpunk.net (8.12.6/8.12.6) with ESMTP id h2T7Lv6g012467; Sat, 29 Mar 2003 01:21:57 -0600 (CST) (envelope-from bandix@geekpunk.net) Received: (from bandix@localhost) by localhost.my.domain (8.12.6/8.12.6/Submit) id h2T7LuI6012466; Sat, 29 Mar 2003 01:21:56 -0600 (CST) (envelope-from bandix) Date: Sat, 29 Mar 2003 01:21:56 -0600 From: "Brandon D. Valentine" To: Tim Kientzle Message-ID: <20030329072156.GO3528@geekpunk.net> References: <3E42C148.4050807@acm.org> <20030329012828.GA32891@intruder.bmah.org> <3E85418F.8010201@acm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E85418F.8010201@acm.org> User-Agent: Mutt/1.4.1i cc: "Bruce A. Mah" cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Making pkg_XXX tools smarter about file types... 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: Sat, 29 Mar 2003 07:21:53 -0000 On Fri, Mar 28, 2003 at 10:47:43PM -0800, Tim Kientzle wrote: > > P.S. It's galled me for a while that pkg_add has to fork 'tar' to > extract the archive. I've started piecing together a library that > reads/writes tarfiles. With this, it should be possible to make > pkg_add considerably more efficient. In particular, rather than > extracting to a temp directory, then parsing important information, > then moving the files, it should be possible using this library to > read the initial entries ("+CONTENTS", in particular) directly into > memory, process the information there, then extract the remainder of > the package files directly into their final locations. So far, I have > a library API outlined, and functional read support implemented. Next > step is to hack up a minimal tar implementation that uses it to make > sure everything's working correctly. > > So far, the library automatically detects compression formats (using > techniques like those in my pkg_install patch) and has some rough > support for detecting the archive format as well. (One goal of mine: > support for 'pax extended archives', which I understand can handle > ACLs.) > > Of course, such a library could also form the basis for a BSD-licensed > tar to replace GNU tar. I understand a few people have wanted such a > thing. FYI, libtar[0] is BSD-licensed and might be useful to such a project. [0] - http://www-dev.cites.uiuc.edu/libtar/ Brandon D. Valentine -- brandon@dvalentine.com http://www.geekpunk.net Pseudo-Random Googlism: valentine is a champion of the true small online business From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 29 05:20: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 C01D337B401; Sat, 29 Mar 2003 05:20:02 -0800 (PST) Received: from hotmail.com (bay2-dav5.bay2.hotmail.com [65.54.246.109]) by mx1.FreeBSD.org (Postfix) with ESMTP id 18D1043F3F; Sat, 29 Mar 2003 05:20:02 -0800 (PST) (envelope-from sukhbinders@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 29 Mar 2003 05:20:01 -0800 Received: from 219.93.219.8 by bay2-dav5.bay2.hotmail.com with DAV; Sat, 29 Mar 2003 13:20:01 +0000 X-Originating-IP: [219.93.219.8] X-Originating-Email: [sukhbinders@hotmail.com] From: "Sukhbinder Singh" To: , "John Vender" , , , , , , , Date: Sat, 29 Mar 2003 21:18:42 +0800 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.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Message-ID: X-OriginalArrivalTime: 29 Mar 2003 13:20:01.0982 (UTC) FILETIME=[E784ADE0:01C2F5F5] Subject: Re: FreeBSD Installation Problems 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: Sat, 29 Mar 2003 13:20:05 -0000 By the way, I am now installing FreeBSD version 4.7 not version 5.0 any longer. When I try installing it using the Floppy disk method it gives me a different type of error message. This time it gives me an error message like, "unable to transfer the bin distribution from fd0 Do you want to try to retrieve it again? Yes No " If I press yes it keeps on showing the same error message "unable to transfer the bin distribution from fd0 Do you want to try to retrieve it again? Yes No ". If I press No it gives me another message like, "unable to save boot -c changes to new kernel, please see the debug screen (ALT -F2) for details. Then finally it gives me another message like "MAKEDEV returned non - zero status. " can anyone help concerning this problem. Do I need to custom my the kernel first before setting anything up, because I did went pass the kernel configuration stage, I did not do any kernel configuration or custom configuration on kernel but passed it. Thanks, bye... Sukhbinder Singh" wrote: > > > First, I made the 2 image floppy disk for the 2 image files by > >downloading them from ftp.freebsd.org. These 2 files are kern.flp and > >msfroot.flp. I also downloaded and made an image disk for drvivers.flp just > >to download the drivers at the installation process. > > Sounds like you are trying to install the 5.0 version. I would advise > anyone who is fairly new to FreeBSD to try 4.7 instead. You would need > to obtain the 4.7 images for kern.flp and mfsroot.flp. There is no > driver.flp for 4.7. > > > > >I have 2 MB of my hard disk space devoted to FreeBSD. > > 2MB isn't enough! I presume you meant 2GB :) > > > > >Then in the next screen I get another window > >with a request message like "Do you want to try DHCP configuration at the > >Interface ? Yes No ". I selected No and proceeded to the next level of the > >installation process. In this next level, I get a big screen called the > >"Network Configuration" window to proceed with my ftp. I think or suspect > >this is where the problem is. This window has 7 fields which it requires > me > >to enter. These 7 fields are host, domain, ipv4 gateway, name server, IPv4 > >address netmask :, extra option to ifconfig. I do not know any information > >regarding any of the fields. If I leave all of these fields empty, the > >installation program prompts me with an error message like "must specify a > >host name of some sort !" Then I just entered a host name for the host, > >like foo.com and pressed enter to proceed all the way through the 7 fields > >to the OK button. > > You definitely need some more entries there. Choose something that you > would not find on the net for domain. I use the rather boring my.domain > and the hostname can be any word you like. > > You must insert a valid IP in the Name Server (DNS) field. If you usually > use Microsoft Windows to connect to your ISP, you should be able to see > the Name Server address by using winipcfg while connected. Or you may be > able to find this from your ISP's www help pages, or contact their Tech. > Support as a last resort. > > Without a Name Server the installation won't be able to convert a name > like ftp.freebsd.org into a number (62.243.72.50). And therefore will > not be able to connect. > > It would probably help to put an entry in the interface netmask field. > 255.255.255.0 should be ok. > > > > >It fails to download freebsd automatically from the freebsd ftp site like > >it should. Any help will be helpful. > > I hope this is helpful. > > Good luck. > John. > > > I did what you asked me to do. This time I had a little bit of progress but > still I got a differen error message. I used the windows command winipcfg > command to get the DNS information. As I indicated in my previous mail there > are 6 fields in the windows in the "Network Configuration" window where > these 6 fields are host, domain, ipv4 gateway, name server, IPv4 address > netmask : , extra option to ifconfig. > > The hostname I typed as :- foo > The domain name as you indicated in your mail that you used my.domain I also > used my.domain > The netmask automatically chaged to :- 255.255.255.0 > The name server address or the DNS address after checking using winipcfg > was: 202.188.0.133 but when I use the arp command it gives me a different > address instead. It gives me 202.188.0.132 instead. The ipv4 gateway > information is blank with no information on this. The IPv4 information is > also left blank with no information and the extra option to ifconfig is > also left blank with no information. I chose to download using FTP. after > keying in all the information like the login name, password and the > telephone number for my ISP, I tried connecting, I got an error message like > " Cannot resolve hostname 'ftp.freebsd.org' ! Are you sure that your name se > rver, gateway and network interface are correctly configured ?" then I > pressed enter after this I got another message like "Killing previous PPP > process 34". Can anyone help regarding this problem. Any help will be > helpful. > > thanks, > > sukh > From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 29 05:26: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 5480F37B401 for ; Sat, 29 Mar 2003 05:26:23 -0800 (PST) Received: from parmenides.zen.co.uk (parmenides.zen.co.uk [212.23.8.69]) by mx1.FreeBSD.org (Postfix) with SMTP id C199A43FBD for ; Sat, 29 Mar 2003 05:26:21 -0800 (PST) (envelope-from tony@ubik.demon.co.uk) Received: (qmail 17451 invoked from network); 29 Mar 2003 13:26:20 -0000 Received: from protagoras.zen.co.uk (212.23.8.61) by parmenides.zen.co.uk with QMQP; 29 Mar 2003 13:26:20 -0000 Received: from dsl-217-155-183-134.zen.co.uk (HELO ubik.demon.co.uk) (217.155.183.134) by protagoras.zen.co.uk with SMTP; 29 Mar 2003 13:26:20 -0000 X-Zen-Trace: 217.155.183.134 Message-ID: Date: Sat, 29 Mar 2003 13:25:49 +0000 To: freebsd-hackers@freebsd.org, wpaul@FreeBSD.ORG (Bill Paul) From: Anthony Naggs References: <20030328183858.7B2DB37B401@hub.freebsd.org> In-Reply-To: <20030328183858.7B2DB37B401@hub.freebsd.org> MIME-Version: 1.0 X-Mailer: Turnpike Integrated Version 5.01 U Subject: Re: Ax88172 vs FreeBSD USB stack 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: Sat, 29 Mar 2003 13:26:26 -0000 In article <20030328183858.7B2DB37B401@hub.freebsd.org>, Bill Paul writes > >So. I picked up a Linksys USB200M USB 2.0 ethernet adapter that uses >the ASIX Electronics AX88172 chip, and I started cobbling together a >driver. This chip uses a series of vendor specific commands to do >things like read/write the MII management interface on the MAC, >read/write the SROM, set the RX filter, multicast hash table, etc. >I can do all this no problem. The Linksys NIC uses a RealTek 8201L >PHY, and I can attach it and negotiate a link. I have a Netgear FA120, also following ASIX's 'demonstration design', (i.e. reference design), of AX88172 and Realtek 8201L phy. I've not tried it with FreeBSD yet, but I had in mind to use NetBSD's uax driver for the AX88172 as the starting point! uax man page: http://netbsd.gw.com/cgi-bin/man-cgi/man?uax+4+NetBSD-current Netbsd cvs web: http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/usb/if_uax.c Hope this helps! Tony From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 29 07:44: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 1780137B401 for ; Sat, 29 Mar 2003 07:44:41 -0800 (PST) Received: from relay1.ntu-kpi.kiev.ua (oberon.ntu-kpi.kiev.ua [195.245.194.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3CF4443FB1 for ; Sat, 29 Mar 2003 07:44:39 -0800 (PST) (envelope-from rea@pth.ntu-kpi.kiev.ua) Received: by relay1.ntu-kpi.kiev.ua (Postfix, from userid 426) id 72A6C19DA5; Sat, 29 Mar 2003 17:44:36 +0200 (EET) Received: from mate.pth.ntu-kpi.kiev.ua (if100Mbit.pth.ntu-kpi.kiev.ua [10.100.5.180]) by relay1.ntu-kpi.kiev.ua (Postfix) with SMTP id A03C0199D4 for ; Sat, 29 Mar 2003 17:44:35 +0200 (EET) Received: (qmail 64209 invoked by uid 7770); 29 Mar 2003 15:44:32 -0000 Received: from tapir.pth.ntu-kpi.kiev.ua (HELO tapir) (10.101.1.75) by pth.ntu-kpi.kiev.ua with SMTP; 29 Mar 2003 15:44:32 -0000 Message-ID: <001d01c2f60a$8fea7b90$4b01650a@tapir> From: "REA" To: Date: Sat, 29 Mar 2003 17:47:53 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: hi 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: Sat, 29 Mar 2003 15:44:42 -0000 From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 29 03:37: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 6C7C637B401; Sat, 29 Mar 2003 03:37:51 -0800 (PST) Received: from hotmail.com (bay2-dav33.bay2.hotmail.com [65.54.246.90]) by mx1.FreeBSD.org (Postfix) with ESMTP id C1BC643FB1; Sat, 29 Mar 2003 03:37:50 -0800 (PST) (envelope-from sukhbinders@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 29 Mar 2003 03:37:50 -0800 Received: from 219.93.219.79 by bay2-dav33.bay2.hotmail.com with DAV; Sat, 29 Mar 2003 11:37:50 +0000 X-Originating-IP: [219.93.219.79] X-Originating-Email: [sukhbinders@hotmail.com] From: "Sukhbinder Singh" To: , "John Vender" , , , , , , , References: <370EFEC0-5F79-11D7-B4F7-00039369D83A@jmv.com.au> Date: Sat, 29 Mar 2003 19:36:33 +0800 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.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Message-ID: X-OriginalArrivalTime: 29 Mar 2003 11:37:50.0633 (UTC) FILETIME=[A0F31190:01C2F5E7] X-Mailman-Approved-At: Sat, 29 Mar 2003 14:14:41 -0800 cc: Sukhbinder Singh Subject: Re: FreeBSD Installation Problems 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: Sat, 29 Mar 2003 11:37:53 -0000 ----- Original Message ----- From: John Murphy To: Sukhbinder Singh Cc: Sent: Thursday, March 27, 2003 10:22 PM Subject: Re: FreeBSD Installation Problems "Sukhbinder Singh" wrote: > First, I made the 2 image floppy disk for the 2 image files by >downloading them from ftp.freebsd.org. These 2 files are kern.flp and >msfroot.flp. I also downloaded and made an image disk for drvivers.flp just >to download the drivers at the installation process. Sounds like you are trying to install the 5.0 version. I would advise anyone who is fairly new to FreeBSD to try 4.7 instead. You would need to obtain the 4.7 images for kern.flp and mfsroot.flp. There is no driver.flp for 4.7. >I have 2 MB of my hard disk space devoted to FreeBSD. 2MB isn't enough! I presume you meant 2GB :) >Then in the next screen I get another window >with a request message like "Do you want to try DHCP configuration at the >Interface ? Yes No ". I selected No and proceeded to the next level of the >installation process. In this next level, I get a big screen called the >"Network Configuration" window to proceed with my ftp. I think or suspect >this is where the problem is. This window has 7 fields which it requires me >to enter. These 7 fields are host, domain, ipv4 gateway, name server, IPv4 >address netmask :, extra option to ifconfig. I do not know any information >regarding any of the fields. If I leave all of these fields empty, the >installation program prompts me with an error message like "must specify a >host name of some sort !" Then I just entered a host name for the host, >like foo.com and pressed enter to proceed all the way through the 7 fields >to the OK button. You definitely need some more entries there. Choose something that you would not find on the net for domain. I use the rather boring my.domain and the hostname can be any word you like. You must insert a valid IP in the Name Server (DNS) field. If you usually use Microsoft Windows to connect to your ISP, you should be able to see the Name Server address by using winipcfg while connected. Or you may be able to find this from your ISP's www help pages, or contact their Tech. Support as a last resort. Without a Name Server the installation won't be able to convert a name like ftp.freebsd.org into a number (62.243.72.50). And therefore will not be able to connect. It would probably help to put an entry in the interface netmask field. 255.255.255.0 should be ok. >It fails to download freebsd automatically from the freebsd ftp site like >it should. Any help will be helpful. I hope this is helpful. Good luck. John. I did what you asked me to do. This time I had a little bit of progress but still I got a differen error message. I used the windows command winipcfg command to get the DNS information. As I indicated in my previous mail there are 6 fields in the windows in the "Network Configuration" window where these 6 fields are host, domain, ipv4 gateway, name server, IPv4 address netmask : , extra option to ifconfig. The hostname I typed as :- foo The domain name as you indicated in your mail that you used my.domain I also used my.domain The netmask automatically chaged to :- 255.255.255.0 The name server address or the DNS address after checking using winipcfg was: 202.188.0.133 but when I use the arp command it gives me a different address instead. It gives me 202.188.0.132 instead. The ipv4 gateway information is blank with no information on this. The IPv4 information is also left blank with no information and the extra option to ifconfig is also left blank with no information. I chose to download using FTP. after keying in all the information like the login name, password and the telephone number for my ISP, I tried connecting, I got an error message like " Cannot resolve hostname 'ftp.freebsd.org' ! Are you sure that your name se rver, gateway and network interface are correctly configured ?" then I pressed enter after this I got another message like "Killing previous PPP process 34". Can anyone help regarding this problem. Any help will be helpful. thanks, sukh From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 29 11:25: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 51DC137B401; Sat, 29 Mar 2003 11:25:52 -0800 (PST) Received: from pa-plum1b-166.pit.adelphia.net (pa-plum1b-122.pit.adelphia.net [24.53.161.122]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5381143FDF; Sat, 29 Mar 2003 11:25:51 -0800 (PST) (envelope-from wmoran@potentialtech.com) Received: from potentialtech.com (working [172.16.0.95]) h2TJPWJP007015; Sat, 29 Mar 2003 14:25:32 -0500 (EST) (envelope-from wmoran@potentialtech.com) Message-ID: <3E85E9AE.8030005@potentialtech.com> Date: Sat, 29 Mar 2003 13:45:02 -0500 From: Bill Moran User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.2.1) Gecko/20030301 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sukhbinder Singh References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 29 Mar 2003 14:14:46 -0800 cc: John Vender cc: jfm@blueyonder.co.uk cc: freebsd-hackers@FreeBSD.ORG cc: barbish@a1poweruser.com cc: alisx123@yahoo.com cc: freebsd-questions@FreeBSD.ORG cc: jonc@chen.org.nz Subject: Re: FreeBSD Installation Problems 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: Sat, 29 Mar 2003 19:25:53 -0000 Sukhbinder Singh wrote: > By the way, I am now installing FreeBSD version 4.7 not version 5.0 any > longer. > > When I try installing it using the Floppy disk method it gives me a > different type of error message. This time it gives me an error message > like, > "unable to transfer the bin distribution from fd0 Do you want to try to > retrieve it again? Yes No " If I press yes it keeps on showing the same > error message "unable to transfer the bin distribution from fd0 Do you > want to try to retrieve it again? Yes No ". If I press No it gives me > another message like, > "unable to save boot -c changes to new kernel, please see the debug screen > (ALT -F2) for details. Then finally it gives me another message like > "MAKEDEV returned non - zero status. " can anyone help concerning this > problem. Do I need to custom my the kernel first before setting anything up, > because I did went pass the kernel configuration stage, I did not do any > kernel configuration or custom configuration on kernel but passed it. The last time I did a floppy install (about 3 years ago) I had to scrap every third disk as bad. It's very likely that the particular disk you're trying to use is bad. That "unable to transfer xxx distribution" seems to happen the most often with bad media (i.e. disks/cds or bad disk/cd drive) I would check there first. -- Bill Moran Potential Technologies http://www.potentialtech.com From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 29 14:43:09 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 618) id 63DA637B401; Sat, 29 Mar 2003 14:43:09 -0800 (PST) In-Reply-To: <20030328220521.GP23168@cicely9.cicely.de> from Bernd Walter at "Mar 28, 2003 11:05:22 pm" To: ticso@cicely.de Date: Sat, 29 Mar 2003 14:43:09 -0800 (PST) X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20030329224309.63DA637B401@hub.freebsd.org> From: wpaul@FreeBSD.ORG (Bill Paul) cc: hackers@FreeBSD.ORG Subject: Re: Ax88172 vs FreeBSD USB stack 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: Sat, 29 Mar 2003 22:43:10 -0000 Ok, I figured it out. Turns out the AX88172 only has one interface after all, in spite of what the manual says. Maybe the info about the second interface was a holdover from the AX88170 datasheet which they forgot to expunge. Or maybe ASIX is on crack. Anyway, I discovered I was doing two things wrong: 1) The RX control register has to be set correctly to enable the RX filter on the MAC. The AX88172 datasheet doesn't tell you what the bits in the RX control byte mean. The AX88170 datasheet does, but only documents bits 0 through 4. It forgets to mention that you must also turn on bit 7. If you don't set this bit, you don't receive any packets. 2) For transmission, you must initialize the three inter-packet gap (IPG) registers correctly. They are unset by default, and until they are set, the MAC won't send any frames. Now that I fixed these two things, the driver works. In fact, I'm using it to type this e-mail right now. :) I uploaded a copy to: http://www.freebsd.org/~wpaul/ASIX/USB All it really needs is for me to fix the multicast filtering. Right now, it defaults to all multicast mode. I need to fill in the axe_setmulti() function so that it sets up the hash table correctly. I think I also need to fix promisc mode. This code is for 5.0-RELEASE or better. -Bill -- ============================================================================= -Bill Paul (510) 749-2329 | Senior Engineer, Master of Unix-Fu wpaul@windriver.com | Wind River Systems ============================================================================= "If stupidity were a handicap, you'd have the best parking spot." ============================================================================= From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 29 15:24:54 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 7788C37B401 for ; Sat, 29 Mar 2003 15:24:54 -0800 (PST) Received: from mad.ieo-research.it (anam.ieo-research.it [193.204.98.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id 84AED43FA3 for ; Sat, 29 Mar 2003 15:24:52 -0800 (PST) (envelope-from orlando.bassotto@ieo-research.it) Received: (qmail 1436 invoked by uid 666); 29 Mar 2003 23:25:01 -0000 Date: Sun, 30 Mar 2003 00:25:01 +0100 From: Orlando Bassotto To: freebsd-hackers@freebsd.org Message-ID: <20030329232501.GA1403@ieo-research.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i cc: freebsd-emulation@freebsd.org Subject: [PATCH] linux shm semantic patch + vmware3.2.0 modules 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: Sat, 29 Mar 2003 23:24:56 -0000 Hi all, working to make vmware 3.2.0 run on freebsd I found that the Linux shm emulation semantic was wrong, I did a small patch with a description file which is available with the vmware 3.2.0 modules at http://mad.ieo-research.it/. If you're going to use vmware 3.2.0, you will need to patch the kernel with this patch; VMware will complain about querying bridge status, but the network will work anyway. The modules have been tested on a UP system only. Best regards, Orlando. -- ---------------------------------------------------------------- Orlando Bassotto European Institute of Oncology orlando.bassotto@ieo-research.it Dept. Experimental Oncology Via Ripamonti, 435 - 20141 Milano (Italy) Phone# +39-02-57489-865/857 - Fax# +39-02-57489-851 ---------------------------------------------------------------- From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 29 17:43:21 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 C96B637B401; Sat, 29 Mar 2003 17:43:21 -0800 (PST) Received: from kientzle.com (h-66-166-149-50.SNVACAID.covad.net [66.166.149.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1C3AF43F75; Sat, 29 Mar 2003 17:43:21 -0800 (PST) (envelope-from kientzle@acm.org) Received: from acm.org (ugly.x.kientzle.com [66.166.149.51]) by kientzle.com (8.11.3/8.11.3) with ESMTP id h2U1hIv39613; Sat, 29 Mar 2003 17:43:18 -0800 (PST) (envelope-from kientzle@acm.org) Message-ID: <3E864BDD.9040102@acm.org> Date: Sat, 29 Mar 2003 17:43:57 -0800 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: "Brandon D. Valentine" References: <3E42C148.4050807@acm.org> <20030329012828.GA32891@intruder.bmah.org> <3E85418F.8010201@acm.org> <20030329072156.GO3528@geekpunk.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: "Bruce A. Mah" cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Making pkg_XXX tools smarter about file types... 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: Sun, 30 Mar 2003 01:43:25 -0000 Brandon D. Valentine wrote: > On Fri, Mar 28, 2003 at 10:47:43PM -0800, Tim Kientzle wrote: > >>P.S. It's galled me for a while that pkg_add has to fork 'tar' to >>extract the archive. I've started piecing together a library that >>reads/writes tarfiles. > > FYI, libtar[0] is BSD-licensed and might be useful to such a project. > > [0] - http://www-dev.cites.uiuc.edu/libtar/ Thanks for the pointer. I took a look, and there are some good ideas there, although my current libtarfile work has a few features that libtar lacks. Cribbing from libtar could be useful, though. (I'm also using John Gilmore's old PD tar as a source of ideas.) Tim