From owner-freebsd-hackers@FreeBSD.ORG Sun Aug 28 00:37:24 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 7B5E116A422 for ; Sun, 28 Aug 2005 00:37:24 +0000 (GMT) (envelope-from freebsd@irbis.net.ru) Received: from mail.irbis.net.ru (mail.irbis.net.ru [62.183.127.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id B489B43DC0 for ; Sun, 28 Aug 2005 00:18:37 +0000 (GMT) (envelope-from freebsd@irbis.net.ru) Received: by mail.irbis.net.ru (Postfix, from userid 106) id DDD6B7303E; Sun, 28 Aug 2005 04:18:34 +0400 (MSD) Received: from crsd.irbis.net.ru (crsd.irbis.net.ru [192.168.0.64]) by mail.irbis.net.ru (Postfix) with ESMTP id AC85B7303B for ; Sun, 28 Aug 2005 04:18:31 +0400 (MSD) From: Yuri Pankov To: freebsd-hackers@freebsd.org Date: Sun, 28 Aug 2005 04:18:26 +0400 User-Agent: KMail/1.8.2 Organization: Irbis Telecommunications, JSC MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200508280418.26456.freebsd@irbis.net.ru> Subject: libpcap and interface with no IPv4 address X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Aug 2005 00:37:24 -0000 Hi, tcpdump (and other programs using libpcap with IP proto filter) behaves strangely (as it seems to me) on an interface with no IPv4 address assigned.. tcpdump -ni xl0 tcpdump: WARNING: xl0: no IPv4 address assigned tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on xl0, link-type EN10MB (Ethernet), capture size 96 bytes 04:08:01.207673 IP 62.183.127.130.49192 > 85.118.141.1.80: . ack 4143124359 win 33304 04:08:01.209350 IP 62.183.127.130.49192 > 85.118.141.1.80: P 0:609(609) ack 1 win 33304 04:08:01.415512 IP 62.183.127.130.49192 > 85.118.141.1.80: . ack 989 win 33060 04:08:01.418589 IP 62.183.127.130.49192 > 85.118.141.1.80: . ack 1989 win 33054 04:08:01.421370 IP 62.183.127.130.49192 > 85.118.141.1.80: . ack 2989 win 33054 04:08:01.424297 IP 62.183.127.130.49192 > 85.118.141.1.80: . ack 3989 win 33054 etc. and using tcpdump -ni xl0 ip (any IP proto related filter here) gives no output at all besides the warning line and info. host must just collect IP packets, which are copied to this interface from another port. can this be solved? and any reason if not. FreeBSD-5 with tcpdump version 3.8.3 +libpcap version 0.8.3 FreeBSD-6 with tcpdump version 3.9.1 + libpcap version 0.9.1 From owner-freebsd-hackers@FreeBSD.ORG Sun Aug 28 03:49:47 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 EC77216A41F; Sun, 28 Aug 2005 03:49:46 +0000 (GMT) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 95E8043D45; Sun, 28 Aug 2005 03:49:46 +0000 (GMT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.13.1/8.13.3) id j7S3nhTH054574; Sat, 27 Aug 2005 22:49:43 -0500 (CDT) (envelope-from dan) Date: Sat, 27 Aug 2005 22:49:43 -0500 From: Dan Nelson To: Michael Bushkov Message-ID: <20050828034943.GE88693@dan.emsphone.com> References: <20050827170633.Y5409@stinger.cc.rsu.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050827170633.Y5409@stinger.cc.rsu.ru> X-OS: FreeBSD 5.4-STABLE X-message-flag: Outlook Error User-Agent: Mutt/1.5.9i Cc: Jacques Vidrine , freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, Brooks Davis Subject: Re: [PATCH] caching daemon release and nsswitch patches X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Aug 2005 03:49:47 -0000 In the last episode (Aug 27), Michael Bushkov said: > Please try the patches and send me your feedback. I also hope that > there are no reasons not to merge changes, which were made to libc > (they are in include.diff and libc.diff) into the CURRENT. As for the > caching daemon (usr.sbin.diff patch) - I also think that it could be > merged into the CURRENT. I applied the patches to 5-stable (only minor conflicts) and I'm getting an assertion failure in cached running "id" as root: Assertion failed: (key_var != NULL), function ht_item_hash_func, file /usr/src/usr.sbin/cached/cachelib/cachelib.c, line 34. You should probably convert cached's argument processing to use getopt, btw. -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-hackers@FreeBSD.ORG Sun Aug 28 14:32:47 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 3712216A41F for ; Sun, 28 Aug 2005 14:32:47 +0000 (GMT) (envelope-from arundel@h3c.de) Received: from enterprise4.noxa.de (enterprise.noxa.de [212.60.197.71]) by mx1.FreeBSD.org (Postfix) with ESMTP id 670D943D46 for ; Sun, 28 Aug 2005 14:32:45 +0000 (GMT) (envelope-from arundel@h3c.de) Received: (qmail 24409 invoked from network); 28 Aug 2005 16:32:43 +0200 Received: from p508fe2dc.dip.t-dialin.net (HELO localhost.skatecity) (80.143.226.220) by enterprise.noxa.de with AES256-SHA encrypted SMTP; 28 Aug 2005 16:32:43 +0200 Received: from localhost.skatecity (nobody@localhost.skatecity [127.0.0.1]) by localhost.skatecity (8.13.4/8.13.4) with ESMTP id j7SEWedB064812 for ; Sun, 28 Aug 2005 16:32:40 +0200 (CEST) (envelope-from arundel@localhost.skatecity) Received: (from arundel@localhost) by localhost.skatecity (8.13.4/8.13.4/Submit) id j7SEWdSl064811 for freebsd-hackers@freebsd.org; Sun, 28 Aug 2005 16:32:39 +0200 (CEST) (envelope-from arundel) From: alexander Date: Sun, 28 Aug 2005 16:32:39 +0200 To: freebsd-hackers@freebsd.org Message-ID: <20050828143239.GA64597@skatecity> Mail-Followup-To: freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Syscall/Sysret state on i386 arch X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Aug 2005 14:32:47 -0000 The AMD64 arch is using the syscall/sysret opcodes instead of int80h to perform a syscall (/usr/src/lib/libc/amd64/SYS.h). I just checked the output my of dmesg and it says: CPU: AMD Duron(tm) Processor (1311.69-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x671 Stepping = 1 Features=0x383f9ff AMD Features=0xc0400800 I got a hold of the AMD document number 21086.pdf. It describes both opcodes pretty well, but doesn't tell which CPUs support the new opcodes. But since the first revision of that document is dated Sept 1997 quite a lot of i386 CPU's should support the opcodes. The NASM manual only states [P6,AMD] as the required CPU to perform those opcodes. I found some patches for Linux that replace the int80h syscall calling convention with syscall/sysret on i386 and the results look pretty convincing: > (INT $0x80 based getpid(), got pid 497) latency:282 cycles > (SYSENTER based getpid(), got pid 497) latency:138 cycles > > on a 266 MHz PII this is 0.51 usecs for a getpid(). (was 1.06 usecs) Quoted from: http://www.ussg.iu.edu/hypermail/linux/kernel/9806.1/0878.html Does anybody know more about this? Is it even possible to replace the current syscall implementation that easily or would that require elaborate changes to all the syscalls (libc), etc. And which CPU's support these new opcodes? Doesn anybody know if the Linux patches actually got comitted to the official kernel? Cheers. From owner-freebsd-hackers@FreeBSD.ORG Sun Aug 28 22:48:31 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 283CB16A422 for ; Sun, 28 Aug 2005 22:48:31 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: from mail1.fluidhosting.com (mail1.fluidhosting.com [204.14.90.61]) by mx1.FreeBSD.org (Postfix) with SMTP id 0960643D49 for ; Sun, 28 Aug 2005 22:48:29 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: (qmail 44685 invoked by uid 399); 28 Aug 2005 22:48:29 -0000 Received: from localhost (HELO ?192.168.1.100?) (dougb@dougbarton.net@127.0.0.1) by localhost with SMTP; 28 Aug 2005 22:48:29 -0000 Message-ID: <43123F3B.8070002@FreeBSD.org> Date: Sun, 28 Aug 2005 15:48:27 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050726) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Bushkov References: <20050827170633.Y5409@stinger.cc.rsu.ru> In-Reply-To: <20050827170633.Y5409@stinger.cc.rsu.ru> X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Jacques Vidrine , freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, Brooks Davis Subject: Re: [PATCH] caching daemon release and nsswitch patches X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Aug 2005 22:48:31 -0000 Michael Bushkov wrote: > Hi! I'm working on nsswitch improvement (during the Google Summer of > Code program. First off, let me say that this is very exciting stuff! I'm particularly excited about caching for the services stuff, as it will finally allow us to bring in a more complete version of the services file. I do have some comments for you, and I hope that you understand that they are in no way critical of your work, just suggestions for improvements, and ways that you can better fit into the FreeBSD code base. I'm not sure what guidelines were given to you when you started the project, but in reviewing your work the first thing I noticed was that you are not following the guidelines in the style(9) man page. You should read that page, and spend an afternoon reformatting your code to fit what is described there. The most common error you've made is not following the 80 column rule, which hopefully should be easily fixed. While one could argue with the specific items in that page, and quite possibly be right, the idea of having a style guideline is more to have a common format that we can all work towards than to have a perfect format that we can all agree on. By reformatting your code to fit this guideline you will greatly increase the chances that it will be welcomed into the tree with open arms. The other style area that you should look at is your man pages. If you look in /usr/share/examples/mdoc you will find the FreeBSD style guidelines for man pages. The line wrapping issue comes into play here as well. We generally don't go past column 60 in man pages, since that reduces CVS repo churn for corrections down the road. Also, any time you have a full stop (period) at the end of a sentence, you should start a new line. I think that you are also using some macros that I'm not familiar with, although I'm not an mdoc expert. The other area that I'm interested in is how you plan to have cached interact with DNS lookups, /etc/hosts, named, etc. If there was a project plan posted somewhere on this already and I missed it, please accept my apologies, and send along a reference. If not, I'm very interested to hear what your plans are. Regards, Doug -- This .signature sanitized for your protection From owner-freebsd-hackers@FreeBSD.ORG Sun Aug 28 23:48:38 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 05B9916A41F for ; Sun, 28 Aug 2005 23:48:38 +0000 (GMT) (envelope-from killing@multiplay.co.uk) Received: from multiplay.co.uk (www1.multiplay.co.uk [212.42.16.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6DC1F43D45 for ; Sun, 28 Aug 2005 23:48:37 +0000 (GMT) (envelope-from killing@multiplay.co.uk) Received: from vader ([217.41.248.92]) by multiplay.co.uk (multiplay.co.uk [212.42.16.7]) (MDaemon.PRO.v8.1.0.R) with ESMTP id md50001830455.msg for ; Mon, 29 Aug 2005 00:40:57 +0100 Message-ID: <000201c5ac2a$df2d2990$5cf829d9@multiplay.co.uk> From: "Steven Hartland" To: Date: Sun, 28 Aug 2005 21:06:47 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Spam-Processed: multiplay.co.uk, Mon, 29 Aug 2005 00:40:57 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 217.41.248.92 X-Return-Path: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-hackers@freebsd.org X-MDAV-Processed: multiplay.co.uk, Mon, 29 Aug 2005 00:40:58 +0100 Subject: bge driver internal routing issues? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Aug 2005 23:48:38 -0000 Having a really odd problem here where udp queries to servers running on machines with bge cards dont respond via ip address that are being bound on: qop1# ifconfig bge0: flags=8843 mtu 1500 options=1a inet 217.41.254.99 netmask 0xffffff80 broadcast 217.41.254.127 ether 00:e0:81:63:9c:0a media: Ethernet autoselect (100baseTX ) status: active bge1: flags=8802 mtu 1500 options=1a ether 00:e0:81:63:9c:09 media: Ethernet autoselect (none) status: no carrier lo0: flags=8049 mtu 16384 inet 127.0.0.1 netmask 0xff000000 qop1# sockstat |grep 8478 mpukgame ucc-bin 42425 66 udp4 *:8478 *:* mpukgame ucc-bin 42424 66 udp4 *:8478 *:* qop1# qstat -uns 127.0.0.1:8478 -noportoffset ADDRESS PLAYERS MAP RESPONSE TIME NAME 127.0.0.1:8478 0/10 CTF-Cybrosis][ 42 / 0 CTFGame i25 :: CTF #1 qop1# qstat -uns 217.41.254.99:8478 -noportoffset ADDRESS PLAYERS MAP RESPONSE TIME NAME 217.41.254.99:8478 no response FreeBSD qop1.event.multiplay.co.uk 5.4-RELEASE-p2 FreeBSD 5.4-RELEASE-p2 #5: Tue Jun 21 13:28:12 UTC 2005 root@r2d2.multiplay.co.uk:/.usr/i386/src/sys/i386/compile/MPUK_SINGLE_200HZ i386 Running the exact same test on a machine with an em driver has no problems. No idea where to start with this one any pointers appreciated. Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone (023) 8024 3137 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 29 02:02:48 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 EFEEC16A41F for ; Mon, 29 Aug 2005 02:02:48 +0000 (GMT) (envelope-from adewole@sympatico.ca) Received: from BAYC1-PASMTP04.bayc1.hotmail.com (bayc1-pasmtp04.bayc1.hotmail.com [65.54.191.164]) by mx1.FreeBSD.org (Postfix) with ESMTP id B5C5D43D49 for ; Mon, 29 Aug 2005 02:02:48 +0000 (GMT) (envelope-from adewole@sympatico.ca) Message-ID: X-Originating-IP: [70.48.32.188] X-Originating-Email: [adewole@sympatico.ca] Received: from newton ([70.48.32.188]) by BAYC1-PASMTP04.bayc1.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.211); Sun, 28 Aug 2005 19:02:47 -0700 Message-ID: <002901c5ac3e$e7034c30$6501a8c0@newton> From: "Mike Adewole" To: Date: Sun, 28 Aug 2005 22:10:59 -0400 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.1506 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-OriginalArrivalTime: 29 Aug 2005 02:02:47.0981 (UTC) FILETIME=[C0EF2DD0:01C5AC3D] Subject: How to disable copy and paste in a virtual terminal ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2005 02:02:49 -0000 Can someone please tell me how to disable copy and paste in a virtual terminal ? I've tried recompiling the kernel with SC_NO_CUTPASTE but then the mouse pointer disappears completely from the console. It doesn't show with "vidcontrol -m on" nor from sysinstall/configure/mouse but it does show up in X. Thanks for any and all pointers. Mike From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 29 08:12:17 2005 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.org 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 4906216A41F; Mon, 29 Aug 2005 08:12:17 +0000 (GMT) (envelope-from bushman@rsu.ru) Received: from mail.r61.net (mail.r61.net [195.208.245.249]) by mx1.FreeBSD.org (Postfix) with ESMTP id AD7B643D49; Mon, 29 Aug 2005 08:12:16 +0000 (GMT) (envelope-from bushman@rsu.ru) Received: from stinger.cc.rsu.ru (stinger.cc.rsu.ru [195.208.252.82]) by mail.r61.net (8.13.4/8.13.4) with ESMTP id j7T8C5o4091247; Mon, 29 Aug 2005 12:12:05 +0400 (MSD) (envelope-from bushman@rsu.ru) Date: Mon, 29 Aug 2005 12:16:01 +0400 (MSD) From: Michael Bushkov X-X-Sender: bushman@stinger.cc.rsu.ru To: Doug Barton In-Reply-To: <43123F3B.8070002@FreeBSD.org> Message-ID: <20050829115740.N5409@stinger.cc.rsu.ru> References: <20050827170633.Y5409@stinger.cc.rsu.ru> <43123F3B.8070002@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV version 0.86.2, clamav-milter version 0.86 on asterix.r61.net X-Virus-Status: Clean X-Spam-Status: No, score=-5.7 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.0.4 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on asterix.r61.net Cc: Jacques Vidrine , freebsd-hackers@FreeBSD.org, freebsd-current@FreeBSD.org, Brooks Davis Subject: Re: [PATCH] caching daemon release and nsswitch patches X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2005 08:12:17 -0000 Hi, Doug! > I'm not sure what guidelines were given to you when you started the project, > but in reviewing your work the first thing I noticed was that you are not > following the guidelines in the style(9) man page. You should read that page, > and spend an afternoon reformatting your code to fit what is described there. > The most common error you've made is not following the 80 column rule, which > hopefully should be easily fixed. While one could argue with the specific > items in that page, and quite possibly be right, the idea of having a style > guideline is more to have a common format that we can all work towards than > to have a perfect format that we can all agree on. By reformatting your code > to fit this guideline you will greatly increase the chances that it will be > welcomed into the tree with open arms. > > The other style area that you should look at is your man pages. If you look > in /usr/share/examples/mdoc you will find the FreeBSD style guidelines for > man pages. The line wrapping issue comes into play here as well. We generally > don't go past column 60 in man pages, since that reduces CVS repo churn for > corrections down the road. Also, any time you have a full stop (period) at > the end of a sentence, you should start a new line. I think that you are also > using some macros that I'm not familiar with, although I'm not an mdoc > expert. Thank you very much for your suggestions - I'll reformat the code and man files. I've seemed to forget about style(9) in some places :( > > The other area that I'm interested in is how you plan to have cached interact > with DNS lookups, /etc/hosts, named, etc. If there was a project plan posted > somewhere on this already and I missed it, please accept my apologies, and > send along a reference. If not, I'm very interested to hear what your plans > are. > There is some information in my project's description here: http://wikitest.freebsd.org/moin.cgi/NsswitchAndCachingTechnicalDetails The "Integrating nsswitch and caching" describes the way that I use to make cached work. It can actually interact with any nsswitch database. All we need is to supply the special structure (in patches it is usually called "cache_info") with 3 functions pointers (*_id_func, *_marshal_func, *_unmarshal_func). These functions are used by nsdispatch during the caching of sccessful results. id_func identifies the key - the unique identifier, which will identify the data in the cache. And marshal_func/unmarshal_func pack/unpack data into/from the (char *)buffer. So almost all data, that go through nsdispatch calls, can be cached. And "struct hostent" and "struct addrinfo" are no exceptions to this rule. I already have the patch with *_id_func, *_marshal and *_unmarshal_func implemented for the "hosts" nsswitch database. I'll send it to the list along with the corrected version of the cached a bit later (in about 12 hours). P.S. the patched version of nsdispatch uses the functions that are implemented in nscache.c and nscachedcli.c files (they are present in the patch). With best regards, Michael From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 29 10:13:55 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 6CDE316A41F for ; Mon, 29 Aug 2005 10:13:55 +0000 (GMT) (envelope-from maarfree@xs4all.nl) Received: from smtp-vbr1.xs4all.nl (smtp-vbr1.xs4all.nl [194.109.24.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id D7C1343D48 for ; Mon, 29 Aug 2005 10:13:54 +0000 (GMT) (envelope-from maarfree@xs4all.nl) Received: from webmail.xs4all.nl (webmail7.xs4all.nl [194.109.22.167]) by smtp-vbr1.xs4all.nl (8.13.3/8.13.3) with ESMTP id j7TADrIi028544 for ; Mon, 29 Aug 2005 12:13:54 +0200 (CEST) (envelope-from maarfree@xs4all.nl) Received: from 194.151.102.253 by webmail.xs4all.nl with HTTP; Mon, 29 Aug 2005 12:13:53 +0200 (CEST) Message-ID: <4382.194.151.102.253.1125310433.squirrel@194.151.102.253> Date: Mon, 29 Aug 2005 12:13:53 +0200 (CEST) From: "Maarten" To: freebsd-hackers@freebsd.org User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by XS4ALL Virus Scanner Subject: PUC driver addition Sealevel cPCI 7203 possible X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: maarfree@xs4all.nl List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2005 10:13:55 -0000 Hi, Intro My company is currently using Linux as a platform for our own control software platform (all in c). We often have clashes between kernel and the rest in the sense of timings, priority handling etc. I feel Linux is not an OS but a kernel plus the rest which hampers us (too) often. My personal experience with FreeBSD is better, a nicely integrated platform being more complete and better documented. I am not a deep inside programmer, only an engineer that uses the packages provided, fixes minor application issues an goes in the field. I would like to convince my colleagues to consider FreeBSD. Good part is the software is rather easily ported, bad part is I am missing crucial support for a type of serial port card. Question Who can help me to add the correct entries - if possible- to src/sys/dev/puc/pucdata.c (as I understand from the sources) for this card: http://www.sealevel.com/product_detail.asp?product_id=497&PCI%5FRS%2D232%5FRS%2D422%5FRS%2D485%5FIsolated%5FSerial%5FInterface%5F The sealevel model no. 7203 that utilizes 16C850 UART. Our systems use 4 of these boards on a cPCI bus. Thank you, Maarten From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 29 10:46:50 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 4BEAD16A41F for ; Mon, 29 Aug 2005 10:46:50 +0000 (GMT) (envelope-from ticso@cicely12.cicely.de) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id AFB0343D45 for ; Mon, 29 Aug 2005 10:46:49 +0000 (GMT) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de (cicely5.cicely.de [10.1.1.7]) (authenticated bits=0) by srv1.cosmo-project.de (8.12.10/8.12.10) with ESMTP id j7TAkjBS071792 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Mon, 29 Aug 2005 12:46:47 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [10.1.1.14]) by cicely5.cicely.de (8.12.10/8.12.10) with ESMTP id j7TAkfKi084544 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 29 Aug 2005 12:46:42 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.12.11/8.12.11) with ESMTP id j7TAkfTd082701; Mon, 29 Aug 2005 12:46:41 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.12.11/8.12.11/Submit) id j7TAkeLt082700; Mon, 29 Aug 2005 12:46:40 +0200 (CEST) (envelope-from ticso) Date: Mon, 29 Aug 2005 12:46:40 +0200 From: Bernd Walter To: Maarten Message-ID: <20050829104640.GD37930@cicely12.cicely.de> References: <4382.194.151.102.253.1125310433.squirrel@194.151.102.253> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4382.194.151.102.253.1125310433.squirrel@194.151.102.253> X-Operating-System: FreeBSD cicely12.cicely.de 5.2-CURRENT alpha User-Agent: Mutt/1.5.9i X-Spam-Status: No, hits=-4.9 required=3.0 tests=BAYES_00 autolearn=ham version=2.64 X-Spam-Report: * -4.9 BAYES_00 BODY: Bayesian spam probability is 0 to 1% * [score: 0.0000] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on cicely12.cicely.de Cc: freebsd-hackers@freebsd.org Subject: Re: PUC driver addition Sealevel cPCI 7203 possible X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 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: Mon, 29 Aug 2005 10:46:50 -0000 On Mon, Aug 29, 2005 at 12:13:53PM +0200, Maarten wrote: > Hi, > > Intro > > My company is currently using Linux as a platform for our own control > software platform (all in c). We often have clashes between kernel and the > rest in the sense of timings, priority handling etc. I feel Linux is not > an OS but a kernel plus the rest which hampers us (too) often. My personal > experience with FreeBSD is better, a nicely integrated platform being more > complete and better documented. > I am not a deep inside programmer, only an engineer that uses the packages > provided, fixes minor application issues an goes in the field. I would > like to convince my colleagues to consider FreeBSD. Good part is the > software is rather easily ported, bad part is I am missing crucial support > for a type of serial port card. > > Question > > Who can help me to add the correct entries - if possible- to > src/sys/dev/puc/pucdata.c (as I understand from the sources) for this > card: > http://www.sealevel.com/product_detail.asp?product_id=497&PCI%5FRS%2D232%5FRS%2D422%5FRS%2D485%5FIsolated%5FSerial%5FInterface%5F > The sealevel model no. 7203 that utilizes 16C850 UART. > Our systems use 4 of these boards on a cPCI bus. At best you have vendor documentation on chip mappings, but usually one can guess the UART layout within the PCI mappings within a few trys once you know the mappings that a given card requests on PCI. Do a boot -v on a FreeBSD system with such a card plugged in to get the required PCI values. Try it with and without puc compiled in - maybe there is already support for that card. Once all chips are probed correctly you should tryout the xtals. Many cards use raised frequencies over PC traditional once, some cards even have different frequencies on their ports. Considered the documented 460.8k rates I would asume COM_FREQ * 4. Proper identification of such cards is sometimes troublesome. In many cases different cards identify themself identic and the kernel won't know the correct configuration to use. It is advised not to mix different puc cards to avoid such situations. Fortunately the 16C850 have large FiFos - with traditional 16C550 FiFo sizes you easily get into troubles even with moderate speeds, especially if your interrupts are shared with non-sio devices and you can't use PUC_FASTINTR. Nevertheless a configuration with PUC_FASTINTR is still prefered. -- B.Walter BWCT http://www.bwct.de bernd@bwct.de info@bwct.de From owner-freebsd-hackers@FreeBSD.ORG Sun Aug 28 13:35:43 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 1957116A41F; Sun, 28 Aug 2005 13:35:43 +0000 (GMT) (envelope-from avg@icyb.net.ua) Received: from dr.sm.ukrtel.net (dr.sm.ukrtel.net [213.179.236.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 70DB743D46; Sun, 28 Aug 2005 13:35:41 +0000 (GMT) (envelope-from avg@icyb.net.ua) Received: from [213.179.237.42] (trost-dialup-3.sm.ukrtel.net [213.179.237.42] (may be forged)) by dr.sm.ukrtel.net (8.12.10/8.12.10) with ESMTP id j7SDZcLG071739; Sun, 28 Aug 2005 16:35:39 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4311BDAD.1010803@icyb.net.ua> Date: Sun, 28 Aug 2005 16:35:41 +0300 From: Andriy Gapon User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050706) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=KOI8-U Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.86.2/1045/Sun Aug 28 15:03:55 2005 on dr.sm.ukrtel.net X-Virus-Status: Clean X-Mailman-Approved-At: Mon, 29 Aug 2005 11:52:51 +0000 Subject: ntpd and cmos clock update X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Aug 2005 13:35:43 -0000 I think I saw more than once speculations that FreeBSD updates CMOS clock when time is set, so CMOS clock value should always be very close to internal OS timer. But I always took it with a grain of salt because every time I reboot after long uptime period I see messages from ntpd about adjusting clock by many seconds and such discrepancy should not occur, of course, during couple of minutes that reboot takes. Recently this question (re-)surfaced in Russian language BSD newsgroup and I thought that a wider community might be interested. It seems that CMOS clock is updated using resettodr(9) function. There seem to be only a few occasions when this function is called: 1. clock_settime(ClOCK_REALTIME) // through kern_time.c:settime() 2. settimeofday() // through kern_time.c:settime() 3. machdep.adjkerntz sysctl is set I believe that ntpd calls settime-family functions only if time offset is larger than 128ms (or maybe I am thinking about ntpdate), but normally it uses ntp_adjtime() to adjust time keeping. Obviosuly, a system running ntpd with good enough hardware clock and good enough connection to good enough ntp server(s) would use the latter method all of the time after some initial stabilization period. But it seems that time changes are never propagated to CMOS in this case, thus leading to behavior mentioned in the beginning. This is not a big problem, of course, but quite an annoyance (sometimes). I wonder what could be the best solution to this issue. One idea is to always update CMOS from adjkerntz(8) upon shutdown/reboot, but this would not help if system crashes, but adjkerntz could also do it periodically. Any ideas ? Is it worth concern at all ? -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 29 12:11:44 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 E0E5E16A41F for ; Mon, 29 Aug 2005 12:11:44 +0000 (GMT) (envelope-from bharath.bhushan@gmail.com) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.200]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7B11643D48 for ; Mon, 29 Aug 2005 12:11:44 +0000 (GMT) (envelope-from bharath.bhushan@gmail.com) Received: by rproxy.gmail.com with SMTP id r35so988709rna for ; Mon, 29 Aug 2005 05:11:43 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=r6cy26+R5Td3KiomgAYqVJJo0oSasD2Cq0xHMdW0AompuN6C7dGbRMQa85VnJnQHTr4QkPvgdH9pP1Pd/82Y+w4UJE3c01lwFi8b2Kf6AkAzfHuc+jZ8f5GX7LaiJzqitl88LqHji58d+AE5shF2jNkhlxDAhR5EHGIyH7zi8uk= Received: by 10.38.12.74 with SMTP id 74mr286309rnl; Mon, 29 Aug 2005 05:11:43 -0700 (PDT) Received: by 10.38.207.15 with HTTP; Mon, 29 Aug 2005 05:11:43 -0700 (PDT) Message-ID: <29683db2050829051168d821be@mail.gmail.com> Date: Mon, 29 Aug 2005 17:41:43 +0530 From: Bharath Bhushan To: freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: interrupt handlers - FreeBSD 4.9 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2005 12:11:45 -0000 1) What is the purpose of the two interrupt handler arrays ihandler[] and intr_handlers[]? What I saw on my system: (kgdb) print intr_handler $8 =3D {0x302b2d04 , 0x302b9bd4 , 0x302b6708 , 0x302be648 , 0x302be648 , 0x302b6708 , 0x302b53e0 , 0x30268128 , 0x302b2fa0 , 0x302b6708 , 0x302b6708 , 0x30268128 , 0x302b6708 , 0x302b6708 , 0x3017606c , 0x3017606c } (kgdb) p/a ihandlers $11 =3D 0x302a522e (kgdb) p/a *ihandlers $12 =3D 0x1ec05ff 2) Does cpl contain the mask to block hardware and software interrupts or just for the software interrupts? --=20 Thanks Bharath From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 29 12:20:58 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 8154D16A420 for ; Mon, 29 Aug 2005 12:20:58 +0000 (GMT) (envelope-from dmitry.mityugov@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id D393743D48 for ; Mon, 29 Aug 2005 12:20:57 +0000 (GMT) (envelope-from dmitry.mityugov@gmail.com) Received: by wproxy.gmail.com with SMTP id 55so570260wri for ; Mon, 29 Aug 2005 05:20:57 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=VrobTg4FjlpOF/hEfkF3lXyVHX3xYVCgdP/efe8tXJ+XrwpErmhWXWL4pWeRpkPEED/AHrWxwbDI6Rb0JHHVlM67DbOSJMDBm1SkEgZuu4ibSUi5vu/yYXHkZ/IBCD2Isc9eWgvMSD9goJBxP5RHQPL6w6FGUXaHDirTETaor5A= Received: by 10.54.82.19 with SMTP id f19mr6369632wrb; Mon, 29 Aug 2005 05:20:56 -0700 (PDT) Received: by 10.54.56.33 with HTTP; Mon, 29 Aug 2005 05:20:56 -0700 (PDT) Message-ID: Date: Mon, 29 Aug 2005 16:20:56 +0400 From: Dmitry Mityugov To: freebsd-hackers@freebsd.org In-Reply-To: <4311BDAD.1010803@icyb.net.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <4311BDAD.1010803@icyb.net.ua> Subject: Re: ntpd and cmos clock update X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2005 12:20:58 -0000 On 8/28/05, Andriy Gapon wrote: >=20 > I think I saw more than once speculations that FreeBSD updates CMOS > clock when time is set, so CMOS clock value should always be very close > to internal OS timer. But I always took it with a grain of salt because > every time I reboot after long uptime period I see messages from ntpd > about adjusting clock by many seconds and such discrepancy should not > occur, of course, during couple of minutes that reboot takes. ... That's why I always thought that ntpd did not work in FreeBSD 5.x! --=20 Dmitry Mityugov, St. Petersburg, Russia I ignore all messages with confidentiality statements "We live less by imagination than despite it" - Rockwell Kent, "N by E" From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 29 15:28:12 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 EF88916A41F for ; Mon, 29 Aug 2005 15:28:12 +0000 (GMT) (envelope-from dwmalone@maths.tcd.ie) Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by mx1.FreeBSD.org (Postfix) with SMTP id 0AD5D43D45 for ; Mon, 29 Aug 2005 15:28:11 +0000 (GMT) (envelope-from dwmalone@maths.tcd.ie) Received: from walton.maths.tcd.ie ([134.226.81.10] helo=walton.maths.tcd.ie) by salmon.maths.tcd.ie with SMTP id ; 29 Aug 2005 16:28:10 +0100 (BST) Date: Mon, 29 Aug 2005 16:28:10 +0100 From: David Malone To: Steven Hartland Message-ID: <20050829152810.GA26150@walton.maths.tcd.ie> References: <000201c5ac2a$df2d2990$5cf829d9@multiplay.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000201c5ac2a$df2d2990$5cf829d9@multiplay.co.uk> User-Agent: Mutt/1.5.6i Sender: dwmalone@maths.tcd.ie Cc: freebsd-hackers@freebsd.org Subject: Re: bge driver internal routing issues? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2005 15:28:13 -0000 On Sun, Aug 28, 2005 at 09:06:47PM +0100, Steven Hartland wrote: > Having a really odd problem here where udp queries to > servers running on machines with bge cards dont respond > via ip address that are being bound on: Can you run "tcpdump -s 0 -vvv port 1234" on the client (replace port 1234 with the port number for the service). See if tcpdump shows a reply packet, and if it does see if the checksum is reported OK. It could be that the checksum offloading on the bge card is busted. (You could also check "netstat -s" on the client to see if it shows many bad checksums in the UDP section.) David. From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 29 15:56:29 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 C021916A41F; Mon, 29 Aug 2005 15:56:29 +0000 (GMT) (envelope-from bart@it-ss.be) Received: from piggy.solidweb.be (piggy.web.bru.it-ss.be [195.28.164.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1DE4943D45; Mon, 29 Aug 2005 15:56:28 +0000 (GMT) (envelope-from bart@it-ss.be) Received: from bartwrkstxp (214.120-136-217.adsl.skynet.be [217.136.120.214]) (authenticated bits=0) by piggy.solidweb.be (8.12.9-SW.b/8.12.9-SW) with ESMTP id j7TFuQuM001491; Mon, 29 Aug 2005 17:56:26 +0200 Message-ID: <001301c5acb2$36d8c820$020b000a@bartwrkstxp> From: "Bart Van Kerckhove" To: , Date: Mon, 29 Aug 2005 17:56:25 +0200 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_000E_01C5ACC2.F97C6840" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2527 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 X-Scanned-By: MIMEDefang 2.45 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Feature requests / inquiries. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2005 15:56:29 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_000E_01C5ACC2.F97C6840 Content-Type: multipart/mixed; boundary="----=_NextPart_001_000F_01C5ACC2.F97C6840" ------=_NextPart_001_000F_01C5ACC2.F97C6840 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Dear Sirs / Fellow Freebsd Freaks, I've been using FreeBSD for a while now as a routing/firewalling platform, but recent developments in our network infrastructure confront me with some lack of features in the IPstack. In a nutshell, i'm looking for support for (in order of importance to me) : (r)STP, ECMP, and LACP. For STP, i have found a patch that contained a port from netbsd code of if_bridge ; but i'm way too insecure about running this on a production system. For ECMP, the only thing i found out was that there used to be a patchset that did something like it, but went defunct after 4.8. LACP: no idea at all, sorry :) As these are features we'll be using some time soon now, i can say we _need_ them. I have even seriously considered moving to NetBSD; the lack of NIC polling support for the intel chipsets i'm using is holding me back at the moment. I do not want to move over to linux, for various reasons. So I figured perhaps some of the freebsd community is also interested in these features, and I might as well sponsor (part of?) its development. Are there any persons interested in developing these features, or do they already exist and am I just plain ignorant (forgive me if that is the case). Please note that i'm not interested in the netgraph approach, as that's (imho) just a hack around it, and it's not functioning with for example gnu/zebra et all. I am looking for short- and long-term solutions, anything that's developed trough sponsoring i'd be happy to contribute to the main tree. As this would be the first time we actually ask for a specific feature in any OSS software, I could be way off the scale with the figures i had in mind. This would be about 200 to 400 euro per feature, the more important ones like STP and ECMP are totally open to discussion. Any takers? Any enlightenment? Thanks for helping out in advance ;) Met vriendelijke groet / With kind regards, Bart Van Kerckhove bart@it-ss.be ------=_NextPart_001_000F_01C5ACC2.F97C6840-- ------=_NextPart_000_000E_01C5ACC2.F97C6840 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIIuzCCAkMw ggGsoAMCAQICAw01XTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQxMDExMjIzNTM0WhcNMDUxMDExMjIzNTM0WjA/MR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMRwwGgYJKoZIhvcNAQkBFg1iYXJ0QGl0LXNzLmJlMIGf MA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDcXRnz65y7RnzVqshaaMreBgPt64Dbc39xCH8Yl5ge zYC1Z91aL2cvglhZNEdf+LPOzOSjDN2N91RIJdrMHE6I/MSot7+B2KeWfYwCoUhyY4ojbr6XChHS kNqMDL1IO3f3HqJEsmH006rT/ZAE1++wwPQf5Geuaj7kpqPRKajiwQIDAQABoyowKDAYBgNVHREE ETAPgQ1iYXJ0QGl0LXNzLmJlMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAeCZFAwf1 hu+mCKdH7rdHBzQO+6nel5FUBiUoeje2N0S00T6psemcwkt0T2YnVecNWZXyk0SZTuSSKoNcUxnJ ZHc9OlqyLVP9a/YyaxfUZ5U+4EAN7Gx2zvGlBtbvlUrtflvRL1Fj0YdrZKhVbhuFeQtolUeR60ir h3J+Yhke7nYwggMtMIIClqADAgECAgEAMA0GCSqGSIb3DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEV MBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0 ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQw IgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNv bmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNOTYwMTAxMDAwMDAwWhcNMjAxMjMxMjM1OTU5WjCB 0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2 aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJ KoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDUadfUsJRkW3HpR9gMUbbqcpGwhF59LQ2PexLfhSV1KHQ6QixjJ5+Ve0vvfhmH HYbqo925zpZkGsIUbkSsfOaP6E0PcR9AOKYAo4d49vmUhl6t6sBeduvZFKNdbnp8DKVLVX8GGSl/ npom1Wq7OCQIapjHsdqjmJH9edvlWsQcuQIDAQABoxMwETAPBgNVHRMBAf8EBTADAQH/MA0GCSqG SIb3DQEBBAUAA4GBAMfskn5O+PWWpWdiKqTwTRFg0G+NYFhhrCa7UjVcCM8w+6hKloofYkIjjBcP 9LpknBesRynfnZhe0mxgcVyirNx54+duAEcftQ0o6AKd5Jr9E/Sm2Xyx+NxfIyYJkYBz0BQb3kOp gyXy5pwvFcr+pquKB3WLDN1RhGvk+NHOd6KBMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUF ADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBU b3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSsw KQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAw MFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7s vc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV 84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGR MBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUu Y29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCk HjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oL LswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoL gnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHT HUb/XV9lTzGCAcwwggHIAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAgMNNV0wCQYFKw4DAhoFAKCBujAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0wNTA4MjkxNTU2MjVaMCMGCSqGSIb3DQEJBDEWBBTfB7TizdB/TOp7IQPLWJ+o L4YNxzBbBgkqhkiG9w0BCQ8xTjBMMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG 9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCHTANBgkqhkiG9w0BAQEFAASB gFpmlcj7vdPzGnjAGOhguwbZLSZq+Lem+SMtW83LicqB4ARPK+WgmenKzdHGKPMln+SnCuUG9zLa h7PKWF9xIpcgkqWGgtZKZCNuPs28Y/a9FZThnUdcanptMhwhLC3/LQfgVGT8lV7/VeD2ZXMnuiMH KQlb/JJ4gombEH3O5ku2AAAAAAAA ------=_NextPart_000_000E_01C5ACC2.F97C6840-- From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 29 15:56:39 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 8A13E16A433 for ; Mon, 29 Aug 2005 15:56:39 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8FF8E43D46 for ; Mon, 29 Aug 2005 15:56:38 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from [10.50.40.201] (Not Verified[10.50.40.201]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Mon, 29 Aug 2005 12:11:54 -0400 From: John Baldwin To: freebsd-hackers@freebsd.org Date: Mon, 29 Aug 2005 11:39:16 -0400 User-Agent: KMail/1.8 References: <29683db2050829051168d821be@mail.gmail.com> In-Reply-To: <29683db2050829051168d821be@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200508291139.17144.jhb@FreeBSD.org> Cc: Bharath Bhushan Subject: Re: interrupt handlers - FreeBSD 4.9 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2005 15:56:39 -0000 On Monday 29 August 2005 08:11 am, Bharath Bhushan wrote: > 1) What is the purpose of the two interrupt handler arrays ihandler[] > and intr_handlers[]? Not sure. It may be that ihandler is used for INTR_FAST interrupts. > What I saw on my system: > (kgdb) print intr_handler > $8 = {0x302b2d04 , 0x302b9bd4 , > 0x302b6708 , 0x302be648 , 0x302be648 , > 0x302b6708 , 0x302b53e0 , 0x30268128 , > 0x302b2fa0 , 0x302b6708 , > 0x302b6708 , 0x30268128 , > 0x302b6708 , 0x302b6708 , > 0x3017606c , 0x3017606c } > (kgdb) p/a ihandlers > $11 = 0x302a522e > (kgdb) p/a *ihandlers > $12 = 0x1ec05ff > > 2) Does cpl contain the mask to block hardware and software interrupts > or just for the software interrupts? Both. SWI is the upper 8 bits, lower 24 are for hardware. (24 are used with APIC_IO, 16 with the 8259A pics). -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 29 15:56:40 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 3B9FE16A42A for ; Mon, 29 Aug 2005 15:56:40 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 53A8143D4C for ; Mon, 29 Aug 2005 15:56:38 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from [10.50.40.201] (Not Verified[10.50.40.201]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Mon, 29 Aug 2005 12:11:53 -0400 From: John Baldwin To: freebsd-hackers@freebsd.org Date: Mon, 29 Aug 2005 11:36:14 -0400 User-Agent: KMail/1.8 References: <20050828143239.GA64597@skatecity> In-Reply-To: <20050828143239.GA64597@skatecity> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200508291136.15662.jhb@FreeBSD.org> Cc: Subject: Re: Syscall/Sysret state on i386 arch X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2005 15:56:40 -0000 On Sunday 28 August 2005 10:32 am, alexander wrote: > The AMD64 arch is using the syscall/sysret opcodes instead of int80h to > perform a syscall (/usr/src/lib/libc/amd64/SYS.h). I just checked the > output my of dmesg and it says: > > CPU: AMD Duron(tm) Processor (1311.69-MHz 686-class CPU) > Origin = "AuthenticAMD" Id = 0x671 Stepping = 1 > > Features=0x383f9ff,\ PAT,PSE36,MMX,FXSR,SSE> > AMD Features=0xc0400800 > > I got a hold of the AMD document number 21086.pdf. It describes both > opcodes pretty well, but doesn't tell which CPUs support the new opcodes. > But since the first revision of that document is dated Sept 1997 quite a > lot of i386 CPU's should support the opcodes. The NASM manual only states > [P6,AMD] as the required CPU to perform those opcodes. > > I found some patches for Linux that replace the int80h syscall calling > > convention with syscall/sysret on i386 and the results look pretty convincing: > > (INT $0x80 based getpid(), got pid 497) latency:282 cycles > > (SYSENTER based getpid(), got pid 497) latency:138 cycles > > > > on a 266 MHz PII this is 0.51 usecs for a getpid(). (was 1.06 usecs) > > Quoted from: http://www.ussg.iu.edu/hypermail/linux/kernel/9806.1/0878.html > > Does anybody know more about this? Is it even possible to replace the > current syscall implementation that easily or would that require elaborate > changes to all the syscalls (libc), etc. And which CPU's support these new > opcodes? Doesn anybody know if the Linux patches actually got comitted to > the official kernel? Support for syscall/sysret is determined by a cpuid flag. I do believe someone has worked on either syscall/sysret or sysenter/sysexit support in a p4 branch. You can try asking jeff@ about it. I think it was sysenter/sysexit and it didn't really improve things much. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 29 16:16:51 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 6341D16A41F; Mon, 29 Aug 2005 16:16:51 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id CCE0E43D49; Mon, 29 Aug 2005 16:16:48 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.3/8.13.3) with ESMTP id j7TGPbau028948; Mon, 29 Aug 2005 10:25:37 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <431334E0.20702@samsco.org> Date: Mon, 29 Aug 2005 10:16:32 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.8) Gecko/20050615 X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Baldwin References: <20050828143239.GA64597@skatecity> <200508291136.15662.jhb@FreeBSD.org> In-Reply-To: <200508291136.15662.jhb@FreeBSD.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org Cc: freebsd-hackers@freebsd.org Subject: Re: Syscall/Sysret state on i386 arch X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2005 16:16:51 -0000 John Baldwin wrote: > On Sunday 28 August 2005 10:32 am, alexander wrote: > >>The AMD64 arch is using the syscall/sysret opcodes instead of int80h to >>perform a syscall (/usr/src/lib/libc/amd64/SYS.h). I just checked the >>output my of dmesg and it says: >> >>CPU: AMD Duron(tm) Processor (1311.69-MHz 686-class CPU) >> Origin = "AuthenticAMD" Id = 0x671 Stepping = 1 >> >>Features=0x383f9ff>,\ PAT,PSE36,MMX,FXSR,SSE> >> AMD Features=0xc0400800 >> >>I got a hold of the AMD document number 21086.pdf. It describes both >>opcodes pretty well, but doesn't tell which CPUs support the new opcodes. >>But since the first revision of that document is dated Sept 1997 quite a >>lot of i386 CPU's should support the opcodes. The NASM manual only states >>[P6,AMD] as the required CPU to perform those opcodes. >> >>I found some patches for Linux that replace the int80h syscall calling >> >>convention with syscall/sysret on i386 and the results look pretty > > convincing: > >>>(INT $0x80 based getpid(), got pid 497) latency:282 cycles >>>(SYSENTER based getpid(), got pid 497) latency:138 cycles >>> >>>on a 266 MHz PII this is 0.51 usecs for a getpid(). (was 1.06 usecs) >> >>Quoted from: http://www.ussg.iu.edu/hypermail/linux/kernel/9806.1/0878.html >> >>Does anybody know more about this? Is it even possible to replace the >>current syscall implementation that easily or would that require elaborate >>changes to all the syscalls (libc), etc. And which CPU's support these new >>opcodes? Doesn anybody know if the Linux patches actually got comitted to >>the official kernel? > > > Support for syscall/sysret is determined by a cpuid flag. I do believe > someone has worked on either syscall/sysret or sysenter/sysexit support in a > p4 branch. You can try asking jeff@ about it. I think it was > sysenter/sysexit and it didn't really improve things much. > Actually, the results were fairly inconclusive because it was also somewhat unstable under real loads. The work is in Perforce under //depot/user/jeff/sysenter/... I've worked on this branch also, but not in a few months. I can make patches if anyone is interested. Scott From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 29 16:30:29 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 C764F16A41F; Mon, 29 Aug 2005 16:30:29 +0000 (GMT) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 484E043D55; Mon, 29 Aug 2005 16:30:29 +0000 (GMT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.13.1/8.13.3) id j7TGUQGB003862; Mon, 29 Aug 2005 11:30:26 -0500 (CDT) (envelope-from dan) Date: Mon, 29 Aug 2005 11:30:26 -0500 From: Dan Nelson To: Michael Bushkov Message-ID: <20050829163025.GA25664@dan.emsphone.com> References: <20050827170633.Y5409@stinger.cc.rsu.ru> <43123F3B.8070002@FreeBSD.org> <20050829115740.N5409@stinger.cc.rsu.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050829115740.N5409@stinger.cc.rsu.ru> X-OS: FreeBSD 5.4-STABLE X-message-flag: Outlook Error User-Agent: Mutt/1.5.9i Cc: Jacques Vidrine , freebsd-hackers@freebsd.org, Doug Barton , Brooks Davis , freebsd-current@freebsd.org Subject: Re: [PATCH] caching daemon release and nsswitch patches X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2005 16:30:30 -0000 In the last episode (Aug 29), Michael Bushkov said: > There is some information in my project's description here: > http://wikitest.freebsd.org/moin.cgi/NsswitchAndCachingTechnicalDetails One question that comes to mind: It looks like the end-user application is still responsible for performing nss lookups. How do you ensure that one user can't poison the cache and cause problems for other users? Could cached do all nss operations itself (making it more like nscd in other OSes)? -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 29 17:50:30 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 9921C16A420; Mon, 29 Aug 2005 17:50:30 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3BFC243D46; Mon, 29 Aug 2005 17:50:30 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j7THoThW024833; Mon, 29 Aug 2005 10:50:29 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j7THoTPc024832; Mon, 29 Aug 2005 10:50:29 -0700 Date: Mon, 29 Aug 2005 10:50:29 -0700 From: Brooks Davis To: Bart Van Kerckhove Message-ID: <20050829175029.GC18276@odin.ac.hmc.edu> References: <001301c5acb2$36d8c820$020b000a@bartwrkstxp> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="kfjH4zxOES6UT95V" Content-Disposition: inline In-Reply-To: <001301c5acb2$36d8c820$020b000a@bartwrkstxp> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=1.2 required=8.0 tests=DEAR_SOMETHING autolearn=no version=2.63 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu Cc: freebsd-net@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: Feature requests / inquiries. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2005 17:50:30 -0000 --kfjH4zxOES6UT95V Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 29, 2005 at 05:56:25PM +0200, Bart Van Kerckhove wrote: > Dear Sirs / Fellow Freebsd Freaks, >=20 > I've been using FreeBSD for a while now as a routing/firewalling platform= ,=20 > but recent developments in our network infrastructure confront me with so= me=20 > lack of features in the IPstack. > In a nutshell, i'm looking for support for (in order of importance to me)= :=20 > (r)STP, ECMP, and LACP. >=20 > For STP, i have found a patch that contained a port from netbsd code of= =20 > if_bridge ; but i'm way too insecure about running this on a production= =20 > system. > For ECMP, the only thing i found out was that there used to be a patchset= =20 > that did something like it, but went defunct after 4.8. > LACP: no idea at all, sorry :) >=20 > As these are features we'll be using some time soon now, i can say we _ne= ed_=20 > them. I have even seriously considered moving to NetBSD; the lack of NIC= =20 > polling support for the intel chipsets i'm using is holding me back at th= e=20 > moment. > I do not want to move over to linux, for various reasons. > So I figured perhaps some of the freebsd community is also interested in= =20 > these features, and I might as well sponsor (part of?) its development. > Are there any persons interested in developing these features, or do they= =20 > already exist and am I just plain ignorant (forgive me if that is the cas= e). > Please note that i'm not interested in the netgraph approach, as that's= =20 > (imho) just a hack around it, and it's not functioning with for example= =20 > gnu/zebra et all. >=20 > I am looking for short- and long-term solutions, anything that's develope= d=20 > trough sponsoring i'd be happy to contribute to the main tree. > As this would be the first time we actually ask for a specific feature in= =20 > any OSS software, I could be way off the scale with the figures i had in= =20 > mind. This would be about 200 to 400 euro per feature, the more important= =20 > ones like STP and ECMP are totally open to discussion. >=20 > Any takers? Any enlightenment? Thanks for helping out in advance ;) if_bridge has been imported into FreeBSD 6.0 and I believe will be merged to 5.x before 5.5. I can't speak for ECMP. LACP is supported by ng_fec. The fact that you don't like it is a seperate issue. FWIW, ng_fec only uses netgraph for configuration. It's not really a netgraph node. I'd personally like to see OpenBSD's if_trunk imported and LACP added, but I certainly don't have time. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --kfjH4zxOES6UT95V Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFDE0rkXY6L6fI4GtQRApefAKDbdyHzzCmHZ7BnZGChhbQLxAVEwACdEW92 iocKsjpSP5AlO5d5xbj5+Mg= =Swf+ -----END PGP SIGNATURE----- --kfjH4zxOES6UT95V-- From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 29 18:10:09 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 1FA3416A420; Mon, 29 Aug 2005 18:10:09 +0000 (GMT) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6F9FA43D48; Mon, 29 Aug 2005 18:10:08 +0000 (GMT) (envelope-from max@love2party.net) Received: from p54A3D18F.dip.t-dialin.net [84.163.209.143] (helo=donor.laier.local) by mrelayeu.kundenserver.de with ESMTP (Nemesis), id 0MKxQS-1E9o56148z-0004Si; Mon, 29 Aug 2005 20:10:04 +0200 From: Max Laier To: freebsd-net@freebsd.org Date: Mon, 29 Aug 2005 20:09:43 +0200 User-Agent: KMail/1.8.2 References: <001301c5acb2$36d8c820$020b000a@bartwrkstxp> <20050829175029.GC18276@odin.ac.hmc.edu> In-Reply-To: <20050829175029.GC18276@odin.ac.hmc.edu> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2886264.EKM6Mzy3H5"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200508292010.02732.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 Cc: freebsd-hackers@freebsd.org, Bart Van Kerckhove , thompsa@freebsd.org Subject: Re: Feature requests / inquiries. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2005 18:10:09 -0000 --nextPart2886264.EKM6Mzy3H5 Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Monday 29 August 2005 19:50, Brooks Davis wrote: > On Mon, Aug 29, 2005 at 05:56:25PM +0200, Bart Van Kerckhove wrote: > > Dear Sirs / Fellow Freebsd Freaks, > > > > I've been using FreeBSD for a while now as a routing/firewalling > > platform, but recent developments in our network infrastructure confront > > me with some lack of features in the IPstack. > > In a nutshell, i'm looking for support for (in order of importance to m= e) > > : (r)STP, ECMP, and LACP. > > > > For STP, i have found a patch that contained a port from netbsd code of > > if_bridge ; but i'm way too insecure about running this on a production > > system. > > For ECMP, the only thing i found out was that there used to be a patchs= et > > that did something like it, but went defunct after 4.8. > > LACP: no idea at all, sorry :) > > > > As these are features we'll be using some time soon now, i can say we > > _need_ them. I have even seriously considered moving to NetBSD; the lack > > of NIC polling support for the intel chipsets i'm using is holding me > > back at the moment. > > I do not want to move over to linux, for various reasons. > > So I figured perhaps some of the freebsd community is also interested in > > these features, and I might as well sponsor (part of?) its development. > > Are there any persons interested in developing these features, or do th= ey > > already exist and am I just plain ignorant (forgive me if that is the > > case). Please note that i'm not interested in the netgraph approach, as > > that's (imho) just a hack around it, and it's not functioning with for > > example gnu/zebra et all. > > > > I am looking for short- and long-term solutions, anything that's > > developed trough sponsoring i'd be happy to contribute to the main tree. > > As this would be the first time we actually ask for a specific feature = in > > any OSS software, I could be way off the scale with the figures i had in > > mind. This would be about 200 to 400 euro per feature, the more importa= nt > > ones like STP and ECMP are totally open to discussion. > > > > Any takers? Any enlightenment? Thanks for helping out in advance ;) > > if_bridge has been imported into FreeBSD 6.0 and I believe will be > merged to 5.x before 5.5. A candidate MFC patchset is at:=20 http://people.freebsd.org/~thompsa/if_bridge-5stable.diff and is believed t= o=20 be production quality (judging from the reports for RELENG_6 so far). Ther= e=20 might be minor problems and/or yet undiscovered problems, but only testing= =20 gets it there. Andrew is certainly thankful for any feedback! > I can't speak for ECMP. > > LACP is supported by ng_fec. The fact that you don't like it is a > seperate issue. FWIW, ng_fec only uses netgraph for configuration. > It's not really a netgraph node. I'd personally like to see OpenBSD's > if_trunk imported and LACP added, but I certainly don't have time. It's certainly a good idea to look at if_trunk. I don't have hardware to=20 build a testbed, but I belive there are people out there who do and also ha= ve=20 the skills to make it happen. The main problem is: Whoever does this must= =20 have (physical) access to a reasonable testbed and free time while there=20 (i.e. agreement with employer etc) =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart2886264.EKM6Mzy3H5 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQBDE096XyyEoT62BG0RAgv8AJ4tDYC03S7+81PgNVwdX3sLIYpSbwCcCY+X +Vp4qPfdZCumMDFJ+mdmDnY= =XBn3 -----END PGP SIGNATURE----- --nextPart2886264.EKM6Mzy3H5-- From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 29 18:44:18 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 B9DC416A420 for ; Mon, 29 Aug 2005 18:44:18 +0000 (GMT) (envelope-from arundel@h3c.de) Received: from enterprise4.noxa.de (enterprise.noxa.de [212.60.197.71]) by mx1.FreeBSD.org (Postfix) with ESMTP id B949743D45 for ; Mon, 29 Aug 2005 18:44:17 +0000 (GMT) (envelope-from arundel@h3c.de) Received: (qmail 30113 invoked from network); 29 Aug 2005 20:44:15 +0200 Received: from p508fd82e.dip.t-dialin.net (HELO localhost.skatecity) (80.143.216.46) by enterprise.noxa.de with AES256-SHA encrypted SMTP; 29 Aug 2005 20:44:15 +0200 Received: from localhost.skatecity (nobody@localhost.skatecity [127.0.0.1]) by localhost.skatecity (8.13.4/8.13.4) with ESMTP id j7TIi8jH096192 for ; Mon, 29 Aug 2005 20:44:09 +0200 (CEST) (envelope-from arundel@localhost.skatecity) Received: (from arundel@localhost) by localhost.skatecity (8.13.4/8.13.4/Submit) id j7TIi8md096191 for freebsd-hackers@freebsd.org; Mon, 29 Aug 2005 20:44:08 +0200 (CEST) (envelope-from arundel) From: Alexander Best Date: Mon, 29 Aug 2005 20:44:08 +0200 To: freebsd-hackers@freebsd.org Message-ID: <20050829184408.GA95840@skatecity> Mail-Followup-To: freebsd-hackers@freebsd.org References: <20050828143239.GA64597@skatecity> <200508291136.15662.jhb@FreeBSD.org> <431334E0.20702@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <431334E0.20702@samsco.org> User-Agent: Mutt/1.4.2.1i Organisation: =?iso-8859-15?Q?Westfl=E4lische_Wilhelms-U?= =?iso-8859-15?Q?niversit=E4t_M=FCnster?= Subject: Re: Syscall/Sysret state on i386 arch X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2005 18:44:19 -0000 On Mon Aug 29 05, Scott Long wrote: > > Actually, the results were fairly inconclusive because it was also > somewhat unstable under real loads. > > The work is in Perforce under > > //depot/user/jeff/sysenter/... > > I've worked on this branch also, but not in a few months. I can > make patches if anyone is interested. > > Scott That would be awsome. I'd defenately check it out, because I'm really interested to see how syscall/sysret compares to the current way of doing syscalls. Maybe somebody can comment on the speed increase that was gained by replacing int80h in the AMD64 branch. I just had a look at lib/libc/amd64/SYS.h and it seems they decided to use syscall/sysret instead of int80h about 2 years ago: > Revision 1.25 (Wed Apr 30 18:06:14 2003 UTC (2 years, 4 months ago) by peter) Cheers From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 29 18:47:14 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 24BA616A41F; Mon, 29 Aug 2005 18:47:14 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3733843D49; Mon, 29 Aug 2005 18:47:13 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j7TIlCgf001027; Mon, 29 Aug 2005 11:47:12 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j7TIlCta001026; Mon, 29 Aug 2005 11:47:12 -0700 Date: Mon, 29 Aug 2005 11:47:12 -0700 From: Brooks Davis To: Max Laier Message-ID: <20050829184712.GF18276@odin.ac.hmc.edu> References: <001301c5acb2$36d8c820$020b000a@bartwrkstxp> <20050829175029.GC18276@odin.ac.hmc.edu> <200508292010.02732.max@love2party.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="WlEyl6ow+jlIgNUh" Content-Disposition: inline In-Reply-To: <200508292010.02732.max@love2party.net> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=1.2 required=8.0 tests=DEAR_SOMETHING autolearn=no version=2.63 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu Cc: freebsd-net@freebsd.org, Bart Van Kerckhove , thompsa@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: Feature requests / inquiries. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2005 18:47:14 -0000 --WlEyl6ow+jlIgNUh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 29, 2005 at 08:09:43PM +0200, Max Laier wrote: > On Monday 29 August 2005 19:50, Brooks Davis wrote: > > On Mon, Aug 29, 2005 at 05:56:25PM +0200, Bart Van Kerckhove wrote: > > > Dear Sirs / Fellow Freebsd Freaks, > > > > > > I've been using FreeBSD for a while now as a routing/firewalling > > > platform, but recent developments in our network infrastructure confr= ont > > > me with some lack of features in the IPstack. > > > In a nutshell, i'm looking for support for (in order of importance to= me) > > > : (r)STP, ECMP, and LACP. > > > > > > For STP, i have found a patch that contained a port from netbsd code = of > > > if_bridge ; but i'm way too insecure about running this on a producti= on > > > system. > > > For ECMP, the only thing i found out was that there used to be a patc= hset > > > that did something like it, but went defunct after 4.8. > > > LACP: no idea at all, sorry :) > > > > > > As these are features we'll be using some time soon now, i can say we > > > _need_ them. I have even seriously considered moving to NetBSD; the l= ack > > > of NIC polling support for the intel chipsets i'm using is holding me > > > back at the moment. > > > I do not want to move over to linux, for various reasons. > > > So I figured perhaps some of the freebsd community is also interested= in > > > these features, and I might as well sponsor (part of?) its developmen= t. > > > Are there any persons interested in developing these features, or do = they > > > already exist and am I just plain ignorant (forgive me if that is the > > > case). Please note that i'm not interested in the netgraph approach, = as > > > that's (imho) just a hack around it, and it's not functioning with for > > > example gnu/zebra et all. > > > > > > I am looking for short- and long-term solutions, anything that's > > > developed trough sponsoring i'd be happy to contribute to the main tr= ee. > > > As this would be the first time we actually ask for a specific featur= e in > > > any OSS software, I could be way off the scale with the figures i had= in > > > mind. This would be about 200 to 400 euro per feature, the more impor= tant > > > ones like STP and ECMP are totally open to discussion. > > > > > > Any takers? Any enlightenment? Thanks for helping out in advance ;) > > > > if_bridge has been imported into FreeBSD 6.0 and I believe will be > > merged to 5.x before 5.5. >=20 > A candidate MFC patchset is at:=20 > http://people.freebsd.org/~thompsa/if_bridge-5stable.diff and is believed= to=20 > be production quality (judging from the reports for RELENG_6 so far). Th= ere=20 > might be minor problems and/or yet undiscovered problems, but only testin= g=20 > gets it there. Andrew is certainly thankful for any feedback! >=20 > > I can't speak for ECMP. > > > > LACP is supported by ng_fec. The fact that you don't like it is a > > seperate issue. FWIW, ng_fec only uses netgraph for configuration. > > It's not really a netgraph node. I'd personally like to see OpenBSD's > > if_trunk imported and LACP added, but I certainly don't have time. >=20 > It's certainly a good idea to look at if_trunk. I don't have hardware to= =20 > build a testbed, but I belive there are people out there who do and also = have=20 > the skills to make it happen. The main problem is: Whoever does this mus= t=20 > have (physical) access to a reasonable testbed and free time while there= =20 > (i.e. agreement with employer etc) I've got the equipment access, but lack the time. Untangling the mess in the VLAN and EtherChannel support has been on my like for a couple years now, but I have know idea when or if I'll get to it. FWIW, a Catalyst 2950 series switch will do EtherChannel and they appear to be available on e-bay for under $500 if someone wants to work on this. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --WlEyl6ow+jlIgNUh Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFDE1gvXY6L6fI4GtQRAp9TAJ0RlklgZ3QtjWSiuCf+AQOwuR/hEQCfaCF8 Jx95l0UzKzXRa96d7DGMVFc= =oYZZ -----END PGP SIGNATURE----- --WlEyl6ow+jlIgNUh-- From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 29 19:07:55 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 1D66916A41F for ; Mon, 29 Aug 2005 19:07:55 +0000 (GMT) (envelope-from samuel.pierson@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id D621743D70 for ; Mon, 29 Aug 2005 19:07:47 +0000 (GMT) (envelope-from samuel.pierson@gmail.com) Received: by wproxy.gmail.com with SMTP id i30so809993wra for ; Mon, 29 Aug 2005 12:07:46 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=pXW09k+adyKGFdZSspM90z6e8/BGQPN4qUjoI4eYuolNe9el1+v1A6qEqMJzDUtYHkQSEs82Aiiq7keBNzb9TC62aLgyz1nU0twiNenD3mPrQff//q5d3CBkzO4x4j9kv48iZH9gjxqL6doGVJBrQwOu9H8qHCKxO2Xuwc2dk/4= Received: by 10.54.18.28 with SMTP id 28mr6523033wrr; Mon, 29 Aug 2005 12:07:46 -0700 (PDT) Received: by 10.54.144.1 with HTTP; Mon, 29 Aug 2005 12:07:46 -0700 (PDT) Message-ID: Date: Mon, 29 Aug 2005 14:07:46 -0500 From: Sam Pierson To: FreeBSD Hackers Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: Atheros driver and radiotap reliability X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2005 19:07:55 -0000 Hi guys, I'm trying to get an accurate measurement of signal strength (preferably=20 in dBm) on a per-packet basis between two atheros cards that I have. I had some correspondence with the ethereal developers and David Young and apparently there is a bug in how ethereal handles the radiotap header. David told me that tcpdump will correctly report whatever the device driver tells it is the correct signal signal strength, but not to trust it until t= he devices have been calibrated. How does the ath driver report the signal strength in the radiotap header? From tcpdump, it's giving me this value: /* taken from /sys/net80211/ieee80211_radiotap.h */ * IEEE80211_RADIOTAP_DB_ANTSIGNAL u_int8_t decibel (dB) * * RF signal power at the antenna, decibel difference from an * arbitrary, fixed reference. ... In this same file, there is a u_int8_t ANTSIGNAL reported in dBm. It appea= rs as though everything is driver (and device, probably) dependent, so I'd lik= e to know how the driver computes this value. =20 As a side question, does anyone have an easier way to reliably measure=20 per-packet signal strength? The area has a decent amount of traffic and= =20 I have to be able to analyze the packets themselves, so a plain hardware solution will not do. Thanks, Sam From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 29 21:21:12 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 9ACB716A41F for ; Mon, 29 Aug 2005 21:21:12 +0000 (GMT) (envelope-from killing@multiplay.co.uk) Received: from multiplay.co.uk (www1.multiplay.co.uk [212.42.16.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8248E43D45 for ; Mon, 29 Aug 2005 21:21:11 +0000 (GMT) (envelope-from killing@multiplay.co.uk) Received: from vader ([212.135.219.179]) by multiplay.co.uk (multiplay.co.uk [212.42.16.7]) (MDaemon.PRO.v8.1.0.R) with ESMTP id md50001832981.msg for ; Mon, 29 Aug 2005 22:14:00 +0100 Message-ID: <002301c5acdf$833c2a90$b3db87d4@multiplay.co.uk> From: "Steven Hartland" To: "David Malone" References: <000201c5ac2a$df2d2990$5cf829d9@multiplay.co.uk> <20050829152810.GA26150@walton.maths.tcd.ie> Date: Mon, 29 Aug 2005 22:20:39 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Spam-Processed: multiplay.co.uk, Mon, 29 Aug 2005 22:14:00 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 212.135.219.179 X-Return-Path: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-hackers@freebsd.org X-MDAV-Processed: multiplay.co.uk, Mon, 29 Aug 2005 22:14:01 +0100 Cc: freebsd-hackers@freebsd.org Subject: Re: bge driver internal routing issues? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2005 21:21:12 -0000 Thanks for the that, we've just packed down the machines to move them I will endeavour to test this as soon as I have access to them again. However I think I did try disabling checksum off loading but not a 100% sure so will need to check. Steve ----- Original Message ----- From: "David Malone" > On Sun, Aug 28, 2005 at 09:06:47PM +0100, Steven Hartland wrote: >> Having a really odd problem here where udp queries to >> servers running on machines with bge cards dont respond >> via ip address that are being bound on: > > Can you run "tcpdump -s 0 -vvv port 1234" on the client (replace > port 1234 with the port number for the service). See if tcpdump > shows a reply packet, and if it does see if the checksum is reported > OK. It could be that the checksum offloading on the bge card is > busted. > > (You could also check "netstat -s" on the client to see if it > shows many bad checksums in the UDP section.) ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone (023) 8024 3137 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 29 23:02:33 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 30A5C16A41F for ; Mon, 29 Aug 2005 23:02:33 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.village.org (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id A8CE943D48 for ; Mon, 29 Aug 2005 23:02:32 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1]) by harmony.village.org (8.13.3/8.13.3) with ESMTP id j7TN13gW048876; Mon, 29 Aug 2005 17:01:03 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 29 Aug 2005 17:01:25 -0600 (MDT) Message-Id: <20050829.170125.88345281.imp@bsdimp.com> To: dmitry.mityugov@gmail.com From: "M. Warner Losh" In-Reply-To: References: <4311BDAD.1010803@icyb.net.ua> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.village.org [127.0.0.1]); Mon, 29 Aug 2005 17:01:03 -0600 (MDT) Cc: freebsd-hackers@freebsd.org Subject: Re: ntpd and cmos clock update X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2005 23:02:33 -0000 In message: Dmitry Mityugov writes: : That's why I always thought that ntpd did not work in FreeBSD 5.x! ntpd works perfectly on FreebSD 5.x Warner From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 29 23:59:14 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 6F59016A41F for ; Mon, 29 Aug 2005 23:59:14 +0000 (GMT) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0782C43D45 for ; Mon, 29 Aug 2005 23:59:13 +0000 (GMT) (envelope-from sam@errno.com) Received: from [66.127.85.91] ([66.127.85.91]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id j7TNxCBd071989 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 29 Aug 2005 16:59:13 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <4313A2EC.5070300@errno.com> Date: Mon, 29 Aug 2005 17:06:04 -0700 From: Sam Leffler User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050327) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Pierson References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Hackers Subject: Re: Atheros driver and radiotap reliability X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2005 23:59:14 -0000 Sam Pierson wrote: > Hi guys, > > I'm trying to get an accurate measurement of signal strength (preferably > in dBm) on a per-packet basis between two atheros cards that I have. I > had some correspondence with the ethereal developers and David Young > and apparently there is a bug in how ethereal handles the radiotap header. News to me; the last time I checked it looked correct. > David told me that tcpdump will correctly report whatever the device driver > tells it is the correct signal signal strength, but not to trust it until the > devices have been calibrated. How does the ath driver report the signal > strength in the radiotap header? From tcpdump, it's giving me this value: > > /* taken from /sys/net80211/ieee80211_radiotap.h */ > * IEEE80211_RADIOTAP_DB_ANTSIGNAL u_int8_t decibel (dB) > * > * RF signal power at the antenna, decibel difference from an > * arbitrary, fixed reference. > ... > > In this same file, there is a u_int8_t ANTSIGNAL reported in dBm. It appears > as though everything is driver (and device, probably) dependent, so I'd like > to know how the driver computes this value. The radiotap header includes the rssi returned by the hardware for rx'd frames. sc->sc_rx_th.wr_antsignal = ds->ds_rxstat.rs_rssi; Nothing is recorded for tx frames. You can typically treat it as being in .5dBm units relative to the current noise floor. Note however that there is currently no way to calibrate these values to physical units; doing that is not a simple matter. > > As a side question, does anyone have an easier way to reliably measure > per-packet signal strength? The area has a decent amount of traffic and > I have to be able to analyze the packets themselves, so a plain hardware > solution will not do. Thanks, rssi is provided and is accurate. If you want the rssi of the ack on xmit you need to collect that yourself from the tx descriptor when it's reaped. The sample tx rate control algorithm uses it (for example). Sam From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 30 00:44:24 2005 Return-Path: X-Original-To: hackers@freebsd.org 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 4757C16A41F for ; Tue, 30 Aug 2005 00:44:24 +0000 (GMT) (envelope-from mwm-keyword-hackers.e471b2@mired.org) Received: from delight.idiom.com (delight.idiom.com [216.240.32.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 035F943D45 for ; Tue, 30 Aug 2005 00:44:23 +0000 (GMT) (envelope-from mwm-keyword-hackers.e471b2@mired.org) Received: from idiom.com (idiom.com [216.240.32.1]) by delight.idiom.com (Postfix) with ESMTP id CD1AD1F9F29 for ; Mon, 29 Aug 2005 17:44:23 -0700 (PDT) Received: from mired.org (mwm@idiom [216.240.32.1]) by idiom.com (8.12.11/8.12.11) with SMTP id j7U0iJPv040762 for ; Mon, 29 Aug 2005 17:44:22 -0700 (PDT) (envelope-from mwm-keyword-hackers.e471b2@mired.org) Received: (qmail 10367 invoked by uid 1001); 30 Aug 2005 00:45:48 -0000 Received: by localhost.mired.org (tmda-sendmail, from uid 1001); Mon, 29 Aug 2005 20:45:48 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17171.44091.893656.850571@bhuda.mired.org> Date: Mon, 29 Aug 2005 20:45:47 -0400 To: hackers@freebsd.org X-Mailer: VM 7.17 under 21.4 (patch 17) "Jumbo Shrimp" XEmacs Lucid X-Primary-Address: mwm@mired.org X-face: "5Mnwy%?j>IIV\)A=):rjWL~NB2aH[}Yq8Z=u~vJ`"(,&SiLvbbz2W`; h9L,Yg`+vb1>RG% *h+%X^n0EZd>TM8_IB;a8F?(Fb"lw'IgCoyM.[Lg#r\ From: Mike Meyer X-Delivery-Agent: TMDA/1.0.3 (Seattle Slew) Cc: Subject: Problems with mpeg video X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2005 00:44:24 -0000 I asked this question on -questions, and got no answers (or at least none that I saw). I recently upgrade from a 1gig tunderbird to a 3gig P4 system, both running 5-STABLE from post 5.4-RELASE. The system and all ports were rebuilt with make.conf having: CPUTYPE=p3 CFLAGS= -O -pipe COPTFLAGS= -O -pipe On the new system, videos don't display the video stream - just a black box with red dots on it. This happens with both plaympeg and xine. I'm looking for suggestions on where to start debugging this issue. Thanks, http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 30 06:59:44 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 6B94816A41F for ; Tue, 30 Aug 2005 06:59:44 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (gate.funkthat.com [69.17.45.168]) by mx1.FreeBSD.org (Postfix) with ESMTP id 04C1143D48 for ; Tue, 30 Aug 2005 06:59:43 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (localhost.funkthat.com [127.0.0.1]) by hydrogen.funkthat.com (8.13.3/8.13.3) with ESMTP id j7U6xXLY047119; Mon, 29 Aug 2005 23:59:33 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.13.3/8.13.3/Submit) id j7U6xVeo047118; Mon, 29 Aug 2005 23:59:31 -0700 (PDT) (envelope-from jmg) Date: Mon, 29 Aug 2005 23:59:31 -0700 From: John-Mark Gurney To: "M. Warner Losh" Message-ID: <20050830065931.GD61824@funkthat.com> Mail-Followup-To: "M. Warner Losh" , dmitry.mityugov@gmail.com, freebsd-hackers@freebsd.org References: <4311BDAD.1010803@icyb.net.ua> <20050829.170125.88345281.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050829.170125.88345281.imp@bsdimp.com> User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 5.4-RELEASE-p1 i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html Cc: freebsd-hackers@freebsd.org, dmitry.mityugov@gmail.com Subject: Re: ntpd and cmos clock update X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: John-Mark Gurney List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2005 06:59:44 -0000 Warner Losh wrote this message on Mon, Aug 29, 2005 at 17:01 -0600: > In message: > Dmitry Mityugov writes: > : That's why I always thought that ntpd did not work in FreeBSD 5.x! > > ntpd works perfectly on FreebSD 5.x I think he refers to the fact that after a reboot, the time has to be adjusted by n seconds, so obviously the time that FreeBSD thought it was just before the reboot was just as far off... hence ntpd wasn't working... but since we don't set the TOD chip upon reboot, all the work that ntpd did over the previous reboot is lost... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 30 07:55:32 2005 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.org 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 D979A16A41F for ; Tue, 30 Aug 2005 07:55:32 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mail2.fluidhosting.com [204.14.90.62]) by mx1.FreeBSD.org (Postfix) with SMTP id 2BDD343D45 for ; Tue, 30 Aug 2005 07:55:32 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: (qmail 80822 invoked by uid 399); 30 Aug 2005 07:55:31 -0000 Received: from mail1.fluidhosting.com (204.14.90.61) by mail2.fluidhosting.com with SMTP; 30 Aug 2005 07:55:31 -0000 Received: (qmail 2924 invoked by uid 399); 30 Aug 2005 07:55:31 -0000 Received: from localhost (HELO ?192.168.1.100?) (dougb@dougbarton.net@127.0.0.1) by localhost with SMTP; 30 Aug 2005 07:55:31 -0000 Message-ID: <431410F1.7020509@FreeBSD.org> Date: Tue, 30 Aug 2005 00:55:29 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050829) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.org, freebsd-arch@freebsd.org X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: ip6.int deprecated X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2005 07:55:33 -0000 [ -hackers and -arch cc'ed to try and get a wide audience for this. Please pick the one list that is most appropriate for any topics you want to follow up on. Thanks. ] Howdy, RFC 4159 was published today, which officially deprecates ip6.int. You can find the full text at http://www.rfc-editor.org/rfc/rfc4159.txt. Here is a relevant excerpt: In August 2001 the IETF published [RFC3152], which advised that the use of "ip6.int" as the domain for reverse-mapping of IPv6 addresses to DNS names was deprecated. The document noted that the use of "ip6.int" would be phased out in an orderly fashion. As of 1 September 2005, the IETF advises the community that the DNS domain "ip6.int" should no longer be used to perform reverse mapping of IPv6 addresses to domain names, and that the domain "ip6.arpa" should be used henceforth, in accordance with the IANA Considerations described in [RFC3596]. The domain "ip6.int" is deprecated, and its use in IPv6 implementations that conform to the IPv6 Internet Standards is discontinued. The one step I'm going to take directly to support this deprecation is to remove the ip6.int example from the sample named.conf file in the base. I'm sending this message to provide notice of that, and notice to the community generally that we should start moving in the direction of deprecating ip6.int wherever it might be found. For those not aware of the history, ip6.int was the first stab at creating a reverse DNS zone for IP version 6. Eventually, the "issues" surrounding this topic were sorted out, and it was agreed to do reverse DNS in IPv6 in .arpa instead. Unfortunately, that left a lot of early adopters in a difficult position, and so the various players in the game (ICANN, the Regional Internet Registries, etc.) have been supporting both zones since 2001. In order to reduce the workload associated with this issue, and in order to encourage complete migration to ip6.arpa before wide deployment of IPv6 (and I'm sure for a lot of other reasons), the decision was made to officially deprecate ip6.int from the IETF perspective. Other than some old references in src/contrib/bind9, the only place I see a reference to ip6.int in our base is in the named.conf file that I mentioned above. I hope that this note is useful however as a more general source of information, and of course if there is anything I've missed, I welcome others to take appropriate action. Regards, Doug -- This .signature sanitized for your protection From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 30 09:28:20 2005 Return-Path: X-Original-To: hackers@freebsd.org 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 EF8DD16A41F; Tue, 30 Aug 2005 09:28:20 +0000 (GMT) (envelope-from freebsd@rea.mbslab.kiae.ru) Received: from rea.mbslab.kiae.ru (rea.mbslab.kiae.ru [144.206.177.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 415EC43D48; Tue, 30 Aug 2005 09:28:20 +0000 (GMT) (envelope-from freebsd@rea.mbslab.kiae.ru) Received: from rea.mbslab.kiae.ru (localhost [127.0.0.1]) by rea.mbslab.kiae.ru (Postfix) with ESMTP id 80236BC58; Tue, 30 Aug 2005 13:28:18 +0400 (MSD) Received: by rea.mbslab.kiae.ru (Postfix, from userid 1000) id 575B9BABE; Tue, 30 Aug 2005 13:28:18 +0400 (MSD) Date: Tue, 30 Aug 2005 13:28:18 +0400 From: "Eygene A. Ryabinkin" To: freebsd-usb@freebsd.org Message-ID: <20050830092818.GD881@rea.mbslab.kiae.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline User-Agent: Mutt/1.5.9i X-AV-Checked: Yes! Cc: hackers@freebsd.org Subject: Low umass performance with USB 2.0 ports X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2005 09:28:21 -0000 Good day. I am observing very low umass performance: when I am trying to move a large file from/to my USB 2.0 flash that is plugged into the USB 2.0 port: transfer starts fine at 3.5 Mb/sec, but after some 20 Mbytes it hangs and the process (dd) stay in the wdrain state. The activity LED on the flash shows no activity. Operations do continue, but very slow and the most time of the copying process spends in the wdrain state. All attempts to invoke `sync` or to see the file state via `ls` are hanging until `dd` leaves the wdrain state. It does not matter what flash is used: I tried Apacer and the Kingmax ones -- the result is the same. If I plug the flash into the USB 1.1 port and trying to move some data -- it works fine, no hangs. Speed is 500 Kb/sec. Seems like others do have this problem: http://lists.freebsd.org/pipermail/freebsd-usb/2005-May/001052.html USB 2.0 controller is Promise PCI (NEC chipset), USB 1.1 chipset is onboard VIA. My dmesg output is: ----- Copyright (c) 1992-2005 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.4-STABLE #2: Tue Aug 30 11:34:26 MSD 2005 XXXXXXXX:/usr/src/sys/i386/compile/GENERIC ACPI APIC Table: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel Pentium III (1004.52-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x686 Stepping = 6 Features=0x383fbff real memory = 2147467264 (2047 MB) avail memory = 2096017408 (1998 MB) FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 3 cpu1 (AP): APIC ID: 0 ioapic0 irqs 0-23 on motherboard acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0xe408-0xe40b on acpi0 cpu0: on acpi0 cpu1: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: mem 0xfe000000-0xfe7fffff at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 drm0: port 0xd800-0xd8ff mem 0xdf000000-0xdf00ffff,0xf0000000-0xf7ffffff irq 16 at device 0.0 on pci1 info: [drm] AGP at 0xfe000000 8MB info: [drm] Initialized radeon 1.11.0 20020828 on minor 0 pci1: at device 0.1 (no driver attached) isab0: at device 4.0 on pci0 isa0: on isab0 atapci0: port 0xb800-0xb80f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 4.1 on pci0 ata0: channel #0 on atapci0 ata1: channel #1 on atapci0 uhci0: port 0xb400-0xb41f irq 5 at device 4.2 on pci0 usb0: on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xb000-0xb01f irq 5 at device 4.3 on pci0 usb1: on uhci1 usb1: USB revision 1.0 uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered pcm0: port 0xa800-0xa83f irq 19 at device 9.0 on pci0 pcm0: pci0: at device 9.2 (no driver attached) pci0: at device 10.0 (no driver attached) pci0: at device 10.1 (no driver attached) ehci0: mem 0xdc000000-0xdc0000ff irq 16 at device 10.2 on pci0 usb2: EHCI version 1.0 usb2: wrong number of companions (2 != 0) usb2: on ehci0 usb2: USB revision 2.0 uhub2: NEC EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub2: 5 ports with 5 removable, self powered umass0: vendor 0x1005 USB FLASH DRIVE, rev 2.00/0.84, addr 2 em0: port 0xa000-0xa03f mem 0xdb000000-0xdb01ffff,0xdb800000-0xdb81ffff irq 17 at device 11.0 on pci0 em0: Ethernet address: 00:07:e9:09:5a:82 em0: Speed:N/A Duplex:N/A atapci1: port 0x9000-0x907f,0x9400-0x940f,0x9800-0x983f mem 0xda000000-0xda01ffff,0xda800000-0xda800fff irq 19 at device 13.0 on pci0 atapci1: failed: rid 0x20 is memory, requested 4 ata2: channel #0 on atapci1 ata3: channel #1 on atapci1 ata4: channel #2 on atapci1 fdc0: port 0x3f7,0x3f2-0x3f5 irq 6 drq 2 on acpi0 fd0: <1440-KB 3.5" drive> on fdc0 drive 0 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 psm0: irq 12 on atkbdc0 psm0: model IntelliMouse, device ID 3 npx0: on motherboard npx0: INT 16 interface orm0: at iomem 0xcc000-0xcd7ff,0xc0000-0xcafff on isa0 pmtimer0 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 fb0 at vga0 ulpt0: Xerox Corporation Xerox Phaser 3130, rev 2.00/1.00, addr 2, iclass 7/1 ulpt0: using bi-directional mode Timecounters tick every 1.000 msec ipfw2 initialized, divert disabled, rule-based forwarding disabled, default to deny, logging limited to 1000 packets/entry by default ad0: 76319MB [155061/16/63] at ata0-master UDMA100 acd0: DVDR at ata0-slave PIO4 ad2: 114498MB [232632/16/63] at ata1-master UDMA100 ad4: 114498MB [232632/16/63] at ata2-master SATA150 SMP: AP CPU #1 Launched! da0 at umass-sim0 bus 0 target 0 lun 0 da0: Removable Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: 247MB (506880 512 byte sectors: 64H 32S/T 247C) cd0 at ata0 bus 0 target 1 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 16.000MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present umass0: Phase Error, residue = 0 (da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0x4, scsi status == 0x0 umass0: Phase Error, residue = 0 (da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0x4, scsi status == 0x0 umass0: Phase Error, residue = 0 (da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0x4, scsi status == 0x0 umass0: Phase Error, residue = 0 (da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0x4, scsi status == 0x0 Mounting root from ufs:/dev/ad0s1a em0: Link is up 100 Mbps Full Duplex info: [drm] Loading R200 Microcode ----- -- rea From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 30 12:50:37 2005 Return-Path: X-Original-To: hackers@freebsd.org 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 71AB916A41F; Tue, 30 Aug 2005 12:50:37 +0000 (GMT) (envelope-from freebsd@rea.mbslab.kiae.ru) Received: from rea.mbslab.kiae.ru (rea.mbslab.kiae.ru [144.206.177.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0675343D46; Tue, 30 Aug 2005 12:50:36 +0000 (GMT) (envelope-from freebsd@rea.mbslab.kiae.ru) Received: from rea.mbslab.kiae.ru (localhost [127.0.0.1]) by rea.mbslab.kiae.ru (Postfix) with ESMTP id 32AA7BB0A; Tue, 30 Aug 2005 16:50:32 +0400 (MSD) Received: by rea.mbslab.kiae.ru (Postfix, from userid 1000) id F30DFBAD0; Tue, 30 Aug 2005 16:50:31 +0400 (MSD) Date: Tue, 30 Aug 2005 16:50:31 +0400 From: "Eygene A. Ryabinkin" To: Eugene Grosbein Message-ID: <20050830125031.GA775@rea.mbslab.kiae.ru> References: <20050830092818.GD881@rea.mbslab.kiae.ru> <4314523D.79926C81@kuzbass.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <4314523D.79926C81@kuzbass.ru> User-Agent: Mutt/1.5.9i X-AV-Checked: Yes! Cc: hackers@freebsd.org, freebsd-usb@freebsd.org Subject: Re: Low umass performance with USB 2.0 ports X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2005 12:50:37 -0000 > > What is filesystem has your USB drive? The one I was extensively testing has FAT, but I've checked the UFS2 -- just a bit better -- 1.8 Mb/second. But you're right -- no wdrains at all. > FreeBSD 4.x had very low performance with FAT filesystem, > writing process spent lots of time in the wdrain state too. Yes, it has. But here the same flash drive gives different results for ehci and uhci devices, and the total speed of echi is lower due to wdrains: 300 Kb/sec versus 500 Kb/sec. And I sometimes write my data to the Windows partition with FAT to my home HDD -- it has no wdrains. At least, I've not noticed them. For flash I can. -- rea From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 30 12:54:43 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 0BAEC16A41F for ; Tue, 30 Aug 2005 12:54:43 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from mh2.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id A181343D48 for ; Tue, 30 Aug 2005 12:54:41 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh2.centtech.com (8.13.1/8.13.1) with ESMTP id j7UCsXGS023718; Tue, 30 Aug 2005 07:54:33 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <43145717.5070305@centtech.com> Date: Tue, 30 Aug 2005 07:54:47 -0500 From: Eric Anderson User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.10) Gecko/20050815 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Siddharth Aggarwal References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: using specfs benchmark on BSD 4.10 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2005 12:54:43 -0000 Siddharth Aggarwal wrote: > Hi, > > I would like to set up and run the specfs benchmark on a BSD 4.10 machine. > I have been searching around for a while on how to do it, but no luck so > far. Could anybody please point me to where I can get the source code, > build/install, and configure the system so that I can profile filesystem > activity. I didn't see any replies to this, but specfs is not open source, if I understand correctly. You can buy the source code from http://www.spec.org. Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology Anything that works is better than anything that doesn't. ------------------------------------------------------------------------ From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 30 12:34:14 2005 Return-Path: X-Original-To: hackers@freebsd.org 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 1CD4216A41F; Tue, 30 Aug 2005 12:34:14 +0000 (GMT) (envelope-from eugen@kuzbass.ru) Received: from www.svzserv.kemerovo.su (www.svzserv.kemerovo.su [213.184.65.80]) by mx1.FreeBSD.org (Postfix) with ESMTP id 541A743D45; Tue, 30 Aug 2005 12:34:12 +0000 (GMT) (envelope-from eugen@kuzbass.ru) Received: from kuzbass.ru (kost [213.184.65.82]) by www.svzserv.kemerovo.su (8.13.3/8.13.3) with ESMTP id j7UCY7qr071282; Tue, 30 Aug 2005 20:34:08 +0800 (KRAST) (envelope-from eugen@kuzbass.ru) Message-ID: <4314523D.79926C81@kuzbass.ru> Date: Tue, 30 Aug 2005 20:34:05 +0800 From: Eugene Grosbein Organization: SVZServ X-Mailer: Mozilla 4.8 [en] (Win98; U) X-Accept-Language: ru,en MIME-Version: 1.0 To: "Eygene A. Ryabinkin" References: <20050830092818.GD881@rea.mbslab.kiae.ru> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 30 Aug 2005 13:02:55 +0000 Cc: hackers@freebsd.org, freebsd-usb@freebsd.org Subject: Re: Low umass performance with USB 2.0 ports X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2005 12:34:14 -0000 "Eygene A. Ryabinkin" wrote: > > Good day. > I am observing very low umass performance: when I am trying to move a large > file from/to my USB 2.0 flash that is plugged into the USB 2.0 port: transfer > starts fine at 3.5 Mb/sec, but after some 20 Mbytes it hangs and the process > (dd) stay in the wdrain state. The activity LED on the flash shows no activity. > Operations do continue, but very slow and the most time of the copying process > spends in the wdrain state. All attempts to invoke `sync` or to see the > file state via `ls` are hanging until `dd` leaves the wdrain state. > It does not matter what flash is used: I tried Apacer and the Kingmax ones -- > the result is the same. > If I plug the flash into the USB 1.1 port and trying to move some data -- it > works fine, no hangs. Speed is 500 Kb/sec. What is filesystem has your USB drive? FreeBSD 4.x had very low performance with FAT filesystem, writing process spent lots of time in the wdrain state too. Eugene From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 30 13:29:12 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 8450C16A41F; Tue, 30 Aug 2005 13:29:12 +0000 (GMT) (envelope-from bushman@rsu.ru) Received: from mail.r61.net (mail.r61.net [195.208.245.249]) by mx1.FreeBSD.org (Postfix) with ESMTP id 251A143D46; Tue, 30 Aug 2005 13:29:10 +0000 (GMT) (envelope-from bushman@rsu.ru) Received: from stinger.cc.rsu.ru (stinger.cc.rsu.ru [195.208.252.82]) by mail.r61.net (8.13.4/8.13.4) with ESMTP id j7UDSmZW051676; Tue, 30 Aug 2005 17:28:48 +0400 (MSD) (envelope-from bushman@rsu.ru) Date: Tue, 30 Aug 2005 17:32:52 +0400 (MSD) From: Michael Bushkov X-X-Sender: bushman@stinger.cc.rsu.ru To: Dan Nelson In-Reply-To: <20050829163025.GA25664@dan.emsphone.com> Message-ID: <20050830172127.E5409@stinger.cc.rsu.ru> References: <20050827170633.Y5409@stinger.cc.rsu.ru> <43123F3B.8070002@FreeBSD.org> <20050829115740.N5409@stinger.cc.rsu.ru> <20050829163025.GA25664@dan.emsphone.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV version 0.86.2, clamav-milter version 0.86 on asterix.r61.net X-Virus-Status: Clean X-Spam-Status: No, score=-5.7 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.0.4 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on asterix.r61.net Cc: Jacques Vidrine , freebsd-hackers@freebsd.org, Doug Barton , Brooks Davis , freebsd-current@freebsd.org Subject: Re: [PATCH] caching daemon release and nsswitch patches X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2005 13:29:12 -0000 On Mon, 29 Aug 2005, Dan Nelson wrote: We can't ensure that, I guess. In the upcoming version (before the 1st of September), the cache would be per-user. This would solve all the security problems. In a little while, I'll implement the ability for cached to act as nscd. So you'll be able to choose the behaviour. > In the last episode (Aug 29), Michael Bushkov said: >> There is some information in my project's description here: >> http://wikitest.freebsd.org/moin.cgi/NsswitchAndCachingTechnicalDetails > > One question that comes to mind: > > It looks like the end-user application is still responsible for > performing nss lookups. How do you ensure that one user can't poison > the cache and cause problems for other users? Could cached do all nss > operations itself (making it more like nscd in other OSes)? > > -- > Dan Nelson > dnelson@allantgroup.com > With best regards, Michael Bushkov Rostov State University From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 30 13:36:52 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 C759416A41F for ; Tue, 30 Aug 2005 13:36:52 +0000 (GMT) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.FreeBSD.org (Postfix) with ESMTP id 536E743D53 for ; Tue, 30 Aug 2005 13:36:52 +0000 (GMT) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id D209F6147; Tue, 30 Aug 2005 15:36:34 +0200 (CEST) Received: from xps.des.no (des.no [80.203.228.37]) by tim.des.no (Postfix) with ESMTP id C13B36144; Tue, 30 Aug 2005 15:36:34 +0200 (CEST) Received: by xps.des.no (Postfix, from userid 1001) id 7C13733DA1; Tue, 30 Aug 2005 15:36:45 +0200 (CEST) To: "M. Warner Losh" References: <4311BDAD.1010803@icyb.net.ua> <20050829.170125.88345281.imp@bsdimp.com> <20050830065931.GD61824@funkthat.com> From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) Date: Tue, 30 Aug 2005 15:36:45 +0200 In-Reply-To: <20050830065931.GD61824@funkthat.com> (John-Mark Gurney's message of "Mon, 29 Aug 2005 23:59:31 -0700") Message-ID: <86wtm3eec2.fsf@xps.des.no> User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Tests: ALL_TRUSTED,AWL,BAYES_00 X-Spam-Learn: ham X-Spam-Score: -5.2/3.0 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on tim.des.no Cc: freebsd-hackers@freebsd.org, dmitry.mityugov@gmail.com Subject: Re: ntpd and cmos clock update X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2005 13:36:52 -0000 John-Mark Gurney writes: > but since we don't set the TOD chip upon reboot, all the work that > ntpd did over the previous reboot is lost... echo 'ntpdate_enable=3D"YES"' >>/etc/rc.conf DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 30 14:38:47 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 C609A16A41F for ; Tue, 30 Aug 2005 14:38:47 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.village.org (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6327143D46 for ; Tue, 30 Aug 2005 14:38:47 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1]) by harmony.village.org (8.13.3/8.13.3) with ESMTP id j7UEb9Qx059848; Tue, 30 Aug 2005 08:37:09 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Tue, 30 Aug 2005 08:37:31 -0600 (MDT) Message-Id: <20050830.083731.122805682.imp@bsdimp.com> To: gurney_j@resnet.uoregon.edu From: "M. Warner Losh" In-Reply-To: <20050830065931.GD61824@funkthat.com> References: <20050829.170125.88345281.imp@bsdimp.com> <20050830065931.GD61824@funkthat.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.village.org [127.0.0.1]); Tue, 30 Aug 2005 08:37:09 -0600 (MDT) Cc: freebsd-hackers@freebsd.org, dmitry.mityugov@gmail.com Subject: Re: ntpd and cmos clock update X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2005 14:38:47 -0000 In message: <20050830065931.GD61824@funkthat.com> John-Mark Gurney writes: : Warner Losh wrote this message on Mon, Aug 29, 2005 at 17:01 -0600: : > In message: : > Dmitry Mityugov writes: : > : That's why I always thought that ntpd did not work in FreeBSD 5.x! : > : > ntpd works perfectly on FreebSD 5.x : : I think he refers to the fact that after a reboot, the time has to be : adjusted by n seconds, so obviously the time that FreeBSD thought it : was just before the reboot was just as far off... hence ntpd wasn't : working... When ntpd is running, ntpd sets the time. The TODR is just something that gets things kinda close for ntpd to actually do its work. Of course, since all my 5.x experience is done on machines that get the time from GPS and the local time doesn't matter at all, I might not have noticed something like that. Warner From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 30 16:43:10 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 257E716A41F for ; Tue, 30 Aug 2005 16:43:10 +0000 (GMT) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8E9B743D5E for ; Tue, 30 Aug 2005 16:43:09 +0000 (GMT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.13.1/8.13.3) id j7UGgn7V041315; Tue, 30 Aug 2005 11:42:49 -0500 (CDT) (envelope-from dan) Date: Tue, 30 Aug 2005 11:42:49 -0500 From: Dan Nelson To: Dag-Erling Smorgrav Message-ID: <20050830164248.GA4337@dan.emsphone.com> References: <4311BDAD.1010803@icyb.net.ua> <20050829.170125.88345281.imp@bsdimp.com> <20050830065931.GD61824@funkthat.com> <86wtm3eec2.fsf@xps.des.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86wtm3eec2.fsf@xps.des.no> X-OS: FreeBSD 5.4-STABLE X-message-flag: Outlook Error User-Agent: Mutt/1.5.9i Cc: freebsd-hackers@freebsd.org, dmitry.mityugov@gmail.com Subject: Re: ntpd and cmos clock update X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2005 16:43:10 -0000 In the last episode (Aug 30), Dag-Erling Smorgrav said: > John-Mark Gurney writes: > > but since we don't set the TOD chip upon reboot, all the work that > > ntpd did over the previous reboot is lost... > > echo 'ntpdate_enable="YES"' >>/etc/rc.conf I think he meant shutdown instead of reboot. ntpd will step the clock itself on bootup if it needs to (although not as quickly at ntpdate certainly). Just calling resettodr during shutdown would be the easiest solution, I think. Or have a kernel timer fire that calls it every 24 hours. -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 30 17:10:15 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 6326816A41F for ; Tue, 30 Aug 2005 17:10:15 +0000 (GMT) (envelope-from jhay@meraka.csir.co.za) Received: from zibbi.meraka.csir.co.za (zibbi.meraka.csir.co.za [146.64.24.58]) by mx1.FreeBSD.org (Postfix) with ESMTP id 931AF43D45 for ; Tue, 30 Aug 2005 17:10:05 +0000 (GMT) (envelope-from jhay@meraka.csir.co.za) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id F117C44; Tue, 30 Aug 2005 19:09:57 +0200 (SAST) Date: Tue, 30 Aug 2005 19:09:57 +0200 From: John Hay To: "M. Warner Losh" Message-ID: <20050830170957.GA53629@zibbi.meraka.csir.co.za> References: <20050829.170125.88345281.imp@bsdimp.com> <20050830065931.GD61824@funkthat.com> <20050830.083731.122805682.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050830.083731.122805682.imp@bsdimp.com> User-Agent: Mutt/1.4.1i Cc: freebsd-hackers@freebsd.org, gurney_j@resnet.uoregon.edu, dmitry.mityugov@gmail.com Subject: Re: ntpd and cmos clock update X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2005 17:10:15 -0000 > : > : That's why I always thought that ntpd did not work in FreeBSD 5.x! > : > > : > ntpd works perfectly on FreebSD 5.x > : > : I think he refers to the fact that after a reboot, the time has to be > : adjusted by n seconds, so obviously the time that FreeBSD thought it > : was just before the reboot was just as far off... hence ntpd wasn't > : working... > > When ntpd is running, ntpd sets the time. The TODR is just something > that gets things kinda close for ntpd to actually do its work. Of > course, since all my 5.x experience is done on machines that get the > time from GPS and the local time doesn't matter at all, I might not > have noticed something like that. What happens is something like this: The machine boots and ntpd starts and maybe step the time and the tod clock is also set. If you reboot at this stage the tod clock is normally close enough that ntpd does not need to step, but if the machine runs for a long time, ntpd will keep FreeBSD time correct but the tod clock will slowly drift away. Then if you reboot or recover from a power failure, ntpd has to step the time again. If the tod clock could be synced periodically, the step on startup can mostly be avoided. I would also like something like this, maybe with a switch to enable/ disable it. John -- John Hay -- John.Hay@meraka.csir.co.za / jhay@FreeBSD.org From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 30 17:17:02 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 EE05016A41F for ; Tue, 30 Aug 2005 17:17:02 +0000 (GMT) (envelope-from samuel.pierson@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7004A43D45 for ; Tue, 30 Aug 2005 17:17:02 +0000 (GMT) (envelope-from samuel.pierson@gmail.com) Received: by wproxy.gmail.com with SMTP id i21so768958wra for ; Tue, 30 Aug 2005 10:17:01 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=hsmvwBV1P87K+V66k1KytQjlo6khlzBtd3ng/fqoxGREHyzRke4DLd8dgoYWpwAsYkCS7crQEn6qRER3kx5+VaognqnDGGxQ28C12QE2EWo5KtjmGglBhEb0wHyyrjnOPsiObkqm/1chjrOjiqbBV7KGdNSFdtie3azAlmoQdts= Received: by 10.54.37.50 with SMTP id k50mr3286785wrk; Tue, 30 Aug 2005 10:17:01 -0700 (PDT) Received: by 10.54.144.1 with HTTP; Tue, 30 Aug 2005 10:17:01 -0700 (PDT) Message-ID: Date: Tue, 30 Aug 2005 12:17:01 -0500 From: Sam Pierson To: Sam Leffler In-Reply-To: <4313A2EC.5070300@errno.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <4313A2EC.5070300@errno.com> Cc: FreeBSD Hackers Subject: Re: Atheros driver and radiotap reliability X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2005 17:17:03 -0000 On 8/29/05, Sam Leffler wrote: > Sam Pierson wrote: > >I had some correspondence with the ethereal developers and David Young > > and apparently there is a bug in how ethereal handles the radiotap head= er. >=20 > News to me; the last time I checked it looked correct. I'm not sure. David told me this: FYI, ethereal's radiotap dissector was broken the last time I checked. :-( It does not obey the alignment rules for radiotap fields: the radiotap producer (usually, the kernel) inserts zeroes to ensure natural alignment of all multi-byte fields. Ethereal does not account for this. The tcpdump sources get this right. > The radiotap header includes the rssi returned by the hardware for rx'd > frames. > sc->sc_rx_th.wr_antsignal =3D ds->ds_rxstat.rs_r= ssi; I get (slightly) different values for the RSSI displayed in ethereal (if it= 's=20 correctly being displayed, still looking) than the SS displayed in dB by=20 tcpdump. Is the SSI displayed by ethereal the sc->sc_rx_th.wr_antsignal being passed through? =20 =20 > Nothing is recorded for tx frames. You can typically treat it as being > in .5dBm units relative to the current noise floor. =20 *it*, referring to the rssi value above? Thanks for the help, Sam From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 30 18:26:37 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 3875216A428 for ; Tue, 30 Aug 2005 18:26:33 +0000 (GMT) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id F288343E44 for ; Tue, 30 Aug 2005 18:26:09 +0000 (GMT) (envelope-from sam@errno.com) Received: from [66.127.85.91] ([66.127.85.91]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id j7UIQ7Bd076427 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Aug 2005 11:26:08 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <4314A65C.4070802@errno.com> Date: Tue, 30 Aug 2005 11:33:00 -0700 From: Sam Leffler User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050327) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Pierson References: <4313A2EC.5070300@errno.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Hackers Subject: Re: Atheros driver and radiotap reliability X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2005 18:26:37 -0000 Sam Pierson wrote: > On 8/29/05, Sam Leffler wrote: > >>Sam Pierson wrote: >> >>>I had some correspondence with the ethereal developers and David Young >>>and apparently there is a bug in how ethereal handles the radiotap header. >> >>News to me; the last time I checked it looked correct. > > > I'm not sure. David told me this: > FYI, ethereal's radiotap dissector was broken the last time I checked. :-( > It does not obey the alignment rules for radiotap fields: the radiotap > producer (usually, the kernel) inserts zeroes to ensure natural > alignment of all multi-byte fields. Ethereal does not account for this. > The tcpdump sources get this right. David appears to be talking about how netbsd works. Understand that David does not work on FreeBSD; I'm not even sure he uses it. > > >>The radiotap header includes the rssi returned by the hardware for rx'd >>frames. >> sc->sc_rx_th.wr_antsignal = ds->ds_rxstat.rs_rssi; > > > I get (slightly) different values for the RSSI displayed in ethereal (if it's > correctly being displayed, still looking) than the SS displayed in dB by > tcpdump. Is the SSI displayed by ethereal the sc->sc_rx_th.wr_antsignal > being passed through? tcpdump and ethereal get the same data. If they display it differently given identical data then one is wrong. If you have an example of where things are wrong please present it. > > >>Nothing is recorded for tx frames. You can typically treat it as being >>in .5dBm units relative to the current noise floor. > > > *it*, referring to the rssi value above? "it" = ds->ds_rxstat.rs_rssi which is the value returned by the hardware. Sam From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 30 18:41:13 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 8B55C16A41F for ; Tue, 30 Aug 2005 18:41:13 +0000 (GMT) (envelope-from samuel.pierson@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5293B43D77 for ; Tue, 30 Aug 2005 18:40:14 +0000 (GMT) (envelope-from samuel.pierson@gmail.com) Received: by wproxy.gmail.com with SMTP id i21so781113wra for ; Tue, 30 Aug 2005 11:40:13 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=iHNEtDjNhmOufEU9TeFeT3mLCOKcHOSoZP2v34NDtjVWdtBt2vLJ64jUsBo5flpqDGCvxH8uxnGAWHt+zbPaDr9Ih4Xc2szPbPC7rqykXqht106iTKwakuIitPRm86tbFheOOw02vEy7n6krxECR9IYhsFThZkuS+3nKZKCEnf4= Received: by 10.54.13.65 with SMTP id 65mr737161wrm; Tue, 30 Aug 2005 11:40:13 -0700 (PDT) Received: by 10.54.144.1 with HTTP; Tue, 30 Aug 2005 11:40:13 -0700 (PDT) Message-ID: Date: Tue, 30 Aug 2005 13:40:13 -0500 From: Sam Pierson To: Sam Leffler In-Reply-To: <4314A65C.4070802@errno.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <4313A2EC.5070300@errno.com> <4314A65C.4070802@errno.com> Cc: FreeBSD Hackers Subject: Re: Atheros driver and radiotap reliability X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2005 18:41:13 -0000 On 8/30/05, Sam Leffler wrote: > David appears to be talking about how netbsd works. Understand that > David does not work on FreeBSD; I'm not even sure he uses it. ... > tcpdump and ethereal get the same data. If they display it differently > given identical data then one is wrong. If you have an example of where > things are wrong please present it. I tried and it looks like everything is being displayed correctly and that tcpdump and ethereal are displaying the same values. The only reason I said they looked different is that in the morning when I examined a few hundred frames with ethereal, the values were consistently 10dB=20 lower than what I had observed through tcpdump. I'm very glad that they are displaying the same values now though. > > *it*, referring to the rssi value above? >=20 > "it" =3D ds->ds_rxstat.rs_rssi which is the value returned by the hardwar= e. Alright, it makes much more sense now. You said earlier that we can use the RSSI value and correspond each unit to ~.5dBm above the noise floor. I didn't see anything being passed through the hardware which records the noise on that same per packet basis, but I can get ahold of the average noise floor for the environment. Will this affect the=20 accuracy of the measurements to the point where they will be=20 significantly skewed? =20 (Thanks for the help, again, it seems like there isn't a lot of information out there regarding these topics) -Sam From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 30 19:09:03 2005 Return-Path: X-Original-To: hackers@freebsd.org 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 660C316A41F; Tue, 30 Aug 2005 19:09:03 +0000 (GMT) (envelope-from iedowse@iedowse.com) Received: from nowhere.iedowse.com (nowhere.iedowse.com [82.195.144.75]) by mx1.FreeBSD.org (Postfix) with SMTP id 993B743D45; Tue, 30 Aug 2005 19:09:02 +0000 (GMT) (envelope-from iedowse@iedowse.com) Received: from localhost ([127.0.0.1] helo=iedowse.com) by nowhere.iedowse.com via local-iedowse id ; 30 Aug 2005 20:09:00 +0100 (IST) To: "Eygene A. Ryabinkin" In-Reply-To: Your message of "Tue, 30 Aug 2005 16:50:31 +0400." <20050830125031.GA775@rea.mbslab.kiae.ru> Date: Tue, 30 Aug 2005 20:08:57 +0100 From: Ian Dowse Message-ID: <200508302009.aa99975@nowhere.iedowse.com> Cc: hackers@freebsd.org, Eugene Grosbein , freebsd-usb@freebsd.org Subject: Re: Low umass performance with USB 2.0 ports X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2005 19:09:03 -0000 In message <20050830125031.GA775@rea.mbslab.kiae.ru>, "Eygene A. Ryabinkin" wri tes: >> >> What is filesystem has your USB drive? > The one I was extensively testing has FAT, but I've checked the UFS2 -- >just a bit better -- 1.8 Mb/second. But you're right -- no wdrains at all. >> FreeBSD 4.x had very low performance with FAT filesystem, >> writing process spent lots of time in the wdrain state too. > Yes, it has. But here the same flash drive gives different results for >ehci and uhci devices, and the total speed of echi is lower due to wdrains: >300 Kb/sec versus 500 Kb/sec. And I sometimes write my data to the Windows >partition with FAT to my home HDD -- it has no wdrains. At least, I've not >noticed them. For flash I can. The patch in from the email below may help with the wdrain state - can you see if it makes any difference? Ian Date: Sun, 26 Jun 2005 17:42:44 BST To: Stefan Walter cc: freebsd-stable@freebsd.org From: Ian Dowse Subject: Re: EHCI: mtools stuck in state 'physrd' or panic OpenBSD have a workaround for problems with VIA EHCI controllers that can cause the hanging symptoms you describe. Below is a patch that implements their change in FreeBSD's driver. Could you try it to see if it helps? Thanks, Ian Index: sys/dev/usb/ehci.c =================================================================== RCS file: /dump/FreeBSD-CVS/src/sys/dev/usb/ehci.c,v retrieving revision 1.14.2.9 diff -u -r1.14.2.9 ehci.c --- sys/dev/usb/ehci.c 31 Mar 2005 19:47:11 -0000 1.14.2.9 +++ sys/dev/usb/ehci.c 26 Jun 2005 16:21:11 -0000 @@ -155,6 +155,7 @@ Static void ehci_idone(struct ehci_xfer *); Static void ehci_timeout(void *); Static void ehci_timeout_task(void *); +Static void ehci_intrlist_timeout(void *); Static usbd_status ehci_allocm(struct usbd_bus *, usb_dma_t *, u_int32_t); Static void ehci_freem(struct usbd_bus *, usb_dma_t *); @@ -491,6 +492,7 @@ EOWRITE4(sc, EHCI_ASYNCLISTADDR, sqh->physaddr | EHCI_LINK_QH); usb_callout_init(sc->sc_tmo_pcd); + usb_callout_init(sc->sc_tmo_intrlist); lockinit(&sc->sc_doorbell_lock, PZERO, "ehcidb", 0, 0); @@ -694,6 +696,11 @@ ehci_check_intr(sc, ex); } + /* Schedule a callout to catch any dropped transactions. */ + if ((sc->sc_flags & EHCI_SCFLG_LOSTINTRBUG) && + !LIST_EMPTY(&sc->sc_intrhead)) + usb_callout(sc->sc_tmo_intrlist, hz, ehci_intrlist_timeout, sc); + #ifdef USB_USE_SOFTINTR if (sc->sc_softwake) { sc->sc_softwake = 0; @@ -942,6 +949,7 @@ EOWRITE4(sc, EHCI_USBINTR, sc->sc_eintrs); EOWRITE4(sc, EHCI_USBCMD, 0); EOWRITE4(sc, EHCI_USBCMD, EHCI_CMD_HCRESET); + usb_uncallout(sc->sc_tmo_intrlist, ehci_intrlist_timeout, sc); usb_uncallout(sc->sc_tmo_pcd, ehci_pcd_enable, sc); #if defined(__NetBSD__) || defined(__OpenBSD__) @@ -2701,6 +2708,30 @@ splx(s); } + +/* + * Some EHCI chips from VIA seem to trigger interrupts before writing back the + * qTD status, or miss signalling occasionally under heavy load. If the host + * machine is too fast, we we can miss transaction completion - when we scan + * the active list the transaction still seems to be active. This generally + * exhibits itself as a umass stall that never recovers. + * + * We work around this behaviour by setting up this callback after any softintr + * that completes with transactions still pending, giving us another chance to + * check for completion after the writeback has taken place. + */ +void +ehci_intrlist_timeout(void *arg) +{ + ehci_softc_t *sc = arg; + int s = splusb(); + + DPRINTFN(3, ("ehci_intrlist_timeout\n")); + usb_schedsoftintr(&sc->sc_bus); + + splx(s); +} + /************************/ Static usbd_status Index: sys/dev/usb/ehci_pci.c =================================================================== RCS file: /dump/FreeBSD-CVS/src/sys/dev/usb/ehci_pci.c,v retrieving revision 1.14.2.2 diff -u -r1.14.2.2 ehci_pci.c --- sys/dev/usb/ehci_pci.c 13 Jun 2005 09:00:19 -0000 1.14.2.2 +++ sys/dev/usb/ehci_pci.c 26 Jun 2005 16:21:11 -0000 @@ -303,6 +303,10 @@ return ENXIO; } + /* Enable workaround for dropped interrupts as required */ + if (pci_get_vendor(self) == PCI_EHCI_VENDORID_VIA) + sc->sc_flags |= EHCI_SCFLG_LOSTINTRBUG; + /* * Find companion controllers. According to the spec they always * have lower function numbers so they should be enumerated already. Index: sys/dev/usb/ehcivar.h =================================================================== RCS file: /dump/FreeBSD-CVS/src/sys/dev/usb/ehcivar.h,v retrieving revision 1.4.2.4 diff -u -r1.4.2.4 ehcivar.h --- sys/dev/usb/ehcivar.h 22 Mar 2005 00:56:54 -0000 1.4.2.4 +++ sys/dev/usb/ehcivar.h 26 Jun 2005 16:21:11 -0000 @@ -93,6 +93,7 @@ #define EHCI_COMPANION_MAX 8 #define EHCI_SCFLG_DONEINIT 0x0001 /* ehci_init() has been called. */ +#define EHCI_SCFLG_LOSTINTRBUG 0x0002 /* workaround for VIA chipsets */ typedef struct ehci_softc { struct usbd_bus sc_bus; /* base device */ @@ -149,6 +150,7 @@ struct lock sc_doorbell_lock; usb_callout_t sc_tmo_pcd; + usb_callout_t sc_tmo_intrlist; device_ptr_t sc_child; /* /dev/usb# device */ From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 30 20:08:41 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 4CD0416A41F; Tue, 30 Aug 2005 20:08:41 +0000 (GMT) (envelope-from bushman@rsu.ru) Received: from mail.r61.net (mail.r61.net [195.208.245.249]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9307543D48; Tue, 30 Aug 2005 20:08:40 +0000 (GMT) (envelope-from bushman@rsu.ru) Received: from stinger.cc.rsu.ru (stinger.cc.rsu.ru [195.208.252.82]) by mail.r61.net (8.13.4/8.13.4) with ESMTP id j7UK8VlX021201; Wed, 31 Aug 2005 00:08:31 +0400 (MSD) (envelope-from bushman@rsu.ru) Date: Wed, 31 Aug 2005 00:12:37 +0400 (MSD) From: Michael Bushkov X-X-Sender: bushman@stinger.cc.rsu.ru To: freebsd-current@freebsd.org, freebsd-hackers@freebsd.org Message-ID: <20050830232904.V72814@stinger.cc.rsu.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV version 0.86.2, clamav-milter version 0.86 on asterix.r61.net X-Virus-Status: Clean X-Spam-Status: No, score=-5.7 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.0.4 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on asterix.r61.net Cc: Jacques Vidrine , Brooks Davis Subject: [PATCH] nsswitch and cached release 2 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2005 20:08:41 -0000 Hello! Here is the second (corrected) release of my Google SoC project (the project's aim is to implement the caching daemon and to extend the nsswitch subsystem). You can download the patch from here: http://www.rsu.ru/~bushman/nsswitch_cached.diff (the patch is absolute, use: patch -p0 < nsswitch_cached.diff) This patch includes everything that was in the previous release: - services, rpc and proto nsswitch databases implemented - passwd, group, services, rpc and proto caching implemented - caching daemon implemented The new things are: - caching for "hosts" nsswitch database is implemented - some bugs in cached were fixed. cache is now per-user (user can only use data, that he has cached by himself. he can't poison the cache of the other user) - all sources now meet the style(9) guidelines much more than they had before - and some other minor fixes Please, test the stuff if you can and send me your bug-reports :) With best regards, Michael Bushkov Rostov State University From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 30 20:22:53 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 B47DC16A41F for ; Tue, 30 Aug 2005 20:22:53 +0000 (GMT) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5A98743D45 for ; Tue, 30 Aug 2005 20:22:53 +0000 (GMT) (envelope-from sam@errno.com) Received: from [66.127.85.91] ([66.127.85.91]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id j7UKMoBd077055 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Aug 2005 13:22:51 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <4314C1B6.4070204@errno.com> Date: Tue, 30 Aug 2005 13:29:42 -0700 From: Sam Leffler User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050327) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Pierson References: <4313A2EC.5070300@errno.com> <4314A65C.4070802@errno.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Hackers Subject: Re: Atheros driver and radiotap reliability X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2005 20:22:53 -0000 Sam Pierson wrote: > On 8/30/05, Sam Leffler wrote: > >>David appears to be talking about how netbsd works. Understand that >>David does not work on FreeBSD; I'm not even sure he uses it. > > ... > >>tcpdump and ethereal get the same data. If they display it differently >>given identical data then one is wrong. If you have an example of where >>things are wrong please present it. > > I tried and it looks like everything is being displayed correctly and that > tcpdump and ethereal are displaying the same values. The only reason > I said they looked different is that in the morning when I examined a > few hundred frames with ethereal, the values were consistently 10dB > lower than what I had observed through tcpdump. I'm very glad that > they are displaying the same values now though. I'll try to verify this but I've never seen things look wrong. If in doubt save to a file and replay from file using both tools. > > >>>*it*, referring to the rssi value above? >> >>"it" = ds->ds_rxstat.rs_rssi which is the value returned by the hardware. > > > Alright, it makes much more sense now. You said earlier that we can use > the RSSI value and correspond each unit to ~.5dBm above the noise > floor. I didn't see anything being passed through the hardware which > records the noise on that same per packet basis, but I can get ahold > of the average noise floor for the environment. Will this affect the > accuracy of the measurements to the point where they will be > significantly skewed? Getting and interpreting the current noise floor is the issue. I was wrong about .5dBm, was thinking of txpower which is done in .5 units. The following comment from the linux code describes how things work in principle: /* * Units are in db above the noise floor. That means the * rssi values reported in the tx/rx descriptors in the * driver are the SNR expressed in db. * * If you assume that the noise floor is -95, which is an * excellent assumption 99.5 % of the time, then you can * derive the absolute signal level (i.e. -95 + rssi). * There are some other slight factors to take into account * depending on whether the rssi measurement is from 11b, * 11g, or 11a. These differences are at most 2db and * can be documented. */ The last bit about differences being minimal isn't quite correct; to dtrt you need to collect the noise floor on all channels and then correlate data. As I've said previously converting the units used internally by the h/w to physical units requires knowledge of things like the PA circuitry. Some vendors (e.g. Cisco) do this in their software but since we don't know what card you're using or how it's been constructed there's no way to do this in general. > > (Thanks for the help, again, it seems like there isn't a lot of information > out there regarding these topics) Information is in the code. Sam From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 30 20:33:23 2005 Return-Path: X-Original-To: hackers@freebsd.org 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 F051D16A41F; Tue, 30 Aug 2005 20:33:23 +0000 (GMT) (envelope-from saturnero@freesbie.org) Received: from jail1-fbsd4.consiagnet.it (jail1-fbsd4.consiagnet.it [83.149.128.151]) by mx1.FreeBSD.org (Postfix) with ESMTP id DC18C43D46; Tue, 30 Aug 2005 20:33:20 +0000 (GMT) (envelope-from saturnero@freesbie.org) Received: from [192.168.10.2] (host235-73.pool8256.interbusiness.it [82.56.73.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by jail1-fbsd4.consiagnet.it (Postfix) with ESMTP id 0BF095836; Tue, 30 Aug 2005 22:34:49 +0200 (CEST) Message-ID: <4314C299.3030003@freesbie.org> Date: Tue, 30 Aug 2005 22:33:29 +0200 From: Dario Freni User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050828) X-Accept-Language: en-us, en MIME-Version: 1.0 To: hackers@freebsd.org, current@freebsd.org, freesbie@gufi.org, esperti@gufi.org X-Enigmail-Version: 0.92.0.0 OpenPGP: url=http://www.saturnero.net/saturnero.asc Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig74C4A2F9C77E3C2A12E3D155" Cc: Subject: FreeSBIE 2 toolkit, developers' preview X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2005 20:33:24 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig74C4A2F9C77E3C2A12E3D155 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi guys, I've put a snapshot of the now toolkit I've been working for the Google Summer of Code here: http://cvs.freesbie.org/~saturnero/freesbie2.tar.gz If you have a FreeBSD version > 6.x, on i386, amd64 and powerpc, you can give it a test and send feedbacks to me. As usual, comments and suggestions are greatly appreciated. Many thanks to Google for this wonderful opportunity, as well as FreeBSD release engeering members (particularly Murray Stokely) for mentoring, Peter Grehan and many FreeBSD developers for being so nice and responsive. Bye everybody, Dario -- Dario Freni (saturnero@freesbie.org) FreeSBIE developer (http://www.freesbie.org) GPG Public key at http://www.saturnero.net/saturnero.asc --------------enig74C4A2F9C77E3C2A12E3D155 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDFMKZymi72IiShysRAtRQAKDZJMfGW/rk5XZHzV9X8i94UQHsBACfQaU5 yE1iWheQ8g9GnBzpiaVvNzc= =c42A -----END PGP SIGNATURE----- --------------enig74C4A2F9C77E3C2A12E3D155-- From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 30 21:13:16 2005 Return-Path: X-Original-To: hackers@freebsd.org 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 EDBE116A41F; Tue, 30 Aug 2005 21:13:16 +0000 (GMT) (envelope-from jonny@jonny.eng.br) Received: from coe.ufrj.br (roma.coe.ufrj.br [146.164.53.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4035343D45; Tue, 30 Aug 2005 21:13:15 +0000 (GMT) (envelope-from jonny@jonny.eng.br) Received: from localhost (localhost [127.0.0.1]) by coe.ufrj.br (Postfix) with ESMTP id 780FD1771C; Tue, 30 Aug 2005 18:13:11 -0300 (BRT) Received: from coe.ufrj.br ([146.164.53.65]) by localhost (roma.coe.ufrj.br [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 77763-08; Tue, 30 Aug 2005 18:13:02 -0300 (BRT) Received: from [135.153.2.243] (200-150-191-54.corp.ajato.com.br [200.150.191.54]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by coe.ufrj.br (Postfix) with ESMTP id F067F1771B; Tue, 30 Aug 2005 18:12:59 -0300 (BRT) Message-ID: <4314CBCE.7010405@jonny.eng.br> Date: Tue, 30 Aug 2005 18:12:46 -0300 From: =?UTF-8?B?Sm/Do28gQ2FybG9zIE1lbmRlcyBMdcOtcw==?= User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Eygene A. Ryabinkin" References: <20050830092818.GD881@rea.mbslab.kiae.ru> In-Reply-To: <20050830092818.GD881@rea.mbslab.kiae.ru> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at coe.ufrj.br Cc: hackers@freebsd.org, freebsd-usb@freebsd.org Subject: Re: Low umass performance with USB 2.0 ports X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2005 21:13:17 -0000 Eygene A. Ryabinkin wrote: > Good day. > I am observing very low umass performance: when I am trying to move a large > file from/to my USB 2.0 flash that is plugged into the USB 2.0 port: transfer > starts fine at 3.5 Mb/sec, but after some 20 Mbytes it hangs and the process > (dd) stay in the wdrain state. The activity LED on the flash shows no activity. > Operations do continue, but very slow and the most time of the copying process > spends in the wdrain state. All attempts to invoke `sync` or to see the > file state via `ls` are hanging until `dd` leaves the wdrain state. > It does not matter what flash is used: I tried Apacer and the Kingmax ones -- > the result is the same. > If I plug the flash into the USB 1.1 port and trying to move some data -- it > works fine, no hangs. Speed is 500 Kb/sec. > Seems like others do have this problem: > http://lists.freebsd.org/pipermail/freebsd-usb/2005-May/001052.html > USB 2.0 controller is Promise PCI (NEC chipset), USB 1.1 chipset is onboard > VIA. > My dmesg output is: ... > umass0: Phase Error, residue = 0 > (da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0x4, scsi status == 0x0 > umass0: Phase Error, residue = 0 > (da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0x4, scsi status == 0x0 > umass0: Phase Error, residue = 0 > (da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0x4, scsi status == 0x0 > umass0: Phase Error, residue = 0 > (da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0x4, scsi status == 0x0 > Mounting root from ufs:/dev/ad0s1a > em0: Link is up 100 Mbps Full Duplex > info: [drm] Loading R200 Microcode I had exactly this problem with Kingston Data Traveler II+, and apparently completely solved it by adding a kludge to disallow Cache Syncronization. Try it yourself. From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 31 00:35:40 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 31DF916A41F for ; Wed, 31 Aug 2005 00:35:40 +0000 (GMT) (envelope-from fetrovsky@yahoo.com) Received: from web53913.mail.yahoo.com (web53913.mail.yahoo.com [206.190.38.162]) by mx1.FreeBSD.org (Postfix) with SMTP id A7DDB43D46 for ; Wed, 31 Aug 2005 00:35:39 +0000 (GMT) (envelope-from fetrovsky@yahoo.com) Received: (qmail 4704 invoked by uid 60001); 31 Aug 2005 00:35:39 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=LWML1QWmU0K8+pX8aonXohdJ8pifgxqFhFbIM8Q8eImTfgRWb9yrFJTq2KyUQoJLq7e+BfEoaMJA9yLELLYssuZIGneIzwwlpen7Ywu395B5ErkYm4oFHJOMH66L5A8o75gUieQodfimvdbGWBuHCODPkEn3jKOFuiGd/ysbC1I= ; Message-ID: <20050831003539.4702.qmail@web53913.mail.yahoo.com> Received: from [128.200.38.50] by web53913.mail.yahoo.com via HTTP; Tue, 30 Aug 2005 17:35:39 PDT Date: Tue, 30 Aug 2005 17:35:39 -0700 (PDT) From: Daniel Valencia To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: strange behaviour with pthread_cond_wait() X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2005 00:35:40 -0000 Hello, everybody... I have this multithreaded program, and there are these two threads that work together with a queue. The backend receive thread reads packets and pushes them into the queue, while the frontend thread pops them off the queue to hand them to the caller. This is an implementation of a software switch. The issue is, i have this little piece of code in the thread which actually performs the popping: if( !_recvq.size() ) { int e = pthread_cond_wait( &_thread_cond_recv, &_thread_mutex_recv ); if( e ) { std::perror( "pthread_cond_wait" ); std::exit( e ); } } pthread_mutex_lock( &_recvq_mutex ); p = _recvq.front(); _recvq.pop(); pthread_mutex_unlock( &_recvq_mutex ); And when I runn my program, it will immediately exit. The message is: pthread_cond_wait: Unknown error: 0 Not only that: the returned value (e) is 1, while EINVAL is 22. According to the man pages, if successful, pthread_cond_wait() will return 0; else, it will return a value indicating the error (the only possible value being EINVAL). My mutex address is not NULL, for I am taking the address of an automatic object (I checked anyways). Any hints will be greatly appreciated. Thank you, Daniel __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 31 00:44:50 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 7E4CE16A41F for ; Wed, 31 Aug 2005 00:44:50 +0000 (GMT) (envelope-from keramida@linux.gr) Received: from nic.ach.sch.gr (nic.sch.gr [194.63.238.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 687A943D4C for ; Wed, 31 Aug 2005 00:44:47 +0000 (GMT) (envelope-from keramida@linux.gr) Received: (qmail 8276 invoked by uid 207); 31 Aug 2005 00:44:45 -0000 Received: from keramida@linux.gr by nic by uid 201 with qmail-scanner-1.21 (sophie: 3.04/2.19/3.81. Clear:RC:1(81.186.70.81):. Processed in 0.537209 secs); 31 Aug 2005 00:44:46 -0000 Received: from dialup81.ach.sch.gr (HELO gothmog.gr) ([81.186.70.81]) (envelope-sender ) by nic.sch.gr (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 31 Aug 2005 00:44:44 -0000 Received: from gothmog.gr (gothmog [127.0.0.1]) by gothmog.gr (8.13.4/8.13.4) with ESMTP id j7V0igKo020189; Wed, 31 Aug 2005 03:44:42 +0300 (EEST) (envelope-from keramida@linux.gr) Received: (from giorgos@localhost) by gothmog.gr (8.13.4/8.13.4/Submit) id j7V0ifLo020185; Wed, 31 Aug 2005 03:44:41 +0300 (EEST) (envelope-from keramida@linux.gr) Date: Wed, 31 Aug 2005 03:44:41 +0300 From: Giorgos Keramidas To: Daniel Valencia Message-ID: <20050831004441.GB17733@gothmog.gr> References: <20050831003539.4702.qmail@web53913.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050831003539.4702.qmail@web53913.mail.yahoo.com> Cc: freebsd-hackers@freebsd.org Subject: Re: strange behaviour with pthread_cond_wait() X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2005 00:44:50 -0000 On 2005-08-30 17:35, Daniel Valencia wrote: > Hello, everybody... > > I have this multithreaded program, and there are these two threads > that work together with a queue. The backend receive thread reads > packets and pushes them into the queue, while the frontend thread pops > them off the queue to hand them to the caller. This is an > implementation of a software switch. > > The issue is, i have this little piece of code in the thread which > actually performs the popping: This is not a complete, compilable program. It's usually much easier to track down problems by looking at a minimal example that exhibits the problem. Can you post one? > if( !_recvq.size() ) > { > int e = pthread_cond_wait( &_thread_cond_recv, > &_thread_mutex_recv ); > > if( e ) > { > std::perror( "pthread_cond_wait" ); > std::exit( e ); > } > } > > pthread_mutex_lock( &_recvq_mutex ); > p = _recvq.front(); > _recvq.pop(); > pthread_mutex_unlock( &_recvq_mutex ); From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 31 00:48:20 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 572F816A41F for ; Wed, 31 Aug 2005 00:48:20 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id EF22343D45 for ; Wed, 31 Aug 2005 00:48:19 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.ntplx.net (8.13.4/8.13.4/NETPLEX) with ESMTP id j7V0mIei004171; Tue, 30 Aug 2005 20:48:18 -0400 (EDT) Date: Tue, 30 Aug 2005 20:48:18 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Daniel Valencia In-Reply-To: <20050831003539.4702.qmail@web53913.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) Cc: freebsd-hackers@freebsd.org Subject: Re: strange behaviour with pthread_cond_wait() X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2005 00:48:20 -0000 On Tue, 30 Aug 2005, Daniel Valencia wrote: > Hello, everybody... > > I have this multithreaded program, and there are these > two threads that work together with a queue. The > backend receive thread reads packets and pushes them > into the queue, while the frontend thread pops them > off the queue to hand them to the caller. This is an > implementation of a software switch. > > The issue is, i have this little piece of code in the > thread which actually performs the popping: [ ... ] > And when I runn my program, it will immediately exit. > The message is: > > pthread_cond_wait: Unknown error: 0 > > Not only that: the returned value (e) is 1, while > EINVAL is 22. According to the man pages, if 1 is EPERM. And from the POSIX Spec (see http://www.opengroup.org/onlinepubs/009695399/toc.htm): [EPERM] The mutex was not owned by the current thread at the time of the call. I suggest Butenhof's "Programming with POSIX Threads" book. -- DE From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 31 01:52:37 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 7F5EB16A41F for ; Wed, 31 Aug 2005 01:52:37 +0000 (GMT) (envelope-from fetrovsky@yahoo.com) Received: from web53901.mail.yahoo.com (web53901.mail.yahoo.com [206.190.36.211]) by mx1.FreeBSD.org (Postfix) with SMTP id E9C1C43D48 for ; Wed, 31 Aug 2005 01:52:36 +0000 (GMT) (envelope-from fetrovsky@yahoo.com) Received: (qmail 53067 invoked by uid 60001); 31 Aug 2005 01:52:36 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=vUgJS2xZBXfjBRMTNGBMI0IduxnPkcgMzcmeAbhi798nwBS/1fi29m/ohUbcDqWRKF2POaqkTWxYBfbaU3iKclGYBLX6ELlzP6hhX52WuASJ01jPyAFCwS5cDBYZaORABieibKmJRbxwURgbOH9mzHXiq0pM1856UkwXtdrCLOA= ; Message-ID: <20050831015236.53063.qmail@web53901.mail.yahoo.com> Received: from [128.200.38.50] by web53901.mail.yahoo.com via HTTP; Tue, 30 Aug 2005 18:52:36 PDT Date: Tue, 30 Aug 2005 18:52:36 -0700 (PDT) From: Daniel Valencia To: freebsd-hackers@freebsd.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: strange behaviour with pthread_cond_wait() X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2005 01:52:37 -0000 Hello I just had to lock the mutex before waiting on the condition... my problem is solved now. Thank you very much for the tip. Daniel __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 31 02:09:38 2005 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.org 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 F12A016A41F; Wed, 31 Aug 2005 02:09:37 +0000 (GMT) (envelope-from ume@mahoroba.org) Received: from ameno.mahoroba.org (gw4.mahoroba.org [218.45.22.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0440343D48; Wed, 31 Aug 2005 02:09:35 +0000 (GMT) (envelope-from ume@mahoroba.org) Received: from kasuga.mahoroba.org (IDENT:2eHbhZwaIgDo2Sydkd9PkM8205jAVq/2DsXz60tdO2bPgF2z8Zr9R6zsSpdWUgcd@[IPv6:3ffe:501:185b:801a:20b:97ff:fe2e:b521]) (user=ume mech=CRAM-MD5 bits=0) by ameno.mahoroba.org (8.13.4/8.13.4) with ESMTP/inet6 id j7V29LJV088412 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Aug 2005 11:09:27 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Wed, 31 Aug 2005 11:09:15 +0900 Message-ID: From: Hajimu UMEMOTO To: Doug Barton In-Reply-To: <431410F1.7020509@FreeBSD.org> References: <431410F1.7020509@FreeBSD.org> User-Agent: xcite1.38> Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/22.0.50 (i386-unknown-freebsd6.0) MULE/5.0 (SAKAKI) X-Operating-System: FreeBSD 6.0-BETA3 X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE Organization: Internet Mutual Aid Society, YOKOHAMA MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0 (ameno.mahoroba.org [IPv6:3ffe:501:185b:8010::1]); Wed, 31 Aug 2005 11:09:29 +0900 (JST) X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.4 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on ameno.mahoroba.org Cc: freebsd-hackers@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: ip6.int deprecated X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2005 02:09:38 -0000 Hi, >>>>> On Tue, 30 Aug 2005 00:55:29 -0700 >>>>> Doug Barton said: dougb> The one step I'm going to take directly to support this deprecation is to dougb> remove the ip6.int example from the sample named.conf file in the base. I'm dougb> sending this message to provide notice of that, and notice to the community dougb> generally that we should start moving in the direction of deprecating dougb> ip6.int wherever it might be found. I think it's a time to nuke RFC 1886 example from our named.conf. dougb> Other than some old references in src/contrib/bind9, the only place I see a dougb> reference to ip6.int in our base is in the named.conf file that I mentioned dougb> above. I hope that this note is useful however as a more general source of dougb> information, and of course if there is anything I've missed, I welcome dougb> others to take appropriate action. Yes, there were ip6.int. lookups in our libc. But, I nuked them already about one year ago. I left named.conf as is intentionally at the time to help the boxes which don't support RFC 3152. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 31 05:50:28 2005 Return-Path: X-Original-To: hackers@freebsd.org 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 E672D16A41F; Wed, 31 Aug 2005 05:50:28 +0000 (GMT) (envelope-from freebsd@rea.mbslab.kiae.ru) Received: from rea.mbslab.kiae.ru (rea.mbslab.kiae.ru [144.206.177.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 817D743D49; Wed, 31 Aug 2005 05:50:28 +0000 (GMT) (envelope-from freebsd@rea.mbslab.kiae.ru) Received: from rea.mbslab.kiae.ru (localhost [127.0.0.1]) by rea.mbslab.kiae.ru (Postfix) with ESMTP id 78CA0BB0A; Wed, 31 Aug 2005 09:50:26 +0400 (MSD) Received: by rea.mbslab.kiae.ru (Postfix, from userid 1000) id 4DA6CBB02; Wed, 31 Aug 2005 09:50:26 +0400 (MSD) Date: Wed, 31 Aug 2005 09:50:26 +0400 From: "Eygene A. Ryabinkin" To: Jo??o Carlos Mendes Lu??s Message-ID: <20050831055026.GE1645@rea.mbslab.kiae.ru> References: <20050830092818.GD881@rea.mbslab.kiae.ru> <4314CBCE.7010405@jonny.eng.br> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <4314CBCE.7010405@jonny.eng.br> User-Agent: Mutt/1.5.9i X-AV-Checked: Yes! Cc: hackers@freebsd.org, freebsd-usb@freebsd.org Subject: Re: Low umass performance with USB 2.0 ports X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2005 05:50:29 -0000 > I had exactly this problem with Kingston Data Traveler II+, and > apparently completely solved it by adding a kludge to disallow Cache > Syncronization. Try it yourself. And the kludge is? -- rea From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 31 07:29:17 2005 Return-Path: X-Original-To: hackers@freebsd.org 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 3D48516A41F for ; Wed, 31 Aug 2005 07:29:17 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from mail09.syd.optusnet.com.au (mail09.syd.optusnet.com.au [211.29.132.190]) by mx1.FreeBSD.org (Postfix) with ESMTP id 55CBF43D45 for ; Wed, 31 Aug 2005 07:29:15 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c220-239-19-236.belrs4.nsw.optusnet.com.au [220.239.19.236]) by mail09.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id j7V7T9Ak009021 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Wed, 31 Aug 2005 17:29:13 +1000 Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1]) by cirb503493.alcatel.com.au (8.12.10/8.12.10) with ESMTP id j7V7T9SR075431 for ; Wed, 31 Aug 2005 17:29:09 +1000 (EST) (envelope-from pjeremy@cirb503493.alcatel.com.au) Received: (from pjeremy@localhost) by cirb503493.alcatel.com.au (8.12.10/8.12.9/Submit) id j7V7T95m075430 for hackers@freebsd.org; Wed, 31 Aug 2005 17:29:09 +1000 (EST) (envelope-from pjeremy) Date: Wed, 31 Aug 2005 17:29:08 +1000 From: Peter Jeremy To: hackers@freebsd.org Message-ID: <20050831072908.GA73852@cirb503493.alcatel.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2i Cc: Subject: Determining where mbufs are in use X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2005 07:29:17 -0000 I think I have a system that is leaking mbufs and I'd like some ideas on how to track down what mbufs are in use. Background: The system is running 4.9p1 and has been up for about 8 months. I haven't noticed any problems before. This afternoon, I opened an xterm, did an slogin to another system and ran "ipfw l" on that system. The output froze about halfway through and I noticed that my system was barely responding. A check of the console showed that the system was out of mbuf clusters (1024). I killed a couple of ssh sessions and the in-use mbufs and clusters dropped to 440 but that still strikes me as excessive. My laptop shows 12 clusters in use with a maximum of 74 after a month of uptime. The system in question is my main workstation at work. It has dual heads with a virtual WM and I tend to have lots of xterms open (maybe 50-60, both local and ssh). It's an NFS client but not server. netstat showed only a couple of dozen TCP sockets, though there are a lot of Unix domain sockets (for X) - none had any data queued. Is there any easy way to work out where all the mbufs have gone? -- Peter Jeremy From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 31 10:21:13 2005 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.org 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 56B3416A41F; Wed, 31 Aug 2005 10:21:13 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from postfix4-1.free.fr (postfix4-1.free.fr [213.228.0.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 01FB543D46; Wed, 31 Aug 2005 10:21:12 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (vol75-8-82-233-239-98.fbx.proxad.net [82.233.239.98]) by postfix4-1.free.fr (Postfix) with ESMTP id 0F09A319E27; Wed, 31 Aug 2005 12:21:12 +0200 (CEST) Received: by tatooine.tataz.chchile.org (Postfix, from userid 1000) id 90883405A; Wed, 31 Aug 2005 12:21:30 +0200 (CEST) Date: Wed, 31 Aug 2005 12:21:30 +0200 From: Jeremie Le Hen To: Doug Barton Message-ID: <20050831102130.GE659@obiwan.tataz.chchile.org> References: <431410F1.7020509@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <431410F1.7020509@FreeBSD.org> User-Agent: Mutt/1.5.9i Cc: freebsd-hackers@FreeBSD.org, freebsd-arch@freebsd.org Subject: Re: ip6.int deprecated X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2005 10:21:13 -0000 Hi Doug, On Tue, Aug 30, 2005 at 12:55:29AM -0700, Doug Barton wrote: > [...] > > Other than some old references in src/contrib/bind9, the only place I see a > reference to ip6.int in our base is in the named.conf file that I mentioned > above. I hope that this note is useful however as a more general source of > information, and of course if there is anything I've missed, I welcome > others to take appropriate action. I think however it would be worth adding a small note in a manpage (I can't think of which, named.conf(5) isn't an option since this is an imported software) telling that ip6.int is deprecated in favor to ip6.arpa, this would prevent some traffic on -net@. Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 31 11:39:45 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 C059C16A41F for ; Wed, 31 Aug 2005 11:39:45 +0000 (GMT) (envelope-from nospam@mgedv.net) Received: from mgedv.at (www.mgedv.at [195.3.87.103]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0922143D46 for ; Wed, 31 Aug 2005 11:39:45 +0000 (GMT) (envelope-from nospam@mgedv.net) Received: from metis (localhost [127.0.0.1]) by mgedv.at (SMTPServer) with ESMTP id C4974186800 for ; Wed, 31 Aug 2005 13:39:43 +0200 (MEST) From: "mdff" To: Date: Wed, 31 Aug 2005 13:39:58 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <20050824010022.GA19515@panix.com> Thread-Index: AcWoR8Hz91vRZvTQToOljsnpSuLkWQF2As0g X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Message-Id: <20050831113943.C4974186800@mgedv.at> Subject: RE: IBM Active Protection System Approach X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: nospam@mgedv.net List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2005 11:39:45 -0000 > what would be the best approach to implement aps on FreeBSD? > We have to poll the device for information quiet often to detect a possible shock early enough to park disk drive heads. > Would an daemon be sufficient for that? Reaction time? What about an kernel thread? sorry for being that late on this, but just a thought: shouldn't this be an issue for the hdd-vendors to put this kind of protection algorithm directly into their hdd-controller-firmware? also, the accel.-detection could be on the hdd, not inside the nb. couldn't this save time and programming efforts for parking, flushing or even stopping the heads/plates? what about some kind of electronic "brake" that immed. stops the rotating plates in case of detection of such an event? cu... ps: just reply to the list, i'm on it! From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 31 06:29:47 2005 Return-Path: X-Original-To: hackers@freebsd.org 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 209F016A41F; Wed, 31 Aug 2005 06:29:47 +0000 (GMT) (envelope-from rea@rea.mbslab.kiae.ru) Received: from rea.mbslab.kiae.ru (rea.mbslab.kiae.ru [144.206.177.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4270B43D49; Wed, 31 Aug 2005 06:29:46 +0000 (GMT) (envelope-from rea@rea.mbslab.kiae.ru) Received: from rea.mbslab.kiae.ru (localhost [127.0.0.1]) by rea.mbslab.kiae.ru (Postfix) with ESMTP id D4212BC58; Wed, 31 Aug 2005 10:29:44 +0400 (MSD) Received: by rea.mbslab.kiae.ru (Postfix, from userid 1000) id 711C8BABE; Wed, 31 Aug 2005 10:29:43 +0400 (MSD) Date: Wed, 31 Aug 2005 10:29:42 +0400 From: "Eygene A. Ryabinkin" To: Ian Dowse Message-ID: <20050831062942.GA801@rea.mbslab.kiae.ru> References: <20050830125031.GA775@rea.mbslab.kiae.ru> <200508302009.aa99975@nowhere.iedowse.com> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <200508302009.aa99975@nowhere.iedowse.com> User-Agent: Mutt/1.5.9i X-AV-Checked: Yes! X-Mailman-Approved-At: Wed, 31 Aug 2005 12:32:16 +0000 Cc: hackers@freebsd.org, freebsd-usb@freebsd.org Subject: Re: Low umass performance with USB 2.0 ports X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2005 06:29:47 -0000 As Ian Dowse wrote to me at Tue, Aug 30, 2005 at 08:08:57PM +0100: > The patch in from the email below may help with the wdrain state - > can you see if it makes any difference? > No, it does not make any. Mainly because my USB 2.0 controller is NEC-based (not VIA), so LOSTINTRBUG flag is not set. Anyway, thanks for your help! -- rea From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 31 17:03:50 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 74CE216A41F for ; Wed, 31 Aug 2005 17:03:50 +0000 (GMT) (envelope-from killing@multiplay.co.uk) Received: from multiplay.co.uk (www1.multiplay.co.uk [212.42.16.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id 62A5C43D58 for ; Wed, 31 Aug 2005 17:03:49 +0000 (GMT) (envelope-from killing@multiplay.co.uk) Received: from vader ([212.135.219.179]) by multiplay.co.uk (multiplay.co.uk [212.42.16.7]) (MDaemon.PRO.v8.1.0.R) with ESMTP id md50001837733.msg for ; Wed, 31 Aug 2005 17:56:38 +0100 Message-ID: <02db01c5ae4d$e38a1780$b3db87d4@multiplay.co.uk> From: "Steven Hartland" To: Date: Wed, 31 Aug 2005 18:03:13 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Spam-Processed: multiplay.co.uk, Wed, 31 Aug 2005 17:56:38 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 212.135.219.179 X-Return-Path: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-hackers@freebsd.org X-MDAV-Processed: multiplay.co.uk, Wed, 31 Aug 2005 17:56:38 +0100 Subject: Debugging an unknown reboot (disk / io related) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2005 17:03:50 -0000 When running a large rsync on one of our machines here it constantly ditches and reboots leaving no traces in the logs or anything. It looks like it could be a driver error but with no crash log or panic message to go on I dont know where to start. The machine is running 5.4-RELEASE-p2 and the latest driver set downloaded and compiled locally. The only error I have to go on is the errors displayed in the ssh session running the rsync. 35111 files to consider rsync: readdir(games/fps/sof2/server): Input/output error (5) rsync: readdir(games/fps/soldner): Input/output error (5) ... ... rsync: mkstemp "/usr/home/ftp/pub/apps/3dmark/win32/.3DMark03.exe.NhcgGA" failed: Input/output error (5) rsync: connection unexpectedly closed (1667283 bytes received so far) [receiver] rsync error: error in rsync protocol data stream (code 12) at io.c(365) rsync: connection unexpectedly closed (1667263 bytes received so far) [generator] rsync error: error in rsync protocol data stream (code 12) at io.c(365) Segmentation fault root@backup1> I've tried running with witness enabled but it fails to boot with a message about hpt_lock. I also tried originally with the default hptmv driver and no joy. When it crashes it takes the RAID5 with it always dropping the same disk. I've replaced the cable, disk and even plugged the disk direct to the raid controller on a different channel to eliminate the supermicro hotswap bay the disks are mounted in and still no changes the same disk always gets dropped. So the question is what can I try to get more info on what's happening? [dmesg] Aug 31 17:56:28 backup1 syslogd: kernel boot file is /boot/kernel/kernel Aug 31 17:56:28 backup1 kernel: Copyright (c) 1992-2005 The FreeBSD Project. Aug 31 17:56:28 backup1 kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 Aug 31 17:56:28 backup1 kernel: The Regents of the University of California. All rights reserved. Aug 31 17:56:28 backup1 kernel: FreeBSD 5.4-RELEASE-p2 #6: Thu Jun 23 00:23:54 UTC 2005 Aug 31 17:56:28 backup1 kernel: root@backup1:/.usr/i386/src/sys/i386/compile/MPUK_SMP_200HZ Aug 31 17:56:28 backup1 kernel: Timecounter "i8254" frequency 1193182 Hz quality 0 Aug 31 17:56:28 backup1 kernel: CPU: AMD Opteron(tm) Processor 244 (1794.41-MHz 686-class CPU) Aug 31 17:56:28 backup1 kernel: Origin = "AuthenticAMD" Id = 0xf5a Stepping = 10 Aug 31 17:56:28 backup1 kernel: Features=0x78bfbff Aug 31 17:56:28 backup1 kernel: AMD Features=0xe0500000 Aug 31 17:56:28 backup1 kernel: AMD Features=0xe0500000 Aug 31 17:56:28 backup1 kernel: real memory = 2146893824 (2047 MB) Aug 31 17:56:28 backup1 kernel: avail memory = 2099625984 (2002 MB) Aug 31 17:56:28 backup1 kernel: ACPI APIC Table: Aug 31 17:56:28 backup1 kernel: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs Aug 31 17:56:28 backup1 kernel: cpu0 (BSP): APIC ID: 0 Aug 31 17:56:28 backup1 kernel: cpu1 (AP): APIC ID: 1 Aug 31 17:56:28 backup1 kernel: MADT: Forcing active-low polarity and level trigger for SCI Aug 31 17:56:28 backup1 kernel: ioapic0 irqs 0-23 on motherboard Aug 31 17:56:28 backup1 kernel: ioapic1 irqs 24-27 on motherboard Aug 31 17:56:28 backup1 kernel: ioapic2 irqs 28-31 on motherboard Aug 31 17:56:28 backup1 kernel: npx0: on motherboard Aug 31 17:56:28 backup1 kernel: npx0: INT 16 interface Aug 31 17:56:28 backup1 kernel: acpi0: on motherboard Aug 31 17:56:28 backup1 kernel: acpi0: Power Button (fixed) Aug 31 17:56:28 backup1 kernel: acpi0: Sleep Button (fixed) Aug 31 17:56:28 backup1 kernel: acpi_bus_number: can't get _ADR Aug 31 17:56:28 backup1 last message repeated 2 times Aug 31 17:56:28 backup1 kernel: unknown: I/O range not supported Aug 31 17:56:28 backup1 kernel: unknown: I/O range not supported Aug 31 17:56:28 backup1 kernel: ACPI-1304: *** Error: Method execution failed [\_SB_.PCI0.LPC_.LPT_._CRS] (Node 0xc30937a0), AE_AML_BUFFER_LIMIT Aug 31 17:56:28 backup1 kernel: ACPI-0239: *** Error: Method execution failed [\_SB_.PCI0.LPC_.LPT_._CRS] (Node 0xc30937a0), AE_AML_BUFFER_LIMIT Aug 31 17:56:28 backup1 kernel: can't fetch resources for \_SB_.PCI0.LPC_.LPT_ - AE_AML_BUFFER_LIMIT Aug 31 17:56:28 backup1 kernel: Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 Aug 31 17:56:28 backup1 kernel: acpi_timer0: <24-bit timer at 3.579545MHz> port 0x8008-0x800b on acpi0 Aug 31 17:56:28 backup1 kernel: cpu0: on acpi0 Aug 31 17:56:28 backup1 kernel: cpu1: on acpi0 Aug 31 17:56:28 backup1 kernel: acpi_button0: on acpi0 Aug 31 17:56:28 backup1 kernel: pcib0: port 0xcf8-0xcff on acpi0 Aug 31 17:56:28 backup1 kernel: pci0: on pcib0 Aug 31 17:56:28 backup1 kernel: pcib1: at device 1.0 on pci0 Aug 31 17:56:28 backup1 kernel: pci1: on pcib1 Aug 31 17:56:28 backup1 kernel: pci1: at device 0.0 (no driver attached) Aug 31 17:56:28 backup1 kernel: pcib2: at device 6.0 on pci0 Aug 31 17:56:28 backup1 kernel: pci2: on pcib2 Aug 31 17:56:28 backup1 kernel: bge0: mem 0xe8100000-0xe810ffff irq 19 at device 5.0 on pci2 Aug 31 17:56:28 backup1 kernel: miibus0: on bge0 Aug 31 17:56:28 backup1 kernel: brgphy0: on miibus0 Aug 31 17:56:28 backup1 kernel: brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto Aug 31 17:56:28 backup1 kernel: bge0: Ethernet address: 00:0f:ea:7a:50:08 Aug 31 17:56:28 backup1 kernel: atapci0: port 0x3000-0x300f,0x3010-0x3013,0x3018-0x301f,0x3014-0x3017,0x3020-0x3027 mem 0xe8110000-0xe81103ff irq 18 at device 6.0 on pci2 Aug 31 17:56:28 backup1 kernel: ata2: channel #0 on atapci0 Aug 31 17:56:28 backup1 kernel: ata3: channel #1 on atapci0 Aug 31 17:56:28 backup1 kernel: ata4: channel #2 on atapci0 Aug 31 17:56:28 backup1 kernel: ata5: channel #3 on atapci0 Aug 31 17:56:28 backup1 kernel: isab0: at device 7.0 on pci0 Aug 31 17:56:28 backup1 kernel: isa0: on isab0 Aug 31 17:56:28 backup1 kernel: atapci1: port 0x1000-0x100f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 7.1 on pci0 Aug 31 17:56:28 backup1 kernel: ata0: channel #0 on atapci1 Aug 31 17:56:28 backup1 kernel: ata1: channel #1 on atapci1 Aug 31 17:56:28 backup1 kernel: pci0: at device 7.3 (no driver attached) Aug 31 17:56:28 backup1 kernel: pcib3: on acpi0 Aug 31 17:56:28 backup1 kernel: pci8: on pcib3 Aug 31 17:56:28 backup1 kernel: pcib4: at device 3.0 on pci8 Aug 31 17:56:28 backup1 kernel: pci9: on pcib4 Aug 31 17:56:28 backup1 kernel: bge1: mem 0xf8100000-0xf810ffff irq 25 at device 1.0 on pci9 Aug 31 17:56:28 backup1 kernel: bge1: Ethernet address: 00:10:18:0d:cc:da Aug 31 17:56:28 backup1 kernel: pci8: at device 3.1 (no driver attached) Aug 31 17:56:28 backup1 kernel: pcib5: at device 4.0 on pci8 Aug 31 17:56:28 backup1 kernel: pci14: on pcib5 Aug 31 17:56:28 backup1 kernel: hptmv0: mem 0xf8200000-0xf827ffff irq 30 at device 2.0 on pci14 Aug 31 17:56:28 backup1 kernel: RocketRAID 182x SATA Controller driver Version 1.1 Aug 31 17:56:28 backup1 kernel: RR182x [0,0]: channel started successfully Aug 31 17:56:28 backup1 kernel: RR182x [0,1]: channel started successfully Aug 31 17:56:28 backup1 kernel: RR182x [0,2]: channel started successfully Aug 31 17:56:28 backup1 kernel: RR182x [0,4]: channel started successfully Aug 31 17:56:28 backup1 kernel: RR182x [0,5]: channel started successfully Aug 31 17:56:28 backup1 kernel: RR182x: RAID5 write-back enabled Aug 31 17:56:28 backup1 kernel: pci8: at device 4.1 (no driver attached) Aug 31 17:56:28 backup1 kernel: atkbdc0: port 0x64,0x60 irq 1 on acpi0 Aug 31 17:56:28 backup1 kernel: atkbd0: irq 1 on atkbdc0 Aug 31 17:56:28 backup1 kernel: fdc0: port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on acpi0 Aug 31 17:56:28 backup1 kernel: sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 Aug 31 17:56:28 backup1 kernel: sio0: type 16550A Aug 31 17:56:28 backup1 kernel: sio1: configured irq 3 not in bitmap of probed irqs 0 Aug 31 17:56:28 backup1 kernel: sio1: port may not be enabled Aug 31 17:56:28 backup1 kernel: sio1: configured irq 3 not in bitmap of probed irqs 0 Aug 31 17:56:28 backup1 kernel: sio1: port may not be enabled Aug 31 17:56:28 backup1 kernel: orm0: at iomem 0xcd000-0xd2fff,0xcb000-0xccfff,0xc0000-0xcafff on isa0 Aug 31 17:56:28 backup1 kernel: sc0: at flags 0x100 on isa0 Aug 31 17:56:28 backup1 kernel: sc0: VGA <16 virtual consoles, flags=0x300> Aug 31 17:56:28 backup1 kernel: vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Aug 31 17:56:28 backup1 kernel: sio1: configured irq 3 not in bitmap of probed irqs 0 Aug 31 17:56:28 backup1 kernel: sio1: port may not be enabled Aug 31 17:56:28 backup1 kernel: Timecounters tick every 5.000 msec Aug 31 17:56:28 backup1 kernel: da0 at hptmv0 bus 0 target 0 lun 0 Aug 31 17:56:28 backup1 kernel: da0: Fixed Direct Access SCSI-0 device Aug 31 17:56:28 backup1 kernel: da0: 1526216MB (3125691008 512 byte sectors: 255H 63S/T 194565C) Aug 31 17:56:28 backup1 kernel: da1 at hptmv0 bus 0 target 1 lun 0 Aug 31 17:56:28 backup1 kernel: da1: Fixed Direct Access SCSI-0 device Aug 31 17:56:28 backup1 kernel: da1: 381554MB (781422757 512 byte sectors: 255H 63S/T 48641C) Aug 31 17:56:28 backup1 kernel: SMP: AP CPU #1 Launched! Aug 31 17:56:28 backup1 kernel: Mounting root from ufs:/dev/da0s1d Aug 31 17:56:28 backup1 kernel: WARNING: / was not properly dismounted Aug 31 17:56:28 backup1 kernel: WARNING: R/W mount of / denied. Filesystem is not clean - run fsck [/dmesg] ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone (023) 8024 3137 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 31 17:42:26 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 E1D8F16A41F for ; Wed, 31 Aug 2005 17:42:25 +0000 (GMT) (envelope-from arundel@h3c.de) Received: from enterprise4.noxa.de (enterprise.noxa.de [212.60.197.71]) by mx1.FreeBSD.org (Postfix) with ESMTP id 09CB043D48 for ; Wed, 31 Aug 2005 17:42:24 +0000 (GMT) (envelope-from arundel@h3c.de) Received: (qmail 8274 invoked from network); 31 Aug 2005 19:42:21 +0200 Received: from p508fc26c.dip.t-dialin.net (HELO localhost.skatecity) (80.143.194.108) by enterprise.noxa.de with AES256-SHA encrypted SMTP; 31 Aug 2005 19:42:21 +0200 Received: from localhost.skatecity (nobody@localhost.skatecity [127.0.0.1]) by localhost.skatecity (8.13.4/8.13.4) with ESMTP id j7VHgJsb001657 for ; Wed, 31 Aug 2005 19:42:19 +0200 (CEST) (envelope-from arundel@localhost.skatecity) Received: (from arundel@localhost) by localhost.skatecity (8.13.4/8.13.4/Submit) id j7VHgJ97001656 for freebsd-hackers@freebsd.org; Wed, 31 Aug 2005 19:42:19 +0200 (CEST) (envelope-from arundel) From: Alexander Best Date: Wed, 31 Aug 2005 19:42:19 +0200 To: freebsd-hackers@freebsd.org Message-ID: <20050831174218.GA1522@skatecity> Mail-Followup-To: freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Organisation: =?iso-8859-15?Q?Westfl=E4lische_Wilhelms-U?= =?iso-8859-15?Q?niversit=E4t_M=FCnster?= Subject: Problem with ath(4) and Netgear WG311T card X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2005 17:42:26 -0000 I just bought myseld a new wlan card called Netgear WG311T (ath(4) lists it as being supported). Here's the ouput of `pciconf -lv`: ath0@pci0:10:0: class=0x020000 card=0x1a001385 chip=0x0013168c rev=0x01 \ hdr=0x00 vendor = 'Atheros Communications Inc.' device = 'AR5212, AR5213 802.11a/b/g Wireless Adapter' class = network subclass = ethernet When I try to load the ath(4) driver I get this error message: ath_hal: 0.9.14.9 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413) ath0: mem 0x84800000-0x8480ffff irq 15 at device 10.0 on pci0 ath0: unable to attach hardware; HAL status 3 device_attach: ath0 attach returned 6 I checked sys/contrib/dev/ath/ah.h as described in ath(4) and this is what I found: HAL_EIO = 3, /* Hardware didn't respond as expected */ I asked a guy in #madwifi and he pointed me to a website with a Q&A stating the following: Q: When I load the ath_pci module I get ?unable to attach hardware: Hardware didn?t respond as expected, (HAL status 3)?! A: There exist pci-bridges which have difficulties with Atheros cards (and other hardware possibly). To get your card working you first have to find your pci-bridges pci-id with ?lspci?. After then you have to set the SUBORDINATE_BUS option for this pci-id with the ?setpci? tool. For example: schleppi:~$ lspci | grep -i ?pci bridge? 0000:00:01.0 PCI bridge: Intel Corp. 82845 845 (Brookdale) Chipset AGP \ Bridge 0000:00:1e.0 PCI bridge: Intel Corp. 82801 PCI Bridge schleppi:~$ setpci -s 0:1e.0 SUBORDINATE_BUS=0A I have chosen PCI bridge, because my problem existed only for mini-pci Atheros card. If you have problems with your cardbus card instead, you would chose your PCI to Cardbus controller possibly. Another possibility is a badly installed pci card - try removing it, dusting of the contacts and putting it firmy back into the slot. Alright I believe this is my PCI bridge: hostb0@pci0:0:0: class=0x060000 card=0x80331043 chip=0x03051106 \ rev=0x02 hdr=0x00 vendor = 'VIA Technologies Inc' device = 'VT8363/5 KT133/KM133 System Controller' class = bridge subclass = HOST-PCI I searched through the linux kernel sources and found the following definition in include/linux/pci.h: define PCI_SUBORDINATE_BUS 0x1a /* Highest bus number behind the \ bridge */ So this is what I did to do what the Q&A proposes: pcitweak -w 00:00:0 -b 0x1A 0xA However the value doesn't seem to have any effect, because I still get the same error. And if I check the PCI mem offset I set beforehand it doesn't seem to have done anything: pcitweak -r 00:00:0 -b 0x1A 0x00 Can somebody help me with this problem? There seems to be a problem with revisions of the card that use a the Atheros AR5213 chip. But those cards have a different `pciconf` output and loading if_ath exits with code 13 which stands for a wrong revision. I'd really appreciate it if somebody could help me out. I already tried the ndis driver, but ndiscvt finds stumbles accross a syntax error in the *.inf file of the driver. Thx a bunch. From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 31 18:12:44 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 48EB516A41F for ; Wed, 31 Aug 2005 18:12:44 +0000 (GMT) (envelope-from fcash@ocis.net) Received: from smtp.sd73.bc.ca (smtp.sd73.bc.ca [142.24.13.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id E7FFE43D46 for ; Wed, 31 Aug 2005 18:12:43 +0000 (GMT) (envelope-from fcash@ocis.net) Received: from localhost (localhost [127.0.0.1]) by localhost.sd73.bc.ca (Postfix) with ESMTP id 8629C8A0172 for ; Wed, 31 Aug 2005 11:12:42 -0700 (PDT) Received: from smtp.sd73.bc.ca ([127.0.0.1]) by localhost (mailtest.sd73.bc.ca [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 01687-01-93 for ; Wed, 31 Aug 2005 11:12:38 -0700 (PDT) Received: from ember.sd73.bc.ca (unknown [192.168.0.9]) by smtp.sd73.bc.ca (Postfix) with ESMTP id EAA658A00EB for ; Wed, 31 Aug 2005 11:12:37 -0700 (PDT) From: Freddie Cash To: freebsd-hackers@freebsd.org Date: Wed, 31 Aug 2005 11:12:35 -0700 User-Agent: KMail/1.8.1 References: <20050831174218.GA1522@skatecity> In-Reply-To: <20050831174218.GA1522@skatecity> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200508311112.35863.fcash@ocis.net> X-Virus-Scanned: by amavisd-new using ClamAV at sd73.bc.ca Subject: Re: Problem with ath(4) and Netgear WG311T card X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2005 18:12:44 -0000 On August 31, 2005 10:42 am, Alexander Best wrote: > I just bought myseld a new wlan card called Netgear WG311T (ath(4) > lists it as being supported). Here's the ouput of `pciconf -lv`: Lots of great info follows, but you forgot the most important part: version of FreeBSD this is running on. :) There have been updates the the Atheros HAL between FreeBSD versions 5.3, 5.4, and 6.0. Each update supports more Atheros revisions. The last time I saw that message was when I purchased a new NetGEAR WG511T last August card and tried running it on FreeBSD 5.3. An update to 6-CURRENT shortly thereafter allowed it to work attach and work. -- Freddie Cash fcash@ocis.net From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 31 18:51:28 2005 Return-Path: X-Original-To: hackers@freebsd.org 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 1630716A41F; Wed, 31 Aug 2005 18:51:28 +0000 (GMT) (envelope-from myself@rojer.pp.ru) Received: from hermes.hw.ru (hermes.hw.ru [80.68.240.91]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4BCF343D53; Wed, 31 Aug 2005 18:51:24 +0000 (GMT) (envelope-from myself@rojer.pp.ru) Received: from [213.141.131.116] (account rojer@rbc.ru HELO [192.168.10.3]) by hermes.hw.ru (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 91512399; Wed, 31 Aug 2005 22:51:22 +0400 Message-ID: <4315FC27.3080703@rojer.pp.ru> Date: Wed, 31 Aug 2005 22:51:19 +0400 From: Rojer User-Agent: Thunderbird 1.0+ (X11/20050816) MIME-Version: 1.0 To: Ian Dowse References: <200508302009.aa99975@nowhere.iedowse.com> In-Reply-To: <200508302009.aa99975@nowhere.iedowse.com> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: hackers@freebsd.org, Eugene Grosbein , freebsd-usb@freebsd.org, "Eygene A. Ryabinkin" Subject: Re: Low umass performance with USB 2.0 ports X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2005 18:51:28 -0000 Ian Dowse wrote: > > The patch in from the email below may help with the wdrain state - > can you see if it makes any difference? > this solved the problem i had with umass devices on VIA controller. works fine, thanks a lot! the problem i hade is described in the followup to usb/81621 (http://www.freebsd.org/cgi/query-pr.cgi?pr=usb/81621) the original submitter seems to have VIA controller too. -- Deomid Ryabkov aka Rojer myself@rojer.pp.ru rojer@sysadmins.ru ICQ: 8025844 From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 31 19:21:43 2005 Return-Path: X-Original-To: hackers@freebsd.org 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 09C2916A41F; Wed, 31 Aug 2005 19:21:43 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7E7ED43D48; Wed, 31 Aug 2005 19:21:38 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.3/8.13.3) with ESMTP id j7VJZBtD008437; Wed, 31 Aug 2005 13:35:12 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <43160334.5000100@samsco.org> Date: Wed, 31 Aug 2005 13:21:24 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.8) Gecko/20050615 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ian Dowse References: <200508302009.aa99975@nowhere.iedowse.com> In-Reply-To: <200508302009.aa99975@nowhere.iedowse.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org Cc: hackers@freebsd.org, Eugene Grosbein , freebsd-usb@freebsd.org, "Eygene A. Ryabinkin" Subject: Re: Low umass performance with USB 2.0 ports X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2005 19:21:43 -0000 Ian Dowse wrote: > In message <20050830125031.GA775@rea.mbslab.kiae.ru>, "Eygene A. Ryabinkin" wri > tes: > >>>What is filesystem has your USB drive? >> >>The one I was extensively testing has FAT, but I've checked the UFS2 -- >>just a bit better -- 1.8 Mb/second. But you're right -- no wdrains at all. >> >>>FreeBSD 4.x had very low performance with FAT filesystem, >>>writing process spent lots of time in the wdrain state too. >> >>Yes, it has. But here the same flash drive gives different results for >>ehci and uhci devices, and the total speed of echi is lower due to wdrains: >>300 Kb/sec versus 500 Kb/sec. And I sometimes write my data to the Windows >>partition with FAT to my home HDD -- it has no wdrains. At least, I've not >>noticed them. For flash I can. > > > The patch in from the email below may help with the wdrain state - > can you see if it makes any difference? Is the problem that the interrupt gets fired but not all of the status information has made it's way back to host memory when the driver gets there? Would it make a difference to instead read back the EHCI_USBSTS register after writing to it in ehci_intr1? That way all transactions down to the controller would be guaranteed to be flushed before you continue on. I wonder if this is a remnant of the famous problems with VIA chipsets doing bad things under medium-to-high PCI contention. I don't see any obvious workarounds for this in the Linux EHCI code, so I wonder if it's a case of them not encountering it, or doing something different that avoids the problem. Scott From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 31 19:47:28 2005 Return-Path: X-Original-To: hackers@freebsd.org 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 D518416A41F; Wed, 31 Aug 2005 19:47:28 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 63F0643D48; Wed, 31 Aug 2005 19:47:28 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.3/8.13.3) with ESMTP id j7VK137k008601; Wed, 31 Aug 2005 14:01:03 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <43160943.6030400@samsco.org> Date: Wed, 31 Aug 2005 13:47:15 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.8) Gecko/20050615 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ian Dowse References: <200508302009.aa99975@nowhere.iedowse.com> <43160334.5000100@samsco.org> In-Reply-To: <43160334.5000100@samsco.org> Content-Type: multipart/mixed; boundary="------------080401070801020504080600" X-Spam-Status: No, score=-2.2 required=3.8 tests=ALL_TRUSTED,URIBL_SBL autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org Cc: hackers@freebsd.org, Eugene Grosbein , freebsd-usb@freebsd.org, "Eygene A. Ryabinkin" Subject: Re: Low umass performance with USB 2.0 ports X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2005 19:47:29 -0000 This is a multi-part message in MIME format. --------------080401070801020504080600 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Scott Long wrote: > Ian Dowse wrote: > >> In message <20050830125031.GA775@rea.mbslab.kiae.ru>, "Eygene A. >> Ryabinkin" wri >> tes: >> >>>> What is filesystem has your USB drive? >>> >>> >>> The one I was extensively testing has FAT, but I've checked the UFS2 -- >>> just a bit better -- 1.8 Mb/second. But you're right -- no wdrains at >>> all. >>> >>>> FreeBSD 4.x had very low performance with FAT filesystem, >>>> writing process spent lots of time in the wdrain state too. >>> >>> >>> Yes, it has. But here the same flash drive gives different results for >>> ehci and uhci devices, and the total speed of echi is lower due to >>> wdrains: >>> 300 Kb/sec versus 500 Kb/sec. And I sometimes write my data to the >>> Windows >>> partition with FAT to my home HDD -- it has no wdrains. At least, >>> I've not >>> noticed them. For flash I can. >> >> >> >> The patch in from the email below may help with the wdrain state - >> can you see if it makes any difference? > > > Is the problem that the interrupt gets fired but not all of the status > information has made it's way back to host memory when the driver gets > there? Would it make a difference to instead read back the EHCI_USBSTS > register after writing to it in ehci_intr1? That way all transactions > down to the controller would be guaranteed to be flushed before you > continue on. I wonder if this is a remnant of the famous problems with > VIA chipsets doing bad things under medium-to-high PCI contention. I > don't see any obvious workarounds for this in the Linux EHCI code, so > I wonder if it's a case of them not encountering it, or doing something > different that avoids the problem. > > Scott Actually, I just peeked inside the Linux EHCI code and it does a dummy read immediately after writing to the status register: /* clear (just) interrupts */ writel (status, &ehci->regs->status); readl (&ehci->regs->command); /* unblock posted write */ I wonder if that's the whole trick here. Would someone be willing to try the attached patch instead of the one that Ian posted? Scott --------------080401070801020504080600 Content-Type: text/plain; name="ehci-flush.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ehci-flush.diff" Index: ehci.c =================================================================== RCS file: /usr/ncvs/src/sys/dev/usb/ehci.c,v retrieving revision 1.36 diff -u -r1.36 ehci.c --- ehci.c 29 May 2005 04:42:27 -0000 1.36 +++ ehci.c 31 Aug 2005 19:44:14 -0000 @@ -578,6 +578,7 @@ return (0); EOWRITE4(sc, EHCI_USBSTS, intrs); /* Acknowledge */ + EOREAD4(sc, EHCI_USBCMD); /* Flush posted writes on PCI */ sc->sc_bus.intr_context++; sc->sc_bus.no_intrs++; if (eintrs & EHCI_STS_IAA) { --------------080401070801020504080600-- From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 31 20:38:10 2005 Return-Path: X-Original-To: hackers@freebsd.org 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 5120416A41F; Wed, 31 Aug 2005 20:38:10 +0000 (GMT) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe14.tele2.se [212.247.155.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5D0F843D48; Wed, 31 Aug 2005 20:38:08 +0000 (GMT) (envelope-from hselasky@c2i.net) X-T2-Posting-ID: Y1QAsIk9O44SO+J/q9KNyQ== Received: from mp-216-86-119.daxnet.no ([193.216.86.119] verified) by mailfe14.swip.net (CommuniGate Pro SMTP 4.3.4) with ESMTP id 13934797; Wed, 31 Aug 2005 22:38:06 +0200 From: Hans Petter Selasky To: freebsd-hackers@freebsd.org Date: Wed, 31 Aug 2005 22:39:02 +0200 User-Agent: KMail/1.7 References: <200508302009.aa99975@nowhere.iedowse.com> <43160334.5000100@samsco.org> <43160943.6030400@samsco.org> In-Reply-To: <43160943.6030400@samsco.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200508312239.04897.hselasky@c2i.net> Cc: Scott Long , Ian Dowse , hackers@freebsd.org, Eugene Grosbein , freebsd-usb@freebsd.org, "Eygene A. Ryabinkin" Subject: Re: Low umass performance with USB 2.0 ports X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hselasky@c2i.net List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2005 20:38:10 -0000 On Wednesday 31 August 2005 21:47, Scott Long wrote: > Scott Long wrote: > > Ian Dowse wrote: > >> In message <20050830125031.GA775@rea.mbslab.kiae.ru>, "Eygene A. > >> Ryabinkin" wri > >> > >> tes: > >>>> What is filesystem has your USB drive? > >>> > >>> The one I was extensively testing has FAT, but I've checked the UFS2 -- > >>> just a bit better -- 1.8 Mb/second. But you're right -- no wdrains at > >>> all. > >>> > >>>> FreeBSD 4.x had very low performance with FAT filesystem, > >>>> writing process spent lots of time in the wdrain state too. > >>> > >>> Yes, it has. But here the same flash drive gives different results for > >>> ehci and uhci devices, and the total speed of echi is lower due to > >>> wdrains: > >>> 300 Kb/sec versus 500 Kb/sec. And I sometimes write my data to the > >>> Windows > >>> partition with FAT to my home HDD -- it has no wdrains. At least, > >>> I've not > >>> noticed them. For flash I can. > >> > >> The patch in from the email below may help with the wdrain state - > >> can you see if it makes any difference? > > > > Is the problem that the interrupt gets fired but not all of the status > > information has made it's way back to host memory when the driver gets > > there? Would it make a difference to instead read back the EHCI_USBSTS > > register after writing to it in ehci_intr1? That way all transactions > > down to the controller would be guaranteed to be flushed before you > > continue on. I wonder if this is a remnant of the famous problems with > > VIA chipsets doing bad things under medium-to-high PCI contention. I > > don't see any obvious workarounds for this in the Linux EHCI code, so > > I wonder if it's a case of them not encountering it, or doing something > > different that avoids the problem. > > > > Scott > > Actually, I just peeked inside the Linux EHCI code and it does a dummy > read immediately after writing to the status register: > > /* clear (just) interrupts */ > writel (status, &ehci->regs->status); > readl (&ehci->regs->command); /* unblock posted write */ > > I wonder if that's the whole trick here. Would someone be willing to > try the attached patch instead of the one that Ian posted? > > Scott This is not documented in the EHCI chip specification. There exists the doorbell to ensure that the EHCI controller is finished with data structures. Also I have noticed that the existing EHCI driver does not always dequeue structures from the controller before accessing them. If Scott's patch doesn't work, could you have tried to install the following (compiles on FreeBSD 5/6/7): Download the three files below into a new directory and type "make install" (to uninstall type "make deinstall") http://home.c2i.net/hselasky/isdn4bsd/privat/usb/Makefile http://home.c2i.net/hselasky/isdn4bsd/privat/usb/new_usb_1_5_4.diff.bz2 http://home.c2i.net/hselasky/isdn4bsd/privat/usb/new_usb_1_5_4.tar.bz2 Then recompile all USB modules and/or kernel, depending on your configuration. Here is a quick USB-module compile script: #!/bin/sh cd /sys/modules/aue && make depend all install clean cd /sys/modules/axe && make depend all install clean cd /sys/modules/cdce && make depend all install clean cd /sys/modules/cue && make depend all install clean cd /sys/modules/if_ndis && make depend all install clean cd /sys/modules/kue && make depend all install clean cd /sys/modules/ndis && make depend all install clean cd /sys/modules/netgraph/bluetooth/ubtbcmfw && make depend all install clean cd /sys/modules/netgraph/bluetooth/ubt && make depend all install clean cd /sys/modules/rue && make depend all install clean cd /sys/modules/sound/driver/uaudio && make depend all install clean cd /sys/modules/ubsa && make depend all install clean cd /sys/modules/ubser && make depend all install clean cd /sys/modules/ucom && make depend all install clean cd /sys/modules/ucycom && make depend all install clean cd /sys/modules/udav && make depend all install clean cd /sys/modules/udbp && make depend all install clean cd /sys/modules/ufm && make depend all install clean cd /sys/modules/uftdi && make depend all install clean cd /sys/modules/ugen && make depend all install clean cd /sys/modules/uhid && make depend all install clean cd /sys/modules/ukbd && make depend all install clean cd /sys/modules/ulpt && make depend all install clean cd /sys/modules/umass && make depend all install clean cd /sys/modules/umct && make depend all install clean cd /sys/modules/umodem && make depend all install clean cd /sys/modules/ums && make depend all install clean cd /sys/modules/uplcom && make depend all install clean cd /sys/modules/ural && make depend all install clean cd /sys/modules/urio && make depend all install clean cd /sys/modules/usb && make depend all install clean cd /sys/modules/uscanner && make depend all install clean cd /sys/modules/uvisor && make depend all install clean cd /sys/modules/uvscom && make depend all install clean --HPS From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 31 20:38:10 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 5120416A41F; Wed, 31 Aug 2005 20:38:10 +0000 (GMT) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe14.tele2.se [212.247.155.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5D0F843D48; Wed, 31 Aug 2005 20:38:08 +0000 (GMT) (envelope-from hselasky@c2i.net) X-T2-Posting-ID: Y1QAsIk9O44SO+J/q9KNyQ== Received: from mp-216-86-119.daxnet.no ([193.216.86.119] verified) by mailfe14.swip.net (CommuniGate Pro SMTP 4.3.4) with ESMTP id 13934797; Wed, 31 Aug 2005 22:38:06 +0200 From: Hans Petter Selasky To: freebsd-hackers@freebsd.org Date: Wed, 31 Aug 2005 22:39:02 +0200 User-Agent: KMail/1.7 References: <200508302009.aa99975@nowhere.iedowse.com> <43160334.5000100@samsco.org> <43160943.6030400@samsco.org> In-Reply-To: <43160943.6030400@samsco.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200508312239.04897.hselasky@c2i.net> Cc: Scott Long , Ian Dowse , hackers@freebsd.org, Eugene Grosbein , freebsd-usb@freebsd.org, "Eygene A. Ryabinkin" Subject: Re: Low umass performance with USB 2.0 ports X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hselasky@c2i.net List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2005 20:38:10 -0000 On Wednesday 31 August 2005 21:47, Scott Long wrote: > Scott Long wrote: > > Ian Dowse wrote: > >> In message <20050830125031.GA775@rea.mbslab.kiae.ru>, "Eygene A. > >> Ryabinkin" wri > >> > >> tes: > >>>> What is filesystem has your USB drive? > >>> > >>> The one I was extensively testing has FAT, but I've checked the UFS2 -- > >>> just a bit better -- 1.8 Mb/second. But you're right -- no wdrains at > >>> all. > >>> > >>>> FreeBSD 4.x had very low performance with FAT filesystem, > >>>> writing process spent lots of time in the wdrain state too. > >>> > >>> Yes, it has. But here the same flash drive gives different results for > >>> ehci and uhci devices, and the total speed of echi is lower due to > >>> wdrains: > >>> 300 Kb/sec versus 500 Kb/sec. And I sometimes write my data to the > >>> Windows > >>> partition with FAT to my home HDD -- it has no wdrains. At least, > >>> I've not > >>> noticed them. For flash I can. > >> > >> The patch in from the email below may help with the wdrain state - > >> can you see if it makes any difference? > > > > Is the problem that the interrupt gets fired but not all of the status > > information has made it's way back to host memory when the driver gets > > there? Would it make a difference to instead read back the EHCI_USBSTS > > register after writing to it in ehci_intr1? That way all transactions > > down to the controller would be guaranteed to be flushed before you > > continue on. I wonder if this is a remnant of the famous problems with > > VIA chipsets doing bad things under medium-to-high PCI contention. I > > don't see any obvious workarounds for this in the Linux EHCI code, so > > I wonder if it's a case of them not encountering it, or doing something > > different that avoids the problem. > > > > Scott > > Actually, I just peeked inside the Linux EHCI code and it does a dummy > read immediately after writing to the status register: > > /* clear (just) interrupts */ > writel (status, &ehci->regs->status); > readl (&ehci->regs->command); /* unblock posted write */ > > I wonder if that's the whole trick here. Would someone be willing to > try the attached patch instead of the one that Ian posted? > > Scott This is not documented in the EHCI chip specification. There exists the doorbell to ensure that the EHCI controller is finished with data structures. Also I have noticed that the existing EHCI driver does not always dequeue structures from the controller before accessing them. If Scott's patch doesn't work, could you have tried to install the following (compiles on FreeBSD 5/6/7): Download the three files below into a new directory and type "make install" (to uninstall type "make deinstall") http://home.c2i.net/hselasky/isdn4bsd/privat/usb/Makefile http://home.c2i.net/hselasky/isdn4bsd/privat/usb/new_usb_1_5_4.diff.bz2 http://home.c2i.net/hselasky/isdn4bsd/privat/usb/new_usb_1_5_4.tar.bz2 Then recompile all USB modules and/or kernel, depending on your configuration. Here is a quick USB-module compile script: #!/bin/sh cd /sys/modules/aue && make depend all install clean cd /sys/modules/axe && make depend all install clean cd /sys/modules/cdce && make depend all install clean cd /sys/modules/cue && make depend all install clean cd /sys/modules/if_ndis && make depend all install clean cd /sys/modules/kue && make depend all install clean cd /sys/modules/ndis && make depend all install clean cd /sys/modules/netgraph/bluetooth/ubtbcmfw && make depend all install clean cd /sys/modules/netgraph/bluetooth/ubt && make depend all install clean cd /sys/modules/rue && make depend all install clean cd /sys/modules/sound/driver/uaudio && make depend all install clean cd /sys/modules/ubsa && make depend all install clean cd /sys/modules/ubser && make depend all install clean cd /sys/modules/ucom && make depend all install clean cd /sys/modules/ucycom && make depend all install clean cd /sys/modules/udav && make depend all install clean cd /sys/modules/udbp && make depend all install clean cd /sys/modules/ufm && make depend all install clean cd /sys/modules/uftdi && make depend all install clean cd /sys/modules/ugen && make depend all install clean cd /sys/modules/uhid && make depend all install clean cd /sys/modules/ukbd && make depend all install clean cd /sys/modules/ulpt && make depend all install clean cd /sys/modules/umass && make depend all install clean cd /sys/modules/umct && make depend all install clean cd /sys/modules/umodem && make depend all install clean cd /sys/modules/ums && make depend all install clean cd /sys/modules/uplcom && make depend all install clean cd /sys/modules/ural && make depend all install clean cd /sys/modules/urio && make depend all install clean cd /sys/modules/usb && make depend all install clean cd /sys/modules/uscanner && make depend all install clean cd /sys/modules/uvisor && make depend all install clean cd /sys/modules/uvscom && make depend all install clean --HPS From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 31 21:17:16 2005 Return-Path: X-Original-To: hackers@freebsd.org 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 3154F16A41F; Wed, 31 Aug 2005 21:17:16 +0000 (GMT) (envelope-from myself@rojer.pp.ru) Received: from hermes.hw.ru (hermes.hw.ru [80.68.240.91]) by mx1.FreeBSD.org (Postfix) with ESMTP id 023CF43D46; Wed, 31 Aug 2005 21:17:13 +0000 (GMT) (envelope-from myself@rojer.pp.ru) Received: from [213.141.131.116] (account rojer@rbc.ru HELO [192.168.10.3]) by hermes.hw.ru (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 91524523; Thu, 01 Sep 2005 01:17:11 +0400 Message-ID: <43161E54.5050705@rojer.pp.ru> Date: Thu, 01 Sep 2005 01:17:08 +0400 From: Rojer User-Agent: Thunderbird 1.0+ (X11/20050816) MIME-Version: 1.0 To: Scott Long References: <200508302009.aa99975@nowhere.iedowse.com> <43160334.5000100@samsco.org> <43160943.6030400@samsco.org> In-Reply-To: <43160943.6030400@samsco.org> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: Ian Dowse , hackers@freebsd.org, Eugene Grosbein , freebsd-usb@freebsd.org, "Eygene A. Ryabinkin" Subject: Re: Low umass performance with USB 2.0 ports X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2005 21:17:16 -0000 Scott Long wrote: > > I wonder if that's the whole trick here. Would someone be willing to > try the attached patch instead of the one that Ian posted? > just tried the patch... no, it doesn't help. stalls still happen when reading large files from the device. -- Deomid Ryabkov aka Rojer myself@rojer.pp.ru rojer@sysadmins.ru ICQ: 8025844 From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 31 21:21:23 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 DAF4F16A41F; Wed, 31 Aug 2005 21:21:23 +0000 (GMT) (envelope-from myself@rojer.pp.ru) Received: from hermes.hw.ru (hermes.hw.ru [80.68.240.91]) by mx1.FreeBSD.org (Postfix) with ESMTP id D1E9243D46; Wed, 31 Aug 2005 21:21:22 +0000 (GMT) (envelope-from myself@rojer.pp.ru) Received: from [213.141.131.116] (account rojer@rbc.ru HELO [192.168.10.3]) by hermes.hw.ru (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 91524791; Thu, 01 Sep 2005 01:21:21 +0400 Message-ID: <43161F4E.8000101@rojer.pp.ru> Date: Thu, 01 Sep 2005 01:21:18 +0400 From: Rojer User-Agent: Thunderbird 1.0+ (X11/20050816) MIME-Version: 1.0 To: hselasky@c2i.net References: <200508302009.aa99975@nowhere.iedowse.com> <43160334.5000100@samsco.org> <43160943.6030400@samsco.org> <200508312239.04897.hselasky@c2i.net> In-Reply-To: <200508312239.04897.hselasky@c2i.net> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: Scott Long , freebsd-hackers@freebsd.org, Ian Dowse , hackers@freebsd.org, Eugene Grosbein , freebsd-usb@freebsd.org, "Eygene A. Ryabinkin" Subject: Re: Low umass performance with USB 2.0 ports X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2005 21:21:24 -0000 Hans Petter Selasky wrote: > If Scott's patch doesn't work, could you have tried to install the following > (compiles on FreeBSD 5/6/7): > > Download the three files below into a new directory and type > "make install" (to uninstall type "make deinstall") > http://home.c2i.net/hselasky/isdn4bsd/privat/usb/Makefile > http://home.c2i.net/hselasky/isdn4bsd/privat/usb/new_usb_1_5_4.diff.bz2 > http://home.c2i.net/hselasky/isdn4bsd/privat/usb/new_usb_1_5_4.tar.bz2 > > Then recompile all USB modules and/or kernel, depending on your configuration. doesn't apply to freshly cvsupped RELENG_6: [skip] x sys/dev/usb2/usb_quirks.h x sys/dev/usb2/usb_subr.h (bzcat new_usb_1_5_4.diff.bz2 | patch -N -l -d /usr/src) || echo -n Hmm... Looks like a new-style context diff to me... The text leading up to this was: -------------------------- |*** sys/i386/include/bus_at386.h.ref Wed Oct 20 21:32:58 2004 |--- sys/i386/include/bus_at386.h Sat Nov 11 11:11:00 2000 -------------------------- File to patch: ^C -- Deomid Ryabkov aka Rojer myself@rojer.pp.ru rojer@sysadmins.ru ICQ: 8025844 From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 31 21:21:24 2005 Return-Path: X-Original-To: hackers@freebsd.org 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 DAF4F16A41F; Wed, 31 Aug 2005 21:21:23 +0000 (GMT) (envelope-from myself@rojer.pp.ru) Received: from hermes.hw.ru (hermes.hw.ru [80.68.240.91]) by mx1.FreeBSD.org (Postfix) with ESMTP id D1E9243D46; Wed, 31 Aug 2005 21:21:22 +0000 (GMT) (envelope-from myself@rojer.pp.ru) Received: from [213.141.131.116] (account rojer@rbc.ru HELO [192.168.10.3]) by hermes.hw.ru (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 91524791; Thu, 01 Sep 2005 01:21:21 +0400 Message-ID: <43161F4E.8000101@rojer.pp.ru> Date: Thu, 01 Sep 2005 01:21:18 +0400 From: Rojer User-Agent: Thunderbird 1.0+ (X11/20050816) MIME-Version: 1.0 To: hselasky@c2i.net References: <200508302009.aa99975@nowhere.iedowse.com> <43160334.5000100@samsco.org> <43160943.6030400@samsco.org> <200508312239.04897.hselasky@c2i.net> In-Reply-To: <200508312239.04897.hselasky@c2i.net> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: Scott Long , freebsd-hackers@freebsd.org, Ian Dowse , hackers@freebsd.org, Eugene Grosbein , freebsd-usb@freebsd.org, "Eygene A. Ryabinkin" Subject: Re: Low umass performance with USB 2.0 ports X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2005 21:21:24 -0000 Hans Petter Selasky wrote: > If Scott's patch doesn't work, could you have tried to install the following > (compiles on FreeBSD 5/6/7): > > Download the three files below into a new directory and type > "make install" (to uninstall type "make deinstall") > http://home.c2i.net/hselasky/isdn4bsd/privat/usb/Makefile > http://home.c2i.net/hselasky/isdn4bsd/privat/usb/new_usb_1_5_4.diff.bz2 > http://home.c2i.net/hselasky/isdn4bsd/privat/usb/new_usb_1_5_4.tar.bz2 > > Then recompile all USB modules and/or kernel, depending on your configuration. doesn't apply to freshly cvsupped RELENG_6: [skip] x sys/dev/usb2/usb_quirks.h x sys/dev/usb2/usb_subr.h (bzcat new_usb_1_5_4.diff.bz2 | patch -N -l -d /usr/src) || echo -n Hmm... Looks like a new-style context diff to me... The text leading up to this was: -------------------------- |*** sys/i386/include/bus_at386.h.ref Wed Oct 20 21:32:58 2004 |--- sys/i386/include/bus_at386.h Sat Nov 11 11:11:00 2000 -------------------------- File to patch: ^C -- Deomid Ryabkov aka Rojer myself@rojer.pp.ru rojer@sysadmins.ru ICQ: 8025844 From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 31 21:21:41 2005 Return-Path: X-Original-To: hackers@freebsd.org 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 5EBD116A41F; Wed, 31 Aug 2005 21:21:41 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id DBBAB43D49; Wed, 31 Aug 2005 21:21:38 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.14] (imini.samsco.home [192.168.254.14]) (authenticated bits=0) by pooker.samsco.org (8.13.3/8.13.3) with ESMTP id j7VLZDes009172; Wed, 31 Aug 2005 15:35:13 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <43161F60.8010408@samsco.org> Date: Wed, 31 Aug 2005 15:21:36 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.7) Gecko/20050416 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hselasky@c2i.net References: <200508302009.aa99975@nowhere.iedowse.com> <43160334.5000100@samsco.org> <43160943.6030400@samsco.org> <200508312239.04897.hselasky@c2i.net> In-Reply-To: <200508312239.04897.hselasky@c2i.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.2 required=3.8 tests=ALL_TRUSTED,URIBL_SBL autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org Cc: Ian Dowse , freebsd-hackers@freebsd.org, hackers@freebsd.org, Eugene Grosbein , freebsd-usb@freebsd.org, "Eygene A. Ryabinkin" Subject: Re: Low umass performance with USB 2.0 ports X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2005 21:21:41 -0000 Hans Petter Selasky wrote: > On Wednesday 31 August 2005 21:47, Scott Long wrote: > >>Scott Long wrote: >> >>>Ian Dowse wrote: >>> >>>>In message <20050830125031.GA775@rea.mbslab.kiae.ru>, "Eygene A. >>>>Ryabinkin" wri >>>> >>>>tes: >>>> >>>>>>What is filesystem has your USB drive? >>>>> >>>>>The one I was extensively testing has FAT, but I've checked the UFS2 -- >>>>>just a bit better -- 1.8 Mb/second. But you're right -- no wdrains at >>>>>all. >>>>> >>>>> >>>>>>FreeBSD 4.x had very low performance with FAT filesystem, >>>>>>writing process spent lots of time in the wdrain state too. >>>>> >>>>>Yes, it has. But here the same flash drive gives different results for >>>>>ehci and uhci devices, and the total speed of echi is lower due to >>>>>wdrains: >>>>>300 Kb/sec versus 500 Kb/sec. And I sometimes write my data to the >>>>>Windows >>>>>partition with FAT to my home HDD -- it has no wdrains. At least, >>>>>I've not >>>>>noticed them. For flash I can. >>>> >>>>The patch in from the email below may help with the wdrain state - >>>>can you see if it makes any difference? >>> >>>Is the problem that the interrupt gets fired but not all of the status >>>information has made it's way back to host memory when the driver gets >>>there? Would it make a difference to instead read back the EHCI_USBSTS >>>register after writing to it in ehci_intr1? That way all transactions >>>down to the controller would be guaranteed to be flushed before you >>>continue on. I wonder if this is a remnant of the famous problems with >>>VIA chipsets doing bad things under medium-to-high PCI contention. I >>>don't see any obvious workarounds for this in the Linux EHCI code, so >>>I wonder if it's a case of them not encountering it, or doing something >>>different that avoids the problem. >>> >>>Scott >> >>Actually, I just peeked inside the Linux EHCI code and it does a dummy >>read immediately after writing to the status register: >> >> /* clear (just) interrupts */ >> writel (status, &ehci->regs->status); >> readl (&ehci->regs->command); /* unblock posted write */ >> >>I wonder if that's the whole trick here. Would someone be willing to >>try the attached patch instead of the one that Ian posted? >> >>Scott > > > This is not documented in the EHCI chip specification. Flushing posted writes is something that all programmers of PCI devices should understand, so it usually isn't documented in device manuals. > There exists the > doorbell to ensure that the EHCI controller is finished with data structures. > Also I have noticed that the existing EHCI driver does not always dequeue > structures from the controller before accessing them. > Can you point to an example here? > If Scott's patch doesn't work, could you have tried to install the following > (compiles on FreeBSD 5/6/7): > Yeah, looks like my guess was wrong. Scott From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 31 21:21:41 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 5EBD116A41F; Wed, 31 Aug 2005 21:21:41 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id DBBAB43D49; Wed, 31 Aug 2005 21:21:38 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.14] (imini.samsco.home [192.168.254.14]) (authenticated bits=0) by pooker.samsco.org (8.13.3/8.13.3) with ESMTP id j7VLZDes009172; Wed, 31 Aug 2005 15:35:13 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <43161F60.8010408@samsco.org> Date: Wed, 31 Aug 2005 15:21:36 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.7) Gecko/20050416 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hselasky@c2i.net References: <200508302009.aa99975@nowhere.iedowse.com> <43160334.5000100@samsco.org> <43160943.6030400@samsco.org> <200508312239.04897.hselasky@c2i.net> In-Reply-To: <200508312239.04897.hselasky@c2i.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.2 required=3.8 tests=ALL_TRUSTED,URIBL_SBL autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org Cc: Ian Dowse , freebsd-hackers@freebsd.org, hackers@freebsd.org, Eugene Grosbein , freebsd-usb@freebsd.org, "Eygene A. Ryabinkin" Subject: Re: Low umass performance with USB 2.0 ports X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2005 21:21:41 -0000 Hans Petter Selasky wrote: > On Wednesday 31 August 2005 21:47, Scott Long wrote: > >>Scott Long wrote: >> >>>Ian Dowse wrote: >>> >>>>In message <20050830125031.GA775@rea.mbslab.kiae.ru>, "Eygene A. >>>>Ryabinkin" wri >>>> >>>>tes: >>>> >>>>>>What is filesystem has your USB drive? >>>>> >>>>>The one I was extensively testing has FAT, but I've checked the UFS2 -- >>>>>just a bit better -- 1.8 Mb/second. But you're right -- no wdrains at >>>>>all. >>>>> >>>>> >>>>>>FreeBSD 4.x had very low performance with FAT filesystem, >>>>>>writing process spent lots of time in the wdrain state too. >>>>> >>>>>Yes, it has. But here the same flash drive gives different results for >>>>>ehci and uhci devices, and the total speed of echi is lower due to >>>>>wdrains: >>>>>300 Kb/sec versus 500 Kb/sec. And I sometimes write my data to the >>>>>Windows >>>>>partition with FAT to my home HDD -- it has no wdrains. At least, >>>>>I've not >>>>>noticed them. For flash I can. >>>> >>>>The patch in from the email below may help with the wdrain state - >>>>can you see if it makes any difference? >>> >>>Is the problem that the interrupt gets fired but not all of the status >>>information has made it's way back to host memory when the driver gets >>>there? Would it make a difference to instead read back the EHCI_USBSTS >>>register after writing to it in ehci_intr1? That way all transactions >>>down to the controller would be guaranteed to be flushed before you >>>continue on. I wonder if this is a remnant of the famous problems with >>>VIA chipsets doing bad things under medium-to-high PCI contention. I >>>don't see any obvious workarounds for this in the Linux EHCI code, so >>>I wonder if it's a case of them not encountering it, or doing something >>>different that avoids the problem. >>> >>>Scott >> >>Actually, I just peeked inside the Linux EHCI code and it does a dummy >>read immediately after writing to the status register: >> >> /* clear (just) interrupts */ >> writel (status, &ehci->regs->status); >> readl (&ehci->regs->command); /* unblock posted write */ >> >>I wonder if that's the whole trick here. Would someone be willing to >>try the attached patch instead of the one that Ian posted? >> >>Scott > > > This is not documented in the EHCI chip specification. Flushing posted writes is something that all programmers of PCI devices should understand, so it usually isn't documented in device manuals. > There exists the > doorbell to ensure that the EHCI controller is finished with data structures. > Also I have noticed that the existing EHCI driver does not always dequeue > structures from the controller before accessing them. > Can you point to an example here? > If Scott's patch doesn't work, could you have tried to install the following > (compiles on FreeBSD 5/6/7): > Yeah, looks like my guess was wrong. Scott From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 31 22:37:06 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 E93E216A41F; Wed, 31 Aug 2005 22:37:06 +0000 (GMT) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe04.swip.net [212.247.154.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id 11D8443D45; Wed, 31 Aug 2005 22:37:05 +0000 (GMT) (envelope-from hselasky@c2i.net) X-T2-Posting-ID: Y1QAsIk9O44SO+J/q9KNyQ== Received: from mp-216-87-18.daxnet.no ([193.216.87.18] verified) by mailfe04.swip.net (CommuniGate Pro SMTP 4.3.4) with ESMTP id 449687991; Thu, 01 Sep 2005 00:37:04 +0200 From: Hans Petter Selasky To: freebsd-hackers@freebsd.org Date: Thu, 1 Sep 2005 00:38:00 +0200 User-Agent: KMail/1.7 References: <200508302009.aa99975@nowhere.iedowse.com> <200508312239.04897.hselasky@c2i.net> <43161F4E.8000101@rojer.pp.ru> In-Reply-To: <43161F4E.8000101@rojer.pp.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200509010038.02519.hselasky@c2i.net> Cc: Scott Long , Ian Dowse , Eugene Grosbein , freebsd-usb@freebsd.org, "Eygene A. Ryabinkin" , Rojer Subject: Re: Low umass performance with USB 2.0 ports X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hselasky@c2i.net List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2005 22:37:07 -0000 On Wednesday 31 August 2005 23:21, Rojer wrote: > Hans Petter Selasky wrote: > > If Scott's patch doesn't work, could you have tried to install the > > following (compiles on FreeBSD 5/6/7): > > > > Download the three files below into a new directory and type > > "make install" (to uninstall type "make deinstall") > > http://home.c2i.net/hselasky/isdn4bsd/privat/usb/Makefile > > http://home.c2i.net/hselasky/isdn4bsd/privat/usb/new_usb_1_5_4.diff.bz2 > > http://home.c2i.net/hselasky/isdn4bsd/privat/usb/new_usb_1_5_4.tar.bz2 > > > > Then recompile all USB modules and/or kernel, depending on your > > configuration. > > doesn't apply to freshly cvsupped RELENG_6: Just ignore those failing patches. The driver will compile regardless of that. > > [skip] > x sys/dev/usb2/usb_quirks.h > x sys/dev/usb2/usb_subr.h > (bzcat new_usb_1_5_4.diff.bz2 | patch -N -l -d /usr/src) || echo -n > Hmm... Looks like a new-style context diff to me... > The text leading up to this was: > -------------------------- > > |*** sys/i386/include/bus_at386.h.ref Wed Oct 20 21:32:58 2004 > |--- sys/i386/include/bus_at386.h Sat Nov 11 11:11:00 2000 > > -------------------------- > File to patch: ^C --HPS From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 31 22:53:11 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 A184A16A41F; Wed, 31 Aug 2005 22:53:11 +0000 (GMT) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe14.swipnet.se [212.247.155.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id E459143D45; Wed, 31 Aug 2005 22:53:10 +0000 (GMT) (envelope-from hselasky@c2i.net) X-T2-Posting-ID: Y1QAsIk9O44SO+J/q9KNyQ== Received: from mp-217-132-64.daxnet.no ([193.217.132.64] verified) by mailfe14.swip.net (CommuniGate Pro SMTP 4.3.4) with ESMTP id 13974270; Thu, 01 Sep 2005 00:53:09 +0200 From: Hans Petter Selasky To: freebsd-hackers@freebsd.org Date: Thu, 1 Sep 2005 00:54:01 +0200 User-Agent: KMail/1.7 References: <200508302009.aa99975@nowhere.iedowse.com> <200508312239.04897.hselasky@c2i.net> <43161F60.8010408@samsco.org> In-Reply-To: <43161F60.8010408@samsco.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200509010054.02793.hselasky@c2i.net> Cc: Scott Long , Eugene Grosbein , Ian Dowse , freebsd-usb@freebsd.org, "Eygene A. Ryabinkin" Subject: Re: Low umass performance with USB 2.0 ports X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hselasky@c2i.net List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2005 22:53:11 -0000 On Wednesday 31 August 2005 23:21, Scott Long wrote: > >> > >>Actually, I just peeked inside the Linux EHCI code and it does a dummy > >>read immediately after writing to the status register: > >> > >> /* clear (just) interrupts */ > >> writel (status, &ehci->regs->status); > >> readl (&ehci->regs->command); /* unblock posted write */ > >> > >>I wonder if that's the whole trick here. Would someone be willing to > >>try the attached patch instead of the one that Ian posted? > >> > >>Scott > > > > This is not documented in the EHCI chip specification. > > Flushing posted writes is something that all programmers of PCI devices > should understand, so it usually isn't documented in device manuals. > > > There exists the > > doorbell to ensure that the EHCI controller is finished with data > > structures. Also I have noticed that the existing EHCI driver does not > > always dequeue structures from the controller before accessing them. > > Can you point to an example here? In the official USB system, when an endpoint is opened, a QH structure is allocated and inserted into the USB controller's schedule. After that the EHCI driver will just write new values to that structure, while it is still scheduled. In my opinion you should unqueue this structure and wait for doorbell, before touching it. > > > If Scott's patch doesn't work, could you have tried to install the > > following (compiles on FreeBSD 5/6/7): > > Yeah, looks like my guess was wrong. > > Scott --HPS From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 31 23:06:24 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 C31EB16A41F for ; Wed, 31 Aug 2005 23:06:24 +0000 (GMT) (envelope-from arundel@h3c.de) Received: from enterprise4.noxa.de (enterprise.noxa.de [212.60.197.71]) by mx1.FreeBSD.org (Postfix) with ESMTP id E88C843D45 for ; Wed, 31 Aug 2005 23:06:23 +0000 (GMT) (envelope-from arundel@h3c.de) Received: (qmail 3834 invoked from network); 1 Sep 2005 01:06:22 +0200 Received: from p508fed1c.dip.t-dialin.net (HELO localhost.skatecity) (80.143.237.28) by enterprise.noxa.de with AES256-SHA encrypted SMTP; 1 Sep 2005 01:06:22 +0200 Received: from localhost.skatecity (nobody@localhost.skatecity [127.0.0.1]) by localhost.skatecity (8.13.4/8.13.4) with ESMTP id j7VN6LJl001034 for ; Thu, 1 Sep 2005 01:06:21 +0200 (CEST) (envelope-from arundel@localhost.skatecity) Received: (from arundel@localhost) by localhost.skatecity (8.13.4/8.13.4/Submit) id j7VN6K5q001033 for freebsd-hackers@freebsd.org; Thu, 1 Sep 2005 01:06:20 +0200 (CEST) (envelope-from arundel) From: Alexander Best Date: Thu, 1 Sep 2005 01:06:20 +0200 To: freebsd-hackers@freebsd.org Message-ID: <20050831230620.GA766@skatecity> Mail-Followup-To: freebsd-hackers@freebsd.org References: <20050831174218.GA1522@skatecity> <200508311112.35863.fcash@ocis.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200508311112.35863.fcash@ocis.net> User-Agent: Mutt/1.4.2.1i Organisation: =?iso-8859-15?Q?Westfl=E4lische_Wilhelms-U?= =?iso-8859-15?Q?niversit=E4t_M=FCnster?= Subject: Re: Problem with ath(4) and Netgear WG311T card X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2005 23:06:24 -0000 On Wed Aug 31 05, Freddie Cash wrote: > > Lots of great info follows, but you forgot the most important part: > version of FreeBSD this is running on. :) There have been updates the > the Atheros HAL between FreeBSD versions 5.3, 5.4, and 6.0. Each > update supports more Atheros revisions. > > The last time I saw that message was when I purchased a new NetGEAR > WG511T last August card and tried running it on FreeBSD 5.3. An update > to 6-CURRENT shortly thereafter allowed it to work attach and work. > > -- > Freddie Cash > fcash@ocis.net Thanks for you help, but I solved the problem. I checked the card, because the Q&A says that I should also try claning the card and the PCI slots. I had a look at the PCI card PINS and one looked very funny. I exchanged the card and now it works fine: ath0: mem 0xc4800000-0xc480ffff irq 15 at device 10.0 on pci0 ath0: Ethernet address: 00:0f:b5:82:07:c8 ath0: mac 7.9 phy 4.5 radio 5.6 Thx. From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 1 03:17:25 2005 Return-Path: X-Original-To: hackers@freebsd.org 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 4C18B16A41F; Thu, 1 Sep 2005 03:17:25 +0000 (GMT) (envelope-from jonny@jonny.eng.br) Received: from coe.ufrj.br (roma.coe.ufrj.br [146.164.53.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id BFEE443D49; Thu, 1 Sep 2005 03:17:24 +0000 (GMT) (envelope-from jonny@jonny.eng.br) Received: from localhost (localhost [127.0.0.1]) by coe.ufrj.br (Postfix) with ESMTP id 98BFB17005; Thu, 1 Sep 2005 00:17:22 -0300 (BRT) Received: from coe.ufrj.br ([146.164.53.65]) by localhost (roma.coe.ufrj.br [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24257-09; Thu, 1 Sep 2005 00:17:11 -0300 (BRT) Received: from [135.153.2.71] (201.20.201.118.corp.ajato.com.br [201.20.201.118]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by coe.ufrj.br (Postfix) with ESMTP id 1D02917004; Thu, 1 Sep 2005 00:16:55 -0300 (BRT) Message-ID: <4316729A.9010702@jonny.eng.br> Date: Thu, 01 Sep 2005 00:16:42 -0300 From: =?UTF-8?B?Sm/Do28gQ2FybG9zIE1lbmRlcyBMdcOtcw==?= User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Eygene A. Ryabinkin" References: <20050830092818.GD881@rea.mbslab.kiae.ru> <4314CBCE.7010405@jonny.eng.br> <20050831055026.GE1645@rea.mbslab.kiae.ru> In-Reply-To: <20050831055026.GE1645@rea.mbslab.kiae.ru> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at coe.ufrj.br Cc: hackers@freebsd.org, freebsd-usb@freebsd.org Subject: Re: Low umass performance with USB 2.0 ports X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2005 03:17:25 -0000 Eygene A. Ryabinkin wrote: >> I had exactly this problem with Kingston Data Traveler II+, and >>apparently completely solved it by adding a kludge to disallow Cache >>Syncronization. Try it yourself. > > And the kludge is? It's on my home machine, and I'm travelling now. But it's easy. Look at /sys/cam/scsi/scsi_da.c, look for the da_quirk_table array, and add the flag DA_Q_NO_SYNC_CACHE to your pen drive specs. There are lots of quirks for pen drives there, just copy one of then and edit the string identifiers. From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 1 08:44:31 2005 Return-Path: X-Original-To: hackers@freebsd.org 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 02DB516A41F; Thu, 1 Sep 2005 08:44:31 +0000 (GMT) (envelope-from freebsd@rea.mbslab.kiae.ru) Received: from rea.mbslab.kiae.ru (rea.mbslab.kiae.ru [144.206.177.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 81B3543D46; Thu, 1 Sep 2005 08:44:30 +0000 (GMT) (envelope-from freebsd@rea.mbslab.kiae.ru) Received: from rea.mbslab.kiae.ru (localhost [127.0.0.1]) by rea.mbslab.kiae.ru (Postfix) with ESMTP id 17CC5BD6D; Thu, 1 Sep 2005 12:44:22 +0400 (MSD) Received: by rea.mbslab.kiae.ru (Postfix, from userid 1000) id DE3E5BD6C; Thu, 1 Sep 2005 12:44:21 +0400 (MSD) Date: Thu, 1 Sep 2005 12:44:21 +0400 From: "Eygene A. Ryabinkin" To: Scott Long Message-ID: <20050901084421.GA840@rea.mbslab.kiae.ru> References: <200508302009.aa99975@nowhere.iedowse.com> <43160334.5000100@samsco.org> <43160943.6030400@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <43160943.6030400@samsco.org> User-Agent: Mutt/1.5.9i X-AV-Checked: Yes! Cc: Ian Dowse , hackers@freebsd.org, Eugene Grosbein , freebsd-usb@freebsd.org Subject: Re: Low umass performance with USB 2.0 ports X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2005 08:44:31 -0000 > Actually, I just peeked inside the Linux EHCI code and it does a dummy > read immediately after writing to the status register: > > /* clear (just) interrupts */ > writel (status, &ehci->regs->status); > readl (&ehci->regs->command); /* unblock posted write */ > > I wonder if that's the whole trick here. Would someone be willing to > try the attached patch instead of the one that Ian posted? Yes, that solved my problem. But the patch (for 5.x) uses different line numbers: ----- --- /sys/dev/usb/ehci.c.orig Thu Sep 1 10:59:51 2005 +++ /sys/dev/usb/ehci.c Thu Sep 1 10:48:59 2005 @@ -580,6 +580,7 @@ return (0); EOWRITE4(sc, EHCI_USBSTS, intrs); /* Acknowledge */ + EOREAD4(sc, EHCI_USBCMD); /* Flush posted writes on PCI */ sc->sc_bus.intr_context++; sc->sc_bus.no_intrs++; if (eintrs & EHCI_STS_IAA) { ----- Apart from this the patch works: the writing process still spends much time in the wdrain state, but no stalls occurs. Just a remark: my USB 2.0 controller chip is made by NEC, not VIA. For a FAT curiosity: FAT 32 gives 700K/sec and FAT 16 -- 3 Mb/sec. -- rea From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 1 09:28:26 2005 Return-Path: X-Original-To: hackers@freebsd.org 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 89A9616A41F for ; Thu, 1 Sep 2005 09:28:26 +0000 (GMT) (envelope-from vys@renet.ru) Received: from mail.renet.ru (mail-local.renet.ru [82.116.32.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id F266143D46 for ; Thu, 1 Sep 2005 09:28:24 +0000 (GMT) (envelope-from vys@renet.ru) Received: from [82.116.32.17] (fox.renet.ru [82.116.32.17]) by mail.renet.ru (8.13.3/8.13.1) with ESMTP id j819SHC1000980 for ; Thu, 1 Sep 2005 13:28:17 +0400 (MSD) Message-ID: <4316C9B1.9070003@renet.ru> Date: Thu, 01 Sep 2005 13:28:17 +0400 From: "Vladimir Yu. Stepanov" User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050616) X-Accept-Language: en-us, en MIME-Version: 1.0 To: hackers@freebsd.org Content-Type: multipart/mixed; boundary="------------000005080204030602000609" X-Virus-Scanned: ClamAV version 0.86.2, clamav-milter version 0.86 on mail.renet.ru X-Virus-Status: Clean X-Spam-Status: No, score=-105.9 required=2.2 tests=ALL_TRUSTED,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.0.1 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on mail.renet.ru X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: BPF patch X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2005 09:28:26 -0000 This is a multi-part message in MIME format. --------------000005080204030602000609 Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Hello! I made a modernization of bpf realization. It have a mind when we are trying to use bpf to account network statistic. When packets is catching by filter thereis imposible to determine the direction of packets flows. Due to this problem statistic accounts two times when packets is routes by the same interface, because this packets counts as incoming and outgoing traffic. The prototype of this patch is packet(7) on linux. This patch is fully compatible with all program uses the bpf. It adds the tags means traffic direction to the struct bpf_hdr. struct bpf_hdr { struct timeval bh_tstamp; /* time stamp */ bpf_u_int32 bh_caplen; /* length of captured portion */ bpf_u_int32 bh_datalen; /* original length of packet */ u_short bh_hdrlen; /* length of bpf header (this struct plus alignment padding) */ u_short bh_pkttype; /* packet type */ }; /* * Packet types. * For help to get some extra information. * It is taken from the description packet(7) in Linux system. */ #define BPFPKTTYPE_HOST 0 /* To us */ #define BPFPKTTYPE_BROADCAST 1 /* To all */ #define BPFPKTTYPE_MULTICAST 2 /* To group */ #define BPFPKTTYPE_OTHERHOST 3 /* To someone else */ #define BPFPKTTYPE_OUTGOING 4 /* Outgoing of any type */ #define BPFPKTTYPE_LOOPBACK 5 /* MC/BRD frame looped back */ #define BPFPKTTYPE_FASTROUTE 6 /* Fastrouted frame (if cannot detect MC/BRD type) */ --------------000005080204030602000609 Content-Type: text/plain; name="freebsd-5.1-bpf-2.0-r4.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="freebsd-5.1-bpf-2.0-r4.patch" diff -ruN sys.orig/net/bpf.c sys/net/bpf.c --- sys.orig/net/bpf.c Fri Dec 12 17:43:55 2003 +++ sys/net/bpf.c Fri Apr 15 20:40:31 2005 @@ -106,7 +106,7 @@ static __inline void bpf_wakeup(struct bpf_d *); static void catchpacket(struct bpf_d *, u_char *, u_int, - u_int, void (*)(const void *, void *, size_t)); + u_int, u_int, void (*)(const void *, void *, size_t)); static void reset_d(struct bpf_d *); static int bpf_setf(struct bpf_d *, struct bpf_program *); static int bpf_getdltlist(struct bpf_d *, struct bpf_dltlist *); @@ -1094,7 +1094,7 @@ #ifdef MAC if (mac_check_bpfdesc_receive(d, bp->bif_ifp) == 0) #endif - catchpacket(d, pkt, pktlen, slen, bcopy); + catchpacket(d, pkt, pktlen, slen, BPFPKTTYPE_FASTROUTE, bcopy); } BPFD_UNLOCK(d); } @@ -1137,15 +1137,32 @@ struct mbuf *m; { struct bpf_d *d; - u_int pktlen, slen; + u_int pktlen, slen, pkttype; pktlen = m_length(m, NULL); - if (pktlen == m->m_len) { - bpf_tap(bp, mtod(m, u_char *), pktlen); - return; - } BPFIF_LOCK(bp); + if (m->m_pkthdr.rcvif == NULL) + pkttype = BPFPKTTYPE_OUTGOING; + else + if (m->m_pkthdr.rcvif != bp->bif_ifp) + pkttype = BPFPKTTYPE_OUTGOING; + else + if ((m->m_flags&M_BPF_TAGGED) == M_BPF_TAGGED) + pkttype = BPFPKTTYPE_OUTGOING; + else { + if ((m->m_flags&M_BCAST) != 0) + pkttype = BPFPKTTYPE_BROADCAST; + else + if ((m->m_flags&M_MCAST) != 0) + pkttype = BPFPKTTYPE_MULTICAST; + else + /* How to detect if packet may received + * only in promiscuous mode ? */ + pkttype = BPFPKTTYPE_HOST; + } + if (m->m_pkthdr.rcvif != NULL && (m->m_flags&M_RDONLY) != M_RDONLY) + m->m_flags |= M_BPF_TAGGED; for (d = bp->bif_dlist; d != 0; d = d->bd_next) { if (!d->bd_seesent && (m->m_pkthdr.rcvif == NULL)) continue; @@ -1157,7 +1174,7 @@ if (mac_check_bpfdesc_receive(d, bp->bif_ifp) == 0) #endif catchpacket(d, (u_char *)m, pktlen, slen, - bpf_mcopy); + pkttype, bpf_mcopy); BPFD_UNLOCK(d); } BPFIF_UNLOCK(bp); @@ -1172,10 +1189,10 @@ * pkt is really an mbuf. */ static void -catchpacket(d, pkt, pktlen, snaplen, cpfn) +catchpacket(d, pkt, pktlen, snaplen, pkttype, cpfn) struct bpf_d *d; u_char *pkt; - u_int pktlen, snaplen; + u_int pktlen, snaplen, pkttype; void (*cpfn)(const void *, void *, size_t); { struct bpf_hdr *hp; @@ -1228,6 +1245,7 @@ microtime(&hp->bh_tstamp); hp->bh_datalen = pktlen; hp->bh_hdrlen = hdrlen; + hp->bh_pkttype = pkttype; /* * Copy the packet data into the store buffer and update its length. */ @@ -1326,11 +1344,11 @@ /* * Compute the length of the bpf header. This is not necessarily - * equal to SIZEOF_BPF_HDR because we want to insert spacing such - * that the network layer header begins on a longword boundary (for - * performance reasons and to alleviate alignment restrictions). + * equal to sizeof(struct bpf_hdr) because we want to insert spacing + * such that the network layer header begins on a longword boundary + * (for performance reasons and to alleviate alignment restrictions). */ - bp->bif_hdrlen = BPF_WORDALIGN(hdrlen + SIZEOF_BPF_HDR) - hdrlen; + bp->bif_hdrlen = BPF_WORDALIGN(hdrlen + sizeof(struct bpf_hdr)) - hdrlen; if (bootverbose) if_printf(ifp, "bpf attached\n"); diff -ruN sys.orig/net/bpf.h sys/net/bpf.h --- sys.orig/net/bpf.h Fri Dec 12 17:43:55 2003 +++ sys/net/bpf.h Fri Apr 15 20:40:31 2005 @@ -94,7 +94,7 @@ }; /* Current version number of filter architecture. */ #define BPF_MAJOR_VERSION 1 -#define BPF_MINOR_VERSION 1 +#define BPF_MINOR_VERSION 2 #define BIOCGBLEN _IOR('B',102, u_int) #define BIOCSBLEN _IOWR('B',102, u_int) @@ -127,16 +127,21 @@ bpf_u_int32 bh_datalen; /* original length of packet */ u_short bh_hdrlen; /* length of bpf header (this struct plus alignment padding) */ + u_short bh_pkttype; /* packet type */ }; + /* - * Because the structure above is not a multiple of 4 bytes, some compilers - * will insist on inserting padding; hence, sizeof(struct bpf_hdr) won't work. - * Only the kernel needs to know about it; applications use bh_hdrlen. + * Packet types. + * For help to get some extra information. + * It is taken from the description packet(7) in Linux system. */ -#ifdef _KERNEL -#define SIZEOF_BPF_HDR (sizeof(struct bpf_hdr) <= 20 ? 18 : \ - sizeof(struct bpf_hdr)) -#endif +#define BPFPKTTYPE_HOST 0 /* To us */ +#define BPFPKTTYPE_BROADCAST 1 /* To all */ +#define BPFPKTTYPE_MULTICAST 2 /* To group */ +#define BPFPKTTYPE_OTHERHOST 3 /* To someone else */ +#define BPFPKTTYPE_OUTGOING 4 /* Outgoing of any type */ +#define BPFPKTTYPE_LOOPBACK 5 /* MC/BRD frame looped back */ +#define BPFPKTTYPE_FASTROUTE 6 /* Fastrouted frame (if cannot detect MC/BRD type) */ /* * Data-link level type codes. diff -ruN sys.orig/sys/mbuf.h sys/sys/mbuf.h --- sys.orig/sys/mbuf.h Fri Dec 12 17:43:59 2003 +++ sys/sys/mbuf.h Fri Apr 15 20:40:31 2005 @@ -163,6 +163,7 @@ #define M_FRAG 0x0800 /* packet is a fragment of a larger packet */ #define M_FIRSTFRAG 0x1000 /* packet is first fragment */ #define M_LASTFRAG 0x2000 /* packet is last fragment */ +#define M_BPF_TAGGED 0x400000 /* * External buffer types: identify ext_buf type. --------------000005080204030602000609 Content-Type: text/plain; name="freebsd-5.2.1-bpf-2.0-r4.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="freebsd-5.2.1-bpf-2.0-r4.patch" diff -ruN sys.orig/net/bpf.c sys/net/bpf.c --- sys.orig/net/bpf.c Thu Dec 2 19:07:36 2004 +++ sys/net/bpf.c Fri Apr 15 16:39:39 2005 @@ -110,7 +110,7 @@ static __inline void bpf_wakeup(struct bpf_d *); static void catchpacket(struct bpf_d *, u_char *, u_int, - u_int, void (*)(const void *, void *, size_t)); + u_int, u_int, void (*)(const void *, void *, size_t)); static void reset_d(struct bpf_d *); static int bpf_setf(struct bpf_d *, struct bpf_program *); static int bpf_getdltlist(struct bpf_d *, struct bpf_dltlist *); @@ -1157,7 +1157,7 @@ #ifdef MAC if (mac_check_bpfdesc_receive(d, bp->bif_ifp) == 0) #endif - catchpacket(d, pkt, pktlen, slen, bcopy); + catchpacket(d, pkt, pktlen, slen, BPFPKTTYPE_FASTROUTE, bcopy); } BPFD_UNLOCK(d); } @@ -1200,15 +1200,32 @@ struct mbuf *m; { struct bpf_d *d; - u_int pktlen, slen; + u_int pktlen, slen, pkttype; pktlen = m_length(m, NULL); - if (pktlen == m->m_len) { - bpf_tap(bp, mtod(m, u_char *), pktlen); - return; - } BPFIF_LOCK(bp); + if (m->m_pkthdr.rcvif == NULL) + pkttype = BPFPKTTYPE_OUTGOING; + else + if (m->m_pkthdr.rcvif != bp->bif_ifp) + pkttype = BPFPKTTYPE_OUTGOING; + else + if ((m->m_flags&M_BPF_TAGGED) == M_BPF_TAGGED) + pkttype = BPFPKTTYPE_OUTGOING; + else { + if ((m->m_flags&M_BCAST) != 0) + pkttype = BPFPKTTYPE_BROADCAST; + else + if ((m->m_flags&M_MCAST) != 0) + pkttype = BPFPKTTYPE_MULTICAST; + else + /* How to detect if packet may received + * only in promiscuous mode ? */ + pkttype = BPFPKTTYPE_HOST; + } + if (m->m_pkthdr.rcvif != NULL && (m->m_flags&M_RDONLY) != M_RDONLY) + m->m_flags |= M_BPF_TAGGED; for (d = bp->bif_dlist; d != 0; d = d->bd_next) { if (!d->bd_seesent && (m->m_pkthdr.rcvif == NULL)) continue; @@ -1220,7 +1237,7 @@ if (mac_check_bpfdesc_receive(d, bp->bif_ifp) == 0) #endif catchpacket(d, (u_char *)m, pktlen, slen, - bpf_mcopy); + pkttype, bpf_mcopy); BPFD_UNLOCK(d); } BPFIF_UNLOCK(bp); @@ -1235,10 +1252,10 @@ * pkt is really an mbuf. */ static void -catchpacket(d, pkt, pktlen, snaplen, cpfn) +catchpacket(d, pkt, pktlen, snaplen, pkttype, cpfn) struct bpf_d *d; u_char *pkt; - u_int pktlen, snaplen; + u_int pktlen, snaplen, pkttype; void (*cpfn)(const void *, void *, size_t); { struct bpf_hdr *hp; @@ -1291,6 +1308,7 @@ microtime(&hp->bh_tstamp); hp->bh_datalen = pktlen; hp->bh_hdrlen = hdrlen; + hp->bh_pkttype = pkttype; /* * Copy the packet data into the store buffer and update its length. */ @@ -1389,11 +1407,11 @@ /* * Compute the length of the bpf header. This is not necessarily - * equal to SIZEOF_BPF_HDR because we want to insert spacing such - * that the network layer header begins on a longword boundary (for - * performance reasons and to alleviate alignment restrictions). + * equal to sizeof(struct bpf_hdr) because we want to insert spacing + * such that the network layer header begins on a longword boundary + * (for performance reasons and to alleviate alignment restrictions). */ - bp->bif_hdrlen = BPF_WORDALIGN(hdrlen + SIZEOF_BPF_HDR) - hdrlen; + bp->bif_hdrlen = BPF_WORDALIGN(hdrlen + sizeof(struct bpf_hdr)) - hdrlen; if (bootverbose) if_printf(ifp, "bpf attached\n"); diff -ruN sys.orig/net/bpf.h sys/net/bpf.h --- sys.orig/net/bpf.h Thu Dec 2 19:07:35 2004 +++ sys/net/bpf.h Fri Apr 15 16:35:24 2005 @@ -94,7 +94,7 @@ }; /* Current version number of filter architecture. */ #define BPF_MAJOR_VERSION 1 -#define BPF_MINOR_VERSION 1 +#define BPF_MINOR_VERSION 2 #define BIOCGBLEN _IOR('B',102, u_int) #define BIOCSBLEN _IOWR('B',102, u_int) @@ -127,16 +127,21 @@ bpf_u_int32 bh_datalen; /* original length of packet */ u_short bh_hdrlen; /* length of bpf header (this struct plus alignment padding) */ + u_short bh_pkttype; /* packet type */ }; + /* - * Because the structure above is not a multiple of 4 bytes, some compilers - * will insist on inserting padding; hence, sizeof(struct bpf_hdr) won't work. - * Only the kernel needs to know about it; applications use bh_hdrlen. + * Packet types. + * For help to get some extra information. + * It is taken from the description packet(7) in Linux system. */ -#ifdef _KERNEL -#define SIZEOF_BPF_HDR (sizeof(struct bpf_hdr) <= 20 ? 18 : \ - sizeof(struct bpf_hdr)) -#endif +#define BPFPKTTYPE_HOST 0 /* To us */ +#define BPFPKTTYPE_BROADCAST 1 /* To all */ +#define BPFPKTTYPE_MULTICAST 2 /* To group */ +#define BPFPKTTYPE_OTHERHOST 3 /* To someone else */ +#define BPFPKTTYPE_OUTGOING 4 /* Outgoing of any type */ +#define BPFPKTTYPE_LOOPBACK 5 /* MC/BRD frame looped back */ +#define BPFPKTTYPE_FASTROUTE 6 /* Fastrouted frame (if cannot detect MC/BRD type) */ /* * Data-link level type codes. diff -ruN sys.orig/sys/mbuf.h sys/sys/mbuf.h --- sys.orig/sys/mbuf.h Thu Dec 2 19:07:43 2004 +++ sys/sys/mbuf.h Fri Apr 15 16:40:55 2005 @@ -164,6 +164,7 @@ #define M_FRAG 0x0800 /* packet is a fragment of a larger packet */ #define M_FIRSTFRAG 0x1000 /* packet is first fragment */ #define M_LASTFRAG 0x2000 /* packet is last fragment */ +#define M_BPF_TAGGED 0x400000 /* * External buffer types: identify ext_buf type. --------------000005080204030602000609 Content-Type: text/plain; name="freebsd-5.3-bpf-2.0-r4.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="freebsd-5.3-bpf-2.0-r4.patch" diff -ruN sys.orig/net/bpf.c sys/net/bpf.c --- sys.orig/net/bpf.c Mon Oct 11 07:45:21 2004 +++ sys/net/bpf.c Fri Apr 15 10:31:39 2005 @@ -106,7 +106,7 @@ static __inline void bpf_wakeup(struct bpf_d *); static void catchpacket(struct bpf_d *, u_char *, u_int, - u_int, void (*)(const void *, void *, size_t)); + u_int, u_int, void (*)(const void *, void *, size_t)); static void reset_d(struct bpf_d *); static int bpf_setf(struct bpf_d *, struct bpf_program *); static int bpf_getdltlist(struct bpf_d *, struct bpf_dltlist *); @@ -1162,7 +1162,7 @@ #ifdef MAC if (mac_check_bpfdesc_receive(d, bp->bif_ifp) == 0) #endif - catchpacket(d, pkt, pktlen, slen, bcopy); + catchpacket(d, pkt, pktlen, slen, BPFPKTTYPE_FASTROUTE, bcopy); } BPFD_UNLOCK(d); } @@ -1205,7 +1205,7 @@ struct mbuf *m; { struct bpf_d *d; - u_int pktlen, slen; + u_int pktlen, slen, pkttype; /* * Lockless read to avoid cost of locking the interface if there are @@ -1215,12 +1215,29 @@ return; pktlen = m_length(m, NULL); - if (pktlen == m->m_len) { - bpf_tap(bp, mtod(m, u_char *), pktlen); - return; - } BPFIF_LOCK(bp); + if (m->m_pkthdr.rcvif == NULL) + pkttype = BPFPKTTYPE_OUTGOING; + else + if (m->m_pkthdr.rcvif != bp->bif_ifp) + pkttype = BPFPKTTYPE_OUTGOING; + else + if ((m->m_flags&M_BPF_TAGGED) == M_BPF_TAGGED) + pkttype = BPFPKTTYPE_OUTGOING; + else { + if ((m->m_flags&M_BCAST) != 0) + pkttype = BPFPKTTYPE_BROADCAST; + else + if ((m->m_flags&M_MCAST) != 0) + pkttype = BPFPKTTYPE_MULTICAST; + else + /* How to detect if packet may received + * only in promiscuous mode ? */ + pkttype = BPFPKTTYPE_HOST; + } + if (m->m_pkthdr.rcvif != NULL && (m->m_flags&M_RDONLY) != M_RDONLY) + m->m_flags |= M_BPF_TAGGED; LIST_FOREACH(d, &bp->bif_dlist, bd_next) { if (!d->bd_seesent && (m->m_pkthdr.rcvif == NULL)) continue; @@ -1232,7 +1249,7 @@ if (mac_check_bpfdesc_receive(d, bp->bif_ifp) == 0) #endif catchpacket(d, (u_char *)m, pktlen, slen, - bpf_mcopy); + pkttype, bpf_mcopy); BPFD_UNLOCK(d); } BPFIF_UNLOCK(bp); @@ -1251,7 +1268,7 @@ { struct mbuf mb; struct bpf_d *d; - u_int pktlen, slen; + u_int pktlen, slen, pkttype; /* * Lockless read to avoid cost of locking the interface if there are @@ -1272,6 +1289,27 @@ pktlen += dlen; BPFIF_LOCK(bp); + if (m->m_pkthdr.rcvif == NULL) + pkttype = BPFPKTTYPE_OUTGOING; + else + if (m->m_pkthdr.rcvif != bp->bif_ifp) + pkttype = BPFPKTTYPE_OUTGOING; + else + if ((m->m_flags&M_BPF_TAGGED) == M_BPF_TAGGED) + pkttype = BPFPKTTYPE_OUTGOING; + else { + if ((m->m_flags&M_BCAST) != 0) + pkttype = BPFPKTTYPE_BROADCAST; + else + if ((m->m_flags&M_MCAST) != 0) + pkttype = BPFPKTTYPE_MULTICAST; + else + /* How to detect if packet may received + * only in promiscuous mode ? */ + pkttype = BPFPKTTYPE_HOST; + } + if (m->m_pkthdr.rcvif != NULL && (m->m_flags&M_RDONLY) != M_RDONLY) + m->m_flags |= M_BPF_TAGGED; LIST_FOREACH(d, &bp->bif_dlist, bd_next) { if (!d->bd_seesent && (m->m_pkthdr.rcvif == NULL)) continue; @@ -1283,7 +1321,7 @@ if (mac_check_bpfdesc_receive(d, bp->bif_ifp) == 0) #endif catchpacket(d, (u_char *)&mb, pktlen, slen, - bpf_mcopy); + pkttype, bpf_mcopy); BPFD_UNLOCK(d); } BPFIF_UNLOCK(bp); @@ -1297,10 +1335,10 @@ * pkt is really an mbuf. */ static void -catchpacket(d, pkt, pktlen, snaplen, cpfn) +catchpacket(d, pkt, pktlen, snaplen, pkttype, cpfn) struct bpf_d *d; u_char *pkt; - u_int pktlen, snaplen; + u_int pktlen, snaplen, pkttype; void (*cpfn)(const void *, void *, size_t); { struct bpf_hdr *hp; @@ -1354,6 +1392,7 @@ microtime(&hp->bh_tstamp); hp->bh_datalen = pktlen; hp->bh_hdrlen = hdrlen; + hp->bh_pkttype = pkttype; /* * Copy the packet data into the store buffer and update its length. */ @@ -1451,11 +1490,11 @@ /* * Compute the length of the bpf header. This is not necessarily - * equal to SIZEOF_BPF_HDR because we want to insert spacing such - * that the network layer header begins on a longword boundary (for - * performance reasons and to alleviate alignment restrictions). + * equal to sizeof(struct bpf_hdr) because we want to insert spacing + * such that the network layer header begins on a longword boundary + * (for performance reasons and to alleviate alignment restrictions). */ - bp->bif_hdrlen = BPF_WORDALIGN(hdrlen + SIZEOF_BPF_HDR) - hdrlen; + bp->bif_hdrlen = BPF_WORDALIGN(hdrlen + sizeof(struct bpf_hdr)) - hdrlen; if (bootverbose) if_printf(ifp, "bpf attached\n"); diff -ruN sys.orig/net/bpf.h sys/net/bpf.h --- sys.orig/net/bpf.h Sun May 30 21:03:48 2004 +++ sys/net/bpf.h Fri Apr 15 09:28:16 2005 @@ -90,7 +90,7 @@ }; /* Current version number of filter architecture. */ #define BPF_MAJOR_VERSION 1 -#define BPF_MINOR_VERSION 1 +#define BPF_MINOR_VERSION 2 #define BIOCGBLEN _IOR('B',102, u_int) #define BIOCSBLEN _IOWR('B',102, u_int) @@ -123,16 +123,21 @@ bpf_u_int32 bh_datalen; /* original length of packet */ u_short bh_hdrlen; /* length of bpf header (this struct plus alignment padding) */ + u_short bh_pkttype; /* packet type */ }; + /* - * Because the structure above is not a multiple of 4 bytes, some compilers - * will insist on inserting padding; hence, sizeof(struct bpf_hdr) won't work. - * Only the kernel needs to know about it; applications use bh_hdrlen. + * Packet types. + * For help to get some extra information. + * It is taken from the description packet(7) in Linux system. */ -#ifdef _KERNEL -#define SIZEOF_BPF_HDR (sizeof(struct bpf_hdr) <= 20 ? 18 : \ - sizeof(struct bpf_hdr)) -#endif +#define BPFPKTTYPE_HOST 0 /* To us */ +#define BPFPKTTYPE_BROADCAST 1 /* To all */ +#define BPFPKTTYPE_MULTICAST 2 /* To group */ +#define BPFPKTTYPE_OTHERHOST 3 /* To someone else */ +#define BPFPKTTYPE_OUTGOING 4 /* Outgoing of any type */ +#define BPFPKTTYPE_LOOPBACK 5 /* MC/BRD frame looped back */ +#define BPFPKTTYPE_FASTROUTE 6 /* Fastrouted frame (if cannot detect MC/BRD type) */ /* * Data-link level type codes. diff -ruN sys.orig/sys/mbuf.h sys/sys/mbuf.h --- sys.orig/sys/mbuf.h Sat Oct 16 01:45:13 2004 +++ sys/sys/mbuf.h Fri Apr 15 09:42:31 2005 @@ -178,6 +178,7 @@ #define M_FRAG 0x0800 /* packet is a fragment of a larger packet */ #define M_FIRSTFRAG 0x1000 /* packet is first fragment */ #define M_LASTFRAG 0x2000 /* packet is last fragment */ +#define M_BPF_TAGGED 0x400000 /* * External buffer types: identify ext_buf type. --------------000005080204030602000609 Content-Type: text/plain; name="freebsd-5.4-bpf-2.0-r4.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="freebsd-5.4-bpf-2.0-r4.patch" diff -ruN sys.orig/net/bpf.c sys/net/bpf.c --- sys.orig/net/bpf.c Thu Jun 16 14:41:15 2005 +++ sys/net/bpf.c Thu Jun 16 14:45:59 2005 @@ -109,7 +109,7 @@ static __inline void bpf_wakeup(struct bpf_d *); static void catchpacket(struct bpf_d *, u_char *, u_int, - u_int, void (*)(const void *, void *, size_t)); + u_int, u_int, void (*)(const void *, void *, size_t)); static void reset_d(struct bpf_d *); static int bpf_setf(struct bpf_d *, struct bpf_program *); static int bpf_getdltlist(struct bpf_d *, struct bpf_dltlist *); @@ -1168,7 +1168,7 @@ #ifdef MAC if (mac_check_bpfdesc_receive(d, bp->bif_ifp) == 0) #endif - catchpacket(d, pkt, pktlen, slen, bcopy); + catchpacket(d, pkt, pktlen, slen, BPFPKTTYPE_FASTROUTE, bcopy); } BPFD_UNLOCK(d); } @@ -1211,7 +1211,7 @@ struct mbuf *m; { struct bpf_d *d; - u_int pktlen, slen; + u_int pktlen, slen, pkttype; /* * Lockless read to avoid cost of locking the interface if there are @@ -1221,12 +1221,29 @@ return; pktlen = m_length(m, NULL); - if (pktlen == m->m_len) { - bpf_tap(bp, mtod(m, u_char *), pktlen); - return; - } BPFIF_LOCK(bp); + if (m->m_pkthdr.rcvif == NULL) + pkttype = BPFPKTTYPE_OUTGOING; + else + if (m->m_pkthdr.rcvif != bp->bif_ifp) + pkttype = BPFPKTTYPE_OUTGOING; + else + if ((m->m_flags&M_BPF_TAGGED) == M_BPF_TAGGED) + pkttype = BPFPKTTYPE_OUTGOING; + else { + if ((m->m_flags&M_BCAST) != 0) + pkttype = BPFPKTTYPE_BROADCAST; + else + if ((m->m_flags&M_MCAST) != 0) + pkttype = BPFPKTTYPE_MULTICAST; + else + /* How to detect if packet may received + * only in promiscuous mode ? */ + pkttype = BPFPKTTYPE_HOST; + } + if (m->m_pkthdr.rcvif != NULL && (m->m_flags&M_RDONLY) != M_RDONLY) + m->m_flags |= M_BPF_TAGGED; LIST_FOREACH(d, &bp->bif_dlist, bd_next) { if (!d->bd_seesent && (m->m_pkthdr.rcvif == NULL)) continue; @@ -1238,7 +1255,7 @@ if (mac_check_bpfdesc_receive(d, bp->bif_ifp) == 0) #endif catchpacket(d, (u_char *)m, pktlen, slen, - bpf_mcopy); + pkttype, bpf_mcopy); BPFD_UNLOCK(d); } BPFIF_UNLOCK(bp); @@ -1257,7 +1274,7 @@ { struct mbuf mb; struct bpf_d *d; - u_int pktlen, slen; + u_int pktlen, slen, pkttype; /* * Lockless read to avoid cost of locking the interface if there are @@ -1278,6 +1295,27 @@ pktlen += dlen; BPFIF_LOCK(bp); + if (m->m_pkthdr.rcvif == NULL) + pkttype = BPFPKTTYPE_OUTGOING; + else + if (m->m_pkthdr.rcvif != bp->bif_ifp) + pkttype = BPFPKTTYPE_OUTGOING; + else + if ((m->m_flags&M_BPF_TAGGED) == M_BPF_TAGGED) + pkttype = BPFPKTTYPE_OUTGOING; + else { + if ((m->m_flags&M_BCAST) != 0) + pkttype = BPFPKTTYPE_BROADCAST; + else + if ((m->m_flags&M_MCAST) != 0) + pkttype = BPFPKTTYPE_MULTICAST; + else + /* How to detect if packet may received + * only in promiscuous mode ? */ + pkttype = BPFPKTTYPE_HOST; + } + if (m->m_pkthdr.rcvif != NULL && (m->m_flags&M_RDONLY) != M_RDONLY) + m->m_flags |= M_BPF_TAGGED; LIST_FOREACH(d, &bp->bif_dlist, bd_next) { if (!d->bd_seesent && (m->m_pkthdr.rcvif == NULL)) continue; @@ -1289,7 +1327,7 @@ if (mac_check_bpfdesc_receive(d, bp->bif_ifp) == 0) #endif catchpacket(d, (u_char *)&mb, pktlen, slen, - bpf_mcopy); + pkttype, bpf_mcopy); BPFD_UNLOCK(d); } BPFIF_UNLOCK(bp); @@ -1303,10 +1341,10 @@ * pkt is really an mbuf. */ static void -catchpacket(d, pkt, pktlen, snaplen, cpfn) +catchpacket(d, pkt, pktlen, snaplen, pkttype, cpfn) struct bpf_d *d; u_char *pkt; - u_int pktlen, snaplen; + u_int pktlen, snaplen, pkttype; void (*cpfn)(const void *, void *, size_t); { struct bpf_hdr *hp; @@ -1361,6 +1399,7 @@ microtime(&hp->bh_tstamp); hp->bh_datalen = pktlen; hp->bh_hdrlen = hdrlen; + hp->bh_pkttype = pkttype; /* * Copy the packet data into the store buffer and update its length. */ @@ -1461,11 +1500,11 @@ /* * Compute the length of the bpf header. This is not necessarily - * equal to SIZEOF_BPF_HDR because we want to insert spacing such - * that the network layer header begins on a longword boundary (for - * performance reasons and to alleviate alignment restrictions). + * equal to sizeof(struct bpf_hdr) because we want to insert spacing + * such that the network layer header begins on a longword boundary + * (for performance reasons and to alleviate alignment restrictions). */ - bp->bif_hdrlen = BPF_WORDALIGN(hdrlen + SIZEOF_BPF_HDR) - hdrlen; + bp->bif_hdrlen = BPF_WORDALIGN(hdrlen + sizeof(struct bpf_hdr)) - hdrlen; if (bootverbose) if_printf(ifp, "bpf attached\n"); diff -ruN sys.orig/net/bpf.h sys/net/bpf.h --- sys.orig/net/bpf.h Thu Jun 16 14:41:15 2005 +++ sys/net/bpf.h Thu Jun 16 14:45:59 2005 @@ -90,7 +90,7 @@ }; /* Current version number of filter architecture. */ #define BPF_MAJOR_VERSION 1 -#define BPF_MINOR_VERSION 1 +#define BPF_MINOR_VERSION 2 #define BIOCGBLEN _IOR('B',102, u_int) #define BIOCSBLEN _IOWR('B',102, u_int) @@ -123,16 +123,21 @@ bpf_u_int32 bh_datalen; /* original length of packet */ u_short bh_hdrlen; /* length of bpf header (this struct plus alignment padding) */ + u_short bh_pkttype; /* packet type */ }; + /* - * Because the structure above is not a multiple of 4 bytes, some compilers - * will insist on inserting padding; hence, sizeof(struct bpf_hdr) won't work. - * Only the kernel needs to know about it; applications use bh_hdrlen. + * Packet types. + * For help to get some extra information. + * It is taken from the description packet(7) in Linux system. */ -#ifdef _KERNEL -#define SIZEOF_BPF_HDR (sizeof(struct bpf_hdr) <= 20 ? 18 : \ - sizeof(struct bpf_hdr)) -#endif +#define BPFPKTTYPE_HOST 0 /* To us */ +#define BPFPKTTYPE_BROADCAST 1 /* To all */ +#define BPFPKTTYPE_MULTICAST 2 /* To group */ +#define BPFPKTTYPE_OTHERHOST 3 /* To someone else */ +#define BPFPKTTYPE_OUTGOING 4 /* Outgoing of any type */ +#define BPFPKTTYPE_LOOPBACK 5 /* MC/BRD frame looped back */ +#define BPFPKTTYPE_FASTROUTE 6 /* Fastrouted frame (if cannot detect MC/BRD type) */ /* * Data-link level type codes. diff -ruN sys.orig/sys/mbuf.h sys/sys/mbuf.h --- sys.orig/sys/mbuf.h Thu Jun 16 14:41:19 2005 +++ sys/sys/mbuf.h Thu Jun 16 14:45:59 2005 @@ -178,6 +178,7 @@ #define M_FRAG 0x0800 /* packet is a fragment of a larger packet */ #define M_FIRSTFRAG 0x1000 /* packet is first fragment */ #define M_LASTFRAG 0x2000 /* packet is last fragment */ +#define M_BPF_TAGGED 0x400000 /* * External buffer types: identify ext_buf type. --------------000005080204030602000609-- From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 1 09:37:35 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 2A51B16A41F; Thu, 1 Sep 2005 09:37:35 +0000 (GMT) (envelope-from freebsd@rea.mbslab.kiae.ru) Received: from rea.mbslab.kiae.ru (rea.mbslab.kiae.ru [144.206.177.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id AADA143D46; Thu, 1 Sep 2005 09:37:34 +0000 (GMT) (envelope-from freebsd@rea.mbslab.kiae.ru) Received: from rea.mbslab.kiae.ru (localhost [127.0.0.1]) by rea.mbslab.kiae.ru (Postfix) with ESMTP id 7CD7EBAD0; Thu, 1 Sep 2005 13:37:33 +0400 (MSD) Received: by rea.mbslab.kiae.ru (Postfix, from userid 1000) id 47403BA3E; Thu, 1 Sep 2005 13:37:33 +0400 (MSD) Date: Thu, 1 Sep 2005 13:37:33 +0400 From: "Eygene A. Ryabinkin" To: Hans Petter Selasky Message-ID: <20050901093733.GA915@rea.mbslab.kiae.ru> References: <200508302009.aa99975@nowhere.iedowse.com> <43160334.5000100@samsco.org> <43160943.6030400@samsco.org> <200508312239.04897.hselasky@c2i.net> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <200508312239.04897.hselasky@c2i.net> User-Agent: Mutt/1.5.9i X-AV-Checked: Yes! Cc: Scott Long , freebsd-hackers@freebsd.org, Ian Dowse , hackers@freebsd.org, Eugene Grosbein , freebsd-usb@freebsd.org Subject: Re: Low umass performance with USB 2.0 ports X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2005 09:37:35 -0000 > If Scott's patch doesn't work, could you have tried to install the following > (compiles on FreeBSD 5/6/7): Yes, it also works and does even better work: FAT 32 and FAT 16 permormance are just the same and there is no additional load as been with the Scott's patch. So I definitely would vote for this fix. > > Download the three files below into a new directory and type > "make install" (to uninstall type "make deinstall") > http://home.c2i.net/hselasky/isdn4bsd/privat/usb/Makefile > http://home.c2i.net/hselasky/isdn4bsd/privat/usb/new_usb_1_5_4.diff.bz2 > http://home.c2i.net/hselasky/isdn4bsd/privat/usb/new_usb_1_5_4.tar.bz2 Can this fix be transformed into the patch? It will be very helpful to the committers to have in the form of patch. Are there any reasons to make it in the way you did? Thank you for your work! -- rea From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 1 09:37:35 2005 Return-Path: X-Original-To: hackers@freebsd.org 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 2A51B16A41F; Thu, 1 Sep 2005 09:37:35 +0000 (GMT) (envelope-from freebsd@rea.mbslab.kiae.ru) Received: from rea.mbslab.kiae.ru (rea.mbslab.kiae.ru [144.206.177.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id AADA143D46; Thu, 1 Sep 2005 09:37:34 +0000 (GMT) (envelope-from freebsd@rea.mbslab.kiae.ru) Received: from rea.mbslab.kiae.ru (localhost [127.0.0.1]) by rea.mbslab.kiae.ru (Postfix) with ESMTP id 7CD7EBAD0; Thu, 1 Sep 2005 13:37:33 +0400 (MSD) Received: by rea.mbslab.kiae.ru (Postfix, from userid 1000) id 47403BA3E; Thu, 1 Sep 2005 13:37:33 +0400 (MSD) Date: Thu, 1 Sep 2005 13:37:33 +0400 From: "Eygene A. Ryabinkin" To: Hans Petter Selasky Message-ID: <20050901093733.GA915@rea.mbslab.kiae.ru> References: <200508302009.aa99975@nowhere.iedowse.com> <43160334.5000100@samsco.org> <43160943.6030400@samsco.org> <200508312239.04897.hselasky@c2i.net> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <200508312239.04897.hselasky@c2i.net> User-Agent: Mutt/1.5.9i X-AV-Checked: Yes! Cc: Scott Long , freebsd-hackers@freebsd.org, Ian Dowse , hackers@freebsd.org, Eugene Grosbein , freebsd-usb@freebsd.org Subject: Re: Low umass performance with USB 2.0 ports X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2005 09:37:35 -0000 > If Scott's patch doesn't work, could you have tried to install the following > (compiles on FreeBSD 5/6/7): Yes, it also works and does even better work: FAT 32 and FAT 16 permormance are just the same and there is no additional load as been with the Scott's patch. So I definitely would vote for this fix. > > Download the three files below into a new directory and type > "make install" (to uninstall type "make deinstall") > http://home.c2i.net/hselasky/isdn4bsd/privat/usb/Makefile > http://home.c2i.net/hselasky/isdn4bsd/privat/usb/new_usb_1_5_4.diff.bz2 > http://home.c2i.net/hselasky/isdn4bsd/privat/usb/new_usb_1_5_4.tar.bz2 Can this fix be transformed into the patch? It will be very helpful to the committers to have in the form of patch. Are there any reasons to make it in the way you did? Thank you for your work! -- rea From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 1 10:36:30 2005 Return-Path: X-Original-To: hackers@freebsd.org 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 00AA516A41F for ; Thu, 1 Sep 2005 10:36:29 +0000 (GMT) (envelope-from vladgalu@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id 97E7043D48 for ; Thu, 1 Sep 2005 10:36:29 +0000 (GMT) (envelope-from vladgalu@gmail.com) Received: by zproxy.gmail.com with SMTP id z6so91005nzd for ; Thu, 01 Sep 2005 03:36:28 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=jJSnVSGi93zgMRjCyklhtDykjUc45wi7S97dj52D+1nUqELLeKsgH8M+3Wq4S74W0dTK6zUNzpgfGyQvtUr3pc3zNM77UYebjlstAVYKNA+//9PEAgR036DHHN1WKjW9okAotFlc1TlxOIxOtm+xCqSvJ6cLR6Q6+g7jsPouUtM= Received: by 10.36.129.1 with SMTP id b1mr1050559nzd; Thu, 01 Sep 2005 03:36:28 -0700 (PDT) Received: by 10.36.86.4 with HTTP; Thu, 1 Sep 2005 03:36:28 -0700 (PDT) Message-ID: <79722fad05090103363fc910@mail.gmail.com> Date: Thu, 1 Sep 2005 13:36:28 +0300 From: Vlad GALU To: hackers@freebsd.org In-Reply-To: <4316C9B1.9070003@renet.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <4316C9B1.9070003@renet.ru> Cc: Subject: Re: BPF patch X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2005 10:36:30 -0000 On 9/1/05, Vladimir Yu. Stepanov wrote: [snip] You can always control which traffic to sniff (ingress/egress) using layer 2 filters (ether src/dst host <>). --=20 If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 1 06:53:47 2005 Return-Path: X-Original-To: hackers@freebsd.org 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 74DC916A41F for ; Thu, 1 Sep 2005 06:53:47 +0000 (GMT) (envelope-from gni@gecko.de) Received: from kirk.baltic.net (kirk.baltic.net [193.189.247.10]) by mx1.FreeBSD.org (Postfix) with SMTP id 372A743D4C for ; Thu, 1 Sep 2005 06:53:41 +0000 (GMT) (envelope-from gni@gecko.de) Received: (qmail 9121 invoked from network); 1 Sep 2005 06:50:00 -0000 Received: from waldorf.gecko.de (HELO kermit.int.gecko.de) (193.189.247.200) by kirk.baltic.net with SMTP; 1 Sep 2005 06:50:00 -0000 Received: from lorien.int.gecko.de (lorien [192.168.120.159]) by kermit.int.gecko.de (8.12.10+Sun/8.12.10) with ESMTP id j816rd6B007558; Thu, 1 Sep 2005 08:53:39 +0200 (CEST) Received: from lorien.int.gecko.de (localhost [127.0.0.1]) by lorien.int.gecko.de (8.12.9/8.12.9) with ESMTP id j816t6Cu023198; Thu, 1 Sep 2005 08:55:06 +0200 (MEST) (envelope-from munk@lorien.int.gecko.de) Received: (from munk@localhost) by lorien.int.gecko.de (8.12.9/8.12.9/Submit) id j816t5EW023197; Thu, 1 Sep 2005 08:55:05 +0200 (MEST) Date: Thu, 1 Sep 2005 08:55:05 +0200 From: Gunther Nikl To: "Eygene A. Ryabinkin" Message-ID: <20050901065505.GA23180@lorien.int.gecko.de> References: <20050830092818.GD881@rea.mbslab.kiae.ru> <4314523D.79926C81@kuzbass.ru> <20050830125031.GA775@rea.mbslab.kiae.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050830125031.GA775@rea.mbslab.kiae.ru> User-Agent: Mutt/1.4.2.1i X-Mailman-Approved-At: Thu, 01 Sep 2005 11:39:21 +0000 Cc: hackers@freebsd.org, freebsd-usb@freebsd.org Subject: Re: Low umass performance with USB 2.0 ports X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2005 06:53:47 -0000 On Tue, Aug 30, 2005 at 04:50:31PM +0400, Eygene A. Ryabinkin wrote: > > FreeBSD 4.x had very low performance with FAT filesystem, > > writing process spent lots of time in the wdrain state too. > Yes, it has. Did you try mtools? I get much better performance with mtools compared to msdosfs. Gunther From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 1 12:08:33 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 81C9916A41F; Thu, 1 Sep 2005 12:08:33 +0000 (GMT) (envelope-from freebsd@rea.mbslab.kiae.ru) Received: from rea.mbslab.kiae.ru (rea.mbslab.kiae.ru [144.206.177.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0F35B43D46; Thu, 1 Sep 2005 12:08:33 +0000 (GMT) (envelope-from freebsd@rea.mbslab.kiae.ru) Received: from rea.mbslab.kiae.ru (localhost [127.0.0.1]) by rea.mbslab.kiae.ru (Postfix) with ESMTP id 09C4BBE7D; Thu, 1 Sep 2005 16:08:27 +0400 (MSD) Received: by rea.mbslab.kiae.ru (Postfix, from userid 1000) id CF50ABE7A; Thu, 1 Sep 2005 16:08:26 +0400 (MSD) Date: Thu, 1 Sep 2005 16:08:26 +0400 From: "Eygene A. Ryabinkin" To: Hans Petter Selasky Message-ID: <20050901120826.GB915@rea.mbslab.kiae.ru> References: <200508302009.aa99975@nowhere.iedowse.com> <43160334.5000100@samsco.org> <43160943.6030400@samsco.org> <200508312239.04897.hselasky@c2i.net> <20050901093733.GA915@rea.mbslab.kiae.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20050901093733.GA915@rea.mbslab.kiae.ru> User-Agent: Mutt/1.5.9i X-AV-Checked: Yes! Cc: Scott Long , freebsd-hackers@freebsd.org, Ian Dowse , hackers@freebsd.org, Eugene Grosbein , freebsd-usb@freebsd.org Subject: Re: Low umass performance with USB 2.0 ports X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2005 12:08:33 -0000 > Yes, it also works and does even better work: FAT 32 and FAT 16 permormance > are just the same and there is no additional load as been with the Scott's > patch. > So I definitely would vote for this fix. Oops, it seems that this patch also does not work as expected: after some time of playing with flash card and working with the system it started to stall as unpatched system, but it freezes the system -- even IP stack was frozen (I am using DEVICE_POLLING), so I were to remove the flash from the port -- system was unfrozen and continued to work. So something is still bad with the USB. I'll try to do some long testing with USB 1.1 -- maybe it will show the same behaviour after some more time. -- rea From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 1 12:08:33 2005 Return-Path: X-Original-To: hackers@freebsd.org 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 81C9916A41F; Thu, 1 Sep 2005 12:08:33 +0000 (GMT) (envelope-from freebsd@rea.mbslab.kiae.ru) Received: from rea.mbslab.kiae.ru (rea.mbslab.kiae.ru [144.206.177.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0F35B43D46; Thu, 1 Sep 2005 12:08:33 +0000 (GMT) (envelope-from freebsd@rea.mbslab.kiae.ru) Received: from rea.mbslab.kiae.ru (localhost [127.0.0.1]) by rea.mbslab.kiae.ru (Postfix) with ESMTP id 09C4BBE7D; Thu, 1 Sep 2005 16:08:27 +0400 (MSD) Received: by rea.mbslab.kiae.ru (Postfix, from userid 1000) id CF50ABE7A; Thu, 1 Sep 2005 16:08:26 +0400 (MSD) Date: Thu, 1 Sep 2005 16:08:26 +0400 From: "Eygene A. Ryabinkin" To: Hans Petter Selasky Message-ID: <20050901120826.GB915@rea.mbslab.kiae.ru> References: <200508302009.aa99975@nowhere.iedowse.com> <43160334.5000100@samsco.org> <43160943.6030400@samsco.org> <200508312239.04897.hselasky@c2i.net> <20050901093733.GA915@rea.mbslab.kiae.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20050901093733.GA915@rea.mbslab.kiae.ru> User-Agent: Mutt/1.5.9i X-AV-Checked: Yes! Cc: Scott Long , freebsd-hackers@freebsd.org, Ian Dowse , hackers@freebsd.org, Eugene Grosbein , freebsd-usb@freebsd.org Subject: Re: Low umass performance with USB 2.0 ports X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2005 12:08:33 -0000 > Yes, it also works and does even better work: FAT 32 and FAT 16 permormance > are just the same and there is no additional load as been with the Scott's > patch. > So I definitely would vote for this fix. Oops, it seems that this patch also does not work as expected: after some time of playing with flash card and working with the system it started to stall as unpatched system, but it freezes the system -- even IP stack was frozen (I am using DEVICE_POLLING), so I were to remove the flash from the port -- system was unfrozen and continued to work. So something is still bad with the USB. I'll try to do some long testing with USB 1.1 -- maybe it will show the same behaviour after some more time. -- rea From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 1 13:31:54 2005 Return-Path: X-Original-To: hackers@freebsd.org 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 D9B9D16A41F; Thu, 1 Sep 2005 13:31:54 +0000 (GMT) (envelope-from ticso@cicely12.cicely.de) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 41A3B43D45; Thu, 1 Sep 2005 13:31:54 +0000 (GMT) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de (cicely5.cicely.de [10.1.1.7]) (authenticated bits=0) by srv1.cosmo-project.de (8.12.10/8.12.10) with ESMTP id j81DVnBS066805 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Thu, 1 Sep 2005 15:31:51 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [10.1.1.14]) by cicely5.cicely.de (8.12.10/8.12.10) with ESMTP id j81DVgqK015176 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Sep 2005 15:31:42 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.12.11/8.12.11) with ESMTP id j81DVfhM004084; Thu, 1 Sep 2005 15:31:41 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.12.11/8.12.11/Submit) id j81DVajl004083; Thu, 1 Sep 2005 15:31:36 +0200 (CEST) (envelope-from ticso) Date: Thu, 1 Sep 2005 15:31:36 +0200 From: Bernd Walter To: "Eygene A. Ryabinkin" Message-ID: <20050901133136.GL3267@cicely12.cicely.de> References: <200508302009.aa99975@nowhere.iedowse.com> <43160334.5000100@samsco.org> <43160943.6030400@samsco.org> <20050901084421.GA840@rea.mbslab.kiae.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050901084421.GA840@rea.mbslab.kiae.ru> X-Operating-System: FreeBSD cicely12.cicely.de 5.2-CURRENT alpha User-Agent: Mutt/1.5.9i X-Spam-Status: No, score=-5.9 required=3.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 X-Spam-Report: * -3.3 ALL_TRUSTED Did not pass through any untrusted hosts * -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% * [score: 0.0000] X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on cicely12.cicely.de Cc: Scott Long , hackers@freebsd.org, Eugene Grosbein , Ian Dowse , freebsd-usb@freebsd.org Subject: Re: Low umass performance with USB 2.0 ports X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2005 13:31:55 -0000 On Thu, Sep 01, 2005 at 12:44:21PM +0400, Eygene A. Ryabinkin wrote: > > Actually, I just peeked inside the Linux EHCI code and it does a dummy > > read immediately after writing to the status register: > > > > /* clear (just) interrupts */ > > writel (status, &ehci->regs->status); > > readl (&ehci->regs->command); /* unblock posted write */ > > > > I wonder if that's the whole trick here. Would someone be willing to > > try the attached patch instead of the one that Ian posted? > Yes, that solved my problem. But the patch (for 5.x) uses different line > numbers: > ----- > --- /sys/dev/usb/ehci.c.orig Thu Sep 1 10:59:51 2005 > +++ /sys/dev/usb/ehci.c Thu Sep 1 10:48:59 2005 > @@ -580,6 +580,7 @@ > return (0); > > EOWRITE4(sc, EHCI_USBSTS, intrs); /* Acknowledge */ > + EOREAD4(sc, EHCI_USBCMD); /* Flush posted writes on PCI */ > sc->sc_bus.intr_context++; > sc->sc_bus.no_intrs++; > if (eintrs & EHCI_STS_IAA) { > ----- > Apart from this the patch works: the writing process still spends much time > in the wdrain state, but no stalls occurs. > > Just a remark: my USB 2.0 controller chip is made by NEC, not VIA. > > For a FAT curiosity: FAT 32 gives 700K/sec and FAT 16 -- 3 Mb/sec. FAT32 vs. FAT16 shouldn't be a difference, but the smaller cluster sizes that you usually get with FAT32 decrease the average transfer size. Basicly you can get around 500-1000 transactions per second over USB, unless interleaving multiple transactions is done. Since msdosfs does no aggregation you can end up with e.g. 512 Byte transactions. 700kB/s points to an FS with 2k cluster size. Currently I'm unshure if umass allows interleaving transactions, but your numbers makes me believe that it does not. -- B.Walter BWCT http://www.bwct.de bernd@bwct.de info@bwct.de From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 1 14:01:12 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 EF0BE16A41F; Thu, 1 Sep 2005 14:01:11 +0000 (GMT) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe07.swip.net [212.247.154.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id 37B8D43D45; Thu, 1 Sep 2005 14:01:10 +0000 (GMT) (envelope-from hselasky@c2i.net) X-T2-Posting-ID: Y1QAsIk9O44SO+J/q9KNyQ== Received: from mp-217-135-60.daxnet.no ([193.217.135.60] verified) by mailfe07.swip.net (CommuniGate Pro SMTP 4.3.4) with ESMTP id 253215240; Thu, 01 Sep 2005 16:01:08 +0200 From: Hans Petter Selasky To: "Eygene A. Ryabinkin" Date: Thu, 1 Sep 2005 16:02:00 +0200 User-Agent: KMail/1.7 References: <200508302009.aa99975@nowhere.iedowse.com> <200508312239.04897.hselasky@c2i.net> <20050901093733.GA915@rea.mbslab.kiae.ru> In-Reply-To: <20050901093733.GA915@rea.mbslab.kiae.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200509011602.03079.hselasky@c2i.net> Cc: freebsd-hackers@freebsd.org, Scott Long , Eugene Grosbein , Ian Dowse , freebsd-usb@freebsd.org Subject: Re: Low umass performance with USB 2.0 ports X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hselasky@c2i.net List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2005 14:01:12 -0000 On Thursday 01 September 2005 11:37, Eygene A. Ryabinkin wrote: > > If Scott's patch doesn't work, could you have tried to install the > > following (compiles on FreeBSD 5/6/7): > > Yes, it also works and does even better work: FAT 32 and FAT 16 > permormance are just the same and there is no additional load as been with > the Scott's patch. > So I definitely would vote for this fix. > > > Download the three files below into a new directory and type > > "make install" (to uninstall type "make deinstall") > > http://home.c2i.net/hselasky/isdn4bsd/privat/usb/Makefile > > http://home.c2i.net/hselasky/isdn4bsd/privat/usb/new_usb_1_5_4.diff.bz2 > > http://home.c2i.net/hselasky/isdn4bsd/privat/usb/new_usb_1_5_4.tar.bz2 > > Can this fix be transformed into the patch? It will be very helpful to the > committers to have in the form of patch. Are there any reasons to make it > in the way you did? I did things like I did it, so I would be saved the work of upgrading my patch every time the source code changes. I am currently working on getting this ported to NetBSD, so maybe the official USB system of FreeBSD can be upgraded without splitting with NetBSD. At the present moment there are too many changes made, so a single patch will not be so good. > Thank you for your work! On Thursday 01 September 2005 14:08, you wrote: > > Yes, it also works and does even better work: FAT 32 and FAT 16 > > permormance are just the same and there is no additional load as been > > with the Scott's patch. Interesting. > > So I definitely would vote for this fix. > > Oops, it seems that this patch also does not work as expected: after some > time of playing with flash card and working with the system it started to > stall as unpatched system, but it freezes the system -- even IP stack was > frozen (I am using DEVICE_POLLING), so I were to remove the flash from the > port -- system was unfrozen and continued to work. So something is still > bad with the USB. I'll try to do some long testing with USB 1.1 -- maybe it > will show the same behaviour after some more time. Do you mean my patch? Maybe you can turn on debugging when the system starts freezing: sysctl hw.usb.debug=15 sysctl hw.usb.umass.debug=-1 sysctl hw.usb.ehci.debug=15 # note: produces alot of output ! Set these variables to zero to turn off debugging. If the system resumes to normal operation when you pull the device plug, it is most likely a timeout in "umass" that takes too long. In the file "/sys/dev/usb/umass.c": Add: sc->timeout = 1000; Before: /* Read the Command Status Wrapper via bulk-in endpoint. */ if (umass_setup_transfer(sc, sc->bulkin_pipe, &sc->csw, UMASS_BBB_CSW_SIZE, 0, next_xfer)) { umass_bbb_reset(sc, STATUS_WIRE_FAILED); return; } See if you get any timeout messages while stressing the system. --HPS From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 1 17:01:22 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 8124816A41F for ; Thu, 1 Sep 2005 17:01:22 +0000 (GMT) (envelope-from SRS0=0g9gYpqP=XD=metro.cx=fbsd@sonologic.nl) Received: from mx1.sonologic.nl (mx1.sonologic.nl [82.94.245.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id B67E543D45 for ; Thu, 1 Sep 2005 17:01:21 +0000 (GMT) (envelope-from SRS0=0g9gYpqP=XD=metro.cx=fbsd@sonologic.nl) Received: from [192.168.3.31] ([212.41.157.237]) (authenticated bits=0) by mx1.sonologic.nl (8.13.3/8.13.3) with ESMTP id j81H126W027573 for ; Thu, 1 Sep 2005 17:01:06 GMT Message-ID: <4317340E.2050208@metro.cx> Date: Thu, 01 Sep 2005 19:02:06 +0200 From: Koen Martens Organization: Sonologic User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050317 Thunderbird/1.0.2 Mnenhy/0.7.2.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Helo-Milter-Authen: gmc@sonologic.nl, fbsd@metro.cx, mx1 Received-SPF: pass (mx1.sonologic.nl: 212.41.157.237 is authenticated by a trusted mechanism) Subject: panic in propagate_priority w/ postgresql under heavy load X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2005 17:01:22 -0000 Hi Hackers, I've had a little chat with neologism on ircnet/#freebsd about this already, and done as he suggested: compile a debug kernel to obtain a stack trace. Anyway, what is happening is that there is a crash when running postgresql 8.0.3 with a very large database and doing heavy queries. Kernel is 5.4-RELEASE-p6 (5.4-RELENG i checked out tuesday a week ago). Kernel conf is down below. Here is the message i get on the console: ==================== kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 06 fault virtual address = 0x24 fault code = supervisor read, page not present instruction pointer = 0x8:0xc050cff7 stack pointer = 0x10:0xe99c2b0c frame pointer = 0x10:0xe99c2b20 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = resume, IOPL = 0 current process = 4571 (postgres) ==================== It has been a postgres process in all of the observed cases. I've looked it up with gdk on my kernel.debug, here's what i get: ===================== yin# gdb kernel.debug GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"... (gdb) l *propagate_priority+0x7f 0xc050cff7 is in propagate_priority (/usr/src/sys/kern/subr_turnstile.c:245). 240 /* 241 * Pick up the lock that td is blocked on. 242 */ 243 ts = td->td_blocked; 244 MPASS(ts != NULL); 245 tc = TC_LOOKUP(ts->ts_lockobj); 246 mtx_lock_spin(&tc->tc_lock); 247 248 /* 249 * This thread may not be blocked on this turnstile anymore (gdb) ===================== So the next thing you'll ask for is a stack trace, but i haven't been able to obtain one. According to the freebsd handbook (http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-gdb.html) there should be a core dump in /var/crash, but there is none and the handbook chapter seems outdated anyway judging by it mentioning kgdb... Anyway, it seems the dump should've gone to the swap partition, but i'm into multi-user mode again so i guess i'll have to wait for another panic to obtain it? I'm not very knowledgeable about the freebsd kernel internals (yet), so i'm not sure what could be wrong here.. I hope some of you can provide some insight, and ideally a fix :) ======================[ kernel config: # # GENERIC -- Generic kernel configuration file for FreeBSD/i386 # # For more information on this file, please read the handbook section on # Kernel Configuration Files: # # http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the ../../conf/NOTES and NOTES files. # If you are in doubt as to the purpose or necessity of a line, check first # in NOTES. # # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.413.2.13 2005/04/02 16:37:58 scottl Exp $ machine i386 cpu I486_CPU cpu I586_CPU cpu I686_CPU ident YIN-YANG # debug options WITNESS options KDB options DDB # makeoptions DEBUG=-g # debug # To statically compile in device wiring instead of /boot/device.hints #hints "GENERIC.hints" # Default places to look for devices. options SCHED_4BSD # 4BSD scheduler options INET # InterNETworking options INET6 # IPv6 communications protocols options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options MD_ROOT # MD is a potential root device options NFSCLIENT # Network Filesystem Client options NFSSERVER # Network Filesystem Server options NFS_ROOT # NFS usable as /, requires NFSCLIENT options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS # Pseudo-filesystem framework options GEOM_GPT # GUID Partition Tables. options COMPAT_43 # Compatible with BSD 4.3 [KEEP THIS!] options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options SCSI_DELAY=15000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options KBD_INSTALL_CDEV # install a CDEV entry in /dev options AHC_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~128k to driver. options AHD_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~215k to driver. options ADAPTIVE_GIANT # Giant mutex is adaptive. options IPFILTER options IPFILTER_LOG options IPFILTER_DEFAULT_BLOCK options IPFILTER options IPFILTER_LOG options IPFIREWALL #firewall options IPFIREWALL_VERBOSE #enable logging to syslogd(8) options IPFIREWALL_FORWARD #enable transparent proxy support options IPFIREWALL_VERBOSE_LIMIT=10 #limit verbosity options IPFIREWALL_DEFAULT_TO_ACCEPT #allow everything by default options IPV6FIREWALL #firewall for IPv6 options IPV6FIREWALL_VERBOSE options IPV6FIREWALL_VERBOSE_LIMIT=10 options IPV6FIREWALL_DEFAULT_TO_ACCEPT options SHMMAXPGS=262144 options SHMSEG=512 options SHMMNI=512 options SEMMNI=512 options SEMMNS=1024 options SEMMNU=512 options SEMMAP=512 options NMBCLUSTERS=32768 device apic # I/O APIC options SMP # Symmetric MultiProcessor Kernel # Bus support. Do not remove isa, even if you have no isa slots device isa device eisa device pci # Floppy drives device fdc # ATA and ATAPI devices device ata device atadisk # ATA disk drives device ataraid # ATA RAID drives device atapicd # ATAPI CDROM drives #device atapifd # ATAPI floppy drives #device atapist # ATAPI tape drives options ATA_STATIC_ID # Static device numbering # SCSI Controllers #device ahb # EISA AHA1742 family #device ahc # AHA2940 and onboard AIC7xxx devices #device ahd # AHA39320/29320 and onboard AIC79xx devices #device amd # AMD 53C974 (Tekram DC-390(T)) #device isp # Qlogic family #device mpt # LSI-Logic MPT-Fusion ##device ncr # NCR/Symbios Logic #device sym # NCR/Symbios Logic (newer chipsets + those of `ncr') #device trm # Tekram DC395U/UW/F DC315U adapters #device adv # Advansys SCSI adapters #device adw # Advansys wide SCSI adapters #device aha # Adaptec 154x SCSI adapters #device aic # Adaptec 15[012]x SCSI adapters, AIC-6[23]60. #device bt # Buslogic/Mylex MultiMaster SCSI adapters #device ncv # NCR 53C500 #device nsp # Workbit Ninja SCSI-3 #device stg # TMC 18C30/18C50 # SCSI peripherals device scbus # SCSI bus (required for SCSI) device ch # SCSI media changers device da # Direct Access (disks) device sa # Sequential Access (tape etc) device cd # CD device pass # Passthrough device (direct SCSI access) device ses # SCSI Environmental Services (and SAF-TE) # RAID controllers interfaced to the SCSI subsystem #device amr # AMI MegaRAID #device arcmsr # Areca SATA II RAID #device asr # DPT SmartRAID V, VI and Adaptec SCSI RAID #device ciss # Compaq Smart RAID 5* #device dpt # DPT Smartcache III, IV - See NOTES for options #device hptmv # Highpoint RocketRAID 182x #device iir # Intel Integrated RAID #device ips # IBM (Adaptec) ServeRAID #device mly # Mylex AcceleRAID/eXtremeRAID device twa # 3ware 9000 series PATA/SATA RAID # RAID controllers #device aac # Adaptec FSA RAID #device aacp # SCSI passthrough for aac (requires CAM) #device ida # Compaq Smart RAID #device mlx # Mylex DAC960 family #device pst # Promise Supertrak SX6000 device twe # 3ware ATA RAID # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard device psm # PS/2 mouse device vga # VGA video card driver #device splash # Splash screen and screen saver support # syscons is the default console driver, resembling an SCO console device sc # Enable this for the pcvt (VT220 compatible) console driver #device vt #options XSERVER # support for X server on a vt console #options FAT_CURSOR # start with block cursor device agp # support several AGP chipsets # Floating point support - do not disable. device npx # Power management support (see NOTES for more options) #device apm # Add suspend/resume support for the i8254. device pmtimer # PCCARD (PCMCIA) support # PCMCIA and cardbus bridge support #device cbb # cardbus (yenta) bridge #device pccard # PC Card (16-bit) bus #device cardbus # CardBus (32-bit) bus # Serial (COM) ports device sio # 8250, 16[45]50 based serial ports # Parallel port device ppc device ppbus # Parallel port bus (required) device lpt # Printer device plip # TCP/IP over parallel device ppi # Parallel port interface device #device vpo # Requires scbus and da # If you've got a "dumb" serial or parallel PCI card that is # supported by the puc(4) glue driver, uncomment the following # line to enable it (connects to the sio and/or ppc drivers): #device puc # PCI Ethernet NICs. #device de # DEC/Intel DC21x4x (``Tulip'') device em # Intel PRO/1000 adapter Gigabit Ethernet Card #device ixgb # Intel PRO/10GbE Ethernet Card #device txp # 3Com 3cR990 (``Typhoon'') #device vx # 3Com 3c590, 3c595 (``Vortex'') # PCI Ethernet NICs that use the common MII bus controller code. # NOTE: Be sure to keep the 'device miibus' line in order to use these NICs! device miibus # MII bus support #device bfe # Broadcom BCM440x 10/100 Ethernet #device bge # Broadcom BCM570xx Gigabit Ethernet #device dc # DEC/Intel 21143 and various workalikes device fxp # Intel EtherExpress PRO/100B (82557, 82558) #device lge # Level 1 LXT1001 gigabit ethernet #device nge # NatSemi DP83820 gigabit ethernet #evice pcn # AMD Am79C97x PCI 10/100 (precedence over 'lnc') #device re # RealTek 8139C+/8169/8169S/8110S #device rl # RealTek 8129/8139 #device sf # Adaptec AIC-6915 (``Starfire'') #device sis # Silicon Integrated Systems SiS 900/SiS 7016 #device sk # SysKonnect SK-984x & SK-982x gigabit Ethernet #device ste # Sundance ST201 (D-Link DFE-550TX) #device ti # Alteon Networks Tigon I/II gigabit Ethernet #device tl # Texas Instruments ThunderLAN #device tx # SMC EtherPower II (83c170 ``EPIC'') #device vge # VIA VT612x gigabit ethernet #device vr # VIA Rhine, Rhine II #device wb # Winbond W89C840F #device xl # 3Com 3c90x (``Boomerang'', ``Cyclone'') # ISA Ethernet NICs. pccard NICs included. #device cs # Crystal Semiconductor CS89x0 NIC # 'device ed' requires 'device miibus' #device ed # NE[12]000, SMC Ultra, 3c503, DS8390 cards #device ex # Intel EtherExpress Pro/10 and Pro/10+ #device ep # Etherlink III based cards #device fe # Fujitsu MB8696x based cards #device ie # EtherExpress 8/16, 3C507, StarLAN 10 etc. #device lnc # NE2100, NE32-VL Lance Ethernet cards #device sn # SMC's 9000 series of Ethernet chips #device xe # Xircom pccard Ethernet # ISA devices that use the old ISA shims #device le # Wireless NIC cards #device wlan # 802.11 support #device an # Aironet 4500/4800 802.11 wireless NICs. #device awi # BayStack 660 and others #device wi # WaveLAN/Intersil/Symbol 802.11 wireless NICs. #device wl # Older non 802.11 Wavelan wireless NIC. # Pseudo devices. device loop # Network loopback device mem # Memory and kernel memory devices device io # I/O device device random # Entropy device device ether # Ethernet support device sl # Kernel SLIP device ppp # Kernel PPP device tun # Packet tunnel. device pty # Pseudo-ttys (telnet etc) device md # Memory "disks" device gif # IPv6 and IPv4 tunneling device faith # IPv6-to-IPv4 relaying (translation) # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! # Note that 'bpf' is required for DHCP. device bpf # Berkeley packet filter # USB support #device uhci # UHCI PCI->USB interface #device ohci # OHCI PCI->USB interface #device ehci # EHCI PCI->USB interface (USB 2.0) #device usb # USB Bus (required) #device udbp # USB Double Bulk Pipe devices #device ugen # Generic #device uhid # "Human Interface Devices" #device ukbd # Keyboard #device ulpt # Printer #device umass # Disks/Mass storage - Requires scbus and da #device ums # Mouse #device urio # Diamond Rio 500 MP3 player #device uscanner # Scanners # USB Ethernet, requires mii #device aue # ADMtek USB Ethernet #device axe # ASIX Electronics USB Ethernet #device cdce # Generic USB over Ethernet #device cue # CATC USB Ethernet #device kue # Kawasaki LSI USB Ethernet #device rue # RealTek RTL8150 USB Ethernet # FireWire support #device firewire # FireWire bus code #device sbp # SCSI over FireWire (Requires scbus and da) #device fwe # Ethernet over FireWire (non-standard!) -- K.F.J. Martens, Sonologic, http://www.sonologic.nl/ Networking, hosting, embedded systems, unix, artificial intelligence. Public PGP key: http://www.metro.cx/pubkey-gmc.asc Wondering about the funny attachment your mail program can't read? Visit http://www.openpgp.org/ -- K.F.J. Martens, Sonologic, http://www.sonologic.nl/ Networking, hosting, embedded systems, unix, artificial intelligence. Public PGP key: http://www.metro.cx/pubkey-gmc.asc Wondering about the funny attachment your mail program can't read? Visit http://www.openpgp.org/ From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 1 17:49:59 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 79A9516A41F for ; Thu, 1 Sep 2005 17:49:59 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 11D8843D45 for ; Thu, 1 Sep 2005 17:49:58 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from [10.50.40.201] (Not Verified[10.50.40.201]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Thu, 01 Sep 2005 14:05:19 -0400 From: John Baldwin To: freebsd-hackers@freebsd.org Date: Thu, 1 Sep 2005 13:48:49 -0400 User-Agent: KMail/1.8 References: <4317340E.2050208@metro.cx> In-Reply-To: <4317340E.2050208@metro.cx> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200509011348.50159.jhb@FreeBSD.org> Cc: Koen Martens Subject: Re: panic in propagate_priority w/ postgresql under heavy load X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2005 17:49:59 -0000 On Thursday 01 September 2005 01:02 pm, Koen Martens wrote: > Hi Hackers, > > I've had a little chat with neologism on ircnet/#freebsd about this > already, and done as he suggested: compile a debug kernel to obtain > a stack trace. Can you reproduce it with a kernel that has INVARIANTS and INVARIANT_SUPPORT on? I see that you had WITNESS on, can you check to see if there were any witness messages about sleepign with non-sleepable locks held before the crash? > Anyway, what is happening is that there is a crash when running > postgresql 8.0.3 with a very large database and doing heavy queries. > > Kernel is 5.4-RELEASE-p6 (5.4-RELENG i checked out tuesday a week > ago). Kernel conf is down below. > > Here is the message i get on the console: > > ==================== > kernel trap 12 with interrupts disabled > > > Fatal trap 12: page fault while in kernel mode > cpuid = 1; apic id = 06 > fault virtual address = 0x24 > fault code = supervisor read, page not present > instruction pointer = 0x8:0xc050cff7 > stack pointer = 0x10:0xe99c2b0c > frame pointer = 0x10:0xe99c2b20 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = resume, IOPL = 0 > current process = 4571 (postgres) > ==================== > > It has been a postgres process in all of the observed cases. > > I've looked it up with gdk on my kernel.debug, here's what i get: > > ===================== > yin# gdb kernel.debug > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and > you are > welcome to change it and/or distribute copies of it under certain > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for > details. > This GDB was configured as "i386-marcel-freebsd"... > (gdb) l *propagate_priority+0x7f > 0xc050cff7 is in propagate_priority > (/usr/src/sys/kern/subr_turnstile.c:245). > 240 /* > 241 * Pick up the lock that td is blocked on. > 242 */ > 243 ts = td->td_blocked; > 244 MPASS(ts != NULL); > 245 tc = TC_LOOKUP(ts->ts_lockobj); > 246 mtx_lock_spin(&tc->tc_lock); > 247 > 248 /* > 249 * This thread may not be blocked on this > turnstile anymore > (gdb) > ===================== > > > So the next thing you'll ask for is a stack trace, but i haven't > been able to obtain one. According to the freebsd handbook > (http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerne >ldebug-gdb.html) there should be a core dump in /var/crash, but there is > none and the handbook chapter seems outdated anyway judging by it > mentioning kgdb... > > Anyway, it seems the dump should've gone to the swap partition, but > i'm into multi-user mode again so i guess i'll have to wait for > another panic to obtain it? > > I'm not very knowledgeable about the freebsd kernel internals (yet), > so i'm not sure what could be wrong here.. I hope some of you can > provide some insight, and ideally a fix :) > > ======================[ kernel config: > > # > # GENERIC -- Generic kernel configuration file for FreeBSD/i386 > # > # For more information on this file, please read the handbook section on > # Kernel Configuration Files: > # > # > http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-conf >ig.html # > # The handbook is also available locally in /usr/share/doc/handbook > # if you've installed the doc distribution, otherwise always see the > # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the > # latest information. > # > # An exhaustive list of options and more detailed explanations of the > # device lines is also present in the ../../conf/NOTES and NOTES files. > # If you are in doubt as to the purpose or necessity of a line, > check first > # in NOTES. > # > # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.413.2.13 2005/04/02 > 16:37:58 scottl Exp $ > > machine i386 > cpu I486_CPU > cpu I586_CPU > cpu I686_CPU > ident YIN-YANG > > # debug > options WITNESS > options KDB > options DDB > # > makeoptions DEBUG=-g > # debug > > > # To statically compile in device wiring instead of /boot/device.hints > #hints "GENERIC.hints" # Default places to look for devices. > > options SCHED_4BSD # 4BSD scheduler > options INET # InterNETworking > options INET6 # IPv6 communications protocols > options FFS # Berkeley Fast Filesystem > options SOFTUPDATES # Enable FFS soft updates support > options UFS_ACL # Support for access control lists > options UFS_DIRHASH # Improve performance on big directories > options MD_ROOT # MD is a potential root device > options NFSCLIENT # Network Filesystem Client > options NFSSERVER # Network Filesystem Server > options NFS_ROOT # NFS usable as /, requires NFSCLIENT > options MSDOSFS # MSDOS Filesystem > options CD9660 # ISO 9660 Filesystem > options PROCFS # Process filesystem (requires PSEUDOFS) > options PSEUDOFS # Pseudo-filesystem framework > options GEOM_GPT # GUID Partition Tables. > options COMPAT_43 # Compatible with BSD 4.3 [KEEP THIS!] > options COMPAT_FREEBSD4 # Compatible with FreeBSD4 > options SCSI_DELAY=15000 # Delay (in ms) before probing SCSI > options KTRACE # ktrace(1) support > options SYSVSHM # SYSV-style shared memory > options SYSVMSG # SYSV-style message queues > options SYSVSEM # SYSV-style semaphores > options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time > extensions > options KBD_INSTALL_CDEV # install a CDEV entry in /dev > options AHC_REG_PRETTY_PRINT # Print register bitfields in debug > # output. Adds ~128k to driver. > options AHD_REG_PRETTY_PRINT # Print register bitfields in debug > # output. Adds ~215k to driver. > options ADAPTIVE_GIANT # Giant mutex is adaptive. > > > options IPFILTER > options IPFILTER_LOG > options IPFILTER_DEFAULT_BLOCK > > options IPFILTER > options IPFILTER_LOG > > options IPFIREWALL #firewall > options IPFIREWALL_VERBOSE #enable logging to syslogd(8) > options IPFIREWALL_FORWARD #enable transparent proxy > support > options IPFIREWALL_VERBOSE_LIMIT=10 #limit verbosity > options IPFIREWALL_DEFAULT_TO_ACCEPT #allow everything by > default > options IPV6FIREWALL #firewall for IPv6 > options IPV6FIREWALL_VERBOSE > options IPV6FIREWALL_VERBOSE_LIMIT=10 > options IPV6FIREWALL_DEFAULT_TO_ACCEPT > > options SHMMAXPGS=262144 > options SHMSEG=512 > options SHMMNI=512 > options SEMMNI=512 > options SEMMNS=1024 > options SEMMNU=512 > options SEMMAP=512 > options NMBCLUSTERS=32768 > > device apic # I/O APIC > > options SMP # Symmetric MultiProcessor > Kernel > > # Bus support. Do not remove isa, even if you have no isa slots > device isa > device eisa > device pci > > # Floppy drives > device fdc > > # ATA and ATAPI devices > device ata > device atadisk # ATA disk drives > device ataraid # ATA RAID drives > device atapicd # ATAPI CDROM drives > #device atapifd # ATAPI floppy drives > #device atapist # ATAPI tape drives > options ATA_STATIC_ID # Static device numbering > > # SCSI Controllers > #device ahb # EISA AHA1742 family > #device ahc # AHA2940 and onboard AIC7xxx devices > #device ahd # AHA39320/29320 and onboard AIC79xx devices > #device amd # AMD 53C974 (Tekram DC-390(T)) > #device isp # Qlogic family > #device mpt # LSI-Logic MPT-Fusion > ##device ncr # NCR/Symbios Logic > #device sym # NCR/Symbios Logic (newer chipsets + those of `ncr') > #device trm # Tekram DC395U/UW/F DC315U adapters > > #device adv # Advansys SCSI adapters > #device adw # Advansys wide SCSI adapters > #device aha # Adaptec 154x SCSI adapters > #device aic # Adaptec 15[012]x SCSI adapters, AIC-6[23]60. > #device bt # Buslogic/Mylex MultiMaster SCSI adapters > > #device ncv # NCR 53C500 > #device nsp # Workbit Ninja SCSI-3 > #device stg # TMC 18C30/18C50 > > # SCSI peripherals > device scbus # SCSI bus (required for SCSI) > device ch # SCSI media changers > device da # Direct Access (disks) > device sa # Sequential Access (tape etc) > device cd # CD > device pass # Passthrough device (direct SCSI access) > device ses # SCSI Environmental Services (and SAF-TE) > > # RAID controllers interfaced to the SCSI subsystem > #device amr # AMI MegaRAID > #device arcmsr # Areca SATA II RAID > #device asr # DPT SmartRAID V, VI and Adaptec SCSI RAID > #device ciss # Compaq Smart RAID 5* > #device dpt # DPT Smartcache III, IV - See NOTES for options > #device hptmv # Highpoint RocketRAID 182x > #device iir # Intel Integrated RAID > #device ips # IBM (Adaptec) ServeRAID > #device mly # Mylex AcceleRAID/eXtremeRAID > device twa # 3ware 9000 series PATA/SATA RAID > > # RAID controllers > #device aac # Adaptec FSA RAID > #device aacp # SCSI passthrough for aac (requires CAM) > #device ida # Compaq Smart RAID > #device mlx # Mylex DAC960 family > #device pst # Promise Supertrak SX6000 > device twe # 3ware ATA RAID > > # atkbdc0 controls both the keyboard and the PS/2 mouse > device atkbdc # AT keyboard controller > device atkbd # AT keyboard > device psm # PS/2 mouse > > device vga # VGA video card driver > > #device splash # Splash screen and screen saver support > > # syscons is the default console driver, resembling an SCO console > device sc > > # Enable this for the pcvt (VT220 compatible) console driver > #device vt > #options XSERVER # support for X server on a vt console > #options FAT_CURSOR # start with block cursor > > device agp # support several AGP chipsets > > # Floating point support - do not disable. > device npx > > # Power management support (see NOTES for more options) > #device apm > # Add suspend/resume support for the i8254. > device pmtimer > > # PCCARD (PCMCIA) support > # PCMCIA and cardbus bridge support > #device cbb # cardbus (yenta) bridge > #device pccard # PC Card (16-bit) bus > #device cardbus # CardBus (32-bit) bus > > # Serial (COM) ports > device sio # 8250, 16[45]50 based serial ports > > # Parallel port > device ppc > device ppbus # Parallel port bus (required) > device lpt # Printer > device plip # TCP/IP over parallel > device ppi # Parallel port interface device > #device vpo # Requires scbus and da > > # If you've got a "dumb" serial or parallel PCI card that is > # supported by the puc(4) glue driver, uncomment the following > # line to enable it (connects to the sio and/or ppc drivers): > #device puc > > # PCI Ethernet NICs. > #device de # DEC/Intel DC21x4x (``Tulip'') > device em # Intel PRO/1000 adapter Gigabit Ethernet Card > #device ixgb # Intel PRO/10GbE Ethernet Card > #device txp # 3Com 3cR990 (``Typhoon'') > #device vx # 3Com 3c590, 3c595 (``Vortex'') > > # PCI Ethernet NICs that use the common MII bus controller code. > # NOTE: Be sure to keep the 'device miibus' line in order to use > these NICs! > device miibus # MII bus support > #device bfe # Broadcom BCM440x 10/100 Ethernet > #device bge # Broadcom BCM570xx Gigabit Ethernet > #device dc # DEC/Intel 21143 and various workalikes > device fxp # Intel EtherExpress PRO/100B (82557, 82558) > #device lge # Level 1 LXT1001 gigabit ethernet > #device nge # NatSemi DP83820 gigabit ethernet > #evice pcn # AMD Am79C97x PCI 10/100 (precedence over 'lnc') > #device re # RealTek 8139C+/8169/8169S/8110S > #device rl # RealTek 8129/8139 > #device sf # Adaptec AIC-6915 (``Starfire'') > #device sis # Silicon Integrated Systems SiS 900/SiS 7016 > #device sk # SysKonnect SK-984x & SK-982x gigabit Ethernet > #device ste # Sundance ST201 (D-Link DFE-550TX) > #device ti # Alteon Networks Tigon I/II gigabit Ethernet > #device tl # Texas Instruments ThunderLAN > #device tx # SMC EtherPower II (83c170 ``EPIC'') > #device vge # VIA VT612x gigabit ethernet > #device vr # VIA Rhine, Rhine II > #device wb # Winbond W89C840F > #device xl # 3Com 3c90x (``Boomerang'', ``Cyclone'') > > # ISA Ethernet NICs. pccard NICs included. > #device cs # Crystal Semiconductor CS89x0 NIC > # 'device ed' requires 'device miibus' > #device ed # NE[12]000, SMC Ultra, 3c503, DS8390 cards > #device ex # Intel EtherExpress Pro/10 and Pro/10+ > #device ep # Etherlink III based cards > #device fe # Fujitsu MB8696x based cards > #device ie # EtherExpress 8/16, 3C507, StarLAN 10 etc. > #device lnc # NE2100, NE32-VL Lance Ethernet cards > #device sn # SMC's 9000 series of Ethernet chips > #device xe # Xircom pccard Ethernet > > # ISA devices that use the old ISA shims > #device le > > # Wireless NIC cards > #device wlan # 802.11 support > #device an # Aironet 4500/4800 802.11 wireless NICs. > #device awi # BayStack 660 and others > #device wi # WaveLAN/Intersil/Symbol 802.11 wireless NICs. > #device wl # Older non 802.11 Wavelan wireless NIC. > > # Pseudo devices. > device loop # Network loopback > device mem # Memory and kernel memory devices > device io # I/O device > device random # Entropy device > device ether # Ethernet support > device sl # Kernel SLIP > device ppp # Kernel PPP > device tun # Packet tunnel. > device pty # Pseudo-ttys (telnet etc) > device md # Memory "disks" > device gif # IPv6 and IPv4 tunneling > device faith # IPv6-to-IPv4 relaying (translation) > > # The `bpf' device enables the Berkeley Packet Filter. > # Be aware of the administrative consequences of enabling this! > # Note that 'bpf' is required for DHCP. > device bpf # Berkeley packet filter > > # USB support > #device uhci # UHCI PCI->USB interface > #device ohci # OHCI PCI->USB interface > #device ehci # EHCI PCI->USB interface (USB 2.0) > #device usb # USB Bus (required) > #device udbp # USB Double Bulk Pipe devices > #device ugen # Generic > #device uhid # "Human Interface Devices" > #device ukbd # Keyboard > #device ulpt # Printer > #device umass # Disks/Mass storage - Requires scbus and da > #device ums # Mouse > #device urio # Diamond Rio 500 MP3 player > #device uscanner # Scanners > # USB Ethernet, requires mii > #device aue # ADMtek USB Ethernet > #device axe # ASIX Electronics USB Ethernet > #device cdce # Generic USB over Ethernet > #device cue # CATC USB Ethernet > #device kue # Kawasaki LSI USB Ethernet > #device rue # RealTek RTL8150 USB Ethernet > > # FireWire support > #device firewire # FireWire bus code > #device sbp # SCSI over FireWire (Requires scbus and da) > #device fwe # Ethernet over FireWire (non-standard!) > > > -- > K.F.J. Martens, Sonologic, http://www.sonologic.nl/ Networking, > hosting, embedded systems, unix, artificial intelligence. Public PGP > key: http://www.metro.cx/pubkey-gmc.asc Wondering about the funny > attachment your mail program can't read? Visit http://www.openpgp.org/ -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 1 21:18:41 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 F1AC716A41F for ; Thu, 1 Sep 2005 21:18:41 +0000 (GMT) (envelope-from dimitry@andric.com) Received: from tensor.xs4all.nl (tensor.xs4all.nl [194.109.160.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7EAF843D45 for ; Thu, 1 Sep 2005 21:18:41 +0000 (GMT) (envelope-from dimitry@andric.com) Received: from kilgore.dim (kilgore.dim [192.168.0.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.xs4all.nl (Postfix) with ESMTP id B5812B80C; Thu, 1 Sep 2005 23:18:39 +0200 (CEST) Date: Thu, 1 Sep 2005 23:18:02 +0200 From: Dimitry Andric X-Mailer: The Bat! (v3.60.05 Forerunner (Beta)) Professional X-Priority: 3 (Normal) Message-ID: <614518786.20050901231802@andric.com> To: Koen Martens In-Reply-To: <4317340E.2050208@metro.cx> References: <4317340E.2050208@metro.cx> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="----------D515224B21B865FA" Cc: freebsd-hackers@freebsd.org Subject: Re: panic in propagate_priority w/ postgresql under heavy load X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Dimitry Andric List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2005 21:18:42 -0000 ------------D515224B21B865FA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable On 2005-09-01 at 19:02:06 Koen Martens wrote: > Anyway, it seems the dump should've gone to the swap partition, but > i'm into multi-user mode again so i guess i'll have to wait for > another panic to obtain it? Yes. By now, if any dump was ever written to your swap partition, it will most probably have been overwritten by your heavy postgres activity. :) In RELENG_6, the dump device is chosen automagically during boot by /etc/rc.d/dumpon, but this is (alas) not the case in RELENG_5_x, so you'll have to manually specify it in /etc/rc.conf, i.e: dumpdev=3D/dev/ad0s1b Then make sure you have enough space in /var/crash, and try to reproduce your panic... Also, I think I read somewhere that there used to be problems with dumping and 3Ware RAID cards (you seem to be using one according to your kernel config, but you apparently didn't post a dmesg). However, it looks like revision 1.22.2.1 of src/sys/dev/twe/twe.c fixed that: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/twe/twe.c?rev=3D1.22.2.1&= content-type=3Dtext/x-cvsweb-markup Just to be sure, can you check if you got this version of twe.c, or 1.22.2.2 (which seems to be the RELENG_5_4 version, and thus it should be fixed). ------------D515224B21B865FA Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: GnuPG v1.4.1 (MingW32) iD8DBQFDF3AKsF6jCi4glqMRAvehAKC3nZZuUOEsE2ullNpx2iyqDdkTDACgokuY s7Uxb7EkItL3ksJQtdRZMXk= =qO+V -----END PGP MESSAGE----- ------------D515224B21B865FA-- From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 1 22:03:10 2005 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.org 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 A973316A48C; Thu, 1 Sep 2005 22:03:10 +0000 (GMT) (envelope-from SRS0=0g9gYpqP=XD=metro.cx=fbsd@sonologic.nl) Received: from mx1.sonologic.nl (mx1.sonologic.nl [82.94.245.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1B9D243D45; Thu, 1 Sep 2005 22:03:09 +0000 (GMT) (envelope-from SRS0=0g9gYpqP=XD=metro.cx=fbsd@sonologic.nl) Received: from [192.168.3.31] ([212.41.157.237]) (authenticated bits=0) by mx1.sonologic.nl (8.13.3/8.13.3) with ESMTP id j81M2xgr041953; Thu, 1 Sep 2005 22:03:04 GMT Message-ID: <43177AD3.7070308@metro.cx> Date: Fri, 02 Sep 2005 00:04:03 +0200 From: Koen Martens Organization: Sonologic User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050317 Thunderbird/1.0.2 Mnenhy/0.7.2.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Baldwin References: <4317340E.2050208@metro.cx> <200509011348.50159.jhb@FreeBSD.org> In-Reply-To: <200509011348.50159.jhb@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Helo-Milter-Authen: gmc@sonologic.nl, fbsd@metro.cx, mx1 Received-SPF: pass (mx1.sonologic.nl: 212.41.157.237 is authenticated by a trusted mechanism) Cc: freebsd-hackers@FreeBSD.org Subject: Re: panic in propagate_priority w/ postgresql under heavy load X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2005 22:03:11 -0000 John Baldwin wrote: > On Thursday 01 September 2005 01:02 pm, Koen Martens wrote: > >>I've had a little chat with neologism on ircnet/#freebsd about this >>already, and done as he suggested: compile a debug kernel to obtain >>a stack trace. > > Can you reproduce it with a kernel that has INVARIANTS and INVARIANT_SUPPORT > on? I see that you had WITNESS on, can you check to see if there were any > witness messages about sleepign with non-sleepable locks held before the > crash? I will do this when I get back. I did a grep -i on witness in the console log but this did not turn up anything suspicious (exact output pasted below). Also, i checked again the logs right before the crashes, nothing special output to console before the Kernel trap 12.. voltaire# grep -i witness yin.log WARNING: WITNESS option enabled, expect reduced performance. witness_get: witness exhausted WARNING: WITNESS option enabled, expect reduced performance. witness_get: witness exhausted Gr, Koen -- K.F.J. Martens, Sonologic, http://www.sonologic.nl/ Networking, hosting, embedded systems, unix, artificial intelligence. Public PGP key: http://www.metro.cx/pubkey-gmc.asc Wondering about the funny attachment your mail program can't read? Visit http://www.openpgp.org/ From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 1 22:09:52 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 C186E16A41F for ; Thu, 1 Sep 2005 22:09:52 +0000 (GMT) (envelope-from SRS0=0g9gYpqP=XD=metro.cx=fbsd@sonologic.nl) Received: from mx1.sonologic.nl (mx1.sonologic.nl [82.94.245.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1FC4F43D49 for ; Thu, 1 Sep 2005 22:09:49 +0000 (GMT) (envelope-from SRS0=0g9gYpqP=XD=metro.cx=fbsd@sonologic.nl) Received: from [192.168.3.31] ([212.41.157.237]) (authenticated bits=0) by mx1.sonologic.nl (8.13.3/8.13.3) with ESMTP id j81M9bn8042127; Thu, 1 Sep 2005 22:09:41 GMT Message-ID: <43177C61.9090601@metro.cx> Date: Fri, 02 Sep 2005 00:10:41 +0200 From: Koen Martens Organization: Sonologic User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050317 Thunderbird/1.0.2 Mnenhy/0.7.2.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dimitry Andric References: <4317340E.2050208@metro.cx> <614518786.20050901231802@andric.com> In-Reply-To: <614518786.20050901231802@andric.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Helo-Milter-Authen: gmc@sonologic.nl, fbsd@metro.cx, mx1 Received-SPF: pass (mx1.sonologic.nl: 212.41.157.237 is authenticated by a trusted mechanism) Cc: freebsd-hackers@freebsd.org Subject: Re: panic in propagate_priority w/ postgresql under heavy load X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2005 22:09:53 -0000 Hi Dim, Dimitry Andric wrote: > On 2005-09-01 at 19:02:06 Koen Martens wrote: > >>Anyway, it seems the dump should've gone to the swap partition, but >>i'm into multi-user mode again so i guess i'll have to wait for >>another panic to obtain it? > > In RELENG_6, the dump device is chosen automagically during boot by > /etc/rc.d/dumpon, but this is (alas) not the case in RELENG_5_x, so > you'll have to manually specify it in /etc/rc.conf, i.e: > > dumpdev=/dev/ad0s1b > > Then make sure you have enough space in /var/crash, and try to > reproduce your panic... Ok, i get it.. When it reboots it detects a dump on the swap partition and dd's that to /var/crash.. Which has plenty of free space on the particular box, 59 gigs ought to be enough for everyone :) > Also, I think I read somewhere that there used to be problems with > dumping and 3Ware RAID cards (you seem to be using one according to > your kernel config, but you apparently didn't post a dmesg). You're right, dmesg included below. > However, > it looks like revision 1.22.2.1 of src/sys/dev/twe/twe.c fixed that: > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/twe/twe.c?rev=1.22.2.1&content-type=text/x-cvsweb-markup > > Just to be sure, can you check if you got this version of twe.c, or > 1.22.2.2 (which seems to be the RELENG_5_4 version, and thus it should > be fixed). * $FreeBSD: src/sys/dev/twe/twe.c,v 1.22.2.2 2005/02/18 18:42:16 vkashyap Exp $ (nice wrapping, i think you get the idea :) dmesg: Copyright (c) 1992-2005 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.4-RELEASE-p6 #1: Thu Sep 1 14:06:03 CEST 2005 root@yin.sonologic.nl:/usr/obj/usr/src/sys/yin-yang-5.4 WARNING: WITNESS option enabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(TM) CPU 3.06GHz (3056.50-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf29 Stepping = 9 Features=0xbfebfbff Hyperthreading: 2 logical CPUs real memory = 2146959360 (2047 MB) avail memory = 2095415296 (1998 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 6 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard ioapic2 irqs 48-71 on motherboard npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 cpu0: on acpi0 cpu1: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: at device 0.1 (no driver attached) pcib1: at device 2.0 on pci0 pci1: on pcib1 pci1: at device 28.0 (no driver attached) pcib2: at device 29.0 on pci1 pci2: on pcib2 pci1: at device 30.0 (no driver attached) pcib3: at device 31.0 on pci1 pci3: on pcib3 3ware device driver for 9000 series storage controllers, version: 2.50.02.012 twa0: <3ware 9000 series Storage Controller> port 0x7000-0x70ff mem 0xfd800000-0xfdffffff,0xfb200000-0xfb2000ff irq 48 at device 1.0 on pci3 twa0: 4 ports, Firmware FE9X 2.02.00.008, BIOS BE9X 2.02.01.037 pci0: at device 2.1 (no driver attached) pcib4: at device 30.0 on pci0 pci4: on pcib4 pci4: at device 3.0 (no driver attached) fxp0: port 0x8400-0x843f mem 0xfb300000-0xfb31ffff,0xfb341000-0xfb341fff irq 20 at device 4.0 on pci4 miibus0: on fxp0 inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: Ethernet address: 00:02:b3:d8:8a:b5 em0: port 0x8440-0x847f mem 0xfb320000-0xfb33ffff irq 23 at device 5.0 on pci4 em0: Ethernet address: 00:02:b3:d8:8b:05 em0: Speed:N/A Duplex:N/A isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x6c60-0x6c6f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 31.1 on pci0 ata0: channel #0 on atapci0 ata1: channel #1 on atapci0 pci0: at device 31.3 (no driver attached) acpi_button0: on acpi0 atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 fdc0: port 0x3f7,0x3f4-0x3f5,0x3f0-0x3f3 irq 6 drq 2 on acpi0 fd0: <1440-KB 3.5" drive> on fdc0 drive 0 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A, console sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A ppc0: port 0x778-0x77b,0x378-0x37f irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold ppbus0: on ppc0 plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 pmtimer0 on isa0 orm0: at iomem 0xe3000-0xe3fff,0xc8000-0xc97ff,0xc0000-0xc7fff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x100> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounters tick every 10.000 msec IPv6 packet filtering initialized, default to accept, logging limited to 10 packets/entry IP Filter: v3.4.35 initialized. Default = block all, Logging = enabled witness_get: witness exhausted ipfw2 initialized, divert disabled, rule-based forwarding enabled, default to accept, logging limited to 10 packets/entry by default acd0: CDROM at ata0-master PIO4 da0 at twa0 bus 0 target 0 lun 0 da0: <3ware Logical Disk 00 1.00> Fixed Direct Access SCSI-0 device da0: 100.000MB/s transfers da0: 114430MB (234352640 512 byte sectors: 255H 63S/T 14587C) SMP: AP CPU #1 Launched! Mounting root from ufs:/dev/da0s1a WARNING: / was not properly dismounted WARNING: /usr was not properly dismounted WARNING: /var was not properly dismounted /var: mount pending error: blocks 1024 files 7 em0: Link is up 100 Mbps Full Duplex twa0: INFO: (0x04: 0x000c): Background initialize started: unit=0 twa0: INFO: (0x04: 0x0007): Background initialize done: unit=0 -- K.F.J. Martens, Sonologic, http://www.sonologic.nl/ Networking, hosting, embedded systems, unix, artificial intelligence. Public PGP key: http://www.metro.cx/pubkey-gmc.asc Wondering about the funny attachment your mail program can't read? Visit http://www.openpgp.org/ From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 1 22:31:04 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 8DEAB16A41F for ; Thu, 1 Sep 2005 22:31:04 +0000 (GMT) (envelope-from vkashyap@amcc.com) Received: from sdcexchange01.amcc.com (gatekeeper-out.amcc.com [198.137.200.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id 330FD43D45 for ; Thu, 1 Sep 2005 22:31:04 +0000 (GMT) (envelope-from vkashyap@amcc.com) Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.326 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 1 Sep 2005 15:31:00 -0700 Message-ID: <2B3B2AA816369A4E87D7BE63EC9D2F269B7B4D@SDCEXCHANGE01.ad.amcc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: panic in propagate_priority w/ postgresql under heavy load thread-index: AcWvQYf3QVjaWsAxQ9mDaYJcbWfdogAAslYg From: "Vinod Kashyap" To: "Koen Martens" , "Dimitry Andric" Cc: freebsd-hackers@freebsd.org Subject: RE: panic in propagate_priority w/ postgresql under heavy load X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2005 22:31:04 -0000 > -----Original Message----- > From: owner-freebsd-hackers@freebsd.org=20 > [mailto:owner-freebsd-hackers@freebsd.org] On Behalf Of Koen Martens > Sent: Thursday, September 01, 2005 3:11 PM > To: Dimitry Andric > Cc: freebsd-hackers@freebsd.org > Subject: Re: panic in propagate_priority w/ postgresql under=20 > heavy load >=20 > Hi Dim, >=20 > Dimitry Andric wrote: > > On 2005-09-01 at 19:02:06 Koen Martens wrote:=20 > >=20 > >>Anyway, it seems the dump should've gone to the swap partition, but=20 > >>i'm into multi-user mode again so i guess i'll have to wait for=20 > >>another panic to obtain it? > >=20 > > In RELENG_6, the dump device is chosen automagically during boot by=20 > > /etc/rc.d/dumpon, but this is (alas) not the case in RELENG_5_x, so=20 > > you'll have to manually specify it in /etc/rc.conf, i.e: > >=20 > > dumpdev=3D/dev/ad0s1b > >=20 > > Then make sure you have enough space in /var/crash, and try to=20 > > reproduce your panic... >=20 > Ok, i get it.. When it reboots it detects a dump on the swap=20 > partition and dd's that to /var/crash.. Which has plenty of=20 > free space on the particular box, 59 gigs ought to be enough=20 > for everyone :) >=20 > > Also, I think I read somewhere that there used to be problems with=20 > > dumping and 3Ware RAID cards (you seem to be using one according to=20 > > your kernel config, but you apparently didn't post a dmesg). >=20 > You're right, dmesg included below. >=20 > > However, > > it looks like revision 1.22.2.1 of src/sys/dev/twe/twe.c fixed that: > >=20 > >=20 > = http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/twe/twe.c?rev=3D1.22.2 > > .1&content-type=3Dtext/x-cvsweb-markup > >=20 > > Just to be sure, can you check if you got this version of twe.c, or > > 1.22.2.2 (which seems to be the RELENG_5_4 version, and=20 > thus it should=20 > > be fixed). >=20 > * $FreeBSD: src/sys/dev/twe/twe.c,v 1.22.2.2 2005/02/18 > 18:42:16 vkashyap > Exp $ >=20 > (nice wrapping, i think you get the idea :) >=20 >=20 > dmesg: >=20 >=20 >=20 > Copyright (c) 1992-2005 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992,=20 > 1993, 1994 > The Regents of the University of California. All rights=20 > reserved. > FreeBSD 5.4-RELEASE-p6 #1: Thu Sep 1 14:06:03 CEST 2005 > root@yin.sonologic.nl:/usr/obj/usr/src/sys/yin-yang-5.4 > WARNING: WITNESS option enabled, expect reduced performance. > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Intel(R) Xeon(TM) CPU 3.06GHz (3056.50-MHz 686-class CPU) > Origin =3D "GenuineIntel" Id =3D 0xf29 Stepping =3D 9 >=20 > Features=3D0xbfebfbff > Hyperthreading: 2 logical CPUs > real memory =3D 2146959360 (2047 MB) > avail memory =3D 2095415296 (1998 MB) > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0=20 > (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 6 > ioapic0 irqs 0-23 on motherboard > ioapic1 irqs 24-47 on motherboard > ioapic2 irqs 48-71 on motherboard > npx0: on motherboard > npx0: INT 16 interface > acpi0: on motherboard > acpi0: Power Button (fixed) > Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 > cpu0: on acpi0 > cpu1: on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > pci0: at device 0.1 (no driver attached) > pcib1: at device 2.0 on pci0 > pci1: on pcib1 > pci1: at device 28.0=20 > (no driver attached) > pcib2: at device 29.0 on pci1 > pci2: on pcib2 > pci1: at device 30.0=20 > (no driver attached) > pcib3: at device 31.0 on pci1 > pci3: on pcib3 > 3ware device driver for 9000 series storage controllers, version: > 2.50.02.012 > twa0: <3ware 9000 series Storage Controller> port=20 > 0x7000-0x70ff mem 0xfd800000-0xfdffffff,0xfb200000-0xfb2000ff=20 > irq 48 at device 1.0 on pci3 > twa0: 4 ports, Firmware FE9X 2.02.00.008, BIOS BE9X 2.02.01.037 > pci0: at device 2.1 (no driver attached) > pcib4: at device 30.0 on pci0 > pci4: on pcib4 > pci4: at device 3.0 (no driver attached) > fxp0: port 0x8400-0x843f mem=20 > 0xfb300000-0xfb31ffff,0xfb341000-0xfb341fff irq 20 at device=20 > 4.0 on pci4 > miibus0: on fxp0 > inphy0: on miibus0 > inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > fxp0: Ethernet address: 00:02:b3:d8:8a:b5 > em0: =20 > port 0x8440-0x847f mem 0xfb320000-0xfb33ffff irq 23 at device=20 > 5.0 on pci4 > em0: Ethernet address: 00:02:b3:d8:8b:05 > em0: Speed:N/A Duplex:N/A > isab0: at device 31.0 on pci0 > isa0: on isab0 > atapci0: port > 0x6c60-0x6c6f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device=20 > 31.1 on pci0 > ata0: channel #0 on atapci0 > ata1: channel #1 on atapci0 > pci0: at device 31.3 (no driver attached) > acpi_button0: on acpi0 > atkbdc0: port 0x64,0x60 irq 1 on acpi0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > fdc0: port=20 > 0x3f7,0x3f4-0x3f5,0x3f0-0x3f3 irq 6 drq 2 on acpi0 > fd0: <1440-KB 3.5" drive> on fdc0 drive 0 > sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4=20 > flags 0x10 on acpi0 > sio0: type 16550A, console > sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 > sio1: type 16550A > ppc0: port=20 > 0x778-0x77b,0x378-0x37f irq 7 drq 3 on acpi0 > ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode > ppc0: FIFO with 16/16/9 bytes threshold > ppbus0: on ppc0 > plip0: on ppbus0 > lpt0: on ppbus0 > lpt0: Interrupt-driven port > ppi0: on ppbus0 > pmtimer0 on isa0 > orm0: at iomem > 0xe3000-0xe3fff,0xc8000-0xc97ff,0xc0000-0xc7fff on isa0 > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=3D0x100> > vga0: at port 0x3c0-0x3df iomem=20 > 0xa0000-0xbffff on isa0 Timecounters tick every 10.000 msec > IPv6 packet filtering initialized, default to accept, logging=20 > limited to 10 packets/entry IP Filter: v3.4.35 initialized. =20 > Default =3D block all, Logging =3D enabled > witness_get: witness exhausted > ipfw2 initialized, divert disabled, rule-based forwarding=20 > enabled, default to accept, logging limited to 10=20 > packets/entry by default > acd0: CDROM at ata0-master PIO4 da0 at twa0=20 > bus 0 target 0 lun 0 > da0: <3ware Logical Disk 00 1.00> Fixed Direct Access SCSI-0 device > da0: 100.000MB/s transfers > da0: 114430MB (234352640 512 byte sectors: 255H 63S/T 14587C) > SMP: AP CPU #1 Launched! > Mounting root from ufs:/dev/da0s1a > WARNING: / was not properly dismounted > WARNING: /usr was not properly dismounted > WARNING: /var was not properly dismounted > /var: mount pending error: blocks 1024 files 7 > em0: Link is up 100 Mbps Full Duplex >=20 > twa0: INFO: (0x04: 0x000c): Background initialize started: unit=3D0 > twa0: INFO: (0x04: 0x0007): Background initialize done: unit=3D0 >=20 You seem to be booting off of a 9000 (twa) controller and not 7000/8000 (twe). It could be because of a 9000 firmware bug that you are not being able to get the dump. The firmware wrongly interprets physical address 0x0 as invalid during dumps, and fails the operations. This bug will be fixed in future firmware releases. -------------------------------------------------------- CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, = is for the sole use of the intended recipient(s) and contains = information that is confidential and proprietary to Applied Micro = Circuits Corporation or its subsidiaries. It is to be used solely for = the purpose of furthering the parties' business relationship. All = unauthorized review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply = e-mail and destroy all copies of the original message. From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 2 02:05:53 2005 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.org 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 CBE3C16A41F; Fri, 2 Sep 2005 02:05:53 +0000 (GMT) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6072B43D46; Fri, 2 Sep 2005 02:05:53 +0000 (GMT) (envelope-from mike@sentex.net) Received: from pumice6.sentex.ca (pumice6.sentex.ca [64.7.153.21]) by smarthost1.sentex.ca (8.13.3/8.13.3) with ESMTP id j8225qKT055233; Thu, 1 Sep 2005 22:05:52 -0400 (EDT) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by pumice6.sentex.ca (8.13.3/8.13.3) with ESMTP id j8225qFo062977; Thu, 1 Sep 2005 22:05:52 -0400 (EDT) (envelope-from mike@sentex.net) Received: from simian.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.3/8.13.3) with ESMTP id j8225nOf024913 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Sep 2005 22:05:50 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <6.2.3.4.0.20050901214122.0846ab90@64.7.153.2> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Thu, 01 Sep 2005 22:05:54 -0400 To: freebsd-hackers@FreeBSD.org From: Mike Tancsa Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by amavisd-new X-Scanned-By: MIMEDefang 2.51 on 64.7.153.18 X-Scanned-By: MIMEDefang 2.51 on 64.7.153.21 Cc: Subject: Winbond W83697UF/UG watchdog driver X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2005 02:05:54 -0000 My colleague gabor@sentex.net and I have slapped together a quick and dirty hardware watchdog driver for boards with the Winbond W83697UF/UG SuperIO chip. Its a kld that ties into the existing watchdog framework. Its version 1.0 but seems to work just fine. If you have a board with such a chip and are willing to try it out, let me know if it works, or if you think it should work but does not. Comments / suggestions for improvement welcome at freebsd-dev@sentex.net http://www.tancsa.com/itxwd1.0.tgz There is also a port version http://www.tancsa.com/watchdog/itxwd-port.tgz The board we developed it on is a Commwell Mini-ITX MB LV-667E8 and we used the existing ichwd driver as a template/framework. ---Mike -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 2 09:20:00 2005 Return-Path: X-Original-To: hackers@freebsd.org 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 36E7516A41F; Fri, 2 Sep 2005 09:20:00 +0000 (GMT) (envelope-from rea@rea.mbslab.kiae.ru) Received: from rea.mbslab.kiae.ru (rea.mbslab.kiae.ru [144.206.177.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id BC3FF43D45; Fri, 2 Sep 2005 09:19:59 +0000 (GMT) (envelope-from rea@rea.mbslab.kiae.ru) Received: from rea.mbslab.kiae.ru (localhost [127.0.0.1]) by rea.mbslab.kiae.ru (Postfix) with ESMTP id C57FCB8F0; Fri, 2 Sep 2005 13:19:57 +0400 (MSD) Received: by rea.mbslab.kiae.ru (Postfix, from userid 1000) id 31D9FBD6D; Thu, 1 Sep 2005 21:04:03 +0400 (MSD) Date: Thu, 1 Sep 2005 21:04:02 +0400 From: "Eygene A. Ryabinkin" To: Hans Petter Selasky Message-ID: <20050901170402.GA754@rea.mbslab.kiae.ru> References: <200508302009.aa99975@nowhere.iedowse.com> <200508312239.04897.hselasky@c2i.net> <20050901093733.GA915@rea.mbslab.kiae.ru> <200509011602.03079.hselasky@c2i.net> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <200509011602.03079.hselasky@c2i.net> User-Agent: Mutt/1.5.9i X-AV-Checked: Yes! X-Mailman-Approved-At: Fri, 02 Sep 2005 12:21:11 +0000 Cc: hackers@freebsd.org, freebsd-usb@freebsd.org Subject: Re: Low umass performance with USB 2.0 ports X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2005 09:20:00 -0000 > > Oops, it seems that this patch also does not work as expected: after some > > time of playing with flash card and working with the system it started to > > stall as unpatched system, but it freezes the system -- even IP stack was > > frozen (I am using DEVICE_POLLING), so I were to remove the flash from the > > port -- system was unfrozen and continued to work. So something is still > > bad with the USB. I'll try to do some long testing with USB 1.1 -- maybe it > > will show the same behaviour after some more time. > > Do you mean my patch? Yes. And I've noticed the second, worst, thing: my cd-burner refused to burn anything using atapi-cam. I've not tested the native atapi (via burncd), because it is broken (at least with many new drives). After recompiling the clean 5.x kernel the problem gone. I don't have much time today to make experiments, but I'll try to check this issue once again. -- rea From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 2 12:35:38 2005 Return-Path: X-Original-To: hackers@freebsd.org 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 6AB0F16A420 for ; Fri, 2 Sep 2005 12:35:38 +0000 (GMT) (envelope-from donatas@lrtc.net) Received: from mail.lrtc.lt (pegasus.lrtc.lt [217.9.240.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4380443D60 for ; Fri, 2 Sep 2005 12:35:35 +0000 (GMT) (envelope-from donatas@lrtc.net) Received: (qmail 17533 invoked from network); 2 Sep 2005 12:32:39 -0000 Received: from p2p-241-242-ird.vln0.lrtc.net (HELO donatas) (d.gendvilas@[217.9.241.242]) (envelope-sender ) by mail.lrtc.lt (qmail-ldap-1.03) with SMTP for ; 2 Sep 2005 12:32:39 -0000 Message-ID: <051d01c5afba$cdc9a7d0$9f90a8c0@donatas> From: "Donatas" To: Date: Fri, 2 Sep 2005 15:35:29 +0300 Organization: AB Lietuvos Radijo ir Televizijos Centras MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Content-Type: text/plain; charset="iso-8859-4" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: kernel.gz.aa & kernel.gz.ab X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Donatas List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2005 12:35:38 -0000 hello, wonder how could I decompress $subj files....they doesn't seems to be in = tar or gzip formats. files are taken from kern1.flp nad kern2.flp on 5.4-RELEASE/floppies thanx From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 2 12:48:02 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 C107E16A41F; Fri, 2 Sep 2005 12:48:02 +0000 (GMT) (envelope-from lists@jnielsen.net) Received: from ns1.jnielsen.net (ns1.jnielsen.net [69.55.238.237]) by mx1.FreeBSD.org (Postfix) with ESMTP id 70C1943D45; Fri, 2 Sep 2005 12:48:00 +0000 (GMT) (envelope-from lists@jnielsen.net) Received: from localhost (ns1 [69.55.238.237]) (authenticated bits=0) by ns1.jnielsen.net (8.12.9p2/8.12.9) with ESMTP id j82Clwsh044404; Fri, 2 Sep 2005 05:47:59 -0700 (PDT) (envelope-from lists@jnielsen.net) From: John Nielsen To: freebsd-hackers@freebsd.org, Donatas Date: Fri, 2 Sep 2005 08:47:30 -0400 User-Agent: KMail/1.8.2 References: <051d01c5afba$cdc9a7d0$9f90a8c0@donatas> In-Reply-To: <051d01c5afba$cdc9a7d0$9f90a8c0@donatas> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-4" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200509020847.31406.lists@jnielsen.net> X-Virus-Scanned: ClamAV 0.85.1/1053/Fri Sep 2 00:01:53 2005 on ns1.jnielsen.net X-Virus-Status: Clean Cc: hackers@freebsd.org Subject: Re: kernel.gz.aa & kernel.gz.ab X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2005 12:48:02 -0000 On Friday 02 September 2005 08:35, Donatas wrote: > wonder how could I decompress $subj files....they doesn't seems to be in > tar or gzip formats. > > files are taken from kern1.flp nad kern2.flp on 5.4-RELEASE/floppies cat kernel.gz.aa kernel.gz.ab > kernel.gz gunzip kernel.gz JN From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 2 12:48:02 2005 Return-Path: X-Original-To: hackers@freebsd.org 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 C107E16A41F; Fri, 2 Sep 2005 12:48:02 +0000 (GMT) (envelope-from lists@jnielsen.net) Received: from ns1.jnielsen.net (ns1.jnielsen.net [69.55.238.237]) by mx1.FreeBSD.org (Postfix) with ESMTP id 70C1943D45; Fri, 2 Sep 2005 12:48:00 +0000 (GMT) (envelope-from lists@jnielsen.net) Received: from localhost (ns1 [69.55.238.237]) (authenticated bits=0) by ns1.jnielsen.net (8.12.9p2/8.12.9) with ESMTP id j82Clwsh044404; Fri, 2 Sep 2005 05:47:59 -0700 (PDT) (envelope-from lists@jnielsen.net) From: John Nielsen To: freebsd-hackers@freebsd.org, Donatas Date: Fri, 2 Sep 2005 08:47:30 -0400 User-Agent: KMail/1.8.2 References: <051d01c5afba$cdc9a7d0$9f90a8c0@donatas> In-Reply-To: <051d01c5afba$cdc9a7d0$9f90a8c0@donatas> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-4" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200509020847.31406.lists@jnielsen.net> X-Virus-Scanned: ClamAV 0.85.1/1053/Fri Sep 2 00:01:53 2005 on ns1.jnielsen.net X-Virus-Status: Clean Cc: hackers@freebsd.org Subject: Re: kernel.gz.aa & kernel.gz.ab X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2005 12:48:02 -0000 On Friday 02 September 2005 08:35, Donatas wrote: > wonder how could I decompress $subj files....they doesn't seems to be in > tar or gzip formats. > > files are taken from kern1.flp nad kern2.flp on 5.4-RELEASE/floppies cat kernel.gz.aa kernel.gz.ab > kernel.gz gunzip kernel.gz JN From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 2 18:30:13 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 9DA2916A41F for ; Fri, 2 Sep 2005 18:30:13 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 239F143D46 for ; Fri, 2 Sep 2005 18:30:13 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from [10.50.40.201] (Not Verified[10.50.40.201]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Fri, 02 Sep 2005 14:45:35 -0400 From: John Baldwin To: freebsd-hackers@freebsd.org Date: Fri, 2 Sep 2005 14:07:42 -0400 User-Agent: KMail/1.8 References: <20050809133109.GA15300@skatecity> <20050811120108.GA20415@skatecity> <20050812232253.GA42088@skatecity> In-Reply-To: <20050812232253.GA42088@skatecity> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200509021407.42860.jhb@FreeBSD.org> Cc: Subject: Re: Using sysarch specific syscalls in assembly? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2005 18:30:13 -0000 On Friday 12 August 2005 07:22 pm, alexander wrote: > On Thu Aug 11 05, alexander wrote: > > Hmm...very odd. Should I file a bug report about this problem? > > Alright. I submitted a PR and got a suggestion on how to solve the problem > by Bruce Evans. Could somebody (apart from me) try out his workaround and > see if it works? > > Thx a bunch. Could you please try the patch I posted to the PR? -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 2 18:30:14 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 A28DF16A41F for ; Fri, 2 Sep 2005 18:30:14 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 42E3043D46 for ; Fri, 2 Sep 2005 18:30:14 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from [10.50.40.201] (Not Verified[10.50.40.201]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Fri, 02 Sep 2005 14:45:35 -0400 From: John Baldwin To: freebsd-hackers@freebsd.org Date: Fri, 2 Sep 2005 14:09:24 -0400 User-Agent: KMail/1.8 References: <4317340E.2050208@metro.cx> <200509011348.50159.jhb@FreeBSD.org> <43177AD3.7070308@metro.cx> In-Reply-To: <43177AD3.7070308@metro.cx> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200509021409.25056.jhb@FreeBSD.org> Cc: Koen Martens Subject: Re: panic in propagate_priority w/ postgresql under heavy load X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2005 18:30:14 -0000 On Thursday 01 September 2005 06:04 pm, Koen Martens wrote: > John Baldwin wrote: > > On Thursday 01 September 2005 01:02 pm, Koen Martens wrote: > >>I've had a little chat with neologism on ircnet/#freebsd about this > >>already, and done as he suggested: compile a debug kernel to obtain > >>a stack trace. > > > > Can you reproduce it with a kernel that has INVARIANTS and > > INVARIANT_SUPPORT on? I see that you had WITNESS on, can you check to > > see if there were any witness messages about sleepign with non-sleepable > > locks held before the crash? > > I will do this when I get back. I did a grep -i on witness in the > console log but this did not turn up anything suspicious (exact > output pasted below). Also, i checked again the logs right before > the crashes, nothing special output to console before the Kernel > trap 12.. > > > voltaire# grep -i witness yin.log > WARNING: WITNESS option enabled, expect reduced performance. > witness_get: witness exhausted > WARNING: WITNESS option enabled, expect reduced performance. > witness_get: witness exhausted This last means that witness had turned itself off because it had run out of resources. Try bumping up the WITNESS_COUNT constant in sys/kern/subr_witness.c. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 2 22:01:41 2005 Return-Path: X-Original-To: hackers@freebsd.org 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 60C1416A41F for ; Fri, 2 Sep 2005 22:01:41 +0000 (GMT) (envelope-from vkushnir@i.kiev.ua) Received: from horse.iptelecom.net.ua (horse.iptelecom.net.ua [212.9.224.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6443643D45 for ; Fri, 2 Sep 2005 22:01:40 +0000 (GMT) (envelope-from vkushnir@i.kiev.ua) Received: from h88.241.159.dialup.iptcom.net ([213.159.241.88]:46292 "EHLO kushnir1.kiev.ua" ident: "SOCKFAULT1" whoson: "vkushnir") by horse.iptelecom.net.ua with ESMTP id S1219376AbVIBWBh (INRCPT ); Sat, 3 Sep 2005 01:01:37 +0300 Received: from kushnir1.kiev.ua (kushnir1.kiev.ua [10.0.0.1]) by kushnir1.kiev.ua (8.13.4/8.13.3) with ESMTP id j82M1ZXE003511 for ; Sat, 3 Sep 2005 01:01:35 +0300 (EEST) (envelope-from vkushnir@i.kiev.ua) Date: Sat, 3 Sep 2005 01:01:35 +0300 (EEST) From: Vladimir Kushnir X-X-Sender: vkushnir@kushnir1.kiev.ua To: hackers@freebsd.org Message-ID: <20050903004621.L1919@kushnir1.kiev.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Subject: libmap.conf: mapping directories? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2005 22:01:41 -0000 Hi all, Is it doable to teach rtld (via libmap.conf) to map directories rather than libraries one-by-one? My problem is: I'm trying to use i386-built packages on my amd64 box. Most of them don't work 'cause of RPATH set to /usr/{X11R6,local}/lib where (obviously) 64-bit libs reside. And this is one of the reasons ia32 compatibility under amd64 arch is almost useless. One way: to completely remove RPATH (with chrpath, for example - BTW, this is nice enough utility but to make it work with 32-bit objects one has to use some workarounds). It's not always convenient, though. Much, much better it would be to place ALL of ia32 compat stuff into something like /compat/freebsd32 like we do it for Linux stuff, but somehow nobody seems to be even remotely interested. And the last way I see (a workaround as well but hey, it's better than nothing at all) would be $SUBJECT. So my question is: is it possible to map, say, /usr/local/lib to /usr/local/lib32 and if yes how do I do it? TIA, Vladimir From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 2 22:13:34 2005 Return-Path: X-Original-To: hackers@freebsd.org 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 01A4D16A41F for ; Fri, 2 Sep 2005 22:13:34 +0000 (GMT) (envelope-from caelian@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.198]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8F28043D4C for ; Fri, 2 Sep 2005 22:13:33 +0000 (GMT) (envelope-from caelian@gmail.com) Received: by zproxy.gmail.com with SMTP id z6so347054nzd for ; Fri, 02 Sep 2005 15:13:33 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:subject:from:to:cc:in-reply-to:references:content-type:date:message-id:mime-version:x-mailer:content-transfer-encoding; b=O8Pc1sFr1+k8IoPnIM8GUwDasf9ooUU9cu81XzAWSyHMaXzbXAMGHOKY1ahsdJNI8dnhr4mYhJeAxAhThlgblZ9iwQVaQ0CNNC9NBvsnqVVN7h1wpv/9WVLYsaXqj0v+tQBrFM9tspkFoWNklT+uJw9bYYs0YvJxkfXIHbf6aKA= Received: by 10.36.37.20 with SMTP id k20mr2583601nzk; Fri, 02 Sep 2005 15:13:33 -0700 (PDT) Received: from ?192.168.15.105? ( [68.190.230.198]) by mx.gmail.com with ESMTP id 15sm2182302nzo.2005.09.02.15.13.32; Fri, 02 Sep 2005 15:13:33 -0700 (PDT) From: Pascal Hofstee To: Vladimir Kushnir In-Reply-To: <20050903004621.L1919@kushnir1.kiev.ua> References: <20050903004621.L1919@kushnir1.kiev.ua> Content-Type: text/plain Date: Fri, 02 Sep 2005 15:13:31 -0700 Message-Id: <1125699211.808.9.camel@synergy.charterpipeline.net.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.3.8 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: hackers@freebsd.org Subject: Re: libmap.conf: mapping directories? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2005 22:13:34 -0000 On Sat, 2005-09-03 at 01:01 +0300, Vladimir Kushnir wrote: > Hi all, [snip] > One way: to completely remove RPATH (with chrpath, for example - BTW, this > is nice enough utility but to make it work with 32-bit objects one has to > use some workarounds). It's not always convenient, though. Much, much better > it would be to place ALL of ia32 compat stuff into something like > /compat/freebsd32 like we do it for Linux stuff, but somehow nobody seems > to be even remotely interested. And the last way I see (a workaround as > well but hey, it's better than nothing at all) would be $SUBJECT. So my > question is: is it possible to map, say, /usr/local/lib to > /usr/local/lib32 and if yes how do I do it? There is actually an effort underway right now to make happen exactly what you suggested: making a /compat/ia32 available with a freebsd32-syscall table similarly to how we treat Linux. The last word i got from the main person involved here is they discovered a few bugs they're trying to iron out at the moment. The person who can tell you more about that and i am sure would be thrilled to receive additional testing support goes by the name of Willow` on ##FreeBSD on the FreeNode IRC-network. Feel free to drop by sometime. -- Pascal Hofstee From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 2 23:20:24 2005 Return-Path: X-Original-To: hackers@freebsd.org 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 190D716A41F for ; Fri, 2 Sep 2005 23:20:24 +0000 (GMT) (envelope-from vkushnir@i.kiev.ua) Received: from horse.iptelecom.net.ua (horse.iptelecom.net.ua [212.9.224.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id DFBD543D49 for ; Fri, 2 Sep 2005 23:20:22 +0000 (GMT) (envelope-from vkushnir@i.kiev.ua) Received: from h88.241.159.dialup.iptcom.net ([213.159.241.88]:15857 "EHLO kushnir1.kiev.ua" ident: "SOCKFAULT1" whoson: "vkushnir") by horse.iptelecom.net.ua with ESMTP id S1219376AbVIBXUU (INRCPT ); Sat, 3 Sep 2005 02:20:20 +0300 Received: from localhost (localhost [IPv6:::1]) by kushnir1.kiev.ua (8.13.4/8.13.3) with ESMTP id j82NKI17008685; Sat, 3 Sep 2005 02:20:18 +0300 (EEST) (envelope-from vkushnir@i.kiev.ua) From: Vladimir Kushnir Organization: BITP To: Pascal Hofstee Date: Sat, 3 Sep 2005 02:20:17 +0300 User-Agent: KMail/1.8.90 References: <20050903004621.L1919@kushnir1.kiev.ua> <1125699211.808.9.camel@synergy.charterpipeline.net.lan> In-Reply-To: <1125699211.808.9.camel@synergy.charterpipeline.net.lan> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-u" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200509030220.18239.vkushnir@i.kiev.ua> Cc: hackers@freebsd.org Subject: Re: libmap.conf: mapping directories? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2005 23:20:24 -0000 On Saturday 03 September 2005 01:13, Pascal Hofstee wrote: [snip] > There is actually an effort underway right now to make happen exactly > what you suggested: making a /compat/ia32 available with a > freebsd32-syscall table similarly to how we treat Linux. > > The last word i got from the main person involved here is they > discovered a few bugs they're trying to iron out at the moment. > > The person who can tell you more about that and i am sure would be > thrilled to receive additional testing support goes by the name of > Willow` on ##FreeBSD on the FreeNode IRC-network. Feel free to drop by > sometime. Thanks a bunch, I'd be happy to participate. Regards, Vladimir From owner-freebsd-hackers@FreeBSD.ORG Sat Sep 3 06:44:06 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 0593216A41F for ; Sat, 3 Sep 2005 06:44:06 +0000 (GMT) (envelope-from dad@netroad.ru) Received: from dad.netroad.ru (dad.netroad.ru [213.24.172.233]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4149443D46 for ; Sat, 3 Sep 2005 06:44:04 +0000 (GMT) (envelope-from dad@netroad.ru) Received: from note.localnet (localhost [127.0.0.1]) by note.localnet (8.13.3/8.13.3) with ESMTP id j836i33o054074 for ; Sat, 3 Sep 2005 10:44:03 +0400 (MSD) (envelope-from dad@netroad.ru) Received: (from dad@localhost) by note.localnet (8.13.3/8.13.3/Submit) id j836i2NW054073 for freebsd-hackers@freebsd.org; Sat, 3 Sep 2005 10:44:02 +0400 (MSD) (envelope-from dad@netroad.ru) X-Authentication-Warning: note.localnet: dad set sender to dad@netroad.ru using -f Date: Sat, 3 Sep 2005 10:44:02 +0400 From: Alex Sidorov To: freebsd-hackers@freebsd.org Message-ID: <20050903104401.A53771@netroad.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Subject: patch for PR kern/42652: [smbfs] error deleting r/o (by windows) files on smbfs X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Sep 2005 06:44:06 -0000 Hi, I have submitted patch for PR: kern/42652: [smbfs] error deleting r/o (by windows) files on smbfs http://www.freebsd.org/cgi/query-pr.cgi?pr=42652 Everybody interested are welcome to test the fix. And, would anyone having permissions, change its state please ? Regards, -- Alex Sidorov From owner-freebsd-hackers@FreeBSD.ORG Sat Sep 3 09:27:46 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 E2BF016A41F for ; Sat, 3 Sep 2005 09:27:46 +0000 (GMT) (envelope-from wigry@uninet.ee) Received: from mail.neti.ee (smtp-out-1.neti.ee [194.126.101.98]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8C2B043D45 for ; Sat, 3 Sep 2005 09:27:45 +0000 (GMT) (envelope-from wigry@uninet.ee) Message-ID: <43196C96.6040504@uninet.ee> Date: Sat, 03 Sep 2005 12:27:50 +0300 From: Rein Kadastik User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-2.2.1 (20041222) (Debian) at neti.ee Subject: sed not working X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Sep 2005 09:27:47 -0000 Hi, I have a very interesing problem with sed in FreeBSD. Lets take the following sed command (from the ncurses MKlib_gen.sh script): sed -e '/^\([a-z_][a-z_]*\) /s//\1 gen_/' This command alters the input: blah something -> blah gen_something This works, but I have found a specific pattern, where it does not work: int something -> int something Does anybody have any idea, what would be the cause of the problem and how to fix it. I also have several other FreeBSD systems, where the sed behaves correctly. I also copied the sed over to the broken system, but no luck. The broken system used to be 4.6-STABLE and I managed to upgrade it to 4.11-RELEASE-p11 (without working sed). I hoped that upgrade procedure would elliminate the problem, but apparently not. "which sed" points to /usr/bin/sed "ident /usr/bin/sed" output: # ident /usr/bin/sed /usr/bin/sed: $FreeBSD: src/usr.bin/sed/compile.c,v 1.13.2.8 2002/08/17 05:47:06 tjr Exp $ $FreeBSD: src/usr.bin/sed/main.c,v 1.9.2.7 2002/08/06 10:03:29 fanf Exp $ $FreeBSD: src/usr.bin/sed/misc.c,v 1.3.2.2 2002/07/17 09:35:56 tjr Exp $ $FreeBSD: src/usr.bin/sed/process.c,v 1.10.2.11 2004/01/10 06:30:37 tjr Exp $ I suspect, that it is some sort of a regex library issue as sed does not contain its own regex engine. -- Rein From owner-freebsd-hackers@FreeBSD.ORG Sat Sep 3 10:18:06 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 969BC16A41F for ; Sat, 3 Sep 2005 10:18:06 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from mail07.syd.optusnet.com.au (mail07.syd.optusnet.com.au [211.29.132.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id F1EEF43D45 for ; Sat, 3 Sep 2005 10:18:05 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c220-239-19-236.belrs4.nsw.optusnet.com.au [220.239.19.236]) by mail07.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id j83AI1Uw012177 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sat, 3 Sep 2005 20:18:03 +1000 Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1]) by cirb503493.alcatel.com.au (8.12.10/8.12.10) with ESMTP id j83AI1SR082829; Sat, 3 Sep 2005 20:18:01 +1000 (EST) (envelope-from pjeremy@cirb503493.alcatel.com.au) Received: (from pjeremy@localhost) by cirb503493.alcatel.com.au (8.12.10/8.12.9/Submit) id j83AI1ID082828; Sat, 3 Sep 2005 20:18:01 +1000 (EST) (envelope-from pjeremy) Date: Sat, 3 Sep 2005 20:18:01 +1000 From: Peter Jeremy To: Rein Kadastik Message-ID: <20050903101800.GA77285@cirb503493.alcatel.com.au> References: <43196C96.6040504@uninet.ee> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43196C96.6040504@uninet.ee> User-Agent: Mutt/1.4.2i Cc: freebsd-hackers@freebsd.org Subject: Re: sed not working X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Sep 2005 10:18:06 -0000 On Sat, 2005-Sep-03 12:27:50 +0300, Rein Kadastik wrote: >Lets take the following sed command (from the ncurses MKlib_gen.sh script): > >sed -e '/^\([a-z_][a-z_]*\) /s//\1 gen_/' ... >This works, but I have found a specific pattern, where it does not work: >int something -> int something >Does anybody have any idea, what would be the cause of the problem and >how to fix it. I can't reproduce it on 4.9 or 7. I presume you've double checked that your test input doesn't have any garbage characters in it (or a tab instead of a space). >I also have several other FreeBSD systems, where the sed behaves >correctly. I also copied the sed over to the broken system, but no luck. ... >I suspect, that it is some sort of a regex library issue as sed does not >contain its own regex engine. What happens if you copy the libc from the broken system to a working system? Is there anything unusual about the problematic system? -- Peter Jeremy From owner-freebsd-hackers@FreeBSD.ORG Sat Sep 3 11:00:30 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 E97CC16A41F for ; Sat, 3 Sep 2005 11:00:30 +0000 (GMT) (envelope-from wigry@uninet.ee) Received: from mail.neti.ee (smtp-out-1.neti.ee [194.126.101.98]) by mx1.FreeBSD.org (Postfix) with ESMTP id 90D6A43D45 for ; Sat, 3 Sep 2005 11:00:30 +0000 (GMT) (envelope-from wigry@uninet.ee) Message-ID: <43198251.6070606@uninet.ee> Date: Sat, 03 Sep 2005 14:00:33 +0300 From: Rein Kadastik User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 CC: freebsd-hackers@freebsd.org References: <43196C96.6040504@uninet.ee> <20050903101800.GA77285@cirb503493.alcatel.com.au> In-Reply-To: <20050903101800.GA77285@cirb503493.alcatel.com.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-2.2.1 (20041222) (Debian) at neti.ee Subject: Re: sed not working X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Sep 2005 11:00:31 -0000 Peter Jeremy wrote: >On Sat, 2005-Sep-03 12:27:50 +0300, Rein Kadastik wrote: > > >>Lets take the following sed command (from the ncurses MKlib_gen.sh script): >> >>sed -e '/^\([a-z_][a-z_]*\) /s//\1 gen_/' >> >> OK got again some extremely strange testing results. If there is anywhere in the first token (the length does not matter) one of the following charakters: t, u, v, w, x, y, the transformation fails. Note that with z it works and with a-s it works also. -- Rein From owner-freebsd-hackers@FreeBSD.ORG Sat Sep 3 11:04:45 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 E3D6516A420 for ; Sat, 3 Sep 2005 11:04:45 +0000 (GMT) (envelope-from wigry@uninet.ee) Received: from mail.neti.ee (smtp-out-1.neti.ee [194.126.101.98]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8936943D53 for ; Sat, 3 Sep 2005 11:04:45 +0000 (GMT) (envelope-from wigry@uninet.ee) Message-ID: <43198354.3000402@uninet.ee> Date: Sat, 03 Sep 2005 14:04:52 +0300 From: Rein Kadastik User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 CC: freebsd-hackers@freebsd.org References: <43196C96.6040504@uninet.ee> <20050903101800.GA77285@cirb503493.alcatel.com.au> <43198251.6070606@uninet.ee> In-Reply-To: <43198251.6070606@uninet.ee> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-2.2.1 (20041222) (Debian) at neti.ee Subject: Re: sed not working X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Sep 2005 11:04:46 -0000 Rein Kadastik wrote: > Peter Jeremy wrote: > >> On Sat, 2005-Sep-03 12:27:50 +0300, Rein Kadastik wrote: >> >> >>> Lets take the following sed command (from the ncurses MKlib_gen.sh >>> script): >>> >>> sed -e '/^\([a-z_][a-z_]*\) /s//\1 gen_/' >>> >> > OK got again some extremely strange testing results. > > If there is anywhere in the first token (the length does not matter) > one of the following charakters: t, u, v, w, x, y, the transformation > fails. Note that with z it works and with a-s it works also. > > -- Rein > _______________________________________________ > 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" > Well I have one guess here. In estonian alphabet, the z comes immediately after s and before t. So as the regex orders [a-z] the characters t, u, v, w, x, y are left out How to order the sed to use english alphabet? Rein From owner-freebsd-hackers@FreeBSD.ORG Sat Sep 3 11:17:24 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 64EA316A41F for ; Sat, 3 Sep 2005 11:17:24 +0000 (GMT) (envelope-from wigry@uninet.ee) Received: from mail.neti.ee (smtp-out-1.neti.ee [194.126.101.98]) by mx1.FreeBSD.org (Postfix) with ESMTP id 04A8043D4C for ; Sat, 3 Sep 2005 11:17:23 +0000 (GMT) (envelope-from wigry@uninet.ee) Message-ID: <4319864A.3040706@uninet.ee> Date: Sat, 03 Sep 2005 14:17:30 +0300 From: Rein Kadastik User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <43196C96.6040504@uninet.ee> <20050903101800.GA77285@cirb503493.alcatel.com.au> <43198251.6070606@uninet.ee> <43198354.3000402@uninet.ee> In-Reply-To: <43198354.3000402@uninet.ee> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-2.2.1 (20041222) (Debian) at neti.ee Subject: Re: sed not working X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Sep 2005 11:17:24 -0000 Rein Kadastik wrote: > Rein Kadastik wrote: > >> Peter Jeremy wrote: >> >>> On Sat, 2005-Sep-03 12:27:50 +0300, Rein Kadastik wrote: >>> >>> >>>> Lets take the following sed command (from the ncurses MKlib_gen.sh >>>> script): >>>> >>>> sed -e '/^\([a-z_][a-z_]*\) /s//\1 gen_/' >>>> >>> >>> >> OK got again some extremely strange testing results. >> >> If there is anywhere in the first token (the length does not matter) >> one of the following charakters: t, u, v, w, x, y, the transformation >> fails. Note that with z it works and with a-s it works also. >> >> -- Rein >> _______________________________________________ >> 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" >> > Well I have one guess here. In estonian alphabet, the z comes > immediately after s and before t. So as the regex orders [a-z] the > characters t, u, v, w, x, y are left out > > How to order the sed to use english alphabet? > > Rein > _______________________________________________ > 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" > Well, My guess was right. I have a following line in the /etc/profile: export LANG=et_EE.ISO8859-15 After I expoerted LANG=en_US.ISO8859-1, the sed started to work. I did not thought that LANG parameter will also alter the alfabet and therefore the expression [a-z] does not cover the full alphabet anymore. Rein From owner-freebsd-hackers@FreeBSD.ORG Sat Sep 3 11:30:16 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 2569A16A41F for ; Sat, 3 Sep 2005 11:30:16 +0000 (GMT) (envelope-from andrea@acampi.inet.it) Received: from acampi.inet.it (acampi.inet.it [213.92.1.165]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8A96543D55 for ; Sat, 3 Sep 2005 11:30:15 +0000 (GMT) (envelope-from andrea@acampi.inet.it) Received: by acampi.inet.it (Postfix, from userid 1000) id D97264B; Sat, 3 Sep 2005 13:30:14 +0200 (CEST) Resent-From: andrea@webcom.it Resent-Date: Sat, 3 Sep 2005 13:30:14 +0200 Resent-Message-ID: <20050903113014.GM36768@webcom.it> Resent-To: freebsd-hackers@freebsd.org Date: Sat, 3 Sep 2005 13:27:41 +0200 From: Andrea Campi To: Rein Kadastik Message-ID: <20050903112741.GL36768@webcom.it> References: <43196C96.6040504@uninet.ee> <20050903101800.GA77285@cirb503493.alcatel.com.au> <43198251.6070606@uninet.ee> <43198354.3000402@uninet.ee> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43198354.3000402@uninet.ee> User-Agent: Mutt/1.5.9i Cc: freebsd-hackers@freebsd.org Subject: Re: sed not working X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Sep 2005 11:30:16 -0000 On Sat, Sep 03, 2005 at 02:04:52PM +0300, Rein Kadastik wrote: > Well I have one guess here. In estonian alphabet, the z comes > immediately after s and before t. So as the regex orders [a-z] the > characters t, u, v, w, x, y are left out That's expected, and it's well known. You should either force LANG=C or (MUCH better) use [[:alpha:]]. See man re_format(7) for more info. Oh, and by the way: this has nothing to do with hackers@, you should have tried questions@ first. Bye, Andrea -- Press every key to continue. From owner-freebsd-hackers@FreeBSD.ORG Sat Sep 3 16:20:52 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 A149716A41F for ; Sat, 3 Sep 2005 16:20:52 +0000 (GMT) (envelope-from ml@t-b-o-h.net) Received: from vjofn.tucs-beachin-obx-house.com (vjofn.tucs-beachin-obx-house.com [204.107.90.128]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2C6C543D45 for ; Sat, 3 Sep 2005 16:20:51 +0000 (GMT) (envelope-from ml@t-b-o-h.net) Received: from himinbjorg.tucs-beachin-obx-house.com (ool-44c511d8.dyn.optonline.net [68.197.17.216]) (authenticated bits=128) by vjofn.tucs-beachin-obx-house.com (8.12.9/8.12.9) with ESMTP id j83GKk8p001878 for ; Sat, 3 Sep 2005 12:20:46 -0400 (EDT) Received: from himinbjorg.tucs-beachin-obx-house.com (localhost.tucs-beachin-obx-house.com [127.0.0.1]) by himinbjorg.tucs-beachin-obx-house.com (8.13.3/8.12.10) with ESMTP id j83GKfmp047529 for ; Sat, 3 Sep 2005 12:20:41 -0400 (EDT) (envelope-from ml@t-b-o-h.net) Received: (from tbohml@localhost) by himinbjorg.tucs-beachin-obx-house.com (8.13.3/8.13.1/Submit) id j83GKfR9047528 for freebsd-hackers@freebsd.org; Sat, 3 Sep 2005 12:20:41 -0400 (EDT) (envelope-from tbohml) From: Tuc at T-B-O-H Message-Id: <200509031620.j83GKfR9047528@himinbjorg.tucs-beachin-obx-house.com> To: freebsd-hackers@freebsd.org Date: Sat, 3 Sep 2005 12:20:41 -0400 (EDT) X-Mailer: ELM [version 2.5 PL8] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: rc sequencing issue / mountcritremote X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Sep 2005 16:20:52 -0000 Hi, I'm having a bit of a problem with the sequencing of the rc when it relates to "mountcritremote". Right now, the /etc/rc script performs : files=`rcorder ${skip} /etc/rc.d/* 2>/dev/null` to determine in what order to start all the services. As it stands now, the sequence looks like : [...] /etc/rc.d/route6d /etc/rc.d/mrouted /etc/rc.d/routed /etc/rc.d/NETWORKING /etc/rc.d/devd /etc/rc.d/mountcritremote /etc/rc.d/syslogd /etc/rc.d/savecore /etc/rc.d/SERVERS /etc/rc.d/named /etc/rc.d/ntpdate /etc/rc.d/rpcbind [...] The problem I'm having is that when it attempts to remotely mount the NFS filesystem I need, there are no support programs running, namely (I THINK) : /etc/rc.d/rpcbind /etc/rc.d/nfsclient /etc/rc.d/mountd /etc/rc.d/nfsd /etc/rc.d/nfslocking It looks like nfsd could force some of this, but it probably would be better that it ran properly. If I override the /etc/rc line to be something like files=`cat /etc/localrcorder.conf` And run the "rcorder -s nostart /etc/rc.d/* > /etc/localrcorder.conf" and put those 5 items before the "/etc/rc.d/mountcritremote", I get 95% of the way there. At this point, "/etc/rc.d/named" isn't running, so using a FQDN on the /etc/fstab doesn't work. If I change it to an IP, then everything is perfect. My question is if somehow I'm not configuring my system correctly, that it shouldn't be mounting the filesystem I need at that time. The problem is, though, is I need my filesystem mounted for "/etc/rc.d/syslogd", so seems like a good enough time as any. If I am configuring it to do it at the proper time, is there a reason the dependencies don't currently have rpc/statd/lockd/etc running first? Thanks, Tuc From owner-freebsd-hackers@FreeBSD.ORG Sat Sep 3 17:18:06 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 D115016A41F for ; Sat, 3 Sep 2005 17:18:06 +0000 (GMT) (envelope-from stas@core.310.ru) Received: from core.310.ru (core.310.ru [83.97.105.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1653C43D45 for ; Sat, 3 Sep 2005 17:18:05 +0000 (GMT) (envelope-from stas@core.310.ru) Received: from core.310.ru (localhost [127.0.0.1]) by core.310.ru (8.13.3/8.12.11) with ESMTP id j83HGLMJ004305; Sat, 3 Sep 2005 21:16:21 +0400 (MSD) (envelope-from stas@core.310.ru) Received: (from stas@localhost) by core.310.ru (8.13.3/8.12.11/Submit) id j83HGLqX004304; Sat, 3 Sep 2005 21:16:21 +0400 (MSD) (envelope-from stas) Date: Sat, 3 Sep 2005 21:16:21 +0400 From: Stanislav Sedov To: Tuc at T-B-O-H Message-ID: <20050903171621.GA3927@core.310.ru> References: <200509031620.j83GKfR9047528@himinbjorg.tucs-beachin-obx-house.com> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <200509031620.j83GKfR9047528@himinbjorg.tucs-beachin-obx-house.com> User-Agent: Mutt/1.4.2.1i Cc: freebsd-hackers@freebsd.org Subject: Re: rc sequencing issue / mountcritremote X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Sep 2005 17:18:06 -0000 On Sat, Sep 03, 2005 at 12:20:41PM -0400, Tuc at T-B-O-H wrote: > The problem I'm having is that when it attempts to remotely > mount the NFS filesystem I need, there are no support programs > running, namely (I THINK) : > > /etc/rc.d/rpcbind > /etc/rc.d/nfsclient > /etc/rc.d/mountd > /etc/rc.d/nfsd > /etc/rc.d/nfslocking This is wrong, you don't need anything to mount remote NFS filesystems. nfsclient only sets some useful sysctls. See handbook for details. From owner-freebsd-hackers@FreeBSD.ORG Sat Sep 3 19:34:28 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 7326F16A41F for ; Sat, 3 Sep 2005 19:34:28 +0000 (GMT) (envelope-from ml@t-b-o-h.net) Received: from vjofn.tucs-beachin-obx-house.com (vjofn.tucs-beachin-obx-house.com [204.107.90.128]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0029143D45 for ; Sat, 3 Sep 2005 19:34:27 +0000 (GMT) (envelope-from ml@t-b-o-h.net) Received: from himinbjorg.tucs-beachin-obx-house.com (ool-44c511d8.dyn.optonline.net [68.197.17.216]) (authenticated bits=128) by vjofn.tucs-beachin-obx-house.com (8.12.9/8.12.9) with ESMTP id j83JY58p005297; Sat, 3 Sep 2005 15:34:06 -0400 (EDT) Received: from himinbjorg.tucs-beachin-obx-house.com (localhost.tucs-beachin-obx-house.com [127.0.0.1]) by himinbjorg.tucs-beachin-obx-house.com (8.13.3/8.12.10) with ESMTP id j83JXt0B050464; Sat, 3 Sep 2005 15:33:59 -0400 (EDT) (envelope-from ml@t-b-o-h.net) Received: (from tbohml@localhost) by himinbjorg.tucs-beachin-obx-house.com (8.13.3/8.13.1/Submit) id j83JXtfZ050463; Sat, 3 Sep 2005 15:33:55 -0400 (EDT) (envelope-from tbohml) From: Tuc at T-B-O-H Message-Id: <200509031933.j83JXtfZ050463@himinbjorg.tucs-beachin-obx-house.com> To: stas@310.ru (Stanislav Sedov) Date: Sat, 3 Sep 2005 15:33:54 -0400 (EDT) In-Reply-To: <20050903171621.GA3927@core.310.ru> X-Mailer: ELM [version 2.5 PL8] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: rc sequencing issue / mountcritremote X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Sep 2005 19:34:28 -0000 > > On Sat, Sep 03, 2005 at 12:20:41PM -0400, Tuc at T-B-O-H wrote: > > > The problem I'm having is that when it attempts to remotely > > mount the NFS filesystem I need, there are no support programs > > running, namely (I THINK) : > > > > /etc/rc.d/rpcbind > > /etc/rc.d/nfsclient > > /etc/rc.d/mountd > > /etc/rc.d/nfsd > > /etc/rc.d/nfslocking > > This is wrong, you don't need anything to mount remote NFS filesystems. > nfsclient only sets some useful sysctls. > See handbook for details. > nfsclient not only does sysctls, but also runs rpc.umntall via a dependency. I would still think the best time to do this is before the remote filesystem is mounted. Since there are other items that need rpcbind, it should be started first, and again I think before the filesystem. In checking more, the mountd isn't needed. The nfsd seems to take into account nfsserver, rpcbind, mountd and a sysctl. However, the biggest one after rpcbind I would think is nfslocking. It runs rpc.statd and rpc.lockd. I've run into ALOT of problems with things if locking isn't running. So isn't this also necessary before the mount? I know I use the remote filesystem very soon after its mounted, so it would need to be running very early on. So, even with the others not running, wouldn't I need rpcbind and nfslocking done just before remotemountcrit? One other thing I didn't touch too much on, is what about the DNS resolution for the remote mount? named isn't running until much later, so it hangs.... Isn't that something that should be running so the resolution can happen? Thanks, Tuc From owner-freebsd-hackers@FreeBSD.ORG Sat Sep 3 20:27:27 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 38A6D16A41F for ; Sat, 3 Sep 2005 20:27:27 +0000 (GMT) (envelope-from arundel@h3c.de) Received: from enterprise4.noxa.de (enterprise.noxa.de [212.60.197.71]) by mx1.FreeBSD.org (Postfix) with ESMTP id 30E3243D46 for ; Sat, 3 Sep 2005 20:27:25 +0000 (GMT) (envelope-from arundel@h3c.de) Received: (qmail 25668 invoked from network); 3 Sep 2005 22:27:23 +0200 Received: from p508fec86.dip.t-dialin.net (HELO localhost.skatecity) (80.143.236.134) by enterprise.noxa.de with AES256-SHA encrypted SMTP; 3 Sep 2005 22:27:23 +0200 Received: from localhost.skatecity (nobody@localhost.skatecity [127.0.0.1]) by localhost.skatecity (8.13.4/8.13.4) with ESMTP id j83KRE9W064275 for ; Sat, 3 Sep 2005 22:27:14 +0200 (CEST) (envelope-from arundel@localhost.skatecity) Received: (from arundel@localhost) by localhost.skatecity (8.13.4/8.13.4/Submit) id j83KREBt064273 for freebsd-hackers@freebsd.org; Sat, 3 Sep 2005 22:27:14 +0200 (CEST) (envelope-from arundel) From: Alexander Best Date: Sat, 3 Sep 2005 22:27:14 +0200 To: freebsd-hackers@freebsd.org Message-ID: <20050903202713.GA45209@skatecity> Mail-Followup-To: freebsd-hackers@freebsd.org References: <20050809133109.GA15300@skatecity> <20050811120108.GA20415@skatecity> <20050812232253.GA42088@skatecity> <200509021407.42860.jhb@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200509021407.42860.jhb@FreeBSD.org> User-Agent: Mutt/1.4.2.1i Organisation: =?iso-8859-15?Q?Westfl=E4lische_Wilhelms-U?= =?iso-8859-15?Q?niversit=E4t_M=FCnster?= Subject: Re: Using sysarch specific syscalls in assembly? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Sep 2005 20:27:27 -0000 On Fri Sep 2 05, John Baldwin wrote: > On Friday 12 August 2005 07:22 pm, alexander wrote: > > On Thu Aug 11 05, alexander wrote: > > > Hmm...very odd. Should I file a bug report about this problem? > > > > Alright. I submitted a PR and got a suggestion on how to solve the problem > > by Bruce Evans. Could somebody (apart from me) try out his workaround and > > see if it works? > > > > Thx a bunch. > > Could you please try the patch I posted to the PR? > > -- > John Baldwin <>< http://www.FreeBSD.org/~jhb/ > "Power Users Use the Power to Serve" = http://www.FreeBSD.org /usr/src/sys/i386/i386/machdep.c:1276: warning: redundant redeclaration of \ 'private_tss' ./machine/pcb_ext.h:47: warning: previous declaration of 'private_tss' was here *** Error code 1 Stop in /usr/obj/usr/src/sys/ARUNDEL. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. machdep.c : \ $FreeBSD: src/sys/i386/i386/machdep.c,v 1.616.2.1 2005/07/28 03:30:53 jkoshy \ Exp $ pcb_ext.h : \ $FreeBSD: src/sys/i386/include/pcb_ext.h,v 1.9 2002/03/20 05:48:58 alfred Exp $ Cheers. From owner-freebsd-hackers@FreeBSD.ORG Sat Sep 3 23:12:25 2005 Return-Path: X-Original-To: hackers@FreeBSD.org 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 AE2F416A41F for ; Sat, 3 Sep 2005 23:12:25 +0000 (GMT) (envelope-from bra@fsn.hu) Received: from people.fsn.hu (people.fsn.hu [195.228.252.137]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4118C43D45 for ; Sat, 3 Sep 2005 23:12:24 +0000 (GMT) (envelope-from bra@fsn.hu) Received: from localhost (localhost [127.0.0.1]) by people.fsn.hu (Postfix) with ESMTP id EA20E8441F for ; Sat, 3 Sep 2005 23:12:24 +0200 (CEST) Received: from people.fsn.hu ([127.0.0.1]) by localhost (people.fsn.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 53009-04-2 for ; Sat, 3 Sep 2005 23:12:12 +0200 (CEST) Received: from [172.16.164.2] (fw.axelero.hu [195.228.243.120]) by people.fsn.hu (Postfix) with ESMTP id 1E8478441E for ; Sat, 3 Sep 2005 23:12:12 +0200 (CEST) Message-ID: <431A11AB.2060008@fsn.hu> Date: Sat, 03 Sep 2005 23:12:11 +0200 From: Attila Nagy User-Agent: Debian Thunderbird 1.0.2 (X11/20050602) X-Accept-Language: en-us, en MIME-Version: 1.0 To: hackers@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at fsn.hu Cc: Subject: Bind DoS? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Sep 2005 23:12:25 -0000 Hello, I am currently trying to set up two caching nameservers and noticed an interesting behaviour. The configuration is the following: two FreeBSD/amd64 6-CURRENT machines, with single Opteron processors. Bind was compiled from ports, without threading, with gcc34 (from ports), with -O2 -static. It runs in a jail, with nothing more than the config and a nearly empty devfs mount. Machine A has a simple config of the following: options { directory "/etc/bind"; tcp-clients 256; recursive-clients 8192; max-cache-size 600M; minimal-responses yes; pid-file "/tmp/named.pid"; forwarders { MACHINE_B_IP; }; }; Machine B has the same bind, but runs as an authoritative NS with a joker record of: * IN TXT "256xA" in the . zone (so it answers 256 "A"s for everything). The test: from machine B I start a queryperf, this way: queryperf -d list -s MACHINE_A_IP where list has the following: www.RANDOMNUMBER.hu TXT [...] this is 9000000 times. During the test, machine A starts to fill its cache up until about 860 MBs. Until that I see this in top: CPU states: 27.7% user, 0.0% nice, 58.1% system, 14.2% interrupt, 0.0% idle On machine B queryperf receives answer within the default timeout (5 seconds). After bind reaches about 860 MBs, it starts to eat CPU, so there is 100% user and nearly 0% system and interrupt usage. queryperf starts to time out with the following: [Timeout] Query timed out: msg id 64837 Warning: Received a response with an unexpected (maybe timed out) id: 64837 The server effectively dies, it can answer only a very little number of queries and with very low performance. If I stop queryperf, bind remains in the CPU eating state: 76423 bind 1 129 0 861M 862M RUN 8:30 97.71% named Because the machine has much more RAM, I first tried with 1200M in the config. The server has reached its "zombie" state at around 1600 MB of usage and it was much unresponsive. On another (real) server, I noticed similar behaviour this week. Bind started to eat all CPU resources, there were only "recursive quota reached" messages in the logs, but rndc status said only very low usage (for example 60/1024 on that server). I can repeat this with and without patch-lib_dns_resolver.c. If I stop the queries, the server starts to answer the queries in a few minutes, after it has finished its strange "CPU eating" loop. ktrace says, it's doing this many-many times between two successful queries: 76423 named CALL gettimeofday(0x7fffffffe450,0) 76423 named RET gettimeofday 0 Any ideas? Thanks, -- Attila Nagy e-mail: Attila.Nagy@fsn.hu Free Software Network (FSN.HU) phone @work: +361 371 3536 ISOs: http://www.fsn.hu/?f=download cell.: +3630 306 6758