From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 22 05:44:42 2007 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6613516A400; Sun, 22 Apr 2007 05:44:42 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 20BCB13C448; Sun, 22 Apr 2007 05:44:42 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.13.8/8.13.4) with ESMTP id l3M5gkt5076231; Sat, 21 Apr 2007 23:42:46 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sat, 21 Apr 2007 23:42:53 -0600 (MDT) Message-Id: <20070421.234253.-937378175.imp@bsdimp.com> To: alfred@freebsd.org From: "M. Warner Losh" In-Reply-To: <20070419211021.GH69188@elvis.mu.org> References: <20070419211021.GH69188@elvis.mu.org> X-Mailer: Mew version 4.2 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.bsdimp.com [127.0.0.1]); Sat, 21 Apr 2007 23:42:46 -0600 (MDT) Cc: hackers@freebsd.org, bde@freebsd.org Subject: Re: serial help ? 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, 22 Apr 2007 05:44:42 -0000 In message: <20070419211021.GH69188@elvis.mu.org> Alfred Perlstein writes: : : I'm working on some custom hardware and I'm getting garbled console : output. : : I noticed that siocntxwait looks like this: : : static void : siocntxwait(iobase) : Port_t iobase; : { : int timo; : : /* : * Wait for any pending transmission to finish. Required to avoid : * the UART lockup bug when the speed is changed, and for normal : * transmits. : */ : timo = 100000; : while ((inb(iobase + com_lsr) & (LSR_TSRE | LSR_TXRDY)) : != (LSR_TSRE | LSR_TXRDY) && --timo != 0) : ; : } : : Shouldn't there be some sort of DELAY in there? : : My platform has an emulated serial device in hardware, so it : may be that the loop could run a LOT faster than transmit can : happen... : : any ideas of what the DELAY should be? The inb() is assumed to provide a delay of 1us, so this has a timeout of 100ms. Even with newer PCI devices that run about 4-5 times faster, the timeout is still on the order of 20ms, which is adequate for most modern baudrates (9600 baud takes 1ms, 115200 takes 10us). Warner From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 22 10:54:08 2007 Return-Path: X-Original-To: FreeBSD-Hackers@FreeBSD.org Delivered-To: FreeBSD-Hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 18CD016A401 for ; Sun, 22 Apr 2007 10:54:08 +0000 (UTC) (envelope-from mohacsi@niif.hu) Received: from mail.ki.iif.hu (mail.ki.iif.hu [193.6.222.241]) by mx1.freebsd.org (Postfix) with ESMTP id D098C13C4B7 for ; Sun, 22 Apr 2007 10:54:07 +0000 (UTC) (envelope-from mohacsi@niif.hu) Received: by mail.ki.iif.hu (Postfix, from userid 1003) id A5A13562C; Sun, 22 Apr 2007 12:27:33 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id A181555ED; Sun, 22 Apr 2007 12:27:33 +0200 (CEST) Date: Sun, 22 Apr 2007 12:27:33 +0200 (CEST) From: Mohacsi Janos X-X-Sender: mohacsi@mignon.ki.iif.hu To: Jan Knepper In-Reply-To: <4628D3EA.6060405@digitaldaemon.com> Message-ID: <20070422122342.Y32158@mignon.ki.iif.hu> References: <45F1C355.8030504@digitaldaemon.com> <20070310082316.K64466@mignon.ki.iif.hu> <4628D3EA.6060405@digitaldaemon.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD Hackers Subject: Re: Multiple IP Jail's patch for FreeBSD 6.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: Sun, 22 Apr 2007 10:54:08 -0000 On Fri, 20 Apr 2007, Jan Knepper wrote: > Mohacsi Janos wrote: >> Hi Jan, >> The problem with your patch is the missing IPv6 support. > I know... So what you are saying it does not work? No. I am saying, that worth considering IPv6 support too. >> The drafonfly version already supports it. > I know... However... If you could get me a version of DragonFlyBSD that > supports amd64 I might consider switching... I don't want you to convince to switch to DragonFlyBSD. Regards, Janos From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 22 15:31:57 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7C4B716A402 for ; Sun, 22 Apr 2007 15:31:57 +0000 (UTC) (envelope-from spap13@googlemail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.224]) by mx1.freebsd.org (Postfix) with ESMTP id 3B4A313C455 for ; Sun, 22 Apr 2007 15:31:56 +0000 (UTC) (envelope-from spap13@googlemail.com) Received: by wr-out-0506.google.com with SMTP id 70so1355954wra for ; Sun, 22 Apr 2007 08:31:56 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=googlemail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=i88rAZW9jRX2sSRapmLHsUy8AZRcokGH2U93wECKBKi2lR6aL3SIOK9gRWo0Wj9W3+TCevt2mzdPtY/6YrtDTbJ9KTnf+Tv9w/W092Hn52oh8i628TqluyD1W3UGfX11mjkBWKT8GWN57Oi53vp/uT/R/Quu5L0hk7fqh/8tgfo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=Y1huK0fg+grjq5QTh2dreo0yLZAAgbj27qKil2foD0YfTvrk7Kkk0JqDIX+lMhBXu1WXEcf/59rvEVFmuejAi06Fdt85WlCz1imYszw7uDNl/X6Fj0s4q6x3KJCU7iV2NzvXG2lAI7rPJuwot5poLNxBuKkWIudx1D9q26uWbhE= Received: by 10.115.58.1 with SMTP id l1mr2079653wak.1177254315135; Sun, 22 Apr 2007 08:05:15 -0700 (PDT) Received: by 10.115.54.16 with HTTP; Sun, 22 Apr 2007 08:05:14 -0700 (PDT) Message-ID: Date: Sun, 22 Apr 2007 11:05:14 -0400 From: "Spiros Papadopoulos" To: freebsd-hackers@freebsd.org In-Reply-To: MIME-Version: 1.0 References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Linksys wireless pcmcia card / FreeBSD 6.2-RELEASE 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, 22 Apr 2007 15:31:57 -0000 Hi, I am running FreeBSD 6.2 RELEASE and I have the above card in my DELL's latitude c810 cardbus. I followed the instructions on the page below and configure the kernel accordingly: http://www.freebsdmall.com/~loader/en_US.ISO8859-1/articles/wireless/article.html i get the message about: cardbus0: CIS pointer is 0 cardbus0: Resource not specified in CIS which takes me to the post below...: http://freebsd.monkey.org/freebsd-stable/200607/msg00449.html I guess i need to tweak the windows driver or anyway hack it somehow. The problem is that i 've never done anything similar before but i would like to get involved and make it work. Anybody can point me to the right direction ? If the above is not the best solution i would really appreciate pointing me to the best alternative. thanks in advance Spiros From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 22 22:22:00 2007 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C052916A413 for ; Sun, 22 Apr 2007 22:22:00 +0000 (UTC) (envelope-from infofarmer@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.224]) by mx1.freebsd.org (Postfix) with ESMTP id 8297A13C468 for ; Sun, 22 Apr 2007 22:22:00 +0000 (UTC) (envelope-from infofarmer@gmail.com) Received: by wr-out-0506.google.com with SMTP id 70so1419671wra for ; Sun, 22 Apr 2007 15:22:00 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; b=HfhnxhtiFfc+11G5OMxciQTk1HA0mctDb+Xfe6zQrj7A8eLviVp3Vj8pCTSpV41xSWw9iOz0M2vFz5Ng2vDt9b5BjEfUnAqDfrgIsEXDu/8Detc7Po8OzfSE3wxTN0TM4XNo2KyJaOJ3/Gs7ITIjzl3TDdbpi5+BgDigsh5TzNo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; b=K+1ZssoidrEYzM4aJdhGYmjnPFM3lb1I0FyzJzidXVzUAz5xULMDqseFPuSQEU5T5yGzMHDrMjn5s3oC1+MYmCU/GBHraA9MfXMsZkjTOAirPhqQA6sJTMofApwn1k2DKtV+7YwvcIMuXpUL0i+JELXOOmqvi3Bnz2VuLqk819w= Received: by 10.114.147.1 with SMTP id u1mr564365wad.1177278887536; Sun, 22 Apr 2007 14:54:47 -0700 (PDT) Received: by 10.114.194.5 with HTTP; Sun, 22 Apr 2007 14:54:47 -0700 (PDT) Message-ID: Date: Mon, 23 Apr 2007 01:54:47 +0400 From: "Andrew Pantyukhin" Sender: infofarmer@gmail.com To: hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Google-Sender-Auth: ae4852398d36b16c Cc: Subject: extern "C" and undefined reference 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, 22 Apr 2007 22:22:00 -0000 7zip developers converted some code from C++ to C, while leaving the main stand-alone lzma app in C++. They use 'extern "C" { }' blocks around #include's referencing C headers. Everything compiles fine, but "undefined reference" errors appear at linkage. The undefined references are to the C functions included from withing those 'extern "C"' wrappers. I tried to remove the wrappers from some files and the amount of errors decreased a bit. Is there a better workaround? Google came up with two results: remove the wrappers or use c++ instead of cc. I'm already using c++. Thanks! From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 22 23:14:02 2007 Return-Path: X-Original-To: hackers@FreeBSD.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D47C816A401; Sun, 22 Apr 2007 23:14:02 +0000 (UTC) (envelope-from dds@aueb.gr) Received: from mx-out-04.forthnet.gr (mx-out.forthnet.gr [193.92.150.103]) by mx1.freebsd.org (Postfix) with ESMTP id 3B2DC13C45A; Sun, 22 Apr 2007 23:14:01 +0000 (UTC) (envelope-from dds@aueb.gr) Received: from mx-av-03.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-04.forthnet.gr (8.13.8/8.13.8) with ESMTP id l3MNE0Y5006304; Mon, 23 Apr 2007 02:14:00 +0300 Received: from MX-IN-02.forthnet.gr (mx-in-02.forthnet.gr [193.92.150.185]) by mx-av-03.forthnet.gr (8.14.1/8.14.1) with ESMTP id l3MNE0LB009913; Mon, 23 Apr 2007 02:14:00 +0300 Received: from [192.168.136.22] (ppp122-171.adsl.forthnet.gr [193.92.229.171]) by MX-IN-02.forthnet.gr (8.14.1/8.14.1) with ESMTP id l3MNDpPD001947; Mon, 23 Apr 2007 02:13:53 +0300 Authentication-Results: MX-IN-02.forthnet.gr from=dds@aueb.gr; sender-id=neutral; spf=neutral Message-ID: <462BEC2B.5090508@aueb.gr> Date: Mon, 23 Apr 2007 02:13:47 +0300 From: Diomidis Spinellis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.9) Gecko/20061211 SeaMonkey/1.0.7 MIME-Version: 1.0 To: Andrew Pantyukhin References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.90.2/3147/Sun Apr 22 18:09:35 2007 on mx-av-03.forthnet.gr X-Virus-Status: Clean Cc: hackers@FreeBSD.org Subject: Re: extern "C" and undefined reference 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, 22 Apr 2007 23:14:02 -0000 Andrew Pantyukhin wrote: > 7zip developers converted some code from C++ to C, > while leaving the main stand-alone lzma app in C++. > They use 'extern "C" { }' blocks around #include's > referencing C headers. > > Everything compiles fine, but "undefined reference" > errors appear at linkage. The undefined references > are to the C functions included from withing those > 'extern "C"' wrappers. I tried to remove the > wrappers from some files and the amount of errors > decreased a bit. Is there a better workaround? > > Google came up with two results: remove the wrappers > or use c++ instead of cc. I'm already using c++. Many of the C headers are available in a different form for C++ programs. For example, in a C++ program you can #include instead of . You can use nm(1) on the .o files to see where the problem comes from. Diomidis From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 23 00:06:36 2007 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AE5AF16A404 for ; Mon, 23 Apr 2007 00:06:36 +0000 (UTC) (envelope-from infofarmer@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.232]) by mx1.freebsd.org (Postfix) with ESMTP id 0DA3313C44B for ; Mon, 23 Apr 2007 00:05:16 +0000 (UTC) (envelope-from infofarmer@gmail.com) Received: by nz-out-0506.google.com with SMTP id r28so1180130nza for ; Sun, 22 Apr 2007 17:05:00 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=DOnvuH81L+GEdVgvhbnshiKmqoT6Zw6tEZ9Ubm1yxmiOoA/QeMX43jFGyxH3Fx7arkHpw++YZ2De6yNsxdyT/X7AKfb5uIRbWbLlft8V46J25+mboaprQM2r0AyxbcPQVe7hsexovhH2Wr/Ky3/D63Dw/jkYiqOSepf0dzn++wQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=XduQuBq4p845ZfiIMVgr1g3A3Q0ehJETHhqsMXdkyGoY9zWtixsDPKBhQ9IfpgPvNSVRklCKK7a5PpsBu6xHRv8Vr8a2cJdQqDgQracvroPyAdq36dTNkhWZ8786/PGSFLebQNQnaurWOovaDGQZt999UpQrEvMfJriXTCzPru8= Received: by 10.114.194.1 with SMTP id r1mr2266865waf.1177286699092; Sun, 22 Apr 2007 17:04:59 -0700 (PDT) Received: by 10.114.194.5 with HTTP; Sun, 22 Apr 2007 17:04:59 -0700 (PDT) Message-ID: Date: Mon, 23 Apr 2007 04:04:59 +0400 From: "Andrew Pantyukhin" Sender: infofarmer@gmail.com To: "Diomidis Spinellis" In-Reply-To: <462BEC2B.5090508@aueb.gr> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <462BEC2B.5090508@aueb.gr> X-Google-Sender-Auth: c2a691a02999596f Cc: hackers@freebsd.org Subject: Re: extern "C" and undefined reference 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, 23 Apr 2007 00:06:36 -0000 On 4/23/07, Diomidis Spinellis wrote: > You can use nm(1) on the .o files to see where the problem comes from. Thanks! Using nm(1) I saw that the object file generated from pure C code had its symbols mangled - only then did I notice that it was being compiled with c++, not cc. A simple sed trick fixed that in a jiffy. How blind could I be... Thanks! From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 23 02:23:33 2007 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.org Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7C75316A400 for ; Mon, 23 Apr 2007 02:23:33 +0000 (UTC) (envelope-from alepulver@FreeBSD.org) Received: from relay02.pair.com (relay02.pair.com [209.68.5.16]) by mx1.freebsd.org (Postfix) with SMTP id 32FAD13C43E for ; Mon, 23 Apr 2007 02:23:33 +0000 (UTC) (envelope-from alepulver@FreeBSD.org) Received: (qmail 80534 invoked by uid 0); 23 Apr 2007 02:23:31 -0000 Received: from 190.55.91.88 (HELO deimos.mars.bsd) (190.55.91.88) by relay02.pair.com with SMTP; 23 Apr 2007 02:23:31 -0000 X-pair-Authenticated: 190.55.91.88 Date: Sun, 22 Apr 2007 23:23:30 -0300 From: Alejandro Pulver To: freebsd-hackers@FreeBSD.org Message-ID: <20070422232330.5026cdca@deimos.mars.bsd> In-Reply-To: <20070414191842.15e2f8b1@deimos.mars.bsd> References: <20070414191842.15e2f8b1@deimos.mars.bsd> X-Mailer: Claws Mail 2.8.1 (GTK+ 2.10.11; i386-portbld-freebsd6.2) Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_3Qrnxx9nmgKjoue_f/VmtlW"; protocol="application/pgp-signature"; micalg=PGP-SHA1 Cc: Subject: Re: Gaim log writing delays the system 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, 23 Apr 2007 02:23:33 -0000 --Sig_3Qrnxx9nmgKjoue_f/VmtlW Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Sat, 14 Apr 2007 19:18:42 -0300 Alejandro Pulver wrote: > Hello. >=20 > I have enabled logging in Gaim, and when a chat message arrives and it > is logged the disk writing delays (freezes) the system for less than a > second, it can be noticed for example with XMMS which does a strange > sound during that period. >=20 > I think this problem is related to the system and not the port, that's > why I asked here. Also I guess more information is needed about this, > like ktrace/truss output of Gaim together with kernel statistics > (vmstat/iostat). But other than ktrace, I don't use them. What would be > the commands to get the most relevant information about this? >=20 > I am using FreeBSD 6.2-RELEASE, and the boot message is here (the file > dmesg_machine_2.txt): >=20 > http://people.freebsd.org/~alepulver/disk-crash.tar.bz2 >=20 > Thanks and Best Regards, > Ale >=20 > P.S.: please CC me as I'm not subscribed. Hello. The issue only happens with gaim-devel, and seems to be related to the sound system (doesn't happen when disabling sounds). Sorry for the noise, I've been somewhat paranoid with this because it happened when I had a broken NVidia card (or incompatible with my motherboard), and some disk problems (these were apparently fixed in FreeBSD 6.2). So I thought it was a kernel problem (it happened on a machine with an old disk and on a new one so I discarded the possibility of hardware failing). Anyways the system does freeze for less than a second when that happens. I will make a more descriptive thread about this. Best Regards, Ale P.S.: I've also sent this to freebsd-performance@, because I thought that was more appropiate when I thought it was a disk driver problem. --Sig_3Qrnxx9nmgKjoue_f/VmtlW Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGLBiiiV05EpRcP2ERAtR8AJ0RqGMbsrJmn889XOJ42Y8RfZAtzACfexTj gRQAVDTVV2qOVY2ZIOnW7Wk= =wBnr -----END PGP SIGNATURE----- --Sig_3Qrnxx9nmgKjoue_f/VmtlW-- From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 23 02:26:37 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DFE3E16A401 for ; Mon, 23 Apr 2007 02:26:37 +0000 (UTC) (envelope-from alepulver@FreeBSD.org) Received: from relay01.pair.com (relay01.pair.com [209.68.5.15]) by mx1.freebsd.org (Postfix) with SMTP id 979FF13C468 for ; Mon, 23 Apr 2007 02:26:37 +0000 (UTC) (envelope-from alepulver@FreeBSD.org) Received: (qmail 31194 invoked by uid 0); 23 Apr 2007 02:26:35 -0000 Received: from 190.55.91.88 (HELO deimos.mars.bsd) (190.55.91.88) by relay01.pair.com with SMTP; 23 Apr 2007 02:26:35 -0000 X-pair-Authenticated: 190.55.91.88 Date: Sun, 22 Apr 2007 23:26:33 -0300 From: Alejandro Pulver To: Garrett Cooper Message-ID: <20070422232633.2390b1e2@deimos.mars.bsd> In-Reply-To: <462318CB.3030205@u.washington.edu> References: <20070414184719.110deaa2@deimos.mars.bsd> <46217486.6080801@u.washington.edu> <20070415161753.7c7a604d@deimos.mars.bsd> <462318CB.3030205@u.washington.edu> X-Mailer: Claws Mail 2.8.1 (GTK+ 2.10.11; i386-portbld-freebsd6.2) Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_PDFt=oc._LDuK4anFqi.32k"; protocol="application/pgp-signature"; micalg=PGP-SHA1 Cc: freebsd-hackers@freebsd.org Subject: Re: High disk load +mount/atacontrol/NFS/SMBFS crashes the system 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, 23 Apr 2007 02:26:38 -0000 --Sig_PDFt=oc._LDuK4anFqi.32k Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Sun, 15 Apr 2007 23:33:47 -0700 Garrett Cooper wrote: > Ale, > I'm not sure what's going on exactly based on the information you=20 > provided, but I would try the following steps to isolate the issue: >=20 > 1) See if you can upgrade the first machine to a later version of=20 > FreeBSD, say 6.2. I believe that there were related issues resolved in=20 > 6.2, but my memory could be incorrect. See if your problems occur after=20 > that. I did that. > 2) Try grabbing a different machine if possible and see if the same=20 > issue occurs when you put the new machine as server and client with one=20 > of the other machines. I used a Win XP machine as client / server. > 3) Try switching roles with the 2 machines. If machine 1 is usually=20 > server, let it play client and vice versa with machine 2. Also did this. > 4) Remove the new drive if possible, see if issue goes away. If it does,= =20 > try acquiring a cheap(er) drive and put it >=20 It's the only drive it has, I meant the second machine is all new, not just the disk. > Also, it appears that another FreeBSD team member had a similar issue=20 > (see: http://people.freebsd.org/~pho/stress/log/cons205.html and=20 > http://people.freebsd.org/~pho/stress/log/cons225.html). I dunno how but= =20 > it showed up as one of the leading searches on Google. >=20 > It looks like a (localized) filesystem issue, but I'm not sure what it=20 > is exactly. >=20 The fsync() problem seems to be related to that, but the rest could be be a different thing. Also I only got it twice. Maybe the filesystem issues were only derived from the crashes. I was unable to reproduce the problem in the first machine, maybe it was fixed on FreeBSD 6.2 as you said. The only things I also did when testing was unloading fuse.ko (unused) and linprocfs.ko (after umounting it). However I will test it a few times more, and let you know the results. The strange crash in the new 6.2 machine when using atacontrol is still unexplained and I couldn't make it happen again (it now refuses to switch to UDMA100 mode when it is SATA300, maybe they aren't supported in SATA drives, but the other time it just crashed without advise). Thank you for your help with this. Best Regards, Ale --Sig_PDFt=oc._LDuK4anFqi.32k Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGLBlZiV05EpRcP2ERAl5xAJ9Hxx49S72NKCiEkh9KLfcet+Wp1wCgywV+ p87NmVltt8WF5HE6KbyZG4A= =6XJe -----END PGP SIGNATURE----- --Sig_PDFt=oc._LDuK4anFqi.32k-- From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 23 15:50:10 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D3DA716A400 for ; Mon, 23 Apr 2007 15:50:10 +0000 (UTC) (envelope-from spap13@googlemail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.226]) by mx1.freebsd.org (Postfix) with ESMTP id 9213413C4B0 for ; Mon, 23 Apr 2007 15:50:08 +0000 (UTC) (envelope-from spap13@googlemail.com) Received: by nz-out-0506.google.com with SMTP id r28so1367763nza for ; Mon, 23 Apr 2007 08:50:08 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=googlemail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=gb9hPNqNiW2OZGJ9oIfYzXWCsIby4AegDw3+mIw3iWUKwki47C5CZ+4Gpctp49W+NJNBsXTIqyWW/9dHE/mBNlnrO1odXGYtAVBNsuUHBKdLCp5GWof88s57b0mTWnWtLaaucu//sQuE9uY5u3QXzSBeFyTd8h+/0MnfRBPpVB8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=dAyoG+/HHvvWGIiq59ffgBikmWHSXbfgr+XbD4RIzL7LZiQFrFQZNHoEzc+gIuas/5NIR0UqloEePp8Nsr/nc5IJ86/RQ8TJbeg1Hi1SnlXNPHRiDsd/oUaTt/aAIsEkC4eSVQzRUdDI4h0wQzgKzrPGI6ZCnjN/24+Ou7Us5iA= Received: by 10.114.173.15 with SMTP id v15mr2595943wae.1177343407295; Mon, 23 Apr 2007 08:50:07 -0700 (PDT) Received: by 10.115.54.16 with HTTP; Mon, 23 Apr 2007 08:50:07 -0700 (PDT) Message-ID: Date: Mon, 23 Apr 2007 11:50:07 -0400 From: "Spiros Papadopoulos" To: freebsd-questions@freebsd.org, freebsd-hackers@freebsd.org In-Reply-To: MIME-Version: 1.0 References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: Linksys wireless pcmcia card / FreeBSD 6.2-RELEASE 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, 23 Apr 2007 15:50:11 -0000 Allthough i have set to yes the option about "receiving your messages to the list" I didn't receive it. In addition i haven't received any reply so far. Could somebody confirm that my message was sent properly to the list. Thanks, Spiros On 21/04/07, Spiros Papadopoulos wrote: > > Hi, > > I am running FreeBSD 6.2 RELEASE and I have the above card in my DELL's > latitude c810 cardbus. > > I followed the instructions on the page below and configure the kernel > accordingly: > > http://www.freebsdmall.com/~loader/en_US.ISO8859-1 > /articles/wireless/article.html > > i get the message about: > > cardbus0: CIS pointer is 0 > cardbus0: Resource not specified in CIS > > which takes me to the post below...: > > http://freebsd.monkey.org/freebsd-stable/200607/msg00449.html > > I guess i need to tweak the windows driver or anyway hack it somehow. The > problem is that i 've never done anything similar before > but i would like to get involved and make it work. > > Anybody can point me to the right direction ? If the above is not the best > solution i would really appreciate pointing me to > the best alternative. > > thanks in advance > Spiros P. -- Spiros P. From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 23 16:48:55 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E213216A401; Mon, 23 Apr 2007 16:48:55 +0000 (UTC) (envelope-from raggen@passagen.se) Received: from av11-1-sn2.hy.skanova.net (av11-1-sn2.hy.skanova.net [81.228.8.183]) by mx1.freebsd.org (Postfix) with ESMTP id 6A01E13C457; Mon, 23 Apr 2007 16:48:55 +0000 (UTC) (envelope-from raggen@passagen.se) Received: by av11-1-sn2.hy.skanova.net (Postfix, from userid 502) id DD97B385AB; Mon, 23 Apr 2007 18:28:07 +0200 (CEST) Received: from smtp4-1-sn2.hy.skanova.net (smtp4-1-sn2.hy.skanova.net [81.228.8.92]) by av11-1-sn2.hy.skanova.net (Postfix) with ESMTP id BD3F2385A8; Mon, 23 Apr 2007 18:28:07 +0200 (CEST) Received: from [192.168.1.6] (81-231-90-251-no41.tbcn.telia.com [81.231.90.251]) by smtp4-1-sn2.hy.skanova.net (Postfix) with ESMTP id 9B0DE37E48; Mon, 23 Apr 2007 18:28:07 +0200 (CEST) Message-ID: <462CDE7D.5020203@passagen.se> Date: Mon, 23 Apr 2007 18:27:41 +0200 From: Roger Olofsson User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Alejandro Pulver , freebsd-hackers@freebsd.org References: <20070414184719.110deaa2@deimos.mars.bsd> <46217486.6080801@u.washington.edu> <20070415161753.7c7a604d@deimos.mars.bsd> <462318CB.3030205@u.washington.edu> <20070422232633.2390b1e2@deimos.mars.bsd> In-Reply-To: <20070422232633.2390b1e2@deimos.mars.bsd> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: High disk load +mount/atacontrol/NFS/SMBFS crashes the system 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, 23 Apr 2007 16:48:56 -0000 Alejandro Pulver skrev: > On Sun, 15 Apr 2007 23:33:47 -0700 > Garrett Cooper wrote: > >> Ale, >> I'm not sure what's going on exactly based on the information you >> provided, but I would try the following steps to isolate the issue: >> >> 1) See if you can upgrade the first machine to a later version of >> FreeBSD, say 6.2. I believe that there were related issues resolved in >> 6.2, but my memory could be incorrect. See if your problems occur after >> that. > > I did that. > >> 2) Try grabbing a different machine if possible and see if the same >> issue occurs when you put the new machine as server and client with one >> of the other machines. > > I used a Win XP machine as client / server. > >> 3) Try switching roles with the 2 machines. If machine 1 is usually >> server, let it play client and vice versa with machine 2. > > Also did this. > >> 4) Remove the new drive if possible, see if issue goes away. If it does, >> try acquiring a cheap(er) drive and put it >> > > It's the only drive it has, I meant the second machine is all new, not > just the disk. > >> Also, it appears that another FreeBSD team member had a similar issue >> (see: http://people.freebsd.org/~pho/stress/log/cons205.html and >> http://people.freebsd.org/~pho/stress/log/cons225.html). I dunno how but >> it showed up as one of the leading searches on Google. >> >> It looks like a (localized) filesystem issue, but I'm not sure what it >> is exactly. >> > > The fsync() problem seems to be related to that, but the rest could be > be a different thing. Also I only got it twice. Maybe the filesystem > issues were only derived from the crashes. > > I was unable to reproduce the problem in the first machine, maybe it > was fixed on FreeBSD 6.2 as you said. The only things I also did when > testing was unloading fuse.ko (unused) and linprocfs.ko (after > umounting it). However I will test it a few times more, and let you > know the results. > > The strange crash in the new 6.2 machine when using atacontrol is still > unexplained and I couldn't make it happen again (it now refuses to > switch to UDMA100 mode when it is SATA300, maybe they aren't supported > in SATA drives, but the other time it just crashed without advise). > > Thank you for your help with this. > > Best Regards, > Ale Dear Ale, I have experienced something similar as you described when this thread started. The solution for me was to exchange the NIC I had for one that worked better. I learned that using cheap nics with realtek chips causes crashes even on the most stable operating system in the world. When I browsed the source code for the driver of the realtek-based nic I regretted I hadn't done so earlier. The comments were _crystal_ clear about the design and performance of it. See /usr/src/sys/pci/if_rl.c. I particularly liked the following bit: /* * Here's a totally undocumented fact for you. When the * RealTek chip is in the process of copying a packet into * RAM for you, the length will be 0xfff0. If you spot a * packet header with this value, you need to stop. The * datasheet makes absolutely no mention of this and * RealTek should be shot for this. */ Hope you will solve the issue! Greetings /Roger From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 23 18:31:43 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BD06C16A404 for ; Mon, 23 Apr 2007 18:31:43 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.freebsd.org (Postfix) with ESMTP id 626FD13C45A for ; Mon, 23 Apr 2007 18:31:43 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id l3NIVMhA049442; Mon, 23 Apr 2007 14:31:34 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Mon, 23 Apr 2007 14:29:57 -0400 User-Agent: KMail/1.9.6 References: <04E232FDCD9FBE43857F7066CAD3C0F12DF19D@svmailmel.bytecraft.internal> In-Reply-To: <04E232FDCD9FBE43857F7066CAD3C0F12DF19D@svmailmel.bytecraft.internal> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200704231429.58036.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Mon, 23 Apr 2007 14:31:35 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/3151/Mon Apr 23 12:11:26 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Murray Taylor Subject: Re: FW: IBM / FreeBSD - Install Update - Seems to be ACPI 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, 23 Apr 2007 18:31:43 -0000 On Thursday 19 April 2007 12:33:08 am Murray Taylor wrote: > > In our initial posts, we stated that we seemed to be having issues > getting the machine to boot with the 4 processors, so to bypass this we > disabled ACPI on boot. This allowed us to get past the CPU error and > continue to boot. However down the track we noticed things like the > ethernet adapater not getting picked up, and the big problem - none of > the disks getting recognised. > > We have since tried a few things, one of which was removing all but one > of the CPU's. If we do this, and boot with ACPI enabled, all is totally > fine. All disks are found, and I receive no CPU panic error. Yes, ACPI enumerates Host-PCI bridges, and trying to enumerate them w/o ACPI is a bit of a guessing game. > So it appears to me that by disabling ACPI in an attempt to bypass the > QUAD CPU problem, we are causing another issue behind the scenes. > > The root of the problem now appears to be, that if we have anything over > 1 CPU, directly after the kernel is loaded (when booting from the CD), > we receive the error message "panic: madt_probe_cpus_handler: CPU ID 38 > Too High". The moment a second CPU to the machine....it bombs out. You can use 'set hint.apic.0.disabled=1' for now to keep ACPI and just disable SMP for now. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 23 18:31:55 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 899CA16A402 for ; Mon, 23 Apr 2007 18:31:55 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.freebsd.org (Postfix) with ESMTP id 3135313C448 for ; Mon, 23 Apr 2007 18:31:55 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id l3NIVMh9049442; Mon, 23 Apr 2007 14:31:31 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Mon, 23 Apr 2007 14:28:25 -0400 User-Agent: KMail/1.9.6 References: <200704191736.l3JHad0E057895@casselton.net> <86y7ko2n8b.fsf@dwp.des.no> In-Reply-To: <86y7ko2n8b.fsf@dwp.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200704231428.26118.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Mon, 23 Apr 2007 14:31:33 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/3151/Mon Apr 23 12:11:26 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?= , Mark Tinguely , freebsd-questions@freebsd.org, MTaylor@bytecraft.com.au Subject: Re: IBM / FreeBSD Install problem 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, 23 Apr 2007 18:31:55 -0000 On Thursday 19 April 2007 03:11:32 pm Dag-Erling Sm=F8rgrav wrote: > Mark Tinguely writes: > > I suggested that in email too, but looking closer, I think the MAXCPU > > needs to be increased because the cpu number uses the apic_id. Or could > > that be changed with a logical CPU to APIC ID lookup? > > > > Isn't the APIC IDs programmable? not that I am suggesting that, I > > can think of headaches of all the places (like interrupt tables) > > where it needs to be changed, not to mention the worry that the > > lower APIC IDs were assigned to IOAPICs. >=20 > I don't know, you'd have to ask jhb@ about the details. APIC IDs are not programmable (well, they are on I/O APICs, but not local=20 APICs). However, I am working on patches to support all valid APIC IDs for= =20 both mptable and MADT. Bumping up NLAPICS as a temporary workaround should= =20 suffice for now. =2D-=20 John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 23 19:54:14 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 04FBD16A484; Mon, 23 Apr 2007 19:54:14 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.freebsd.org (Postfix) with ESMTP id 9B4F113C45D; Mon, 23 Apr 2007 19:54:13 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id l3NJrnV3049908; Mon, 23 Apr 2007 15:53:55 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: Mark Tinguely Date: Mon, 23 Apr 2007 15:02:16 -0400 User-Agent: KMail/1.9.6 References: <200704231851.l3NIpJ7H071370@casselton.net> In-Reply-To: <200704231851.l3NIpJ7H071370@casselton.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200704231502.16968.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Mon, 23 Apr 2007 15:53:56 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/3151/Mon Apr 23 12:11:26 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: freebsd-hackers@freebsd.org, MTaylor@bytecraft.com.au, freebsd-questions@freebsd.org, des@des.no Subject: Re: IBM / FreeBSD Install problem 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, 23 Apr 2007 19:54:14 -0000 On Monday 23 April 2007 02:51:19 pm Mark Tinguely wrote: > > > John Baldwin says: > > > > APIC IDs are not programmable (well, they are on I/O APICs, but not local=20 > > APICs). However, I am working on patches to support all valid APIC IDs for= > > =20 > > both mptable and MADT. Bumping up NLAPICS as a temporary workaround should= > > =20 > > suffice for now. > > > > =2D-=20 > > John Baldwin > > IMO, the quick solution also requires that MAX_APICID in > [amd64/amd64 | i386/i386]/local_apic.c needs to be changed > because lapic_create() checks if the passed apic_id > MAX_APICID. > > Also in [amd64/amd64 | i386/i386]/mp_machdep.c checks in cpu_add() > if the passed apic_id >= MAXCPU. There are a couple other checks > in mp_machdep.c before converting to use the cpu_apic_ids[] array. > > I was curious, and wrote up a patch file with the potential minor changes > for -current at http://www.casselton.com/~tinguely/acpicid.patch . > I saw one more change needed to use on FreeBSD 6.2-RELEASE. What I have so far is somewhat similar, but goes ahead and allows the full range of APIC IDs while trying to still honor MAXCPU correctly. I haven't ported it to i386 yet, nor compiled it yet, much less booted it. :) I hope to at least get it booted on amd64 today. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 23 18:51:26 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id ECEDD16A40A; Mon, 23 Apr 2007 18:51:25 +0000 (UTC) (envelope-from tinguely@casselton.net) Received: from casselton.net (casselton.net [63.165.140.2]) by mx1.freebsd.org (Postfix) with ESMTP id 96B1E13C4CC; Mon, 23 Apr 2007 18:51:25 +0000 (UTC) (envelope-from tinguely@casselton.net) Received: from casselton.net (localhost [127.0.0.1]) by casselton.net (8.13.8/8.13.8) with ESMTP id l3NIpJo8071371; Mon, 23 Apr 2007 13:51:19 -0500 (CDT) (envelope-from tinguely@casselton.net) Received: (from tinguely@localhost) by casselton.net (8.13.8/8.13.8/Submit) id l3NIpJ7H071370; Mon, 23 Apr 2007 13:51:19 -0500 (CDT) (envelope-from tinguely) Date: Mon, 23 Apr 2007 13:51:19 -0500 (CDT) From: Mark Tinguely Message-Id: <200704231851.l3NIpJ7H071370@casselton.net> To: freebsd-hackers@freebsd.org, jhb@freebsd.org In-Reply-To: <200704231428.26118.jhb@freebsd.org> X-Mailman-Approved-At: Mon, 23 Apr 2007 21:04:53 +0000 Cc: des@des.no, tinguely@casselton.net, freebsd-questions@freebsd.org, MTaylor@bytecraft.com.au Subject: Re: IBM / FreeBSD Install problem 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, 23 Apr 2007 18:51:26 -0000 > John Baldwin says: > > APIC IDs are not programmable (well, they are on I/O APICs, but not local=20 > APICs). However, I am working on patches to support all valid APIC IDs for= > =20 > both mptable and MADT. Bumping up NLAPICS as a temporary workaround should= > =20 > suffice for now. > > =2D-=20 > John Baldwin IMO, the quick solution also requires that MAX_APICID in [amd64/amd64 | i386/i386]/local_apic.c needs to be changed because lapic_create() checks if the passed apic_id > MAX_APICID. Also in [amd64/amd64 | i386/i386]/mp_machdep.c checks in cpu_add() if the passed apic_id >= MAXCPU. There are a couple other checks in mp_machdep.c before converting to use the cpu_apic_ids[] array. I was curious, and wrote up a patch file with the potential minor changes for -current at http://www.casselton.com/~tinguely/acpicid.patch . I saw one more change needed to use on FreeBSD 6.2-RELEASE. --Mark Tinguely From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 24 00:59:59 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E5A6C16A402 for ; Tue, 24 Apr 2007 00:59:59 +0000 (UTC) (envelope-from alepulver@FreeBSD.org) Received: from relay03.pair.com (relay03.pair.com [209.68.5.17]) by mx1.freebsd.org (Postfix) with SMTP id 9E40F13C459 for ; Tue, 24 Apr 2007 00:59:59 +0000 (UTC) (envelope-from alepulver@FreeBSD.org) Received: (qmail 25026 invoked by uid 0); 24 Apr 2007 00:59:50 -0000 Received: from 190.55.91.88 (HELO deimos.mars.bsd) (190.55.91.88) by relay03.pair.com with SMTP; 24 Apr 2007 00:59:50 -0000 X-pair-Authenticated: 190.55.91.88 Date: Mon, 23 Apr 2007 21:58:58 -0300 From: Alejandro Pulver To: Garrett Cooper Message-ID: <20070423215858.74c29e98@deimos.mars.bsd> In-Reply-To: <20070422232633.2390b1e2@deimos.mars.bsd> References: <20070414184719.110deaa2@deimos.mars.bsd> <46217486.6080801@u.washington.edu> <20070415161753.7c7a604d@deimos.mars.bsd> <462318CB.3030205@u.washington.edu> <20070422232633.2390b1e2@deimos.mars.bsd> X-Mailer: Claws Mail 2.8.1 (GTK+ 2.10.11; i386-portbld-freebsd6.2) Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_H=zhMGuuZLh5pTKBsqzNhE9"; protocol="application/pgp-signature"; micalg=PGP-SHA1 Cc: freebsd-hackers@freebsd.org Subject: Re: High disk load +mount/atacontrol/NFS/SMBFS crashes the system 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, 24 Apr 2007 01:00:00 -0000 --Sig_H=zhMGuuZLh5pTKBsqzNhE9 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Sun, 22 Apr 2007 23:26:33 -0300 Alejandro Pulver wrote: [...] > The strange crash in the new 6.2 machine when using atacontrol is still > unexplained and I couldn't make it happen again (it now refuses to > switch to UDMA100 mode when it is SATA300, maybe they aren't supported > in SATA drives, but the other time it just crashed without advise). >=20 In the machine which was recently upgraded to 6.2 using "atacontrol" when the disk is reading/writing crashes the system half or more of the times. Maybe it's a BIOS or hard disk issue, but I can't try it in the new machine because it uses "SATA300" and other modes aren't documented in the manual page. The other machine supports UDMA* modes. Otherwise there is a problem in "atacontrol". When this happens, the disk light keeps blinking but the system freezes, and keeps waiting for the disk to respond forever. Best Regards, Ale --Sig_H=zhMGuuZLh5pTKBsqzNhE9 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGLVZSiV05EpRcP2ERAq12AKC40He/3EDT1HLyE/PCSsc9GZjGSACfW9wZ 2VSJ+/tOVz8TKUOx8jyqE04= =r8ZA -----END PGP SIGNATURE----- --Sig_H=zhMGuuZLh5pTKBsqzNhE9-- From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 24 03:59:48 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D55D216A400 for ; Tue, 24 Apr 2007 03:59:48 +0000 (UTC) (envelope-from rick@kiwi-computer.com) Received: from kiwi-computer.com (keira.kiwi-computer.com [63.224.10.3]) by mx1.freebsd.org (Postfix) with SMTP id 5F96313C45B for ; Tue, 24 Apr 2007 03:59:47 +0000 (UTC) (envelope-from rick@kiwi-computer.com) Received: (qmail 9849 invoked by uid 2001); 24 Apr 2007 03:59:44 -0000 Date: Mon, 23 Apr 2007 22:59:44 -0500 From: "Rick C. Petty" To: Alejandro Pulver Message-ID: <20070424035944.GA9695@keira.kiwi-computer.com> References: <20070414184719.110deaa2@deimos.mars.bsd> <46217486.6080801@u.washington.edu> <20070415161753.7c7a604d@deimos.mars.bsd> <462318CB.3030205@u.washington.edu> <20070422232633.2390b1e2@deimos.mars.bsd> <20070423215858.74c29e98@deimos.mars.bsd> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070423215858.74c29e98@deimos.mars.bsd> User-Agent: Mutt/1.4.2.1i Cc: freebsd-hackers@freebsd.org Subject: Re: High disk load +mount/atacontrol/NFS/SMBFS crashes the system X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rick-freebsd@kiwi-computer.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2007 03:59:48 -0000 On Mon, Apr 23, 2007 at 09:58:58PM -0300, Alejandro Pulver wrote: > > In the machine which was recently upgraded to 6.2 using "atacontrol" > when the disk is reading/writing crashes the system half or more of the > times. Which atacontrol command were you doing? Just plain "atacontrol" shouldn't do anything useful. -- Rick C. Petty From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 24 23:21:33 2007 Return-Path: X-Original-To: FreeBSD-Hackers@FreeBSD.org Delivered-To: FreeBSD-Hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 98C4516A401 for ; Tue, 24 Apr 2007 23:21:33 +0000 (UTC) (envelope-from jan@digitaldaemon.com) Received: from digitaldaemon.com (digitaldaemon.com [63.105.9.34]) by mx1.freebsd.org (Postfix) with SMTP id 16DA113C4AD for ; Tue, 24 Apr 2007 23:21:32 +0000 (UTC) (envelope-from jan@digitaldaemon.com) Received: (qmail 76969 invoked by uid 98); 24 Apr 2007 23:21:31 -0000 Received: from 63.105.9.34 by digitaldaemon.com (envelope-from , uid 89) with qmail-scanner-1.25 (clamdscan: 0.87/1195. Clear:RC:1(63.105.9.34):. Processed in 0.042571 secs); 24 Apr 2007 23:21:31 -0000 X-Qmail-Scanner-Mail-From: jan@digitaldaemon.com via digitaldaemon.com X-Qmail-Scanner: 1.25 (Clear:RC:1(63.105.9.34):. Processed in 0.042571 secs) Received: from digitaldaemon.com (HELO ?192.80.151.2?) (63.105.9.34) by digitaldaemon.com with SMTP; 24 Apr 2007 23:21:31 -0000 Message-ID: <462E90FA.70004@digitaldaemon.com> Date: Tue, 24 Apr 2007 19:21:30 -0400 From: Jan Knepper User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Mohacsi Janos References: <45F1C355.8030504@digitaldaemon.com> <20070310082316.K64466@mignon.ki.iif.hu> <4628D3EA.6060405@digitaldaemon.com> <20070422122342.Y32158@mignon.ki.iif.hu> In-Reply-To: <20070422122342.Y32158@mignon.ki.iif.hu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Hackers Subject: Re: Multiple IP Jail's patch for FreeBSD 6.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, 24 Apr 2007 23:21:33 -0000 Mohacsi Janos wrote: > On Fri, 20 Apr 2007, Jan Knepper wrote: > >> Mohacsi Janos wrote: >>> Hi Jan, >>> The problem with your patch is the missing IPv6 support. >> I know... So what you are saying it does not work? > > No. I am saying, that worth considering IPv6 support too. Definitely... especially since we better be prepared. As far as I know IPv6 is not widely being used (yet) so that would give time... With that regard I do not see an issue to include it for IPv4 now. >> I know... However... If you could get me a version of DragonFlyBSD >> that supports amd64 I might consider switching... > The drafonfly version already supports it. > > I don't want you to convince to switch to DragonFlyBSD. I *was* considering it some time before... However.. The reason has been mentioned... Thanks! Jan From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 25 00:20:39 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0EBB316A400 for ; Wed, 25 Apr 2007 00:20:39 +0000 (UTC) (envelope-from alepulver@FreeBSD.org) Received: from relay00.pair.com (relay00.pair.com [209.68.5.9]) by mx1.freebsd.org (Postfix) with SMTP id A07C513C45A for ; Wed, 25 Apr 2007 00:20:38 +0000 (UTC) (envelope-from alepulver@FreeBSD.org) Received: (qmail 27326 invoked by uid 0); 25 Apr 2007 00:20:36 -0000 Received: from 190.55.91.88 (HELO deimos.mars.bsd) (190.55.91.88) by relay00.pair.com with SMTP; 25 Apr 2007 00:20:36 -0000 X-pair-Authenticated: 190.55.91.88 Date: Tue, 24 Apr 2007 21:20:27 -0300 From: Alejandro Pulver To: rick-freebsd@kiwi-computer.com Message-ID: <20070424212027.1d7071e6@deimos.mars.bsd> In-Reply-To: <20070424035944.GA9695@keira.kiwi-computer.com> References: <20070414184719.110deaa2@deimos.mars.bsd> <46217486.6080801@u.washington.edu> <20070415161753.7c7a604d@deimos.mars.bsd> <462318CB.3030205@u.washington.edu> <20070422232633.2390b1e2@deimos.mars.bsd> <20070423215858.74c29e98@deimos.mars.bsd> <20070424035944.GA9695@keira.kiwi-computer.com> X-Mailer: Claws Mail 2.8.1 (GTK+ 2.10.11; i386-portbld-freebsd6.2) Mime-Version: 1.0 Content-Type: multipart/signed; boundary=Sig_Dl1Zvj2Jai2z0DYT2X6Ly53; protocol="application/pgp-signature"; micalg=PGP-SHA1 Cc: freebsd-hackers@freebsd.org Subject: Re: High disk load +mount/atacontrol/NFS/SMBFS crashes the system 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, 25 Apr 2007 00:20:39 -0000 --Sig_Dl1Zvj2Jai2z0DYT2X6Ly53 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Mon, 23 Apr 2007 22:59:44 -0500 "Rick C. Petty" wrote: > On Mon, Apr 23, 2007 at 09:58:58PM -0300, Alejandro Pulver wrote: > >=20 > > In the machine which was recently upgraded to 6.2 using "atacontrol" > > when the disk is reading/writing crashes the system half or more of the > > times. >=20 > Which atacontrol command were you doing? Just plain "atacontrol" shouldn= 't > do anything useful. >=20 To change DMA modes, like: # atacontrol mode ad0 UDMA100 Best Regards, Ale --Sig_Dl1Zvj2Jai2z0DYT2X6Ly53 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGLp7LiV05EpRcP2ERAotNAJ4uW3j6uloSBflpolI7QHHgBovu7ACfQaJa HP0l9wxrSDVH6wCEe7fB+BU= =FK7F -----END PGP SIGNATURE----- --Sig_Dl1Zvj2Jai2z0DYT2X6Ly53-- From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 25 03:27:38 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 59A4116A401 for ; Wed, 25 Apr 2007 03:27:38 +0000 (UTC) (envelope-from artifact.one@googlemail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.227]) by mx1.freebsd.org (Postfix) with ESMTP id 1A84B13C458 for ; Wed, 25 Apr 2007 03:27:37 +0000 (UTC) (envelope-from artifact.one@googlemail.com) Received: by wr-out-0506.google.com with SMTP id 70so76899wra for ; Tue, 24 Apr 2007 20:27:37 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=googlemail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=ZdX3PYovu4/BZj0Z92SxQo3Z8LwhkAW+iW8Xv0GYWCU1CfGn3f2yGQ48klFi6bTuTxBusYinzSGa6CaayE4+/GqTA/wUcfnr/ROpGMlJI8qy97JEefL8McPfHIyKffR5QtMX50+5bKcj+8jSwJis0OmHApVwu2h3+qrchJ0rQBk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=O8aHi1vCN5ui9zMh/q51mu11WcUI+xftZYZqTLAHg7zjSciEY0iIQYQNdc+s1JoBaMmFxFvsfcKQ8MV952YJEQkof3iXaZ8mpZaKrMMfm9qPCtIyfrMRqN3oDC6MJKZCtWWRRyjQgIa7Y6sX5yyenLM49Y6ntMuyeeCcICZqiAo= Received: by 10.90.54.4 with SMTP id c4mr125710aga.1177470105482; Tue, 24 Apr 2007 20:01:45 -0700 (PDT) Received: by 10.90.79.16 with HTTP; Tue, 24 Apr 2007 20:01:45 -0700 (PDT) Message-ID: <8e96a0b90704242001g28a32eav592d0a8576f1297a@mail.gmail.com> Date: Wed, 25 Apr 2007 04:01:45 +0100 From: "mal content" To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: SIGFPE with libthr and gdb 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, 25 Apr 2007 03:27:38 -0000 Hello. When using this libmap.conf: libpthread.so.2 libthr.so.2 libpthread.so libthr.so libc_r.so.6 libthr.so.2 libc_r.so libthr.so ...nearly every program receives SIGFPE when calling various functions, when running under gdb. strtol() is one example. Is this a well known problem, before I file a bug report? I'm on FreeBSD 6.2-RELEASE. MC From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 25 07:25:23 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4633D16A407 for ; Wed, 25 Apr 2007 07:25:23 +0000 (UTC) (envelope-from davidxu@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id 3536113C44C; Wed, 25 Apr 2007 07:25:23 +0000 (UTC) (envelope-from davidxu@freebsd.org) Received: from [127.0.0.1] (root@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id l3P7PLa9001776; Wed, 25 Apr 2007 07:25:22 GMT (envelope-from davidxu@freebsd.org) Message-ID: <462F027B.5010809@freebsd.org> Date: Wed, 25 Apr 2007 15:25:47 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.13) Gecko/20061204 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mal content References: <8e96a0b90704242001g28a32eav592d0a8576f1297a@mail.gmail.com> In-Reply-To: <8e96a0b90704242001g28a32eav592d0a8576f1297a@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: SIGFPE with libthr and gdb 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, 25 Apr 2007 07:25:23 -0000 mal content wrote: > Hello. > > When using this libmap.conf: > > libpthread.so.2 libthr.so.2 > libpthread.so libthr.so > libc_r.so.6 libthr.so.2 > libc_r.so libthr.so > > ...nearly every program receives SIGFPE when calling various > functions, when running under gdb. strtol() is one example. > > Is this a well known problem, before I file a bug report? > > I'm on FreeBSD 6.2-RELEASE. > > MC try to update fbsd-threads.c to revision 1.13.2.3, this may resolve the problem. http://www.freebsd.org/cgi/cvsweb.cgi/src/gnu/usr.bin/gdb/libgdb/fbsd-threads.c Regards, David Xu From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 25 11:44:22 2007 Return-Path: X-Original-To: FreeBSD-Hackers@FreeBSD.org Delivered-To: FreeBSD-Hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A43B816A402 for ; Wed, 25 Apr 2007 11:44:22 +0000 (UTC) (envelope-from ah@crypta.net) Received: from mail.crypta.net (mail.crypta.net [83.136.131.3]) by mx1.freebsd.org (Postfix) with ESMTP id 66DEE13C465 for ; Wed, 25 Apr 2007 11:44:22 +0000 (UTC) (envelope-from ah@crypta.net) Received: by mail.crypta.net (cryptobank/eProtect-smtpd, from userid 1001) id 2DAF1ECD4CB; Wed, 25 Apr 2007 13:44:21 +0200 (CEST) Date: Wed, 25 Apr 2007 13:44:21 +0200 From: ah@crypta.net To: Jan Knepper Message-ID: <20070425114421.GA6750@mail.crypta.net> References: <45F1C355.8030504@digitaldaemon.com> <20070310082316.K64466@mignon.ki.iif.hu> <4628D3EA.6060405@digitaldaemon.com> <20070420192041.GA83236@mail.crypta.net> <46294699.7040501@digitaldaemon.com> <20070421115712.GB41964@mail.crypta.net> <462D07F2.5020706@digitaldaemon.com> <20070424072149.GA97533@mail.crypta.net> <462E9011.5070809@digitaldaemon.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <462E9011.5070809@digitaldaemon.com> User-Agent: Mutt/1.4.2.2i X-PGP-Key: http://wwwkeys.pgp.net:11371/pks/lookup?op=get&search=0xEC6E1071 X-PGP-Fingerprint: 9B2E 5892 AD93 D5C5 FB8E 3912 35D6 951B EC6E 1071 Organization: cryptobank - Andy Hilker Cc: FreeBSD-Hackers@FreeBSD.org Subject: Re: Multiple IP Jail's patch for FreeBSD 6.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: Wed, 25 Apr 2007 11:44:22 -0000 You (Jan Knepper) wrote: > Multiple IP's in a jail out-of-the-box would be great... Yes, I hope it will be included in 7.0... From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 25 19:28:36 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 99F8016A401 for ; Wed, 25 Apr 2007 19:28:36 +0000 (UTC) (envelope-from stas.ibragimov@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.172]) by mx1.freebsd.org (Postfix) with ESMTP id 49DA713C457 for ; Wed, 25 Apr 2007 19:28:34 +0000 (UTC) (envelope-from stas.ibragimov@gmail.com) Received: by ug-out-1314.google.com with SMTP id 71so423395ugh for ; Wed, 25 Apr 2007 12:28:34 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:date:to:subject:message-id:mime-version:content-type:content-disposition:user-agent:from; b=PBMA7M1Hr4iKh3eYgAyUDZXdGqNcY2QymXlrSl3YwOQHq5lA8838qrin0jP1B5LpXs50Hh2gBu4nByMiRcCUPv7UW4mezY7nqz5NmibjcAPZf5fnqgVB2ANI7w0jPiLDjCn+XdYVmuqjIqjXFpt9IONaOSpPzly3mnWIM7ZMlLc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:date:to:subject:message-id:mime-version:content-type:content-disposition:user-agent:from; b=DTFhxJuFU0q7CzeDekWGYl4A2tfkyuzjdzp1Ugj9iNsKYQezlxtbhqNszEBO2JgRnrp+YPGz3VIs/oTj5GpCFSKe8pKvLKLJqdweb0gU7TcpxwZWLzRPXMHyS0ouKbPfyrKjkc1pvYVQXzp3VFtwweSbITxgnIxMsdvlf9CymTU= Received: by 10.66.242.19 with SMTP id p19mr1617166ugh.1177529314123; Wed, 25 Apr 2007 12:28:34 -0700 (PDT) Received: from localhost ( [213.141.154.21]) by mx.google.com with ESMTP id e23sm3811329ugd.2007.04.25.12.28.32; Wed, 25 Apr 2007 12:28:33 -0700 (PDT) Date: Wed, 25 Apr 2007 23:31:21 +0400 To: freebsd-hackers@freebsd.org Message-ID: <20070425193121.GA1109@q.q> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.13 (2006-08-11) From: stas.ibragimov@gmail.com Subject: FreeBSD install problem on Asus A6T laptop. 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, 25 Apr 2007 19:28:36 -0000 I am attemping to install FreeBSD Current into this laptop.System boot well, but working very very slow(switching to next virtual console took 5-10 minutes). What could be the reason of this? Stas Ibragimov From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 25 23:19:37 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5859616A402 for ; Wed, 25 Apr 2007 23:19:37 +0000 (UTC) (envelope-from mlfbsd@dong.ci0.org) Received: from dong.ci0.org (cognet.ci0.org [80.65.224.102]) by mx1.freebsd.org (Postfix) with ESMTP id 8390A13C44C for ; Wed, 25 Apr 2007 23:19:36 +0000 (UTC) (envelope-from mlfbsd@dong.ci0.org) Received: from dong.ci0.org (localhost.ci0.org [127.0.0.1]) by dong.ci0.org (8.13.8/8.13.8) with ESMTP id l3PNMcm3094054; Thu, 26 Apr 2007 01:22:39 +0200 (CEST) (envelope-from mlfbsd@dong.ci0.org) Received: (from mlfbsd@localhost) by dong.ci0.org (8.13.8/8.13.8/Submit) id l3PNMcol094053; Thu, 26 Apr 2007 01:22:38 +0200 (CEST) (envelope-from mlfbsd) Date: Thu, 26 Apr 2007 01:22:38 +0200 From: Olivier Houchard To: stas.ibragimov@gmail.com Message-ID: <20070425232238.GA93592@ci0.org> References: <20070425193121.GA1109@q.q> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070425193121.GA1109@q.q> User-Agent: Mutt/1.4.1i Cc: freebsd-hackers@freebsd.org Subject: Re: FreeBSD install problem on Asus A6T laptop. 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, 25 Apr 2007 23:19:37 -0000 On Wed, Apr 25, 2007 at 11:31:21PM +0400, stas.ibragimov@gmail.com wrote: > I am attemping to install FreeBSD Current into this laptop.System boot well, but working very very slow(switching to next virtual console took 5-10 minutes). > What could be the reason of this? > > Hi, I've had a similar problem with an A7T, if I'm not mistaken it's due to a bug in the thurion timer, you can use machdep.cpu_idle_hlt="0" in your loader.conf as a workaround. Cheers, Olivier From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 26 02:24:03 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from misaki (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with SMTP id C510916A407; Thu, 26 Apr 2007 02:24:01 +0000 (UTC) (envelope-from ariff@FreeBSD.org) Date: Thu, 26 Apr 2007 10:23:34 +0800 From: Ariff Abdullah To: Olivier Houchard Message-Id: <20070426102334.1c301b0a.ariff@FreeBSD.org> In-Reply-To: <20070425232238.GA93592@ci0.org> References: <20070425193121.GA1109@q.q> <20070425232238.GA93592@ci0.org> Organization: FreeBSD X-Mailer: /usr/local/lib/ruby/1.8/net/smtp.rb Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA1"; boundary="Signature=_Thu__26_Apr_2007_10_23_34_+0800_5uWb+SL.rHlrr7tq" Cc: freebsd-hackers@freebsd.org, stas.ibragimov@gmail.com Subject: Re: FreeBSD install problem on Asus A6T laptop. 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, 26 Apr 2007 02:24:03 -0000 --Signature=_Thu__26_Apr_2007_10_23_34_+0800_5uWb+SL.rHlrr7tq Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, 26 Apr 2007 01:22:38 +0200 Olivier Houchard wrote: > On Wed, Apr 25, 2007 at 11:31:21PM +0400, stas.ibragimov@gmail.com > wrote: > > I am attemping to install FreeBSD Current into this laptop.System > > boot well, but working very very slow(switching to next virtual > > console took 5-10 minutes). What could be the reason of this? > >=20 > >=20 >=20 > Hi, >=20 > I've had a similar problem with an A7T, if I'm not mistaken it's due > to a bug in the thurion timer, you can use > machdep.cpu_idle_hlt=3D"0" > in your loader.conf as a workaround. >=20 This has been fixed few hours ago. http://docs.freebsd.org/cgi/getmsg.cgi?fetch=3D401120+0+current/cvs-src -- Ariff Abdullah FreeBSD ... Recording in stereo is obviously too advanced and confusing for us idiot ***** users :P ........ --Signature=_Thu__26_Apr_2007_10_23_34_+0800_5uWb+SL.rHlrr7tq Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGMA0mlr+deMUwTNoRAkyHAJ4xvsT37qu/hQuZqrLJe8VynVLGlgCg4ZPM qctJCn2QUKpk7r64wHjRoEg= =xpK4 -----END PGP SIGNATURE----- --Signature=_Thu__26_Apr_2007_10_23_34_+0800_5uWb+SL.rHlrr7tq-- From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 26 04:54:53 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3607616A408 for ; Thu, 26 Apr 2007 04:54:53 +0000 (UTC) (envelope-from stas.ibragimov@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.175]) by mx1.freebsd.org (Postfix) with ESMTP id B50F013C4B9 for ; Thu, 26 Apr 2007 04:54:52 +0000 (UTC) (envelope-from stas.ibragimov@gmail.com) Received: by ug-out-1314.google.com with SMTP id 71so482029ugh for ; Wed, 25 Apr 2007 21:54:51 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:date:to:cc:subject:message-id:references:mime-version:content-type:content-disposition:in-reply-to:user-agent:from; b=ntZ7GzKt/6yPESc6woWIT41zQ1flAYj8DYnLzbMqvvQ5e3+tzb4U9OsMSiISWxE44csvLxctMbRGtMmlGXZGjCE/OEsQzvZVbXYx8MW0MfM6ls4Gs/qBR76XksLlKoswg3GNkuKcdpPeLWhtVkHPOaRXiVM8Uaw8lulH9rzGaGA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:date:to:cc:subject:message-id:references:mime-version:content-type:content-disposition:in-reply-to:user-agent:from; b=GhCvZqpSaiSvdCyZz1Xf34n9jokj0QQd5Ks9BDRNd+O9QVn36bnUXHf8tX/YADMDn+aq1EoQ6/GToHqrVCRydfkruJKP9cOoHsHfjOFz5a3xYePl8SZZpVXoPCAOtZVwtP99FG7g3dmgoFHVjBqzruC+hJ/PwXnLVCCMe4g2pKo= Received: by 10.66.248.13 with SMTP id v13mr1919340ugh.1177563291443; Wed, 25 Apr 2007 21:54:51 -0700 (PDT) Received: from localhost ( [213.141.154.21]) by mx.google.com with ESMTP id b23sm4430189ugd.2007.04.25.21.54.49; Wed, 25 Apr 2007 21:54:50 -0700 (PDT) Date: Thu, 26 Apr 2007 08:57:40 +0400 To: Olivier Houchard Message-ID: <20070426045740.GA1093@q.q> References: <20070425193121.GA1109@q.q> <20070425232238.GA93592@ci0.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070425232238.GA93592@ci0.org> User-Agent: Mutt/1.5.13 (2006-08-11) From: stas.ibragimov@gmail.com Cc: freebsd-hackers@freebsd.org Subject: Re: FreeBSD install problem on Asus A6T laptop. 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, 26 Apr 2007 04:54:53 -0000 On Thu Apr 26, 2007 at 01:22:38AM +0200, Olivier Houchard wrote: > On Wed, Apr 25, 2007 at 11:31:21PM +0400, stas.ibragimov@gmail.com wrote: > > I am attemping to install FreeBSD Current into this laptop.System boot well, but working very very slow(switching to next virtual console took 5-10 minutes). > > What could be the reason of this? > > > > > > Hi, > > I've had a similar problem with an A7T, if I'm not mistaken it's due to a > bug in the thurion timer, you can use > machdep.cpu_idle_hlt="0" > in your loader.conf as a workaround. > > Cheers, > > Olivier When I used the machdep.cpu_idle_hlt="0", system has been properly loaded. Stas Ibragimov From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 26 09:53:13 2007 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.org Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3CED916A401 for ; Thu, 26 Apr 2007 09:53:13 +0000 (UTC) (envelope-from mlfbsd@dong.ci0.org) Received: from dong.ci0.org (cognet.ci0.org [80.65.224.102]) by mx1.freebsd.org (Postfix) with ESMTP id 8D62313C45D for ; Thu, 26 Apr 2007 09:53:11 +0000 (UTC) (envelope-from mlfbsd@dong.ci0.org) Received: from dong.ci0.org (localhost.ci0.org [127.0.0.1]) by dong.ci0.org (8.13.8/8.13.8) with ESMTP id l3QAFV6O098909; Thu, 26 Apr 2007 12:15:31 +0200 (CEST) (envelope-from mlfbsd@dong.ci0.org) Received: (from mlfbsd@localhost) by dong.ci0.org (8.13.8/8.13.8/Submit) id l3QAFVAm098908; Thu, 26 Apr 2007 12:15:31 +0200 (CEST) (envelope-from mlfbsd) Date: Thu, 26 Apr 2007 12:15:31 +0200 From: Olivier Houchard To: Ariff Abdullah Message-ID: <20070426101530.GA98888@ci0.org> References: <20070425193121.GA1109@q.q> <20070425232238.GA93592@ci0.org> <20070426102334.1c301b0a.ariff@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070426102334.1c301b0a.ariff@FreeBSD.org> User-Agent: Mutt/1.4.1i Cc: freebsd-hackers@FreeBSD.org, stas.ibragimov@gmail.com Subject: Re: FreeBSD install problem on Asus A6T laptop. 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, 26 Apr 2007 09:53:13 -0000 On Thu, Apr 26, 2007 at 10:23:34AM +0800, Ariff Abdullah wrote: > On Thu, 26 Apr 2007 01:22:38 +0200 > Olivier Houchard wrote: > > On Wed, Apr 25, 2007 at 11:31:21PM +0400, stas.ibragimov@gmail.com > > wrote: > > > I am attemping to install FreeBSD Current into this laptop.System > > > boot well, but working very very slow(switching to next virtual > > > console took 5-10 minutes). What could be the reason of this? > > > > > > > > > > Hi, > > > > I've had a similar problem with an A7T, if I'm not mistaken it's due > > to a bug in the thurion timer, you can use > > machdep.cpu_idle_hlt="0" > > in your loader.conf as a workaround. > > > > This has been fixed few hours ago. > > http://docs.freebsd.org/cgi/getmsg.cgi?fetch=401120+0+current/cvs-src > > Great to hear ! It's been annoying me for some times. Thanks for your work ! Olivier From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 26 12:34:56 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 21B1216A40A for ; Thu, 26 Apr 2007 12:34:56 +0000 (UTC) (envelope-from marc.loerner@hob.de) Received: from mailgate.hob.de (mailgate.hob.de [212.185.199.3]) by mx1.freebsd.org (Postfix) with ESMTP id B91E713C459 for ; Thu, 26 Apr 2007 12:34:55 +0000 (UTC) (envelope-from marc.loerner@hob.de) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailgate.hob.de (Postfix) with ESMTP id EA6A727966; Thu, 26 Apr 2007 14:08:23 +0200 (CEST) Received: from mailgate.hob.de ([127.0.0.1]) by localhost (mailgate.hob.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29907-01; Thu, 26 Apr 2007 14:08:23 +0200 (CEST) Received: from imap.hob.de (mail2.hob.de [172.25.1.102]) by mailgate.hob.de (Postfix) with ESMTP id A611027975 for ; Thu, 26 Apr 2007 14:08:23 +0200 (CEST) Received: from linux03.hob.de (linux03.hob.de [172.22.0.190]) by imap.hob.de (Postfix on SuSE eMail Server 2.0) with ESMTP id 5EF9629DE for ; Thu, 26 Apr 2007 14:08:23 +0200 (CEST) From: Marc =?iso-8859-1?q?L=F6rner?= Organization: hob To: freebsd-hackers@freebsd.org Date: Thu, 26 Apr 2007 13:08:19 +0100 User-Agent: KMail/1.6.2 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200704261408.19885.marc.loerner@hob.de> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at hob.de Subject: Usage of kern_* functions in kernel 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, 26 Apr 2007 12:34:56 -0000 Hello, I googled but found nothing about the usage of the kern_* functions (kern_open, kern_close, kern_pwritev, kern_preadv) that are located in vfs_syscalls.c When I use kern_open to open a file within the kernel, I get an error. When I use the normal vn_open function instead, all works well. So my question is which functions are recommended by you kernel-hackers for use within kernelspace? And here a second question: Is it possible to open/use the console driver in kernelspace within the functions mentioned above? If not, can you give me some pointers on where I can find this information! Regards, Marc From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 26 19:08:44 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7DB4316A401 for ; Thu, 26 Apr 2007 19:08:44 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.freebsd.org (Postfix) with ESMTP id D685B13C45E for ; Thu, 26 Apr 2007 19:08:43 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id l3QJ8dGr077259; Thu, 26 Apr 2007 15:08:40 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Thu, 26 Apr 2007 13:49:35 -0400 User-Agent: KMail/1.9.6 References: <200704261408.19885.marc.loerner@hob.de> In-Reply-To: <200704261408.19885.marc.loerner@hob.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200704261349.35661.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Thu, 26 Apr 2007 15:08:40 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/3165/Thu Apr 26 09:03:24 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Marc =?iso-8859-1?q?L=F6rner?= Subject: Re: Usage of kern_* functions in kernel 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, 26 Apr 2007 19:08:44 -0000 On Thursday 26 April 2007 08:08:19 am Marc L=F6rner wrote: > Hello, > I googled but found nothing about the usage of the kern_* functions=20 > (kern_open, kern_close, kern_pwritev, kern_preadv) that are located in=20 > vfs_syscalls.c >=20 > When I use kern_open to open a file within the kernel, I get an error.=20 > When I use the normal vn_open function instead, all works well. >=20 > So my question is which functions are recommended by you kernel-hackers=20 > for use within kernelspace? >=20 > And here a second question: Is it possible to open/use the console driver= in=20 > kernelspace within the functions mentioned above?=20 > If not, can you give me some pointers on where I can find this informatio= n! kern_XXX are generally used by system calls such as alternative ABIs, etc. =2D-=20 John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 26 20:37:04 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C3FDF16A401 for ; Thu, 26 Apr 2007 20:37:04 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe11.swip.net [212.247.155.65]) by mx1.freebsd.org (Postfix) with ESMTP id 642B913C469 for ; Thu, 26 Apr 2007 20:37:04 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] Received: from [193.71.38.142] (account mc467741@c2i.net HELO [10.42.11.147]) by mailfe11.swip.net (CommuniGate Pro SMTP 5.1.7) with ESMTPA id 305604204 for freebsd-hackers@freebsd.org; Thu, 26 Apr 2007 21:36:56 +0200 From: Hans Petter Selasky To: freebsd-hackers@freebsd.org Date: Thu, 26 Apr 2007 21:36:33 +0200 User-Agent: KMail/1.9.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200704262136.33196.hselasky@c2i.net> Subject: msleep() on recursivly locked mutexes 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, 26 Apr 2007 20:37:04 -0000 Hi, In the new USB stack I have defined the following: u_int32_t mtx_drop_recurse(struct mtx *mtx) { u_int32_t recurse_level = mtx->mtx_recurse; u_int32_t recurse_curr = recurse_level; mtx_assert(mtx, MA_OWNED); while(recurse_curr--) { mtx_unlock(mtx); } return recurse_level; } void mtx_pickup_recurse(struct mtx *mtx, u_int32_t recurse_level) { mtx_assert(mtx, MA_OWNED); while(recurse_level--) { mtx_lock(mtx); } return; } When I do a msleep() I do it like this: level = mtx_drop_recurse(ctd->p_mtx); error = msleep(ctd, ctd->p_mtx, 0, "config td sleep", timeout); mtx_pickup_recurse(ctd->p_mtx, level); Are there any comments on integrating this functionality into msleep(), and adding mtx_drop_recurse() and mtx_pickup_recurse() to the FreeBSD kernel? --HPS From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 26 21:17:49 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3ECFD16A401 for ; Thu, 26 Apr 2007 21:17:49 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outJ.internet-mail-service.net (outJ.internet-mail-service.net [216.240.47.233]) by mx1.freebsd.org (Postfix) with ESMTP id 2C66B13C455 for ; Thu, 26 Apr 2007 21:17:49 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Thu, 26 Apr 2007 13:44:58 -0700 Received: from julian-mac.elischer.org (nat.ironport.com [63.251.108.100]) by idiom.com (Postfix) with ESMTP id 7EEA8125B23; Thu, 26 Apr 2007 14:17:48 -0700 (PDT) Message-ID: <46311708.5030002@elischer.org> Date: Thu, 26 Apr 2007 14:18:00 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: Hans Petter Selasky References: <200704262136.33196.hselasky@c2i.net> In-Reply-To: <200704262136.33196.hselasky@c2i.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: msleep() on recursivly locked mutexes 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, 26 Apr 2007 21:17:49 -0000 Hans Petter Selasky wrote: > Hi, > > In the new USB stack I have defined the following: > > u_int32_t > mtx_drop_recurse(struct mtx *mtx) > { > u_int32_t recurse_level = mtx->mtx_recurse; > u_int32_t recurse_curr = recurse_level; > > mtx_assert(mtx, MA_OWNED); > > while(recurse_curr--) { > mtx_unlock(mtx); > } > > return recurse_level; > } The reason that mutexes ever recurse in the first place is usually because one piece of code calls itself (or a related piece of code) in a blind manner.. in other words, it doesn't know it is doing so. The whole concept of recursing mutexes is a bit gross. The concept of blindly unwinding them is I think just asking for trouble. Further the idea that holding a mutex "except for when we sleep" is a generally bright idea is also a bit odd to me.. If you hold a mutex and release it during sleep you probably should invalidate all assumptions you made during the period before you slept as whatever you were protecting has possibly been raped while you slept. I have seen too many instances where people just called msleep and dropped the mutex they held, picked it up again on wakeup, and then blithely continued on without checking what happened while they were asleep. It seems to me that if someone else held that lock for some purpose when you slept, then you don't know what it was that they were trying to protect, so you don't know what to recheck when you wake up.. I think this is extremely dangerous as you don't know when you are in this situation.. Personally I think Matt Dillon had a good idea when he suggested that the need to sleep when holding a lock should require the lock holder to back out as far as needed as to be able to see why the lock was held and to comfortably cope with the situaution when the protected structures got frobbed while it slept. (He actually at one time committed some primitives to do this. I forget their names and htey were never used, but the idea has some merrit.) This change may be OK in the situations you plan but it makes me very uncomfortable. it basically should have a big sign on it saying "You could spend years looking for the wierd bugs you are likely to get if you use this" on it. > > void > mtx_pickup_recurse(struct mtx *mtx, u_int32_t recurse_level) > { > mtx_assert(mtx, MA_OWNED); > > while(recurse_level--) { > mtx_lock(mtx); > } > return; > } > > When I do a msleep() I do it like this: > > level = mtx_drop_recurse(ctd->p_mtx); > > error = msleep(ctd, ctd->p_mtx, 0, > "config td sleep", timeout); > > mtx_pickup_recurse(ctd->p_mtx, level); > > Are there any comments on integrating this functionality into msleep(), and > adding mtx_drop_recurse() and mtx_pickup_recurse() to the FreeBSD kernel? > > --HPS > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 26 21:38:56 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 96B5416A404 for ; Thu, 26 Apr 2007 21:38:56 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.241]) by mx1.freebsd.org (Postfix) with ESMTP id 5436B13C4AD for ; Thu, 26 Apr 2007 21:38:56 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by an-out-0708.google.com with SMTP id c24so410861ana for ; Thu, 26 Apr 2007 14:38:55 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=UuLOatCkBiIRwGTT5GIXBkB3F7mHsliq5xItlacCtLGobhLVK8sVZK3heeQi9+hgeujPVrutLAPZsl9u450Fuj3Yi46Qd08nRUn7zKizU83VmhpGKsec8ZdekGT9lwz4m8KOTtgorDj9Elr3vC5+Ursaj3dP/vMJjqacAsA3wzU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=GAXk0vJmfisfAt5lsfa7tkq4xgG464Akc9FDCH/nkgc1ox/dhYFTOh0ypZEkvQK6rUXwRWbq7Wp8coWla2oMdRC7AjSjJX+sr8F6qeGpnnyeOM03Tam4PsYm8j9mqwu/KaVWiN0CgrXlk5QCJHt+A08KsTnHbpni/Oqdnmh+5u8= Received: by 10.100.40.17 with SMTP id n17mr1447024ann.1177623535468; Thu, 26 Apr 2007 14:38:55 -0700 (PDT) Received: by 10.100.178.1 with HTTP; Thu, 26 Apr 2007 14:38:55 -0700 (PDT) Message-ID: <3bbf2fe10704261438k5e25e892w3f821ac9507f5457@mail.gmail.com> Date: Thu, 26 Apr 2007 23:38:55 +0200 From: "Attilio Rao" Sender: asmrookie@gmail.com To: "Hans Petter Selasky" In-Reply-To: <200704262136.33196.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200704262136.33196.hselasky@c2i.net> X-Google-Sender-Auth: 53a4ac8bf6a46057 Cc: freebsd-hackers@freebsd.org Subject: Re: msleep() on recursivly locked mutexes 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, 26 Apr 2007 21:38:56 -0000 2007/4/26, Hans Petter Selasky : > Hi, > > In the new USB stack I have defined the following: > > u_int32_t > mtx_drop_recurse(struct mtx *mtx) > { > u_int32_t recurse_level = mtx->mtx_recurse; > u_int32_t recurse_curr = recurse_level; > > mtx_assert(mtx, MA_OWNED); > > while(recurse_curr--) { > mtx_unlock(mtx); > } > > return recurse_level; > } > > void > mtx_pickup_recurse(struct mtx *mtx, u_int32_t recurse_level) > { > mtx_assert(mtx, MA_OWNED); > > while(recurse_level--) { > mtx_lock(mtx); > } > return; > } > > When I do a msleep() I do it like this: > > level = mtx_drop_recurse(ctd->p_mtx); > > error = msleep(ctd, ctd->p_mtx, 0, > "config td sleep", timeout); > > mtx_pickup_recurse(ctd->p_mtx, level); > > Are there any comments on integrating this functionality into msleep(), and > adding mtx_drop_recurse() and mtx_pickup_recurse() to the FreeBSD kernel? Several times I thought to adding recursed mutex handling in msleep & condvar, but in the end the better approach is mantaining the current behaviour. Recursed mutexes often are results of incorrect locking strategies and catering that kind of errors is necessarily a bad idea. It is a lot better handling potential recursing mutexes outside from sleeping points (that is what your implementation does). Just, please, don't deal with internal struct mtx fields for that (so, please, don't refer to mtx->mtx_recurse) just use the mutex(9) API provided. Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 26 21:50:16 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3365A16A406 for ; Thu, 26 Apr 2007 21:50:16 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id D1F8613C465 for ; Thu, 26 Apr 2007 21:50:15 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.13.8/8.13.4) with ESMTP id l3QLl4UA032598; Thu, 26 Apr 2007 15:47:05 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 26 Apr 2007 15:47:13 -0600 (MDT) Message-Id: <20070426.154713.-135506433.imp@bsdimp.com> To: hselasky@c2i.net From: "M. Warner Losh" In-Reply-To: <200704262136.33196.hselasky@c2i.net> References: <200704262136.33196.hselasky@c2i.net> X-Mailer: Mew version 4.2 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.bsdimp.com [127.0.0.1]); Thu, 26 Apr 2007 15:47:05 -0600 (MDT) Cc: freebsd-hackers@freebsd.org Subject: Re: msleep() on recursivly locked mutexes 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, 26 Apr 2007 21:50:16 -0000 In message: <200704262136.33196.hselasky@c2i.net> Hans Petter Selasky writes: : Are there any comments on integrating this functionality into msleep(), and : adding mtx_drop_recurse() and mtx_pickup_recurse() to the FreeBSD kernel? This is generally a bad idea. We allow it for Giant because it has to be acquired everywhere and we have to drop it in some extremely ugly places. To enshrine this behavior for all mutexes strikes me as ill advised. Adding additional hacks to recursive mutexes seems wrong to my way of thinking. Warner From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 26 21:50:17 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1645D16A407 for ; Thu, 26 Apr 2007 21:50:17 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.242]) by mx1.freebsd.org (Postfix) with ESMTP id C602813C458 for ; Thu, 26 Apr 2007 21:50:16 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by an-out-0708.google.com with SMTP id c24so413994ana for ; Thu, 26 Apr 2007 14:50:16 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=PTwhlVgp5Du3S1kdbUrYI+TIcURKAH3Se8jud4LmUqNTedMPNipCmCYqhR4O3HkYC/QzzC9cJovePbEiGW0KlF7IK0f2pCYCYjITKgj/Hy4ss6jTnEyaDiddPVwC5zYqflB6gfD8V3Ysr9NBt/GwG20reM8gLT9EuCZHOVq/m4A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=RtI45W/I3QbdeQpo3F8hfB6SskjlVgmP6sqPij6atzrIDwdHptu+lw6IEpDLyUWe9xX1wZvkFJouj68rMDi1Ib4FuHM+ROgrcOJNGhP4DDwsZEgIaGvSsyHWAcJJPTqwzfCNColwv3MYSlGl/dbsUO80umQFjS5iCAZUgnDOoM4= Received: by 10.100.120.5 with SMTP id s5mr1517796anc.1177624216107; Thu, 26 Apr 2007 14:50:16 -0700 (PDT) Received: by 10.100.178.1 with HTTP; Thu, 26 Apr 2007 14:50:16 -0700 (PDT) Message-ID: <3bbf2fe10704261450n50b66392saa7dc2ea7f091d31@mail.gmail.com> Date: Thu, 26 Apr 2007 23:50:16 +0200 From: "Attilio Rao" Sender: asmrookie@gmail.com To: "Julian Elischer" In-Reply-To: <46311708.5030002@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200704262136.33196.hselasky@c2i.net> <46311708.5030002@elischer.org> X-Google-Sender-Auth: 22782b4d1654f6b2 Cc: freebsd-hackers@freebsd.org, Hans Petter Selasky Subject: Re: msleep() on recursivly locked mutexes 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, 26 Apr 2007 21:50:17 -0000 2007/4/26, Julian Elischer : > The reason that mutexes ever recurse in the first place is usually because one > piece of code calls itself (or a related piece of code) in a blind manner.. in other > words, it doesn't know it is doing so. The whole concept of recursing mutexes is a bit > gross. The concept of blindly unwinding them is I think just asking for trouble. > > Further the idea that holding a mutex "except for when we sleep" is a generally > bright idea is also a bit odd to me.. If you hold a mutex and release it > during sleep you probably should invalidate all assumptions you made during the > period before you slept as whatever you were protecting has possibly been raped > while you slept. I have seen too many instances where people just called msleep > and dropped the mutex they held, picked it up again on wakeup, and then blithely > continued on without checking what happened while they were asleep. Basically, the idea you cannot hold "blocking" locks (mutexes and rwlocks) while sleeping, cames from the difference there is behind turnstiles and sleepqueues. Turnstiles are thought to serve syncronous events, for short period of time (or rather short) while sleepqueues are thought to serve asyncronous events, so that the path to be protected can be definitively bigger. If you fit in the situation you have to call first a blocking lock and later a sleeping lock, probabilly you are just using a wrong locking strategy and you should really revisit it. As you mention, it is not always possible to drop the blocking lock before to sleep since you can break your critical path and free the way for races of various genre. Even unlocking Giant, that is auto-magically done by sleeping primitives, can lead to very difficult to discover races (I can remind one in tty code, old of some months, that can be a good proof-of-concept for that). Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 27 05:53:24 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A233516A403 for ; Fri, 27 Apr 2007 05:53:24 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe12.swip.net [212.247.155.97]) by mx1.freebsd.org (Postfix) with ESMTP id 19D5C13C46C for ; Fri, 27 Apr 2007 05:53:23 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] Received: from [193.71.38.142] (account mc467741@c2i.net HELO [10.42.11.147]) by mailfe12.swip.net (CommuniGate Pro SMTP 5.1.7) with ESMTPA id 304137636; Fri, 27 Apr 2007 07:53:22 +0200 From: Hans Petter Selasky To: Julian Elischer Date: Fri, 27 Apr 2007 07:53:05 +0200 User-Agent: KMail/1.9.5 References: <200704262136.33196.hselasky@c2i.net> <46311708.5030002@elischer.org> In-Reply-To: <46311708.5030002@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200704270753.05438.hselasky@c2i.net> Cc: freebsd-hackers@freebsd.org Subject: Re: msleep() on recursivly locked mutexes 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, 27 Apr 2007 05:53:24 -0000 On Thursday 26 April 2007 23:18, Julian Elischer wrote: > Hans Petter Selasky wrote: > > Hi, > > > > In the new USB stack I have defined the following: > > > > u_int32_t > > mtx_drop_recurse(struct mtx *mtx) > > { > > u_int32_t recurse_level = mtx->mtx_recurse; > > u_int32_t recurse_curr = recurse_level; > > > > mtx_assert(mtx, MA_OWNED); > > > > while(recurse_curr--) { > > mtx_unlock(mtx); > > } > > > > return recurse_level; > > } > > The reason that mutexes ever recurse in the first place is usually because > one piece of code calls itself (or a related piece of code) in a blind > manner.. in other words, it doesn't know it is doing so. The whole concept > of recursing mutexes is a bit gross. The concept of blindly unwinding them > is I think just asking for trouble. > > Further the idea that holding a mutex "except for when we sleep" is a > generally bright idea is also a bit odd to me.. If you hold a mutex and > release it during sleep you probably should invalidate all assumptions you > made during the period before you slept as whatever you were protecting has > possibly been raped while you slept. I have seen too many instances where > people just called msleep and dropped the mutex they held, picked it up > again on wakeup, and then blithely continued on without checking what > happened while they were asleep. > > It seems to me that if someone else held that lock for some purpose when > you slept, then you don't know what it was that they were trying to > protect, so you don't know what to recheck when you wake up.. I think this > is extremely dangerous as you don't know when you are in this situation.. > > Personally I think Matt Dillon had a good idea when he suggested that the > need to sleep when holding a lock should require the lock holder to back > out as far as needed as to be able to see why the lock was held and to > comfortably cope with the situaution when the protected structures got > frobbed while it slept. (He actually at one time committed some primitives > to do this. I forget their names and htey were never used, but the idea has > some merrit.) > > This change may be OK in the situations you plan but it makes me very > uncomfortable. it basically should have a big sign on it saying "You could > spend years looking for the wierd bugs you are likely to get if you use > this" on it. Yes, but could we factor this code out into a msleep_recurse() function then? And the mtx_pickup/mtx_drop functions I would rather see in "kern_synch.c", because it is so much faster to change the recurse level, than it is to do a while loop. --HPS From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 27 06:43:22 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CDAA716A402 for ; Fri, 27 Apr 2007 06:43:22 +0000 (UTC) (envelope-from marc.loerner@hob.de) Received: from mailgate.hob.de (mailgate.hob.de [212.185.199.3]) by mx1.freebsd.org (Postfix) with ESMTP id 065B813C44C for ; Fri, 27 Apr 2007 06:43:21 +0000 (UTC) (envelope-from marc.loerner@hob.de) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailgate.hob.de (Postfix) with ESMTP id 9B69F279DB; Fri, 27 Apr 2007 08:43:20 +0200 (CEST) Received: from mailgate.hob.de ([127.0.0.1]) by localhost (mailgate.hob.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20731-01; Fri, 27 Apr 2007 08:43:20 +0200 (CEST) Received: from imap.hob.de (mail2.hob.de [172.25.1.102]) by mailgate.hob.de (Postfix) with ESMTP id 573C9279E3; Fri, 27 Apr 2007 08:43:20 +0200 (CEST) Received: from linux03.hob.de (linux03.hob.de [172.22.0.190]) by imap.hob.de (Postfix on SuSE eMail Server 2.0) with ESMTP id D18C23C59; Fri, 27 Apr 2007 08:43:19 +0200 (CEST) From: Marc =?iso-8859-1?q?L=F6rner?= Organization: hob To: freebsd-hackers@freebsd.org Date: Fri, 27 Apr 2007 07:43:16 +0100 User-Agent: KMail/1.6.2 References: <200704261408.19885.marc.loerner@hob.de> <200704261349.35661.jhb@freebsd.org> In-Reply-To: <200704261349.35661.jhb@freebsd.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Message-Id: <200704270843.16908.marc.loerner@hob.de> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at hob.de Cc: Subject: Re: Usage of kern_* functions in kernel 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, 27 Apr 2007 06:43:22 -0000 On Thursday 26 April 2007 19:49, John Baldwin wrote: > On Thursday 26 April 2007 08:08:19 am Marc Lörner wrote: > > Hello, > > I googled but found nothing about the usage of the kern_* functions > > (kern_open, kern_close, kern_pwritev, kern_preadv) that are located in > > vfs_syscalls.c > > > > When I use kern_open to open a file within the kernel, I get an error. > > When I use the normal vn_open function instead, all works well. > > > > So my question is which functions are recommended by you kernel-hackers > > for use within kernelspace? > > > > And here a second question: Is it possible to open/use the console driver > > in kernelspace within the functions mentioned above? > > If not, can you give me some pointers on where I can find this > > information! > > kern_XXX are generally used by system calls such as alternative ABIs, etc. so, you would recommend using the vn_* functions instead? -- Marc From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 27 06:49:25 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8D3CF16A406; Fri, 27 Apr 2007 06:49:25 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe04.swip.net [212.247.154.97]) by mx1.freebsd.org (Postfix) with ESMTP id 7124C13C44B; Fri, 27 Apr 2007 06:49:24 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] Received: from [193.71.38.142] (account mc467741@c2i.net HELO [10.42.11.147]) by mailfe04.swip.net (CommuniGate Pro SMTP 5.1.7) with ESMTPA id 474056930; Fri, 27 Apr 2007 07:49:14 +0200 From: Hans Petter Selasky To: "Attilio Rao" Date: Fri, 27 Apr 2007 07:48:49 +0200 User-Agent: KMail/1.9.5 References: <200704262136.33196.hselasky@c2i.net> <46311708.5030002@elischer.org> <3bbf2fe10704261450n50b66392saa7dc2ea7f091d31@mail.gmail.com> In-Reply-To: <3bbf2fe10704261450n50b66392saa7dc2ea7f091d31@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200704270748.49404.hselasky@c2i.net> Cc: freebsd-hackers@freebsd.org, Julian Elischer Subject: Re: msleep() on recursivly locked mutexes 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, 27 Apr 2007 06:49:25 -0000 On Thursday 26 April 2007 23:50, Attilio Rao wrote: > 2007/4/26, Julian Elischer : > > The reason that mutexes ever recurse in the first place is usually > > because one piece of code calls itself (or a related piece of code) in a > > blind manner.. in other words, it doesn't know it is doing so. The whole > > concept of recursing mutexes is a bit gross. The concept of blindly > > unwinding them is I think just asking for trouble. > > > > Further the idea that holding a mutex "except for when we sleep" is a > > generally bright idea is also a bit odd to me.. If you hold a mutex and > > release it during sleep you probably should invalidate all assumptions > > you made during the period before you slept as whatever you were That is not always correct. If you run your code in a separate thread/taskqueue, then you simply wait for this thread/taskqueue to complete somewhere else. This is basically when I need to exit mutexes. > > protecting has possibly been raped while you slept. I have seen too many > > instances where people just called msleep and dropped the mutex they > > held, picked it up again on wakeup, and then blithely continued on > > without checking what happened while they were asleep. > > Basically, the idea you cannot hold "blocking" locks (mutexes and > rwlocks) while sleeping, cames from the difference there is behind > turnstiles and sleepqueues. > > Turnstiles are thought to serve syncronous events, for short period of > time (or rather short) while sleepqueues are thought to serve > asyncronous events, so that the path to be protected can be > definitively bigger. If you fit in the situation you have to call > first a blocking lock and later a sleeping lock, probabilly you are > just using a wrong locking strategy and you should really revisit it. The suggestion is just for convenience. Usually you don't have a recursed mutex to sleep on. It is just to catch some rare cases where you will end up with a doubly locked mutex, which is not part of the ordinary code path. I don't have such cases in the kernel of the new USB stack, but there are some cases in the USB device drivers, which is due to some mutex locking moves. Those I can fix. My idea was that by allowing recursive mutexes to sleep, you will end up with less panics in the end for the unwary code developer. You just protect your code with mutexes and if they recurse calling synchronous USB functions, you don't have to care. > > As you mention, it is not always possible to drop the blocking lock > before to sleep since you can break your critical path and free the > way for races of various genre. Even unlocking Giant, that is > auto-magically done by sleeping primitives, can lead to very difficult > to discover races (I can remind one in tty code, old of some months, > that can be a good proof-of-concept for that). > --HPS From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 27 06:50:24 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5E8C216A400 for ; Fri, 27 Apr 2007 06:50:24 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe06.swip.net [212.247.154.161]) by mx1.freebsd.org (Postfix) with ESMTP id EEB2313C46E for ; Fri, 27 Apr 2007 06:50:23 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] Received: from [193.71.38.142] (account mc467741@c2i.net HELO [10.42.11.147]) by mailfe06.swip.net (CommuniGate Pro SMTP 5.1.7) with ESMTPA id 475367310; Fri, 27 Apr 2007 07:50:21 +0200 From: Hans Petter Selasky To: "Bosko Milekic" Date: Fri, 27 Apr 2007 07:50:04 +0200 User-Agent: KMail/1.9.5 References: <200704262136.33196.hselasky@c2i.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200704270750.04606.hselasky@c2i.net> Cc: freebsd-hackers@freebsd.org Subject: Re: msleep() on recursivly locked mutexes 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, 27 Apr 2007 06:50:24 -0000 On Thursday 26 April 2007 23:52, Bosko Milekic wrote: > On 4/26/07, Hans Petter Selasky wrote: > > Hi, > > > > In the new USB stack I have defined the following: > > Could you perhaps describe some of the codepaths in the USB stack that > require this behavior? There are no requirements for that. It is just for the convenience of unwary USB device driver developers. --HPS From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 27 07:18:53 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 81D2F16A400 for ; Fri, 27 Apr 2007 07:18:53 +0000 (UTC) (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 4DB4113C4BB for ; Fri, 27 Apr 2007 07:18:53 +0000 (UTC) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (jmn14xyw7hcndmxd@localhost.funkthat.com [127.0.0.1]) by hydrogen.funkthat.com (8.13.6/8.13.3) with ESMTP id l3R75Lh7060137; Fri, 27 Apr 2007 00:05:21 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.13.6/8.13.3/Submit) id l3R75LWn060136; Fri, 27 Apr 2007 00:05:21 -0700 (PDT) (envelope-from jmg) Date: Fri, 27 Apr 2007 00:05:21 -0700 From: John-Mark Gurney To: Hans Petter Selasky Message-ID: <20070427070521.GH73385@funkthat.com> Mail-Followup-To: Hans Petter Selasky , Bosko Milekic , freebsd-hackers@freebsd.org References: <200704262136.33196.hselasky@c2i.net> <200704270750.04606.hselasky@c2i.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200704270750.04606.hselasky@c2i.net> User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 5.4-RELEASE-p6 i386 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, Bosko Milekic Subject: Re: msleep() on recursivly locked mutexes 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: Fri, 27 Apr 2007 07:18:53 -0000 Hans Petter Selasky wrote this message on Fri, Apr 27, 2007 at 07:50 +0200: > On Thursday 26 April 2007 23:52, Bosko Milekic wrote: > > On 4/26/07, Hans Petter Selasky wrote: > > > Hi, > > > > > > In the new USB stack I have defined the following: > > > > Could you perhaps describe some of the codepaths in the USB stack that > > require this behavior? > > There are no requirements for that. It is just for the convenience of unwary > USB device driver developers. The reason we have restrictions on such things as prevention of recursion on mutexes is for the convenience of the unwary developer so they don't do something stupid, and not realize it till it's causing bugs... Multithreaded programming is hard, and even w/ the power of witness, is still hard to get right, and we need to help capable programmers not make mistakes... There is always ugen if the driver developer doesn't want to deal w/ making their driver multithread safe... -- 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 Fri Apr 27 08:29:46 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D36A316A409 for ; Fri, 27 Apr 2007 08:29:46 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.171]) by mx1.freebsd.org (Postfix) with ESMTP id 665CC13C44C for ; Fri, 27 Apr 2007 08:29:46 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by ug-out-1314.google.com with SMTP id 71so670207ugh for ; Fri, 27 Apr 2007 01:29:45 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding:sender; b=JkWIibiJpqDmHqwsnWKiCYXa/v0/3M3NfjNCr4B1izyIZwS1EAkdz6ez/X0SbzHiLktVdpq2/sxbFO+d5plFbbrEaXqScgaCaFYZQZYzZBnStb7pwj4n+ckau/yyknJBdgVV5YZ1sNt7E/z5RC3YzBT7+9478yZxgdGvaLNi9oA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding:sender; b=AD9h1KVzlKJmEbjAH4oRfO0w2Lod4YO24Ir6lKTUvZVgEBO6B+LkO3MJcgvv7Jc9q4HPAHV/whdircoB9wwP4wEM4vGR8T3htDoOlwDi4qlCzB1cGNWE0/Gk8TDdBsD6bSeGKBGuEy14pTtJyHiAX5DqSQDXJD3vPCbayWj+ByM= Received: by 10.82.151.14 with SMTP id y14mr5214243bud.1177662581828; Fri, 27 Apr 2007 01:29:41 -0700 (PDT) Received: from ?172.31.5.21? ( [89.97.252.178]) by mx.google.com with ESMTP id y37sm1585309iky.2007.04.27.01.29.26; Fri, 27 Apr 2007 01:29:35 -0700 (PDT) Message-ID: <463225AF.9070708@FreeBSD.org> Date: Fri, 27 Apr 2007 18:32:47 +0200 From: Attilio Rao User-Agent: Thunderbird 1.5 (X11/20060526) MIME-Version: 1.0 To: Hans Petter Selasky References: <200704262136.33196.hselasky@c2i.net> <46311708.5030002@elischer.org> <3bbf2fe10704261450n50b66392saa7dc2ea7f091d31@mail.gmail.com> <200704270748.49404.hselasky@c2i.net> In-Reply-To: <200704270748.49404.hselasky@c2i.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: Attilio Rao Cc: freebsd-hackers@freebsd.org, Julian Elischer Subject: Re: msleep() on recursivly locked mutexes X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: attilio@FreeBSD.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2007 08:29:46 -0000 Hans Petter Selasky wrote: > On Thursday 26 April 2007 23:50, Attilio Rao wrote: >> 2007/4/26, Julian Elischer : >>> The reason that mutexes ever recurse in the first place is usually >>> because one piece of code calls itself (or a related piece of code) in a >>> blind manner.. in other words, it doesn't know it is doing so. The whole >>> concept of recursing mutexes is a bit gross. The concept of blindly >>> unwinding them is I think just asking for trouble. >>> >>> Further the idea that holding a mutex "except for when we sleep" is a >>> generally bright idea is also a bit odd to me.. If you hold a mutex and >>> release it during sleep you probably should invalidate all assumptions >>> you made during the period before you slept as whatever you were > > That is not always correct. If you run your code in a separate > thread/taskqueue, then you simply wait for this thread/taskqueue to complete > somewhere else. This is basically when I need to exit mutexes. > >>> protecting has possibly been raped while you slept. I have seen too many >>> instances where people just called msleep and dropped the mutex they >>> held, picked it up again on wakeup, and then blithely continued on >>> without checking what happened while they were asleep. >> Basically, the idea you cannot hold "blocking" locks (mutexes and >> rwlocks) while sleeping, cames from the difference there is behind >> turnstiles and sleepqueues. >> >> Turnstiles are thought to serve syncronous events, for short period of >> time (or rather short) while sleepqueues are thought to serve >> asyncronous events, so that the path to be protected can be >> definitively bigger. If you fit in the situation you have to call >> first a blocking lock and later a sleeping lock, probabilly you are >> just using a wrong locking strategy and you should really revisit it. > > The suggestion is just for convenience. Usually you don't have a recursed > mutex to sleep on. It is just to catch some rare cases where you will end up > with a doubly locked mutex, which is not part of the ordinary code path. I > don't have such cases in the kernel of the new USB stack, but there are some > cases in the USB device drivers, which is due to some mutex locking moves. > Those I can fix. I don't think you got my point. I can understand this is for convenience and I can understand why you want it but definitively you should never have a recursed mutex, That's all. This is why msleep(), condvar() and lockmgr() panics if a recursed mutex is passed. Definitively, we mustn't cater a misbehaving approach with extra-hack in the kernel code. Attilio From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 26 22:20:56 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1FDEC16A40B for ; Thu, 26 Apr 2007 22:20:56 +0000 (UTC) (envelope-from bosko.milekic@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.226]) by mx1.freebsd.org (Postfix) with ESMTP id D645D13C469 for ; Thu, 26 Apr 2007 22:20:55 +0000 (UTC) (envelope-from bosko.milekic@gmail.com) Received: by wx-out-0506.google.com with SMTP id s18so788680wxc for ; Thu, 26 Apr 2007 15:20:55 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=uYkS9WFNgNZMiqVkC5CQ4w0VavSgOqOC5yOIjrSnLjp4YCXnjKOTRN1xdiqixzOvpuPp6qYqUf/VxaiArZffdgmpcictdBR3je5RCnb8urNgZCNZkZJpWvB7EnKb9MSCWiH/Rs5I7B8s+BnIcvws4deyK9MRP6Ok6sZLkiZ8QrQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=KBOr/3jeXSiUrQER6yvMqFcvOO/kgCKntCelChrvpTYQtYACfZnIyQGFNBtrMbVb0I7ssDHcFPeyDlbKg4iDyBEwCtfyjeCU9bWQfkulL/xzNz2B2xhnV0HYHNh1wUxCO+iQRHGn0IQ5Jr/z7aPoJKqaJVTO+kRLzSF6Sb5TkSM= Received: by 10.90.73.7 with SMTP id v7mr2944280aga.1177624336564; Thu, 26 Apr 2007 14:52:16 -0700 (PDT) Received: by 10.90.36.4 with HTTP; Thu, 26 Apr 2007 14:52:16 -0700 (PDT) Message-ID: Date: Thu, 26 Apr 2007 17:52:16 -0400 From: "Bosko Milekic" To: "Hans Petter Selasky" In-Reply-To: <200704262136.33196.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200704262136.33196.hselasky@c2i.net> X-Mailman-Approved-At: Fri, 27 Apr 2007 11:38:03 +0000 Cc: freebsd-hackers@freebsd.org Subject: Re: msleep() on recursivly locked mutexes 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, 26 Apr 2007 22:20:56 -0000 On 4/26/07, Hans Petter Selasky wrote: > Hi, > > In the new USB stack I have defined the following: Could you perhaps describe some of the codepaths in the USB stack that require this behavior? -- Bosko Milekic http://www.crowdedweb.com/ From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 27 13:14:36 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C39F416A400 for ; Fri, 27 Apr 2007 13:14:36 +0000 (UTC) (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 8A4CF13C484 for ; Fri, 27 Apr 2007 13:14:36 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.ntplx.net (8.14.0/8.14.0/NETPLEX) with ESMTP id l3RDEAgN010070; Fri, 27 Apr 2007 09:14:11 -0400 (EDT) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-3.0 (mail.ntplx.net [204.213.176.10]); Fri, 27 Apr 2007 09:14:11 -0400 (EDT) Date: Fri, 27 Apr 2007 09:14:10 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Hans Petter Selasky In-Reply-To: <200704270748.49404.hselasky@c2i.net> Message-ID: References: <200704262136.33196.hselasky@c2i.net> <46311708.5030002@elischer.org> <3bbf2fe10704261450n50b66392saa7dc2ea7f091d31@mail.gmail.com> <200704270748.49404.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Attilio Rao , freebsd-hackers@freebsd.org, Julian Elischer Subject: Re: msleep() on recursivly locked mutexes 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: Fri, 27 Apr 2007 13:14:36 -0000 On Fri, 27 Apr 2007, Hans Petter Selasky wrote: > On Thursday 26 April 2007 23:50, Attilio Rao wrote: >> 2007/4/26, Julian Elischer : >>> The reason that mutexes ever recurse in the first place is usually >>> because one piece of code calls itself (or a related piece of code) in a >>> blind manner.. in other words, it doesn't know it is doing so. The whole >>> concept of recursing mutexes is a bit gross. The concept of blindly >>> unwinding them is I think just asking for trouble. >>> >>> Further the idea that holding a mutex "except for when we sleep" is a >>> generally bright idea is also a bit odd to me.. If you hold a mutex and >>> release it during sleep you probably should invalidate all assumptions >>> you made during the period before you slept as whatever you were > > That is not always correct. If you run your code in a separate > thread/taskqueue, then you simply wait for this thread/taskqueue to complete > somewhere else. This is basically when I need to exit mutexes. I know there are reasons why we have msleep(), but use of msleep() and recursive mutexes should raise be frowned upon. If you want to sleep, that's why we have condvar's. And if you are releasing a synchronization lock in a different thread, then why aren't you using condvar's wrapped by mutexes() to protect the internal state? When you hold a mutex, it should be for a very short time. And I agree with the other comment that all drivers should be multi-thread safe, so we shouldn't add cruft to allow for non MT-safe drivers. -- DE From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 27 17:41:20 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3754E16A400 for ; Fri, 27 Apr 2007 17:41:20 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outA.internet-mail-service.net (outA.internet-mail-service.net [216.240.47.224]) by mx1.freebsd.org (Postfix) with ESMTP id 2251E13C4AD for ; Fri, 27 Apr 2007 17:41:20 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Fri, 27 Apr 2007 10:08:22 -0700 Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id E0E73125B53; Fri, 27 Apr 2007 10:41:18 -0700 (PDT) Message-ID: <463235D1.5030605@elischer.org> Date: Fri, 27 Apr 2007 10:41:37 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: Hans Petter Selasky References: <200704262136.33196.hselasky@c2i.net> <46311708.5030002@elischer.org> <3bbf2fe10704261450n50b66392saa7dc2ea7f091d31@mail.gmail.com> <200704270748.49404.hselasky@c2i.net> In-Reply-To: <200704270748.49404.hselasky@c2i.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Attilio Rao , freebsd-hackers@freebsd.org Subject: Re: msleep() on recursivly locked mutexes 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, 27 Apr 2007 17:41:20 -0000 Hans Petter Selasky wrote: > On Thursday 26 April 2007 23:50, Attilio Rao wrote: >> 2007/4/26, Julian Elischer : >>> The reason that mutexes ever recurse in the first place is usually >>> because one piece of code calls itself (or a related piece of code) in a >>> blind manner.. in other words, it doesn't know it is doing so. The whole >>> concept of recursing mutexes is a bit gross. The concept of blindly >>> unwinding them is I think just asking for trouble. >>> >>> Further the idea that holding a mutex "except for when we sleep" is a >>> generally bright idea is also a bit odd to me.. If you hold a mutex and >>> release it during sleep you probably should invalidate all assumptions >>> you made during the period before you slept as whatever you were > > That is not always correct. If you run your code in a separate > thread/taskqueue, then you simply wait for this thread/taskqueue to complete > somewhere else. This is basically when I need to exit mutexes. then you are probably using the wrong synchronization primitive. > >>> protecting has possibly been raped while you slept. I have seen too many >>> instances where people just called msleep and dropped the mutex they >>> held, picked it up again on wakeup, and then blithely continued on >>> without checking what happened while they were asleep. >> Basically, the idea you cannot hold "blocking" locks (mutexes and >> rwlocks) while sleeping, cames from the difference there is behind >> turnstiles and sleepqueues. >> >> Turnstiles are thought to serve syncronous events, for short period of >> time (or rather short) while sleepqueues are thought to serve >> asyncronous events, so that the path to be protected can be >> definitively bigger. If you fit in the situation you have to call >> first a blocking lock and later a sleeping lock, probabilly you are >> just using a wrong locking strategy and you should really revisit it. that's what I think.. if you are trying to make a nail with threading, then you probably should be using a screw to start with. You obviously know a lot about USB. You have a good grask of how that works. Maybe what you need to do is write a small document on how the USB side should work, and what needs to be locked, and enter into a cooperative partnership with some other people who are active in the locking side of things to produce an optimal locking strategy for your module. > > The suggestion is just for convenience. Usually you don't have a recursed > mutex to sleep on. It is just to catch some rare cases where you will end up > with a doubly locked mutex, which is not part of the ordinary code path. I > don't have such cases in the kernel of the new USB stack, but there are some > cases in the USB device drivers, which is due to some mutex locking moves. > Those I can fix. Basically you shouldn't have a recursed mutex FULL STOP. We have a couple of instances in the kernel where we allow a mutex to recurse, but they had to be hard fought, and the general rule is "Don't". If you are recursing on a mutex you need to switch to some other method of doing things. e.g. reference counts, turnstiles, whatever.. use the mutex to create these but don't hold the mutex for long enough to need to recurse on it. A mutex should generally lock, dash-in and work, unlock. We have some cases where that is not true, but we are trying to get rid of them, not add more. also look at read-write type locks for use as much as possible, (man 9 locking) should be a guide to this (if people were to add to this it would be even better). > > My idea was that by allowing recursive mutexes to sleep, you will end up with > less panics in the end for the unwary code developer. You just protect your > code with mutexes and if they recurse calling synchronous USB functions, you > don't have to care. I think trying to sleep with a recursed mutex should be an instant panic, even if the mutex IS marked as being allowed to sleep. > >> As you mention, it is not always possible to drop the blocking lock >> before to sleep since you can break your critical path and free the >> way for races of various genre. Even unlocking Giant, that is >> auto-magically done by sleeping primitives, can lead to very difficult >> to discover races (I can remind one in tty code, old of some months, >> that can be a good proof-of-concept for that). >> > > --HPS From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 27 17:49:42 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1668916A46D for ; Fri, 27 Apr 2007 17:49:42 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.freebsd.org (Postfix) with ESMTP id DCE4613C45A for ; Fri, 27 Apr 2007 17:49:41 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.13.8/8.13.7) with ESMTP id l3RHdHrS009989; Fri, 27 Apr 2007 10:39:17 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.13.8/8.13.4/Submit) id l3RHdG7a009988; Fri, 27 Apr 2007 10:39:16 -0700 (PDT) Date: Fri, 27 Apr 2007 10:39:16 -0700 (PDT) From: Matthew Dillon Message-Id: <200704271739.l3RHdG7a009988@apollo.backplane.com> To: Hans Petter Selasky References: <200704262136.33196.hselasky@c2i.net> <46311708.5030002@elischer.org> <200704270753.05438.hselasky@c2i.net> Cc: freebsd-hackers@freebsd.org, Julian Elischer Subject: Re: msleep() on recursivly locked mutexes 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, 27 Apr 2007 17:49:42 -0000 The real culprit here is passing held mutexes to unrelated procedures in the first place because those procedures might have to block, in order so those procedures can release and reacquire the mutex. That's just bad coding in my view. The unrelated procedure has no clue as to what the mutex is or why it is being held and really has no business messing with it. What I did was implement spinlocks with VERY restricted capabilities, far more restricted then the capabilities of your mutexes. Our spinlocks are meant only to be used to lock up tiny pieces of code (like for ref counting or structural or flag-changing operations). Plus the kernel automatically acts as if it were in a critical section if it takes an interrupt while the current thread is holding a spinlock. That way mainline code can just use a spinlock to deal with small bits of interlocked information without it costing much in the way of overhead. I made the decision that ANYTHING more complex then that would have to use a real lock, like a lockmgr lock or a token, depending on the characteristics desired. To make it even more desireable I also stripped down the lockmgr() lock implementation, removing numerous bits that were inherited from very old code methodologies that have no business being in a modern operating system, like LK_DRAIN. And I removed the passing of an interlocking spinlock to the lockmgr code, because that methodology was being massively abused in existing code (and I do mean massively). I'm not quite sure what the best way to go is for FreeBSD, because you guys have made your mutexes just as or even more sophisticated then your normal locks in many respects, and you have like 50 different types of locks now (I can't keep track of them all). If I were to offer advise it would be: Just stop trying to mix water and hot wax. Stop holding mutexes across potentially blocking procedure calls. Stop passing mutexes into unrelated bits of code in order for them to be released and reacquired somewhere deep in that code. Just doing that will probably solve all of the problems being reported. -Matt From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 27 18:01:10 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C8E4E16A402 for ; Fri, 27 Apr 2007 18:01:10 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outN.internet-mail-service.net (outN.internet-mail-service.net [216.240.47.237]) by mx1.freebsd.org (Postfix) with ESMTP id B4DFF13C487 for ; Fri, 27 Apr 2007 18:01:10 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Fri, 27 Apr 2007 10:28:13 -0700 Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id A2062125B34; Fri, 27 Apr 2007 11:01:09 -0700 (PDT) Message-ID: <46323A77.8010907@elischer.org> Date: Fri, 27 Apr 2007 11:01:27 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: Hans Petter Selasky References: <200704262136.33196.hselasky@c2i.net> <200704270748.49404.hselasky@c2i.net> <200704271917.29939.hselasky@freebsd.org> In-Reply-To: <200704271917.29939.hselasky@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Daniel Eischen , Attilio Rao , freebsd-hackers@freebsd.org Subject: Re: msleep() on recursivly locked mutexes 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, 27 Apr 2007 18:01:10 -0000 Hans Petter Selasky wrote: > First of all: Where is FreeBSD's locking strategy document? It is just started.. man 9 locking. it needs a lot of work still. > We should have a > global strategy when we write device drivers, so that various modules can be > connected together without races and locking order reversals. > > In my view there are two categories of mutexes. > > 1) Global mutexes. > > 2) Private mutexes. > > Rule: The Global mutex is locked last. errr I'm not sure I'm following but this sounds kind-of reversed from normal behaviour. > > How do we organize this. > > 1a) The global mutex protects interrupts/callbacks into a hardware driver. > This is the lowest level. > > 2a) Private mutexes protects sub-devices of the hardware driver. This might be > as simple as an IF-QUEUE. > I'm having trouble following already. you mean subcomponents? > I have chosen the following model: > > P0 indicates process 0. P1 indicates an optional second process. > > Up-call: > > P0 lock(2); > P0 lock(1); > P0 unlock(1); > P0 unlock(2); this looks "interesting". Can you give a more concrete example of this? what work is done in the upcall? WHo is upcalling to who? > > Down-call: > > P1 lock(1); > P1 wakeup P0 // for example > P1 unlock(1); pretty normal. > > P0 //callback: > P0 lock(2); // the new USB stack currently uses P1 here > P0 unlock(2); > > Sure, in the up-call you lock #2 longer than lock #1, that is why lock #1 has > got to be a short as possible. But it does not make sense to make lock #2 > lock shorter than lock #1. I cannot see that the system will go faster that > way. > > In the downcall I see no problems at all. #1 does its things as fast as > possible. In parallell #2 can still execute, until the "callback". > > I hope you understand my semantics. > > What do you want to change from what I have explained? > > Any comments? > > My conclusion: If you want more paralellism, then use more mutexes. Don't try > to push an existing mutex by unlocking it! that may or may not be true depending on how busy the mutex is.. but I don't think there is an argument about this. shouldn't this be somewhere other than "hackers"? > > --HPS From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 27 18:07:22 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7E2B316A400 for ; Fri, 27 Apr 2007 18:07:22 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outC.internet-mail-service.net (outC.internet-mail-service.net [216.240.47.226]) by mx1.freebsd.org (Postfix) with ESMTP id 6C57D13C4B0 for ; Fri, 27 Apr 2007 18:07:22 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Fri, 27 Apr 2007 10:34:24 -0700 Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id EDEE3125B44; Fri, 27 Apr 2007 11:07:20 -0700 (PDT) Message-ID: <46323BEB.1020404@elischer.org> Date: Fri, 27 Apr 2007 11:07:39 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: Matthew Dillon References: <200704262136.33196.hselasky@c2i.net> <46311708.5030002@elischer.org> <200704270753.05438.hselasky@c2i.net> <200704271739.l3RHdG7a009988@apollo.backplane.com> In-Reply-To: <200704271739.l3RHdG7a009988@apollo.backplane.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, Hans Petter Selasky Subject: Re: msleep() on recursivly locked mutexes 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, 27 Apr 2007 18:07:22 -0000 Matthew Dillon wrote: > The real culprit here is passing held mutexes to unrelated procedures > in the first place because those procedures might have to block, in > order so those procedures can release and reacquire the mutex. > That's just bad coding in my view. The unrelated procedure has no > clue as to what the mutex is or why it is being held and really has no > business messing with it. [description of DFLY spinlocks removed for brevity] > > If I were to offer advise it would be: Just stop trying to mix water > and hot wax. Stop holding mutexes across potentially blocking procedure > calls. Stop passing mutexes into unrelated bits of code in order for > them to be released and reacquired somewhere deep in that code. Just > doing that will probably solve all of the problems being reported. Actually Matt, I don't think there is much argument here.. It has come to the time where locking needs a big broom, and I suspect that there will be such a broom activated at BSDCan. There is some work going on (by john and others) to 'unify and sanitise' the locking. We'll see where it goes. Or is that wax and hot water? From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 27 18:09:23 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4999716A403 for ; Fri, 27 Apr 2007 18:09:23 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outJ.internet-mail-service.net (outJ.internet-mail-service.net [216.240.47.233]) by mx1.freebsd.org (Postfix) with ESMTP id 36EA213C46A for ; Fri, 27 Apr 2007 18:09:23 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Fri, 27 Apr 2007 10:36:25 -0700 Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 2A26B125B45; Fri, 27 Apr 2007 11:09:22 -0700 (PDT) Message-ID: <46323C64.6010102@elischer.org> Date: Fri, 27 Apr 2007 11:09:40 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: Hans Petter Selasky References: <200704262136.33196.hselasky@c2i.net> <46311708.5030002@elischer.org> <3bbf2fe10704261450n50b66392saa7dc2ea7f091d31@mail.gmail.com> <200704270748.49404.hselasky@c2i.net> <463235D1.5030605@elischer.org> In-Reply-To: <463235D1.5030605@elischer.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Attilio Rao , freebsd-hackers@freebsd.org Subject: Re: msleep() on recursivly locked mutexes 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, 27 Apr 2007 18:09:23 -0000 Julian Elischer wrote: > > I think trying to sleep with a recursed mutex should be an instant panic, > even if the mutex IS marked as being allowed to sleep. I mean marked as being able to recurse. > >> From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 27 18:10:33 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B2A2716A404 for ; Fri, 27 Apr 2007 18:10:33 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe12.swip.net [212.247.155.97]) by mx1.freebsd.org (Postfix) with ESMTP id 2C04713C459 for ; Fri, 27 Apr 2007 18:10:32 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] Received: from [193.71.38.142] (account mc467741@c2i.net HELO [10.42.11.147]) by mailfe12.swip.net (CommuniGate Pro SMTP 5.1.7) with ESMTPA id 304786933; Fri, 27 Apr 2007 20:10:31 +0200 From: Hans Petter Selasky To: Matthew Dillon Date: Fri, 27 Apr 2007 20:10:14 +0200 User-Agent: KMail/1.9.5 References: <200704262136.33196.hselasky@c2i.net> <200704270753.05438.hselasky@c2i.net> <200704271739.l3RHdG7a009988@apollo.backplane.com> In-Reply-To: <200704271739.l3RHdG7a009988@apollo.backplane.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200704272010.14812.hselasky@c2i.net> Cc: freebsd-hackers@freebsd.org, Julian Elischer Subject: Re: msleep() on recursivly locked mutexes 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, 27 Apr 2007 18:10:33 -0000 On Friday 27 April 2007 19:39, Matthew Dillon wrote: > The real culprit here is passing held mutexes to unrelated procedures > in the first place because those procedures might have to block, in > order so those procedures can release and reacquire the mutex. > That's just bad coding in my view. The unrelated procedure has no > clue as to what the mutex is or why it is being held and really has no > business messing with it. > > What I did was implement spinlocks with VERY restricted capabilities, > far more restricted then the capabilities of your mutexes. Our > spinlocks are meant only to be used to lock up tiny pieces of code > (like for ref counting or structural or flag-changing operations). > Plus the kernel automatically acts as if it were in a critical section > if it takes an interrupt while the current thread is holding a > spinlock. That way mainline code can just use a spinlock to deal with small > bits of interlocked information without it costing much in the way of > overhead. > > I made the decision that ANYTHING more complex then that would have to > use a real lock, like a lockmgr lock or a token, depending on the > characteristics desired. To make it even more desireable I also > stripped down the lockmgr() lock implementation, removing numerous > bits that were inherited from very old code methodologies that have no > business being in a modern operating system, like LK_DRAIN. And I > removed the passing of an interlocking spinlock to the lockmgr code, > because that methodology was being massively abused in existing code > (and I do mean massively). > > I'm not quite sure what the best way to go is for FreeBSD, because > you guys have made your mutexes just as or even more sophisticated > then your normal locks in many respects, and you have like 50 different > types of locks now (I can't keep track of them all). > > If I were to offer advise it would be: Just stop trying to mix water > and hot wax. Stop holding mutexes across potentially blocking > procedure calls. Stop passing mutexes into unrelated bits of code in order > for them to be released and reacquired somewhere deep in that code. Just > doing that will probably solve all of the problems being reported. Maybe one should put some characters into blocking and non-blocking function names so that the compiler can check if non-blocking functions call blocking functions. Doing everything blocking will make the system work, but suddently it can dead-lock, when two threads are waiting for eachother, and you will have zero clue about it. I like the current FreeBSD. It's a brain exercise and it clearly shows that MPSAFE/Giant-free is quality mark, and not something you acchieve by adding some lock/unlock statements here and there. Sometimes it means you have to completely rewrite code. And that is the most difficult part to convince other developers about. Been there done that :-) --HPS From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 27 18:17:55 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0FB1816A411; Fri, 27 Apr 2007 18:17:55 +0000 (UTC) (envelope-from hselasky@freebsd.org) Received: from swip.net (mailfe09.swip.net [212.247.155.1]) by mx1.freebsd.org (Postfix) with ESMTP id 286D913C484; Fri, 27 Apr 2007 18:17:53 +0000 (UTC) (envelope-from hselasky@freebsd.org) X-Cloudmark-Score: 0.000000 [] Received: from [193.71.38.142] (account mc467741@c2i.net HELO [10.42.11.147]) by mailfe09.swip.net (CommuniGate Pro SMTP 5.1.7) with ESMTPA id 306539616; Fri, 27 Apr 2007 19:17:47 +0200 From: Hans Petter Selasky To: Daniel Eischen Date: Fri, 27 Apr 2007 19:17:29 +0200 User-Agent: KMail/1.9.5 References: <200704262136.33196.hselasky@c2i.net> <200704270748.49404.hselasky@c2i.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200704271917.29939.hselasky@freebsd.org> Cc: Attilio Rao , freebsd-hackers@freebsd.org, Julian Elischer Subject: Re: msleep() on recursivly locked mutexes 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, 27 Apr 2007 18:17:55 -0000 On Friday 27 April 2007 15:14, Daniel Eischen wrote: > On Fri, 27 Apr 2007, Hans Petter Selasky wrote: > > On Thursday 26 April 2007 23:50, Attilio Rao wrote: > >> 2007/4/26, Julian Elischer : > >>> The reason that mutexes ever recurse in the first place is usually > >>> because one piece of code calls itself (or a related piece of code) in > >>> a blind manner.. in other words, it doesn't know it is doing so. The > >>> whole concept of recursing mutexes is a bit gross. The concept of > >>> blindly unwinding them is I think just asking for trouble. > >>> > >>> Further the idea that holding a mutex "except for when we sleep" is a > >>> generally bright idea is also a bit odd to me.. If you hold a mutex and > >>> release it during sleep you probably should invalidate all assumptions > >>> you made during the period before you slept as whatever you were > > > > That is not always correct. If you run your code in a separate > > thread/taskqueue, then you simply wait for this thread/taskqueue to > > complete somewhere else. This is basically when I need to exit mutexes. > > I know there are reasons why we have msleep(), but use of msleep() > and recursive mutexes should raise be frowned upon. If you want to > sleep, that's why we have condvar's. And if you are releasing a > synchronization lock in a different thread, then why aren't you > using condvar's wrapped by mutexes() to protect the internal state? When I find time, I will convert my new USB stack into using condvar's, but they will do the same as msleep(), and that is to exit the passed mutex. > > When you hold a mutex, it should be for a very short time. And > I agree with the other comment that all drivers should be multi-thread > safe, so we shouldn't add cruft to allow for non MT-safe drivers. Yes, and no. Mutexes are used to get the CPU out of the code. Therefore you should not lock/unlock all the time, to ensure that the locked time is as short as possible. Because then you get double work checking the state after that you lock a mutex again. Surely, in a "static" environment there is nothing to check. But in a dynamic environment you need to check that "descriptors" of all kinds are still present, after that you lock a mutex. Unlocking a mutex allows "anything" to happen. Keeping a mutex locked prevents certain things from happening. First of all: Where is FreeBSD's locking strategy document? We should have a global strategy when we write device drivers, so that various modules can be connected together without races and locking order reversals. In my view there are two categories of mutexes. 1) Global mutexes. 2) Private mutexes. Rule: The Global mutex is locked last. How do we organize this. 1a) The global mutex protects interrupts/callbacks into a hardware driver. This is the lowest level. 2a) Private mutexes protects sub-devices of the hardware driver. This might be as simple as an IF-QUEUE. I have chosen the following model: P0 indicates process 0. P1 indicates an optional second process. Up-call: P0 lock(2); P0 lock(1); P0 unlock(1); P0 unlock(2); Down-call: P1 lock(1); P1 wakeup P0 // for example P1 unlock(1); P0 //callback: P0 lock(2); // the new USB stack currently uses P1 here P0 unlock(2); Sure, in the up-call you lock #2 longer than lock #1, that is why lock #1 has got to be a short as possible. But it does not make sense to make lock #2 lock shorter than lock #1. I cannot see that the system will go faster that way. In the downcall I see no problems at all. #1 does its things as fast as possible. In parallell #2 can still execute, until the "callback". I hope you understand my semantics. What do you want to change from what I have explained? Any comments? My conclusion: If you want more paralellism, then use more mutexes. Don't try to push an existing mutex by unlocking it! --HPS From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 27 18:36:24 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1C3C016A401; Fri, 27 Apr 2007 18:36:24 +0000 (UTC) (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 D3C1013C43E; Fri, 27 Apr 2007 18:36:23 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.ntplx.net (8.14.0/8.14.0/NETPLEX) with ESMTP id l3RIaLew013944; Fri, 27 Apr 2007 14:36:21 -0400 (EDT) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-3.0 (mail.ntplx.net [204.213.176.10]); Fri, 27 Apr 2007 14:36:21 -0400 (EDT) Date: Fri, 27 Apr 2007 14:36:21 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Hans Petter Selasky In-Reply-To: <200704271917.29939.hselasky@freebsd.org> Message-ID: References: <200704262136.33196.hselasky@c2i.net> <200704270748.49404.hselasky@c2i.net> <200704271917.29939.hselasky@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Attilio Rao , freebsd-hackers@freebsd.org, Julian Elischer Subject: Re: msleep() on recursivly locked mutexes 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: Fri, 27 Apr 2007 18:36:24 -0000 On Fri, 27 Apr 2007, Hans Petter Selasky wrote: > On Friday 27 April 2007 15:14, Daniel Eischen wrote: >> >> When you hold a mutex, it should be for a very short time. And >> I agree with the other comment that all drivers should be multi-thread >> safe, so we shouldn't add cruft to allow for non MT-safe drivers. > > Yes, and no. > > Mutexes are used to get the CPU out of the code. Therefore you should not > lock/unlock all the time, to ensure that the locked time is as short as > possible. Because then you get double work checking the state after that you > lock a mutex again. Surely, in a "static" environment there is nothing to > check. But in a dynamic environment you need to check that "descriptors" of > all kinds are still present, after that you lock a mutex. Unlocking a mutex > allows "anything" to happen. Keeping a mutex locked prevents certain things > from happening. If you need to prevent "things" from happening, and it is at more of a macro level than micro level, then you probably want a condvar or barrier sort of synchroninzation, or possibly a rwlock. When the thread currently in the guts of your driver exits, he releases the CV or rwlock and allows another thread to enter (which possibly causes another "anything" to happen). -- DE From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 27 19:03:05 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DBAD016A403 for ; Fri, 27 Apr 2007 19:03:05 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.freebsd.org (Postfix) with ESMTP id 3F45A13C455 for ; Fri, 27 Apr 2007 19:03:04 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id l3RJ2wST086294; Fri, 27 Apr 2007 15:02:58 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Fri, 27 Apr 2007 11:49:41 -0400 User-Agent: KMail/1.9.6 References: <200704262136.33196.hselasky@c2i.net> In-Reply-To: <200704262136.33196.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200704271149.42325.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Fri, 27 Apr 2007 15:02:58 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/3172/Fri Apr 27 10:49:40 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.2 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00, DATE_IN_PAST_03_06 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Hans Petter Selasky Subject: Re: msleep() on recursivly locked mutexes 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, 27 Apr 2007 19:03:05 -0000 On Thursday 26 April 2007 03:36:33 pm Hans Petter Selasky wrote: > Are there any comments on integrating this functionality into msleep(), and > adding mtx_drop_recurse() and mtx_pickup_recurse() to the FreeBSD kernel? Nope. Fix the code to not recurse instead, or to know it has a recursed mutex and make sure it doesn't call mtx_sleep() or cv_wait() with a recursed lock. It's not that hard to do. The rest of the kernel manages that restriction fine. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 27 19:03:09 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0B58916A4CF for ; Fri, 27 Apr 2007 19:03:09 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.freebsd.org (Postfix) with ESMTP id 5FF1813C465 for ; Fri, 27 Apr 2007 19:03:08 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id l3RJ2wSU086294; Fri, 27 Apr 2007 15:03:02 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: Marc =?iso-8859-1?q?L=F6rner?= Date: Fri, 27 Apr 2007 11:51:54 -0400 User-Agent: KMail/1.9.6 References: <200704261408.19885.marc.loerner@hob.de> <200704261349.35661.jhb@freebsd.org> <200704270843.16908.marc.loerner@hob.de> In-Reply-To: <200704270843.16908.marc.loerner@hob.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200704271151.54720.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Fri, 27 Apr 2007 15:03:02 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/3172/Fri Apr 27 10:49:40 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.1 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00, DATE_IN_PAST_03_06 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: freebsd-hackers@freebsd.org Subject: Re: Usage of kern_* functions in kernel 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, 27 Apr 2007 19:03:09 -0000 On Friday 27 April 2007 02:43:16 am Marc L=F6rner wrote: > On Thursday 26 April 2007 19:49, John Baldwin wrote: > > On Thursday 26 April 2007 08:08:19 am Marc L=F6rner wrote: > > > Hello, > > > I googled but found nothing about the usage of the kern_* functions > > > (kern_open, kern_close, kern_pwritev, kern_preadv) that are located in > > > vfs_syscalls.c > > > > > > When I use kern_open to open a file within the kernel, I get an error. > > > When I use the normal vn_open function instead, all works well. > > > > > > So my question is which functions are recommended by you kernel-hacke= rs > > > for use within kernelspace? > > > > > > And here a second question: Is it possible to open/use the console=20 driver > > > in kernelspace within the functions mentioned above? > > > If not, can you give me some pointers on where I can find this > > > information! > > > > kern_XXX are generally used by system calls such as alternative ABIs, e= tc. >=20 > so, you would recommend using the vn_* functions instead? In general userland should open files rather than the kernel. =2D-=20 John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 27 19:34:23 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7333316A407; Fri, 27 Apr 2007 19:34:23 +0000 (UTC) (envelope-from hselasky@freebsd.org) Received: from swip.net (mailfe13.swip.net [212.247.155.129]) by mx1.freebsd.org (Postfix) with ESMTP id 600C913C46C; Fri, 27 Apr 2007 19:34:22 +0000 (UTC) (envelope-from hselasky@freebsd.org) X-Cloudmark-Score: 0.000000 [] Received: from [193.71.38.142] (account mc467741@c2i.net HELO [10.42.11.147]) by mailfe13.swip.net (CommuniGate Pro SMTP 5.1.7) with ESMTPA id 83177350; Fri, 27 Apr 2007 20:32:38 +0200 From: Hans Petter Selasky To: freebsd-hackers@freebsd.org Date: Fri, 27 Apr 2007 20:32:20 +0200 User-Agent: KMail/1.9.5 References: <200704262136.33196.hselasky@c2i.net> <200704271917.29939.hselasky@freebsd.org> <46323A77.8010907@elischer.org> In-Reply-To: <46323A77.8010907@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200704272032.20664.hselasky@freebsd.org> Cc: Daniel Eischen , Attilio Rao , Julian Elischer , freebsd-arch@freebsd.org Subject: Re: msleep() on recursivly locked mutexes 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, 27 Apr 2007 19:34:23 -0000 On Friday 27 April 2007 20:01, Julian Elischer wrote: > Hans Petter Selasky wrote: > > First of all: Where is FreeBSD's locking strategy document? > > It is just started.. > man 9 locking. it needs a lot of work still. Excellent. > > > We should have a > > global strategy when we write device drivers, so that various modules can > > be connected together without races and locking order reversals. > > > > In my view there are two categories of mutexes. > > > > 1) Global mutexes. > > > > 2) Private mutexes. > > > > Rule: The Global mutex is locked last. > > errr I'm not sure I'm following but this sounds kind-of reversed from > normal behaviour. Yes, it is. But you have to make a choice. Either this way or the other way. But not both! The reason for my choice is that I consider it to be more complicated to be a Global device than a private device. Complicated means that the Global device, which is locked last, has to unlock its lock before it calls back the "private" device, like I have explained below. Hence there are fewer Global devices (e.g. USB host controllers), then private devices (USB device drivers), we end up with less code/headache locking the Global devices last. If that is unclear I can explain more. > > > How do we organize this. > > > > 1a) The global mutex protects interrupts/callbacks into a hardware > > driver. This is the lowest level. > > > > 2a) Private mutexes protects sub-devices of the hardware driver. This > > might be as simple as an IF-QUEUE. > > I'm having trouble following already. > you mean subcomponents? Yes, children of devices. Sub-devices. > > > I have chosen the following model: > > > > P0 indicates process 0. P1 indicates an optional second process. > > > > Up-call: > > > > P0 lock(2); > > P0 lock(1); The work done [here] might be to setup DMA-able memory, and link it into the hardware. > > P0 unlock(1); > > P0 unlock(2); > > this looks "interesting". > Can you give a more concrete example of this? > what work is done in the upcall? WHo is upcalling to who? For example an USB device driver might be up-calling to the USB host controller driver. Down call is when the transfer finishes. > > > Down-call: > > > > P1 lock(1); > > P1 wakeup P0 // for example > > P1 unlock(1); > > pretty normal. > > > P0 //callback: > > P0 lock(2); // the new USB stack currently uses P1 here > > P0 unlock(2); > > > > > > > > Sure, in the up-call you lock #2 longer than lock #1, that is why lock #1 > > has got to be a short as possible. But it does not make sense to make > > lock #2 lock shorter than lock #1. I cannot see that the system will go > > faster that way. > > > > In the downcall I see no problems at all. #1 does its things as fast as > > possible. In parallell #2 can still execute, until the "callback". > > > > I hope you understand my semantics. > > > > What do you want to change from what I have explained? > > > > Any comments? > > > > My conclusion: If you want more paralellism, then use more mutexes. Don't > > try to push an existing mutex by unlocking it! > > that may or may not be true depending on how busy the mutex is.. > but I don't think there is an argument about this. > > > shouldn't this be somewhere other than "hackers"? I've CC'ed freebsd-arch. --HPS From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 27 19:40:26 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D875116A402 for ; Fri, 27 Apr 2007 19:40:26 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.229]) by mx1.freebsd.org (Postfix) with ESMTP id 954A613C45B for ; Fri, 27 Apr 2007 19:40:24 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: by wr-out-0506.google.com with SMTP id 70so1001547wra for ; Fri, 27 Apr 2007 12:40:23 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=fLGPEjpXoO+eslFm9XwtWh6OYPvXIz8GcgbUb2oKN8+ktkCG3wuLAdZE+Gt2dsQAffm+ize+scmg+WaHsBjdFFhcN+CQAe7r2sb3uoS1Wb08DCQ5j/ceqTXSSBr3QVxWcR+nglnzysu9Y+/Xd6b+xLu6sbMBaXdse2+wDo61EJg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=sxx9lJvKXokNnPhTzIbW7voPAcu5gFs1LOAYInBfaVhgrXON3pZA9ICAqCR6AYzzRmO79SzzJouXiT7dbDOP+A/EEGkR9IvyK/h/ghsfs5uAHeqr7e94A3LJ46Kl+4yEVl3uZwh2wr0Hw6pdK3FjNQmNZHquAwQFeX9SiD/kA2o= Received: by 10.78.146.11 with SMTP id t11mr1105483hud.1177701253606; Fri, 27 Apr 2007 12:14:13 -0700 (PDT) Received: by 10.78.107.4 with HTTP; Fri, 27 Apr 2007 12:14:13 -0700 (PDT) Message-ID: Date: Fri, 27 Apr 2007 12:14:13 -0700 From: "Kip Macy" To: "John Baldwin" , "=?ISO-8859-1?Q?Marc_L=F6rner?=" , freebsd-hackers@freebsd.org In-Reply-To: <200704271151.54720.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <200704261408.19885.marc.loerner@hob.de> <200704261349.35661.jhb@freebsd.org> <200704270843.16908.marc.loerner@hob.de> <200704271151.54720.jhb@freebsd.org> Cc: Subject: Re: Usage of kern_* functions in kernel 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, 27 Apr 2007 19:40:26 -0000 For core files and checkpoints that isn't possible. -Kip On 4/27/07, John Baldwin wrote: > On Friday 27 April 2007 02:43:16 am Marc L=F6rner wrote: > > On Thursday 26 April 2007 19:49, John Baldwin wrote: > > > On Thursday 26 April 2007 08:08:19 am Marc L=F6rner wrote: > > > > Hello, > > > > I googled but found nothing about the usage of the kern_* functions > > > > (kern_open, kern_close, kern_pwritev, kern_preadv) that are located= in > > > > vfs_syscalls.c > > > > > > > > When I use kern_open to open a file within the kernel, I get an err= or. > > > > When I use the normal vn_open function instead, all works well. > > > > > > > > So my question is which functions are recommended by you > kernel-hackers > > > > for use within kernelspace? > > > > > > > > And here a second question: Is it possible to open/use the console > driver > > > > in kernelspace within the functions mentioned above? > > > > If not, can you give me some pointers on where I can find this > > > > information! > > > > > > kern_XXX are generally used by system calls such as alternative ABIs, > etc. > > > > so, you would recommend using the vn_* functions instead? > > In general userland should open files rather than the kernel. > > -- > John Baldwin > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org= " > From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 27 22:09:35 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 08A0216A401; Fri, 27 Apr 2007 22:09:35 +0000 (UTC) (envelope-from babkin@verizon.net) Received: from vms046pub.verizon.net (vms046pub.verizon.net [206.46.252.46]) by mx1.freebsd.org (Postfix) with ESMTP id DB12013C458; Fri, 27 Apr 2007 22:09:34 +0000 (UTC) (envelope-from babkin@verizon.net) Received: from vms073.mailsrvcs.net ([172.18.12.131]) by vms046.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPA id <0JH600CLEG7ILDD1@vms046.mailsrvcs.net>; Fri, 27 Apr 2007 17:09:18 -0500 (CDT) Received: from 208.253.138.194 ([208.253.138.194]) by vms073.mailsrvcs.net (Verizon Webmail) with HTTP; Fri, 27 Apr 2007 17:09:18 -0500 (CDT) Date: Fri, 27 Apr 2007 17:09:18 -0500 (CDT) From: Sergey Babkin X-Originating-IP: [208.253.138.194] To: Julian Elischer , Hans Petter Selasky Message-id: <2782784.9021177711758431.JavaMail.root@vms073.mailsrvcs.net> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7bit X-Mailman-Approved-At: Fri, 27 Apr 2007 22:25:26 +0000 Cc: Attilio Rao , freebsd-hackers@freebsd.org Subject: Re: Re: msleep() on recursivly locked mutexes X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: babkin@users.sf.net List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2007 22:09:35 -0000 >From: Julian Elischer >Basically you shouldn't have a recursed mutex FULL STOP. We have a couple >of instances in the kernel where we allow a mutex to recurse, but they had to be >hard fought, and the general rule is "Don't". If you are recursing on >a mutex you need to switch to some other method of doing things. >e.g. reference counts, turnstiles, whatever.. use the mutex to create these One typical problem is when someone holds a mutex and needs to call a function that also tried to get the mutex. The typical solution for it is to provide two versions of this function, one expecting the mutex being already held by the caller, the other being a wrapper that grabs the mutex and then calls the actual worker function. -SB From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 28 09:52:17 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5F4DF16A400 for ; Sat, 28 Apr 2007 09:52:17 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 3B52813C458 for ; Sat, 28 Apr 2007 09:52:17 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id CEF5A46B5D; Sat, 28 Apr 2007 05:52:16 -0400 (EDT) Date: Sat, 28 Apr 2007 10:52:16 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Julian Elischer In-Reply-To: <46311708.5030002@elischer.org> Message-ID: <20070428104944.U28395@fledge.watson.org> References: <200704262136.33196.hselasky@c2i.net> <46311708.5030002@elischer.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org, Hans Petter Selasky Subject: Re: msleep() on recursivly locked mutexes 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, 28 Apr 2007 09:52:17 -0000 On Thu, 26 Apr 2007, Julian Elischer wrote: > Further the idea that holding a mutex "except for when we sleep" is a > generally bright idea is also a bit odd to me.. If you hold a mutex and > release it during sleep you probably should invalidate all assumptions you > made during the period before you slept as whatever you were protecting has > possibly been raped while you slept. I have seen too many instances where > people just called msleep and dropped the mutex they held, picked it up > again on wakeup, and then blithely continued on without checking what > happened while they were asleep. And interesting observation here is that FreeBSD 4.x and earlier were actually rife with exactly this sort of race condition, exercised only when under kernel memory pressure because sleeping occurred only then. The explicit locking model we use now makes these races larger due increased concurrency (preemption, parallelism, etc), but also makes our assertion model stronger. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 28 09:57:34 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D663016A400; Sat, 28 Apr 2007 09:57:34 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id A7B7413C487; Sat, 28 Apr 2007 09:57:34 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 1CF0946C5C; Sat, 28 Apr 2007 05:57:34 -0400 (EDT) Date: Sat, 28 Apr 2007 10:57:34 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Julian Elischer In-Reply-To: <463235D1.5030605@elischer.org> Message-ID: <20070428105428.I28395@fledge.watson.org> References: <200704262136.33196.hselasky@c2i.net> <46311708.5030002@elischer.org> <3bbf2fe10704261450n50b66392saa7dc2ea7f091d31@mail.gmail.com> <200704270748.49404.hselasky@c2i.net> <463235D1.5030605@elischer.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Attilio Rao , freebsd-hackers@freebsd.org, Hans Petter Selasky Subject: Re: msleep() on recursivly locked mutexes 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, 28 Apr 2007 09:57:34 -0000 On Fri, 27 Apr 2007, Julian Elischer wrote: > Basically you shouldn't have a recursed mutex FULL STOP. We have a couple of > instances in the kernel where we allow a mutex to recurse, but they had to > be hard fought, and the general rule is "Don't". If you are recursing on a > mutex you need to switch to some other method of doing things. e.g. > reference counts, turnstiles, whatever.. use the mutex to create these but > don't hold the mutex for long enough to need to recurse on it. A mutex > should generally lock, dash-in and work, unlock. We have some cases where > that is not true, but we are trying to get rid of them, not add more. Most of these instances have to do with legacy code and data structures that involve high levels of code recursion and reentrance. This is frequently an unreliable way to organize code anyway, and often involves other bugs that are less visible. Over time, it's my hope that we can eliminate quite a few sources of remaining lock recursion, but there are some tricky cases involving repeated callbacks between layers that make that harder. For example, in the socket/network pcb relationship, there's a lack of clarity on which side drives the overlapping state machines present in both sets of data structures. Over time, we're migrating towards a model in which the socket infrastructure is more of a "library" in service to network protocols that will drive the actual transitions, but in the mean time, lock recursion is required. For any significantly rewritten or new code, I would expect that recursion would be avoided in almost all cases. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 28 14:14:26 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 37BCC16A401 for ; Sat, 28 Apr 2007 14:14:26 +0000 (UTC) (envelope-from dom@helenmarks.co.uk) Received: from mail.goodforbusiness.co.uk (mail.goodforbusiness.co.uk [81.19.179.90]) by mx1.freebsd.org (Postfix) with ESMTP id EBE7113C45B for ; Sat, 28 Apr 2007 14:14:25 +0000 (UTC) (envelope-from dom@helenmarks.co.uk) Received: from localhost (localhost [127.0.0.1]) by mail.goodforbusiness.co.uk (Postfix) with ESMTP id 14254114C5 for ; Sat, 28 Apr 2007 14:55:44 +0100 (BST) X-Virus-Scanned: mail.goodforbusiness.co.uk Received: from mail.goodforbusiness.co.uk ([127.0.0.1]) by localhost (mail.goodforbusiness.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nd2JQBkcrPbO for ; Sat, 28 Apr 2007 14:55:43 +0100 (BST) Received: from [192.168.2.100] (82-69-13-6.dsl.in-addr.zen.co.uk [82.69.13.6]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: dom@goodforbusiness.co.uk) by mail.goodforbusiness.co.uk (Postfix) with ESMTP id 0DF0B114A7 for ; Sat, 28 Apr 2007 14:55:42 +0100 (BST) Message-ID: <46335268.2030701@helenmarks.co.uk> Date: Sat, 28 Apr 2007 14:55:52 +0100 From: Dominic Marks User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Mono XSP & mod_mono support on FreeBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dom@helenmarks.co.uk List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Apr 2007 14:14:26 -0000 Hackers, Currently XSP (Mono's ASP.NET implementation) does not run on FreeBSD. There is a brief post here about the reasons why from David Xu: http://lists.freebsd.org/pipermail/freebsd-threads/2005-March/002944.html Since that message is over 2 years old I hoped that it might no longer be the case, but when I attempted to run the application it does not work. This is the case if you use libc_r, libthr or libpthread. I was using 6.2-STABLE, if it matters. I am interested if anyone knows if this is likely to ever work. I am more than happy to test patches for anyone who wanted to have a go at it. It seems that there was a previous effort to get it ported but that seems to have run to this issue and stopped. I must be in a very small minority who actually wants capability? Thanks, Dominic From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 28 14:56:00 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E990316A400 for ; Sat, 28 Apr 2007 14:56:00 +0000 (UTC) (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 A870B13C45D for ; Sat, 28 Apr 2007 14:56:00 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.ntplx.net (8.14.0/8.14.0/NETPLEX) with ESMTP id l3SEtxNT028103; Sat, 28 Apr 2007 10:55:59 -0400 (EDT) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-3.0 (mail.ntplx.net [204.213.176.10]); Sat, 28 Apr 2007 10:55:59 -0400 (EDT) Date: Sat, 28 Apr 2007 10:55:59 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Dominic Marks In-Reply-To: <46335268.2030701@helenmarks.co.uk> Message-ID: References: <46335268.2030701@helenmarks.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org Subject: Re: Mono XSP & mod_mono support on FreeBSD 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: Sat, 28 Apr 2007 14:56:01 -0000 On Sat, 28 Apr 2007, Dominic Marks wrote: > Hackers, > > Currently XSP (Mono's ASP.NET implementation) does not run on FreeBSD. > > There is a brief post here about the reasons why from David Xu: > > http://lists.freebsd.org/pipermail/freebsd-threads/2005-March/002944.html > > Since that message is over 2 years old I hoped that it might no longer be the > case, but when I attempted to run the application it does not work. This is > the case if you use libc_r, libthr or libpthread. I was using 6.2-STABLE, if > it matters. > > I am interested if anyone knows if this is likely to ever work. I am more > than happy to test patches for anyone who wanted to have a go at it. It seems > that there was a previous effort to get it ported but that seems to have run > to this issue and stopped. Process shared mutexes and condition variables will never be supported in 6.x. They may occur at some point in 7.x. mono should be fixed so that it respects _POSIX_THREAD_PROCESS_SHARED. -- DE