From owner-freebsd-current@FreeBSD.ORG Sun Aug 31 07:16:28 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C8439106564A for ; Sun, 31 Aug 2008 07:16:28 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.terabit.net.ua (mail.terabit.net.ua [195.137.202.147]) by mx1.freebsd.org (Postfix) with ESMTP id 6A7718FC08 for ; Sun, 31 Aug 2008 07:16:28 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from skuns.zoral.com.ua ([91.193.166.194] helo=mail.zoral.com.ua) by mail.terabit.net.ua with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1KZhAf-000HfY-EW; Sun, 31 Aug 2008 10:16:25 +0300 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m7V7GJo9013182 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 31 Aug 2008 10:16:19 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m7V7GJ4k051017; Sun, 31 Aug 2008 10:16:19 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id m7V7GInV051014; Sun, 31 Aug 2008 10:16:18 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 31 Aug 2008 10:16:18 +0300 From: Kostik Belousov To: Artem Belevich Message-ID: <20080831071618.GK2038@deviant.kiev.zoral.com.ua> References: <20080830183804.GG2038@deviant.kiev.zoral.com.ua> <20080830195844.GI2038@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ohWw6IXhY39HKnGA" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua X-Virus-Scanned: mail.terabit.net.ua 1KZhAf-000HfY-EW 18a7ec7b57280c2a8a7c3f2019c2c331 X-Terabit: YES Cc: Bernd Walter , freebsd-current@freebsd.org Subject: Re: __tls_get_addr problem with recent current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Aug 2008 07:16:28 -0000 --ohWw6IXhY39HKnGA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Aug 30, 2008 at 02:03:00PM -0700, Artem Belevich wrote: > With the new patch kernel has crashed as soon as I ran i386 app, > though the crash happened within in-kernel thread g_up: >=20 > Fatal trap 12: page fault while in kernel mode > cpuid =3D 2; apic id =3D 02 > fault virtual address =3D 0x20 > fault code =3D supervisor read data, page not present > instruction pointer =3D 0x8:0xffffffff804a821f > stack pointer =3D 0x10:0xffffffffac280b60 > frame pointer =3D 0x10:0x0 > code segment =3D base 0x0, limit 0xfffff, type 0x1b > =3D DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags =3D resume, IOPL =3D 0 > current process =3D 3 (g_up) > trap number =3D 12 > panic: page fault > cpuid =3D 2 > Uptime: 37s > Physical memory: 8169 MB > Dumping 380 MB: 365 349 333 317 301 285 269 253 237 221 205 189 173 > 157 141 125 109 93 77 61 45 29 13 Could you, please, show me the disassembled code around the faulted %rip ? --ohWw6IXhY39HKnGA Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAki6RUIACgkQC3+MBN1Mb4jtOwCgyr/vYmo71UKCGPkuv7wN3E34 LV4AoL7F61DJJOXWagk6LDrkt9iR3QeN =sIm+ -----END PGP SIGNATURE----- --ohWw6IXhY39HKnGA-- From owner-freebsd-current@FreeBSD.ORG Sun Aug 31 09:03:15 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7A8331065676 for ; Sun, 31 Aug 2008 09:03:15 +0000 (UTC) (envelope-from caelian@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by mx1.freebsd.org (Postfix) with ESMTP id 09BD18FC29 for ; Sun, 31 Aug 2008 09:03:14 +0000 (UTC) (envelope-from caelian@gmail.com) Received: by ey-out-2122.google.com with SMTP id 6so587850eyi.7 for ; Sun, 31 Aug 2008 02:03:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; 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; bh=BFuHXy0rnZ0b3FtvCdX6V/tyalHYqbP5NthKTLiqJGY=; b=RZ4vhejjwTCLrwZnqg0FHtUr/rwwvvWrI0R05En+AZS8LdxdVuuf5BtEeSGcd/oGv4 20WOSUIXyKmQpPN2p/MNaoB0446QXfHVC6VcmEatVPqRFJ+F5D4kaWIbwQGjFWSSWJJE IEsrRVutJOYXlS8mbBv1l7LEuFTvAfxJFgOmo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=IsigDRkyW2aTO2PstSg72UJI+as8tJI4Eqlc7Gm/iP46T2SRv6PZ5Hv2THCXKzXdVA 1VxjO+1qJBJYjpUdXfC/kf2+sOClOcBdQSz8VIUhk81kOh4ZQzJJTxJ3+weMTIx8Bbhp G5E3ah6GXcAy4gyOSZJMzhEpKre7rSBWjaYj4= Received: by 10.210.37.11 with SMTP id k11mr4536005ebk.136.1220173393394; Sun, 31 Aug 2008 02:03:13 -0700 (PDT) Received: by 10.210.44.20 with HTTP; Sun, 31 Aug 2008 02:03:13 -0700 (PDT) Message-ID: Date: Sun, 31 Aug 2008 11:03:13 +0200 From: "Pascal Hofstee" To: "Christian Weisgerber" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200808290951.44955.jhb@freebsd.org> <20080830010551.GA2090@lorvorc.mips.inka.de> <20080830145757.GG1468@alpha.local> Cc: freebsd-current@freebsd.org Subject: Re: No root filesystem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Aug 2008 09:03:15 -0000 On Sat, Aug 30, 2008 at 5:43 PM, Christian Weisgerber The problem is the fallout from this commit: > > SVN rev 181987 on 2008-08-22 02:14:23Z by jhb > Extend the support for PCI-e memory mapped configuration space access: > > For me, it causes two failures: > (1) atapci (Nvidia MCP55 SATA) doesn't find its connected devices; > (2) k8temp doesn't attach. > > I don't know if there is any conceivable connection between the > two, so it would be nice to know if anybody else can reproduce (2). I am out of town at the moment ... expect to be back home later tonight ... since i am seeing the MCP55 problem myself i'll check to see if i also see the k8temp problem as well, since it does attach for me with the old kernel. -- Pascal Hofstee From owner-freebsd-current@FreeBSD.ORG Sun Aug 31 09:16:53 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D3C9B106566B for ; Sun, 31 Aug 2008 09:16:53 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.terabit.net.ua (mail.terabit.net.ua [195.137.202.147]) by mx1.freebsd.org (Postfix) with ESMTP id 7507F8FC17 for ; Sun, 31 Aug 2008 09:16:53 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from skuns.zoral.com.ua ([91.193.166.194] helo=mail.zoral.com.ua) by mail.terabit.net.ua with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1KZj3D-000GM4-Nd; Sun, 31 Aug 2008 12:16:51 +0300 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m7V9Gdwg016967 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 31 Aug 2008 12:16:40 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m7V9GddD025587; Sun, 31 Aug 2008 12:16:39 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id m7V9GdUo025584; Sun, 31 Aug 2008 12:16:39 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 31 Aug 2008 12:16:39 +0300 From: Kostik Belousov To: Artem Belevich Message-ID: <20080831091639.GM2038@deviant.kiev.zoral.com.ua> References: <20080830183804.GG2038@deviant.kiev.zoral.com.ua> <20080830195844.GI2038@deviant.kiev.zoral.com.ua> <20080831071618.GK2038@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="fBvfXcdybK7Zhu+D" Content-Disposition: inline In-Reply-To: <20080831071618.GK2038@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua X-Virus-Scanned: mail.terabit.net.ua 1KZj3D-000GM4-Nd fb7775fd1918e6a67c994f4082eb23c0 X-Terabit: YES Cc: Bernd Walter , freebsd-current@freebsd.org Subject: Re: __tls_get_addr problem with recent current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Aug 2008 09:16:53 -0000 --fBvfXcdybK7Zhu+D Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Aug 31, 2008 at 10:16:18AM +0300, Kostik Belousov wrote: > On Sat, Aug 30, 2008 at 02:03:00PM -0700, Artem Belevich wrote: > > With the new patch kernel has crashed as soon as I ran i386 app, > > though the crash happened within in-kernel thread g_up: > >=20 > > Fatal trap 12: page fault while in kernel mode > > cpuid =3D 2; apic id =3D 02 > > fault virtual address =3D 0x20 > > fault code =3D supervisor read data, page not present > > instruction pointer =3D 0x8:0xffffffff804a821f > > stack pointer =3D 0x10:0xffffffffac280b60 > > frame pointer =3D 0x10:0x0 > > code segment =3D base 0x0, limit 0xfffff, type 0x1b > > =3D DPL 0, pres 1, long 1, def32 0, gran 1 > > processor eflags =3D resume, IOPL =3D 0 > > current process =3D 3 (g_up) > > trap number =3D 12 > > panic: page fault > > cpuid =3D 2 > > Uptime: 37s > > Physical memory: 8169 MB > > Dumping 380 MB: 365 349 333 317 301 285 269 253 237 221 205 189 173 > > 157 141 125 109 93 77 61 45 29 13 > Could you, please, show me the disassembled code around the faulted > %rip ? No need, it seems I found the problem. I trashed the %rdx that contains the third cpu_switch argument. Please, try the updated patch. Thanks for the testing ! diff --git a/sys/amd64/amd64/cpu_switch.S b/sys/amd64/amd64/cpu_switch.S index f34b0cc..03f0eca 100644 --- a/sys/amd64/amd64/cpu_switch.S +++ b/sys/amd64/amd64/cpu_switch.S @@ -249,6 +249,12 @@ store_seg: 1: movl %ds,PCB_DS(%r8) movl %es,PCB_ES(%r8) movl %fs,PCB_FS(%r8) + movq %rdx,%r11 + movl $MSR_FSBASE,%ecx + rdmsr + shlq $32,%rdx + leaq (%rax,%rdx),%r9 + movq %r11,%rdx jmp done_store_seg 2: movq PCB_GS32P(%r8),%rax movq (%rax),%rax --fBvfXcdybK7Zhu+D Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAki6YXYACgkQC3+MBN1Mb4iTVACdFf/FbQdh/YlDlojF9OopXMJV tRMAnj11dnkHE78sE1fVV/rTF7H7Vutv =B+JS -----END PGP SIGNATURE----- --fBvfXcdybK7Zhu+D-- From owner-freebsd-current@FreeBSD.ORG Sun Aug 31 10:35:58 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 50DA21065683 for ; Sun, 31 Aug 2008 10:35:58 +0000 (UTC) (envelope-from shuvaev@physik.uni-wuerzburg.de) Received: from mailrelay.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by mx1.freebsd.org (Postfix) with ESMTP id CAFBC8FC14 for ; Sun, 31 Aug 2008 10:35:57 +0000 (UTC) (envelope-from shuvaev@physik.uni-wuerzburg.de) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 4EFA5198E07 for ; Sun, 31 Aug 2008 12:35:56 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 43054198E06 for ; Sun, 31 Aug 2008 12:35:56 +0200 (CEST) Received: from mail.physik.uni-wuerzburg.de (wthp192.physik.uni-wuerzburg.de [132.187.40.192]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 2E6A0198DFD for ; Sun, 31 Aug 2008 12:35:56 +0200 (CEST) Received: from wep4017.physik.uni-wuerzburg.de ([132.187.37.17]) by mail.physik.uni-wuerzburg.de (Lotus Domino Release 8.0.1HF110) with ESMTP id 2008083112355498-20524 ; Sun, 31 Aug 2008 12:35:54 +0200 Received: by wep4017.physik.uni-wuerzburg.de (sSMTP sendmail emulation); Sun, 31 Aug 2008 12:35:55 +0200 From: "Alexey Shuvaev" Date: Sun, 31 Aug 2008 12:35:55 +0200 To: freebsd-current@freebsd.org Message-ID: <20080831103555.GA12957@wep4017.physik.uni-wuerzburg.de> References: <20080829205313.GA30330@wep4017.physik.uni-wuerzburg.de> <3a142e750808291416o25b6678bm2b6fa75d0f8e4714@mail.gmail.com> MIME-Version: 1.0 In-Reply-To: <3a142e750808291416o25b6678bm2b6fa75d0f8e4714@mail.gmail.com> Organization: Universitaet Wuerzburg User-Agent: Mutt/1.5.18 (2008-05-17) X-MIMETrack: Itemize by SMTP Server on domino1/uni-wuerzburg(Release 8.0.1HF110 | April 11, 2008) at 08/31/2008 12:35:55 PM, Serialize by Router on domino1/uni-wuerzburg(Release 8.0.1HF110 | April 11, 2008) at 08/31/2008 12:35:55 PM, Serialize complete at 08/31/2008 12:35:55 PM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Subject: Re: Booting from gpt on i386/amd64? [SOLVED] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Aug 2008 10:35:58 -0000 On Fri, Aug 29, 2008 at 11:16:07PM +0200, Paul B. Mahol wrote: > On 8/29/08, Alexey Shuvaev wrote: > > Hello list! > > > > I have tried to install a system with pure gpt partitioning, > > but haven't managed to boot from it. > > > > Partition table: > > > > => 34 976773101 ad6 GPT (500.1GB) > > 34 1571840 1 freebsd-ufs (804.8MB) > > 1571874 8388608 2 freebsd-swap (4.3GB) > > 9960482 1024 3 freebsd-boot (524.3KB) > > 9961506 8388608 4 freebsd-ufs (4.3GB) > > 18350114 524288 5 freebsd-ufs (268.4MB) > > 18874402 134217728 6 freebsd-ufs (68.7GB) > > 153092130 823681005 - free - (421.7GB) > > > > All necessary files are already installed (ad6p1 = /, ad6p4 = /var, and > > so on). The system is 8.0-CURRENT from 8 August (bootable usb flash). > > Computer is Core2Duo E8400 3.0 GHz, 4 Gb RAM, ICH9, 500 GB SATA. > > What have been done: > > > > gpart bootcode -b /path/to/pmbr ad6 > > [Successful] > > > > gpart bootcode -p /path/to/gptboot -i 3 ad6 > > gpart: /dev/ad6p3: Invalid argument > > > > I have tried to 'newfs /dev/ad6p3' and then mounting it and copying > > gptboot into 'boot' directory on ad6p3, but looking at the sources it > > seems to be wrong. > > > > Then I tried to 'dd if=gptboot of=/dev/ad6p3 bs=512', ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This command writes gptboot only partially!!! I have padded gptboot to nearest sector boundary and dd-ed it to ad6p3. After that the system booted successfully. As I have expected GENERIC kernel is enough. > > but in all cases during the boot the blinking cursor moves 1 line down > > and computer freezes here. > > The remaining question is what is the correct way to put gptboot to 'freebsd-boot' partition? It seems that this functionality was in gpt(8) but is missing in gpart(8). Any work in progress? While I am here should I look at it? Alexey. From owner-freebsd-current@FreeBSD.ORG Sat Aug 30 10:34:31 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 336CA1065672; Sat, 30 Aug 2008 10:34:31 +0000 (UTC) (envelope-from fbsd-sparc64@bzerk.org) Received: from ei.bzerk.org (ei.bzerk.org [82.95.223.12]) by mx1.freebsd.org (Postfix) with ESMTP id A234C8FC2C; Sat, 30 Aug 2008 10:34:30 +0000 (UTC) (envelope-from fbsd-sparc64@bzerk.org) Received: from ei.bzerk.org (BOFH@localhost [127.0.0.1]) by ei.bzerk.org (8.14.2/8.14.2) with ESMTP id m7UAF2dh042427; Sat, 30 Aug 2008 12:15:02 +0200 (CEST) (envelope-from fbsd-sparc64@bzerk.org) Received: (from bulk@localhost) by ei.bzerk.org (8.14.2/8.14.2/Submit) id m7UAF21s042426; Sat, 30 Aug 2008 12:15:02 +0200 (CEST) (envelope-from fbsd-sparc64@bzerk.org) Date: Sat, 30 Aug 2008 12:15:01 +0200 From: Ruben de Groot To: current@freebsd.org Message-ID: <20080830101501.GA42366@ei.bzerk.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.2.1 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on ei.bzerk.org X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (ei.bzerk.org [127.0.0.1]); Sat, 30 Aug 2008 12:15:05 +0200 (CEST) X-Mailman-Approved-At: Sun, 31 Aug 2008 13:29:59 +0000 Cc: sparc64@freebsd.org Subject: DTrace on sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Aug 2008 10:34:31 -0000 Is anyone aware of any patches to implement DTrace on sparc64? While grepping through the kernel source I found it's only implemented in i386 and amd64. I do have a spare netra X1 to test on if that's any help.. greetings, Ruben From owner-freebsd-current@FreeBSD.ORG Sun Aug 31 17:40:31 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7E0561065677 for ; Sun, 31 Aug 2008 17:40:31 +0000 (UTC) (envelope-from pawel.worach@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.24]) by mx1.freebsd.org (Postfix) with ESMTP id 0B9918FC23 for ; Sun, 31 Aug 2008 17:40:30 +0000 (UTC) (envelope-from pawel.worach@gmail.com) Received: by ey-out-2122.google.com with SMTP id 6so629601eyi.7 for ; Sun, 31 Aug 2008 10:40:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=q3qfUuOfElHJN6nRDrgfFIJDymycpfbnxD8kUSa/ipk=; b=VBdZrJ0/QIFylWi8aVTC6KQru5Y9KBqfFRA6PN7zg61hy8LE+sSjzDLBMfeMh0VrFG Rj+VlXNFybn0mvKmp0+tWqnWMsb1bLsPiOV+87ezYG+uvnzVsMafSIIevzKCoQqpW2jz QLOp7rFwUGu93jqUdUZUTiPjrbwtrHVSudEW4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=lIeeldldDAKYO9BnmAMSgSS2gUlKfJlxrxgoeQVFNFsR2REKWOtfhRLmiPn075ouMk 5Y+0WYOJKQaPu7QYn/tq4OQ9+3RfVJO1miDW/n/ZTQVouY4UAce1dfHquhYV1LgHYLRr 5Sek6xLe78aDafJgmeWd7HZqNZ7Qs3cabdvWM= Received: by 10.210.20.17 with SMTP id 17mr5109401ebt.170.1220202629844; Sun, 31 Aug 2008 10:10:29 -0700 (PDT) Received: from ?192.168.1.102? ( [213.89.241.138]) by mx.google.com with ESMTPS id 7sm6245550eyg.0.2008.08.31.10.10.27 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 31 Aug 2008 10:10:28 -0700 (PDT) Message-ID: <48BAD085.1090507@gmail.com> Date: Sun, 31 Aug 2008 19:10:29 +0200 From: Pawel Worach User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b1pre) Gecko/20080830031141 Shredder/3.0b1pre MIME-Version: 1.0 To: current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: csh history and pts X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Aug 2008 17:40:31 -0000 Hi, Since the MPSAFETTY landing and pts being the default csh seems to loose the contents of ~/.history when "shutdown -r now" is issued, I'm not sure about the timeframe but I have not noticed this before and I use history quite a bit. Steps to reproduce (tested with root): 1) Login on console (ttyv0) 2) Issued a couple of commands 3) Logout 4) Login 5) 'history' and your previous session shows up, all good. 6) 'shutdown -r now' 7) After boot, login, 'history' and it's blank. At step #6 a reboot(8) does not cause this, only shutdown(8), or at least so it seems. Does shutdown(8) send a evil signal to csh so it looses the history? Relevant parts of .cshrc: set history = 2000 set savehist = (2000 merge) Regrads Pawel From owner-freebsd-current@FreeBSD.ORG Sun Aug 31 20:09:52 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 633391065670 for ; Sun, 31 Aug 2008 20:09:52 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:610:652::211]) by mx1.freebsd.org (Postfix) with ESMTP id 238068FC26 for ; Sun, 31 Aug 2008 20:09:51 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 42BD71CC73; Sun, 31 Aug 2008 22:09:50 +0200 (CEST) Date: Sun, 31 Aug 2008 22:09:50 +0200 From: Ed Schouten To: Pawel Worach Message-ID: <20080831200950.GF99951@hoeg.nl> References: <48BAD085.1090507@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="S/fPHpVs8+EC64rw" Content-Disposition: inline In-Reply-To: <48BAD085.1090507@gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: current@freebsd.org Subject: Re: csh history and pts X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Aug 2008 20:09:52 -0000 --S/fPHpVs8+EC64rw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Pawel, * Pawel Worach wrote: > Hi, > > Since the MPSAFETTY landing and pts being the default csh seems to loose = =20 > the contents of ~/.history when "shutdown -r now" is issued, I'm not =20 > sure about the timeframe but I have not noticed this before and I use =20 > history quite a bit. > > Steps to reproduce (tested with root): > 1) Login on console (ttyv0) > 2) Issued a couple of commands > 3) Logout > 4) Login > 5) 'history' and your previous session shows up, all good. > 6) 'shutdown -r now' > 7) After boot, login, 'history' and it's blank. > > At step #6 a reboot(8) does not cause this, only shutdown(8), or at =20 > least so it seems. Does shutdown(8) send a evil signal to csh so it =20 > looses the history? > > Relevant parts of .cshrc: > set history =3D 2000 > set savehist =3D (2000 merge) Can you tell me how pts is related to this? Looking at your steps, I can't see how pts is involved with this, because you happen to use syscons(4) here. Some people on IRC told me that (t)csh had some problems with "pty detection" with MPSAFE TTY, but grepping through the source and asking various people around the globe, I still have no idea what "pty detection" is and why (t)csh has the urge to "detect pty's". Maybe a (t)csh guru can help me out? --=20 Ed Schouten WWW: http://80386.nl/ --S/fPHpVs8+EC64rw Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAki6+o4ACgkQ52SDGA2eCwWMJQCfefvBvA4GX+5uS1UDEsRKFxmY NEgAmwRcqtT8VBM8xyJ37IvYUc/s7aMK =Xrl2 -----END PGP SIGNATURE----- --S/fPHpVs8+EC64rw-- From owner-freebsd-current@FreeBSD.ORG Sun Aug 31 20:18:24 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5F9BD106566B for ; Sun, 31 Aug 2008 20:18:24 +0000 (UTC) (envelope-from alexanderchuranov@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by mx1.freebsd.org (Postfix) with ESMTP id DB7118FC0A for ; Sun, 31 Aug 2008 20:18:23 +0000 (UTC) (envelope-from alexanderchuranov@gmail.com) Received: by ey-out-2122.google.com with SMTP id 6so643975eyi.7 for ; Sun, 31 Aug 2008 13:18:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=t+Z1C/BGHsS89nrhH0BKjZ5Rmn8bX91JyBxtp/IHfYo=; b=vcSVKAKvwAxfnn2Nwi9+guFgccLtO7x4DsbeJFDuxt4pgU+dTpvJH97nnsAthCxjKd ESsjamyzHYrXrzg0O8IGFCdd321jefGScvweJzYpkWPJZapo1AD38igvp+z60JIZoLLm BLRsAYyqrfw025e1/7ZPvf5RqLRryXVZgRge4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=hHLQqSF3SgLmBsn9zMQX/SpPlr/qZDEG3f00RTT5wTxV2lQusJX11Z9H1URqSmHHer FnDDW1kveX+UUr4CsapGIqzSabQpnik7Ib1ul5f0OeB9EW1/l5T2lIwu29HT9cq/EiMg pOwQ+8JnYBpsKEAJLeoNrPUlGVWbKVOJYZwKs= Received: by 10.210.67.20 with SMTP id p20mr5364780eba.66.1220213902775; Sun, 31 Aug 2008 13:18:22 -0700 (PDT) Received: by 10.210.130.15 with HTTP; Sun, 31 Aug 2008 13:18:22 -0700 (PDT) Message-ID: <3cb459ed0808311318s498884f4tf02b582406833fb5@mail.gmail.com> Date: Mon, 1 Sep 2008 00:18:22 +0400 From: "Alexander Churanov" To: "Konrad Jankowski" In-Reply-To: <716a8d5f0808291804r1f66ce2ek176c2fac28a94c92@mail.gmail.com> MIME-Version: 1.0 References: <3cb459ed0808250952j572dfc35j2feb852a73de5ace@mail.gmail.com> <200808281718.m7SHISGL067492@lurza.secnetix.de> <3cb459ed0808290636r5eb389c8y6d4aafae1b8001cf@mail.gmail.com> <3cb459ed0808291708l581422c1pdb2e3cb2913ecaa7@mail.gmail.com> <716a8d5f0808291804r1f66ce2ek176c2fac28a94c92@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org, olli@lurza.secnetix.de, Tz-Huan Huang , Peter Wemm Subject: Re: Unicode-based FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Aug 2008 20:18:24 -0000 2008/8/30 Konrad Jankowski > I support the initial idea - i'd like to 'cat' UTF8 encoded Polish > files in the console. And this can easily accommodate most European > languages. But there will need to be a secondary switching mechanism > for selecting which part of the Unicode is being mapped at the time. There is a "scrnmap". The difference is it maps from 8-bit to 8-bit now, and I want it to map from UTF-8 to 8-bit. > We also get a bonus - for people that use languages like Polish, they > can stay in text mode and not loose speed, which is Inherent with > VESA. > Yes, people will be able to read and write Polish in syscons. At the other hand, reading Polish and Russian at the same type will not be possible. However, users are already able to do it right now. The improvement is that people will use a single encoding for configuration files, manual pages and other things - UTF-8. Alexander Churanov From owner-freebsd-current@FreeBSD.ORG Sun Aug 31 20:20:27 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EBD791065671 for ; Sun, 31 Aug 2008 20:20:27 +0000 (UTC) (envelope-from alexanderchuranov@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by mx1.freebsd.org (Postfix) with ESMTP id 71F258FC18 for ; Sun, 31 Aug 2008 20:20:27 +0000 (UTC) (envelope-from alexanderchuranov@gmail.com) Received: by ey-out-2122.google.com with SMTP id 6so644172eyi.7 for ; Sun, 31 Aug 2008 13:20:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=qXF8/e3J6HCPA43oFbu4uMsd+Hh+cVFWaidzf8MBtw8=; b=RalTNUDqI+hGOVx8Bn+KUxBmFVX1Vb7BVVHLxbMxXhAnrcchs3jWohB/b4F8K+fJNZ 1XXV+j7CD944LMiGi9jh63NBraxygC3ZiYZn6sxr8x1+Mig1TXB3PNuF9DucgKOXRG1F XDXUOt/cugzp0XzONejfPSYWyJQna7nNc1x/0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=Oy0ijPgj3ir6RSSpOLuSyd7A702/gNs09492z42wANPcxTH7ORYKXahz92mnNwpY08 CMAyXb/TuBZh0RnUF62ekcNH2w8hDPzR/qu44J5i6E7olm6fgdicvqf3dXTcNExlKvFX JTqEgaf0hoW+6dAlnjPd/2Uh/JlEfyA03nAFU= Received: by 10.210.67.4 with SMTP id p4mr5349681eba.118.1220214026446; Sun, 31 Aug 2008 13:20:26 -0700 (PDT) Received: by 10.210.130.15 with HTTP; Sun, 31 Aug 2008 13:20:26 -0700 (PDT) Message-ID: <3cb459ed0808311320y5269bc12l8d22c011ae5e839e@mail.gmail.com> Date: Mon, 1 Sep 2008 00:20:26 +0400 From: "Alexander Churanov" To: "Konrad Jankowski" In-Reply-To: <3cb459ed0808311318s498884f4tf02b582406833fb5@mail.gmail.com> MIME-Version: 1.0 References: <3cb459ed0808250952j572dfc35j2feb852a73de5ace@mail.gmail.com> <200808281718.m7SHISGL067492@lurza.secnetix.de> <3cb459ed0808290636r5eb389c8y6d4aafae1b8001cf@mail.gmail.com> <3cb459ed0808291708l581422c1pdb2e3cb2913ecaa7@mail.gmail.com> <716a8d5f0808291804r1f66ce2ek176c2fac28a94c92@mail.gmail.com> <3cb459ed0808311318s498884f4tf02b582406833fb5@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org, olli@lurza.secnetix.de, Tz-Huan Huang , Peter Wemm Subject: Re: Unicode-based FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Aug 2008 20:20:28 -0000 2008/9/1 Alexander Churanov > Yes, people will be able to read and write Polish in syscons. At the other > hand, reading Polish and Russian at the same type will not be possible. > However, users are already able to do it right now. The improvement is that > people will use a single encoding for configuration files, manual pages and > other things - UTF-8. > Should read as "at the same time". Sorry. From owner-freebsd-current@FreeBSD.ORG Sun Aug 31 20:25:04 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 802CF1065678 for ; Sun, 31 Aug 2008 20:25:04 +0000 (UTC) (envelope-from alexanderchuranov@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.24]) by mx1.freebsd.org (Postfix) with ESMTP id 0678E8FC13 for ; Sun, 31 Aug 2008 20:25:03 +0000 (UTC) (envelope-from alexanderchuranov@gmail.com) Received: by ey-out-2122.google.com with SMTP id 6so644556eyi.7 for ; Sun, 31 Aug 2008 13:25:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=ocqPmga//m8UZpsI6ATF4sqfS0eArJmuGaYMhN9qg6A=; b=rz8OKZlrLevX18zWGtqWh5Fgt7U01ojvRwmgNBy7oLXLHnHRa27kUIzM2jVG2M9iAj 8pppNbvrKyX2cJyK3erVPT0uvVJGo1N/GtGkBAdB6Uv9Z79GWdogTKZv2j9busK6f1Lz /OVy7IekJ8qU+WiAaSSyclr12kSVikaPZTJ2A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=riYd9kI6LEIJPWpQO/l1Rq0pbcI5qsumj3ckJxA/W2uHzb3GsBTi6jtcDwNdAAd7eU afZY/tP7I+euz+yv+clm9+VBX28cv0FuGEmXiICJhL8o/cZl6Ippv+GbriytuKZtnVlT dQ1EHM4JLY7FwKp6K/2XX5hzDuJbgWhZ0/fOA= Received: by 10.210.19.4 with SMTP id 4mr5346679ebs.134.1220214302625; Sun, 31 Aug 2008 13:25:02 -0700 (PDT) Received: by 10.210.130.15 with HTTP; Sun, 31 Aug 2008 13:25:02 -0700 (PDT) Message-ID: <3cb459ed0808311325i1c09a85at22faa7c71d83104@mail.gmail.com> Date: Mon, 1 Sep 2008 00:25:02 +0400 From: "Alexander Churanov" To: "Tz-Huan Huang" In-Reply-To: <6a7033710808300142o1b253c6cw2e286d42a60e342b@mail.gmail.com> MIME-Version: 1.0 References: <3cb459ed0808250952j572dfc35j2feb852a73de5ace@mail.gmail.com> <200808281718.m7SHISGL067492@lurza.secnetix.de> <3cb459ed0808290636r5eb389c8y6d4aafae1b8001cf@mail.gmail.com> <6a7033710808300142o1b253c6cw2e286d42a60e342b@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org, olli@lurza.secnetix.de Subject: Re: Unicode-based FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Aug 2008 20:25:04 -0000 2008/8/30 Tz-Huan Huang > As far as I known Linux's console really support Chinese by change the > display to graphics mode through framebuffer[1]. It should be no video > card compatibility issue if the video card supports VESA well (most cards > support it well I think). How much Chinese glyphs it can render depends on > the coverage of the bitmap fonts, so it should be possible to render all > glyphs if the fonts are available. > > However, I have never used this feature in Linux. All linux systems I > manage > have either X (desktop) or just text-mode console (server) like FreeBSD. > So I don't think this feature is very useful for me. The debian installer > use > this feature to support Chinese and other language interfaces, it might be > useful for a newbie to install an unfamiliar OS. Besides that, there are > less > benefits to support this I think. > > IMHO your schedules looks fine to me. :-) > > Tz-Huan > > [1] http://en.wikipedia.org/wiki/Linux_framebuffer > Thank you. Alexander Churanov From owner-freebsd-current@FreeBSD.ORG Sun Aug 31 20:38:29 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6A8991065776 for ; Sun, 31 Aug 2008 20:38:29 +0000 (UTC) (envelope-from alexanderchuranov@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by mx1.freebsd.org (Postfix) with ESMTP id E44298FC21 for ; Sun, 31 Aug 2008 20:38:28 +0000 (UTC) (envelope-from alexanderchuranov@gmail.com) Received: by ey-out-2122.google.com with SMTP id 6so645821eyi.7 for ; Sun, 31 Aug 2008 13:38:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type:references; bh=0+S+aQodgWOPMthYbQYuZQ01tR9LIGpN6zj+yzPDVto=; b=lC4G3Lz58ZfIRDu9zlrnpIP9oawRnN/pz3ETW9EbIULfFjVgjA+zcixNS90ihI01cR S7nVfJi+lQikghW4+8vDtBM2Sh51pINvwx6fhSLo9MDx2+ZfqI6F/MfMHrPhSrYhxUZf 5QviFa2iJM4dg0z6iY6rKSFb0wkGUc01flMb4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:references; b=OCf6DGUcpCfXTeoCU53NHANTxBlFpe9zVu7WkKn/mkx7tzet1hsdy4n1a3+/p2a1P4 QBOqqwCrz82KV2OxJdMNGKcauYJjCUA05xpZr0ww/lHDs+krYyBDjlXIB6yIa+W6/a2m 7LGDO6Hk3BRndRbIoLLDeq44jbanIPJF4cje8= Received: by 10.210.59.3 with SMTP id h3mr5372077eba.145.1220215107763; Sun, 31 Aug 2008 13:38:27 -0700 (PDT) Received: by 10.210.130.15 with HTTP; Sun, 31 Aug 2008 13:38:27 -0700 (PDT) Message-ID: <3cb459ed0808311338h6ff615eas3491b75c9d8251ea@mail.gmail.com> Date: Mon, 1 Sep 2008 00:38:27 +0400 From: "Alexander Churanov" To: "Marcus von Appen" , freebsd-current@freebsd.org In-Reply-To: <20080830083901.GA2183@medusa.sysfault.org> MIME-Version: 1.0 References: <3cb459ed0808250952j572dfc35j2feb852a73de5ace@mail.gmail.com> <200808281718.m7SHISGL067492@lurza.secnetix.de> <3cb459ed0808290636r5eb389c8y6d4aafae1b8001cf@mail.gmail.com> <3cb459ed0808291708l581422c1pdb2e3cb2913ecaa7@mail.gmail.com> <20080830083901.GA2183@medusa.sysfault.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: Unicode-based FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Aug 2008 20:38:29 -0000 2008/8/30 Marcus von Appen > I wonder, how backspacing will be implemented for complex scripts such > as the Indic one or Arabic, where two codepoints will be resolved to one > logical (and usually visible) character. This definitely will not be implemented. At least, in current iteration. :-) Syscons will count code points. > In either of those case the backspacing might appear broken to the user. Yes. The improvement will not solve all internationalization issues at once. Just some of them. > What frightens me away is the implementation cost for the fonts. I'm planning only software engineering work for this project. Probably, someone else will have to prepeare fonts, event if that is a costly task. > Rendering complex RTL scripts (Arabic, Hebrew) is another issue. In > case RTL layout is left aside, they still will need proper bidi > support, otherwise they are useless in my opinion. Complex and non-LTR scripts will not be rendered properly. Or, more exactly, not better than now. I'm considering rendering as another issue. So, only code points for the first step. Alexander Churanov From owner-freebsd-current@FreeBSD.ORG Sun Aug 31 20:42:55 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BD1A110656BF for ; Sun, 31 Aug 2008 20:42:55 +0000 (UTC) (envelope-from alexanderchuranov@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by mx1.freebsd.org (Postfix) with ESMTP id 468318FC15 for ; Sun, 31 Aug 2008 20:42:55 +0000 (UTC) (envelope-from alexanderchuranov@gmail.com) Received: by ey-out-2122.google.com with SMTP id 6so646199eyi.7 for ; Sun, 31 Aug 2008 13:42:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=S5EZk15/ycq11yO4G8/Qkfo/nyB+SEe4FQg+aihMRJo=; b=Gw1LlL5Q/+1OmkSi8dRtToXDBzrk0lmDrQWTqHPeyjB5DHC4qusgzQJCzQQpU49lF2 5XPn1FBFpXKPkq8j0QnF3wZ1ZJN9P2lO+X6ZCDhsItTjEE+9yWsqCIxvdQv0aFRmUqKG 8I9CvP+IU2OAl3ybm5KZlOyjrjGJcnO08yXww= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=BLFwOZGqx9MU/ZcQlOpptJdJJiWpKzhukcofi3SBLSnLZyTMuRdg0wMRv3IeL+PaGp LqHZ/GlqQHy24kC9XLCGjHScVuJSG/Vq0aRrMH45iT/iSDoguWFpmz39LLEbZBFlCMpB JTtREF7uqPFbFVmcQ3VlCYKkd6dwnWgNKsA5M= Received: by 10.210.51.18 with SMTP id y18mr5353089eby.160.1220215374107; Sun, 31 Aug 2008 13:42:54 -0700 (PDT) Received: by 10.210.130.15 with HTTP; Sun, 31 Aug 2008 13:42:54 -0700 (PDT) Message-ID: <3cb459ed0808311342x2f96e5a6oc04f97cf1362823b@mail.gmail.com> Date: Mon, 1 Sep 2008 00:42:54 +0400 From: "Alexander Churanov" To: "Peter Jeremy" In-Reply-To: <20080830115559.GM86609@server.vk2pj.dyndns.org> MIME-Version: 1.0 References: <3cb459ed0808250952j572dfc35j2feb852a73de5ace@mail.gmail.com> <200808281718.m7SHISGL067492@lurza.secnetix.de> <3cb459ed0808290636r5eb389c8y6d4aafae1b8001cf@mail.gmail.com> <3cb459ed0808291708l581422c1pdb2e3cb2913ecaa7@mail.gmail.com> <20080830083901.GA2183@medusa.sysfault.org> <20080830115559.GM86609@server.vk2pj.dyndns.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: Unicode-based FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Aug 2008 20:42:55 -0000 2008/8/30 Peter Jeremy > IMHO, unless we want to embed the equivalent of pango in the kernel, > the only realistic solution is to count unicode codepoints. That's exactly what I want to implement. > It would be useful to know how other implementations work because I > can't see how to avoid some degree of broken-ness without a complete > CTF implementation. If we aim syscons at sysadmins then a degree of > misbehaviour may be acceptable. You are reading my thoughts! > The fonts are available in ports. I'm not sure if there are existing > bit-mapped fonts but a TTF or similar font can be converted to a > bitmap without major effort. Antialiasing would help with legibility. > Also agree. Alexander Churanov From owner-freebsd-current@FreeBSD.ORG Sun Aug 31 20:49:13 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 98F071065673 for ; Sun, 31 Aug 2008 20:49:13 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id 1348E8FC1A for ; Sun, 31 Aug 2008 20:49:12 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from kobe.laptop (adsl10-93.kln.forthnet.gr [77.49.137.93]) (authenticated bits=128) by igloo.linux.gr (8.14.3/8.14.3/Debian-5) with ESMTP id m7VKmij8030678 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 31 Aug 2008 23:48:50 +0300 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.3/8.14.3) with ESMTP id m7VKmh4x003253; Sun, 31 Aug 2008 23:48:43 +0300 (EEST) (envelope-from keramida@freebsd.org) Received: (from keramida@localhost) by kobe.laptop (8.14.3/8.14.3/Submit) id m7VKmgGg003252; Sun, 31 Aug 2008 23:48:42 +0300 (EEST) (envelope-from keramida@freebsd.org) From: Giorgos Keramidas To: Ed Schouten References: <48BAD085.1090507@gmail.com> <20080831200950.GF99951@hoeg.nl> Date: Sun, 31 Aug 2008 23:48:35 +0300 In-Reply-To: <20080831200950.GF99951@hoeg.nl> (Ed Schouten's message of "Sun, 31 Aug 2008 22:09:50 +0200") Message-ID: <871w04syfw.fsf@kobe.laptop> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (berkeley-unix) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" X-MailScanner-ID: m7VKmij8030678 X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-4.288, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.11, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@freebsd.org X-Spam-Status: No Cc: current@freebsd.org Subject: Re: csh history and pts X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Aug 2008 20:49:13 -0000 --=-=-= On Sun, 31 Aug 2008 22:09:50 +0200, Ed Schouten wrote: > Some people on IRC told me that (t)csh had some problems with "pty > detection" with MPSAFE TTY, but grepping through the source and asking > various people around the globe, I still have no idea what "pty > detection" is and why (t)csh has the urge to "detect pty's". > > Maybe a (t)csh guru can help me out? Yes, a bit of background is probably going to be useful... tcsh enables autologout automatically to a default of 60 seconds in the following cases: Set to `60' (automatic logout after 60 minutes, and no locking) by default in login and superuser shells, but not if the shell thinks it is running under a window system (i.e., the DISPLAY environment variable is set), the tty is a pseudo-tty (pty) or the shell was not so compiled (see the version shell variable). The `contrib/tcsh/sh.c' code implements this near line 456: 456 if (loginsh || (uid == 0)) { 457 if (*cp) { 458 /* only for login shells or root and we must have a tty */ 459 if ((cp2 = Strrchr(cp, (Char) '/')) != NULL) { 460 cp2 = cp2 + 1; 461 } 462 else 463 cp2 = cp; 464 if (!(((Strncmp(cp2, STRtty, 3) == 0) && Isalpha(cp2[3])) || 465 Strstr(cp, STRslptssl) != NULL)) { 466 if (getenv("DISPLAY") == NULL) { 467 /* NOT on X window shells */ 468 setcopy(STRautologout, STRdefautologout, VAR_READWRITE); 469 } 470 } 471 } 472 } The STRslptssl[] char array contains { '/', 'p', 't', 's', '/', '\0' }, in wide char format, and this is where the check for /dev/pts/xxx is done. By skimming through the code I haven't been able to see anything odd, after the fix we installed in subversion change r172665: ------------------------------------------------------------------------ r172665 | mp | 2007-10-15 18:23:07 +0300 (Mon, 15 Oct 2007) | 6 lines Import two vendor fixes from tcsh-6.15.01 for MFC to 7.0. The fixes are: - Fix pty detection for autologout setting - kill `foo` got stuck because sigchld was disabled too soon Requested by: re ------------------------------------------------------------------------ I have an IRC log from scottl noting that he still got the default 60 second autologout, but this was on 6.X IIRC: * scottl__ tries to remember how to turn off auto-logout scottl__: tcsh option - I guess tcsh can no longer determin activity post TTY? scottl__: I remember Kris mentioning an mpsafetty & tcsh issue. I haven't had the time to go back and check if the pty-detection we fixed with kern.pts.enable=1 still works after mpsafetty scottl__: what does echo $autologout say? [y1] ~> echo $autologout 60 on a 6.3 machine, I get pooker] ~> echo $autologout autologout: Undefined variable. I can't reproduce this with a current from Aug 29, but this snapshot has been built with the experimental 'packet mode' patch, and a few other local changes, so I will have to try with a clean /head/ snapshot. HTH, Giorgos --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAki7A6kACgkQ1g+UGjGGA7bnJACdFompVLnYMH7YCjm/TyzS+QZ6 bR4AoLv8of5HMtlHdJ50MWE3G+Eqt3FJ =RrQW -----END PGP SIGNATURE----- --=-=-=-- From owner-freebsd-current@FreeBSD.ORG Mon Sep 1 01:32:04 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D4BB3106564A; Mon, 1 Sep 2008 01:32:04 +0000 (UTC) (envelope-from Tor.Egge@cvsup.no.freebsd.org) Received: from pil.idi.ntnu.no (pil.idi.ntnu.no [129.241.107.93]) by mx1.freebsd.org (Postfix) with ESMTP id 557178FC13; Mon, 1 Sep 2008 01:32:04 +0000 (UTC) (envelope-from Tor.Egge@cvsup.no.freebsd.org) Received: from cvsup.no.freebsd.org (c2h5oh.idi.ntnu.no [129.241.103.69]) by pil.idi.ntnu.no (8.14.1/8.13.1) with ESMTP id m811VUoH027877 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 1 Sep 2008 03:31:30 +0200 (MEST) Received: from localhost (localhost [127.0.0.1]) by cvsup.no.freebsd.org (8.14.2/8.14.2) with ESMTP id m811VT18058877; Mon, 1 Sep 2008 01:31:29 GMT (envelope-from Tor.Egge@cvsup.no.freebsd.org) Date: Mon, 01 Sep 2008 01:31:17 +0000 (UTC) Message-Id: <20080901.013117.74700691.Tor.Egge@cvsup.no.freebsd.org> To: Benjamin.Close@clearchain.com From: Tor Egge In-Reply-To: <48B6BC81.5060300@clearchain.com> References: <200808230003.44081.jhb@freebsd.org> <3bbf2fe10808230233u195f3530wf4e3b6e007b638d9@mail.gmail.com> <48B6BC81.5060300@clearchain.com> X-Mailer: Mew version 5.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-Virus-Scanned-By: mimedefang.idi.ntnu.no, using CLAMD X-SMTP-From: Sender=, Relay/Client=c2h5oh.idi.ntnu.no [129.241.103.69], EHLO=cvsup.no.freebsd.org X-Scanned-By: MIMEDefang 2.48 on 129.241.107.38 X-Scanned-By: mimedefang.idi.ntnu.no, using MIMEDefang 2.48 with local filter 16.42-idi X-Filter-Time: 1 seconds Cc: attilio@freebsd.org, kevinxlinuz@163.com, freebsd-current@freebsd.org, kib@freebsd.org Subject: Re: [BUG] I think sleepqueue need to be protected in sleepq_broadcast X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Sep 2008 01:32:04 -0000 sleepq_resume_thread() contains an ownership handover of sq if the resumed thread is the last one blocked on the wait channel. After the handover, sq is no longer protected by the sleep queue chain lock and should no longer be accessed by sleepq_broadcast(). Normally, when sleepq_broadcast() incorrectly accesses sq after the handover, it will find the sq->sq_blocked queue to be empty, and the code appears to work. If the last correctly woken thread manages to go to sleep again very quickly on another wait channel, sleepq_broadcast() might incorrectly determine that the sq->sq_blocked queue isn't empty, and start doing the wrong thing. A similar (but probably much more difficult to trigger) issue is present with regards to thread_lock() and turnstiles. The caller of thread_lock() might have performed sufficient locking to ensure that the thread to be locked doesn't go away, but any turnstile spin lock pointed to by td->td_lock isn't protected. Making turnstiles type stable (setting UMA_ZONE_NOFREE flag for turnstile_zone) should fix that issue. - Tor Egge From owner-freebsd-current@FreeBSD.ORG Mon Sep 1 03:26:29 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 576BB106566B for ; Mon, 1 Sep 2008 03:26:29 +0000 (UTC) (envelope-from y2s1982@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.229]) by mx1.freebsd.org (Postfix) with ESMTP id 2AD798FC1D for ; Mon, 1 Sep 2008 03:26:29 +0000 (UTC) (envelope-from y2s1982@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so2351390rvf.43 for ; Sun, 31 Aug 2008 20:26:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type; bh=nCZzxRqvYKrB9ZcFIgjI4ZVfGDhVCmor6Ec+NFPy6Ws=; b=EIHKSp3hNpR3IFTslwdRVrcwzTTBYRGje6Yoi3TGwyduYPNdNO0Qyj3upuHxLGA4WP ZGRE7M+hZrNfl4DY2r91Dt0Cy7nYzWiqe9SuvVyE7U1opjJWLP3NaVAolh0VIFllw0sL FcvrQ8RmBbrXQ6RxsXgEsCUXrrpDzLlSsg2Sw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=JfodWmRlZ28GXsfPzD3EIIgEnbReHiSC6QQFqH6lpn8sUwrQWmWX76LeHAG3+Ue0tc AtVRlvF8XEzNhLpgSmo/voIGKvz8h2XW7YMtENf44qG4m8U8bDIEnIbwM+MX626IUbyZ AIOUDzTS+24pMObwZRyOd4LBXdBKM0BSUSbY4= Received: by 10.141.115.6 with SMTP id s6mr3098178rvm.239.1220238076789; Sun, 31 Aug 2008 20:01:16 -0700 (PDT) Received: by 10.140.148.4 with HTTP; Sun, 31 Aug 2008 20:01:16 -0700 (PDT) Message-ID: <5fb5cdcd0808312001k419cd735r55c37a15f5f76ab5@mail.gmail.com> Date: Mon, 1 Sep 2008 12:01:16 +0900 From: "Tony Sim" To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Questions on how to use the Head files Pyun YongHyeon has created for re driver X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Sep 2008 03:26:29 -0000 Hi. I've recently purchased a laptop that, by the looks of windows drivers that came with it, was made by Realtek. I THINK it might be 8168c, but regardless, freebsd 7-rel failed to detect it. I've tried to use ndisgen to get a .ko module, but it only half-worked; now freebsd detects the card as a realtek 8168/8111 and can be found on ifconfig, but it's status is not UP nor DOWN. When I tried to change the status to UP, the entire system crashed. I've also tried downloading the driver from realtek homepage, but it won't compile (and does not have a folder with .ko file, as the Readme.txt claims) A google search got me to an archived post: http://unix.derkeiler.com/Mailing-Lists/FreeBSD/current/2008-06/msg00186.html and from the looks of it, he has created more patches since the posting: http://people.freebsd.org/~yongari/re/ except me being a newbie, I can't figure out what to do with this file. The responses from the testers were quite favorable, so I'm very excited about the find. Can someone help me figure out what i'm supposed to do here? I'm guessing these are patches, but patches to which files? and how do i apply these? thank you very much for reading so far. From owner-freebsd-current@FreeBSD.ORG Mon Sep 1 04:19:50 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 72646106567A for ; Mon, 1 Sep 2008 04:19:50 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.224]) by mx1.freebsd.org (Postfix) with ESMTP id 3D3DB8FC1A for ; Mon, 1 Sep 2008 04:19:50 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so2366384rvf.43 for ; Sun, 31 Aug 2008 21:19:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from :to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=DZLrCo0GCO82vaOq598IEBqxoIJVQA2PAL4RWs5NpCg=; b=jES2/rdzdJC6AjHRpIwHRbSM48HPCsPo3FBFHSqCBYmxHOwye0UNpQiasce1SGx37o P6a0LVKNsNhkkwCITJ8xeFbGcltyWoVSEWBvUaPoo8QmNlcpT0EYmzcT0ZNnF7Ej3ddK SXptWng0hdURv6ntd7cbHNJ2KyJaQ44OBA288= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=YqSfRiDx/DBB6DkFkT7/tXqs7VMTwAZryAtBuVNUiYRlpmxfHfWvM7DYMmqemYfmSH 5QHzkiQOwH7t+Rp/XWGyG0JtXo0hhYe0MO1T1yEIqse8+IA5ukOL3L1DXQbc8P7bY9zv ZfiobEpDWPPPCNHB43QuBdKcaMqfAYBcripFg= Received: by 10.141.29.8 with SMTP id g8mr3170052rvj.62.1220242789957; Sun, 31 Aug 2008 21:19:49 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTPS id g31sm9492600rvb.7.2008.08.31.21.19.47 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 31 Aug 2008 21:19:48 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id m814JiaQ048639 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Sep 2008 13:19:44 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id m814JiBF048638; Mon, 1 Sep 2008 13:19:44 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Mon, 1 Sep 2008 13:19:44 +0900 From: Pyun YongHyeon To: Tony Sim Message-ID: <20080901041944.GB48568@cdnetworks.co.kr> References: <5fb5cdcd0808312001k419cd735r55c37a15f5f76ab5@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5fb5cdcd0808312001k419cd735r55c37a15f5f76ab5@mail.gmail.com> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org Subject: Re: Questions on how to use the Head files Pyun YongHyeon has created for re driver X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Sep 2008 04:19:50 -0000 On Mon, Sep 01, 2008 at 12:01:16PM +0900, Tony Sim wrote: > Hi. I've recently purchased a laptop that, by the looks of windows drivers > that came with it, was made by Realtek. I THINK it might be 8168c, but > regardless, freebsd 7-rel failed to detect it. > Have you tried to run it on latest 7-stable or CURRENT? I guess re(4) on 7-stable may recognize your controller. If not please let me know. > I've tried to use ndisgen to get a .ko module, but it only > half-worked; now freebsd detects the card as a realtek 8168/8111 and can be > found on ifconfig, but it's status is not UP nor DOWN. When I tried to > change the status to UP, the entire system crashed. > > I've also tried downloading the driver from realtek homepage, but it won't > compile (and does not have a folder with .ko file, as the Readme.txt claims) > > A google search got me to an archived post: > http://unix.derkeiler.com/Mailing-Lists/FreeBSD/current/2008-06/msg00186.html > > and from the looks of it, he has created more patches since the posting: > http://people.freebsd.org/~yongari/re/ > Now re(4) has all the changes in the directory above so you don't need to manually patch them if you run 7-stable/CURRENT. > except me being a newbie, I can't figure out what to do with this file. The > responses from the testers were quite favorable, so I'm very excited about > the find. Can someone help me figure out what i'm supposed to do here? I'm > guessing these are patches, but patches to which files? and how do i apply > these? > > thank you very much for reading so far. -- Regards, Pyun YongHyeon From owner-freebsd-current@FreeBSD.ORG Mon Sep 1 05:41:16 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9CFF01065677 for ; Mon, 1 Sep 2008 05:41:16 +0000 (UTC) (envelope-from aryeh.friedman@gmail.com) Received: from mta3.srv.hcvlny.cv.net (mta3.srv.hcvlny.cv.net [167.206.4.198]) by mx1.freebsd.org (Postfix) with ESMTP id 756B48FC1A for ; Mon, 1 Sep 2008 05:41:16 +0000 (UTC) (envelope-from aryeh.friedman@gmail.com) Received: from flosoft.no-ip.biz (ool-435559b8.dyn.optonline.net [67.85.89.184]) by mta3.srv.hcvlny.cv.net (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTP id <0K6I00B2G3QRGAE0@mta3.srv.hcvlny.cv.net> for freebsd-current@freebsd.org; Mon, 01 Sep 2008 01:11:16 -0400 (EDT) Received: from flosoft.no-ip.biz (localhost [127.0.0.1]) by flosoft.no-ip.biz (8.14.3/8.14.3) with ESMTP id m8119b4Z085331; Sun, 31 Aug 2008 21:09:38 -0400 Date: Sun, 31 Aug 2008 21:09:37 -0400 From: "Aryeh M. Friedman" In-reply-to: <5fb5cdcd0808312001k419cd735r55c37a15f5f76ab5@mail.gmail.com> To: Tony Sim Message-id: <48BB40D1.4030104@gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT References: <5fb5cdcd0808312001k419cd735r55c37a15f5f76ab5@mail.gmail.com> User-Agent: Thunderbird 2.0.0.16 (X11/20080824) Cc: freebsd-current@freebsd.org Subject: Re: Questions on how to use the Head files Pyun YongHyeon has created for re driver X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Sep 2008 05:41:16 -0000 Just to answer the basic question of how to apply a patch take a quick glance at the patch to determine: 1. Does it make sense to install it 2. Determine from what dir you need to install it from (the filenames will give a good clue) Then to apply it cd to that dir and do: patch -p < [file] where [file] is the filename of the patch (don't forget to reference its patch if needed also) If the patch is for something in /usr/src or /usr/src/sys use the normal methods of rebuilding world or the kernel. Disclaimer: c(v)sup will ignore the fact you patched a file and will overwrite it. You have two options at this point: 1. Repatch after csup is done [often hard to tell if you need to] 2. Use some variant of the method in development(8) to create your own local cvs repo of the source tree then update the actual /usr/src with cvs not c(v)sup because it understands how to preserve your changes while adding new content to the file From owner-freebsd-current@FreeBSD.ORG Mon Sep 1 06:15:42 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F1FDF1065670 for ; Mon, 1 Sep 2008 06:15:42 +0000 (UTC) (envelope-from aryeh.friedman@gmail.com) Received: from mta1.srv.hcvlny.cv.net (mta1.srv.hcvlny.cv.net [167.206.4.196]) by mx1.freebsd.org (Postfix) with ESMTP id CCD8F8FC3F for ; Mon, 1 Sep 2008 06:15:42 +0000 (UTC) (envelope-from aryeh.friedman@gmail.com) Received: from flosoft.no-ip.biz (ool-435559b8.dyn.optonline.net [67.85.89.184]) by mta1.srv.hcvlny.cv.net (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTP id <0K6I0025V6Q5QLN0@mta1.srv.hcvlny.cv.net> for freebsd-current@freebsd.org; Mon, 01 Sep 2008 02:15:42 -0400 (EDT) Received: from flosoft.no-ip.biz (localhost [127.0.0.1]) by flosoft.no-ip.biz (8.14.3/8.14.3) with ESMTP id m812E3H7085504; Sun, 31 Aug 2008 22:14:04 -0400 Date: Sun, 31 Aug 2008 22:14:03 -0400 From: "Aryeh M. Friedman" To: freebsd-current@freebsd.org Message-id: <48BB4FEB.1050906@gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT User-Agent: Thunderbird 2.0.0.16 (X11/20080824) Subject: RFC: moving sysutils/fusefs-kmod to base system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Sep 2008 06:15:43 -0000 Unless I understand how the kernel does stuff there is no penalty for having unused modules (except the size of the kernel that needs to be loaded). Keeping in mind that unless I am not reading stuff corectly fusefs-kmod is the only FS related module that is not in the base system. Since any fundamental changes in the generic FS API seems to break fusefs-kmod, and cause some very nasty effects that are almost impossible to trace to fusefs-kmod (machine freezes so no output or core dump) it seems to make sense to move it to the base system (after all we already do this with third party FS code like x/zfs) by moving it we force it to always compile instead of breaking (of course there can be other issues but as the FS API is updated fusefs-kmod is also updated to use the new API) From owner-freebsd-current@FreeBSD.ORG Mon Sep 1 07:21:20 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3C7E5106566B for ; Mon, 1 Sep 2008 07:21:20 +0000 (UTC) (envelope-from caelian@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by mx1.freebsd.org (Postfix) with ESMTP id BB5958FC20 for ; Mon, 1 Sep 2008 07:21:19 +0000 (UTC) (envelope-from caelian@gmail.com) Received: by ey-out-2122.google.com with SMTP id 6so703513eyi.7 for ; Mon, 01 Sep 2008 00:21:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; 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; bh=lABDBmAqBRwcy/J/DT2Pb5YF2PZ+oVzLT0AwKlRkeDs=; b=SZUiSJgrzX/w2W6jdbRxaxSJAc+H6zBL4rLDv5X/APIz7erB8lbO5LELORcCXB9fIg ExPwXftZSgRkmlXNAxYOUuCqPkFkR+IukOl/hXlXwfAi1XeKlPv7kFIRM1D+VtJKyZQO FQCQqz2aZdSaQHxJ72L03XAjlMY6LmXaljUCU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=Z/kzrJ959jYhftmGHPP3x8H73rVswks8q9rgvOgDafcYrnstmcu5CYkAWwQXXv5CaW 6z2TbCtrO5TTCIYI/xOKA7YyKI65XDXHsrhL0YJqSXSkZo+TnW9CIOYa9roJdeNJ32Gl U0ukYie5UParP/ez2TzJGDpcqWvKK4T7eNsiY= Received: by 10.210.22.16 with SMTP id 16mr6058226ebv.92.1220253676632; Mon, 01 Sep 2008 00:21:16 -0700 (PDT) Received: by 10.210.44.20 with HTTP; Mon, 1 Sep 2008 00:21:16 -0700 (PDT) Message-ID: Date: Mon, 1 Sep 2008 09:21:16 +0200 From: "Pascal Hofstee" To: "Christian Weisgerber" In-Reply-To: <20080830010551.GA2090@lorvorc.mips.inka.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200808231056.18305.jhb@freebsd.org> <200808290951.44955.jhb@freebsd.org> <20080830010551.GA2090@lorvorc.mips.inka.de> Cc: freebsd-current@freebsd.org Subject: Re: No root filesystem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Sep 2008 07:21:20 -0000 On Sat, Aug 30, 2008 at 3:05 AM, Christian Weisgerber wrote: > John Baldwin: > >> So the reports I've seen of this all involve the Nvidia MCP55 ATA chipset, and >> only the ata controller loses its marbles (so to speak). > > I also observe that k8temp doesn't attach. Maybe Pascal can check this. > It's not part of GENERIC, so k8temp.ko needs to be explicitly loaded > by the loader for this. > > k8temp0: on hostb3 Ok .. this morning i went ahead and collected two boot -v logs. One for the old (working) kernel and one for the new (broken) kernel. For this i made sure not to load the snd_hda module as that tended to bloat the verbose boot output beyond the limit that i could still get to the interesting data at the next boot. The two verbose bootlogs can be found at: http://shadowrun.homeunix.net/boot.verbose.working for the old kernel http://shadowrun.homeunix.net/boot.verbose.broken for the new kernel http://shadowrun.homeunix.net/boot.verbose.diff for the differences between the two. The part that really stood out for me is the section of found devices on pcib0: slot 8 INTA routed to irq 22 via \\_SB_.LMAC The working kernel shows several devices there that do Not show up on the new kernel, according to http://www.pcidatabase.com this concerns the following devices all by"Advanced Micro Devices" -found-> vendor=0x1022, dev=0x1100, revid=0x00 0x1100 HyperTransport Technology Configuration -found-> vendor=0x1022, dev=0x1101, revid=0x00 0x1101 Address Map -found-> vendor=0x1022, dev=0x1102, revid=0x00 0x1102 DRAM Controller -found-> vendor=0x1022, dev=0x1103, revid=0x00 0x1103 Miscellaneous Control I believe this to be rather significant especially because of the way the old kernel hooks up my SATA disks: (ata2-master -> ata2 | ata3-master -> ata3) -> atapci1 -> pci0 -> pcib0 Also i can confirm that indeed k8temp for me also does not even probe with the new kernel. Beyond that i do not see anything majorly different between the two verbose boot logs. I hope this information will provide enough insight into the observed problem :) -- Pascal Hofstee From owner-freebsd-current@FreeBSD.ORG Mon Sep 1 08:30:55 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A22AB1065679; Mon, 1 Sep 2008 08:30:55 +0000 (UTC) (envelope-from kevinxlinuz@163.com) Received: from m5-85.163.com (m12-15.163.com [220.181.12.15]) by mx1.freebsd.org (Postfix) with SMTP id 685268FC2B; Mon, 1 Sep 2008 08:30:54 +0000 (UTC) (envelope-from kevinxlinuz@163.com) Received: from [127.0.0.1] (unknown [60.191.58.178]) by smtp11 (Coremail) with SMTP id D8CowLD7lEw+qLtIOlSIYA==.7990S2; Mon, 01 Sep 2008 16:30:54 +0800 (CST) Message-ID: <48BBA841.3060507@163.com> Date: Mon, 01 Sep 2008 16:30:57 +0800 From: kevin User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: FreeBSD Current References: <20080727125413.GG1345@garage.freebsd.pl> <488CBF49.10308@delphij.net> In-Reply-To: <488CBF49.10308@delphij.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Coremail-Antispam: 1Uf129KBjvdXoW7XF15KF17ZFWUKrykCrWUtwb_yoWxAwbEqa y2kr1UCrW2g3yxZwsxKr98J348JrW3C3W5Z34FqFsxW3yqqayxGFZ7J3y0gr1Yka1rtr95 Jw1rXw1UCa13XjkaLaAFLSUrUUUUUbIjqfuFe4nvWSU5nxnvy29KBjDU0xBIdaVrnRJUUU cjb7Iv0xC_Xr1lb4IE77IF4wAFF20E14v26r1j6r4UM7C26xCjj4IEI4klw4CSwwAFxVCa YxvI4VCIwcAKzIAtM7CIcVAFz4kK6r1j6r18M2kK67kvxFCE548m6r1fGryUXwAa7VCY0V AaVVAqrcv_Jw1UWr13Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0I7IYx2IY67AKxVWU XVWUAwAv7VC2z280aVAFwI0_Gr0_Cr1lFVAaXTZC67ZELSn0mTvEwaV2v3VFvVW8M4IE42 xK82IY64kIx2x0424l7I0Y64k_MxkIecxEwVAFwVW8ZwCY0x0Ix7I2Y4AK6F4j6FyUMxCj nVAqn7xvrwC2zVAF1VAY17CE14v26r1Y6r17YxBIdaVFxhVjvjDU0xZFpf9x07U3cTPUUU UU= Cc: Pawel Jakub Dawidek Subject: Re: ZFS patches. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Sep 2008 08:30:55 -0000 Hi, The patch can't work with current source tree now. vdev_file.c,zfs_context.h and zfs_replay.c could not be patched correctly.I tried to do it by hand,it stop at: /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_file.c: In function 'vdev_file_open': /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_file.c:105: error: too many arguments to function 'VOP_GETATTR' *** Error code 1 Stop in /usr/src/sys/modules/zfs. *** Error code 1 Stop in /usr/src/sys/modules. It seems VOP_GETATTR was changed recently.(VOP_GETATTR in zfs_context.h) Thanks kevin From owner-freebsd-current@FreeBSD.ORG Mon Sep 1 08:32:09 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B573B106566C for ; Mon, 1 Sep 2008 08:32:09 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by mx1.freebsd.org (Postfix) with ESMTP id 417FB8FC08 for ; Mon, 1 Sep 2008 08:32:09 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: by ey-out-2122.google.com with SMTP id 6so713116eyi.7 for ; Mon, 01 Sep 2008 01:32:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:date:from:to:cc :subject:message-id:references:mime-version:content-type :content-disposition:in-reply-to:user-agent:sender; bh=nw/MZX7CA5V/hc+7oAub1LaePGlq6oI6khXAIacxflM=; b=peC/7YIkCUTRehN/i8Sl8g7PEcIpMnS5FDt4d10SJJlxXAyYI5kLTuPfLpS19LEu3y Xr9WcAFvFvQz6T3y4kIZ4A0xQuoUVvXAl65uWiUoLSWZhzclIBpJmx8ACpJM3etcWsBD sbDSfxaKLR5ksf8SJYy1LTedqGwcyMvYHHsBI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent:sender; b=bLwWbvFzeoVcMUJuLY8t6O8jml0e0IbyfYmcc6vMz6scH5sWYZoD06PX1JHdoN31PX dTfkcE+CwV9pOMnIRfpiPeGMGJkyZTmDGQHNMtrHfclF330033llETFthNq5sP4oxysT VvDkA0N7Tm5XZaXH/MCbLWtgU1IivKxD5H0Pg= Received: by 10.210.56.7 with SMTP id e7mr6187218eba.5.1220257927884; Mon, 01 Sep 2008 01:32:07 -0700 (PDT) Received: from alpha.local ( [83.144.140.92]) by mx.google.com with ESMTPS id 5sm7477834eyf.8.2008.09.01.01.32.06 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 01 Sep 2008 01:32:07 -0700 (PDT) Received: by alpha.local (Postfix, from userid 1001) id 52FB6F57A; Mon, 1 Sep 2008 09:31:06 +0100 (WEST) Date: Mon, 1 Sep 2008 09:31:06 +0100 From: Rui Paulo To: "army.of.root@googlemail.com" Message-ID: <20080901083106.GB97323@alpha.local> References: <48BB403C.5090103@googlemail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48BB403C.5090103@googlemail.com> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: Rui Paulo Cc: freebsd-current@FreeBSD.org, Rui Paulo Subject: Re: k8temp choose the higher temp of the two sensors on one core X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Sep 2008 08:32:09 -0000 On Mon, Sep 01, 2008 at 03:07:08AM +0200, army.of.root@googlemail.com wrote: > Hi, > > I noticed that not the highest of the two temp values of one core is used: > > dev.cpu.0.temperature: 46 > dev.cpu.1.temperature: 46 <== > dev.k8temp.0.%desc: AMD K8 Thermal Sensors > dev.k8temp.0.%driver: k8temp > dev.k8temp.0.%parent: hostb3 > dev.k8temp.0.sensor0.core0: 46 > dev.k8temp.0.sensor0.core1: 49 <== > dev.k8temp.0.sensor1.core0: 46 > dev.k8temp.0.sensor1.core1: 46 > Well, this is normal. The temperature is queried twice, so it could have changed meanwhile. Regards, -- Rui Paulo From owner-freebsd-current@FreeBSD.ORG Mon Sep 1 10:11:25 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AF4971065674 for ; Mon, 1 Sep 2008 10:11:25 +0000 (UTC) (envelope-from shuvaev@physik.uni-wuerzburg.de) Received: from mailrelay.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by mx1.freebsd.org (Postfix) with ESMTP id 3BC4C8FC14 for ; Mon, 1 Sep 2008 10:11:24 +0000 (UTC) (envelope-from shuvaev@physik.uni-wuerzburg.de) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 23DC9198E37; Mon, 1 Sep 2008 12:11:22 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 172AC198E35; Mon, 1 Sep 2008 12:11:22 +0200 (CEST) Received: from mail.physik.uni-wuerzburg.de (wthp192.physik.uni-wuerzburg.de [132.187.40.192]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 00CB6198E34; Mon, 1 Sep 2008 12:11:22 +0200 (CEST) Received: from wep400x.physik.uni-wuerzburg.de ([132.187.37.32]) by mail.physik.uni-wuerzburg.de (Lotus Domino Release 8.0.1HF110) with ESMTP id 2008090112112147-22731 ; Mon, 1 Sep 2008 12:11:21 +0200 Received: by wep400x.physik.uni-wuerzburg.de (sSMTP sendmail emulation); Mon, 1 Sep 2008 12:11:21 +0200 From: "Alexey Shuvaev" Date: Mon, 1 Sep 2008 12:11:21 +0200 To: Ed Schouten Message-ID: <20080901101121.GC4083@wep400x.physik.uni-wuerzburg.de> References: <48BAD085.1090507@gmail.com> <20080831200950.GF99951@hoeg.nl> <871w04syfw.fsf@kobe.laptop> MIME-Version: 1.0 In-Reply-To: <871w04syfw.fsf@kobe.laptop> Organization: Universitaet Wuerzburg User-Agent: Mutt/1.5.18 (2008-05-17) X-MIMETrack: Itemize by SMTP Server on domino1/uni-wuerzburg(Release 8.0.1HF110 | April 11, 2008) at 09/01/2008 12:11:21 PM, Serialize by Router on domino1/uni-wuerzburg(Release 8.0.1HF110 | April 11, 2008) at 09/01/2008 12:11:21 PM, Serialize complete at 09/01/2008 12:11:21 PM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: freebsd-current@freebsd.org Subject: Re: csh history and pts X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Sep 2008 10:11:25 -0000 On Sun, Aug 31, 2008 at 11:48:35PM +0300, Giorgos Keramidas wrote: > > Yes, a bit of background is probably going to be useful... > > tcsh enables autologout automatically to a default of 60 seconds in the > following cases: > > Set to `60' (automatic logout after 60 minutes, and no > locking) by default in login and superuser shells, but not if > the shell thinks it is running under a window system (i.e., > the DISPLAY environment variable is set), the tty is a > pseudo-tty (pty) or the shell was not so compiled (see the > version shell variable). > > The `contrib/tcsh/sh.c' code implements this near line 456: > [snip] > > I have an IRC log from scottl noting that he still got the default 60 > second autologout, but this was on 6.X IIRC: > > * scottl__ tries to remember how to turn off auto-logout > scottl__: tcsh option - I guess tcsh can no longer determin > activity post TTY? > scottl__: I remember Kris mentioning an mpsafetty & tcsh > issue. I haven't had the time to go back and check if the pty-detection > we fixed with kern.pts.enable=1 still works after mpsafetty > scottl__: what does echo $autologout say? > [y1] ~> echo $autologout > 60 > on a 6.3 machine, I get > pooker] ~> echo $autologout > autologout: Undefined variable. > > I can't reproduce this with a current from Aug 29, but this snapshot has > been built with the experimental 'packet mode' patch, and a few other > local changes, so I will have to try with a clean /head/ snapshot. > FWIW: In xterm: ~> uname -a FreeBSD wep400x.physik.uni-wuerzburg.de 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Sun Aug 31 16:30:20 CEST 2008 root@wep400x.physik.uni-wuerzburg.de:/usr/obj/usr/src/sys/GENERIC amd64 ~> echo $autologout autologout: Undefined variable. ~> su - Password: # echo $autologout 60 In the console (I think ttyv*) autologout is not defined for both normal user and root. Finally, ~> echo $version tcsh 6.15.00 (Astron) 2007-03-03 (unknown-unknown-FreeBSD) options wide,nls,dl,al,kan,sm,rh,color,filec Back to original post, I confirm that [t]csh loses history after shutdown(8). My 0.02$, Alexey. From owner-freebsd-current@FreeBSD.ORG Mon Sep 1 10:41:04 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A503A1065675 for ; Mon, 1 Sep 2008 10:41:04 +0000 (UTC) (envelope-from Thomas.Sparrevohn@btinternet.com) Received: from smtp821.mail.ukl.yahoo.com (smtp821.mail.ukl.yahoo.com [217.12.12.250]) by mx1.freebsd.org (Postfix) with SMTP id 1A14A8FC17 for ; Mon, 1 Sep 2008 10:41:03 +0000 (UTC) (envelope-from Thomas.Sparrevohn@btinternet.com) Received: (qmail 89836 invoked from network); 1 Sep 2008 10:14:23 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=btinternet.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language; b=f9rtliLdCJq8CP23uJTBMrHopiGaG4aPY0C1w1iJFhKs4ZWdSARE/iBF5tgPKpNJQHRCU3a/Bp2Um7LSBPfOFa3J4px7c6mfOHR0QFb7FACnhfbibW/gdi1T9ir+A961v25pTQNgBLlY1Z3xSvPWB/FkwdxsVhy1bAgDFdSb+fw= ; Received: from unknown (HELO W2FZZ0VC03) (thomas.sparrevohn@btinternet.com@86.136.31.195 with login) by smtp821.mail.ukl.yahoo.com with SMTP; 1 Sep 2008 10:14:23 -0000 X-YMail-OSG: VcDrym8VM1kwBixGwtJvMkal30WXUosyVA.vbMseoIEIFE.RAN2qvcMbhcbxrQ227TyTLafoMDbPfi9GNsVZ2pFVPpEuIB8vOBBZy3bB0m3tEjv_TpuHAkZOYq6c7Mg- X-Yahoo-Newman-Property: ymail-3 From: "Thomas Sparrevohn" To: "'kevin'" , "'FreeBSD Current'" References: <20080727125413.GG1345@garage.freebsd.pl> <488CBF49.10308@delphij.net> <48BBA841.3060507@163.com> In-Reply-To: <48BBA841.3060507@163.com> Date: Mon, 1 Sep 2008 11:14:22 +0100 Message-ID: <000001c90c1b$819c1530$84d43f90$@Sparrevohn@btinternet.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AckMDR5YRU0HAPtHSnuRaXEBc3ubzwADhavA Content-Language: en-gb Cc: 'Pawel Jakub Dawidek' Subject: RE: ZFS patches. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Sep 2008 10:41:04 -0000 I ran into the same problem - Pawel what are the timeline for getting the patch into CURRENT? It seems to work fine - However I assume that some merging will have to be done with the NFSV4 ACL? -----Original Message----- From: owner-freebsd-current@freebsd.org [mailto:owner-freebsd-current@freebsd.org] On Behalf Of kevin Sent: 01 September 2008 09:31 To: FreeBSD Current Cc: Pawel Jakub Dawidek Subject: Re: ZFS patches. Hi, The patch can't work with current source tree now. vdev_file.c,zfs_context.h and zfs_replay.c could not be patched correctly.I tried to do it by hand,it stop at: /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/vd ev_file.c: In function 'vdev_file_open': /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/vd ev_file.c:105: error: too many arguments to function 'VOP_GETATTR' *** Error code 1 Stop in /usr/src/sys/modules/zfs. *** Error code 1 Stop in /usr/src/sys/modules. It seems VOP_GETATTR was changed recently.(VOP_GETATTR in zfs_context.h) Thanks kevin _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Mon Sep 1 12:50:49 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DE9A7106564A for ; Mon, 1 Sep 2008 12:50:49 +0000 (UTC) (envelope-from alex-goncharov@comcast.net) Received: from QMTA01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by mx1.freebsd.org (Postfix) with ESMTP id 8DD798FC1D for ; Mon, 1 Sep 2008 12:50:49 +0000 (UTC) (envelope-from alex-goncharov@comcast.net) Received: from OMTA02.westchester.pa.mail.comcast.net ([76.96.62.19]) by QMTA01.westchester.pa.mail.comcast.net with comcast id 9PhM1a0090QuhwU51QaotD; Mon, 01 Sep 2008 12:34:48 +0000 Received: from daland.home ([24.61.21.4]) by OMTA02.westchester.pa.mail.comcast.net with comcast id 9Qal1a00E05H7zL3NQalB1; Mon, 01 Sep 2008 12:34:45 +0000 X-Authority-Analysis: v=1.0 c=1 a=WyKGbDgc-tgA:10 a=HHiX7DWWUSYA:10 a=rITDv7nW5hcA:10 a=p86Qp4d3rrSN5LiXVPkA:9 a=LY6ymqolsIcx-F8FWNcA:7 a=MUFzYB8CGC-18tBo0Wk_s5795eUA:4 a=si9q_4b84H0A:10 a=-ZQhYGXY2L8A:10 Received: from algo by daland.home with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ka8cJ-000GgI-Um for freebsd-current@FreeBSD.org; Mon, 01 Sep 2008 08:34:47 -0400 From: Alex Goncharov To: freebsd-current@FreeBSD.org Message-Id: Sender: Alex Goncharov Date: Mon, 01 Sep 2008 08:34:47 -0400 Cc: Subject: named mystery -- error: dumping master file: master/tmp-wTjhUzoix6 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Goncharov List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Sep 2008 12:50:50 -0000 For quite a while I've been trying to understand how to work around this little annoyance: named periodically writes dumping master file: master/tmp-dnbiuWrKNQ: open: permission denied to `/var/log/message'. Sure, I thought -- out of the box the `master' directory doesn't give write permission to user bind: -------------------- $ pwd; ls -ld master /var/named/etc/namedb drwxr-xr-x 2 root wheel 512 Aug 17 13:47 master/ -------------------- If, in a default setup, I change the owner of `master' to `bind', a `named' restart will revert the ownership to `root', due to the settings in `/etc/mtree/BIND.chroot.dist'. So, a couple of months ago I changed the latter: ---------------------------------------- $ diff /etc/mtree/BIND.chroot.dist~ /etc/mtree/BIND.chroot.dist 14c14 < master --- > master uname=bind ---------------------------------------- After this change, every time I restart `named', the ownership of the `master' directory is changed to `bind' -- and this is what I want: user `bind', I would think, should be allowed to write to this directory. Every time after the restart everything is working well: no complains about the `master/tmp-XXX' files (which are zone dumps -- I did look at the code.) But also every time some time after the restart (perhaps a week or two down the road), something (and I can't figure out what), changes the owner of `master' to `root' -- and the zone dump gets impossible. Not that this leads to any problem in my DNS operations but I am totally flabbergasted about this behavior: looked at the code, did all kind of Internet searches and experiments, and still don't have an idea on: Who changes the owner of the `master' directory from `bind' to `root'? (The only thing I can think of is the dynamic DNS updates by DHCP daemon.) At this point, I pulled back my change to `/etc/mtree/BIND.chroot.dist' -- there is no use in it if somebody overrides my preference later, silently. Does anybody know what's going on? Who is that "silent changer"? What settings should I change to get things work right? Thanks, -- Alex -- alex-goncharov@comcast.net -- From owner-freebsd-current@FreeBSD.ORG Mon Sep 1 13:00:19 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CAB35106569B for ; Mon, 1 Sep 2008 13:00:19 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (unknown [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id 46AD58FC2A for ; Mon, 1 Sep 2008 13:00:19 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.2/8.14.2) with ESMTP id m81D0H0N093447; Mon, 1 Sep 2008 15:00:17 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.2/8.14.2/Submit) id m81D0HMq093446; Mon, 1 Sep 2008 15:00:17 +0200 (CEST) (envelope-from olli) Date: Mon, 1 Sep 2008 15:00:17 +0200 (CEST) Message-Id: <200809011300.m81D0HMq093446@lurza.secnetix.de> From: Oliver Fromme To: freebsd-current@FreeBSD.ORG, aryeh.friedman@gmail.com In-Reply-To: <48BB4FEB.1050906@gmail.com> X-Newsgroups: list.freebsd-current User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.3-STABLE (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Mon, 01 Sep 2008 15:00:17 +0200 (CEST) Cc: Subject: Re: RFC: moving sysutils/fusefs-kmod to base system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-current@FreeBSD.ORG, aryeh.friedman@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Sep 2008 13:00:19 -0000 Aryeh M. Friedman wrote: > Unless I understand how the kernel does stuff there is no penalty for > having unused modules (except the size of the kernel that needs to be > loaded). Right. > Keeping in mind that unless I am not reading stuff corectly > fusefs-kmod is the only FS related module that is not in the base > system. How is that relevant? > Since any fundamental changes in the generic FS API seems to > break fusefs-kmod, I think such fundamental changes don't happen very often, and mostly only on -current. Therefore I don't think it's a significant problem. > [...] it seems to make sense to move it to the base system (after all > we already do this with third party FS code like x/zfs) by moving it we > force it to always compile instead of breaking (of course there can be > other issues but as the FS API is updated fusefs-kmod is also updated to > use the new API) That theory assumes that the fusefs-kmod code has an active maintainer who is a FreeBSD src committer. Does it? If it doesn't, then your proposal won't work very well. Since you mentioned XFS: I wouldn't mind XFS support being moved from base to ports. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "Life is short (You need Python)" -- Bruce Eckel, ANSI C++ Comitee member, author of "Thinking in C++" and "Thinking in Java" From owner-freebsd-current@FreeBSD.ORG Mon Sep 1 13:12:00 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CB1D81065674 for ; Mon, 1 Sep 2008 13:12:00 +0000 (UTC) (envelope-from garga@FreeBSD.org) Received: from capeta.freebsdbrasil.com.br (capeta.freebsdbrasil.com.br [201.48.151.3]) by mx1.freebsd.org (Postfix) with SMTP id C9F758FC21 for ; Mon, 1 Sep 2008 13:11:59 +0000 (UTC) (envelope-from garga@FreeBSD.org) Received: (qmail 84712 invoked from network); 1 Sep 2008 09:45:18 -0300 Received: by simscan 1.1.0 ppid: 84292, pid: 84329, t: 14.2356s scanners: clamav: 0.91.1/m: spam: 3.1.1 X-Spam-Checker-Version: SpamAssassin: -last, FreeBSD Brasil LTDA rulesets: Yes X-Spam-Status: No, hits=-1.9 required=3.7 Received: from unknown (HELO botelhor.bluepex.com) (garga@189.19.84.134) by capeta.freebsdbrasil.com.br with SMTP; 1 Sep 2008 09:45:03 -0300 Received: (qmail 27089 invoked by uid 1001); 1 Sep 2008 09:46:28 -0300 Date: Mon, 1 Sep 2008 09:46:28 -0300 From: Renato Botelho To: freebsd-current@FreeBSD.org Message-ID: <20080901124627.GC13194@bluepex.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Subject: [mgleason@ncftp.com: Re: [wxs@FreeBSD.org: Re: cvs commit: ports/ftp/ncftp3 pkg-plist]] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Sep 2008 13:12:00 -0000 Can anyone take a look at this problem happened with ncftp3 at 8.0-CURRENT, i'm just wondering if it could or not happen with other port(s). Thanks ----- Forwarded message from Mike Gleason ----- Date: Sun, 31 Aug 2008 18:51:24 -0500 From: Mike Gleason To: Renato Botelho Cc: wxs@FreeBSD.org, obrien@FreeBSD.org Subject: Re: [wxs@FreeBSD.org: Re: cvs commit: ports/ftp/ncftp3 pkg-plist] X-Mailer: Apple Mail (2.926) OK, I have a workaround for this problem. However, I believe there is a bug in the 8.0-CURRENT version of select(), which is returning an incorrect number of ready descriptors. This bug does not occur on 7.0- RELEASE. NcFTP's sio library function, _SConnect, wants to select() for one descriptor. It creates fd_set structures for writeable fds and exception fds, with each fd set having only one bit set corresponding to the single descriptor it is selecting. Select() then returns 2, rather than 1. NcFTP was essentially checking if select returned 1, and if so, OK, if not 1, error. Since 2 was returned, this was causing the problem that Renato reported. If a descriptor was both writeable and exceptioned, I suppose that select could count that descriptor twice (I'm not sure what the official semantics are). In that scenario, select could return 2, so regardless of any select bug, NcFTP will now check to see if a value greater than or equal to 1 is returned, rather than simply checking for equality to 1 (and this is the first patch for NcFTP 3.2.x appended below). However, there is still a problem in select() somewhere, since as you can see below, select() returns 2, but according to the resulting fd_sets, only the writeable fd_set has my fd. It should either return 1, or have the fd set in both the writers and exceptions fd_sets. (The second patch adds these debug prints, if you want to reproduce this.) > ./bin/ncftpls ftp://ftp.freebsd.org/pub/ fd 3 is set in writers fd 3 is set in exceptions select = 2 fd 3 is set in writers Mike Gleason NcFTP Software http://www.NcFTP.com diff -wurd ncftp-3.2.2/sio/SConnect.c ncftp-3.2.2-WORKAROUND/sio/ SConnect.c --- ncftp-3.2.2/sio/SConnect.c 2007-10-27 14:14:05.000000000 -0400 +++ ncftp-3.2.2-WORKAROUND/sio/SConnect.c 2008-08-31 19:00:56.000000000 -0400 @@ -154,7 +154,7 @@ tv.tv_sec = (tv_sec_t) tlen; tv.tv_usec = 0; result = select(sfd + 1, NULL, SELECT_TYPE_ARG234 &ss, SELECT_TYPE_ARG234 &xx, SELECT_TYPE_ARG5 &tv); - if (result == 1) { + if (result >= 1) { /* ready */ break; } else if (result == 0) { diff -wurd ncftp-3.2.2/sio/SConnect.c ncftp-3.2.2-SELECT-BUG/sio/ SConnect.c --- ncftp-3.2.2/sio/SConnect.c 2007-10-27 14:14:05.000000000 -0400 +++ ncftp-3.2.2-SELECT-BUG/sio/SConnect.c 2008-08-31 19:10:04.000000000 -0400 @@ -151,10 +151,25 @@ #if defined(__DECC) || defined(__DECCXX) # pragma message restore #endif +{ +int x; +for (x=0; x<=sfd; x++) { +if (MY_FD_ISSET(x, &ss)) {fprintf(stderr, "fd %d is set in writers\n", x); } +if (MY_FD_ISSET(x, &xx)) {fprintf(stderr, "fd %d is set in exceptions\n", x); } +} +} tv.tv_sec = (tv_sec_t) tlen; tv.tv_usec = 0; result = select(sfd + 1, NULL, SELECT_TYPE_ARG234 &ss, SELECT_TYPE_ARG234 &xx, SELECT_TYPE_ARG5 &tv); - if (result == 1) { +fprintf(stderr, "select = %d\n", result); +{ +int x; +for (x=0; x<=sfd; x++) { +if (MY_FD_ISSET(x, &ss)) {fprintf(stderr, "fd %d is set in writers\n", x); } +if (MY_FD_ISSET(x, &xx)) {fprintf(stderr, "fd %d is set in exceptions\n", x); } +} +} + if (result >= 1) { /* ready */ break; } else if (result == 0) { On Aug 27, 2008, at 11:05 AM, Renato Botelho wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hello Mike, > > What do you think about it? > > Regards > > - ----- Forwarded message from Wesley Shields ----- > > Date: Wed, 27 Aug 2008 11:04:15 -0400 > From: Wesley Shields > To: Renato Botelho > Cc: "David E. O'Brien" , cvs-ports@FreeBSD.org > Subject: Re: cvs commit: ports/ftp/ncftp3 pkg-plist > > On Wed, Aug 27, 2008 at 11:49:52AM -0300, Renato Botelho wrote: >> On Wed, Aug 27, 2008 at 02:31:01PM +0000, David E. O'Brien wrote: >>> obrien 2008-08-27 14:31:01 UTC >>> >>> FreeBSD ports repository >>> >>> Modified files: >>> ftp/ncftp3 pkg-plist >>> Log: >>> Upgrade to version 3.2.2. >> >> This version still doesn't work at recent -CURRENT (since 800041 for >> me). >> >> garga@botelhor:~> ncftp >> NcFTP 3.2.2 (Aug 18, 2008) by Mike Gleason >> (http://www.NcFTP.com/contact/). >> ncftp> open ftp.FreeBSD.org >> Could not connect to ftp.FreeBSD.org: Operation now in progress. >> Could not open host ftp.FreeBSD.org: could not connect to remote >> host. >> >> What do you think to mark it as BROKEN? >> >> btw, i've notified ncftp people about this problem, but the guy >> couldn't >> install -CURRENT on his vmware and couldn't reproduce, but me and >> more 2 >> people that i've assked tested and had the same. > > I can give him/her access to an amd64 -current box for testing if (s)he > wants. > > - -- WXS > > - ----- End forwarded message ----- > > - -- > Renato Botelho > > GnuPG Key: http://www.FreeBSD.org/~garga/pubkey.asc > > Dianetics is a milestone for man comparable to his discovery of > fire and superior to his invention of the wheel and the arch. > -- L. Ron Hubbard > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.9 (FreeBSD) > > iEYEARECAAYFAki1e0UACgkQ6CRbiSJE7anb2gCeOJIhB+OzS/XFiVnDZh6Wl+Yl > u/AAoJEG69J0gf2+6unuIi4PhxeLZ2L7 > =CjJA > -----END PGP SIGNATURE----- > > ----- End forwarded message ----- -- Renato Botelho GnuPG Key: http://www.FreeBSD.org/~garga/pubkey.asc I think your opinions are reasonable, except for the one about my mental instability. -- Psychology Professor, Farifield University From owner-freebsd-current@FreeBSD.ORG Mon Sep 1 13:31:14 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F0A811065671 for ; Mon, 1 Sep 2008 13:31:14 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (unknown [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id 54D218FC14 for ; Mon, 1 Sep 2008 13:31:14 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.2/8.14.2) with ESMTP id m81DV75S094906; Mon, 1 Sep 2008 15:31:08 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.2/8.14.2/Submit) id m81DV7pq094904; Mon, 1 Sep 2008 15:31:07 +0200 (CEST) (envelope-from olli) Date: Mon, 1 Sep 2008 15:31:07 +0200 (CEST) Message-Id: <200809011331.m81DV7pq094904@lurza.secnetix.de> From: Oliver Fromme To: freebsd-current@FreeBSD.ORG, Alex Goncharov In-Reply-To: X-Newsgroups: list.freebsd-current User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.3-STABLE (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Mon, 01 Sep 2008 15:31:08 +0200 (CEST) Cc: Subject: Re: named mystery -- error: dumping master file: master/tmp-wTjhUzoix6 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-current@FreeBSD.ORG, Alex Goncharov List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Sep 2008 13:31:15 -0000 Alex Goncharov wrote: > [...] > After this change, every time I restart `named', the ownership of the > `master' directory is changed to `bind' -- and this is what I want: > user `bind', I would think, should be allowed to write to this > directory. No, it shouldn't. It's a security matter. If there's an exploitable bug in BIND, an attacker could manipulate your master zone files. That's why the bind user should *not* be able to write to your master directory. There's no reason that the named process needs write access to the master directory. If you use dynamic zone updates, you should use the "dynamic" directory for those zones, which is writable by bind. > Who changes the owner of the `master' directory from `bind' to > `root'? I'm sorry, I don't know. In fact I have a similar problem with mtree: I want /var/mail to be mode 1777 (the reason is to make dot-locking work), so I changed BSD.var.dist to include "mode=01777" for the mail directory, but it doesn't work. After an installworld the directory is back to 0775. I have no idea why. My workaround is to insert a chmod command in /etc/rc.local. It's not pretty, but it works. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "We, the unwilling, led by the unknowing, are doing the impossible for the ungrateful. We have done so much, for so long, with so little, we are now qualified to do anything with nothing."         -- Mother Teresa From owner-freebsd-current@FreeBSD.ORG Mon Sep 1 13:46:30 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C93C81065689 for ; Mon, 1 Sep 2008 13:46:30 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from koef.zs64.net (koef.zs64.net [212.12.50.230]) by mx1.freebsd.org (Postfix) with ESMTP id 359028FC41 for ; Mon, 1 Sep 2008 13:46:29 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from localhost by koef.zs64.net (8.14.3/8.14.3) with ESMTP id m81DVhEg087421 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 1 Sep 2008 15:31:50 +0200 (CEST) (envelope-from stb@lassitu.de) (authenticated as stb) Message-Id: <9B5F3198-4C3E-4FDE-B9BC-2C67B0B82CEC@lassitu.de> From: Stefan Bethke To: Alex Goncharov In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v928.1) Date: Mon, 1 Sep 2008 15:31:37 +0200 References: X-Mailer: Apple Mail (2.928.1) Cc: freebsd-current@freebsd.org Subject: Re: named mystery -- error: dumping master file: master/tmp-wTjhUzoix6 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Sep 2008 13:46:30 -0000 Am 01.09.2008 um 14:34 schrieb Alex Goncharov: > For quite a while I've been trying to understand how to work around > this little annoyance: named periodically writes > > dumping master file: master/tmp-dnbiuWrKNQ: open: permission denied > > to `/var/log/message'. > > Sure, I thought -- out of the box the `master' directory doesn't give > write permission to user bind Why is named trying to dump a master zone? The root ownership is intentional: since named is only serving these zones, not receiving or updating them, the files are not writeable by the bind user. Stefan -- Stefan Bethke Fon +49 170 346 0140 From owner-freebsd-current@FreeBSD.ORG Mon Sep 1 14:12:24 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3396B106566B for ; Mon, 1 Sep 2008 14:12:24 +0000 (UTC) (envelope-from alex-goncharov@comcast.net) Received: from QMTA06.emeryville.ca.mail.comcast.net (qmta06.emeryville.ca.mail.comcast.net [76.96.30.56]) by mx1.freebsd.org (Postfix) with ESMTP id 1A4E58FC0C for ; Mon, 1 Sep 2008 14:12:24 +0000 (UTC) (envelope-from alex-goncharov@comcast.net) Received: from OMTA01.emeryville.ca.mail.comcast.net ([76.96.30.11]) by QMTA06.emeryville.ca.mail.comcast.net with comcast id 9PPt1a0040EPchoA6S2Qka; Mon, 01 Sep 2008 14:02:24 +0000 Received: from daland.home ([24.61.21.4]) by OMTA01.emeryville.ca.mail.comcast.net with comcast id 9S2N1a00805H7zL8MS2Pk1; Mon, 01 Sep 2008 14:02:24 +0000 X-Authority-Analysis: v=1.0 c=1 a=aVV7_ef_2ZQA:10 a=y3Be58pVqgkA:10 a=rITDv7nW5hcA:10 a=tBTIeuz21jnuXfyD9oYA:9 a=miZ-xwcqITgsGs0uY28W0JRVJZ8A:4 a=si9q_4b84H0A:10 a=mhQ4J5QMNLoA:10 Received: from algo by daland.home with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ka9z3-0009PA-Rw; Mon, 01 Sep 2008 10:02:21 -0400 From: Alex Goncharov To: Stefan Bethke In-reply-to: <9B5F3198-4C3E-4FDE-B9BC-2C67B0B82CEC@lassitu.de> (message from Stefan Bethke on Mon, 1 Sep 2008 15:31:37 +0200) References: <9B5F3198-4C3E-4FDE-B9BC-2C67B0B82CEC@lassitu.de> Message-Id: Sender: Alex Goncharov Date: Mon, 01 Sep 2008 10:02:21 -0400 Cc: freebsd-current@freebsd.org, alex-goncharov@comcast.net Subject: Re: named mystery -- error: dumping master file: master/tmp-wTjhUzoix6 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Goncharov List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Sep 2008 14:12:24 -0000 ,--- You/Stefan (Mon, 1 Sep 2008 15:31:37 +0200) ----* | Why is named trying to dump a master zone? The root ownership is | intentional: since named is only serving these zones, not receiving or | updating them, the files are not writeable by the bind user. Sorry, why can't a master zone be updatable? How about rndc? How about making entries per DHCP daemon requests? Is there a standard statement that a master zone can't be dynamically updated? -- Alex -- alex-goncharov@comcast.net -- From owner-freebsd-current@FreeBSD.ORG Mon Sep 1 14:13:00 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 51CC6106567C; Mon, 1 Sep 2008 14:13:00 +0000 (UTC) (envelope-from null@pozo.com) Received: from pozo.com (pozo.com [216.101.162.50]) by mx1.freebsd.org (Postfix) with ESMTP id 1826C8FC1F; Mon, 1 Sep 2008 14:12:59 +0000 (UTC) (envelope-from null@pozo.com) Received: from T41p.pozo.com (t41p.pozo.com [192.168.0.4]) (authenticated bits=0) by pozo.com (8.14.3/8.14.3) with ESMTP id m81DZW8b006033 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 1 Sep 2008 06:35:33 -0700 (PDT) (envelope-from null@pozo.com) Message-Id: <200809011335.m81DZW8b006033@pozo.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 01 Sep 2008 06:35:15 -0700 To: freebsd-current@freebsd.org From: Manfred Antar Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, score=-101.4 required=5.0 tests=ALL_TRUSTED,MISSING_MID, USER_IN_WHITELIST autolearn=failed version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on pozo.com X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on pozo.com X-Virus-Status: Clean Cc: ports@freebsd.org Subject: Apache.sh on current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Sep 2008 14:13:00 -0000 /usr/local/etc/rc.d/apache.sh : /usr/bin/limits -e -U www dumps core when starting apache on current This something new, not sure when it started as I have been out of the Country for the past month. Kernel and usr are current Also /usr/local/sbin/apachect : eval `limits -e -C daemon` also dumps core ================================== || null@pozo.com || || Ph. (415) 681-6235 || ================================== From owner-freebsd-current@FreeBSD.ORG Mon Sep 1 14:14:22 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 352301065686 for ; Mon, 1 Sep 2008 14:14:22 +0000 (UTC) (envelope-from alex-goncharov@comcast.net) Received: from QMTA05.emeryville.ca.mail.comcast.net (qmta05.emeryville.ca.mail.comcast.net [76.96.30.48]) by mx1.freebsd.org (Postfix) with ESMTP id 1A68B8FC2B for ; Mon, 1 Sep 2008 14:14:22 +0000 (UTC) (envelope-from alex-goncharov@comcast.net) Received: from OMTA01.emeryville.ca.mail.comcast.net ([76.96.30.11]) by QMTA05.emeryville.ca.mail.comcast.net with comcast id 9QS71a0060EPchoA5RyNRt; Mon, 01 Sep 2008 13:58:22 +0000 Received: from daland.home ([24.61.21.4]) by OMTA01.emeryville.ca.mail.comcast.net with comcast id 9RyJ1a00B05H7zL8MRyKx2; Mon, 01 Sep 2008 13:58:20 +0000 X-Authority-Analysis: v=1.0 c=1 a=fyfqdYF2hYYA:10 a=y3Be58pVqgkA:10 a=rITDv7nW5hcA:10 a=05FjcV7UAAAA:8 a=uZkhZlGR_L3skUBHqPYA:9 a=9btQufkmoi2c6pNA_sMTwYjWWpkA:4 a=uoE9lMzFE5YA:10 a=si9q_4b84H0A:10 a=mhQ4J5QMNLoA:10 Received: from algo by daland.home with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ka9v7-0007oh-Re; Mon, 01 Sep 2008 09:58:17 -0400 From: Alex Goncharov To: freebsd-current@FreeBSD.ORG, Alex Goncharov In-reply-to: <200809011331.m81DV7pq094904@lurza.secnetix.de> (message from Oliver Fromme on Mon, 1 Sep 2008 15:31:07 +0200 (CEST)) References: <200809011331.m81DV7pq094904@lurza.secnetix.de> Message-Id: Sender: Alex Goncharov Date: Mon, 01 Sep 2008 09:58:17 -0400 Cc: freebsd-current@FreeBSD.ORG, alex-goncharov@comcast.net Subject: Re: named mystery -- error: dumping master file: master/tmp-wTjhUzoix6 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Goncharov List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Sep 2008 14:14:22 -0000 ,--- Oliver Fromme (Mon, 1 Sep 2008 15:31:07 +0200 (CEST)) ----* | Alex Goncharov wrote: | > [...] | > After this change, every time I restart `named', the ownership of the | > `master' directory is changed to `bind' -- and this is what I want: | > user `bind', I would think, should be allowed to write to this | > directory. | | No, it shouldn't. It's a security matter. If there's an | exploitable bug in BIND, an attacker could manipulate your | master zone files. That's why the bind user should *not* | be able to write to your master directory. OK, I am ready to accept this point of view and make it my starting point again (I tried, in the past). | There's no reason that the named process needs write access | to the master directory. If you use dynamic zone updates, | you should use the "dynamic" directory for those zones, | which is writable by bind. I just tried a simplistic change: a. Changed "type master" to "type dynamic" in named.conf. b. cp master/* dynamic Starting `named' with this I get: /etc/namedb/named.conf:358: 'dynamic' unexpected How do I use the `dynamic' directory? (If you know the answer -- I'll do more reading later.) OTOH, I see this example at `http://www.boran.com/security/sp/bind9_20010430.html#BM4_setting_jail_permission' -------------------- zone "test2.com" { type master; file "test2.com"; allow-update { updaters; }; }; -------------------- Which is: a. Close enough to what I have, in my original `named.conf', before a `dynamic' change attempt. b. Implies that updating a master zone is not such an unusual idea. Any comments on this? -- Alex -- alex-goncharov@comcast.net -- From owner-freebsd-current@FreeBSD.ORG Mon Sep 1 14:19:58 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E03DC106568D for ; Mon, 1 Sep 2008 14:19:58 +0000 (UTC) (envelope-from kometen@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.158]) by mx1.freebsd.org (Postfix) with ESMTP id 734598FC2C for ; Mon, 1 Sep 2008 14:19:57 +0000 (UTC) (envelope-from kometen@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so1249822fgb.35 for ; Mon, 01 Sep 2008 07:19:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; 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; bh=k6RbAwug3xyXhTQH+wpy6Xm6vVDvVYLPwG+oZ1c15pk=; b=kbNRkFfSGbV/hduzMhks64IiDwXlZZPtWzi/n9PhneXM9sdBjXcOxcTauj7EdzMANE 76ACSZf/LA72u9sbuQwxJN4oUwOqxHIA1tM/0HJ68y6N6AxlzSr6BTq5x6C03pN05SMI 8BoXzMYX95kv6sfItaBCQEP1BwrBOo/3yYFIE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=MnREAY0ArWzJj7e75gFBNWmR51NqGwqNxzYWR1dlBNllCoo83Tdz9Jf8Ym3LoU7DLd jcglsoUbRBAij73q7YlZmeKJAUVQV6Jwwj5+Id0FNQuV8fcUmuIia6lhZbSo1X9L22q4 syg9TuFJzY4YP97bHAOaG0dWtLTsFQZFZX2EY= Received: by 10.86.31.18 with SMTP id e18mr4629275fge.52.1220278796988; Mon, 01 Sep 2008 07:19:56 -0700 (PDT) Received: by 10.86.79.10 with HTTP; Mon, 1 Sep 2008 07:19:56 -0700 (PDT) Message-ID: Date: Mon, 1 Sep 2008 16:19:56 +0200 From: "Claus Guttesen" To: "Manfred Antar" In-Reply-To: <200809011335.m81DZW8b006033@pozo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200809011335.m81DZW8b006033@pozo.com> Cc: ports@freebsd.org, freebsd-current@freebsd.org Subject: Re: Apache.sh on current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Sep 2008 14:19:59 -0000 > /usr/local/etc/rc.d/apache.sh : > /usr/bin/limits -e -U www > dumps core when starting apache on current > This something new, not sure when it started as I have been out of the Country for the past month. > Kernel and usr are current > Also /usr/local/sbin/apachect : > eval `limits -e -C daemon` > also dumps core Are you using apache and php? -- regards Claus When lenity and cruelty play for a kingdom, the gentler gamester is the soonest winner. Shakespeare From owner-freebsd-current@FreeBSD.ORG Mon Sep 1 14:20:47 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6C1D31065679 for ; Mon, 1 Sep 2008 14:20:47 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from koef.zs64.net (koef.zs64.net [212.12.50.230]) by mx1.freebsd.org (Postfix) with ESMTP id 07F2A8FC3A for ; Mon, 1 Sep 2008 14:20:46 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from localhost by koef.zs64.net (8.14.3/8.14.3) with ESMTP id m81EKZ9g089140 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 1 Sep 2008 16:20:42 +0200 (CEST) (envelope-from stb@lassitu.de) (authenticated as stb) Message-Id: <597586F2-3D3E-4B16-8E20-C3D2B69D25BD@lassitu.de> From: Stefan Bethke To: Alex Goncharov In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v928.1) Date: Mon, 1 Sep 2008 16:20:29 +0200 References: <200809011331.m81DV7pq094904@lurza.secnetix.de> X-Mailer: Apple Mail (2.928.1) Cc: freebsd-current@freebsd.org Subject: Re: named mystery -- error: dumping master file: master/tmp-wTjhUzoix6 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Sep 2008 14:20:47 -0000 Am 01.09.2008 um 15:58 schrieb Alex Goncharov: > | There's no reason that the named process needs write access > | to the master directory. If you use dynamic zone updates, > | you should use the "dynamic" directory for those zones, > | which is writable by bind. > > I just tried a simplistic change: > > a. Changed "type master" to "type dynamic" in named.conf. > > b. cp master/* dynamic There no "dynamic" type. You need to change the file path for the zone from 'file "master/foo.bar"' to 'file "dynamic/foo.bar"'. Maybe reading the Bind Admin Guide or one of the books might be in order? Stefan -- Stefan Bethke Fon +49 170 346 0140 From owner-freebsd-current@FreeBSD.ORG Mon Sep 1 14:36:56 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D07DC1065670; Mon, 1 Sep 2008 14:36:56 +0000 (UTC) (envelope-from null@pozo.com) Received: from pozo.com (pozo.com [216.101.162.50]) by mx1.freebsd.org (Postfix) with ESMTP id AAF3C8FC0C; Mon, 1 Sep 2008 14:36:56 +0000 (UTC) (envelope-from null@pozo.com) Received: from T41p.pozo.com (t41p.pozo.com [192.168.0.4]) (authenticated bits=0) by pozo.com (8.14.3/8.14.3) with ESMTP id m81Eaq2v040141 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 1 Sep 2008 07:36:53 -0700 (PDT) (envelope-from null@pozo.com) Message-Id: <200809011436.m81Eaq2v040141@pozo.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 01 Sep 2008 07:36:47 -0700 To: "Claus Guttesen" From: Manfred Antar In-Reply-To: References: <200809011335.m81DZW8b006033@pozo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, score=-101.4 required=5.0 tests=ALL_TRUSTED,MISSING_MID, USER_IN_WHITELIST autolearn=failed version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on pozo.com X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on pozo.com X-Virus-Status: Clean Cc: ports@freebsd.org, freebsd-current@freebsd.org Subject: Re: Apache.sh on current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Sep 2008 14:36:56 -0000 At 07:19 AM 9/1/2008, Claus Guttesen wrote: >> /usr/local/etc/rc.d/apache.sh : >> /usr/bin/limits -e -U www >> dumps core when starting apache on current >> This something new, not sure when it started as I have been out of the Country for the past month. >> Kernel and usr are current >> Also /usr/local/sbin/apachect : >> eval `limits -e -C daemon` >> also dumps core > >Are you using apache and php? > >-- >regards >Claus > >When lenity and cruelty play for a kingdom, >the gentler gamester is the soonest winner. > >Shakespeare Yes But if I just do limits -e -U root I get a core dump. I don't think the problem is with apache. limits -e -U (Any User) dumps core ================================== || null@pozo.com || || Ph. (415) 681-6235 || ================================== From owner-freebsd-current@FreeBSD.ORG Mon Sep 1 14:53:24 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EAC851065679 for ; Mon, 1 Sep 2008 14:53:24 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.terabit.net.ua (mail.terabit.net.ua [195.137.202.147]) by mx1.freebsd.org (Postfix) with ESMTP id 85D328FC0A for ; Mon, 1 Sep 2008 14:53:24 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from skuns.zoral.com.ua ([91.193.166.194] helo=mail.zoral.com.ua) by mail.terabit.net.ua with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1KaAmQ-000El9-Oy; Mon, 01 Sep 2008 17:53:22 +0300 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m81ErFLr099966 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Sep 2008 17:53:16 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m81ErFAC069798; Mon, 1 Sep 2008 17:53:15 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id m81ErFHn069797; Mon, 1 Sep 2008 17:53:15 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 1 Sep 2008 17:53:15 +0300 From: Kostik Belousov To: Vyacheslav Bocharov Message-ID: <20080901145315.GU2038@deviant.kiev.zoral.com.ua> References: <20080830183804.GG2038@deviant.kiev.zoral.com.ua> <20080830195844.GI2038@deviant.kiev.zoral.com.ua> <20080831071618.GK2038@deviant.kiev.zoral.com.ua> <20080831091639.GM2038@deviant.kiev.zoral.com.ua> <80861bfa0809010733h47580d3evb3eb68c972a2bb25@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="bIK/Xm5bvUaTMa1a" Content-Disposition: inline In-Reply-To: <80861bfa0809010733h47580d3evb3eb68c972a2bb25@mail.gmail.com> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua X-Virus-Scanned: mail.terabit.net.ua 1KaAmQ-000El9-Oy 8a05e145e1118eed93fd03ea43ba523c X-Terabit: YES Cc: freebsd-current@freebsd.org Subject: Re: __tls_get_addr problem with recent current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Sep 2008 14:53:25 -0000 --bIK/Xm5bvUaTMa1a Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Sep 01, 2008 at 05:33:37PM +0300, Vyacheslav Bocharov wrote: > I have similar problem in 7-STABLE (from 1 sep): > 32bit application exec 64application and we have an core dump: >=20 > # gdb fw.sh fw.sh.core > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you = are > welcome to change it and/or distribute copies of it under certain > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for detail= s. > This GDB was configured as "amd64-marcel-freebsd"... > Core was generated by `fw.sh'. > Program terminated with signal 11, Segmentation fault. > Reading symbols from /usr/lib/libstdc++.so.6...done. > Loaded symbols for /usr/lib/libstdc++.so.6 > Reading symbols from /lib/libm.so.5...done. > Loaded symbols for /lib/libm.so.5 > Reading symbols from /lib/libgcc_s.so.1...done. > Loaded symbols for /lib/libgcc_s.so.1 > Reading symbols from /lib/libc.so.7...done. > Loaded symbols for /lib/libc.so.7 > Reading symbols from /libexec/ld-elf.so.1...done. > Loaded symbols for /libexec/ld-elf.so.1 > #0 0x0000000800507483 in __tls_get_addr () from /libexec/ld-elf.so.1 > (gdb) bt > #0 0x0000000800507483 in __tls_get_addr () from /libexec/ld-elf.so.1 > #1 0x0000000800ad8892 in _pthread_mutex_init_calloc_cb () from > /lib/libc.so.7 > #2 0x0000000800ada35f in malloc () from /lib/libc.so.7 > #3 0x00000008007050ad in operator new () from /usr/lib/libstdc++.so.6 > #4 0x00000008006b5f21 in std::string::_Rep::_S_create () > from /usr/lib/libstdc++.so.6 > #5 0x00000008006b6ca5 in std::string::_S_copy_chars () > from /usr/lib/libstdc++.so.6 > #6 0x00000008006b6dc2 in std::basic_string, > std::allocator >::basic_string () from /usr/lib/libstdc++.so.6 > #7 0x00000000004021ec in __static_initialization_and_destruction_0 ( > __initialize_p=3D1, __priority=3D65535) at CCmdLine.cpp:16 > #8 0x00000000004026c3 in global constructors keyed to cmdlist () > at CCmdLine.cpp:177 > #9 0x00000000004033a2 in __do_global_ctors_aux () > #10 0x000000000040113e in _init () > #11 0x0000000800b2b0c0 in __cxa_atexit () from /lib/libc.so.7 > #12 0x00000000004014e8 in _start () > #13 0x000000080052c000 in ?? () >=20 > I tried your patch but nothing changed. Exactly which patch ? There were three, one of which caused immediate panic. I put the patches at http://people.freebsd.org/~kib/misc/fsbase.1.patch http://people.freebsd.org/~kib/misc/fsbase.2.patch Could you, please, try both and report the results ? And, isolated test case, as several C files or recipe to reproduce this with base system, would be ideal. >=20 > 2008/8/31 Kostik Belousov >=20 > > On Sun, Aug 31, 2008 at 10:16:18AM +0300, Kostik Belousov wrote: > > > On Sat, Aug 30, 2008 at 02:03:00PM -0700, Artem Belevich wrote: > > > > With the new patch kernel has crashed as soon as I ran i386 app, > > > > though the crash happened within in-kernel thread g_up: > > > > > > > > Fatal trap 12: page fault while in kernel mode > > > > cpuid =3D 2; apic id =3D 02 > > > > fault virtual address =3D 0x20 > > > > fault code =3D supervisor read data, page not present > > > > instruction pointer =3D 0x8:0xffffffff804a821f > > > > stack pointer =3D 0x10:0xffffffffac280b60 > > > > frame pointer =3D 0x10:0x0 > > > > code segment =3D base 0x0, limit 0xfffff, type 0x1b > > > > =3D DPL 0, pres 1, long 1, def32 0, gran 1 > > > > processor eflags =3D resume, IOPL =3D 0 > > > > current process =3D 3 (g_up) > > > > trap number =3D 12 > > > > panic: page fault > > > > cpuid =3D 2 > > > > Uptime: 37s > > > > Physical memory: 8169 MB > > > > Dumping 380 MB: 365 349 333 317 301 285 269 253 237 221 205 189 173 > > > > 157 141 125 109 93 77 61 45 29 13 > > > Could you, please, show me the disassembled code around the faulted > > > %rip ? > > > > No need, it seems I found the problem. I trashed the %rdx that contains > > the third cpu_switch argument. Please, try the updated patch. > > > > Thanks for the testing ! > > > > diff --git a/sys/amd64/amd64/cpu_switch.S b/sys/amd64/amd64/cpu_switch.S > > index f34b0cc..03f0eca 100644 > > --- a/sys/amd64/amd64/cpu_switch.S > > +++ b/sys/amd64/amd64/cpu_switch.S > > @@ -249,6 +249,12 @@ store_seg: > > 1: movl %ds,PCB_DS(%r8) > > movl %es,PCB_ES(%r8) > > movl %fs,PCB_FS(%r8) > > + movq %rdx,%r11 > > + movl $MSR_FSBASE,%ecx > > + rdmsr > > + shlq $32,%rdx > > + leaq (%rax,%rdx),%r9 > > + movq %r11,%rdx > > jmp done_store_seg > > 2: movq PCB_GS32P(%r8),%rax > > movq (%rax),%rax > > >=20 >=20 >=20 > --=20 > Vyacheslav Bocharov --bIK/Xm5bvUaTMa1a Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEUEARECAAYFAki8AdoACgkQC3+MBN1Mb4inawCYl59qyGdgaNeh1NHS8ClgVXw/ BwCg3i5KZIllKNFpfQ3wJLQFpt7cEyo= =k9RZ -----END PGP SIGNATURE----- --bIK/Xm5bvUaTMa1a-- From owner-freebsd-current@FreeBSD.ORG Mon Sep 1 15:04:50 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 626DE106566B for ; Mon, 1 Sep 2008 15:04:50 +0000 (UTC) (envelope-from adeepv@gmail.com) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.189]) by mx1.freebsd.org (Postfix) with ESMTP id AC6548FC14 for ; Mon, 1 Sep 2008 15:04:49 +0000 (UTC) (envelope-from adeepv@gmail.com) Received: by mu-out-0910.google.com with SMTP id i2so1956028mue.3 for ; Mon, 01 Sep 2008 08:04:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=bnnFDPlrgn8CSXmc43nGpIy+H+y5zudR2ZiAUlq5D4A=; b=H8Uy8oUVfUuB3sWlFYDK6bGTyu81rs11ecpq6/UaG2Uz9/mVG1XcP1jNKBNNvpfUhC rCbC6Ql0yNVrTwme1JpH9khgIeMPnQDklA6+tG+HrBRjt1cG/qQzbPcHR34nN7hmU0bW ikmOGPJMdU88cCJZB1HrFf2CZYff0KFQHQvzI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=alSW30w/BEFNG2GNxlYU378po/DT/OvGfsby2fuOK9GCcEd+WNK3S4IMyEeQyd+qJ5 /xLEBMXtENyKktQ9BeBBmEpCABHbIlG4o6eEeucvCmP9je7dRrVRp/b/GufpLa6AgMf6 us8Vn/xQ9lOUp1M+6BVaxuzaG3hfN0D3oFADg= Received: by 10.103.228.15 with SMTP id f15mr4420927mur.14.1220279617967; Mon, 01 Sep 2008 07:33:37 -0700 (PDT) Received: by 10.102.253.9 with HTTP; Mon, 1 Sep 2008 07:33:37 -0700 (PDT) Message-ID: <80861bfa0809010733h47580d3evb3eb68c972a2bb25@mail.gmail.com> Date: Mon, 1 Sep 2008 17:33:37 +0300 From: "Vyacheslav Bocharov" To: "Kostik Belousov" In-Reply-To: <20080831091639.GM2038@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 References: <20080830183804.GG2038@deviant.kiev.zoral.com.ua> <20080830195844.GI2038@deviant.kiev.zoral.com.ua> <20080831071618.GK2038@deviant.kiev.zoral.com.ua> <20080831091639.GM2038@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: __tls_get_addr problem with recent current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Sep 2008 15:04:50 -0000 I have similar problem in 7-STABLE (from 1 sep): 32bit application exec 64application and we have an core dump: # gdb fw.sh fw.sh.core GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Core was generated by `fw.sh'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/lib/libstdc++.so.6...done. Loaded symbols for /usr/lib/libstdc++.so.6 Reading symbols from /lib/libm.so.5...done. Loaded symbols for /lib/libm.so.5 Reading symbols from /lib/libgcc_s.so.1...done. Loaded symbols for /lib/libgcc_s.so.1 Reading symbols from /lib/libc.so.7...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /libexec/ld-elf.so.1...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x0000000800507483 in __tls_get_addr () from /libexec/ld-elf.so.1 (gdb) bt #0 0x0000000800507483 in __tls_get_addr () from /libexec/ld-elf.so.1 #1 0x0000000800ad8892 in _pthread_mutex_init_calloc_cb () from /lib/libc.so.7 #2 0x0000000800ada35f in malloc () from /lib/libc.so.7 #3 0x00000008007050ad in operator new () from /usr/lib/libstdc++.so.6 #4 0x00000008006b5f21 in std::string::_Rep::_S_create () from /usr/lib/libstdc++.so.6 #5 0x00000008006b6ca5 in std::string::_S_copy_chars () from /usr/lib/libstdc++.so.6 #6 0x00000008006b6dc2 in std::basic_string, std::allocator >::basic_string () from /usr/lib/libstdc++.so.6 #7 0x00000000004021ec in __static_initialization_and_destruction_0 ( __initialize_p=1, __priority=65535) at CCmdLine.cpp:16 #8 0x00000000004026c3 in global constructors keyed to cmdlist () at CCmdLine.cpp:177 #9 0x00000000004033a2 in __do_global_ctors_aux () #10 0x000000000040113e in _init () #11 0x0000000800b2b0c0 in __cxa_atexit () from /lib/libc.so.7 #12 0x00000000004014e8 in _start () #13 0x000000080052c000 in ?? () I tried your patch but nothing changed. 2008/8/31 Kostik Belousov > On Sun, Aug 31, 2008 at 10:16:18AM +0300, Kostik Belousov wrote: > > On Sat, Aug 30, 2008 at 02:03:00PM -0700, Artem Belevich wrote: > > > With the new patch kernel has crashed as soon as I ran i386 app, > > > though the crash happened within in-kernel thread g_up: > > > > > > Fatal trap 12: page fault while in kernel mode > > > cpuid = 2; apic id = 02 > > > fault virtual address = 0x20 > > > fault code = supervisor read data, page not present > > > instruction pointer = 0x8:0xffffffff804a821f > > > stack pointer = 0x10:0xffffffffac280b60 > > > frame pointer = 0x10:0x0 > > > code segment = base 0x0, limit 0xfffff, type 0x1b > > > = DPL 0, pres 1, long 1, def32 0, gran 1 > > > processor eflags = resume, IOPL = 0 > > > current process = 3 (g_up) > > > trap number = 12 > > > panic: page fault > > > cpuid = 2 > > > Uptime: 37s > > > Physical memory: 8169 MB > > > Dumping 380 MB: 365 349 333 317 301 285 269 253 237 221 205 189 173 > > > 157 141 125 109 93 77 61 45 29 13 > > Could you, please, show me the disassembled code around the faulted > > %rip ? > > No need, it seems I found the problem. I trashed the %rdx that contains > the third cpu_switch argument. Please, try the updated patch. > > Thanks for the testing ! > > diff --git a/sys/amd64/amd64/cpu_switch.S b/sys/amd64/amd64/cpu_switch.S > index f34b0cc..03f0eca 100644 > --- a/sys/amd64/amd64/cpu_switch.S > +++ b/sys/amd64/amd64/cpu_switch.S > @@ -249,6 +249,12 @@ store_seg: > 1: movl %ds,PCB_DS(%r8) > movl %es,PCB_ES(%r8) > movl %fs,PCB_FS(%r8) > + movq %rdx,%r11 > + movl $MSR_FSBASE,%ecx > + rdmsr > + shlq $32,%rdx > + leaq (%rax,%rdx),%r9 > + movq %r11,%rdx > jmp done_store_seg > 2: movq PCB_GS32P(%r8),%rax > movq (%rax),%rax > -- Vyacheslav Bocharov From owner-freebsd-current@FreeBSD.ORG Mon Sep 1 15:14:21 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 878D4106566B for ; Mon, 1 Sep 2008 15:14:21 +0000 (UTC) (envelope-from alex-goncharov@comcast.net) Received: from QMTA08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by mx1.freebsd.org (Postfix) with ESMTP id 312E28FC17 for ; Mon, 1 Sep 2008 15:14:20 +0000 (UTC) (envelope-from alex-goncharov@comcast.net) Received: from OMTA03.westchester.pa.mail.comcast.net ([76.96.62.27]) by QMTA08.westchester.pa.mail.comcast.net with comcast id 9Qfc1a00D0bG4ec58TELuN; Mon, 01 Sep 2008 15:14:20 +0000 Received: from daland.home ([24.61.21.4]) by OMTA03.westchester.pa.mail.comcast.net with comcast id 9TEK1a00H05H7zL3PTELsj; Mon, 01 Sep 2008 15:14:20 +0000 X-Authority-Analysis: v=1.0 c=1 a=aVV7_ef_2ZQA:10 a=y3Be58pVqgkA:10 a=rITDv7nW5hcA:10 a=W39awwjPDwUKrvW531MA:9 a=OiDF6X2pRF-60hE7uNKU5btG2GgA:4 a=si9q_4b84H0A:10 a=mhQ4J5QMNLoA:10 Received: from algo by daland.home with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KaB6h-0006LK-Hu; Mon, 01 Sep 2008 11:14:19 -0400 From: Alex Goncharov To: Stefan Bethke In-reply-to: <597586F2-3D3E-4B16-8E20-C3D2B69D25BD@lassitu.de> (message from Stefan Bethke on Mon, 1 Sep 2008 16:20:29 +0200) References: <200809011331.m81DV7pq094904@lurza.secnetix.de> <597586F2-3D3E-4B16-8E20-C3D2B69D25BD@lassitu.de> Message-Id: Sender: Alex Goncharov Date: Mon, 01 Sep 2008 11:14:19 -0400 Cc: freebsd-current@freebsd.org Subject: Re: named mystery -- error: dumping master file: master/tmp-wTjhUzoix6 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Goncharov List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Sep 2008 15:14:21 -0000 ,--- You/Stefan (Mon, 1 Sep 2008 16:20:29 +0200) ----* | | Am 01.09.2008 um 15:58 schrieb Alex Goncharov: | | > | There's no reason that the named process needs write access | > | to the master directory. If you use dynamic zone updates, | > | you should use the "dynamic" directory for those zones, | > | which is writable by bind. | > | > I just tried a simplistic change: | > | > a. Changed "type master" to "type dynamic" in named.conf. | > | > b. cp master/* dynamic | | There no "dynamic" type. You need to change the file path for the | zone from 'file "master/foo.bar"' to 'file "dynamic/foo.bar"'. Oh thank you -- why didn't I think of doing that?.. | Maybe reading the Bind Admin Guide or one of the books might be in There is no question about it: I think I've done adequate reading and will likely take a look at the Guide again, to see if this situation and your resolution are described there. By my recollection, it is not (BIND FAQ discusses permissions for `sl' -- the slave directory, but this is not the same as "master".) Do you think it is? Now, how does the argument that master zones should not be dynamically updatable, and `bind' must not have write permissions over the directory keeping the master zone files -- how does this live with your resolution to my problem? I am quite happy to accept it (if down the road nothing is going to "chown root dynamic") but I don't see much sense in doing this trick -- my master zone files are as vulnerable now as if they lived under `master' and the conceptual structure of the system seems worse to me: after all, what now lives under `dynamic' is a "master" zone (marked as such in `named.conf'). Thanks a lot for the help, anyway! -- Alex -- alex-goncharov@comcast.net -- From owner-freebsd-current@FreeBSD.ORG Mon Sep 1 16:08:38 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C8E0C106566B for ; Mon, 1 Sep 2008 16:08:38 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from vlakno.cz (vlk.vlakno.cz [62.168.28.247]) by mx1.freebsd.org (Postfix) with ESMTP id 809328FC20 for ; Mon, 1 Sep 2008 16:08:38 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from localhost (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 1B21D65B588; Mon, 1 Sep 2008 18:08:55 +0200 (CEST) X-Virus-Scanned: amavisd-new at vlakno.cz Received: from vlakno.cz ([127.0.0.1]) by localhost (vlk.vlakno.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c3fVvxf6nEwr; Mon, 1 Sep 2008 18:08:45 +0200 (CEST) Received: from vlk.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 1BF3B65B479; Mon, 1 Sep 2008 18:08:45 +0200 (CEST) Received: (from rdivacky@localhost) by vlk.vlakno.cz (8.14.2/8.14.2/Submit) id m81G8iWg056897; Mon, 1 Sep 2008 18:08:44 +0200 (CEST) (envelope-from rdivacky) Date: Mon, 1 Sep 2008 18:08:44 +0200 From: Roman Divacky To: Alexey Shuvaev Message-ID: <20080901160844.GA56657@freebsd.org> References: <48BAD085.1090507@gmail.com> <20080831200950.GF99951@hoeg.nl> <871w04syfw.fsf@kobe.laptop> <20080901101121.GC4083@wep400x.physik.uni-wuerzburg.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080901101121.GC4083@wep400x.physik.uni-wuerzburg.de> User-Agent: Mutt/1.4.2.3i Cc: Ed Schouten , freebsd-current@freebsd.org Subject: Re: csh history and pts X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Sep 2008 16:08:38 -0000 > Back to original post, I confirm that [t]csh loses history after shutdown(8). might be completely irrelevant but tcsh on linux loses history for me as well :) From owner-freebsd-current@FreeBSD.ORG Mon Sep 1 17:17:34 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4061A1065688 for ; Mon, 1 Sep 2008 17:17:34 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (unknown [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id 9D5158FC21 for ; Mon, 1 Sep 2008 17:17:33 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.2/8.14.2) with ESMTP id m81HHPHt005178; Mon, 1 Sep 2008 19:17:26 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.2/8.14.2/Submit) id m81HHPLO005177; Mon, 1 Sep 2008 19:17:25 +0200 (CEST) (envelope-from olli) Date: Mon, 1 Sep 2008 19:17:25 +0200 (CEST) Message-Id: <200809011717.m81HHPLO005177@lurza.secnetix.de> From: Oliver Fromme To: freebsd-current@FreeBSD.ORG, Alex Goncharov In-Reply-To: X-Newsgroups: list.freebsd-current User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.3-STABLE (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Mon, 01 Sep 2008 19:17:27 +0200 (CEST) Cc: Subject: Re: named mystery -- error: dumping master file: ?master/tmp-wTjhUzoix6 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-current@FreeBSD.ORG, Alex Goncharov List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Sep 2008 17:17:34 -0000 Alex Goncharov wrote: > There is no question about it: I think I've done adequate reading and > will likely take a look at the Guide again, to see if this situation > and your resolution are described there. By my recollection, it is > not (BIND FAQ discusses permissions for `sl' -- the slave directory, > but this is not the same as "master".) Do you think it is? Forget the FAQ. You should read the ARM (Administrator Reference Manual), especially the section on dynamic updates. Of course bind must be able to write to the "slave" and "dynamic" directory, so it is able to store slave zones and dynamic updates. There is no reason that bind needs write access to static master zone files, because, well, they're static. > Now, how does the argument that master zones should not be dynamically > updatable, and `bind' must not have write permissions over the > directory keeping the master zone files -- how does this live with > your resolution to my problem? I am quite happy to accept it (if down > the road nothing is going to "chown root dynamic") but I don't see > much sense in doing this trick -- my master zone files are as > vulnerable now as if they lived under `master' and the conceptual > structure of the system seems worse to me: after all, what now lives > under `dynamic' is a "master" zone (marked as such in `named.conf'). Yes, of course, there are static master zones and dynamic master zones. They all are really master zones, the only difference is that the dynamic ones have been enabled for dynamic updates. This is often used for dynamic clients in internal networks or VPNs. The static zones live in the "master" directory, and the dynamic ones live in the "dynamic" directory. Some people advise against serving both static (public) and dynamic (internal) master zones from the same server. That's precisely for the security reason you mentioned: If an external attacker could gain access to your named via an exploit, he could manipulate your dynamic zones (though not your static ones if permissions are configured correctly). Therefore it might be a good idea to serve static and dynamic zones from different named instances in separate jails that are bound to appropriate (public vs. internal) IP addresses. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "Whatever happened to the days when hacking started at the cerebral cortex, and not at the keyboard?" -- Sid on userfriendly.org by Illiad, 2007-06-20 From owner-freebsd-current@FreeBSD.ORG Mon Sep 1 17:40:00 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B3F1E1065682 for ; Mon, 1 Sep 2008 17:40:00 +0000 (UTC) (envelope-from alex-goncharov@comcast.net) Received: from QMTA07.emeryville.ca.mail.comcast.net (qmta07.emeryville.ca.mail.comcast.net [76.96.30.64]) by mx1.freebsd.org (Postfix) with ESMTP id 94CE18FC08 for ; Mon, 1 Sep 2008 17:40:00 +0000 (UTC) (envelope-from alex-goncharov@comcast.net) Received: from OMTA02.emeryville.ca.mail.comcast.net ([76.96.30.19]) by QMTA07.emeryville.ca.mail.comcast.net with comcast id 9SUZ1a00X0QkzPwA7Vg0bY; Mon, 01 Sep 2008 17:40:00 +0000 Received: from daland.home ([24.61.21.4]) by OMTA02.emeryville.ca.mail.comcast.net with comcast id 9Vfy1a00605H7zL8NVfzwe; Mon, 01 Sep 2008 17:39:59 +0000 X-Authority-Analysis: v=1.0 c=1 a=MOE8-hbERY8A:10 a=y3Be58pVqgkA:10 a=rITDv7nW5hcA:10 a=w4t_P5V44vApi16t8q0A:9 a=k13AldOkiX_SSz5Vg0O2TuSK7hgA:4 a=si9q_4b84H0A:10 a=mhQ4J5QMNLoA:10 Received: from algo by daland.home with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KaDNd-0005he-UV for freebsd-current@FreeBSD.ORG; Mon, 01 Sep 2008 13:39:57 -0400 From: Alex Goncharov To: freebsd-current@FreeBSD.ORG In-reply-to: <200809011717.m81HHPLO005177@lurza.secnetix.de> (message from Oliver Fromme on Mon, 1 Sep 2008 19:17:25 +0200 (CEST)) References: <200809011717.m81HHPLO005177@lurza.secnetix.de> Message-Id: Sender: Alex Goncharov Date: Mon, 01 Sep 2008 13:39:57 -0400 Cc: Subject: Re: named mystery -- error: dumping master file: ?master/tmp-wTjhUzoix6 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Goncharov List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Sep 2008 17:40:00 -0000 ,--- Oliver Fromme (Mon, 1 Sep 2008 19:17:25 +0200 (CEST)) ----* | Forget the FAQ. You should read the ARM (Administrator | Reference Manual), especially the section on dynamic | updates. Thanks -- I will most certainly do it! | The static zones live in the "master" directory, and the | dynamic ones live in the "dynamic" directory. | | Some people advise against serving both static (public) and dynamic | (internal) master zones from the same server. That's precisely for | the security reason you mentioned: If an external attacker could | gain access to your named via an exploit, he could manipulate your | dynamic zones (though not your static ones if permissions are | configured correctly). Therefore it might be a good idea to serve | static and dynamic zones from different named instances in separate | jails that are bound to appropriate (public vs. internal) IP | addresses. In most environments I've been, including my home environment, the idea that static and DHCP addresses have to be in different zones, and/or be served by various DNS servers, would not be met enthusiastically and probably would not fly at all. At home, I have some static addresses and the rest is DHCP-assigned -- all in one zone. Having two zones to accommodate a couple of static addresses for the servers doesn't sound like a good idea to me. Thank you for your excellent explanations -- I just learned something valuable and now know what I have to read. -- Alex -- alex-goncharov@comcast.net -- From owner-freebsd-current@FreeBSD.ORG Mon Sep 1 19:49:56 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2760A1065670 for ; Mon, 1 Sep 2008 19:49:56 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx24.fluidhosting.com [204.14.89.7]) by mx1.freebsd.org (Postfix) with ESMTP id 9C5BE8FC18 for ; Mon, 1 Sep 2008 19:49:55 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 30117 invoked by uid 399); 1 Sep 2008 19:21:54 -0000 Received: from localhost (HELO lap.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 1 Sep 2008 19:21:54 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <48BC40D0.6070107@FreeBSD.org> Date: Mon, 01 Sep 2008 12:21:52 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.16 (X11/20080726) MIME-Version: 1.0 To: Alex Goncharov References: <200809011331.m81DV7pq094904@lurza.secnetix.de> <597586F2-3D3E-4B16-8E20-C3D2B69D25BD@lassitu.de> In-Reply-To: X-Enigmail-Version: 0.95.7 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: named mystery -- error: dumping master file: master/tmp-wTjhUzoix6 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Sep 2008 19:49:56 -0000 Alex Goncharov wrote: > Now, how does the argument that master zones should not be dynamically > updatable, and `bind' must not have write permissions over the > directory keeping the master zone files -- how does this live with > your resolution to my problem? The distinction between namedb/master and namedb/dynamic is somewhat artificial, and if I had it to do over from the beginning I would rename "master" to "static." However the master directory has been there since basically day 1, and I added the dynamic directory after severely tightening down the permissions in the etc/namedb directory when moving to the chroot defaults. Thus the confusion you are experiencing is related to the fact that zones which are dynamically updated are "master" zones, but because the bind user needs to write to them in our directory structure they need to live in etc/namedb/dynamic. As someone else pointed out drawing this distinction is a good thing, since you want the bind user to have write access to as little as possible for security reasons. > my master zone files are as vulnerable now as if they lived under `master' Yes, because you were previously chowning the master directory. If you have an environment where you have a mixture of static master zones and dynamic master zones the distinction is meaningful. hope this helps, Doug -- This .signature sanitized for your protection From owner-freebsd-current@FreeBSD.ORG Sun Aug 31 23:16:43 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 77B001065672 for ; Sun, 31 Aug 2008 23:16:43 +0000 (UTC) (envelope-from bounces@nabble.com) Received: from kuber.nabble.com (kuber.nabble.com [216.139.236.158]) by mx1.freebsd.org (Postfix) with ESMTP id 4E5128FC15 for ; Sun, 31 Aug 2008 23:16:43 +0000 (UTC) (envelope-from bounces@nabble.com) Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1KZvv6-0000PG-5t for freebsd-current@freebsd.org; Sun, 31 Aug 2008 16:01:20 -0700 Message-ID: <19247018.post@talk.nabble.com> Date: Sun, 31 Aug 2008 16:01:20 -0700 (PDT) From: rocketboy811 To: freebsd-current@freebsd.org In-Reply-To: <48516BC1.9060904@math.missouri.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: rocketboy811@gmail.com References: <48516BC1.9060904@math.missouri.edu> X-Mailman-Approved-At: Tue, 02 Sep 2008 02:35:35 +0000 Subject: Re: Marvell Yukon 2 88E8040 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Aug 2008 23:16:43 -0000 not to sound like an idiot, but how do you go about putting this code into the system? -- View this message in context: http://www.nabble.com/Marvell-Yukon-2-88E8040-tp17807287p19247018.html Sent from the freebsd-current mailing list archive at Nabble.com. From owner-freebsd-current@FreeBSD.ORG Mon Sep 1 01:37:43 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F0C9C106568C for ; Mon, 1 Sep 2008 01:37:43 +0000 (UTC) (envelope-from army.of.root@googlemail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.152]) by mx1.freebsd.org (Postfix) with ESMTP id 8131A8FC1C for ; Mon, 1 Sep 2008 01:37:43 +0000 (UTC) (envelope-from army.of.root@googlemail.com) Received: by fg-out-1718.google.com with SMTP id l26so1115423fgb.35 for ; Sun, 31 Aug 2008 18:37:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:content-type :content-transfer-encoding; bh=oYDs/F5hRlkieTCM43pD8GGeGokqtjFjTACR//++Jxs=; b=iiLUVa6K4hL3tkXZrLZIDq6u3nX5zhjat7/R783MAOSeJe7Vr35p5TeLqkhOXEAqau YaBDwhym5YlV5VqkG45YKAF2s4y3Iv+71A3H0Vf+8EiooAkEyH4yKkPVAg2p0KSLWzB+ d+ggRZ+ELhHd+zGlRhoIEtmXg3eD2U/+pJGlc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :content-type:content-transfer-encoding; b=cgD5vlsCDfT2LOEFn3+i8Mf9NK4F1TRbkD9zT/jhyzdkQG5QPt2AAIMPzoaeleoD9h waHx5Nm2SOV6Rs/Q04a8Ow5MO9uZnXeHdEKwKJ6opaqcHZur1ZriUO+RhGLwO3OY0p9f 0m+duvnUw7KSDAOn9dy5CFwceBSmDbA4C4bCE= Received: by 10.86.60.15 with SMTP id i15mr4136293fga.14.1220231230232; Sun, 31 Aug 2008 18:07:10 -0700 (PDT) Received: from ?192.168.2.18? ( [84.134.242.148]) by mx.google.com with ESMTPS id l12sm5938772fgb.6.2008.08.31.18.07.08 (version=SSLv3 cipher=RC4-MD5); Sun, 31 Aug 2008 18:07:09 -0700 (PDT) Message-ID: <48BB403C.5090103@googlemail.com> Date: Mon, 01 Sep 2008 03:07:08 +0200 From: "army.of.root@googlemail.com" User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Rui Paulo Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 02 Sep 2008 02:40:18 +0000 Cc: freebsd-current@FreeBSD.org Subject: k8temp choose the higher temp of the two sensors on one core X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Sep 2008 01:37:44 -0000 Hi, I noticed that not the highest of the two temp values of one core is used: dev.cpu.0.temperature: 46 dev.cpu.1.temperature: 46 <== dev.k8temp.0.%desc: AMD K8 Thermal Sensors dev.k8temp.0.%driver: k8temp dev.k8temp.0.%parent: hostb3 dev.k8temp.0.sensor0.core0: 46 dev.k8temp.0.sensor0.core1: 49 <== dev.k8temp.0.sensor1.core0: 46 dev.k8temp.0.sensor1.core1: 46 I assume the dev.cpu.1.temperature sysctl comes from the k8temp module, because it only shows up if it is loaded. Thanks for the great module ! From owner-freebsd-current@FreeBSD.ORG Mon Sep 1 18:04:21 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8BC8C106567B for ; Mon, 1 Sep 2008 18:04:21 +0000 (UTC) (envelope-from naylor.b.david@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by mx1.freebsd.org (Postfix) with ESMTP id 12D228FC18 for ; Mon, 1 Sep 2008 18:04:20 +0000 (UTC) (envelope-from naylor.b.david@gmail.com) Received: by ey-out-2122.google.com with SMTP id 6so794281eyi.7 for ; Mon, 01 Sep 2008 11:04:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:organization:to:subject :date:user-agent:mime-version:content-type:content-transfer-encoding :message-id; bh=W4AlWK3GXZNw3w8I/fsjeeaxlkiceN4tn+3+RSMu0ms=; b=bGOT9Yp1J7SHxu3lMWfK0ZnPOJvuOl/f7V/kJQMtLqcfukUXcQviXjyod+c75xymN+ tNx3w7B/5ajC54GX394NeEe/+Y3fgvuP/AGAXXMNr6ST43/Ieo+BhsXa9mBzSIwmXbD0 gtGQ2N2ciD320U3bxSvi1eqlClbY7TiFR/Z3Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:organization:to:subject:date:user-agent:mime-version :content-type:content-transfer-encoding:message-id; b=ak4nEs+t9dm0Vv8c3MNaCsBlqV5LnQMaO2EeW4IDbXLJBOODpjC3XZCox72AJfM9+3 DCWqbDspwzWq/BOO2hD92bCtBAWsNsDKOxsCH8uz3eVsLvwKzbfphjgdngRFNoX1D8rM 9gZpz6z9jewDvLCT0KlwzFvo0wyZm+daphAsc= Received: by 10.210.90.10 with SMTP id n10mr6862523ebb.115.1220292259754; Mon, 01 Sep 2008 11:04:19 -0700 (PDT) Received: from ?0.0.0.0? ( [196.34.241.123]) by mx.google.com with ESMTPS id f13sm14199590gvd.10.2008.09.01.11.04.15 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 01 Sep 2008 11:04:18 -0700 (PDT) From: David Naylor Organization: Private To: freebsd-current@freebsd.org Date: Mon, 1 Sep 2008 19:21:36 +0200 User-Agent: KMail/1.9.7 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2707132.nVE3c2aNbb"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200809011921.40737.naylor.b.david@gmail.com> X-Mailman-Approved-At: Tue, 02 Sep 2008 02:41:04 +0000 Subject: powerd and multicore X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Sep 2008 18:04:21 -0000 --nextPart2707132.nVE3c2aNbb Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, The way I understand powerd works by default is that it monitors the CPU us= age=20 (or idleness) and changes the CPU frequency accordingly. The default value= s=20 are >95% idle =3D> decrease frequency; <65% idle =3D> increase frequency. = =20 The problem arises when you have a system with 4 or more 'cores'. In this= =20 case the first CPU can be running flat out but still report an overall=20 idleness of 75% and thus the frequency is not increased even though the fir= st=20 core could easily be stuck, at say 200 when capable of 2400. =20 Should powerd be changed to look at CPU specific usage and adjust according= ly=20 or scale the above defaults according to the number of CPU's. =20 =46urthermore, currently (with core 2) all CPU's are controlled using a sin= gle=20 value however (I think) it is possible to have each CPU running on a=20 different frequency (and at least with some other architectures). Does=20 powerd handle these cases? Regards=20 David P.S. sysctl dev.cpu.0.freq=3D2400 complains about an invalid argument yet=20 adjusts the value accordingly. Is this know or should I file a PR. =20 P.P.S. Should the above be filed as a PR? P.P.P.S. Willing to test patches :-) P.P.P.P.S. This is the last one :-> --nextPart2707132.nVE3c2aNbb Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQBIvCSkUaaFgP9pFrIRAo+WAJ9kaje0g3R7sMy6GcYmnaiUgM/HiwCeK1rs lP+P3/k/5pJG06CIzmIkDpY= =vgYM -----END PGP SIGNATURE----- --nextPart2707132.nVE3c2aNbb-- From owner-freebsd-current@FreeBSD.ORG Tue Sep 2 02:56:34 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7886F106564A for ; Tue, 2 Sep 2008 02:56:34 +0000 (UTC) (envelope-from stephen@math.missouri.edu) Received: from cauchy.math.missouri.edu (cauchy.math.missouri.edu [128.206.184.213]) by mx1.freebsd.org (Postfix) with ESMTP id 150CD8FC1A for ; Tue, 2 Sep 2008 02:56:33 +0000 (UTC) (envelope-from stephen@math.missouri.edu) Received: from laptop3.gateway.2wire.net (cauchy.math.missouri.edu [128.206.184.213]) by cauchy.math.missouri.edu (8.14.2/8.14.2) with ESMTP id m822i0gR065577; Mon, 1 Sep 2008 21:44:00 -0500 (CDT) (envelope-from stephen@math.missouri.edu) Message-ID: <48BCA883.4050405@math.missouri.edu> Date: Mon, 01 Sep 2008 21:44:19 -0500 From: Stephen Montgomery-Smith User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.1.16) Gecko/20080829 SeaMonkey/1.1.11 MIME-Version: 1.0 To: rocketboy811 References: <48516BC1.9060904@math.missouri.edu> <19247018.post@talk.nabble.com> In-Reply-To: <19247018.post@talk.nabble.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Marvell Yukon 2 88E8040 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2008 02:56:34 -0000 rocketboy811 wrote: > not to sound like an idiot, but how do you go about putting this code into > the system? Get the latest version from http://people.freebsd.org/~yongari/msk/. Then cd /usr/src patch < /whereever_it_is/msk.88E8040.patch8 Then do whatever you usually do to build the kernel. I tried patch7 a while back, and it didn't work for me. But maybe it will work for you. If it doesn't work, back it out with patch -R < /whereever_it_is/msk.88E8040.patch8 From owner-freebsd-current@FreeBSD.ORG Tue Sep 2 03:53:28 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 57E6C1065683 for ; Tue, 2 Sep 2008 03:53:28 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.224]) by mx1.freebsd.org (Postfix) with ESMTP id 1DC4E8FC08 for ; Tue, 2 Sep 2008 03:53:27 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so2949753rvf.43 for ; Mon, 01 Sep 2008 20:53:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from :to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=V7fPt4tQqVr5qW3sxWHdVKRkK9vP2n6S+i9zyRFp738=; b=U0e/GmRyzx12b6KV37/d6Pz8BdrUDYfVumgn1Zj89KjQOBz623Nkq5oWsIjMoiycL2 /fpQhVsmiZxxioz1u8S8KDUR1F+6LkWSqPFNHMuI+K/43VOBz55qgBGCPTIhjA1Yhg9g 5EzH7RxJZiaOfqVI1BS094Kyoa+4tNEf9SGho= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=otzsfcA585w7XNSLCy1G9/Nj6x1RZoB2QP3DWwYSe8yPeySt6guhfRuaRX2Ek40xM/ BhMSEmHcvn8EkbLHCNWL0gwHOl8dVklIGI1hLmdPVg81u+2Kvn7s4APDAjRJXkngqTl+ JfGmob46dPJFBngOCcMn5GEq8VgaM5y7rvN48= Received: by 10.141.198.9 with SMTP id a9mr3866861rvq.108.1220327607481; Mon, 01 Sep 2008 20:53:27 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTPS id g31sm11847744rvb.7.2008.09.01.20.53.24 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 01 Sep 2008 20:53:26 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id m823rLWv053300 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Sep 2008 12:53:21 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id m823rKfe053299; Tue, 2 Sep 2008 12:53:20 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Tue, 2 Sep 2008 12:53:20 +0900 From: Pyun YongHyeon To: Stephen Montgomery-Smith Message-ID: <20080902035320.GH48568@cdnetworks.co.kr> References: <48516BC1.9060904@math.missouri.edu> <19247018.post@talk.nabble.com> <48BCA883.4050405@math.missouri.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48BCA883.4050405@math.missouri.edu> User-Agent: Mutt/1.4.2.1i Cc: rocketboy811 , freebsd-current@freebsd.org Subject: Re: Marvell Yukon 2 88E8040 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2008 03:53:28 -0000 On Mon, Sep 01, 2008 at 09:44:19PM -0500, Stephen Montgomery-Smith wrote: > rocketboy811 wrote: > >not to sound like an idiot, but how do you go about putting this code into > >the system? > > Get the latest version from http://people.freebsd.org/~yongari/msk/. > > Then > > cd /usr/src > patch < /whereever_it_is/msk.88E8040.patch8 > > Then do whatever you usually do to build the kernel. > > I tried patch7 a while back, and it didn't work for me. But maybe it > will work for you. > Unfortunately it still doesn't work. :-( > If it doesn't work, back it out with > > patch -R < /whereever_it_is/msk.88E8040.patch8 -- Regards, Pyun YongHyeon From owner-freebsd-current@FreeBSD.ORG Tue Sep 2 06:02:06 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E47DE1065674; Tue, 2 Sep 2008 06:02:06 +0000 (UTC) (envelope-from Yuriy.Tsibizov@gfk.com) Received: from mx2.gfk.ru (mx2.gfk.ru [84.21.231.139]) by mx1.freebsd.org (Postfix) with ESMTP id 1E0558FC0C; Tue, 2 Sep 2008 06:02:05 +0000 (UTC) (envelope-from Yuriy.Tsibizov@gfk.com) Received: from ex.hhp.local by mx2.gfk.ru (MDaemon PRO v9.6.0) with ESMTP id md50001761858.msg; Tue, 02 Sep 2008 09:51:36 +0400 Received: from bootserv.hhp.local ([10.0.0.54]) by ex.hhp.local with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Sep 2008 09:51:32 +0400 Date: Tue, 2 Sep 2008 09:53:11 +0400 (MSD) From: Yuriy Tsibizov X-X-Sender: chibis@atwork.home.local To: Manfred Antar In-Reply-To: <200809011436.m81Eaq2v040141@pozo.com> Message-ID: <20080902095229.Y1605@atwork.home.local> References: <200809011335.m81DZW8b006033@pozo.com> <200809011436.m81Eaq2v040141@pozo.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 02 Sep 2008 05:51:32.0979 (UTC) FILETIME=[F410AC30:01C90CBF] X-Spam-Processed: mx2.gfk.ru, Tue, 02 Sep 2008 09:51:36 +0400 (not processed: message from valid local sender) X-MDRemoteIP: 10.0.0.30 X-Return-Path: Yuriy.Tsibizov@gfk.com X-Envelope-From: Yuriy.Tsibizov@gfk.com X-MDAV-Processed: mx2.gfk.ru, Tue, 02 Sep 2008 09:51:37 +0400 Cc: ports@freebsd.org, Yuriy.Tsibizov@gfk.ru, freebsd-current@freebsd.org, Claus Guttesen Subject: /usr/bin/limits (WAS: Re: Apache.sh on current) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2008 06:02:07 -0000 On Mon, 1 Sep 2008, Manfred Antar wrote: > At 07:19 AM 9/1/2008, Claus Guttesen wrote: >>> /usr/local/etc/rc.d/apache.sh : >>> /usr/bin/limits -e -U www >>> dumps core when starting apache on current >>> This something new, not sure when it started as I have been out of the Country for the past month. >>> Kernel and usr are current >>> Also /usr/local/sbin/apachect : >>> eval `limits -e -C daemon` >>> also dumps core >> >> Are you using apache and php? >> >> -- >> regards >> Claus >> >> When lenity and cruelty play for a kingdom, >> the gentler gamester is the soonest winner. >> >> Shakespeare > > Yes > But if I just do limits -e -U root I get a core dump. > I don't think the problem is with apache. > limits -e -U (Any User) dumps core It's not apache problem. There was new limit added to kernel, and /usr/src/usr.bin/limits was not updated. looking in limits core (lines are a bit different, I had some debug printfs in .c file): (gdb) bt #0 0x00000000 in ?? () #1 0x0804937d in main (argc=3, argv=0xbfbfed44) at /usr/src/usr.bin/limits/limits.c:341 (gdb) l 341 val = resources[rcswhich].func(lc, resources[rcswhich].cap, limits[rcswhich].rlim_cur, limits[rcswhich].rlim_cur); 342 limits[rcswhich].rlim_cur = resources[rcswhich].func(lc, str, val, val); 343 /* maximum value overridden by resourcename or resourcename-max */ 344 sprintf(str, "%s-max", resources[rcswhich].cap); 345 val = resources[rcswhich].func(lc, resources[rcswhich].cap, limits[rcswhich].rlim_max, limits[rcswhich].rlim_max); 346 limits[rcswhich].rlim_max = resources[rcswhich].func(lc, str, val, val); 347 } 348 } 349 } 350 (gdb) p resources $1 = {{cap = 0x804adc2 "cputime", func = 0x8048c84 }, { cap = 0x804adca "filesize", func = 0x8048c34 }, { cap = 0x804add3 "datasize", func = 0x8048c34 }, { cap = 0x804addc "stacksize", func = 0x8048c34 }, { cap = 0x804ade6 "coredumpsize", func = 0x8048c34 },{ cap = 0x804adf3 "memoryuse", func = 0x8048c34 }, { cap = 0x804adfd "memorylocked", func = 0x8048c34 },{ cap = 0x804ae0a "maxproc", func = 0x8048c94 }, { cap = 0x804ae12 "openfiles", func = 0x8048c94 }, { cap = 0x804ae1c "sbsize", func = 0x8048c34 }, { cap = 0x804ae23 "vmemoryuse", func = 0x8048c34 }, { cap = 0x0, func = 0}} And limits dies when processing last limit. Yuriy Tsibizov, GfK RUS Network Administrator p.s. Please keep me in CC. From owner-freebsd-current@FreeBSD.ORG Tue Sep 2 06:30:19 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CD31910656C1; Tue, 2 Sep 2008 06:30:19 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:610:652::211]) by mx1.freebsd.org (Postfix) with ESMTP id 6E2838FC1E; Tue, 2 Sep 2008 06:30:18 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id BECCB1CC40; Tue, 2 Sep 2008 08:30:16 +0200 (CEST) Date: Tue, 2 Sep 2008 08:30:16 +0200 From: Ed Schouten To: Yuriy Tsibizov Message-ID: <20080902063016.GK99951@hoeg.nl> References: <200809011335.m81DZW8b006033@pozo.com> <200809011436.m81Eaq2v040141@pozo.com> <20080902095229.Y1605@atwork.home.local> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="CthBKbHMLuDDTcy3" Content-Disposition: inline In-Reply-To: <20080902095229.Y1605@atwork.home.local> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: ports@freebsd.org, FreeBSD Current , Claus Guttesen Subject: Re: /usr/bin/limits (WAS: Re: Apache.sh on current) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2008 06:30:19 -0000 --CthBKbHMLuDDTcy3 Content-Type: multipart/mixed; boundary="MKa19fad5K0Qqc8o" Content-Disposition: inline --MKa19fad5K0Qqc8o Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Yuriy Tsibizov wrote: > (gdb) bt > #0 0x00000000 in ?? () > #1 0x0804937d in main (argc=3D3, argv=3D0xbfbfed44) > at /usr/src/usr.bin/limits/limits.c:341 > (gdb) l > 341 val =3D resources[rcswhich].func(lc, resources[rcswhich].cap, li= mits[rcswhich].rlim_cur, limits[rcswhich].rlim_cur); > 342 limits[rcswhich].rlim_cur =3D resources[rcswhich].func(lc, str, = val, val); > 343 /* maximum value overridden by resourcename or resourcename-max = */ > 344 sprintf(str, "%s-max", resources[rcswhich].cap); > 345 val =3D resources[rcswhich].func(lc, resources[rcswhich].cap, li= mits[rcswhich].rlim_max, limits[rcswhich].rlim_max); > 346 limits[rcswhich].rlim_max =3D resources[rcswhich].func(lc, str, = val, val); > 347 } > 348 } > 349 } > 350 > (gdb) p resources > $1 =3D {{cap =3D 0x804adc2 "cputime", func =3D 0x8048c84 }, { > cap =3D 0x804adca "filesize", func =3D 0x8048c34 }= , { > cap =3D 0x804add3 "datasize", func =3D 0x8048c34 }= , { > cap =3D 0x804addc "stacksize", func =3D 0x8048c34 = }, { > cap =3D 0x804ade6 "coredumpsize", func =3D 0x8048c34 },{ > cap =3D 0x804adf3 "memoryuse", func =3D 0x8048c34 = }, { > cap =3D 0x804adfd "memorylocked", func =3D 0x8048c34 },{ > cap =3D 0x804ae0a "maxproc", func =3D 0x8048c94 }, { > cap =3D 0x804ae12 "openfiles", func =3D 0x8048c94 }= , { > cap =3D 0x804ae1c "sbsize", func =3D 0x8048c34 }, { > cap =3D 0x804ae23 "vmemoryuse", func =3D 0x8048c34 }, { > cap =3D 0x0, func =3D 0}} Looks like I introduced this regression when importing MPSAFE TTY. limits(1) dies when RLIMIT_NLIMITS is increased, but the array in limits.c isn't extended (seems to be quite fragile). Can you try the attached patch for limits(1)? Thanks! --=20 Ed Schouten WWW: http://80386.nl/ --MKa19fad5K0Qqc8o Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="limits.diff" Content-Transfer-Encoding: quoted-printable --- limits.c +++ limits.c @@ -76,17 +76,18 @@ { { "", "infinity", "Resource limits%s%s:\n", "-max", "-cur", "", { - { " cputime%-4s %8s", " secs\n", 1 }, - { " filesize%-4s %8s", " kB\n", 1024 }, - { " datasize%-4s %8s", " kB\n", 1024 }, - { " stacksize%-4s %8s", " kB\n", 1024 }, - { " coredumpsize%-4s %8s", " kB\n", 1024 }, - { " memoryuse%-4s %8s", " kB\n", 1024 }, - { " memorylocked%-4s %8s", " kB\n", 1024 }, - { " maxprocesses%-4s %8s", "\n", 1 }, - { " openfiles%-4s %8s", "\n", 1 }, - { " sbsize%-4s %8s", " bytes\n", 1 }, - { " vmemoryuse%-4s %8s", " kB\n", 1024 } + { " cputime%-4s %8s", " secs\n", 1 }, + { " filesize%-4s %8s", " kB\n", 1024 }, + { " datasize%-4s %8s", " kB\n", 1024 }, + { " stacksize%-4s %8s", " kB\n", 1024 }, + { " coredumpsize%-4s %8s", " kB\n", 1024 }, + { " memoryuse%-4s %8s", " kB\n", 1024 }, + { " memorylocked%-4s %8s", " kB\n", 1024 }, + { " maxprocesses%-4s %8s", "\n", 1 }, + { " openfiles%-4s %8s", "\n", 1 }, + { " sbsize%-4s %8s", " bytes\n", 1 }, + { " vmemoryuse%-4s %8s", " kB\n", 1024 }, + { " pseudo-terminals%-4s %8s", "\n", 1 } } }, { "sh", "unlimited", "", " -H", " -S", "", @@ -101,22 +102,24 @@ { "ulimit%s -u %s", ";\n", 1 }, { "ulimit%s -n %s", ";\n", 1 }, { "ulimit%s -b %s", ";\n", 1 }, - { "ulimit%s -v %s", ";\n", 1024 } + { "ulimit%s -v %s", ";\n", 1024 }, + { "ulimit%s -p %s", ";\n", 1 } } }, { "csh", "unlimited", "", " -h", "", NULL, { - { "limit%s cputime %s", ";\n", 1 }, - { "limit%s filesize %s", ";\n", 1024 }, - { "limit%s datasize %s", ";\n", 1024 }, - { "limit%s stacksize %s", ";\n", 1024 }, - { "limit%s coredumpsize %s", ";\n", 1024 }, - { "limit%s memoryuse %s", ";\n", 1024 }, - { "limit%s memorylocked %s", ";\n", 1024 }, - { "limit%s maxproc %s", ";\n", 1 }, - { "limit%s openfiles %s", ";\n", 1 }, - { "limit%s sbsize %s", ";\n", 1 }, - { "limit%s vmemoryuse %s", ";\n", 1024 } + { "limit%s cputime %s", ";\n", 1 }, + { "limit%s filesize %s", ";\n", 1024 }, + { "limit%s datasize %s", ";\n", 1024 }, + { "limit%s stacksize %s", ";\n", 1024 }, + { "limit%s coredumpsize %s", ";\n", 1024 }, + { "limit%s memoryuse %s", ";\n", 1024 }, + { "limit%s memorylocked %s", ";\n", 1024 }, + { "limit%s maxproc %s", ";\n", 1 }, + { "limit%s openfiles %s", ";\n", 1 }, + { "limit%s sbsize %s", ";\n", 1 }, + { "limit%s vmemoryuse %s", ";\n", 1024 }, + { "limit%s pseudoterminals %s", ";\n", 1 } } }, { "bash|bash2", "unlimited", "", " -H", " -S", "", @@ -131,22 +134,24 @@ { "ulimit%s -u %s", ";\n", 1 }, { "ulimit%s -n %s", ";\n", 1 }, { "ulimit%s -b %s", ";\n", 1 }, - { "ulimit%s -v %s", ";\n", 1024 } + { "ulimit%s -v %s", ";\n", 1024 }, + { "ulimit%s -p %s", ";\n", 1 } } }, { "tcsh", "unlimited", "", " -h", "", NULL, { - { "limit%s cputime %s", ";\n", 1 }, - { "limit%s filesize %s", ";\n", 1024 }, - { "limit%s datasize %s", ";\n", 1024 }, - { "limit%s stacksize %s", ";\n", 1024 }, - { "limit%s coredumpsize %s", ";\n", 1024 }, - { "limit%s memoryuse %s", ";\n", 1024 }, - { "limit%s memorylocked %s", ";\n", 1024 }, - { "limit%s maxproc %s", ";\n", 1 }, - { "limit%s descriptors %s", ";\n", 1 }, - { "limit%s sbsize %s", ";\n", 1 }, - { "limit%s vmemoryuse %s", ";\n", 1024 } + { "limit%s cputime %s", ";\n", 1 }, + { "limit%s filesize %s", ";\n", 1024 }, + { "limit%s datasize %s", ";\n", 1024 }, + { "limit%s stacksize %s", ";\n", 1024 }, + { "limit%s coredumpsize %s", ";\n", 1024 }, + { "limit%s memoryuse %s", ";\n", 1024 }, + { "limit%s memorylocked %s", ";\n", 1024 }, + { "limit%s maxproc %s", ";\n", 1 }, + { "limit%s descriptors %s", ";\n", 1 }, + { "limit%s sbsize %s", ";\n", 1 }, + { "limit%s vmemoryuse %s", ";\n", 1024 }, + { "limit%s pseudoterminals %s", ";\n", 1 } } }, { "ksh|pdksh", "unlimited", "", " -H", " -S", "", @@ -161,7 +166,8 @@ { "ulimit%s -p %s", ";\n", 1 }, { "ulimit%s -n %s", ";\n", 1 }, { "ulimit%s -b %s", ";\n", 1 }, - { "ulimit%s -v %s", ";\n", 1024 } + { "ulimit%s -v %s", ";\n", 1024 }, + { "ulimit%s -p %s", ";\n", 1 } } }, { "zsh", "unlimited", "", " -H", " -S", "", @@ -176,22 +182,24 @@ { "ulimit%s -u %s", ";\n", 1 }, { "ulimit%s -n %s", ";\n", 1 }, { "ulimit%s -b %s", ";\n", 1 }, - { "ulimit%s -v %s", ";\n", 1024 } + { "ulimit%s -v %s", ";\n", 1024 }, + { "ulimit%s -p %s", ";\n", 1 } } }, { "rc|es", "unlimited", "", " -h", "", NULL, { - { "limit%s cputime %s", ";\n", 1 }, - { "limit%s filesize %s", ";\n", 1024 }, - { "limit%s datasize %s", ";\n", 1024 }, - { "limit%s stacksize %s", ";\n", 1024 }, - { "limit%s coredumpsize %s", ";\n", 1024 }, - { "limit%s memoryuse %s", ";\n", 1024 }, - { "limit%s lockedmemory %s", ";\n", 1024 }, - { "limit%s processes %s", ";\n", 1 }, - { "limit%s descriptors %s", ";\n", 1 }, - { "limit%s sbsize %s", ";\n", 1 }, - { "limit%s vmemoryuse %s", ";\n", 1024 } + { "limit%s cputime %s", ";\n", 1 }, + { "limit%s filesize %s", ";\n", 1024 }, + { "limit%s datasize %s", ";\n", 1024 }, + { "limit%s stacksize %s", ";\n", 1024 }, + { "limit%s coredumpsize %s", ";\n", 1024 }, + { "limit%s memoryuse %s", ";\n", 1024 }, + { "limit%s lockedmemory %s", ";\n", 1024 }, + { "limit%s processes %s", ";\n", 1 }, + { "limit%s descriptors %s", ";\n", 1 }, + { "limit%s sbsize %s", ";\n", 1 }, + { "limit%s vmemoryuse %s", ";\n", 1024 }, + { "limit%s pseudoterminals %s", ";\n", 1 } } }, { NULL, NULL, NULL, NULL, NULL, NULL, @@ -213,7 +221,8 @@ { "maxproc", login_getcapnum }, { "openfiles", login_getcapnum }, { "sbsize", login_getcapsize }, - { "vmemoryuse", login_getcapsize } + { "vmemoryuse", login_getcapsize }, + { "pseudoterminals",login_getcapnum }, }; =20 /* --MKa19fad5K0Qqc8o-- --CthBKbHMLuDDTcy3 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAki83XgACgkQ52SDGA2eCwWPPwCfYoGazVxBOv24F1thn4PvllyC 1jAAnigG4Zi1W8C6BeyOkpPSboTtQo+b =eVms -----END PGP SIGNATURE----- --CthBKbHMLuDDTcy3-- From owner-freebsd-current@FreeBSD.ORG Tue Sep 2 06:51:15 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 96E04106569F; Tue, 2 Sep 2008 06:51:15 +0000 (UTC) (envelope-from Yuriy.Tsibizov@gfk.com) Received: from mx2.gfk.ru (mx2.gfk.ru [84.21.231.139]) by mx1.freebsd.org (Postfix) with ESMTP id B76E68FC17; Tue, 2 Sep 2008 06:51:14 +0000 (UTC) (envelope-from Yuriy.Tsibizov@gfk.com) Received: from ex.hhp.local by mx2.gfk.ru (MDaemon PRO v9.6.0) with ESMTP id md50001762409.msg; Tue, 02 Sep 2008 10:51:28 +0400 Received: from bootserv.hhp.local ([10.0.0.54]) by ex.hhp.local with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Sep 2008 10:51:26 +0400 Date: Tue, 2 Sep 2008 10:52:45 +0400 (MSD) From: Yuriy Tsibizov X-X-Sender: chibis@atwork.home.local To: Ed Schouten In-Reply-To: <20080902063016.GK99951@hoeg.nl> Message-ID: <20080902104710.S1754@atwork.home.local> References: <200809011335.m81DZW8b006033@pozo.com> <200809011436.m81Eaq2v040141@pozo.com> <20080902095229.Y1605@atwork.home.local> <20080902063016.GK99951@hoeg.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 02 Sep 2008 06:51:26.0991 (UTC) FILETIME=[524361F0:01C90CC8] X-Spam-Processed: mx2.gfk.ru, Tue, 02 Sep 2008 10:51:28 +0400 (not processed: message from valid local sender) X-MDRemoteIP: 10.0.0.30 X-Return-Path: Yuriy.Tsibizov@gfk.com X-Envelope-From: Yuriy.Tsibizov@gfk.com X-MDAV-Processed: mx2.gfk.ru, Tue, 02 Sep 2008 10:51:28 +0400 Cc: ports@freebsd.org, Yuriy Tsibizov , FreeBSD Current , Claus Guttesen Subject: Re: /usr/bin/limits (WAS: Re: Apache.sh on current) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2008 06:51:15 -0000 On Tue, 2 Sep 2008, Ed Schouten wrote: > * Yuriy Tsibizov wrote: >> (gdb) bt >> #0 0x00000000 in ?? () >> #1 0x0804937d in main (argc=3, argv=0xbfbfed44) >> at /usr/src/usr.bin/limits/limits.c:341 >> (gdb) l >> 341 val = resources[rcswhich].func(lc, resources[rcswhich].cap, limits[rcswhich].rlim_cur, limits[rcswhich].rlim_cur); >> 342 limits[rcswhich].rlim_cur = resources[rcswhich].func(lc, str, val, val); >> 343 /* maximum value overridden by resourcename or resourcename-max */ >> 344 sprintf(str, "%s-max", resources[rcswhich].cap); >> 345 val = resources[rcswhich].func(lc, resources[rcswhich].cap, limits[rcswhich].rlim_max, limits[rcswhich].rlim_max); >> 346 limits[rcswhich].rlim_max = resources[rcswhich].func(lc, str, val, val); >> 347 } >> 348 } >> 349 } >> 350 >> (gdb) p resources >> $1 = {{cap = 0x804adc2 "cputime", func = 0x8048c84 }, { >> cap = 0x804adca "filesize", func = 0x8048c34 }, { >> cap = 0x804add3 "datasize", func = 0x8048c34 }, { >> cap = 0x804addc "stacksize", func = 0x8048c34 }, { >> cap = 0x804ade6 "coredumpsize", func = 0x8048c34 },{ >> cap = 0x804adf3 "memoryuse", func = 0x8048c34 }, { >> cap = 0x804adfd "memorylocked", func = 0x8048c34 },{ >> cap = 0x804ae0a "maxproc", func = 0x8048c94 }, { >> cap = 0x804ae12 "openfiles", func = 0x8048c94 }, { >> cap = 0x804ae1c "sbsize", func = 0x8048c34 }, { >> cap = 0x804ae23 "vmemoryuse", func = 0x8048c34 }, { >> cap = 0x0, func = 0}} > > Looks like I introduced this regression when importing MPSAFE TTY. > limits(1) dies when RLIMIT_NLIMITS is increased, but the array in > limits.c isn't extended (seems to be quite fragile). > > Can you try the attached patch for limits(1)? Thanks! Will test it this evening, but patch iteslf looks correct. Yuriy. From owner-freebsd-current@FreeBSD.ORG Tue Sep 2 08:24:17 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4C67B106566C for ; Tue, 2 Sep 2008 08:24:17 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 04EC98FC22 for ; Tue, 2 Sep 2008 08:24:16 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1KaRBK-0003cH-U2 for freebsd-current@freebsd.org; Tue, 02 Sep 2008 08:24:11 +0000 Received: from utwig.xim.bz ([195.184.197.130]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 02 Sep 2008 08:24:10 +0000 Received: from c.kworr by utwig.xim.bz with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 02 Sep 2008 08:24:10 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Volodymyr Kostyrko Date: Tue, 02 Sep 2008 11:23:59 +0300 Lines: 22 Message-ID: References: <48BB4FEB.1050906@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: utwig.xim.bz User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; ru-RU; rv:1.8.1.16) Gecko/20080822 SeaMonkey/1.1.11 In-Reply-To: <48BB4FEB.1050906@gmail.com> Sender: news Subject: Re: RFC: moving sysutils/fusefs-kmod to base system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2008 08:24:17 -0000 Aryeh M. Friedman wrote: > Unless I understand how the kernel does stuff there is no penalty for > having unused modules (except the size of the kernel that needs to be > loaded). Keeping in mind that unless I am not reading stuff corectly > fusefs-kmod is the only FS related module that is not in the base > system. Since any fundamental changes in the generic FS API seems to > break fusefs-kmod, and cause some very nasty effects that are almost > impossible to trace to fusefs-kmod (machine freezes so no output or core > dump) it seems to make sense to move it to the base system (after all > we already do this with third party FS code like x/zfs) by moving it we > force it to always compile instead of breaking This can be done by documenting usage of make.conf PORTS_MODULES knob. Just a little notice in ports would suffice, not anybody out there compiles a new kernel daily. > (of course there can be > other issues but as the FS API is updated fusefs-kmod is also updated to > use the new API) -- Sphinx of black quartz judge my vow. From owner-freebsd-current@FreeBSD.ORG Tue Sep 2 09:42:44 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BF8D1106566C for ; Tue, 2 Sep 2008 09:42:44 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 156178FC08 for ; Tue, 2 Sep 2008 09:42:43 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (ppp121-45-54-50.lns11.adl2.internode.on.net [121.45.54.50]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id m829gfqa000495 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 2 Sep 2008 19:12:41 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-current@freebsd.org Date: Tue, 2 Sep 2008 19:12:30 +0930 User-Agent: KMail/1.9.7 References: <48BB4FEB.1050906@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart5285365.xYJcLFmnYY"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200809021912.38401.doconnor@gsoft.com.au> X-Spam-Score: -2.212 () BAYES_00,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.63 on 203.31.81.10 Cc: Volodymyr Kostyrko Subject: Re: RFC: moving sysutils/fusefs-kmod to base system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2008 09:42:44 -0000 --nextPart5285365.xYJcLFmnYY Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tue, 2 Sep 2008, Volodymyr Kostyrko wrote: > Aryeh M. Friedman wrote: > > Unless I understand how the kernel does stuff there is no penalty > > for having unused modules (except the size of the kernel that needs > > to be loaded). Keeping in mind that unless I am not reading stuff > > corectly fusefs-kmod is the only FS related module that is not in > > the base system. Since any fundamental changes in the generic FS > > API seems to break fusefs-kmod, and cause some very nasty effects > > that are almost impossible to trace to fusefs-kmod (machine freezes > > so no output or core dump) it seems to make sense to move it to=20 > > the base system (after all we already do this with third party FS > > code like x/zfs) by moving it we force it to always compile > > instead of breaking > > This can be done by documenting usage of make.conf PORTS_MODULES > knob. Just a little notice in ports would suffice, not anybody out > there compiles a new kernel daily. It would be nice if ports could put their kernel module source somewhere=20 so that a buildkernel would build it. This has several advantages =2D You don't upgrade the port unless you want to when building a kernel. =2D If the kernel API changes you find out because the port doesn't=20 compile then you can make an informed decision. =2D You don't need a working network connection to rebuild your kernel. I did make some strawman patches for this but my make fu is weak so it=20 wasn't very reliable :( =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart5285365.xYJcLFmnYY Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iD8DBQBIvQqO5ZPcIHs/zowRAhWUAJ0YeZjIju3Xu7VuRzZjQFSd+lFCngCeJeEA 2BRaYDyfbOD12hlDDYfDo7k= =bKTF -----END PGP SIGNATURE----- --nextPart5285365.xYJcLFmnYY-- From owner-freebsd-current@FreeBSD.ORG Tue Sep 2 09:55:17 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 31E101065690 for ; Tue, 2 Sep 2008 09:55:17 +0000 (UTC) (envelope-from kometen@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.153]) by mx1.freebsd.org (Postfix) with ESMTP id AF3FE8FC21 for ; Tue, 2 Sep 2008 09:55:16 +0000 (UTC) (envelope-from kometen@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so1472720fgb.35 for ; Tue, 02 Sep 2008 02:55:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; 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; bh=W/biHiBhzZvCukuqYb8BBI6NXErcVIujDDQiQu8SCNk=; b=lmxQi0DcWf2e8Gr3lqSRLEnGKXcUMBu2bbdNlqxFGgvkczfumhCqC3HOlkpnmd/sds HHthICAlmmfgJzY/fpDb6CSBv9xJFOs5C74CmDzQZssloiyOpzHTu1cfJBzA124f2tjR aiUGruKduxCf5o7nekdHkWfAp/D3T9PHq60iI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=ADJS9wXGp0KWO8rCgHnBh4NjJuHK+Wz1kdJMIOGGnMMQxT1wW1IqLmClH/7vsPbhHE L7aZDbm5l1joSUxHnKuY9TvClc9VQTJoW7z/YZaOV5V/JSc/z0+ugTehJTKsOVuys+FV QWWF10/4GO57K8iVJS/qH6yKH25YiAM9k5JHI= Received: by 10.86.84.5 with SMTP id h5mr5419469fgb.58.1220349315454; Tue, 02 Sep 2008 02:55:15 -0700 (PDT) Received: by 10.86.79.10 with HTTP; Tue, 2 Sep 2008 02:55:15 -0700 (PDT) Message-ID: Date: Tue, 2 Sep 2008 11:55:15 +0200 From: "Claus Guttesen" To: "Daniel O'Connor" In-Reply-To: <200809021912.38401.doconnor@gsoft.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <48BB4FEB.1050906@gmail.com> <200809021912.38401.doconnor@gsoft.com.au> Cc: Volodymyr Kostyrko , freebsd-current@freebsd.org Subject: Re: RFC: moving sysutils/fusefs-kmod to base system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2008 09:55:17 -0000 >> > Unless I understand how the kernel does stuff there is no penalty >> > for having unused modules (except the size of the kernel that needs >> > to be loaded). Keeping in mind that unless I am not reading stuff >> > corectly fusefs-kmod is the only FS related module that is not in >> > the base system. Since any fundamental changes in the generic FS >> > API seems to break fusefs-kmod, and cause some very nasty effects >> > that are almost impossible to trace to fusefs-kmod (machine freezes >> > so no output or core dump) it seems to make sense to move it to >> > the base system (after all we already do this with third party FS >> > code like x/zfs) by moving it we force it to always compile >> > instead of breaking >> >> This can be done by documenting usage of make.conf PORTS_MODULES >> knob. Just a little notice in ports would suffice, not anybody out >> there compiles a new kernel daily. > > > It would be nice if ports could put their kernel module source somewhere > so that a buildkernel would build it. > > This has several advantages > - You don't upgrade the port unless you want to when building a kernel. > - If the kernel API changes you find out because the port doesn't > compile then you can make an informed decision. > - You don't need a working network connection to rebuild your kernel. > > By ports do you mean the ports-system? If that's the case you're mixing the basesystem with applications. The separation of basesystem and apps is IMO one of BSD's strength. Why not use portupgrade for that purpose? -- regards Claus When lenity and cruelty play for a kingdom, the gentler gamester is the soonest winner. Shakespeare From owner-freebsd-current@FreeBSD.ORG Tue Sep 2 11:03:50 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6DC21106567B for ; Tue, 2 Sep 2008 11:03:50 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id B611F8FC17 for ; Tue, 2 Sep 2008 11:03:49 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (ppp121-45-54-50.lns11.adl2.internode.on.net [121.45.54.50]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id m82B3kwC002927 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 2 Sep 2008 20:33:47 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: "Claus Guttesen" Date: Tue, 2 Sep 2008 20:33:27 +0930 User-Agent: KMail/1.9.7 References: <48BB4FEB.1050906@gmail.com> <200809021912.38401.doconnor@gsoft.com.au> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2462860.TtqyxuQP5z"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200809022033.41657.doconnor@gsoft.com.au> X-Spam-Score: -2.212 () BAYES_00,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.63 on 203.31.81.10 Cc: Volodymyr Kostyrko , freebsd-current@freebsd.org Subject: Re: RFC: moving sysutils/fusefs-kmod to base system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2008 11:03:50 -0000 --nextPart2462860.TtqyxuQP5z Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tue, 2 Sep 2008, Claus Guttesen wrote: > > This has several advantages > > - You don't upgrade the port unless you want to when building a > > kernel. - If the kernel API changes you find out because the port > > doesn't compile then you can make an informed decision. > > - You don't need a working network connection to rebuild your > > kernel. > > > > > > By ports do you mean the ports-system? If that's the case you're I mean something in /usr/ports. > mixing the basesystem with applications. The separation of basesystem > and apps is IMO one of BSD's strength. Why not use portupgrade for > that purpose? Then why allow ports to create & install KLDs at all? This would cause /usr/src to reference an outside source (ie somewhere=20 in LOCALBASE where KLD source would be) but since the user already=20 opted to install a port KLD it seems reasonable. I did get told that in theory you shouldn't need to rebuild port KLDs on=20 a release branch because the ABI shouldn't change.. That's a bit=20 unsatisfactory because people run -current where this guarantee doesn't=20 apply, and it isn't an iron-clad guarantee anyway :) Basically it seems to me that it would have no drawbacks and prevent=20 people from forgetting to recompile stuff which could hose them down=20 the track.. =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart2462860.TtqyxuQP5z Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iD8DBQBIvR2N5ZPcIHs/zowRAu3mAKCL5TCLOYyEvzMgysO/bbZpAP5kAgCdGFBX xMifgQH1sPZoVpBjk+8aAdk= =DGXz -----END PGP SIGNATURE----- --nextPart2462860.TtqyxuQP5z-- From owner-freebsd-current@FreeBSD.ORG Tue Sep 2 12:55:13 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3F64B1065677 for ; Tue, 2 Sep 2008 12:55:13 +0000 (UTC) (envelope-from llc2w@virginia.edu) Received: from fork4.mail.virginia.edu (fork4.mail.Virginia.EDU [128.143.2.194]) by mx1.freebsd.org (Postfix) with ESMTP id 0AF288FC31 for ; Tue, 2 Sep 2008 12:55:12 +0000 (UTC) (envelope-from llc2w@virginia.edu) Received: from localhost (localhost [127.0.0.1]) by fork4.mail.virginia.edu (Postfix) with ESMTP id C1EEC11B07F for ; Tue, 2 Sep 2008 08:34:35 -0400 (EDT) Received: from fork4.mail.virginia.edu ([127.0.0.1]) by localhost (fork4.mail.virginia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30043-08 for ; Tue, 2 Sep 2008 08:34:35 -0400 (EDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.158]) by fork4.mail.virginia.edu (Postfix) with ESMTP id 68E1911B07C for ; Tue, 2 Sep 2008 08:34:35 -0400 (EDT) Received: by fg-out-1718.google.com with SMTP id 19so1445646fgg.4 for ; Tue, 02 Sep 2008 05:34:34 -0700 (PDT) Received: by 10.86.57.9 with SMTP id f9mr5540656fga.66.1220358874545; Tue, 02 Sep 2008 05:34:34 -0700 (PDT) Received: by 10.86.31.14 with HTTP; Tue, 2 Sep 2008 05:34:34 -0700 (PDT) Message-ID: <792298050809020534i65a9d6efv3f1b166dfe96ad7@mail.gmail.com> Date: Tue, 2 Sep 2008 08:34:34 -0400 From: "L Campbell" To: "Daniel O'Connor" , freebsd-current@freebsd.org In-Reply-To: <200809021912.38401.doconnor@gsoft.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <48BB4FEB.1050906@gmail.com> <200809021912.38401.doconnor@gsoft.com.au> X-UVA-Virus-Scanned: by amavisd-new at fork4.mail.virginia.edu Cc: Subject: Re: RFC: moving sysutils/fusefs-kmod to base system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2008 12:55:13 -0000 On Tue, Sep 2, 2008 at 5:42 AM, Daniel O'Connor wrote: > On Tue, 2 Sep 2008, Volodymyr Kostyrko wrote: >> Aryeh M. Friedman wrote: >> This can be done by documenting usage of make.conf PORTS_MODULES >> knob. > It would be nice if ports could put their kernel module source somewhere > so that a buildkernel would build it. If I'm reading make.conf(5) correctly, PORTS_MODULES does exactly that -- rebuilds the port whenever the kernel is built. From owner-freebsd-current@FreeBSD.ORG Tue Sep 2 13:22:31 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3C360106566B for ; Tue, 2 Sep 2008 13:22:31 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id A17D68FC13 for ; Tue, 2 Sep 2008 13:22:30 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (ppp121-45-54-50.lns11.adl2.internode.on.net [121.45.54.50]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id m82DMQjN007101 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 2 Sep 2008 22:52:28 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: "L Campbell" Date: Tue, 2 Sep 2008 22:52:14 +0930 User-Agent: KMail/1.9.7 References: <48BB4FEB.1050906@gmail.com> <200809021912.38401.doconnor@gsoft.com.au> <792298050809020534i65a9d6efv3f1b166dfe96ad7@mail.gmail.com> In-Reply-To: <792298050809020534i65a9d6efv3f1b166dfe96ad7@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart10996720.BnYZx494AT"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200809022252.22146.doconnor@gsoft.com.au> X-Spam-Score: -2.212 () BAYES_00,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.63 on 203.31.81.10 Cc: freebsd-current@freebsd.org Subject: Re: RFC: moving sysutils/fusefs-kmod to base system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2008 13:22:31 -0000 --nextPart10996720.BnYZx494AT Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tue, 2 Sep 2008, L Campbell wrote: > On Tue, Sep 2, 2008 at 5:42 AM, Daniel O'Connor=20 wrote: > > On Tue, 2 Sep 2008, Volodymyr Kostyrko wrote: > >> Aryeh M. Friedman wrote: > >> This can be done by documenting usage of make.conf PORTS_MODULES > >> knob. > > > > It would be nice if ports could put their kernel module source > > somewhere so that a buildkernel would build it. > > If I'm reading make.conf(5) correctly, PORTS_MODULES does exactly > that -- rebuilds the port whenever the kernel is built. There are a few problems with that.. =2D You need to configure it manually. =2D If you update your ports tree it will upgrade the KLD port which may = =20 not be what you want. =2D You need the distfile for the port available. =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart10996720.BnYZx494AT Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iD8DBQBIvT4O5ZPcIHs/zowRAjqYAJ4uNRlodJsgQiCw0IIaqpngEtn1XgCeNsgr gaqxbpCSdsXv55lzEWhOAJs= =Ixyp -----END PGP SIGNATURE----- --nextPart10996720.BnYZx494AT-- From owner-freebsd-current@FreeBSD.ORG Tue Sep 2 13:26:03 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 667D2106566B; Tue, 2 Sep 2008 13:26:03 +0000 (UTC) (envelope-from bkelly@vadev.org) Received: from ianto.vadev.org (vadev.org [66.92.166.151]) by mx1.freebsd.org (Postfix) with ESMTP id 0C94D8FC18; Tue, 2 Sep 2008 13:26:02 +0000 (UTC) (envelope-from bkelly@vadev.org) Received: from harkness.vadev.org (harkness.vadev.org [192.168.1.210]) (authenticated bits=0) by ianto.vadev.org (8.14.3/8.14.3) with ESMTP id m82CkZNf012550 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 2 Sep 2008 12:46:36 GMT (envelope-from bkelly@vadev.org) Message-Id: <21FF036D-2418-43E4-8FA6-84DCF71BDFDE@vadev.org> From: Ben Kelly To: current@freebsd.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Date: Tue, 2 Sep 2008 08:46:35 -0400 X-Mailer: Apple Mail (2.926) X-Spam-Score: -1.44 () ALL_TRUSTED X-Scanned-By: MIMEDefang 2.64 on 192.168.1.110 Cc: roberto@freebsd.org Subject: [patch] ntp no longer compiles using WITHOUT_GNU_SUPPORT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2008 13:26:03 -0000 Hello all, It looks like the following commit broke the WITHOUT_GNU_SUPPORT knob when compiling ntp: http://svn.freebsd.org/viewvc/base?view=revision&revision=182008 The various readline symbols are conditionally set in usr.sbin/ntp/ ntpdc/Makefile, but this commit now hardcodes them in the usr.sbin/ntp/ config.h as well. I assume this was not intended. The attached patch fixed the issue for me. Anyway, just FYI. Thanks. - Ben Index: usr.sbin/ntp/config.h =================================================================== --- usr.sbin/ntp/config.h (revision 91) +++ usr.sbin/ntp/config.h (working copy) @@ -439,7 +439,7 @@ /* #undef HAVE_LIBPOSIX4 */ /* Define to 1 if you have the `readline' library (-lreadline). */ -#define HAVE_LIBREADLINE 1 +/* #undef HAVE_LIBREADLINE */ /* Define to 1 if you have the `rt' library (-lrt). */ #define HAVE_LIBRT 1 @@ -570,10 +570,10 @@ /* #undef HAVE_PUTUTXLINE */ /* Define to 1 if you have the header file. */ -#define HAVE_READLINE_HISTORY_H 1 +/* #undef HAVE_READLINE_HISTORY_H */ /* Define to 1 if you have the header file. */ -#define HAVE_READLINE_READLINE_H 1 +/* #undef HAVE_READLINE_READLINE_H */ /* Define to 1 if you have the `readlink' function. */ #define HAVE_READLINK 1 From owner-freebsd-current@FreeBSD.ORG Tue Sep 2 14:00:58 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3760D1065787 for ; Tue, 2 Sep 2008 14:00:58 +0000 (UTC) (envelope-from roberto@keltia.freenix.fr) Received: from keltia.freenix.fr (keltia.freenix.org [IPv6:2001:660:330f:f820:213:72ff:fe15:f44]) by mx1.freebsd.org (Postfix) with ESMTP id D57868FC2A for ; Tue, 2 Sep 2008 14:00:57 +0000 (UTC) (envelope-from roberto@keltia.freenix.fr) Received: from localhost (localhost [127.0.0.1]) by keltia.freenix.fr (Postfix/TLS) with ESMTP id 77A773AC07 for ; Tue, 2 Sep 2008 16:00:56 +0200 (CEST) X-Virus-Scanned: amavisd-new at keltia.freenix.fr Received: from keltia.freenix.fr ([127.0.0.1]) by localhost (keltia.freenix.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SXD5ahWQad7s for ; Tue, 2 Sep 2008 16:00:56 +0200 (CEST) Received: by keltia.freenix.fr (Postfix/TLS, from userid 101) id 1B17B3ABE5; Tue, 2 Sep 2008 16:00:56 +0200 (CEST) Date: Tue, 2 Sep 2008 16:00:56 +0200 From: Ollivier Robert To: current@freebsd.org Message-ID: <20080902140056.GA48955@keltia.freenix.fr> References: <21FF036D-2418-43E4-8FA6-84DCF71BDFDE@vadev.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <21FF036D-2418-43E4-8FA6-84DCF71BDFDE@vadev.org> X-Operating-System: MacOS X / Macbook Pro - FreeBSD 7 / Dell D820 SMP User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Subject: Re: [patch] ntp no longer compiles using WITHOUT_GNU_SUPPORT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2008 14:00:58 -0000 According to Ben Kelly: > It looks like the following commit broke the WITHOUT_GNU_SUPPORT knob > when compiling ntp: Fixed, thanks. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr Darwin sidhe.keltia.net Version 9.2.0: Tue Feb 5 16:13:22 PST 2008; i386 From owner-freebsd-current@FreeBSD.ORG Tue Sep 2 15:03:00 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2B3FA106579E for ; Tue, 2 Sep 2008 15:03:00 +0000 (UTC) (envelope-from nakaji@kankyo-u.ac.jp) Received: from www.heimat.gr.jp (unknown [IPv6:2001:3e0:a84::1]) by mx1.freebsd.org (Postfix) with ESMTP id B52458FC32 for ; Tue, 2 Sep 2008 15:02:58 +0000 (UTC) (envelope-from nakaji@kankyo-u.ac.jp) X-Virus-Scanned: amavisd-new at heimat.gr.jp Received: from ra333.heimat.gr.jp.kankyo-u.ac.jp ([IPv6:2001:3e0:a84:0:200:4cff:fe17:573c]) by www.heimat.gr.jp (8.14.2/8.14.2) with ESMTP id m82F25eq076688; Wed, 3 Sep 2008 00:02:15 +0900 (JST) (envelope-from nakaji@kankyo-u.ac.jp) From: NAKAJI Hiroyuki To: Julian Elischer References: <4824F1B4.6010302@elischer.org> Date: Wed, 03 Sep 2008 00:02:05 +0900 In-Reply-To: <4824F1B4.6010302@elischer.org> (Julian Elischer's message of "Fri, 09 May 2008 17:52:04 -0700") Message-ID: <86wshuwpzm.fsf@ra333.heimat.gr.jp> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, score=-6.1 required=13.0 tests=BAYES_00, CONTENT_TYPE_PRESENT,NO_RELAYS autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on www.heimat.gr.jp Cc: freebsd-current@freebsd.org Subject: Re: Multiple routing table support commited X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2008 15:03:00 -0000 Thanks for your great work. Do you have a plan to MFC this feature to RELENG_6? Or is it better to upgrade my RELENG6 box to RELENG_7? My ISP allows 5 PPPoE sessions but it always returns only one IP address as HISADDR. I hope this FIB feature will help my multi PPPoE sessions. I tried "setfib -1 ppp anothersession" on my RELENG_7 box, which complains Warning: iface add: ioctl(SIOCAIFADDR, 10.172.1.73 -> 210.247.16.1): File exists Maybe I misunderstand the usage. >>>>> In <4824F1B4.6010302@elischer.org> >>>>> Julian Elischer wrote: > I have committed the base of teh Multi-routing-table support. > I am current;y waiting for it to loop back to me before a final > make universe test, but I think it should be ok. > if you do nothing you should not see any difference. -- NAKAJI Hiroyuki From owner-freebsd-current@FreeBSD.ORG Tue Sep 2 15:34:46 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C657A106564A for ; Tue, 2 Sep 2008 15:34:46 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 369B48FC12 for ; Tue, 2 Sep 2008 15:34:46 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m82FYMYc015249; Tue, 2 Sep 2008 11:34:36 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: "Pascal Hofstee" Date: Tue, 2 Sep 2008 10:33:54 -0400 User-Agent: KMail/1.9.7 References: <20080830010551.GA2090@lorvorc.mips.inka.de> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200809021033.55033.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Tue, 02 Sep 2008 11:34:37 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.1/8140/Tue Sep 2 11:02:13 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: freebsd-current@freebsd.org, Christian Weisgerber Subject: Re: No root filesystem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2008 15:34:46 -0000 On Monday 01 September 2008 03:21:16 am Pascal Hofstee wrote: > On Sat, Aug 30, 2008 at 3:05 AM, Christian Weisgerber > wrote: > > John Baldwin: > > > >> So the reports I've seen of this all involve the Nvidia MCP55 ATA chipset, and > >> only the ata controller loses its marbles (so to speak). > > > > I also observe that k8temp doesn't attach. Maybe Pascal can check this. > > It's not part of GENERIC, so k8temp.ko needs to be explicitly loaded > > by the loader for this. > > > > k8temp0: on hostb3 > > Ok .. this morning i went ahead and collected two boot -v logs. One > for the old (working) kernel and one for the new (broken) kernel. For > this i made sure not to load the snd_hda module as that tended to > bloat the verbose boot output beyond the limit that i could still get > to the interesting data at the next boot. The two verbose bootlogs can > be found at: > > http://shadowrun.homeunix.net/boot.verbose.working for the old kernel > http://shadowrun.homeunix.net/boot.verbose.broken for the new kernel > http://shadowrun.homeunix.net/boot.verbose.diff for the differences > between the two. > > The working kernel shows several devices there that do Not show up on > the new kernel, according to http://www.pcidatabase.com this concerns > the following devices all by"Advanced Micro Devices" > -found-> vendor=0x1022, dev=0x1100, revid=0x00 > 0x1100 HyperTransport Technology Configuration > > -found-> vendor=0x1022, dev=0x1101, revid=0x00 > 0x1101 Address Map > > -found-> vendor=0x1022, dev=0x1102, revid=0x00 > 0x1102 DRAM Controller > > -found-> vendor=0x1022, dev=0x1103, revid=0x00 > 0x1103 Miscellaneous Control This explains k8temp. So my earlier test patch to Christian only checked on i386 which is why it didn't find an issue before. Try the updated patch at http://www.FreeBSD.org/~jhb/patches/pcie.patch This does PCI config reads using both methods and panics if it doesn't get the same result. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Sep 2 15:34:51 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 00DF7106564A for ; Tue, 2 Sep 2008 15:34:51 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 7704E8FC17 for ; Tue, 2 Sep 2008 15:34:50 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m82FYMYd015249; Tue, 2 Sep 2008 11:34:44 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: Kostik Belousov Date: Tue, 2 Sep 2008 10:35:49 -0400 User-Agent: KMail/1.9.7 References: <200808291726.16799.jhb@freebsd.org> <20080830084824.GE2038@deviant.kiev.zoral.com.ua> In-Reply-To: <20080830084824.GE2038@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200809021035.49822.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Tue, 02 Sep 2008 11:34:44 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.1/8140/Tue Sep 2 11:02:13 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Kirk Strauser , freebsd-current@freebsd.org Subject: Re: System, diagnose thyself: auto-documentation for crashes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2008 15:34:51 -0000 On Saturday 30 August 2008 04:48:24 am Kostik Belousov wrote: > On Fri, Aug 29, 2008 at 05:26:16PM -0400, John Baldwin wrote: > > On Friday 29 August 2008 05:07:15 pm Kirk Strauser wrote: > > > On Aug 29, 2008, at 10:44 AM, John Baldwin wrote: > > > > > > > See /usr/sbin/crashinfo for a start. I have patches to enable it > > > > from /etc/rc.d/savecore after generating a patch (still need to test > > > > them > > > > though). > > > > > > > > > I'm not finding that anywhere, either on my systems or on Google. > > > > It's in HEAD. > > > > http://www.freebsd.org/cgi/cvsweb.cgi/src/usr.sbin/crashinfo/crashinfo.sh > > John, why not MFCing it ? MFC cannot break anything :), it is a standalone > utility, and it definitely useful to have bigger test base. It is on the list, I've just been a bit busy recently. :) Also, I didn't want to merge it to 7.x until I fixed vmstat and iostat to work on core dumps again. > I propose to add some note to the manpage, explicitely mentioning > experimantal status of utility, and the fact that both user interface > and output format are subject to change. I imagine this is the only > obstacle for MFC. Actually, Y! has used a script like this in production for years, so I don't foresee much in the way of changes in the future. One change would be to add a run of ddb to dump the capture buffer from a crash dump. Another change would be to re-enable w(1) if it ever becomes useful on crash dumps again. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Sep 2 15:34:58 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B699410657E5; Tue, 2 Sep 2008 15:34:58 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id DBD5C8FC21; Tue, 2 Sep 2008 15:34:52 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m82FYMYa015249; Tue, 2 Sep 2008 11:34:23 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: Tor Egge Date: Tue, 2 Sep 2008 10:19:38 -0400 User-Agent: KMail/1.9.7 References: <200808230003.44081.jhb@freebsd.org> <48B6BC81.5060300@clearchain.com> <20080901.013117.74700691.Tor.Egge@cvsup.no.freebsd.org> In-Reply-To: <20080901.013117.74700691.Tor.Egge@cvsup.no.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200809021019.39467.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Tue, 02 Sep 2008 11:34:24 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.1/8140/Tue Sep 2 11:02:13 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: attilio@freebsd.org, kevinxlinuz@163.com, freebsd-current@freebsd.org, Benjamin.Close@clearchain.com, kib@freebsd.org Subject: Re: [BUG] I think sleepqueue need to be protected in sleepq_broadcast X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2008 15:34:58 -0000 On Sunday 31 August 2008 09:31:17 pm Tor Egge wrote: > > sleepq_resume_thread() contains an ownership handover of sq if the resumed > thread is the last one blocked on the wait channel. After the handover, sq is > no longer protected by the sleep queue chain lock and should no longer be > accessed by sleepq_broadcast(). > > Normally, when sleepq_broadcast() incorrectly accesses sq after the handover, > it will find the sq->sq_blocked queue to be empty, and the code appears to > work. > > If the last correctly woken thread manages to go to sleep again very quickly on > another wait channel, sleepq_broadcast() might incorrectly determine that the > sq->sq_blocked queue isn't empty, and start doing the wrong thing. > > A similar (but probably much more difficult to trigger) issue is present with > regards to thread_lock() and turnstiles. > > The caller of thread_lock() might have performed sufficient locking to ensure > that the thread to be locked doesn't go away, but any turnstile spin lock > pointed to by td->td_lock isn't protected. Making turnstiles type stable > (setting UMA_ZONE_NOFREE flag for turnstile_zone) should fix that issue. Good find! I think the better fix is to not rely on type stability, but to have sleepq_resume_thread() indicate to the caller that it has claimed the sleepqueue instead. I think this race is only possible with thread_lock() btw. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Sep 2 15:34:59 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4EC82106582D; Tue, 2 Sep 2008 15:34:59 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id E50488FC2C; Tue, 2 Sep 2008 15:34:58 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m82FYMYe015249; Tue, 2 Sep 2008 11:34:51 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: Julian Elischer Date: Tue, 2 Sep 2008 10:36:53 -0400 User-Agent: KMail/1.9.7 References: <200808291636.10656.jhb@FreeBSD.org> <48B86BB3.30705@elischer.org> In-Reply-To: <48B86BB3.30705@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200809021036.53908.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Tue, 02 Sep 2008 11:34:51 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.1/8140/Tue Sep 2 11:02:13 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: current@freebsd.org Subject: Re: rtentry panic with FIB X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2008 15:34:59 -0000 On Friday 29 August 2008 05:35:47 pm Julian Elischer wrote: > John Baldwin wrote: > > Unfortunately it hung trying to dump, so all I have is the stack trace from > > DDB. This is recent HEAD running stress2 > > > > panic: _mtx_lock_sleep: recursed on non-recursive mutex rtentry @ ../../1 > > > > do you know what lock it was talking about? All I have is what I included in the original e-mail. So it's an "rtentry" mutex, but that's all I know. You can try running the 'udp' test from stress2 locally perhaps to see if you can trigger it. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Sep 2 15:53:40 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DDA1F106567C; Tue, 2 Sep 2008 15:53:40 +0000 (UTC) (envelope-from tom.hurst@clara.net) Received: from spork.qfe3.net (spork.qfe3.net [212.13.207.101]) by mx1.freebsd.org (Postfix) with ESMTP id 8522E8FC12; Tue, 2 Sep 2008 15:53:39 +0000 (UTC) (envelope-from tom.hurst@clara.net) Received: from [81.104.123.28] (helo=voi.aagh.net) by spork.qfe3.net with esmtp (Exim 4.66 (FreeBSD)) (envelope-from ) id 1KaXpk-000JiZ-Q1; Tue, 02 Sep 2008 16:30:20 +0100 Received: from freaky by voi.aagh.net with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KaXpk-0002a9-JV; Tue, 02 Sep 2008 16:30:20 +0100 Date: Tue, 2 Sep 2008 16:30:20 +0100 From: Thomas Hurst To: Roman Divacky Message-ID: <20080902153020.GA94977@voi.aagh.net> Mail-Followup-To: Roman Divacky , Alexey Shuvaev , Ed Schouten , freebsd-current@freebsd.org References: <48BAD085.1090507@gmail.com> <20080831200950.GF99951@hoeg.nl> <871w04syfw.fsf@kobe.laptop> <20080901101121.GC4083@wep400x.physik.uni-wuerzburg.de> <20080901160844.GA56657@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080901160844.GA56657@freebsd.org> Organization: Not much. User-Agent: Mutt/1.5.18 (2008-05-17) Sender: Thomas Hurst Cc: Alexey Shuvaev , Ed Schouten , freebsd-current@freebsd.org Subject: Re: csh history and pts X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2008 15:53:41 -0000 * Roman Divacky (rdivacky@freebsd.org) wrote: > > Back to original post, I confirm that [t]csh loses history after shutdown(8). > > might be completely irrelevant but tcsh on linux loses history for me as well :) tcsh doesn't bother doing any locking when merging .history, so if you kill multiple sessions at once, it's very common to see entries get lost, interlaced or doubled e.g: #+1220363109 ./setup.py uninsta#+1220237817 ... #+1220363109 ./setup.py uninsta#+1220237817 #+1220363109 ./setup.py uninstall -vv --manifest files.txt #+1220363109 iles.txt #+1220363109 d' I see it a lot when I close Terminator and kill the 4+ terms in it at the same time. If I ^D each term manually it's fine, if I kill half a dozen at once I'll probably lose half the history entirely and the other half will be badly mangled. I expect shutdown is having a similar effect. -- Thomas 'Freaky' Hurst http://hur.st/ From owner-freebsd-current@FreeBSD.ORG Tue Sep 2 16:00:18 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A203C1065694 for ; Tue, 2 Sep 2008 16:00:18 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from vlakno.cz (vlk.vlakno.cz [62.168.28.247]) by mx1.freebsd.org (Postfix) with ESMTP id 9805E8FC22 for ; Tue, 2 Sep 2008 16:00:07 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from localhost (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 5B53265B615; Tue, 2 Sep 2008 18:00:23 +0200 (CEST) X-Virus-Scanned: amavisd-new at vlakno.cz Received: from vlakno.cz ([127.0.0.1]) by localhost (vlk.vlakno.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w1sztBMj1iPP; Tue, 2 Sep 2008 18:00:04 +0200 (CEST) Received: from vlk.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 32A5C65B5FF; Tue, 2 Sep 2008 18:00:04 +0200 (CEST) Received: (from rdivacky@localhost) by vlk.vlakno.cz (8.14.2/8.14.2/Submit) id m82G03K1050867; Tue, 2 Sep 2008 18:00:03 +0200 (CEST) (envelope-from rdivacky) Date: Tue, 2 Sep 2008 18:00:03 +0200 From: Roman Divacky To: Alexey Shuvaev , Ed Schouten , freebsd-current@freebsd.org Message-ID: <20080902160003.GA50767@freebsd.org> References: <48BAD085.1090507@gmail.com> <20080831200950.GF99951@hoeg.nl> <871w04syfw.fsf@kobe.laptop> <20080901101121.GC4083@wep400x.physik.uni-wuerzburg.de> <20080901160844.GA56657@freebsd.org> <20080902153020.GA94977@voi.aagh.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080902153020.GA94977@voi.aagh.net> User-Agent: Mutt/1.4.2.3i Cc: Subject: Re: csh history and pts X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2008 16:00:18 -0000 On Tue, Sep 02, 2008 at 04:30:20PM +0100, Thomas Hurst wrote: > * Roman Divacky (rdivacky@freebsd.org) wrote: > > > > Back to original post, I confirm that [t]csh loses history after shutdown(8). > > > > might be completely irrelevant but tcsh on linux loses history for me as well :) > > tcsh doesn't bother doing any locking when merging .history, so if you > kill multiple sessions at once, it's very common to see entries get > lost, interlaced or doubled e.g: that's not it.... I never had any history saved since I started to use Linux (10 months ago).. I occasionlly get garbled/lost history under fbsd but this is different From owner-freebsd-current@FreeBSD.ORG Tue Sep 2 16:15:08 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 050811065677 for ; Tue, 2 Sep 2008 16:15:08 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [62.111.66.27]) by mx1.freebsd.org (Postfix) with ESMTP id B170F8FC1B for ; Tue, 2 Sep 2008 16:15:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from localhost (amavis.str.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id EDC9441C6A1; Tue, 2 Sep 2008 18:15:05 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([62.111.66.27]) by localhost (amavis.str.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id Of9RxuCpULpE; Tue, 2 Sep 2008 18:15:05 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id 9500E41C690; Tue, 2 Sep 2008 18:15:05 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id B774644487F; Tue, 2 Sep 2008 16:13:57 +0000 (UTC) Date: Tue, 2 Sep 2008 16:13:57 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: John Baldwin In-Reply-To: <200809021036.53908.jhb@freebsd.org> Message-ID: <20080902161225.C65801@maildrop.int.zabbadoz.net> References: <200808291636.10656.jhb@FreeBSD.org> <48B86BB3.30705@elischer.org> <200809021036.53908.jhb@freebsd.org> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Julian Elischer , FreeBSD current mailing list Subject: Re: rtentry panic with FIB X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2008 16:15:08 -0000 On Tue, 2 Sep 2008, John Baldwin wrote: > On Friday 29 August 2008 05:35:47 pm Julian Elischer wrote: >> John Baldwin wrote: >>> Unfortunately it hung trying to dump, so all I have is the stack trace > from >>> DDB. This is recent HEAD running stress2 >>> >>> panic: _mtx_lock_sleep: recursed on non-recursive mutex rtentry @ ../../1 >>> >> >> do you know what lock it was talking about? > > All I have is what I included in the original e-mail. So it's an "rtentry" > mutex, but that's all I know. You can try running the 'udp' test from > stress2 locally perhaps to see if you can trigger it. I had a look at the function and the locking looked strange (possibly because of the goto and label in the middle). Could you find the line number (surrounding code block) for: >>> rt_check_fib() at rt_check_fib+0x1ea /bz -- Bjoern A. Zeeb Stop bit received. Insert coin for new game. From owner-freebsd-current@FreeBSD.ORG Tue Sep 2 16:48:01 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 192C2106564A for ; Tue, 2 Sep 2008 16:48:01 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:610:652::211]) by mx1.freebsd.org (Postfix) with ESMTP id 17D568FC29 for ; Tue, 2 Sep 2008 16:48:00 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 42CBA1CC40; Tue, 2 Sep 2008 18:47:59 +0200 (CEST) Date: Tue, 2 Sep 2008 18:47:59 +0200 From: Ed Schouten To: FreeBSD Current Message-ID: <20080902164759.GL99951@hoeg.nl> References: <87fxot5hoi.fsf@kobe.laptop> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Zek6ooiun86DS3+c" Content-Disposition: inline In-Reply-To: <87fxot5hoi.fsf@kobe.laptop> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Giorgos Keramidas Subject: CFT: pts(4) "packet mode" support X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2008 16:48:01 -0000 --Zek6ooiun86DS3+c Content-Type: multipart/mixed; boundary="kn2F/kOnIYRmW7Hu" Content-Disposition: inline --kn2F/kOnIYRmW7Hu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello everyone, One of the things I couldn't fix in time for the MPSAFE TTY import, was pts(4) packet mode. Because people have noticed it was missing, I decided to implement it, for inclusion in the SVN tree. ;-) Giorgos and I have already tried the attached patch, but it would be nice if others could test it as well. I'm planning to integrate this patch by the end of the week. Any feedback? Comments? Obscure panics? --=20 Ed Schouten WWW: http://80386.nl/ --kn2F/kOnIYRmW7Hu Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="packet-mode.diff" Content-Transfer-Encoding: quoted-printable Index: share/man/man4/pts.4 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- share/man/man4/pts.4 (revision 182681) +++ share/man/man4/pts.4 (working copy) @@ -173,9 +173,3 @@ it was replaced with the .Nm driver. -.Sh BUGS -Packet mode has not been properly implemented in this version of -.Fx . -When enabled, it will always prepend -.Dv TIOCPKT_DATA , -even if other events have been triggered. Index: sys/kern/tty_pts.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/kern/tty_pts.c (revision 182681) +++ sys/kern/tty_pts.c (working copy) @@ -82,6 +82,7 @@ int pts_unit; /* (c) Device unit number. */ unsigned int pts_flags; /* (t) Device flags. */ #define PTS_PKT 0x1 /* Packet mode. */ + char pts_pkt; /* (t) Unread packet mode data. */ =20 struct cv pts_inwait; /* (t) Blocking write() on master. */ struct selinfo pts_inpoll; /* (t) Select queue for write(). */ @@ -105,34 +106,54 @@ { struct tty *tp =3D fp->f_data; struct pts_softc *psc =3D tty_softc(tp); - int error, oresid; + int error =3D 0; + char pkt; =20 if (uio->uio_resid =3D=3D 0) return (0); -=09 - /* - * Implement packet mode. When packet mode is turned on, the - * first byte contains a bitmask of events that occured (start, - * stop, flush, window size, etc). - */ =20 - if (psc->pts_flags & PTS_PKT) { - /* XXX: return proper bits. */ - error =3D ureadc(0, uio); - if (error !=3D 0) + tty_lock(tp); + + for (;;) { + /* + * Implement packet mode. When packet mode is turned on, + * the first byte contains a bitmask of events that + * occured (start, stop, flush, window size, etc). + */ + if (psc->pts_flags & PTS_PKT && psc->pts_pkt) { + pkt =3D psc->pts_pkt; + psc->pts_pkt =3D 0; + tty_unlock(tp); + + error =3D ureadc(pkt, uio); return (error); - if (uio->uio_resid =3D=3D 0) - return (0); - } + } =20 - oresid =3D uio->uio_resid; + /* + * Transmit regular data. + * + * XXX: We shouldn't use ttydisc_getc_poll()! Even + * though in this implementation, there is likely going + * to be data, we should just call ttydisc_getc_uio() + * and use its return value to sleep. + */ + if (ttydisc_getc_poll(tp)) { + if (psc->pts_flags & PTS_PKT) { + /* + * XXX: Small race. Fortunately PTY + * consumers aren't multithreaded. + */ =20 - tty_lock(tp); - for (;;) { - error =3D ttydisc_getc_uio(tp, uio); - /* We've got data (or an error). */ - if (error !=3D 0 || uio->uio_resid !=3D oresid) + tty_unlock(tp); + error =3D ureadc(TIOCPKT_DATA, uio); + if (error) + return (error); + tty_lock(tp); + } + + error =3D ttydisc_getc_uio(tp, uio); break; + } =20 /* Maybe the device isn't used anyway. */ if (tty_opened(tp) =3D=3D 0) @@ -147,6 +168,7 @@ if (error !=3D 0) break; } + tty_unlock(tp); =20 return (error); @@ -162,14 +184,14 @@ size_t iblen, rintlen; int error =3D 0; =20 - tty_lock(tp); + if (uio->uio_resid =3D=3D 0) + return (0); =20 - while (uio->uio_resid > 0) { - /* Temporarily unlock to buffer new characters. */ - tty_unlock(tp); + for (;;) { ibstart =3D ib; iblen =3D MIN(uio->uio_resid, sizeof ib); error =3D uiomove(ib, iblen, uio); + tty_lock(tp); if (error !=3D 0) goto done; @@ -178,7 +200,8 @@ * When possible, avoid the slow path. rint_bypass() * copies all input to the input queue at once. */ - while (iblen > 0) { + MPASS(iblen > 0); + do { if (ttydisc_can_bypass(tp)) { /* Store data at once. */ rintlen =3D ttydisc_rint_bypass(tp, @@ -188,7 +211,7 @@ =20 if (iblen =3D=3D 0) { /* All data written. */ - continue; + break; } } else { error =3D ttydisc_rint(tp, *ibstart, 0); @@ -217,7 +240,11 @@ error =3D cv_wait_sig(&psc->pts_inwait, tp->t_mtx); if (error !=3D 0) goto done; - } + } while (iblen > 0); + + if (uio->uio_resid =3D=3D 0) + break; + tty_unlock(tp); } =20 done: ttydisc_rint_done(tp); @@ -362,7 +389,8 @@ =20 if (events & (POLLIN|POLLRDNORM)) { /* See if we can getc something. */ - if (ttydisc_getc_poll(tp)) + if (ttydisc_getc_poll(tp) || + (psc->pts_flags & PTS_PKT && psc->pts_pkt)) revents |=3D events & (POLLIN|POLLRDNORM); } if (events & (POLLOUT|POLLWRNORM)) { @@ -481,6 +509,34 @@ } =20 static void +ptsdrv_pktnotify(struct tty *tp, char event) +{ + struct pts_softc *psc =3D tty_softc(tp); + + /* + * Clear conflicting flags. + */ + + switch (event) { + case TIOCPKT_STOP: + psc->pts_pkt &=3D ~TIOCPKT_START; + break; + case TIOCPKT_START: + psc->pts_pkt &=3D ~TIOCPKT_STOP; + break; + case TIOCPKT_NOSTOP: + psc->pts_pkt &=3D ~TIOCPKT_DOSTOP; + break; + case TIOCPKT_DOSTOP: + psc->pts_pkt &=3D ~TIOCPKT_NOSTOP; + break; + } + + psc->pts_pkt |=3D event; + ptsdrv_outwakeup(tp); +} + +static void ptsdrv_free(void *softc) { struct pts_softc *psc =3D softc; @@ -506,6 +562,7 @@ .tsw_outwakeup =3D ptsdrv_outwakeup, .tsw_inwakeup =3D ptsdrv_inwakeup, .tsw_close =3D ptsdrv_close, + .tsw_pktnotify =3D ptsdrv_pktnotify, .tsw_free =3D ptsdrv_free, }; =20 Index: sys/kern/tty.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/kern/tty.c (revision 182681) +++ sys/kern/tty.c (working copy) @@ -816,6 +816,11 @@ } =20 static void +ttydevsw_defpktnotify(struct tty *tp, char event) +{ +} + +static void ttydevsw_deffree(void *softc) { =20 @@ -846,6 +851,7 @@ PATCH_FUNC(param); PATCH_FUNC(modem); PATCH_FUNC(mmap); + PATCH_FUNC(pktnotify); PATCH_FUNC(free); #undef PATCH_FUNC =20 @@ -1226,11 +1232,13 @@ tp->t_flags &=3D ~TF_HIWAT_OUT; ttyoutq_flush(&tp->t_outq); tty_wakeup(tp, FWRITE); + ttydevsw_pktnotify(tp, TIOCPKT_FLUSHWRITE); } if (flags & FREAD) { tty_hiwat_in_unblock(tp); ttyinq_flush(&tp->t_inq); ttydevsw_inwakeup(tp); + ttydevsw_pktnotify(tp, TIOCPKT_FLUSHREAD); } } =20 @@ -1372,6 +1380,17 @@ ttyinq_canonicalize(&tp->t_inq); tty_wakeup(tp, FREAD); } + + /* + * For packet mode: notify the PTY consumer that VSTOP + * and VSTART may have been changed. + */ + if (tp->t_termios.c_iflag & IXON && + tp->t_termios.c_cc[VSTOP] =3D=3D CTRL('S') && + tp->t_termios.c_cc[VSTART] =3D=3D CTRL('Q')) + ttydevsw_pktnotify(tp, TIOCPKT_DOSTOP); + else + ttydevsw_pktnotify(tp, TIOCPKT_NOSTOP); return (0); } case TIOCGETD: @@ -1562,10 +1581,12 @@ return (0); case TIOCSTOP: tp->t_flags |=3D TF_STOPPED; + ttydevsw_pktnotify(tp, TIOCPKT_STOP); return (0); case TIOCSTART: tp->t_flags &=3D ~TF_STOPPED; ttydevsw_outwakeup(tp); + ttydevsw_pktnotify(tp, TIOCPKT_START); return (0); case TIOCSTAT: tty_info(tp); Index: sys/sys/ttydevsw.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/sys/ttydevsw.h (revision 182681) +++ sys/sys/ttydevsw.h (working copy) @@ -48,6 +48,7 @@ typedef int tsw_param_t(struct tty *, struct termios *); typedef int tsw_modem_t(struct tty *, int, int); typedef int tsw_mmap_t(struct tty *, vm_offset_t, vm_paddr_t *, int); +typedef void tsw_pktnotify_t(struct tty *, char); typedef void tsw_free_t(void *); =20 struct ttydevsw { @@ -64,6 +65,7 @@ tsw_modem_t *tsw_modem; /* Modem sigon/sigoff. */ =20 tsw_mmap_t *tsw_mmap; /* mmap() hooks. */ + tsw_pktnotify_t *tsw_pktnotify; /* TIOCPKT events. */ =20 tsw_free_t *tsw_free; /* Destructor. */ }; @@ -148,6 +150,15 @@ } =20 static __inline void +ttydevsw_pktnotify(struct tty *tp, char event) +{ + tty_lock_assert(tp, MA_OWNED); + MPASS(!tty_gone(tp)); + + tp->t_devsw->tsw_pktnotify(tp, event); +} + +static __inline void ttydevsw_free(struct tty *tp) { MPASS(tty_gone(tp)); --kn2F/kOnIYRmW7Hu-- --Zek6ooiun86DS3+c Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAki9bj8ACgkQ52SDGA2eCwUk3ACfTRsZXw8t/JdsJq/jFTKyDdoU 2AQAn3jd9jREmvDmuIxyH/rdA9Wnthy3 =rjaz -----END PGP SIGNATURE----- --Zek6ooiun86DS3+c-- From owner-freebsd-current@FreeBSD.ORG Tue Sep 2 16:57:52 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 916251065691 for ; Tue, 2 Sep 2008 16:57:52 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outY.internet-mail-service.net (outy.internet-mail-service.net [216.240.47.248]) by mx1.freebsd.org (Postfix) with ESMTP id 7EB0D8FC1D for ; Tue, 2 Sep 2008 16:57:52 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id C8D87249C; Tue, 2 Sep 2008 09:57:51 -0700 (PDT) Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 22F722D600D; Tue, 2 Sep 2008 09:57:51 -0700 (PDT) Message-ID: <48BD7095.3060406@elischer.org> Date: Tue, 02 Sep 2008 09:57:57 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: NAKAJI Hiroyuki References: <4824F1B4.6010302@elischer.org> <86wshuwpzm.fsf@ra333.heimat.gr.jp> In-Reply-To: <86wshuwpzm.fsf@ra333.heimat.gr.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Multiple routing table support commited X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2008 16:57:52 -0000 NAKAJI Hiroyuki wrote: > Thanks for your great work. > > Do you have a plan to MFC this feature to RELENG_6? > Or is it better to upgrade my RELENG6 box to RELENG_7? > > My ISP allows 5 PPPoE sessions but it always returns only one IP address > as HISADDR. I hope this FIB feature will help my multi PPPoE sessions. > > I tried "setfib -1 ppp anothersession" on my RELENG_7 box, which > complains > > Warning: iface add: ioctl(SIOCAIFADDR, 10.172.1.73 -> 210.247.16.1): File exists > > Maybe I misunderstand the usage. > >>>>>> In <4824F1B4.6010302@elischer.org> >>>>>> Julian Elischer wrote: >> I have committed the base of teh Multi-routing-table support. >> I am current;y waiting for it to loop back to me before a final >> make universe test, but I think it should be ok. >> if you do nothing you should not see any difference. I have a perforce branch with a RELENG_6 version but it will not be checked in. WE use it at work on 6 but we will go to 7 soon so we will not need to have it committed. we currently just add the patch when we do the build. From owner-freebsd-current@FreeBSD.ORG Tue Sep 2 16:59:07 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 42B091065679 for ; Tue, 2 Sep 2008 16:59:07 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outM.internet-mail-service.net (outm.internet-mail-service.net [216.240.47.236]) by mx1.freebsd.org (Postfix) with ESMTP id 30A5C8FC24 for ; Tue, 2 Sep 2008 16:59:07 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 3BCC523FB; Tue, 2 Sep 2008 09:59:07 -0700 (PDT) Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 5872F2D60AE; Tue, 2 Sep 2008 09:59:06 -0700 (PDT) Message-ID: <48BD70E1.4010201@elischer.org> Date: Tue, 02 Sep 2008 09:59:13 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: NAKAJI Hiroyuki References: <4824F1B4.6010302@elischer.org> <86wshuwpzm.fsf@ra333.heimat.gr.jp> In-Reply-To: <86wshuwpzm.fsf@ra333.heimat.gr.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Multiple routing table support commited X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2008 16:59:07 -0000 NAKAJI Hiroyuki wrote: > Thanks for your great work. > > Do you have a plan to MFC this feature to RELENG_6? > Or is it better to upgrade my RELENG6 box to RELENG_7? > > My ISP allows 5 PPPoE sessions but it always returns only one IP address > as HISADDR. I hope this FIB feature will help my multi PPPoE sessions. > > I tried "setfib -1 ppp anothersession" on my RELENG_7 box, which > complains > > Warning: iface add: ioctl(SIOCAIFADDR, 10.172.1.73 -> 210.247.16.1): File exists yes you need a later commit that I have not made to releng_7 yet. > > Maybe I misunderstand the usage. > >>>>>> In <4824F1B4.6010302@elischer.org> >>>>>> Julian Elischer wrote: >> I have committed the base of teh Multi-routing-table support. >> I am current;y waiting for it to loop back to me before a final >> make universe test, but I think it should be ok. >> if you do nothing you should not see any difference. From owner-freebsd-current@FreeBSD.ORG Tue Sep 2 17:41:26 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B5AEE1065677 for ; Tue, 2 Sep 2008 17:41:26 +0000 (UTC) (envelope-from caelian@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.189]) by mx1.freebsd.org (Postfix) with ESMTP id 45B438FC20 for ; Tue, 2 Sep 2008 17:41:25 +0000 (UTC) (envelope-from caelian@gmail.com) Received: by nf-out-0910.google.com with SMTP id h3so449107nfh.33 for ; Tue, 02 Sep 2008 10:41:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; 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; bh=bn51BbiyEOSUDg4MDO2mfzZEIdZvVx/rnP/BICWjKtg=; b=bXpTQ+Tjot38xrq7gjgTM9J4rx72EzhrVARpx341gudZtCW3wavvbaDsPvrOnvOVAu ZxJUfWRodAHrWAxiu8WNBCRdAkE8CmRniqeqRz43y60/X/rqLV9R+Ql0GAO8sy1itia2 8kBeRl+euFBSD6I8hfTAm1cQr6N2d5Xw+5s+w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=tuQwBhV5hago/KJj3Vmhizw3I9jQtjbsr48SdnBihmDAOGQi+ZFwwnKReViQnOOw56 4y3hsD5MqY08RXisBu7kfgOCGsNHBrBA4xs22NJtKs4faQk4yIx4UV+GYDTjQ01Zo3NS qWemz6PQHgWw6PbL7paiam2ojzEOrggX7+uNA= Received: by 10.210.46.12 with SMTP id t12mr8653063ebt.23.1220377284674; Tue, 02 Sep 2008 10:41:24 -0700 (PDT) Received: by 10.210.44.20 with HTTP; Tue, 2 Sep 2008 10:41:24 -0700 (PDT) Message-ID: Date: Tue, 2 Sep 2008 19:41:24 +0200 From: "Pascal Hofstee" To: "John Baldwin" In-Reply-To: <200809021033.55033.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20080830010551.GA2090@lorvorc.mips.inka.de> <200809021033.55033.jhb@freebsd.org> Cc: freebsd-current@freebsd.org, Christian Weisgerber Subject: Re: No root filesystem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2008 17:41:26 -0000 On Tue, Sep 2, 2008 at 4:33 PM, John Baldwin wrote: > This explains k8temp. So my earlier test patch to Christian only checked on > i386 which is why it didn't find an issue before. Try the updated patch at > http://www.FreeBSD.org/~jhb/patches/pcie.patch > > This does PCI config reads using both methods and panics if it doesn't get the > same result. I had to adjust the patch slightly by actually initializing edata to -1 to get the kernel to actually build (WARNS was complaining about possibly uninitialized variable edata). I then booted the resulting kernel and got the following boot log: [snip earlier parts of boot log] acpi0: <090607 RSDT1001> on motherboard PCIe: Memory Mapped configuration base @ 0xe0000000 ioapic0: routing intpin 9 (ISA IRQ 9) to vector 48 acpi0: [MPSAFE] acpi0: [ITHREAD] acpi0: Power Button (fixed) panic: pci_cfgread(0:24:0, 11, 1) => 0x6, 0xff cpuid = 0 According to pciconf -lv on a working kernel device 0:24:0 is the following: hostb0@pci0:0:24:0: class=0x060000 card=0x00000000 chip=0x11001022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = '(K8) Athlon 64/Opteron HyperTransport Technology Configuration' class = bridge subclass = HOST-PCI Which matches perfectly with the first previously mentioned missing devices that are normally attached to pcib0. -- Pascal Hofstee From owner-freebsd-current@FreeBSD.ORG Tue Sep 2 17:45:50 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0516D106564A for ; Tue, 2 Sep 2008 17:45:50 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from pele.citylink.co.nz (pele.citylink.co.nz [202.8.44.226]) by mx1.freebsd.org (Postfix) with ESMTP id BD9558FC1C for ; Tue, 2 Sep 2008 17:45:49 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) by pele.citylink.co.nz (Postfix) with ESMTP id 7FDC42BCB2 for ; Wed, 3 Sep 2008 05:45:48 +1200 (NZST) X-Virus-Scanned: Debian amavisd-new at citylink.co.nz Received: from pele.citylink.co.nz ([127.0.0.1]) by localhost (pele.citylink.co.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id scSieg8udp3U for ; Wed, 3 Sep 2008 05:45:41 +1200 (NZST) Received: from citylink.fud.org.nz (unknown [202.8.44.45]) by pele.citylink.co.nz (Postfix) with ESMTP for ; Wed, 3 Sep 2008 05:45:41 +1200 (NZST) Received: by citylink.fud.org.nz (Postfix, from userid 1001) id 64D511142A; Wed, 3 Sep 2008 05:45:40 +1200 (NZST) Date: Tue, 2 Sep 2008 10:45:40 -0700 From: Andrew Thompson To: current@freebsd.org Message-ID: <20080902174540.GB12367@citylink.fud.org.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.17 (2007-11-01) Cc: Subject: m_uiotombuf alignment X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2008 17:45:50 -0000 Hi, I have a patch here to removing the alignment of the align parameter. I can not see why it was added as it up to the caller to specify this, it breaks tap(4) on strict alignment machines as m_uiotombuf is called with ETHER_ALIGN. Also 'align' isnt a great description of this field, its more a padding or data offset. As far as I can see only SCTP uses this parameter in a non-trivial way and may be affected if it has assumed the 4byte alignment. Andrew Index: uipc_mbuf.c =================================================================== --- uipc_mbuf.c (revision 182549) +++ uipc_mbuf.c (working copy) @@ -1732,10 +1732,8 @@ m_uiotombuf(struct uio *uio, int how, int len, int /* * The smallest unit returned by m_getm2() is a single mbuf - * with pkthdr. We can't align past it. Align align itself. + * with pkthdr. We can't align past it. */ - if (align) - align &= ~(sizeof(long) - 1); if (align >= MHLEN) return (NULL); From owner-freebsd-current@FreeBSD.ORG Tue Sep 2 17:46:58 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 89BBF1065671 for ; Tue, 2 Sep 2008 17:46:58 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outH.internet-mail-service.net (outh.internet-mail-service.net [216.240.47.231]) by mx1.freebsd.org (Postfix) with ESMTP id 772FD8FC1F for ; Tue, 2 Sep 2008 17:46:58 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 9859624D9; Tue, 2 Sep 2008 10:46:58 -0700 (PDT) Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 024322D6032; Tue, 2 Sep 2008 10:46:56 -0700 (PDT) Message-ID: <48BD7C17.70800@elischer.org> Date: Tue, 02 Sep 2008 10:47:03 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: John Baldwin References: <200808291636.10656.jhb@FreeBSD.org> <48B86BB3.30705@elischer.org> <200809021036.53908.jhb@freebsd.org> In-Reply-To: <200809021036.53908.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: rtentry panic with FIB X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2008 17:46:58 -0000 John Baldwin wrote: > On Friday 29 August 2008 05:35:47 pm Julian Elischer wrote: >> John Baldwin wrote: >>> Unfortunately it hung trying to dump, so all I have is the stack trace > from >>> DDB. This is recent HEAD running stress2 >>> >>> panic: _mtx_lock_sleep: recursed on non-recursive mutex rtentry @ ../../1 >>> >> do you know what lock it was talking about? > > All I have is what I included in the original e-mail. So it's an "rtentry" > mutex, but that's all I know. You can try running the 'udp' test from > stress2 locally perhaps to see if you can trigger it. > 'scuse the ignorance but is that checked in somewhere? From owner-freebsd-current@FreeBSD.ORG Tue Sep 2 18:32:49 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AC8E91065672 for ; Tue, 2 Sep 2008 18:32:49 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from pele.citylink.co.nz (pele.citylink.co.nz [202.8.44.226]) by mx1.freebsd.org (Postfix) with ESMTP id 6AC1F8FC1A for ; Tue, 2 Sep 2008 18:32:49 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) by pele.citylink.co.nz (Postfix) with ESMTP id 59ED42BC5C; Wed, 3 Sep 2008 06:32:48 +1200 (NZST) X-Virus-Scanned: Debian amavisd-new at citylink.co.nz Received: from pele.citylink.co.nz ([127.0.0.1]) by localhost (pele.citylink.co.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 48QAenODF+BC; Wed, 3 Sep 2008 06:32:44 +1200 (NZST) Received: from citylink.fud.org.nz (unknown [202.8.44.45]) by pele.citylink.co.nz (Postfix) with ESMTP; Wed, 3 Sep 2008 06:32:44 +1200 (NZST) Received: by citylink.fud.org.nz (Postfix, from userid 1001) id 05C3E1142A; Wed, 3 Sep 2008 06:32:43 +1200 (NZST) Date: Tue, 2 Sep 2008 11:32:43 -0700 From: Andrew Thompson To: Maksim Yevmenkin Message-ID: <20080902183243.GC12367@citylink.fud.org.nz> References: <20080902174540.GB12367@citylink.fud.org.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Cc: current@freebsd.org Subject: Re: m_uiotombuf alignment X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2008 18:32:49 -0000 On Tue, Sep 02, 2008 at 10:54:08AM -0700, Maksim Yevmenkin wrote: > Andrew, > > > I have a patch here to removing the alignment of the align parameter. I > > can not see why it was added as it up to the caller to specify this, it > > breaks tap(4) on strict alignment machines as m_uiotombuf is called with > > ETHER_ALIGN. Also 'align' isnt a great description of this field, its > > more a padding or data offset. > > hmm... strange... from cvs > > === > > Revision 1.53 > Wed May 4 18:55:02 2005 UTC (3 years, 4 months ago) by emax > Branches: MAIN > > Change m_uiotombuf so it will accept offset at which data should be copied > to the mbuf. Offset cannot exceed MHLEN bytes. This is currently used to > fix Ethernet header alignment problem on alpha and sparc64. Also change all > users of m_uiotombuf to pass proper offset. > > Reviewed by: jmg, sam > Tested by: Sten Spans "sten AT blinkenlights DOT nl" > MFC after: 1 week > > === > > could you please explain how and on which platforms it breaks tap(4)? That revision had the correct behaviour, it was broken in r1.169 Rewrite m_uiotombuf() to use m_getm2() for mbuf allocation and do the uiomove() in a tight loop over the mbuf chain. Add a flags parameter to accept mbuf flags to be passed to m_getm2(). Adjust all callers for the extra parameter. Sponsored by: TCP/IP Optimization Fundraise 2005 Andrew From owner-freebsd-current@FreeBSD.ORG Tue Sep 2 18:41:12 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8C9E81065670 for ; Tue, 2 Sep 2008 18:41:12 +0000 (UTC) (envelope-from freebsd-current@adam.gs) Received: from mail.adam.gs (cl-127.ewr-01.us.sixxs.net [IPv6:2001:4830:1200:7e::2]) by mx1.freebsd.org (Postfix) with ESMTP id 180118FC2C for ; Tue, 2 Sep 2008 18:41:12 +0000 (UTC) (envelope-from freebsd-current@adam.gs) Received: from [127.0.0.1] (localhost.adam.gs [127.0.0.1]) by mail.adam.gs (Postfix) with ESMTP id 99888F8D61D for ; Tue, 2 Sep 2008 14:41:10 -0400 (EDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=mail; d=adam.gs; b=Qy4SktDGZf3OQ4mxIAR62j/qaE4uOwFhLdKS+XQghXt2G27xFpWXYksHGyvvo28BQFEuRbZ3iDqEoaXomWJOb8mHpULGVMdRWvI/GECR8GJrIhtKtKdhdGm7m4ZNYF/WPnMZWcTSK9xc/n3CaRSx77D2Vo7pGu1//Zv2iuyolk4=; Message-Id: From: Adam Jacob Muller To: Kostik Belousov In-Reply-To: <20080901145315.GU2038@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v928.1) Date: Tue, 2 Sep 2008 14:41:08 -0400 References: <20080830183804.GG2038@deviant.kiev.zoral.com.ua> <20080830195844.GI2038@deviant.kiev.zoral.com.ua> <20080831071618.GK2038@deviant.kiev.zoral.com.ua> <20080831091639.GM2038@deviant.kiev.zoral.com.ua> <80861bfa0809010733h47580d3evb3eb68c972a2bb25@mail.gmail.com> <20080901145315.GU2038@deviant.kiev.zoral.com.ua> X-Authentication: 5Y9zP9uohPVCIKSKssvSwTvzf0+nN8I7IHuNjRHchA2ZGkQ0S1nNBDHYYPDC3FPZGd9A1cjjjyDCoZ9VN+JLpLiSCkZVi7UuiAa/zQMWg10/YCOcNIalQ2HNL//J/eqV60ibrXDFlBGWDW/aW03wCn3+ZAGKOzfiwburp0e9qa2uGm7X2FGol2eC+A== Cc: freebsd-current@freebsd.org, Vyacheslav Bocharov Subject: Re: __tls_get_addr problem with recent current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2008 18:41:12 -0000 On Sep 1, 2008, at 10:53 AM, Kostik Belousov wrote: > On Mon, Sep 01, 2008 at 05:33:37PM +0300, Vyacheslav Bocharov wrote: >> I have similar problem in 7-STABLE (from 1 sep): >> 32bit application exec 64application and we have an core dump: >> >> # gdb fw.sh fw.sh.core >> GNU gdb 6.1.1 [FreeBSD] >> Copyright 2004 Free Software Foundation, Inc. >> GDB is free software, covered by the GNU General Public License, >> and you are >> welcome to change it and/or distribute copies of it under certain >> conditions. >> Type "show copying" to see the conditions. >> There is absolutely no warranty for GDB. Type "show warranty" for >> details. >> This GDB was configured as "amd64-marcel-freebsd"... >> Core was generated by `fw.sh'. >> Program terminated with signal 11, Segmentation fault. >> Reading symbols from /usr/lib/libstdc++.so.6...done. >> Loaded symbols for /usr/lib/libstdc++.so.6 >> Reading symbols from /lib/libm.so.5...done. >> Loaded symbols for /lib/libm.so.5 >> Reading symbols from /lib/libgcc_s.so.1...done. >> Loaded symbols for /lib/libgcc_s.so.1 >> Reading symbols from /lib/libc.so.7...done. >> Loaded symbols for /lib/libc.so.7 >> Reading symbols from /libexec/ld-elf.so.1...done. >> Loaded symbols for /libexec/ld-elf.so.1 >> #0 0x0000000800507483 in __tls_get_addr () from /libexec/ld-elf.so.1 >> (gdb) bt >> #0 0x0000000800507483 in __tls_get_addr () from /libexec/ld-elf.so.1 >> #1 0x0000000800ad8892 in _pthread_mutex_init_calloc_cb () from >> /lib/libc.so.7 >> #2 0x0000000800ada35f in malloc () from /lib/libc.so.7 >> #3 0x00000008007050ad in operator new () from /usr/lib/libstdc+ >> +.so.6 >> #4 0x00000008006b5f21 in std::string::_Rep::_S_create () >> from /usr/lib/libstdc++.so.6 >> #5 0x00000008006b6ca5 in std::string::_S_copy_chars () >> from /usr/lib/libstdc++.so.6 >> #6 0x00000008006b6dc2 in std::basic_string> std::char_traits, >> std::allocator >::basic_string () from /usr/lib/libstdc++.so.6 >> #7 0x00000000004021ec in __static_initialization_and_destruction_0 ( >> __initialize_p=1, __priority=65535) at CCmdLine.cpp:16 >> #8 0x00000000004026c3 in global constructors keyed to cmdlist () >> at CCmdLine.cpp:177 >> #9 0x00000000004033a2 in __do_global_ctors_aux () >> #10 0x000000000040113e in _init () >> #11 0x0000000800b2b0c0 in __cxa_atexit () from /lib/libc.so.7 >> #12 0x00000000004014e8 in _start () >> #13 0x000000080052c000 in ?? () >> >> I tried your patch but nothing changed. > Exactly which patch ? There were three, one of which caused immediate > panic. I put the patches at > http://people.freebsd.org/~kib/misc/fsbase.1.patch > http://people.freebsd.org/~kib/misc/fsbase.2.patch > > Could you, please, try both and report the results ? > And, isolated test case, as several C files or recipe to reproduce > this with base system, would be ideal. > >> >> 2008/8/31 Kostik Belousov >> >>> On Sun, Aug 31, 2008 at 10:16:18AM +0300, Kostik Belousov wrote: >>>> On Sat, Aug 30, 2008 at 02:03:00PM -0700, Artem Belevich wrote: >>>>> With the new patch kernel has crashed as soon as I ran i386 app, >>>>> though the crash happened within in-kernel thread g_up: >>>>> >>>>> Fatal trap 12: page fault while in kernel mode >>>>> cpuid = 2; apic id = 02 >>>>> fault virtual address = 0x20 >>>>> fault code = supervisor read data, page not present >>>>> instruction pointer = 0x8:0xffffffff804a821f >>>>> stack pointer = 0x10:0xffffffffac280b60 >>>>> frame pointer = 0x10:0x0 >>>>> code segment = base 0x0, limit 0xfffff, type 0x1b >>>>> = DPL 0, pres 1, long 1, def32 0, gran 1 >>>>> processor eflags = resume, IOPL = 0 >>>>> current process = 3 (g_up) >>>>> trap number = 12 >>>>> panic: page fault >>>>> cpuid = 2 >>>>> Uptime: 37s >>>>> Physical memory: 8169 MB >>>>> Dumping 380 MB: 365 349 333 317 301 285 269 253 237 221 205 189 >>>>> 173 >>>>> 157 141 125 109 93 77 61 45 29 13 >>>> Could you, please, show me the disassembled code around the faulted >>>> %rip ? >>> >>> No need, it seems I found the problem. I trashed the %rdx that >>> contains >>> the third cpu_switch argument. Please, try the updated patch. >>> >>> Thanks for the testing ! >>> >>> diff --git a/sys/amd64/amd64/cpu_switch.S b/sys/amd64/amd64/ >>> cpu_switch.S >>> index f34b0cc..03f0eca 100644 >>> --- a/sys/amd64/amd64/cpu_switch.S >>> +++ b/sys/amd64/amd64/cpu_switch.S >>> @@ -249,6 +249,12 @@ store_seg: >>> 1: movl %ds,PCB_DS(%r8) >>> movl %es,PCB_ES(%r8) >>> movl %fs,PCB_FS(%r8) >>> + movq %rdx,%r11 >>> + movl $MSR_FSBASE,%ecx >>> + rdmsr >>> + shlq $32,%rdx >>> + leaq (%rax,%rdx),%r9 >>> + movq %r11,%rdx >>> jmp done_store_seg >>> 2: movq PCB_GS32P(%r8),%rax >>> movq (%rax),%rax >>> >> >> >> >> -- >> Vyacheslav Bocharov Hi, i have this same issue on recent RELENG_7 (pre and post 7.1- PRERELEASE), the issue was reproducible by a simple c-app compiled on 7.x 32-bit #include main() { execl("/bin/ls", "/bin/ls", (char *) 0); } this app will segfault rather reliably (but not 100% of the time) (while true;do ./test; if [ "$?" -gt "0" ];then break; fi; done). patch 1 (http://people.freebsd.org/~kib/misc/fsbase.1.patch) fixes the issue for me patch 2 (http://people.freebsd.org/~kib/misc/fsbase.2.patch) does not though it may mitigate it slightly (cause things to crash less frequently) -Adam From owner-freebsd-current@FreeBSD.ORG Tue Sep 2 18:44:39 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C63E91065675 for ; Tue, 2 Sep 2008 18:44:39 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.terabit.net.ua (mail.terabit.net.ua [195.137.202.147]) by mx1.freebsd.org (Postfix) with ESMTP id 442B78FC1A for ; Tue, 2 Sep 2008 18:44:39 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from skuns.zoral.com.ua ([91.193.166.194] helo=mail.zoral.com.ua) by mail.terabit.net.ua with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1Kaarl-0002vb-5j; Tue, 02 Sep 2008 21:44:37 +0300 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m82IiUwL022379 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Sep 2008 21:44:30 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m82IiUFX054967; Tue, 2 Sep 2008 21:44:30 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id m82IiUM3054966; Tue, 2 Sep 2008 21:44:30 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 2 Sep 2008 21:44:30 +0300 From: Kostik Belousov To: Adam Jacob Muller Message-ID: <20080902184429.GB2038@deviant.kiev.zoral.com.ua> References: <20080830183804.GG2038@deviant.kiev.zoral.com.ua> <20080830195844.GI2038@deviant.kiev.zoral.com.ua> <20080831071618.GK2038@deviant.kiev.zoral.com.ua> <20080831091639.GM2038@deviant.kiev.zoral.com.ua> <80861bfa0809010733h47580d3evb3eb68c972a2bb25@mail.gmail.com> <20080901145315.GU2038@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4rh8KwHgidtw24lr" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua X-Virus-Scanned: mail.terabit.net.ua 1Kaarl-0002vb-5j 0aa25621ca5a7c5469071f0727456f72 X-Terabit: YES Cc: freebsd-current@freebsd.org, Vyacheslav Bocharov Subject: Re: __tls_get_addr problem with recent current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2008 18:44:39 -0000 --4rh8KwHgidtw24lr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 02, 2008 at 02:41:08PM -0400, Adam Jacob Muller wrote: >=20 > On Sep 1, 2008, at 10:53 AM, Kostik Belousov wrote: >=20 > >On Mon, Sep 01, 2008 at 05:33:37PM +0300, Vyacheslav Bocharov wrote: > >>I have similar problem in 7-STABLE (from 1 sep): > >>32bit application exec 64application and we have an core dump: > >> > >># gdb fw.sh fw.sh.core > >>GNU gdb 6.1.1 [FreeBSD] > >>Copyright 2004 Free Software Foundation, Inc. > >>GDB is free software, covered by the GNU General Public License, =20 > >>and you are > >>welcome to change it and/or distribute copies of it under certain > >>conditions. > >>Type "show copying" to see the conditions. > >>There is absolutely no warranty for GDB. Type "show warranty" for =20 > >>details. > >>This GDB was configured as "amd64-marcel-freebsd"... > >>Core was generated by `fw.sh'. > >>Program terminated with signal 11, Segmentation fault. > >>Reading symbols from /usr/lib/libstdc++.so.6...done. > >>Loaded symbols for /usr/lib/libstdc++.so.6 > >>Reading symbols from /lib/libm.so.5...done. > >>Loaded symbols for /lib/libm.so.5 > >>Reading symbols from /lib/libgcc_s.so.1...done. > >>Loaded symbols for /lib/libgcc_s.so.1 > >>Reading symbols from /lib/libc.so.7...done. > >>Loaded symbols for /lib/libc.so.7 > >>Reading symbols from /libexec/ld-elf.so.1...done. > >>Loaded symbols for /libexec/ld-elf.so.1 > >>#0 0x0000000800507483 in __tls_get_addr () from /libexec/ld-elf.so.1 > >>(gdb) bt > >>#0 0x0000000800507483 in __tls_get_addr () from /libexec/ld-elf.so.1 > >>#1 0x0000000800ad8892 in _pthread_mutex_init_calloc_cb () from > >>/lib/libc.so.7 > >>#2 0x0000000800ada35f in malloc () from /lib/libc.so.7 > >>#3 0x00000008007050ad in operator new () from /usr/lib/libstdc+=20 > >>+.so.6 > >>#4 0x00000008006b5f21 in std::string::_Rep::_S_create () > >> from /usr/lib/libstdc++.so.6 > >>#5 0x00000008006b6ca5 in std::string::_S_copy_chars () > >> from /usr/lib/libstdc++.so.6 > >>#6 0x00000008006b6dc2 in std::basic_string >>std::char_traits, > >>std::allocator >::basic_string () from /usr/lib/libstdc++.so.6 > >>#7 0x00000000004021ec in __static_initialization_and_destruction_0 ( > >> __initialize_p=3D1, __priority=3D65535) at CCmdLine.cpp:16 > >>#8 0x00000000004026c3 in global constructors keyed to cmdlist () > >> at CCmdLine.cpp:177 > >>#9 0x00000000004033a2 in __do_global_ctors_aux () > >>#10 0x000000000040113e in _init () > >>#11 0x0000000800b2b0c0 in __cxa_atexit () from /lib/libc.so.7 > >>#12 0x00000000004014e8 in _start () > >>#13 0x000000080052c000 in ?? () > >> > >>I tried your patch but nothing changed. > >Exactly which patch ? There were three, one of which caused immediate > >panic. I put the patches at > >http://people.freebsd.org/~kib/misc/fsbase.1.patch > >http://people.freebsd.org/~kib/misc/fsbase.2.patch > > > >Could you, please, try both and report the results ? > >And, isolated test case, as several C files or recipe to reproduce > >this with base system, would be ideal. > > > >> > >>2008/8/31 Kostik Belousov > >> > >>>On Sun, Aug 31, 2008 at 10:16:18AM +0300, Kostik Belousov wrote: > >>>>On Sat, Aug 30, 2008 at 02:03:00PM -0700, Artem Belevich wrote: > >>>>>With the new patch kernel has crashed as soon as I ran i386 app, > >>>>>though the crash happened within in-kernel thread g_up: > >>>>> > >>>>>Fatal trap 12: page fault while in kernel mode > >>>>>cpuid =3D 2; apic id =3D 02 > >>>>>fault virtual address =3D 0x20 > >>>>>fault code =3D supervisor read data, page not present > >>>>>instruction pointer =3D 0x8:0xffffffff804a821f > >>>>>stack pointer =3D 0x10:0xffffffffac280b60 > >>>>>frame pointer =3D 0x10:0x0 > >>>>>code segment =3D base 0x0, limit 0xfffff, type 0x1b > >>>>> =3D DPL 0, pres 1, long 1, def32 0, gran 1 > >>>>>processor eflags =3D resume, IOPL =3D 0 > >>>>>current process =3D 3 (g_up) > >>>>>trap number =3D 12 > >>>>>panic: page fault > >>>>>cpuid =3D 2 > >>>>>Uptime: 37s > >>>>>Physical memory: 8169 MB > >>>>>Dumping 380 MB: 365 349 333 317 301 285 269 253 237 221 205 189 =20 > >>>>>173 > >>>>>157 141 125 109 93 77 61 45 29 13 > >>>>Could you, please, show me the disassembled code around the faulted > >>>>%rip ? > >>> > >>>No need, it seems I found the problem. I trashed the %rdx that =20 > >>>contains > >>>the third cpu_switch argument. Please, try the updated patch. > >>> > >>>Thanks for the testing ! > >>> > >>>diff --git a/sys/amd64/amd64/cpu_switch.S b/sys/amd64/amd64/=20 > >>>cpu_switch.S > >>>index f34b0cc..03f0eca 100644 > >>>--- a/sys/amd64/amd64/cpu_switch.S > >>>+++ b/sys/amd64/amd64/cpu_switch.S > >>>@@ -249,6 +249,12 @@ store_seg: > >>>1: movl %ds,PCB_DS(%r8) > >>> movl %es,PCB_ES(%r8) > >>> movl %fs,PCB_FS(%r8) > >>>+ movq %rdx,%r11 > >>>+ movl $MSR_FSBASE,%ecx > >>>+ rdmsr > >>>+ shlq $32,%rdx > >>>+ leaq (%rax,%rdx),%r9 > >>>+ movq %r11,%rdx > >>> jmp done_store_seg > >>>2: movq PCB_GS32P(%r8),%rax > >>> movq (%rax),%rax > >>> > >> > >> > >> > >>--=20 > >>Vyacheslav Bocharov >=20 >=20 >=20 > Hi, > i have this same issue on recent RELENG_7 (pre and post 7.1-=20 > PRERELEASE), the issue was reproducible by a simple c-app compiled on =20 > 7.x 32-bit >=20 > #include > main() > { > execl("/bin/ls", "/bin/ls", (char *) 0); > } >=20 > this app will segfault rather reliably (but not 100% of the time) =20 > (while true;do ./test; if [ "$?" -gt "0" ];then break; fi; done). >=20 > patch 1 (http://people.freebsd.org/~kib/misc/fsbase.1.patch) fixes the = =20 > issue for me > patch 2 (http://people.freebsd.org/~kib/misc/fsbase.2.patch) does not =20 > though it may mitigate it slightly (cause things to crash less =20 > frequently) Patch below was committed to current, it shall address your issue. diff --git a/sys/amd64/amd64/cpu_switch.S b/sys/amd64/amd64/cpu_switch.S index f34b0cc..a0b11f8 100644 --- a/sys/amd64/amd64/cpu_switch.S +++ b/sys/amd64/amd64/cpu_switch.S @@ -109,8 +109,24 @@ ENTRY(cpu_switch) movq %rsp,PCB_RSP(%r8) movq %rbx,PCB_RBX(%r8) movq %rax,PCB_RIP(%r8) - movq PCB_FSBASE(%r8),%r9 - movq PCB_GSBASE(%r8),%r10 + + /* + * Reread fs and gs bases. Explicit fs segment register load + * by the usermode code may change actual fs base without + * updating pcb_{fs,gs}base. + * + * %rdx still contains the mtx, save %rdx around rdmsr. + */ + movq %rdx,%r11 + movl $MSR_FSBASE,%ecx + rdmsr + shlq $32,%rdx + leaq (%rax,%rdx),%r9 + movl $MSR_KGSBASE,%ecx + rdmsr + shlq $32,%rdx + leaq (%rax,%rdx),%r10 + movq %r11,%rdx =20 testl $PCB_32BIT,PCB_FLAGS(%r8) jnz store_seg diff --git a/sys/amd64/amd64/machdep.c b/sys/amd64/amd64/machdep.c index 06c0803..f3c41f7 100644 --- a/sys/amd64/amd64/machdep.c +++ b/sys/amd64/amd64/machdep.c @@ -734,6 +734,7 @@ exec_setregs(td, entry, stack, ps_strings) pcb->pcb_fsbase =3D 0; pcb->pcb_gsbase =3D 0; critical_exit(); + pcb->pcb_flags &=3D ~(PCB_32BIT | PCB_GS32BIT); load_ds(_udatasel); load_es(_udatasel); load_fs(_udatasel); diff --git a/sys/amd64/ia32/ia32_signal.c b/sys/amd64/ia32/ia32_signal.c index 9e98656..162dcf9 100644 --- a/sys/amd64/ia32/ia32_signal.c +++ b/sys/amd64/ia32/ia32_signal.c @@ -742,5 +742,6 @@ ia32_setregs(td, entry, stack, ps_strings) =20 /* Return via doreti so that we can change to a different %cs */ pcb->pcb_flags |=3D PCB_FULLCTX | PCB_32BIT; + pcb->pcb_flags &=3D ~PCB_GS32BIT; td->td_retval[1] =3D 0; } --4rh8KwHgidtw24lr Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAki9iY0ACgkQC3+MBN1Mb4io6ACffUbwirUsrG+W+Tm6p3iiubId 1IsAoM17j/oi6+N2hZlY9TZPzK4WKZhF =YEdn -----END PGP SIGNATURE----- --4rh8KwHgidtw24lr-- From owner-freebsd-current@FreeBSD.ORG Tue Sep 2 18:56:58 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C3C8010656CF for ; Tue, 2 Sep 2008 18:56:57 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.152]) by mx1.freebsd.org (Postfix) with ESMTP id 1AAE88FC90 for ; Tue, 2 Sep 2008 18:53:34 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so1593029fgb.35 for ; Tue, 02 Sep 2008 11:53:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; 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; bh=BLJGy/cgf1kB687+m4MMag2Y3UFBSj8JSw0MbwpApEA=; b=XWC91jICK/4fwVEj+kSzb4LXS06nrbH4e6aZlizjsvA8lcUTC0B1ua79Og0DqlfeG3 vtvxhzf6ZHOv4F+WmcYOffTGTtTK/fdFN8D7E/SI7/lOMb9f9JGlKSCMHtrf1dAntb1k NPdNXOPXEZuD9SXP5jQTYrWlbGeJ7ZdsscDVY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=mg0fZG4EeQLbuTrCaGtrF/Qfjj8PF4MxD0exx7ymSCDcn0DXxHgeSRM2j5BPqA2THY MOfyjzFfQHJvksSrl4/dcLlvnOoynpnqgRhSWiq8ALjd4kCONFGLxSLpcCqzcMKuCNop sVSonDP/4waKTI9geivlD9m58LMAYrj/Lzdcw= Received: by 10.86.79.19 with SMTP id c19mr5871026fgb.79.1220381611000; Tue, 02 Sep 2008 11:53:31 -0700 (PDT) Received: by 10.86.70.1 with HTTP; Tue, 2 Sep 2008 11:53:30 -0700 (PDT) Message-ID: Date: Tue, 2 Sep 2008 11:53:30 -0700 From: "Maksim Yevmenkin" To: "Andrew Thompson" In-Reply-To: <20080902183243.GC12367@citylink.fud.org.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20080902174540.GB12367@citylink.fud.org.nz> <20080902183243.GC12367@citylink.fud.org.nz> Cc: current@freebsd.org Subject: Re: m_uiotombuf alignment X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2008 18:57:02 -0000 On 9/2/08, Andrew Thompson wrote: > On Tue, Sep 02, 2008 at 10:54:08AM -0700, Maksim Yevmenkin wrote: > > Andrew, > > > > > I have a patch here to removing the alignment of the align parameter. I > > > can not see why it was added as it up to the caller to specify this, it > > > breaks tap(4) on strict alignment machines as m_uiotombuf is called with > > > ETHER_ALIGN. Also 'align' isnt a great description of this field, its > > > more a padding or data offset. > > > > hmm... strange... from cvs > > > > === > > > > Revision 1.53 > > Wed May 4 18:55:02 2005 UTC (3 years, 4 months ago) by emax > > Branches: MAIN > > > > Change m_uiotombuf so it will accept offset at which data should be copied > > to the mbuf. Offset cannot exceed MHLEN bytes. This is currently used to > > fix Ethernet header alignment problem on alpha and sparc64. Also change all > > users of m_uiotombuf to pass proper offset. > > > > Reviewed by: jmg, sam > > Tested by: Sten Spans "sten AT blinkenlights DOT nl" > > MFC after: 1 week > > > > === > > > > could you please explain how and on which platforms it breaks tap(4)? > > > That revision had the correct behaviour, it was broken in r1.169 > > Rewrite m_uiotombuf() to use m_getm2() for mbuf allocation and do the > uiomove() in a tight loop over the mbuf chain. Add a flags parameter to > accept mbuf flags to be passed to m_getm2(). Adjust all callers for the > extra parameter. > > Sponsored by: TCP/IP Optimization Fundraise 2005 ahh... i see... i was looking at the wrong revision :) yes, i agree with you. i do not see the reason for the alignment of the align parameter. thanks, max From owner-freebsd-current@FreeBSD.ORG Tue Sep 2 19:02:24 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 30089106567C for ; Tue, 2 Sep 2008 19:02:24 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by mx1.freebsd.org (Postfix) with ESMTP id 2BC388FC27 for ; Tue, 2 Sep 2008 19:02:22 +0000 (UTC) (envelope-from artemb@gmail.com) Received: by ey-out-2122.google.com with SMTP id 6so997523eyi.7 for ; Tue, 02 Sep 2008 12:02:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; 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; bh=0skUkmKE6EQ765jT6DAZ484pdRr8FbJuciOJPNntvns=; b=gEKn340sRCbXylSHrkbZT8QgvEVryg3iFoWouCvO1pUgyw2UkFkBB1lozqUo0tByAY H1ieVcSs9uLfqy3NDJDrzGK0rdZXJB/WF+mddBlGnKfHavz1DJ6HjGg+C3NZieAWUnlR Kyzgw5Mrsr6wnx63dP+0Wnp+s7VCO9zMkkkc0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=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=t6Y1RrY/1HjHTVrb/VKYjst8TMldazvC/C9xqanmHWRej9wknno0UhuzXL4bMYbjlv MsTFAjku5EFlY3VPNaVGEzx3iltqmTathBu7ZRueZSdZBwJJeV6E6199U8V3ME6vachG 1cnH3/qRIv2cnjuV1/CKQU24vUZmI9wLqy9Us= Received: by 10.210.92.8 with SMTP id p8mr8769540ebb.7.1220382140304; Tue, 02 Sep 2008 12:02:20 -0700 (PDT) Received: by 10.210.128.7 with HTTP; Tue, 2 Sep 2008 12:02:20 -0700 (PDT) Message-ID: Date: Tue, 2 Sep 2008 12:02:20 -0700 From: "Artem Belevich" Sender: artemb@gmail.com To: "Kostik Belousov" In-Reply-To: <20080902153135.GZ2038@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20080830183804.GG2038@deviant.kiev.zoral.com.ua> <20080830195844.GI2038@deviant.kiev.zoral.com.ua> <20080831071618.GK2038@deviant.kiev.zoral.com.ua> <20080831091639.GM2038@deviant.kiev.zoral.com.ua> <20080902153135.GZ2038@deviant.kiev.zoral.com.ua> X-Google-Sender-Auth: a340882660ba0041 Cc: freebsd-current@freebsd.org Subject: Re: __tls_get_addr problem with recent current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2008 19:02:24 -0000 The latest patch works fine. > Ok, below is the updated patch, that fixes additional problem with > execution of 64bit binaries from 32bit processes. I am not sure whether > your test load includes such operation, but it cannot hurt anyway. Yes, my workload does include running 64-bit binaries from 32-bit ones. --Artem On 9/2/08, Kostik Belousov wrote: > On Sun, Aug 31, 2008 at 11:43:08AM -0700, Artem Belevich wrote: > > I'll not be able to try it till Tuesday. I've been running these > > experiments on a remote box without remotely accessible console. At > > some point yesterday the box had failed to reboot, so no more > > experiments untill I get back to work and restart the system. > > > Ok, below is the updated patch, that fixes additional problem with > execution of 64bit binaries from 32bit processes. I am not sure whether > your test load includes such operation, but it cannot hurt anyway. > > > diff --git a/sys/amd64/amd64/cpu_switch.S b/sys/amd64/amd64/cpu_switch.S > index f34b0cc..03f0eca 100644 > --- a/sys/amd64/amd64/cpu_switch.S > +++ b/sys/amd64/amd64/cpu_switch.S > @@ -249,6 +249,12 @@ store_seg: > 1: movl %ds,PCB_DS(%r8) > movl %es,PCB_ES(%r8) > movl %fs,PCB_FS(%r8) > + movq %rdx,%r11 > + movl $MSR_FSBASE,%ecx > + rdmsr > + shlq $32,%rdx > + leaq (%rax,%rdx),%r9 > + movq %r11,%rdx > jmp done_store_seg > 2: movq PCB_GS32P(%r8),%rax > movq (%rax),%rax > > diff --git a/sys/amd64/amd64/machdep.c b/sys/amd64/amd64/machdep.c > index 06c0803..f3c41f7 100644 > --- a/sys/amd64/amd64/machdep.c > +++ b/sys/amd64/amd64/machdep.c > @@ -734,6 +734,7 @@ exec_setregs(td, entry, stack, ps_strings) > pcb->pcb_fsbase = 0; > pcb->pcb_gsbase = 0; > critical_exit(); > + pcb->pcb_flags &= ~(PCB_32BIT | PCB_GS32BIT); > load_ds(_udatasel); > load_es(_udatasel); > load_fs(_udatasel); > diff --git a/sys/amd64/ia32/ia32_signal.c b/sys/amd64/ia32/ia32_signal.c > index 9e98656..162dcf9 100644 > --- a/sys/amd64/ia32/ia32_signal.c > +++ b/sys/amd64/ia32/ia32_signal.c > @@ -742,5 +742,6 @@ ia32_setregs(td, entry, stack, ps_strings) > > /* Return via doreti so that we can change to a different %cs */ > pcb->pcb_flags |= PCB_FULLCTX | PCB_32BIT; > + pcb->pcb_flags &= ~PCB_GS32BIT; > td->td_retval[1] = 0; > } > > -- --Artem From owner-freebsd-current@FreeBSD.ORG Tue Sep 2 19:06:41 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B5F6E106567A for ; Tue, 2 Sep 2008 19:06:41 +0000 (UTC) (envelope-from Yuriy.Tsibizov@gfk.com) Received: from mx2.gfk.ru (mx2.gfk.ru [84.21.231.139]) by mx1.freebsd.org (Postfix) with ESMTP id 080E78FC13 for ; Tue, 2 Sep 2008 19:06:40 +0000 (UTC) (envelope-from Yuriy.Tsibizov@gfk.com) Received: from ex.hhp.local by mx2.gfk.ru (MDaemon PRO v9.6.0) with ESMTP id md50001769123.msg for ; Tue, 02 Sep 2008 23:06:52 +0400 Received: from bootserv.hhp.local ([10.0.0.54]) by ex.hhp.local with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Sep 2008 23:06:49 +0400 Date: Tue, 2 Sep 2008 23:08:20 +0400 (MSD) From: Yuriy Tsibizov X-X-Sender: chibis@atwork.home.local To: Ed Schouten In-Reply-To: <20080902063016.GK99951@hoeg.nl> Message-ID: <20080902225533.O3497@atwork.home.local> References: <200809011335.m81DZW8b006033@pozo.com> <200809011436.m81Eaq2v040141@pozo.com> <20080902095229.Y1605@atwork.home.local> <20080902063016.GK99951@hoeg.nl> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="789136512-1465995021-1220382500=:3497" X-OriginalArrivalTime: 02 Sep 2008 19:06:49.0131 (UTC) FILETIME=[0D1BA7B0:01C90D2F] X-Spam-Processed: mx2.gfk.ru, Tue, 02 Sep 2008 23:06:52 +0400 (not processed: message from valid local sender) X-MDRemoteIP: 10.0.0.30 X-Return-Path: Yuriy.Tsibizov@gfk.com X-Envelope-From: Yuriy.Tsibizov@gfk.com X-MDaemon-Deliver-To: freebsd-current@freebsd.org X-MDAV-Processed: mx2.gfk.ru, Tue, 02 Sep 2008 23:06:54 +0400 Cc: Yuriy Tsibizov , FreeBSD Current Subject: Re: /usr/bin/limits (WAS: Re: Apache.sh on current) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2008 19:06:41 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --789136512-1465995021-1220382500=:3497 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed On Tue, 2 Sep 2008, Ed Schouten wrote: > Looks like I introduced this regression when importing MPSAFE TTY. > limits(1) dies when RLIMIT_NLIMITS is increased, but the array in > limits.c isn't extended (seems to be quite fragile). > > Can you try the attached patch for limits(1)? Thanks! Yes, it solves that problem. You may also want to add -p switch to man page and fix some other places in limits.c (see attached files). We also have built-in 'limit' in csh -- should it be updated as well? Yuriy Tsibizov, GfK RUS Network Administrator --789136512-1465995021-1220382500=:3497 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=limits.c.diff Content-Transfer-Encoding: BASE64 Content-ID: <20080902230820.Q3497@atwork.home.local> Content-Description: Content-Disposition: attachment; filename=limits.c.diff SW5kZXg6IGxpbWl0cy5jDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQpSQ1Mg ZmlsZTogL2hvbWUvbmN2cy9zcmMvdXNyLmJpbi9saW1pdHMvbGltaXRzLmMs dg0KcmV0cmlldmluZyByZXZpc2lvbiAxLjE3DQpkaWZmIC11IC1yMS4xNyBs aW1pdHMuYw0KLS0tIGxpbWl0cy5jCTQgSnVsIDIwMDcgMDA6MDA6NDAgLTAw MDAJMS4xNw0KKysrIGxpbWl0cy5jCTIgU2VwIDIwMDggMTg6MTM6MDcgLTAw MDANCkBAIC03NiwxNyArNzYsMTggQEANCiB7DQogICAgIHsgIiIsICJpbmZp bml0eSIsICJSZXNvdXJjZSBsaW1pdHMlcyVzOlxuIiwgIi1tYXgiLCAiLWN1 ciIsICIiLA0KICAgICAgIHsNCi0JICB7ICIgIGNwdXRpbWUlLTRzICAgICAg JThzIiwgIiBzZWNzXG4iLCAgMSAgICB9LA0KLQkgIHsgIiAgZmlsZXNpemUl LTRzICAgICAlOHMiLCAiIGtCXG4iLCAgICAxMDI0IH0sDQotCSAgeyAiICBk YXRhc2l6ZSUtNHMgICAgICU4cyIsICIga0JcbiIsICAgIDEwMjQgfSwNCi0J ICB7ICIgIHN0YWNrc2l6ZSUtNHMgICAgJThzIiwgIiBrQlxuIiwgICAgMTAy NCB9LA0KLQkgIHsgIiAgY29yZWR1bXBzaXplJS00cyAlOHMiLCAiIGtCXG4i LCAgICAxMDI0IH0sDQotCSAgeyAiICBtZW1vcnl1c2UlLTRzICAgICU4cyIs ICIga0JcbiIsICAgIDEwMjQgfSwNCi0JICB7ICIgIG1lbW9yeWxvY2tlZCUt NHMgJThzIiwgIiBrQlxuIiwgICAgMTAyNCB9LA0KLQkgIHsgIiAgbWF4cHJv Y2Vzc2VzJS00cyAlOHMiLCAiXG4iLCAgICAgICAxICAgIH0sDQotCSAgeyAi ICBvcGVuZmlsZXMlLTRzICAgICU4cyIsICJcbiIsICAgICAgIDEgICAgfSwN Ci0JICB7ICIgIHNic2l6ZSUtNHMgICAgICAgJThzIiwgIiBieXRlc1xuIiwg MSAgICB9LA0KLQkgIHsgIiAgdm1lbW9yeXVzZSUtNHMgICAlOHMiLCAiIGtC XG4iLCAgICAxMDI0IH0NCisJICB7ICIgIGNwdXRpbWUlLTRzICAgICAgICAg ICU4cyIsICIgc2Vjc1xuIiwgIDEgICAgfSwNCisJICB7ICIgIGZpbGVzaXpl JS00cyAgICAgICAgICU4cyIsICIga0JcbiIsICAgIDEwMjQgfSwNCisJICB7 ICIgIGRhdGFzaXplJS00cyAgICAgICAgICU4cyIsICIga0JcbiIsICAgIDEw MjQgfSwNCisJICB7ICIgIHN0YWNrc2l6ZSUtNHMgICAgICAgICU4cyIsICIg a0JcbiIsICAgIDEwMjQgfSwNCisJICB7ICIgIGNvcmVkdW1wc2l6ZSUtNHMg ICAgICU4cyIsICIga0JcbiIsICAgIDEwMjQgfSwNCisJICB7ICIgIG1lbW9y eXVzZSUtNHMgICAgICAgICU4cyIsICIga0JcbiIsICAgIDEwMjQgfSwNCisJ ICB7ICIgIG1lbW9yeWxvY2tlZCUtNHMgICAgICU4cyIsICIga0JcbiIsICAg IDEwMjQgfSwNCisJICB7ICIgIG1heHByb2Nlc3NlcyUtNHMgICAgICU4cyIs ICJcbiIsICAgICAgIDEgICAgfSwNCisJICB7ICIgIG9wZW5maWxlcyUtNHMg ICAgICAgICU4cyIsICJcbiIsICAgICAgIDEgICAgfSwNCisJICB7ICIgIHNi c2l6ZSUtNHMgICAgICAgICAgICU4cyIsICIgYnl0ZXNcbiIsIDEgICAgfSwN CisJICB7ICIgIHZtZW1vcnl1c2UlLTRzICAgICAgICU4cyIsICIga0JcbiIs ICAgIDEwMjQgfSwNCisJICB7ICIgIHBzZXVkby10ZXJtaW5hbHMlLTRzICU4 cyIsICJcbiIsICAgICAgIDEgICAgfQ0KICAgICAgIH0NCiAgICAgfSwNCiAg ICAgeyAic2giLCAidW5saW1pdGVkIiwgIiIsICIgLUgiLCAiIC1TIiwgIiIs DQpAQCAtMTAxLDIyICsxMDIsMjQgQEANCiAJICB7ICJ1bGltaXQlcyAtdSAl cyIsICI7XG4iLCAgMSAgICB9LA0KIAkgIHsgInVsaW1pdCVzIC1uICVzIiwg IjtcbiIsICAxICAgIH0sDQogCSAgeyAidWxpbWl0JXMgLWIgJXMiLCAiO1xu IiwgIDEgICAgfSwNCi0JICB7ICJ1bGltaXQlcyAtdiAlcyIsICI7XG4iLCAg MTAyNCB9DQorCSAgeyAidWxpbWl0JXMgLXYgJXMiLCAiO1xuIiwgIDEwMjQg fSwNCisJICB7ICJ1bGltaXQlcyAtcCAlcyIsICI7XG4iLCAgMSAgICB9DQog ICAgICAgfQ0KICAgICB9LA0KICAgICB7ICJjc2giLCAidW5saW1pdGVkIiwg IiIsICIgLWgiLCAiIiwgTlVMTCwNCiAgICAgICB7DQotCSAgeyAibGltaXQl cyBjcHV0aW1lICVzIiwgICAgICAiO1xuIiwgIDEgICAgfSwNCi0JICB7ICJs aW1pdCVzIGZpbGVzaXplICVzIiwgICAgICI7XG4iLCAgMTAyNCB9LA0KLQkg IHsgImxpbWl0JXMgZGF0YXNpemUgJXMiLCAgICAgIjtcbiIsICAxMDI0IH0s DQotCSAgeyAibGltaXQlcyBzdGFja3NpemUgJXMiLCAgICAiO1xuIiwgIDEw MjQgfSwNCi0JICB7ICJsaW1pdCVzIGNvcmVkdW1wc2l6ZSAlcyIsICI7XG4i LCAgMTAyNCB9LA0KLQkgIHsgImxpbWl0JXMgbWVtb3J5dXNlICVzIiwgICAg IjtcbiIsICAxMDI0IH0sDQotCSAgeyAibGltaXQlcyBtZW1vcnlsb2NrZWQg JXMiLCAiO1xuIiwgIDEwMjQgfSwNCi0JICB7ICJsaW1pdCVzIG1heHByb2Mg JXMiLCAgICAgICI7XG4iLCAgMSAgICB9LA0KLQkgIHsgImxpbWl0JXMgb3Bl bmZpbGVzICVzIiwgICAgIjtcbiIsICAxICAgIH0sDQotCSAgeyAibGltaXQl cyBzYnNpemUgJXMiLCAgICAgICAiO1xuIiwgIDEgICAgfSwNCi0JICB7ICJs aW1pdCVzIHZtZW1vcnl1c2UgJXMiLCAgICI7XG4iLCAgMTAyNCB9DQorCSAg eyAibGltaXQlcyBjcHV0aW1lICVzIiwgICAgICAgICAiO1xuIiwgIDEgICAg fSwNCisJICB7ICJsaW1pdCVzIGZpbGVzaXplICVzIiwgICAgICAgICI7XG4i LCAgMTAyNCB9LA0KKwkgIHsgImxpbWl0JXMgZGF0YXNpemUgJXMiLCAgICAg ICAgIjtcbiIsICAxMDI0IH0sDQorCSAgeyAibGltaXQlcyBzdGFja3NpemUg JXMiLCAgICAgICAiO1xuIiwgIDEwMjQgfSwNCisJICB7ICJsaW1pdCVzIGNv cmVkdW1wc2l6ZSAlcyIsICAgICI7XG4iLCAgMTAyNCB9LA0KKwkgIHsgImxp bWl0JXMgbWVtb3J5dXNlICVzIiwgICAgICAgIjtcbiIsICAxMDI0IH0sDQor CSAgeyAibGltaXQlcyBtZW1vcnlsb2NrZWQgJXMiLCAgICAiO1xuIiwgIDEw MjQgfSwNCisJICB7ICJsaW1pdCVzIG1heHByb2MgJXMiLCAgICAgICAgICI7 XG4iLCAgMSAgICB9LA0KKwkgIHsgImxpbWl0JXMgb3BlbmZpbGVzICVzIiwg ICAgICAgIjtcbiIsICAxICAgIH0sDQorCSAgeyAibGltaXQlcyBzYnNpemUg JXMiLCAgICAgICAgICAiO1xuIiwgIDEgICAgfSwNCisJICB7ICJsaW1pdCVz IHZtZW1vcnl1c2UgJXMiLCAgICAgICI7XG4iLCAgMTAyNCB9LA0KKwkgIHsg ImxpbWl0JXMgcHNldWRvdGVybWluYWxzICVzIiwgIjtcbiIsICAxICAgIH0N CiAgICAgICB9DQogICAgIH0sDQogICAgIHsgImJhc2h8YmFzaDIiLCAidW5s aW1pdGVkIiwgIiIsICIgLUgiLCAiIC1TIiwgIiIsDQpAQCAtMTMxLDIyICsx MzQsMjQgQEANCiAJICB7ICJ1bGltaXQlcyAtdSAlcyIsICI7XG4iLCAgMSAg ICB9LA0KIAkgIHsgInVsaW1pdCVzIC1uICVzIiwgIjtcbiIsICAxICAgIH0s DQogCSAgeyAidWxpbWl0JXMgLWIgJXMiLCAiO1xuIiwgIDEgICAgfSwNCi0J ICB7ICJ1bGltaXQlcyAtdiAlcyIsICI7XG4iLCAgMTAyNCB9DQorCSAgeyAi dWxpbWl0JXMgLXYgJXMiLCAiO1xuIiwgIDEwMjQgfSwNCisJICB7ICJ1bGlt aXQlcyAtcCAlcyIsICI7XG4iLCAgMSAgICB9DQogICAgICAgfQ0KICAgICB9 LA0KICAgICB7ICJ0Y3NoIiwgInVubGltaXRlZCIsICIiLCAiIC1oIiwgIiIs IE5VTEwsDQogICAgICAgew0KLQkgIHsgImxpbWl0JXMgY3B1dGltZSAlcyIs ICAgICAgIjtcbiIsICAxICAgIH0sDQotCSAgeyAibGltaXQlcyBmaWxlc2l6 ZSAlcyIsICAgICAiO1xuIiwgIDEwMjQgfSwNCi0JICB7ICJsaW1pdCVzIGRh dGFzaXplICVzIiwgICAgICI7XG4iLCAgMTAyNCB9LA0KLQkgIHsgImxpbWl0 JXMgc3RhY2tzaXplICVzIiwgICAgIjtcbiIsICAxMDI0IH0sDQotCSAgeyAi bGltaXQlcyBjb3JlZHVtcHNpemUgJXMiLCAiO1xuIiwgIDEwMjQgfSwNCi0J ICB7ICJsaW1pdCVzIG1lbW9yeXVzZSAlcyIsICAgICI7XG4iLCAgMTAyNCB9 LA0KLQkgIHsgImxpbWl0JXMgbWVtb3J5bG9ja2VkICVzIiwgIjtcbiIsICAx MDI0IH0sDQotCSAgeyAibGltaXQlcyBtYXhwcm9jICVzIiwgICAgICAiO1xu IiwgIDEgICAgfSwNCi0JICB7ICJsaW1pdCVzIGRlc2NyaXB0b3JzICVzIiwg ICI7XG4iLCAgMSAgICB9LA0KLQkgIHsgImxpbWl0JXMgc2JzaXplICVzIiwg ICAgICAgIjtcbiIsICAxICAgIH0sDQotCSAgeyAibGltaXQlcyB2bWVtb3J5 dXNlICVzIiwgICAiO1xuIiwgIDEwMjQgfQ0KKwkgIHsgImxpbWl0JXMgY3B1 dGltZSAlcyIsICAgICAgICAgIjtcbiIsICAxICAgIH0sDQorCSAgeyAibGlt aXQlcyBmaWxlc2l6ZSAlcyIsICAgICAgICAiO1xuIiwgIDEwMjQgfSwNCisJ ICB7ICJsaW1pdCVzIGRhdGFzaXplICVzIiwgICAgICAgICI7XG4iLCAgMTAy NCB9LA0KKwkgIHsgImxpbWl0JXMgc3RhY2tzaXplICVzIiwgICAgICAgIjtc biIsICAxMDI0IH0sDQorCSAgeyAibGltaXQlcyBjb3JlZHVtcHNpemUgJXMi LCAgICAiO1xuIiwgIDEwMjQgfSwNCisJICB7ICJsaW1pdCVzIG1lbW9yeXVz ZSAlcyIsICAgICAgICI7XG4iLCAgMTAyNCB9LA0KKwkgIHsgImxpbWl0JXMg bWVtb3J5bG9ja2VkICVzIiwgICAgIjtcbiIsICAxMDI0IH0sDQorCSAgeyAi bGltaXQlcyBtYXhwcm9jICVzIiwgICAgICAgICAiO1xuIiwgIDEgICAgfSwN CisJICB7ICJsaW1pdCVzIGRlc2NyaXB0b3JzICVzIiwgICAgICI7XG4iLCAg MSAgICB9LA0KKwkgIHsgImxpbWl0JXMgc2JzaXplICVzIiwgICAgICAgICAg IjtcbiIsICAxICAgIH0sDQorCSAgeyAibGltaXQlcyB2bWVtb3J5dXNlICVz IiwgICAgICAiO1xuIiwgIDEwMjQgfSwNCisJICB7ICJsaW1pdCVzIHBzZXVk b3Rlcm1pbmFscyAlcyIsICI7XG4iLCAgMSAgICB9DQogICAgICAgfQ0KICAg ICB9LA0KICAgICB7ICJrc2h8cGRrc2giLCAidW5saW1pdGVkIiwgIiIsICIg LUgiLCAiIC1TIiwgIiIsDQpAQCAtMTYxLDcgKzE2Niw4IEBADQogCSAgeyAi dWxpbWl0JXMgLXAgJXMiLCAiO1xuIiwgIDEgICAgfSwNCiAJICB7ICJ1bGlt aXQlcyAtbiAlcyIsICI7XG4iLCAgMSAgICB9LA0KIAkgIHsgInVsaW1pdCVz IC1iICVzIiwgIjtcbiIsICAxICAgIH0sDQotCSAgeyAidWxpbWl0JXMgLXYg JXMiLCAiO1xuIiwgIDEwMjQgfQ0KKwkgIHsgInVsaW1pdCVzIC12ICVzIiwg IjtcbiIsICAxMDI0IH0sDQorCSAgeyAidWxpbWl0JXMgLXAgJXMiLCAiO1xu IiwgIDEgICAgfQ0KICAgICAgIH0NCiAgICAgfSwNCiAgICAgeyAienNoIiwg InVubGltaXRlZCIsICIiLCAiIC1IIiwgIiAtUyIsICIiLA0KQEAgLTE3Niwy MiArMTgyLDI0IEBADQogCSAgeyAidWxpbWl0JXMgLXUgJXMiLCAiO1xuIiwg IDEgICAgfSwNCiAJICB7ICJ1bGltaXQlcyAtbiAlcyIsICI7XG4iLCAgMSAg ICB9LA0KIAkgIHsgInVsaW1pdCVzIC1iICVzIiwgIjtcbiIsICAxICAgIH0s DQotCSAgeyAidWxpbWl0JXMgLXYgJXMiLCAiO1xuIiwgIDEwMjQgfQ0KKwkg IHsgInVsaW1pdCVzIC12ICVzIiwgIjtcbiIsICAxMDI0IH0sDQorCSAgeyAi dWxpbWl0JXMgLXAgJXMiLCAiO1xuIiwgIDEgICAgfQ0KICAgICAgIH0NCiAg ICAgfSwNCiAgICAgeyAicmN8ZXMiLCAidW5saW1pdGVkIiwgIiIsICIgLWgi LCAiIiwgTlVMTCwNCiAgICAgICB7DQotCSAgeyAibGltaXQlcyBjcHV0aW1l ICVzIiwgICAgICAiO1xuIiwgIDEgICAgfSwNCi0JICB7ICJsaW1pdCVzIGZp bGVzaXplICVzIiwgICAgICI7XG4iLCAgMTAyNCB9LA0KLQkgIHsgImxpbWl0 JXMgZGF0YXNpemUgJXMiLCAgICAgIjtcbiIsICAxMDI0IH0sDQotCSAgeyAi bGltaXQlcyBzdGFja3NpemUgJXMiLCAgICAiO1xuIiwgIDEwMjQgfSwNCi0J ICB7ICJsaW1pdCVzIGNvcmVkdW1wc2l6ZSAlcyIsICI7XG4iLCAgMTAyNCB9 LA0KLQkgIHsgImxpbWl0JXMgbWVtb3J5dXNlICVzIiwgICAgIjtcbiIsICAx MDI0IH0sDQotCSAgeyAibGltaXQlcyBsb2NrZWRtZW1vcnkgJXMiLCAiO1xu IiwgIDEwMjQgfSwNCi0JICB7ICJsaW1pdCVzIHByb2Nlc3NlcyAlcyIsICAg ICI7XG4iLCAgMSAgICB9LA0KLQkgIHsgImxpbWl0JXMgZGVzY3JpcHRvcnMg JXMiLCAgIjtcbiIsICAxICAgIH0sDQotCSAgeyAibGltaXQlcyBzYnNpemUg JXMiLCAgICAgICAiO1xuIiwgIDEgICAgfSwNCi0JICB7ICJsaW1pdCVzIHZt ZW1vcnl1c2UgJXMiLCAgICI7XG4iLCAgMTAyNCB9DQorCSAgeyAibGltaXQl cyBjcHV0aW1lICVzIiwgICAgICAgICAiO1xuIiwgIDEgICAgfSwNCisJICB7 ICJsaW1pdCVzIGZpbGVzaXplICVzIiwgICAgICAgICI7XG4iLCAgMTAyNCB9 LA0KKwkgIHsgImxpbWl0JXMgZGF0YXNpemUgJXMiLCAgICAgICAgIjtcbiIs ICAxMDI0IH0sDQorCSAgeyAibGltaXQlcyBzdGFja3NpemUgJXMiLCAgICAg ICAiO1xuIiwgIDEwMjQgfSwNCisJICB7ICJsaW1pdCVzIGNvcmVkdW1wc2l6 ZSAlcyIsICAgICI7XG4iLCAgMTAyNCB9LA0KKwkgIHsgImxpbWl0JXMgbWVt b3J5dXNlICVzIiwgICAgICAgIjtcbiIsICAxMDI0IH0sDQorCSAgeyAibGlt aXQlcyBsb2NrZWRtZW1vcnkgJXMiLCAgICAiO1xuIiwgIDEwMjQgfSwNCisJ ICB7ICJsaW1pdCVzIHByb2Nlc3NlcyAlcyIsICAgICAgICI7XG4iLCAgMSAg ICB9LA0KKwkgIHsgImxpbWl0JXMgZGVzY3JpcHRvcnMgJXMiLCAgICAgIjtc biIsICAxICAgIH0sDQorCSAgeyAibGltaXQlcyBzYnNpemUgJXMiLCAgICAg ICAgICAiO1xuIiwgIDEgICAgfSwNCisJICB7ICJsaW1pdCVzIHZtZW1vcnl1 c2UgJXMiLCAgICAgICI7XG4iLCAgMTAyNCB9LA0KKwkgIHsgImxpbWl0JXMg cHNldWRvdGVybWluYWxzICVzIiwgIjtcbiIsICAxICAgIH0NCiAgICAgICB9 DQogICAgIH0sDQogICAgIHsgTlVMTCwgTlVMTCwgTlVMTCwgTlVMTCwgTlVM TCwgTlVMTCwNCkBAIC0yMTMsNyArMjIxLDggQEANCiAgICAgeyAibWF4cHJv YyIsCWxvZ2luX2dldGNhcG51bSAgfSwNCiAgICAgeyAib3BlbmZpbGVzIiwJ bG9naW5fZ2V0Y2FwbnVtICB9LA0KICAgICB7ICJzYnNpemUiLAkJbG9naW5f Z2V0Y2Fwc2l6ZSAgfSwNCi0gICAgeyAidm1lbW9yeXVzZSIsCWxvZ2luX2dl dGNhcHNpemUgIH0NCisgICAgeyAidm1lbW9yeXVzZSIsCWxvZ2luX2dldGNh cHNpemUgIH0sDQorICAgIHsgInBzZXVkb3Rlcm1pbmFscyIsbG9naW5fZ2V0 Y2FwbnVtICB9LA0KIH07DQogDQogLyoNCkBAIC0yMjQsNyArMjMzLDcgQEAN CiAgKiB0byBiZSBtb2RpZmllZCBhY2NvcmRpbmdseSENCiAgKi8NCiANCi0j ZGVmaW5lIFJDU19TVFJJTkcgICJ0ZmRzY21sdW5idiINCisjZGVmaW5lIFJD U19TVFJJTkcgICJ0ZmRzY21sdW5idnAiDQogDQogc3RhdGljIHJsaW1fdCBy ZXNvdXJjZV9udW0oaW50IHdoaWNoLCBpbnQgY2gsIGNvbnN0IGNoYXIgKnN0 cik7DQogc3RhdGljIHZvaWQgdXNhZ2Uodm9pZCk7DQpAQCAtMjYxLDcgKzI3 MCw3IEBADQogICAgIH0NCiANCiAgICAgb3B0YXJnID0gTlVMTDsNCi0gICAg d2hpbGUgKChjaCA9IGdldG9wdChhcmdjLCBhcmd2LCAiOkVlQzpVOkJTSGFi OmM6ZDpmOmw6bTpuOnM6dDp1OnY6IikpICE9IC0xKSB7DQorICAgIHdoaWxl ICgoY2ggPSBnZXRvcHQoYXJnYywgYXJndiwgIjpFZUM6VTpCU0hhYjpjOmQ6 ZjpsOm06bjpzOnQ6dTp2OnA6IikpICE9IC0xKSB7DQogCXN3aXRjaChjaCkg ew0KIAljYXNlICdhJzoNCiAJICAgIGRvYWxsID0gMTsNCkBAIC00NzUsNyAr NDg0LDcgQEANCiB1c2FnZSh2b2lkKQ0KIHsNCiAgICAgKHZvaWQpZnByaW50 ZihzdGRlcnIsDQotInVzYWdlOiBsaW1pdHMgWy1DIGNsYXNzfC1VIHVzZXJd IFstZWFTSEJFXSBbLWJjZGZsbW5zdHV2IFt2YWxdXSBbW25hbWU9dmFsIC4u Ll0gY21kXVxuIik7DQorInVzYWdlOiBsaW1pdHMgWy1DIGNsYXNzfC1VIHVz ZXJdIFstZWFTSEJFXSBbLWJjZGZsbW5zdHV2cCBbdmFsXV0gW1tuYW1lPXZh bCAuLi5dIGNtZF1cbiIpOw0KICAgICBleGl0KEVYSVRfRkFJTFVSRSk7DQog fQ0KIA0KQEAgLTU4MSw2ICs1OTAsNyBAQA0KIAkgICAgYnJlYWs7DQogCWNh c2UgUkxJTUlUX05QUk9DOg0KIAljYXNlIFJMSU1JVF9OT0ZJTEU6DQorCWNh c2UgUkxJTUlUX05QVFM6DQogCSAgICByZXMgPSBzdHJ0b3EocywgJmUsIDAp Ow0KIAkgICAgcyA9IGU7DQogCSAgICBicmVhazsNCg== --789136512-1465995021-1220382500=:3497 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=limits.1.diff Content-Transfer-Encoding: BASE64 Content-ID: <20080902230820.I3497@atwork.home.local> Content-Description: Content-Disposition: attachment; filename=limits.1.diff SW5kZXg6IGxpbWl0cy4xDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQpSQ1Mg ZmlsZTogL2hvbWUvbmN2cy9zcmMvdXNyLmJpbi9saW1pdHMvbGltaXRzLjEs dg0KcmV0cmlldmluZyByZXZpc2lvbiAxLjI5DQpkaWZmIC11IC1yMS4yOSBs aW1pdHMuMQ0KLS0tIGxpbWl0cy4xCTE3IEphbiAyMDA1IDA3OjQ0OjIwIC0w MDAwCTEuMjkNCisrKyBsaW1pdHMuMQkyIFNlcCAyMDA4IDE4OjAzOjQ1IC0w MDAwDQpAQCAtMzAsMTEgKzMwLDExIEBADQogLk9wIEZsIEMgQXIgY2xhc3Mg fCBGbCBVIEFyIHVzZXINCiAuT3AgRmwgU0hCDQogLk9wIEZsIGVhDQotLk9w IEZsIGJjZGZsbW5zdHV2IE9wIEFyIHZhbA0KKy5PcCBGbCBiY2RmbG1uc3R1 dnAgT3AgQXIgdmFsDQogLk5tDQogLk9wIEZsIEMgQXIgY2xhc3MgfCBGbCBV IEFyIHVzZXINCiAuT3AgRmwgU0hCDQotLk9wIEZsIGJjZGZsbW5zdHV2IE9w IEFyIHZhbA0KKy5PcCBGbCBiY2RmbG1uc3R1dnAgT3AgQXIgdmFsDQogLk9w IEZsIEUNCiAuT28NCiAuT3AgQXIgbmFtZSBOcyA9IE5zIEFyIHZhbHVlIC4u Lg0KQEAgLTI2Miw2ICsyNjIsMTAgQEANCiBhbmQNCiAuWHIgbW1hcCAyIE5z ICdkDQogc3BhY2UuDQorLkl0IEZsIHAgT3AgQXIgdmFsDQorU2VsZWN0IG9y IHNldCB0aGUNCisuVmEgcHNldWRvdGVybWluYWxzDQorcmVzb3VyY2UgbGlt aXQuDQogLkVsDQogLlBwDQogVmFsaWQgdmFsdWVzIGZvcg0K --789136512-1465995021-1220382500=:3497-- From owner-freebsd-current@FreeBSD.ORG Tue Sep 2 19:08:17 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 018BB106564A for ; Tue, 2 Sep 2008 19:08:17 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.157]) by mx1.freebsd.org (Postfix) with ESMTP id 81EAC8FC2B for ; Tue, 2 Sep 2008 19:08:16 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so1596261fgb.35 for ; Tue, 02 Sep 2008 12:08:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; 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; bh=Av9JsLjnld3D/7nuZ4Xqfj9F0pQsiucfLRL0rTVOjHw=; b=GdwLSGTnfrnHErEdjRcyKczR1JAma4gpUCgOW5d213j4m+bJpsFS0vEd0eQZCDM2mt nxomC1eRQyhyns1BzokMja4erzOLP6Rr4K9GLhdnC+6i1BS2frJcU5noxRq142Dh+iGU EzWeSc+gXLVbN9O42x00aFokm/Dg0vFm3kVJE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=TNdnz6pVwRWEbROwAeTDvqYJkCttc1d749O17hXAghff39jA/gC37MiiYjyapOFpf7 G0X9t5W2utOPAERjSp99uiB3dklLocdlqByY460CbDMHXy3YWsIRNWr+fCLkrDeI25UV HKUIYIZA/Ty+EFvWFNewoHCc6zfsqa5DK5LlQ= Received: by 10.86.98.10 with SMTP id v10mr5837019fgb.39.1220378048618; Tue, 02 Sep 2008 10:54:08 -0700 (PDT) Received: by 10.86.70.1 with HTTP; Tue, 2 Sep 2008 10:54:08 -0700 (PDT) Message-ID: Date: Tue, 2 Sep 2008 10:54:08 -0700 From: "Maksim Yevmenkin" To: "Andrew Thompson" In-Reply-To: <20080902174540.GB12367@citylink.fud.org.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20080902174540.GB12367@citylink.fud.org.nz> Cc: current@freebsd.org Subject: Re: m_uiotombuf alignment X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2008 19:08:17 -0000 Andrew, > I have a patch here to removing the alignment of the align parameter. I > can not see why it was added as it up to the caller to specify this, it > breaks tap(4) on strict alignment machines as m_uiotombuf is called with > ETHER_ALIGN. Also 'align' isnt a great description of this field, its > more a padding or data offset. hmm... strange... from cvs === Revision 1.53 Wed May 4 18:55:02 2005 UTC (3 years, 4 months ago) by emax Branches: MAIN Change m_uiotombuf so it will accept offset at which data should be copied to the mbuf. Offset cannot exceed MHLEN bytes. This is currently used to fix Ethernet header alignment problem on alpha and sparc64. Also change all users of m_uiotombuf to pass proper offset. Reviewed by: jmg, sam Tested by: Sten Spans "sten AT blinkenlights DOT nl" MFC after: 1 week === could you please explain how and on which platforms it breaks tap(4)? thanks, max From owner-freebsd-current@FreeBSD.ORG Tue Sep 2 19:14:35 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CE9101065671 for ; Tue, 2 Sep 2008 19:14:35 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:610:652::211]) by mx1.freebsd.org (Postfix) with ESMTP id A1E348FC15 for ; Tue, 2 Sep 2008 19:14:34 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id E8F6E1CC73; Tue, 2 Sep 2008 21:14:33 +0200 (CEST) Date: Tue, 2 Sep 2008 21:14:33 +0200 From: Ed Schouten To: Yuriy Tsibizov Message-ID: <20080902191433.GM99951@hoeg.nl> References: <200809011335.m81DZW8b006033@pozo.com> <200809011436.m81Eaq2v040141@pozo.com> <20080902095229.Y1605@atwork.home.local> <20080902063016.GK99951@hoeg.nl> <20080902225533.O3497@atwork.home.local> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="oVW42zVB+v3BFr50" Content-Disposition: inline In-Reply-To: <20080902225533.O3497@atwork.home.local> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: FreeBSD Current Subject: Re: /usr/bin/limits (WAS: Re: Apache.sh on current) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2008 19:14:35 -0000 --oVW42zVB+v3BFr50 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Yuriy Tsibizov wrote: > Yes, it solves that problem. You may also want to add -p switch to man > page and fix some other places in limits.c (see attached files). Thanks. I've committed it as r182685. > We also have built-in 'limit' in csh -- should it be updated as well? Yes, but I'd rather let this be done by the (t)csh folks, because it's not my territory. I'll see if I can poke someone. --=20 Ed Schouten WWW: http://80386.nl/ --oVW42zVB+v3BFr50 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAki9kJkACgkQ52SDGA2eCwXjygCfeuR23Xb877JuChmbIyu/1zdX MLEAnAtPD/GDxMd/unnbpsKGfoJjijnz =1VHv -----END PGP SIGNATURE----- --oVW42zVB+v3BFr50-- From owner-freebsd-current@FreeBSD.ORG Tue Sep 2 19:39:38 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3F8FE1065681 for ; Tue, 2 Sep 2008 19:39:38 +0000 (UTC) (envelope-from freebsd-current@adam.gs) Received: from mail.adam.gs (cl-127.ewr-01.us.sixxs.net [IPv6:2001:4830:1200:7e::2]) by mx1.freebsd.org (Postfix) with ESMTP id F243C8FC14 for ; Tue, 2 Sep 2008 19:39:37 +0000 (UTC) (envelope-from freebsd-current@adam.gs) Received: from [127.0.0.1] (localhost.adam.gs [127.0.0.1]) by mail.adam.gs (Postfix) with ESMTP id 09E25F8D62F for ; Tue, 2 Sep 2008 15:39:36 -0400 (EDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=mail; d=adam.gs; b=W1WeqpV3CaF3GGD1B1UG2z1ezQp+dydLuyhJPm9eXGukcme6jIoLTn8A0pOIg/J0wJwEkGmIIk7VV2rdvGy+zADzSFFegx/lMir7JJDooyfQ1ZLzisd/uA5RmVwJHAFFXcs85b2PK1K0cy9apKfrffXseBXlQIurqAej7lLHqHU=; Message-Id: From: Adam Jacob Muller To: Kostik Belousov In-Reply-To: <20080902184429.GB2038@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v928.1) Date: Tue, 2 Sep 2008 15:39:35 -0400 References: <20080830183804.GG2038@deviant.kiev.zoral.com.ua> <20080830195844.GI2038@deviant.kiev.zoral.com.ua> <20080831071618.GK2038@deviant.kiev.zoral.com.ua> <20080831091639.GM2038@deviant.kiev.zoral.com.ua> <80861bfa0809010733h47580d3evb3eb68c972a2bb25@mail.gmail.com> <20080901145315.GU2038@deviant.kiev.zoral.com.ua> <20080902184429.GB2038@deviant.kiev.zoral.com.ua> X-Authentication: U7ms6qe97VuHIIGUvsxMlJqzHyGSLCy4CoJ1NHOQrS/IsgIR7ZcpJJK0YGxpdokKs287xD3XhFaMQG+Z33b/1p99QXIzPRbPRJiKOlzlHjxQLDrjjpMiX6vMtSxzCnW1M1nKeqhBMlcCM8PRQgNUdXHWm1oL0+Ua4NrmtJZFum0ClWqzvVgLKnXtvw== Cc: freebsd-current@freebsd.org, Vyacheslav Bocharov Subject: Re: __tls_get_addr problem with recent current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2008 19:39:38 -0000 On Sep 2, 2008, at 2:44 PM, Kostik Belousov wrote: > On Tue, Sep 02, 2008 at 02:41:08PM -0400, Adam Jacob Muller wrote: >> >> On Sep 1, 2008, at 10:53 AM, Kostik Belousov wrote: >> >>> On Mon, Sep 01, 2008 at 05:33:37PM +0300, Vyacheslav Bocharov wrote: >>>> I have similar problem in 7-STABLE (from 1 sep): >>>> 32bit application exec 64application and we have an core dump: >>>> >>>> # gdb fw.sh fw.sh.core >>>> GNU gdb 6.1.1 [FreeBSD] >>>> Copyright 2004 Free Software Foundation, Inc. >>>> GDB is free software, covered by the GNU General Public License, >>>> and you are >>>> welcome to change it and/or distribute copies of it under certain >>>> conditions. >>>> Type "show copying" to see the conditions. >>>> There is absolutely no warranty for GDB. Type "show warranty" for >>>> details. >>>> This GDB was configured as "amd64-marcel-freebsd"... >>>> Core was generated by `fw.sh'. >>>> Program terminated with signal 11, Segmentation fault. >>>> Reading symbols from /usr/lib/libstdc++.so.6...done. >>>> Loaded symbols for /usr/lib/libstdc++.so.6 >>>> Reading symbols from /lib/libm.so.5...done. >>>> Loaded symbols for /lib/libm.so.5 >>>> Reading symbols from /lib/libgcc_s.so.1...done. >>>> Loaded symbols for /lib/libgcc_s.so.1 >>>> Reading symbols from /lib/libc.so.7...done. >>>> Loaded symbols for /lib/libc.so.7 >>>> Reading symbols from /libexec/ld-elf.so.1...done. >>>> Loaded symbols for /libexec/ld-elf.so.1 >>>> #0 0x0000000800507483 in __tls_get_addr () from /libexec/ld- >>>> elf.so.1 >>>> (gdb) bt >>>> #0 0x0000000800507483 in __tls_get_addr () from /libexec/ld- >>>> elf.so.1 >>>> #1 0x0000000800ad8892 in _pthread_mutex_init_calloc_cb () from >>>> /lib/libc.so.7 >>>> #2 0x0000000800ada35f in malloc () from /lib/libc.so.7 >>>> #3 0x00000008007050ad in operator new () from /usr/lib/libstdc+ >>>> +.so.6 >>>> #4 0x00000008006b5f21 in std::string::_Rep::_S_create () >>>> from /usr/lib/libstdc++.so.6 >>>> #5 0x00000008006b6ca5 in std::string::_S_copy_chars () >>>> from /usr/lib/libstdc++.so.6 >>>> #6 0x00000008006b6dc2 in std::basic_string>>> std::char_traits, >>>> std::allocator >::basic_string () from /usr/lib/libstdc+ >>>> +.so.6 >>>> #7 0x00000000004021ec in >>>> __static_initialization_and_destruction_0 ( >>>> __initialize_p=1, __priority=65535) at CCmdLine.cpp:16 >>>> #8 0x00000000004026c3 in global constructors keyed to cmdlist () >>>> at CCmdLine.cpp:177 >>>> #9 0x00000000004033a2 in __do_global_ctors_aux () >>>> #10 0x000000000040113e in _init () >>>> #11 0x0000000800b2b0c0 in __cxa_atexit () from /lib/libc.so.7 >>>> #12 0x00000000004014e8 in _start () >>>> #13 0x000000080052c000 in ?? () >>>> >>>> I tried your patch but nothing changed. >>> Exactly which patch ? There were three, one of which caused >>> immediate >>> panic. I put the patches at >>> http://people.freebsd.org/~kib/misc/fsbase.1.patch >>> http://people.freebsd.org/~kib/misc/fsbase.2.patch >>> >>> Could you, please, try both and report the results ? >>> And, isolated test case, as several C files or recipe to reproduce >>> this with base system, would be ideal. >>> >>>> >>>> 2008/8/31 Kostik Belousov >>>> >>>>> On Sun, Aug 31, 2008 at 10:16:18AM +0300, Kostik Belousov wrote: >>>>>> On Sat, Aug 30, 2008 at 02:03:00PM -0700, Artem Belevich wrote: >>>>>>> With the new patch kernel has crashed as soon as I ran i386 app, >>>>>>> though the crash happened within in-kernel thread g_up: >>>>>>> >>>>>>> Fatal trap 12: page fault while in kernel mode >>>>>>> cpuid = 2; apic id = 02 >>>>>>> fault virtual address = 0x20 >>>>>>> fault code = supervisor read data, page not present >>>>>>> instruction pointer = 0x8:0xffffffff804a821f >>>>>>> stack pointer = 0x10:0xffffffffac280b60 >>>>>>> frame pointer = 0x10:0x0 >>>>>>> code segment = base 0x0, limit 0xfffff, type 0x1b >>>>>>> = DPL 0, pres 1, long 1, def32 0, gran 1 >>>>>>> processor eflags = resume, IOPL = 0 >>>>>>> current process = 3 (g_up) >>>>>>> trap number = 12 >>>>>>> panic: page fault >>>>>>> cpuid = 2 >>>>>>> Uptime: 37s >>>>>>> Physical memory: 8169 MB >>>>>>> Dumping 380 MB: 365 349 333 317 301 285 269 253 237 221 205 189 >>>>>>> 173 >>>>>>> 157 141 125 109 93 77 61 45 29 13 >>>>>> Could you, please, show me the disassembled code around the >>>>>> faulted >>>>>> %rip ? >>>>> >>>>> No need, it seems I found the problem. I trashed the %rdx that >>>>> contains >>>>> the third cpu_switch argument. Please, try the updated patch. >>>>> >>>>> Thanks for the testing ! >>>>> >>>>> diff --git a/sys/amd64/amd64/cpu_switch.S b/sys/amd64/amd64/ >>>>> cpu_switch.S >>>>> index f34b0cc..03f0eca 100644 >>>>> --- a/sys/amd64/amd64/cpu_switch.S >>>>> +++ b/sys/amd64/amd64/cpu_switch.S >>>>> @@ -249,6 +249,12 @@ store_seg: >>>>> 1: movl %ds,PCB_DS(%r8) >>>>> movl %es,PCB_ES(%r8) >>>>> movl %fs,PCB_FS(%r8) >>>>> + movq %rdx,%r11 >>>>> + movl $MSR_FSBASE,%ecx >>>>> + rdmsr >>>>> + shlq $32,%rdx >>>>> + leaq (%rax,%rdx),%r9 >>>>> + movq %r11,%rdx >>>>> jmp done_store_seg >>>>> 2: movq PCB_GS32P(%r8),%rax >>>>> movq (%rax),%rax >>>>> >>>> >>>> >>>> >>>> -- >>>> Vyacheslav Bocharov >> >> >> >> Hi, >> i have this same issue on recent RELENG_7 (pre and post 7.1- >> PRERELEASE), the issue was reproducible by a simple c-app compiled on >> 7.x 32-bit >> >> #include >> main() >> { >> execl("/bin/ls", "/bin/ls", (char *) 0); >> } >> >> this app will segfault rather reliably (but not 100% of the time) >> (while true;do ./test; if [ "$?" -gt "0" ];then break; fi; done). >> >> patch 1 (http://people.freebsd.org/~kib/misc/fsbase.1.patch) fixes >> the >> issue for me >> patch 2 (http://people.freebsd.org/~kib/misc/fsbase.2.patch) does not >> though it may mitigate it slightly (cause things to crash less >> frequently) > > Patch below was committed to current, it shall address your issue. > > diff --git a/sys/amd64/amd64/cpu_switch.S b/sys/amd64/amd64/ > cpu_switch.S > index f34b0cc..a0b11f8 100644 > --- a/sys/amd64/amd64/cpu_switch.S > +++ b/sys/amd64/amd64/cpu_switch.S > @@ -109,8 +109,24 @@ ENTRY(cpu_switch) > movq %rsp,PCB_RSP(%r8) > movq %rbx,PCB_RBX(%r8) > movq %rax,PCB_RIP(%r8) > - movq PCB_FSBASE(%r8),%r9 > - movq PCB_GSBASE(%r8),%r10 > + > + /* > + * Reread fs and gs bases. Explicit fs segment register load > + * by the usermode code may change actual fs base without > + * updating pcb_{fs,gs}base. > + * > + * %rdx still contains the mtx, save %rdx around rdmsr. > + */ > + movq %rdx,%r11 > + movl $MSR_FSBASE,%ecx > + rdmsr > + shlq $32,%rdx > + leaq (%rax,%rdx),%r9 > + movl $MSR_KGSBASE,%ecx > + rdmsr > + shlq $32,%rdx > + leaq (%rax,%rdx),%r10 > + movq %r11,%rdx > > testl $PCB_32BIT,PCB_FLAGS(%r8) > jnz store_seg > diff --git a/sys/amd64/amd64/machdep.c b/sys/amd64/amd64/machdep.c > index 06c0803..f3c41f7 100644 > --- a/sys/amd64/amd64/machdep.c > +++ b/sys/amd64/amd64/machdep.c > @@ -734,6 +734,7 @@ exec_setregs(td, entry, stack, ps_strings) > pcb->pcb_fsbase = 0; > pcb->pcb_gsbase = 0; > critical_exit(); > + pcb->pcb_flags &= ~(PCB_32BIT | PCB_GS32BIT); > load_ds(_udatasel); > load_es(_udatasel); > load_fs(_udatasel); > diff --git a/sys/amd64/ia32/ia32_signal.c b/sys/amd64/ia32/ > ia32_signal.c > index 9e98656..162dcf9 100644 > --- a/sys/amd64/ia32/ia32_signal.c > +++ b/sys/amd64/ia32/ia32_signal.c > @@ -742,5 +742,6 @@ ia32_setregs(td, entry, stack, ps_strings) > > /* Return via doreti so that we can change to a different %cs */ > pcb->pcb_flags |= PCB_FULLCTX | PCB_32BIT; > + pcb->pcb_flags &= ~PCB_GS32BIT; > td->td_retval[1] = 0; > } This will be MFC'd into 7.1 before release? -Adam From owner-freebsd-current@FreeBSD.ORG Tue Sep 2 19:47:14 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 317A51065673 for ; Tue, 2 Sep 2008 19:47:14 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.terabit.net.ua (mail.terabit.net.ua [195.137.202.147]) by mx1.freebsd.org (Postfix) with ESMTP id C427E8FC15 for ; Tue, 2 Sep 2008 19:47:13 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from skuns.zoral.com.ua ([91.193.166.194] helo=mail.zoral.com.ua) by mail.terabit.net.ua with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1KabqJ-000769-Uu; Tue, 02 Sep 2008 22:47:11 +0300 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m82Jl9eq024856 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Sep 2008 22:47:09 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m82Jl9DB036576; Tue, 2 Sep 2008 22:47:09 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id m82Jl83t036575; Tue, 2 Sep 2008 22:47:08 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 2 Sep 2008 22:47:08 +0300 From: Kostik Belousov To: Adam Jacob Muller Message-ID: <20080902194708.GD2038@deviant.kiev.zoral.com.ua> References: <20080830195844.GI2038@deviant.kiev.zoral.com.ua> <20080831071618.GK2038@deviant.kiev.zoral.com.ua> <20080831091639.GM2038@deviant.kiev.zoral.com.ua> <80861bfa0809010733h47580d3evb3eb68c972a2bb25@mail.gmail.com> <20080901145315.GU2038@deviant.kiev.zoral.com.ua> <20080902184429.GB2038@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VCkJvjZSj7PKU6M/" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua X-Virus-Scanned: mail.terabit.net.ua 1KabqJ-000769-Uu 38ee3a46691ceb615ef5b25f89d0c0b7 X-Terabit: YES Cc: freebsd-current@freebsd.org, Vyacheslav Bocharov Subject: Re: __tls_get_addr problem with recent current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2008 19:47:14 -0000 --VCkJvjZSj7PKU6M/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 02, 2008 at 03:39:35PM -0400, Adam Jacob Muller wrote: >=20 > This will be MFC'd into 7.1 before release? If nothing goes wrong, yes. --VCkJvjZSj7PKU6M/ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAki9mDsACgkQC3+MBN1Mb4h+tQCgnpsA3IaFVR2gfnFccM+f7Wdd nPcAnRl16VMfWTH2gE3GgdPjKVU4XrJo =JyAQ -----END PGP SIGNATURE----- --VCkJvjZSj7PKU6M/-- From owner-freebsd-current@FreeBSD.ORG Tue Sep 2 19:57:54 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6A1411065678 for ; Tue, 2 Sep 2008 19:57:54 +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 538238FC0A for ; Tue, 2 Sep 2008 19:57:54 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 06BD5244E; Tue, 2 Sep 2008 12:57:55 -0700 (PDT) Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 27DEC2D605B; Tue, 2 Sep 2008 12:57:53 -0700 (PDT) Message-ID: <48BD9AC7.7030000@elischer.org> Date: Tue, 02 Sep 2008 12:57:59 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: NAKAJI Hiroyuki References: <4824F1B4.6010302@elischer.org> <86wshuwpzm.fsf@ra333.heimat.gr.jp> <48BD70E1.4010201@elischer.org> In-Reply-To: <48BD70E1.4010201@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Multiple routing table support commited X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2008 19:57:54 -0000 Julian Elischer wrote: > NAKAJI Hiroyuki wrote: >> Thanks for your great work. >> >> Do you have a plan to MFC this feature to RELENG_6? >> Or is it better to upgrade my RELENG6 box to RELENG_7? >> >> My ISP allows 5 PPPoE sessions but it always returns only one IP address >> as HISADDR. I hope this FIB feature will help my multi PPPoE sessions. >> >> I tried "setfib -1 ppp anothersession" on my RELENG_7 box, which >> complains >> >> Warning: iface add: ioctl(SIOCAIFADDR, 10.172.1.73 -> 210.247.16.1): >> File exists > > yes you need a later commit that I have not made to releng_7 yet. ok it is now in RELENG_7 you need to do 'sysctl net.add_addr_allfibs=0' after your system has booted, so that the PPP links only affect the FIB that you want them to. > >> >> Maybe I misunderstand the usage. >> >>>>>>> In <4824F1B4.6010302@elischer.org> Julian Elischer >>>>>>> wrote: >>> I have committed the base of teh Multi-routing-table support. >>> I am current;y waiting for it to loop back to me before a final >>> make universe test, but I think it should be ok. >>> if you do nothing you should not see any difference. > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Tue Sep 2 20:09:32 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1B6CC1065930; Tue, 2 Sep 2008 20:09:32 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id A0B7A8FC12; Tue, 2 Sep 2008 20:09:31 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m82K92uO017934; Tue, 2 Sep 2008 16:09:09 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: Tor Egge Date: Tue, 2 Sep 2008 16:08:56 -0400 User-Agent: KMail/1.9.7 References: <200808230003.44081.jhb@freebsd.org> <48B6BC81.5060300@clearchain.com> <20080901.013117.74700691.Tor.Egge@cvsup.no.freebsd.org> In-Reply-To: <20080901.013117.74700691.Tor.Egge@cvsup.no.freebsd.org> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200809021608.57542.jhb@freebsd.org> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Tue, 02 Sep 2008 16:09:10 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.1/8141/Tue Sep 2 11:52:21 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: attilio@freebsd.org, kevinxlinuz@163.com, freebsd-current@freebsd.org, Benjamin.Close@clearchain.com, kib@freebsd.org Subject: Re: [BUG] I think sleepqueue need to be protected in sleepq_broadcast X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2008 20:09:32 -0000 On Sunday 31 August 2008 09:31:17 pm Tor Egge wrote: > > sleepq_resume_thread() contains an ownership handover of sq if the resumed > thread is the last one blocked on the wait channel. After the handover, sq is > no longer protected by the sleep queue chain lock and should no longer be > accessed by sleepq_broadcast(). > > Normally, when sleepq_broadcast() incorrectly accesses sq after the handover, > it will find the sq->sq_blocked queue to be empty, and the code appears to > work. > > If the last correctly woken thread manages to go to sleep again very quickly on > another wait channel, sleepq_broadcast() might incorrectly determine that the > sq->sq_blocked queue isn't empty, and start doing the wrong thing. So disregard my earlier e-mail. Here is a simple fix for the sleepq case: Index: subr_sleepqueue.c =================================================================== --- subr_sleepqueue.c (revision 182679) +++ subr_sleepqueue.c (working copy) @@ -779,7 +779,7 @@ sleepq_broadcast(void *wchan, int flags, int pri, int queue) { struct sleepqueue *sq; - struct thread *td; + struct thread *td, *tdn; int wakeup_swapper; CTR2(KTR_PROC, "sleepq_broadcast(%p, %d)", wchan, flags); @@ -793,8 +793,7 @@ /* Resume all blocked threads on the sleep queue. */ wakeup_swapper = 0; - while (!TAILQ_EMPTY(&sq->sq_blocked[queue])) { - td = TAILQ_FIRST(&sq->sq_blocked[queue]); + TAILQ_FOREACH_SAFE(td, &sq->sq_blocked[queue], td_slpq, tdn) { thread_lock(td); if (sleepq_resume_thread(sq, td, pri)) wakeup_swapper = 1; This only uses 'sq' to fetch the head of the queue once up front. It won't use it again once it has started waking up threads. > A similar (but probably much more difficult to trigger) issue is present with > regards to thread_lock() and turnstiles. > > The caller of thread_lock() might have performed sufficient locking to ensure > that the thread to be locked doesn't go away, but any turnstile spin lock > pointed to by td->td_lock isn't protected. Making turnstiles type stable > (setting UMA_ZONE_NOFREE flag for turnstile_zone) should fix that issue. Note that unlike the sleepq case, turnstiles are not made runnable until all of them are dequeued from the turnstile and assigned a new turnstile. Only after all that is settled are the threads made runnable in turnstile_unpend(). However, that doesn't fix this specific race (though it means the turnstile code is not subject to the same exact race as the sleepq code above). Making turnstiles type-stable is indeed probably the only fix for this. :-/ -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Sep 2 20:41:26 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B7009106564A for ; Tue, 2 Sep 2008 20:41:26 +0000 (UTC) (envelope-from peter@wemm.org) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.29]) by mx1.freebsd.org (Postfix) with ESMTP id 798978FC12 for ; Tue, 2 Sep 2008 20:41:26 +0000 (UTC) (envelope-from peter@wemm.org) Received: by yw-out-2324.google.com with SMTP id 9so303418ywe.13 for ; Tue, 02 Sep 2008 13:41:25 -0700 (PDT) Received: by 10.142.191.10 with SMTP id o10mr2714620wff.94.1220388084446; Tue, 02 Sep 2008 13:41:24 -0700 (PDT) Received: by 10.142.76.14 with HTTP; Tue, 2 Sep 2008 13:41:24 -0700 (PDT) Message-ID: Date: Tue, 2 Sep 2008 13:41:24 -0700 From: "Peter Wemm" To: "Roman Divacky" In-Reply-To: <20080902160003.GA50767@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <48BAD085.1090507@gmail.com> <20080831200950.GF99951@hoeg.nl> <871w04syfw.fsf@kobe.laptop> <20080901101121.GC4083@wep400x.physik.uni-wuerzburg.de> <20080901160844.GA56657@freebsd.org> <20080902153020.GA94977@voi.aagh.net> <20080902160003.GA50767@freebsd.org> Cc: Alexey Shuvaev , Ed Schouten , freebsd-current@freebsd.org Subject: Re: csh history and pts X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2008 20:41:26 -0000 On Tue, Sep 2, 2008 at 9:00 AM, Roman Divacky wrote: > On Tue, Sep 02, 2008 at 04:30:20PM +0100, Thomas Hurst wrote: >> * Roman Divacky (rdivacky@freebsd.org) wrote: >> >> > > Back to original post, I confirm that [t]csh loses history after shutdown(8). >> > >> > might be completely irrelevant but tcsh on linux loses history for me as well :) >> >> tcsh doesn't bother doing any locking when merging .history, so if you >> kill multiple sessions at once, it's very common to see entries get >> lost, interlaced or doubled e.g: > > that's not it.... I never had any history saved since I started to use Linux (10 months > ago).. > > I occasionlly get garbled/lost history under fbsd but this is different FreeBSD's tcsh history saving has always been spotty on the console at reboot time. Over the last 15 years, sometimes it worked, sometimes not. I think it depended more on the phase of moon than anything. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV "All of this is for nothing if we don't go to the stars" - JMS/B5 "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell From owner-freebsd-current@FreeBSD.ORG Tue Sep 2 22:26:51 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 377581065677 for ; Tue, 2 Sep 2008 22:26:51 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id A93308FC1C for ; Tue, 2 Sep 2008 22:26:50 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from kobe.laptop (adsl10-93.kln.forthnet.gr [77.49.137.93]) (authenticated bits=128) by igloo.linux.gr (8.14.3/8.14.3/Debian-5) with ESMTP id m82MQMKZ002468 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 3 Sep 2008 01:26:27 +0300 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.3/8.14.3) with ESMTP id m82MQLof073544; Wed, 3 Sep 2008 01:26:21 +0300 (EEST) (envelope-from keramida@freebsd.org) Received: (from keramida@localhost) by kobe.laptop (8.14.3/8.14.3/Submit) id m82MQKBH073543; Wed, 3 Sep 2008 01:26:20 +0300 (EEST) (envelope-from keramida@freebsd.org) From: Giorgos Keramidas To: Ed Schouten References: <87fxot5hoi.fsf@kobe.laptop> <20080902164759.GL99951@hoeg.nl> Date: Wed, 03 Sep 2008 01:26:20 +0300 In-Reply-To: <20080902164759.GL99951@hoeg.nl> (Ed Schouten's message of "Tue, 2 Sep 2008 18:47:59 +0200") Message-ID: <871w029oc3.fsf@kobe.laptop> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-MailScanner-ID: m82MQMKZ002468 X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-4.289, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.11, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@freebsd.org X-Spam-Status: No Cc: FreeBSD Current Subject: Re: CFT: pts(4) "packet mode" support X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2008 22:26:51 -0000 On Tue, 2 Sep 2008 18:47:59 +0200, Ed Schouten wrote: > Hello everyone, > > One of the things I couldn't fix in time for the MPSAFE TTY import, was > pts(4) packet mode. Because people have noticed it was missing, I > decided to implement it, for inclusion in the SVN tree. ;-) > > Giorgos and I have already tried the attached patch, but it would be > nice if others could test it as well. I'm planning to integrate this > patch by the end of the week. > > Any feedback? Comments? Obscure panics? Thanks! I've been rebasing the patch on top of /head for a while, and running with a kernel that includes: http://people.freebsd.org/~keramida/mpsafetty/ The last time I resynced/merged was some time yesterday noon. I will install this patch now, but FWIW things seem 'ok' so far with the local version of the patch I was merging on top of /head :-) From owner-freebsd-current@FreeBSD.ORG Wed Sep 3 01:16:13 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 232831065C82 for ; Wed, 3 Sep 2008 01:16:13 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.freebsd.org (Postfix) with ESMTP id E36968FC0A for ; Wed, 3 Sep 2008 01:16:12 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.3/8.14.3) with ESMTP id m831GCWH001267 for ; Tue, 2 Sep 2008 18:16:12 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.3/8.14.3/Submit) id m831GCGP001266 for freebsd-current@freebsd.org; Tue, 2 Sep 2008 18:16:12 -0700 (PDT) (envelope-from sgk) Date: Tue, 2 Sep 2008 18:16:12 -0700 From: Steve Kargl To: freebsd-current@freebsd.org Message-ID: <20080903011612.GA1242@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Subject: drm causes kernel panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2008 01:16:13 -0000 Built world/kernel with today sources. Upon starting Xorg as a normal user, I was greeted with Script started on Tue Sep 2 18:12:22 2008 Unread portion of the kernel message buffer: panic: lock (sleep mutex) drmdev not locked @ /usr/src/sys/dev/drm/drm_pci.c:77 cpuid = 0 Uptime: 24s Physical memory: 8118 MB Dumping 346 MB: 331 315 299 283 267 251 235 219 203 187 171 155 139 123 107 91 75 59 43 27 11 #0 doadump () at pcpu.h:195 195 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:195 #1 0xffffffff802ee4da in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #2 0xffffffff802ee947 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:572 #3 0xffffffff803301ca in witness_unlock (lock=0xffffffff806f3d60, flags=8, file=0xffffffff8055dc88 "/usr/src/sys/dev/drm/drm_pci.c", line=77) at /usr/src/sys/kern/subr_witness.c:1460 #4 0xffffffff802e20c6 in _mtx_unlock_flags (m=0xffffff00017b41a8, opts=0, file=0xffffffff8055dc88 "/usr/src/sys/dev/drm/drm_pci.c", line=77) at /usr/src/sys/kern/kern_mutex.c:199 #5 0xffffffff8021a945 in drm_pci_alloc (dev=Variable "dev" is not available. ) at /usr/src/sys/dev/drm/drm_pci.c:77 #6 0xffffffff80214654 in drm_addmap (dev=0xffffff00017b4000, offset=0, size=16384, type=_DRM_CONSISTENT, flags=Variable "flags" is not available. ) at /usr/src/sys/dev/drm/drm_bufs.c:247 #7 0xffffffff80214b8b in drm_addmap_ioctl (dev=0xffffff00017b4000, data=0xffffff000576c480, file_priv=Variable "file_priv" is not available. ) at /usr/src/sys/dev/drm/drm_bufs.c:291 #8 0xffffffff8021786e in drm_ioctl (kdev=Variable "kdev" is not available. ) at /usr/src/sys/dev/drm/drm_drv.c:952 #9 0xffffffff802bb4e5 in giant_ioctl (dev=0xffffff000188e400, cmd=3223872533, data=0xffffff000576c480 "", fflag=67, td=0xffffff0005a25a20) at /usr/src/sys/kern/kern_conf.c:407 ---Type to continue, or q to quit--- #10 0xffffffff80288eea in devfs_ioctl_f (fp=0xffffff0005665c30, com=3223872533, data=0xffffff000576c480, cred=Variable "cred" is not available. ) at /usr/src/sys/fs/devfs/devfs_vnops.c:585 #11 0xffffffff80332942 in kern_ioctl (td=0xffffff0005a25a20, fd=Variable "fd" is not available. ) at file.h:262 #12 0xffffffff80332ba0 in ioctl (td=0xffffff0005a25a20, uap=0xffffffff2231fbf0) at /usr/src/sys/kern/sys_generic.c:677 #13 0xffffffff804f4f9f in syscall (frame=0xffffffff2231fc80) at /usr/src/sys/amd64/amd64/trap.c:897 #14 0xffffffff804d8b6b in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:338 #15 0x000000020185340c in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) quit exit Script done on Tue Sep 2 18:13:12 2008 -- Steve From owner-freebsd-current@FreeBSD.ORG Wed Sep 3 01:40:51 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F1680106755A for ; Wed, 3 Sep 2008 01:40:50 +0000 (UTC) (envelope-from peter@wemm.org) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.229]) by mx1.freebsd.org (Postfix) with ESMTP id CFE208FC16 for ; Wed, 3 Sep 2008 01:40:50 +0000 (UTC) (envelope-from peter@wemm.org) Received: by rv-out-0506.google.com with SMTP id b25so3568537rvf.43 for ; Tue, 02 Sep 2008 18:40:50 -0700 (PDT) Received: by 10.142.255.14 with SMTP id c14mr2791445wfi.296.1220406049982; Tue, 02 Sep 2008 18:40:49 -0700 (PDT) Received: by 10.142.76.14 with HTTP; Tue, 2 Sep 2008 18:40:49 -0700 (PDT) Message-ID: Date: Tue, 2 Sep 2008 18:40:49 -0700 From: "Peter Wemm" To: "John Baldwin" In-Reply-To: <200809021608.57542.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200808230003.44081.jhb@freebsd.org> <48B6BC81.5060300@clearchain.com> <20080901.013117.74700691.Tor.Egge@cvsup.no.freebsd.org> <200809021608.57542.jhb@freebsd.org> Cc: Benjamin.Close@clearchain.com, attilio@freebsd.org, freebsd-current@freebsd.org, kib@freebsd.org, kevinxlinuz@163.com Subject: Re: [BUG] I think sleepqueue need to be protected in sleepq_broadcast X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2008 01:40:51 -0000 On Tue, Sep 2, 2008 at 1:08 PM, John Baldwin wrote: > On Sunday 31 August 2008 09:31:17 pm Tor Egge wrote: >> >> sleepq_resume_thread() contains an ownership handover of sq if the resumed >> thread is the last one blocked on the wait channel. After the handover, sq > is >> no longer protected by the sleep queue chain lock and should no longer be >> accessed by sleepq_broadcast(). >> >> Normally, when sleepq_broadcast() incorrectly accesses sq after the > handover, >> it will find the sq->sq_blocked queue to be empty, and the code appears to >> work. >> >> If the last correctly woken thread manages to go to sleep again very quickly > on >> another wait channel, sleepq_broadcast() might incorrectly determine that > the >> sq->sq_blocked queue isn't empty, and start doing the wrong thing. > > So disregard my earlier e-mail. Here is a simple fix for the sleepq case: > > Index: subr_sleepqueue.c > =================================================================== > --- subr_sleepqueue.c (revision 182679) > +++ subr_sleepqueue.c (working copy) > @@ -779,7 +779,7 @@ > sleepq_broadcast(void *wchan, int flags, int pri, int queue) > { > struct sleepqueue *sq; > - struct thread *td; > + struct thread *td, *tdn; > int wakeup_swapper; > > CTR2(KTR_PROC, "sleepq_broadcast(%p, %d)", wchan, flags); > @@ -793,8 +793,7 @@ > > /* Resume all blocked threads on the sleep queue. */ > wakeup_swapper = 0; > - while (!TAILQ_EMPTY(&sq->sq_blocked[queue])) { > - td = TAILQ_FIRST(&sq->sq_blocked[queue]); > + TAILQ_FOREACH_SAFE(td, &sq->sq_blocked[queue], td_slpq, tdn) { > thread_lock(td); > if (sleepq_resume_thread(sq, td, pri)) > wakeup_swapper = 1; > > This only uses 'sq' to fetch the head of the queue once up front. It won't > use it again once it has started waking up threads. I don't know if it is the same problem, but mx2.freebsd.org, running today's 6.4-PRERELEASE just died with: Sep 3 00:20:11 mx2 sshd[15333]: fatal: Read from socket failed: Connection resr panic: Assertion td->td_flags & TDF_SINTR failed at ../../../kern/subr_sleepque5 cpuid = 2 KDB: enter: panic FreeBSD 6.4-PRERELEASE #7: Tue Sep 2 19:43:27 UTC 2008 This was after about 3 hours of uptime. It has previously run happily for months at a time before today's rebuild. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV "All of this is for nothing if we don't go to the stars" - JMS/B5 "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell From owner-freebsd-current@FreeBSD.ORG Wed Sep 3 01:49:40 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3B7081065672 for ; Wed, 3 Sep 2008 01:49:40 +0000 (UTC) (envelope-from unixmania@gmail.com) Received: from ik-out-1112.google.com (ik-out-1112.google.com [66.249.90.181]) by mx1.freebsd.org (Postfix) with ESMTP id C45FB8FC17 for ; Wed, 3 Sep 2008 01:49:39 +0000 (UTC) (envelope-from unixmania@gmail.com) Received: by ik-out-1112.google.com with SMTP id c30so1330426ika.3 for ; Tue, 02 Sep 2008 18:49:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type:content-transfer-encoding :content-disposition; bh=qnWemti97UYNVzKjg+2Ron10PtYKn1CMkHrwGzJh53E=; b=V/lQQX7LDeelsJJboRz+3jD3AuHHurS3aVJ9mUk4xkdyleL6e91/fFqBBZjHySC7Sr p1A65HGDiBF+cYdgMKQVAfVyrbp8bNi+kYvHDSdnqIoKBqH0SFUP4Kj5PUN8UxJPRYYC HxkbWrjpXdiWwSM+NrYQhyVwK1l5uGQ26Sga4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition; b=jQiW3GbfxnIvFY/2wz5YuGBX2Y1MdXWlgelRh3BLWCD15DDegco5zqs2w9LfMm8XIr EKv5du7Wt6LFD5+QAhhs1RCgh/2vDgyVk7O5C2Zheq9+TNBbNhTaaY7rvApvJNCPRONt tLEbA4nOYtohlnyRFRCd1JGd1yY5/6hOLulSs= Received: by 10.103.204.3 with SMTP id g3mr5886700muq.30.1220406578019; Tue, 02 Sep 2008 18:49:38 -0700 (PDT) Received: by 10.103.231.14 with HTTP; Tue, 2 Sep 2008 18:49:37 -0700 (PDT) Message-ID: Date: Tue, 2 Sep 2008 22:49:38 -0300 From: "Carlos A. M. dos Santos" To: "FreeBSD Current" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Subject: Why VESA and DPMS are available only for i386? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2008 01:49:40 -0000 Hello, Several PRs were closed based on the argument that FreeBSD/amd64 cannot call to the VESA BIOS. XFree86 solved this problem by means of the INT10 module. I believe that it would be possible to do the same on the FreeBSD kernel. Is there any ongoing effort to enable the VESA kernel moule on non-i386 platform? Is there any particular difficulty for doing this, besides depending on VM86? -- cd /usr/ports/sysutils/life make clean From owner-freebsd-current@FreeBSD.ORG Wed Sep 3 03:49:53 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 88B8D106566C for ; Wed, 3 Sep 2008 03:49:53 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 151A88FC1B for ; Wed, 3 Sep 2008 03:49:52 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from cicely5.cicely.de ([10.1.1.7]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id m833no0H051923 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 3 Sep 2008 05:49:50 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by cicely5.cicely.de (8.14.2/8.14.2) with ESMTP id m833niDP043189 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Sep 2008 05:49:44 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id m833nium011818; Wed, 3 Sep 2008 05:49:44 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id m833niOv011817; Wed, 3 Sep 2008 05:49:44 +0200 (CEST) (envelope-from ticso) Date: Wed, 3 Sep 2008 05:49:44 +0200 From: Bernd Walter To: freebsd-current@freebsd.org Message-ID: <20080903034943.GD11548@cicely7.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED=-1.8, AWL=0.072, BAYES_00=-2.599 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on spamd.cicely.de Cc: Bernd Walter Subject: MTRR fixup? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2008 03:49:53 -0000 Some boards (including my Intel DG33BU) seem to have problems setting up the mtrr to cache all RAM. My system runs fast with 2G and ist about 6 times slower in buildworld with 6G RAM. I will try a BIOS update once Intels tells me why their update ISO just turn the system off instead of updating the BIOS - sigh. But it seems that Linux is doing some kind of fixup for MTRR: http://lkml.org/lkml/2008/1/18/170 Can we do something similar? -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-current@FreeBSD.ORG Wed Sep 3 05:06:12 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ECCBB106566B for ; Wed, 3 Sep 2008 05:06:12 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id C513F8FC13 for ; Wed, 3 Sep 2008 05:06:12 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from [192.168.2.97] (c-71-56-39-94.hsd1.ga.comcast.net [71.56.39.94]) (authenticated bits=0) by gizmo.2hip.net (8.13.8/8.13.8) with ESMTP id m834e36v027382 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Sep 2008 00:40:03 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Steve Kargl In-Reply-To: <20080903011612.GA1242@troutmask.apl.washington.edu> References: <20080903011612.GA1242@troutmask.apl.washington.edu> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-pF+u94eHghb0cOlLiEgP" Organization: FreeBSD Date: Wed, 03 Sep 2008 00:39:53 -0400 Message-Id: <1220416793.1848.1.camel@wombat.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 FreeBSD GNOME Team Port X-Spam-Status: No, score=-0.9 required=5.0 tests=AWL,BAYES_00, RCVD_IN_SORBS_DUL autolearn=no version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on gizmo.2hip.net Cc: freebsd-current@freebsd.org Subject: Re: drm causes kernel panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2008 05:06:13 -0000 --=-pF+u94eHghb0cOlLiEgP Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2008-09-02 at 18:16 -0700, Steve Kargl wrote: > Built world/kernel with today sources. Upon starting Xorg=20 > as a normal user, I was greeted with >=20 > Script started on Tue Sep 2 18:12:22 2008 > Unread portion of the kernel message buffer: > panic: lock (sleep mutex) drmdev not locked @ /usr/src/sys/dev/drm/drm_pc= i.c:77 > cpuid =3D 0 > Uptime: 24s > Physical memory: 8118 MB > Dumping 346 MB: 331 315 299 283 267 251 235 219 203 187 171 155 139 123 1= 07 91 75 59 43 27 11 >=20 > #0 doadump () at pcpu.h:195 > 195 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) bt > #0 doadump () at pcpu.h:195 > #1 0xffffffff802ee4da in boot (howto=3D260) > at /usr/src/sys/kern/kern_shutdown.c:418 > #2 0xffffffff802ee947 in panic (fmt=3DVariable "fmt" is not available. > ) > at /usr/src/sys/kern/kern_shutdown.c:572 > #3 0xffffffff803301ca in witness_unlock (lock=3D0xffffffff806f3d60, flag= s=3D8,=20 > file=3D0xffffffff8055dc88 "/usr/src/sys/dev/drm/drm_pci.c", line=3D77= ) > at /usr/src/sys/kern/subr_witness.c:1460 > #4 0xffffffff802e20c6 in _mtx_unlock_flags (m=3D0xffffff00017b41a8, opts= =3D0,=20 > file=3D0xffffffff8055dc88 "/usr/src/sys/dev/drm/drm_pci.c", line=3D77= ) > at /usr/src/sys/kern/kern_mutex.c:199 > #5 0xffffffff8021a945 in drm_pci_alloc (dev=3DVariable "dev" is not avai= lable. > ) > at /usr/src/sys/dev/drm/drm_pci.c:77 > #6 0xffffffff80214654 in drm_addmap (dev=3D0xffffff00017b4000, offset=3D= 0,=20 > size=3D16384, type=3D_DRM_CONSISTENT, flags=3DVariable "flags" is not= available. > ) > at /usr/src/sys/dev/drm/drm_bufs.c:247 > #7 0xffffffff80214b8b in drm_addmap_ioctl (dev=3D0xffffff00017b4000,=20 > data=3D0xffffff000576c480, file_priv=3DVariable "file_priv" is not av= ailable. > ) > at /usr/src/sys/dev/drm/drm_bufs.c:291 I can't quite tell how we got here from this trace... What graphics hardware are you using and can you tell me what was going on when it paniced? robert. > #8 0xffffffff8021786e in drm_ioctl (kdev=3DVariable "kdev" is not availa= ble. > ) > at /usr/src/sys/dev/drm/drm_drv.c:952 > #9 0xffffffff802bb4e5 in giant_ioctl (dev=3D0xffffff000188e400,=20 > cmd=3D3223872533, data=3D0xffffff000576c480 "", fflag=3D67,=20 > td=3D0xffffff0005a25a20) at /usr/src/sys/kern/kern_conf.c:407 > ---Type to continue, or q to quit--- > #10 0xffffffff80288eea in devfs_ioctl_f (fp=3D0xffffff0005665c30,=20 > com=3D3223872533, data=3D0xffffff000576c480, cred=3DVariable "cred" i= s not available. > ) > at /usr/src/sys/fs/devfs/devfs_vnops.c:585 > #11 0xffffffff80332942 in kern_ioctl (td=3D0xffffff0005a25a20, fd=3DVaria= ble "fd" is not available. > ) > at file.h:262 > #12 0xffffffff80332ba0 in ioctl (td=3D0xffffff0005a25a20,=20 > uap=3D0xffffffff2231fbf0) at /usr/src/sys/kern/sys_generic.c:677 > #13 0xffffffff804f4f9f in syscall (frame=3D0xffffffff2231fc80) > at /usr/src/sys/amd64/amd64/trap.c:897 > #14 0xffffffff804d8b6b in Xfast_syscall () > at /usr/src/sys/amd64/amd64/exception.S:338 > #15 0x000000020185340c in ?? () > Previous frame inner to this frame (corrupt stack?) > (kgdb) quit > exit >=20 > Script done on Tue Sep 2 18:13:12 2008 --=-pF+u94eHghb0cOlLiEgP Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEABECAAYFAki+FRkACgkQM4TrQ4qfRONiIwCeMLzJmJCTFwDS8K1xoFWkEsnd dv8An3CUjUwf9T3bBkFqdo9L4sBT7vm4 =oCCx -----END PGP SIGNATURE----- --=-pF+u94eHghb0cOlLiEgP-- From owner-freebsd-current@FreeBSD.ORG Wed Sep 3 05:12:29 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 04F451065671; Wed, 3 Sep 2008 05:12:29 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.freebsd.org (Postfix) with ESMTP id D18EB8FC1A; Wed, 3 Sep 2008 05:12:28 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.3/8.14.3) with ESMTP id m835CSO7002609; Tue, 2 Sep 2008 22:12:28 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.3/8.14.3/Submit) id m835CSIN002608; Tue, 2 Sep 2008 22:12:28 -0700 (PDT) (envelope-from sgk) Date: Tue, 2 Sep 2008 22:12:28 -0700 From: Steve Kargl To: Robert Noland Message-ID: <20080903051228.GA2475@troutmask.apl.washington.edu> References: <20080903011612.GA1242@troutmask.apl.washington.edu> <1220416793.1848.1.camel@wombat.2hip.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1220416793.1848.1.camel@wombat.2hip.net> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@FreeBSD.org Subject: Re: drm causes kernel panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2008 05:12:29 -0000 On Wed, Sep 03, 2008 at 12:39:53AM -0400, Robert Noland wrote: > On Tue, 2008-09-02 at 18:16 -0700, Steve Kargl wrote: > > #0 doadump () at pcpu.h:195 > > #1 0xffffffff802ee4da in boot (howto=260) > > at /usr/src/sys/kern/kern_shutdown.c:418 > > #2 0xffffffff802ee947 in panic (fmt=Variable "fmt" is not available. > > ) > > at /usr/src/sys/kern/kern_shutdown.c:572 > > #3 0xffffffff803301ca in witness_unlock (lock=0xffffffff806f3d60, flags=8, > > file=0xffffffff8055dc88 "/usr/src/sys/dev/drm/drm_pci.c", line=77) > > at /usr/src/sys/kern/subr_witness.c:1460 > > #4 0xffffffff802e20c6 in _mtx_unlock_flags (m=0xffffff00017b41a8, opts=0, > > file=0xffffffff8055dc88 "/usr/src/sys/dev/drm/drm_pci.c", line=77) > > at /usr/src/sys/kern/kern_mutex.c:199 > > #5 0xffffffff8021a945 in drm_pci_alloc (dev=Variable "dev" is not available. > > ) > > at /usr/src/sys/dev/drm/drm_pci.c:77 > > #6 0xffffffff80214654 in drm_addmap (dev=0xffffff00017b4000, offset=0, > > size=16384, type=_DRM_CONSISTENT, flags=Variable "flags" is not available. > > ) > > at /usr/src/sys/dev/drm/drm_bufs.c:247 > > #7 0xffffffff80214b8b in drm_addmap_ioctl (dev=0xffffff00017b4000, > > data=0xffffff000576c480, file_priv=Variable "file_priv" is not available. > > ) > > at /usr/src/sys/dev/drm/drm_bufs.c:291 > > I can't quite tell how we got here from this trace... What graphics > hardware are you using and can you tell me what was going on when it > paniced? > >From dmesg: vgapci0: port 0xb000-0xb0ff mem 0xfd000000-0xfdffffff,0 xfeaff000-0xfeafffff irq 18 at device 6.0 on pci3 drm0: on vgapci0 info: [drm] Initialized mach64 2.0.0 20060718 >From pciconf -vl vgapci0@pci0:3:6:0: class=0x030000 card=0x80081002 chip=0x47521002 rev=0x27 hdr=0x00 vendor = 'ATI Technologies Inc' device = 'Rage XL PCI' class = display subclass = VGA IIRC, Motherboard is a Tyan Thunder K8SD Pro. I was using startx to start Xorg with a .xinitrc of #xsetroot -solid '#7332AE12B0A3' xset s on display -window root pics/freefield_1280x1024.jpg fvwm2 & xclock -geometry 85x85-5+3 -fg black -bg red & xload -geometry 85x85-5+103 -fg blue -bg yellow & xhost atlas troutmask hpc & coolmail -geometry 85x85-5+203 -f /var/mail/kargl & /usr/local/bin/ical -iconposition 1210,1000 & xterm -fn '10x20' -geometry 80x24 -iconic -name login -sb -sl 512 -fg black -bg BlanchedAlmond -cr red -ms red The panic appears to have occurred during the xhost command, but I believe it is related to loading Xorg's dri module. If I disable dri in my xorg.conf file, the system does not panic. If Xorg tries to load its dri module, I get an error message in Xorg's log file. Unfortunately, I don't have a copy of the message laying around here at home. I can panic the system tomorrow to get that message if you think it is required. I suspect that I need to recompile the Xorg server port, but that isn't mentioned anywhere in src/UPDATING. -- Steve From owner-freebsd-current@FreeBSD.ORG Wed Sep 3 05:39:00 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 192A1106566C for ; Wed, 3 Sep 2008 05:39:00 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outZ.internet-mail-service.net (outz.internet-mail-service.net [216.240.47.249]) by mx1.freebsd.org (Postfix) with ESMTP id 0625B8FC14 for ; Wed, 3 Sep 2008 05:38:59 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 1B0D424BF for ; Tue, 2 Sep 2008 22:39:00 -0700 (PDT) Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 5A5462D60A9 for ; Tue, 2 Sep 2008 22:38:59 -0700 (PDT) Message-ID: <48BE22F9.4070105@elischer.org> Date: Tue, 02 Sep 2008 22:39:05 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: install failure for loader X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2008 05:39:00 -0000 ===> sys/boot/i386/loader (install) make: don't know how to make /big/obj/usr/src/sys/boot/i386/loader/../../ficl/libficl.a. Stop *** Error code 2 current as of a few hours ago.. I've noticed that some people are looking at the loader.. does this ring a bell for anyone? Julian From owner-freebsd-current@FreeBSD.ORG Wed Sep 3 05:44:46 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 280461065670 for ; Wed, 3 Sep 2008 05:44:46 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outH.internet-mail-service.net (outh.internet-mail-service.net [216.240.47.231]) by mx1.freebsd.org (Postfix) with ESMTP id 13B358FC19 for ; Wed, 3 Sep 2008 05:44:45 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id D616524BF for ; Tue, 2 Sep 2008 22:44:46 -0700 (PDT) Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 7593A2D6011 for ; Tue, 2 Sep 2008 22:44:45 -0700 (PDT) Message-ID: <48BE2454.8020905@elischer.org> Date: Tue, 02 Sep 2008 22:44:52 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: FreeBSD Current References: <48BE22F9.4070105@elischer.org> In-Reply-To: <48BE22F9.4070105@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: install failure for loader X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2008 05:44:46 -0000 Julian Elischer wrote: > ===> sys/boot/i386/loader (install) > make: don't know how to make > /big/obj/usr/src/sys/boot/i386/loader/../../ficl/libficl.a. Stop > *** Error code 2 > > current as of a few hours ago.. > I've noticed that some people are looking at the loader.. > does this ring a bell for anyone? hmm blew away and rebuilt.. seems to be ok now.. please ignore. > > > Julian > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Wed Sep 3 10:04:31 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B2CBD1065671 for ; Wed, 3 Sep 2008 10:04:31 +0000 (UTC) (envelope-from kr.lekha@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.236]) by mx1.freebsd.org (Postfix) with ESMTP id 850348FC23 for ; Wed, 3 Sep 2008 10:04:31 +0000 (UTC) (envelope-from kr.lekha@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so3772356rvf.43 for ; Wed, 03 Sep 2008 03:04:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type; bh=H0ktQUyA2KCyS1Be9Zx248s8VuCl0eLMwMxcL4G+cFo=; b=ir0pnL99LdsQYSxBpDHHTa6vygjn/A+7bdovnGIU2I17r4jV+CCuuAKSbYQP3FjgvQ lVi1vhFaAfxZ+cuBUOd9gjoi6bXbvwZ3Th/3cznQCbk925rYHKSgV3j6gzoBknVsYsOL MU+xA1vYEPdGIl/yE0oR/stSk067W4VewuKw0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=tvn04OdFljfPhAEbnRnamEvHFMRgv6LL7PiRrtMZBrrQm0Qoz4sFj3S0Gka3L8LhE9 teUQLsAXmrOt5gMVqIt3hvVaddVBp0nnda12pKR5AebaWtUw7UgkM+U/JH6pegZl1Xnr WzGg7yQb4f81g5QoQ9g9DhAjqqAj6cIEECQlk= Received: by 10.141.168.16 with SMTP id v16mr4765654rvo.233.1220434320864; Wed, 03 Sep 2008 02:32:00 -0700 (PDT) Received: by 10.141.212.11 with HTTP; Wed, 3 Sep 2008 02:32:00 -0700 (PDT) Message-ID: <96b2ec350809030232v5586ea44nf6ead7d856f72634@mail.gmail.com> Date: Wed, 3 Sep 2008 10:32:00 +0100 From: "kr Lekha" To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Kthread kill X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2008 10:04:31 -0000 Hi, i wanted to kill a kthread created by my module, There is no actual kthread_kill to kill it hence I tried to send kill signal to thread psignal(p, SIGTERM); psignal(p, SIGKILL); killproc(p,"messeage"); and kthread_suspend() Nothing seems to be killing the kthread, I still see it [root@ /usr/src]# ps awx -l | grep kernel UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND 0 1048 1 0 20 0 0 8 ktsusp DL ?? 0:00.01 [new_kernel_thread] I have noticed that generally if kernel module wanted to kill a thread then it calls { wakeup(p); msleep(p,0); /*or tsleep*/ } This puts the thread to sleep forever. However kthread_suspend also performs same actions. Does scheduler take care to killing it? I read that after 2 min scheduler wakes up the thread and eventually kills it, i see the same kthread suspended even after a day I would appreciate any thoughts in this reagard. Thanks, -lekha From owner-freebsd-current@FreeBSD.ORG Wed Sep 3 13:12:47 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 57E6B106564A; Wed, 3 Sep 2008 13:12:47 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 122428FC13; Wed, 3 Sep 2008 13:12:46 +0000 (UTC) (envelope-from des@des.no) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 54ADA207E; Wed, 3 Sep 2008 15:12:45 +0200 (CEST) Received: by ds4.des.no (Postfix, from userid 1001) id 45C8B8447B; Wed, 3 Sep 2008 15:12:45 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: "army.of.root\@googlemail.com" References: <48BB403C.5090103@googlemail.com> Date: Wed, 03 Sep 2008 15:12:45 +0200 In-Reply-To: <48BB403C.5090103@googlemail.com> (army's message of "Mon, 01 Sep 2008 03:07:08 +0200") Message-ID: <86d4jl9xv6.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@FreeBSD.org, Rui Paulo Subject: Re: k8temp choose the higher temp of the two sensors on one core X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2008 13:12:47 -0000 "army.of.root@googlemail.com" writes: > I noticed that not the highest of the two temp values of one core is used: > > dev.cpu.0.temperature: 46 > dev.cpu.1.temperature: 46 <=3D=3D > dev.k8temp.0.%desc: AMD K8 Thermal Sensors > dev.k8temp.0.%driver: k8temp > dev.k8temp.0.%parent: hostb3 > dev.k8temp.0.sensor0.core0: 46 > dev.k8temp.0.sensor0.core1: 49 <=3D=3D > dev.k8temp.0.sensor1.core0: 46 > dev.k8temp.0.sensor1.core1: 46 > > I assume the dev.cpu.1.temperature sysctl comes from the k8temp > module, because it only shows up if it is loaded. That's not the only error: sysctlnode =3D SYSCTL_ADD_NODE(sysctlctx, SYSCTL_CHILDREN(device_get_sysctl_tree(dev)), OID_AUTO, "sensor= 1", CTLFLAG_RD, 0, "Sensor 1"); =20=20=20=20=20=20=20=20 SYSCTL_ADD_PROC(sysctlctx, SYSCTL_CHILDREN(sysctlnode), OID_AUTO, "core0", CTLTYPE_INT | CTLFLAG_RD, dev, SENSOR0_CORE0, k8temp_sysctl, "I", "Sensor 1 / Core 0 temperature"); =20=20=20=20=20=20=20=20 SYSCTL_ADD_PROC(sysctlctx, SYSCTL_CHILDREN(sysctlnode), OID_AUTO, "core1", CTLTYPE_INT | CTLFLAG_RD, dev, SENSOR0_CORE0, k8temp_sysctl, "I", "Sensor 1 / Core 1 temperature"); Another thing - wouldn't coreX.sensorY make more sense than sensorY.coreX? DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Wed Sep 3 13:14:45 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BE85A1065680 for ; Wed, 3 Sep 2008 13:14:45 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id 0C77B8FC18 for ; Wed, 3 Sep 2008 13:14:44 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from kobe.laptop (adsl83-19.kln.forthnet.gr [77.49.50.19]) (authenticated bits=128) by igloo.linux.gr (8.14.3/8.14.3/Debian-5) with ESMTP id m83DEV5E028711 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 3 Sep 2008 16:14:36 +0300 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.3/8.14.3) with ESMTP id m83DEU0C092214 for ; Wed, 3 Sep 2008 16:14:30 +0300 (EEST) (envelope-from keramida@freebsd.org) Received: (from keramida@localhost) by kobe.laptop (8.14.3/8.14.3/Submit) id m83DEUc1092196; Wed, 3 Sep 2008 16:14:30 +0300 (EEST) (envelope-from keramida@freebsd.org) From: Giorgos Keramidas To: freebsd-current@freebsd.org Date: Wed, 03 Sep 2008 16:14:30 +0300 Message-ID: <87hc8x74nd.fsf@kobe.laptop> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-MailScanner-ID: m83DEV5E028711 X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-4.288, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.11, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@freebsd.org X-Spam-Status: No Subject: cpio reporting too many 'blocks' X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2008 13:14:45 -0000 In a CURRENT snapshot built at: FreeBSD 8.0-CURRENT #0: Mon Sep 1 03:13:59 EEST 2008 bsdcpio is reporting _very_ large block counts: keramida@kobe:/ws/bsd/doc$ find * | cpio -p -dmu /hg/doc/bsd-import 757935406 blocks keramida@kobe:/ws/bsd/doc$ du -sh . 24M . keramida@kobe:/ws/bsd/doc$ env | fgrep BLOCK BLOCKSIZE=K I haven't tried building cpio from earlier versions yet, because an mpsafetty test patch is building as I type this. The last few commits seem related though: ------------------------------------------------------------------------ r182151 | kientzle | 2008-08-25 09:39:29 +0300 (Mon, 25 Aug 2008) | 6 lines MfP4: Verify correct interaction with umask: Add another file with different permissions and set a non-zero umask during the actual copy tests. The extra entry increases the size of the test archives of course, so adjust the expected sizes. ------------------------------------------------------------------------ r182102 | kientzle | 2008-08-24 09:21:00 +0300 (Sun, 24 Aug 2008) | 5 lines Update the total archive byte counters when writing entries to disk using archive_write_disk. Update cpio to use this to emit block counts in -p mode. Update cpio tests to verify these block counts. Is anyone else seeing similar/bogus cpio block counts? From owner-freebsd-current@FreeBSD.ORG Wed Sep 3 13:34:55 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5EBFD106567A for ; Wed, 3 Sep 2008 13:34:55 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: from ik-out-1112.google.com (ik-out-1112.google.com [66.249.90.179]) by mx1.freebsd.org (Postfix) with ESMTP id D8E488FC1D for ; Wed, 3 Sep 2008 13:34:54 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: by ik-out-1112.google.com with SMTP id c30so1451510ika.3 for ; Wed, 03 Sep 2008 06:34:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:date:from:to:cc :subject:message-id:references:mime-version:content-type :content-disposition:in-reply-to:user-agent:sender; bh=U1Uf7SYifCl90equQKHKVBxiAe2QgZrIpWCyV6GUHjU=; b=f1B1bjL0iti3f00SWFbEc3UhVe70MHPQ1wGIoHWVs7wa5YU8VzBEeJwNh3AKVafp// YIvwLwx4N0SOaLzrUunVlbOiNkVhqsF+qxXiPHDoexv/er7Uh72w+0x8QXWSiv1i+Lcb QqBK+l1DPFF5hE1BkuauMxTBcy7LhSTaXEaYo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent:sender; b=pPZKarTFrSjK5JeejtcoHFrETDPxGxkIANuqWFK4p/CojtEuDJU3tRU/+Z/ILKkEe0 ExUxWR0LlapzZTZZ9aJJWgsM7DCtkGlzB3Y8tXosGqvTJeTd5UVS5OwVlmeoVDzxXe7/ hrsbDPGP9VOd8iq30tQfNrBdYP9zlTSHbA6/Y= Received: by 10.210.89.4 with SMTP id m4mr10091496ebb.132.1220448893661; Wed, 03 Sep 2008 06:34:53 -0700 (PDT) Received: from alpha.local ( [83.144.140.92]) by mx.google.com with ESMTPS id 3sm12067056eyi.5.2008.09.03.06.34.52 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 03 Sep 2008 06:34:52 -0700 (PDT) Received: by alpha.local (Postfix, from userid 1001) id 704CFF3DE; Wed, 3 Sep 2008 14:33:56 +0100 (WEST) Date: Wed, 3 Sep 2008 14:33:56 +0100 From: Rui Paulo To: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= Message-ID: <20080903133356.GC21178@alpha.local> References: <48BB403C.5090103@googlemail.com> <86d4jl9xv6.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86d4jl9xv6.fsf@ds4.des.no> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: Rui Paulo Cc: "army.of.root@googlemail.com" , freebsd-current@FreeBSD.org, Rui Paulo Subject: Re: k8temp choose the higher temp of the two sensors on one core X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2008 13:34:55 -0000 On Wed, Sep 03, 2008 at 03:12:45PM +0200, Dag-Erling Smrgrav wrote: > That's not the only error: Fixed, thanks. > Another thing - wouldn't coreX.sensorY make more sense than > sensorY.coreX? Maybe. I'll think about it. Regards, -- Rui Paulo From owner-freebsd-current@FreeBSD.ORG Wed Sep 3 13:50:38 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AECCE106566C for ; Wed, 3 Sep 2008 13:50:38 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (unknown [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id 2501D8FC1A for ; Wed, 3 Sep 2008 13:50:37 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.2/8.14.2) with ESMTP id m83DoWEe021574; Wed, 3 Sep 2008 15:50:32 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.2/8.14.2/Submit) id m83DoVw6021573; Wed, 3 Sep 2008 15:50:31 +0200 (CEST) (envelope-from olli) Date: Wed, 3 Sep 2008 15:50:31 +0200 (CEST) Message-Id: <200809031350.m83DoVw6021573@lurza.secnetix.de> From: Oliver Fromme To: freebsd-current@FreeBSD.ORG, Alex Goncharov In-Reply-To: X-Newsgroups: list.freebsd-current User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.3-STABLE (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Wed, 03 Sep 2008 15:50:33 +0200 (CEST) Cc: Subject: Re: named mystery -- error: dumping master file: ??master/tmp-wTjhUzoix6 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-current@FreeBSD.ORG, Alex Goncharov List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2008 13:50:38 -0000 Alex Goncharov wrote: > In most environments I've been, including my home environment, the > idea that static and DHCP addresses have to be in different zones, > and/or be served by various DNS servers, would not be met > enthusiastically and probably would not fly at all. At home, I have > some static addresses and the rest is DHCP-assigned -- all in one > zone. Having two zones to accommodate a couple of static addresses > for the servers doesn't sound like a good idea to me. Of course you can have both dynamic and static entries within the same zone. But the question is: Is that zone only visible to your internal network, or is it public? If it's only internal, then the BIND jail serving that zone should be bound to an internal IP address, so an attacker from outside cannot break into the BIND jail. It is usually not a good idea to put dynamic entries of internal hosts into a zone that is served to the public internet. So it is not only an issue of static vs. dynamic, but also internal vs. public. Ideally your internal and public DNS would run on different machines, but that's probably overkill for a home network (I assume you don't have a DMZ network at home). Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "We will perhaps eventually be writing only small modules which are identi- fied by name as they are used to build larger ones, so that devices like indentation, rather than delimiters, might become feasible for expressing local structure in the source language." -- Donald E. Knuth, 1974 From owner-freebsd-current@FreeBSD.ORG Wed Sep 3 16:04:47 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F33BE1069121 for ; Wed, 3 Sep 2008 16:04:47 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from kientzle.com (kientzle.com [66.166.149.50]) by mx1.freebsd.org (Postfix) with ESMTP id 45B478FC1C for ; Wed, 3 Sep 2008 16:04:47 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from [10.0.0.128] (p54.kientzle.com [66.166.149.54]) by kientzle.com (8.12.9/8.12.9) with ESMTP id m83G4ctv080984; Wed, 3 Sep 2008 09:04:38 -0700 (PDT) (envelope-from kientzle@freebsd.org) Message-ID: <48BEB5E1.8080906@freebsd.org> Date: Wed, 03 Sep 2008 09:05:53 -0700 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20060422 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Giorgos Keramidas References: <87hc8x74nd.fsf@kobe.laptop> In-Reply-To: <87hc8x74nd.fsf@kobe.laptop> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: cpio reporting too many 'blocks' X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2008 16:04:48 -0000 Giorgos Keramidas wrote: > In a CURRENT snapshot built at: > FreeBSD 8.0-CURRENT #0: Mon Sep 1 03:13:59 EEST 2008 > > bsdcpio is reporting _very_ large block counts: > > keramida@kobe:/ws/bsd/doc$ find * | cpio -p -dmu /hg/doc/bsd-import > 757935406 blocks > keramida@kobe:/ws/bsd/doc$ du -sh . > 24M . > keramida@kobe:/ws/bsd/doc$ env | fgrep BLOCK > BLOCKSIZE=K What does 'find * | xargs cat | wc -c' show? > I haven't tried building cpio from earlier versions yet, because an > mpsafetty test patch is building as I type this. The last few commits > seem related though: > > ------------------------------------------------------------------------ > r182151 | kientzle | 2008-08-25 09:39:29 +0300 (Mon, 25 Aug 2008) | 6 lines This is just a change to the regression tests. Certainly not relevant. > ------------------------------------------------------------------------ > r182102 | kientzle | 2008-08-24 09:21:00 +0300 (Sun, 24 Aug 2008) | 5 lines > > Update the total archive byte counters when writing entries to disk using > archive_write_disk. > Update cpio to use this to emit block counts in -p mode. > Update cpio tests to verify these block counts. Prior to this commit, cpio didn't emit block counts in -p mode at all. I suppose reversing this commit might qualify as "fixing" the problem, but I'd like to do better. ;-) I'll take a look... Tim From owner-freebsd-current@FreeBSD.ORG Wed Sep 3 16:17:41 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D58541068984 for ; Wed, 3 Sep 2008 16:17:41 +0000 (UTC) (envelope-from rink@rink.nu) Received: from mx1.rink.nu (gloom.rink.nu [213.34.49.2]) by mx1.freebsd.org (Postfix) with ESMTP id 9780F8FC13 for ; Wed, 3 Sep 2008 16:17:40 +0000 (UTC) (envelope-from rink@rink.nu) Received: from localhost (localhost [127.0.0.1]) by mx1.rink.nu (Postfix) with ESMTP id A51386D453; Wed, 3 Sep 2008 18:19:24 +0200 (CEST) X-Virus-Scanned: amavisd-new at rink.nu Received: from mx1.rink.nu ([213.34.49.2]) by localhost (gloom.rink.nu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GF9He9mbZ4lc; Wed, 3 Sep 2008 18:19:16 +0200 (CEST) Received: by mx1.rink.nu (Postfix, from userid 1000) id 2F6BB6D450; Wed, 3 Sep 2008 18:19:16 +0200 (CEST) Date: Wed, 3 Sep 2008 18:19:16 +0200 From: Rink Springer To: ticso@cicely.de Message-ID: <20080903161916.GC95039@rink.nu> References: <20080903034943.GD11548@cicely7.cicely.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080903034943.GD11548@cicely7.cicely.de> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-current@freebsd.org Subject: Re: MTRR fixup? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2008 16:17:41 -0000 Hi Bernd, On Wed, Sep 03, 2008 at 05:49:44AM +0200, Bernd Walter wrote: > Some boards (including my Intel DG33BU) seem to have problems setting > up the mtrr to cache all RAM. > My system runs fast with 2G and ist about 6 times slower in buildworld > with 6G RAM. > I will try a BIOS update once Intels tells me why their update ISO > just turn the system off instead of updating the BIOS - sigh. > But it seems that Linux is doing some kind of fixup for MTRR: > http://lkml.org/lkml/2008/1/18/170 > Can we do something similar? This is interesting, my motherboard (Intel DP965LT) seems to suffer from the same problem: putting 4GB of memory in it makes it dog slow, while putting 2GB in it makes it lightning fast... I've just given up trying to put 4GB of memory in this machine, but I believe this may help... Please, keep me posted if the BIOS update fixes it for you. Regards, -- Rink P.W. Springer - http://rink.nu "Anyway boys, this is America. Just because you get more votes doesn't mean you win." - Fox Mulder From owner-freebsd-current@FreeBSD.ORG Wed Sep 3 17:56:24 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E8C02107AD2A for ; Wed, 3 Sep 2008 17:56:24 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id 32ED28FC15 for ; Wed, 3 Sep 2008 17:56:23 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from kobe.laptop (adsl83-19.kln.forthnet.gr [77.49.50.19]) (authenticated bits=128) by igloo.linux.gr (8.14.3/8.14.3/Debian-5) with ESMTP id m83HttYV016961 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 3 Sep 2008 20:56:01 +0300 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.3/8.14.3) with ESMTP id m83HttIS002790; Wed, 3 Sep 2008 20:55:55 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Received: (from keramida@localhost) by kobe.laptop (8.14.3/8.14.3/Submit) id m83Htraw002789; Wed, 3 Sep 2008 20:55:53 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) From: Giorgos Keramidas To: Ed Schouten References: <87fxot5hoi.fsf@kobe.laptop> <20080902164759.GL99951@hoeg.nl> <871w029oc3.fsf@kobe.laptop> Date: Wed, 03 Sep 2008 20:55:53 +0300 In-Reply-To: <871w029oc3.fsf@kobe.laptop> (Giorgos Keramidas's message of "Wed, 03 Sep 2008 01:26:20 +0300") Message-ID: <87skshf712.fsf@kobe.laptop> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-MailScanner-ID: m83HttYV016961 X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-3.837, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.56, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@ceid.upatras.gr X-Spam-Status: No Cc: FreeBSD Current Subject: Re: CFT: pts(4) "packet mode" support X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2008 17:56:25 -0000 On Wed, 03 Sep 2008 01:26:20 +0300, Giorgos Keramidas wrote: > On Tue, 2 Sep 2008 18:47:59 +0200, Ed Schouten wrote: >> Hello everyone, >> >> One of the things I couldn't fix in time for the MPSAFE TTY import, was >> pts(4) packet mode. Because people have noticed it was missing, I >> decided to implement it, for inclusion in the SVN tree. ;-) >> >> Giorgos and I have already tried the attached patch, but it would be >> nice if others could test it as well. I'm planning to integrate this >> patch by the end of the week. >> >> Any feedback? Comments? Obscure panics? > > Thanks! I've been rebasing the patch on top of /head for a while, and > running with a kernel that includes: > > http://people.freebsd.org/~keramida/mpsafetty/ > > The last time I resynced/merged was some time yesterday noon. I will > install this patch now, but FWIW things seem 'ok' so far with the local > version of the patch I was merging on top of /head :-) Ok, I've installed the patch and have been running with it for a few hours. The obvious consumers of the packet mode seem to work so far, i.e. `C-s' works in Emacs, `C-q quoted-char' works in Emacs, ^V^S and ^V^Q work fine in vi, and the same tests inside or outside screen work. Thanks :) From owner-freebsd-current@FreeBSD.ORG Wed Sep 3 19:42:31 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 59209106564A for ; Wed, 3 Sep 2008 19:42:31 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from mail-gw0.york.ac.uk (mail-gw0.york.ac.uk [144.32.128.245]) by mx1.freebsd.org (Postfix) with ESMTP id C946B8FC14 for ; Wed, 3 Sep 2008 19:42:30 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from mail-gw7.york.ac.uk (mail-gw7.york.ac.uk [144.32.129.30]) by mail-gw0.york.ac.uk (8.13.6/8.13.6) with ESMTP id m83JBvO8011665; Wed, 3 Sep 2008 20:11:57 +0100 (BST) Received: from ury.york.ac.uk ([144.32.108.81]) by mail-gw7.york.ac.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1Kaxll-0002VR-Kd; Wed, 03 Sep 2008 20:11:57 +0100 Received: from ury.york.ac.uk (localhost.york.ac.uk [127.0.0.1]) by ury.york.ac.uk (8.14.2/8.14.2) with ESMTP id m83JBvfY063168; Wed, 3 Sep 2008 20:11:57 +0100 (BST) (envelope-from gavin@FreeBSD.org) Received: from localhost (gavin@localhost) by ury.york.ac.uk (8.14.2/8.14.2/Submit) with ESMTP id m83JBupa063160; Wed, 3 Sep 2008 20:11:57 +0100 (BST) (envelope-from gavin@FreeBSD.org) X-Authentication-Warning: ury.york.ac.uk: gavin owned process doing -bs Date: Wed, 3 Sep 2008 20:11:56 +0100 (BST) From: Gavin Atkinson X-X-Sender: gavin@ury.york.ac.uk To: David Naylor In-Reply-To: <200809011921.40737.naylor.b.david@gmail.com> Message-ID: <20080903200611.Y57629@ury.york.ac.uk> References: <200809011921.40737.naylor.b.david@gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-York-MailScanner: Found to be clean X-York-MailScanner-From: gavin@freebsd.org Cc: freebsd-current@FreeBSD.org Subject: Re: powerd and multicore X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2008 19:42:31 -0000 On Mon, 1 Sep 2008, David Naylor wrote: > The way I understand powerd works by default is that it monitors the CPU usage > (or idleness) and changes the CPU frequency accordingly. The default values > are >95% idle => decrease frequency; <65% idle => increase frequency. > > The problem arises when you have a system with 4 or more 'cores'. In this > case the first CPU can be running flat out but still report an overall > idleness of 75% and thus the frequency is not increased even though the first > core could easily be stuck, at say 200 when capable of 2400. > > Should powerd be changed to look at CPU specific usage and adjust accordingly > or scale the above defaults according to the number of CPU's. There are a handful of PRs discussing this exact issue, and it is something I was hoping to look into at some point. Have a search for powerd PRs, especially http://www.freebsd.org/cgi/query-pr.cgi?pr=119589 (which contains patches). You may well also be better off discussing this on the -acpi mailing list, which (although this is not strictly related to ACPI) may be the best place to find people ihnterested in power management. > Furthermore, currently (with core 2) all CPU's are controlled using a single > value however (I think) it is possible to have each CPU running on a > different frequency (and at least with some other architectures). Does > powerd handle these cases? I don't believe so, no. I also don't know if the kernel would be ok with CPUs running at different speeds, even if things like timecounters work correctly the scheduler may need to grow some more knowledge of this. Gavin From owner-freebsd-current@FreeBSD.ORG Wed Sep 3 19:52:01 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AF378106566C for ; Wed, 3 Sep 2008 19:52:01 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id 740348FC14 for ; Wed, 3 Sep 2008 19:52:01 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from [192.168.166.46] ([68.0.14.34]) (authenticated bits=0) by gizmo.2hip.net (8.13.8/8.13.8) with ESMTP id m83Jpweq035112 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Sep 2008 15:51:58 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Steve Kargl In-Reply-To: <20080903051228.GA2475@troutmask.apl.washington.edu> References: <20080903011612.GA1242@troutmask.apl.washington.edu> <1220416793.1848.1.camel@wombat.2hip.net> <20080903051228.GA2475@troutmask.apl.washington.edu> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-hnEUpu1d9OLtU7kYgntx" Organization: FreeBSD Date: Wed, 03 Sep 2008 15:51:52 -0400 Message-Id: <1220471512.11763.9.camel@squirrel.corp.cox.com> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 FreeBSD GNOME Team Port X-Spam-Status: No, score=-0.8 required=5.0 tests=AWL,BAYES_00, RCVD_IN_SORBS_DUL autolearn=no version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on gizmo.2hip.net Cc: freebsd-current@FreeBSD.org Subject: Re: drm causes kernel panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2008 19:52:01 -0000 --=-hnEUpu1d9OLtU7kYgntx Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2008-09-02 at 22:12 -0700, Steve Kargl wrote: > On Wed, Sep 03, 2008 at 12:39:53AM -0400, Robert Noland wrote: > > On Tue, 2008-09-02 at 18:16 -0700, Steve Kargl wrote: > > > #0 doadump () at pcpu.h:195 > > > #1 0xffffffff802ee4da in boot (howto=3D260) > > > at /usr/src/sys/kern/kern_shutdown.c:418 > > > #2 0xffffffff802ee947 in panic (fmt=3DVariable "fmt" is not availabl= e. > > > ) > > > at /usr/src/sys/kern/kern_shutdown.c:572 > > > #3 0xffffffff803301ca in witness_unlock (lock=3D0xffffffff806f3d60, = flags=3D8,=20 > > > file=3D0xffffffff8055dc88 "/usr/src/sys/dev/drm/drm_pci.c", line= =3D77) > > > at /usr/src/sys/kern/subr_witness.c:1460 > > > #4 0xffffffff802e20c6 in _mtx_unlock_flags (m=3D0xffffff00017b41a8, = opts=3D0,=20 > > > file=3D0xffffffff8055dc88 "/usr/src/sys/dev/drm/drm_pci.c", line= =3D77) > > > at /usr/src/sys/kern/kern_mutex.c:199 > > > #5 0xffffffff8021a945 in drm_pci_alloc (dev=3DVariable "dev" is not = available. > > > ) > > > at /usr/src/sys/dev/drm/drm_pci.c:77 > > > #6 0xffffffff80214654 in drm_addmap (dev=3D0xffffff00017b4000, offse= t=3D0,=20 > > > size=3D16384, type=3D_DRM_CONSISTENT, flags=3DVariable "flags" is= not available. > > > ) > > > at /usr/src/sys/dev/drm/drm_bufs.c:247 > > > #7 0xffffffff80214b8b in drm_addmap_ioctl (dev=3D0xffffff00017b4000,= =20 > > > data=3D0xffffff000576c480, file_priv=3DVariable "file_priv" is no= t available. > > > ) > > > at /usr/src/sys/dev/drm/drm_bufs.c:291 > >=20 > > I can't quite tell how we got here from this trace... What graphics > > hardware are you using and can you tell me what was going on when it > > paniced? > >=20 >=20 > From dmesg: >=20 > vgapci0: port 0xb000-0xb0ff mem 0xfd000000-0xfdf= fffff,0 > xfeaff000-0xfeafffff irq 18 at device 6.0 on pci3 > drm0: on vgapci0 > info: [drm] Initialized mach64 2.0.0 20060718 Ok, I've found the problem... It is easy enough to fix your specific situation, but doing so will cause problems for other drivers... Which is the reason that I made that change to begin with. The big problem is that drm_pci_alloc gets called from a variety of places, some of which already hold locks while others don't. We aren't allowed to hold locks over some of the bus_dma functions, so I have to go through all of these paths and figure out if it is generally safe to always drop the locks, or if I need to restructure the code somehow... If you want a patch to just get you going temporarily, just let me know... robert. > From pciconf -vl >=20 > vgapci0@pci0:3:6:0: class=3D0x030000 card=3D0x80081002 chip=3D0x47521= 002 rev=3D0x27 hdr=3D0x00 > vendor =3D 'ATI Technologies Inc' > device =3D 'Rage XL PCI' > class =3D display > subclass =3D VGA >=20 > IIRC, Motherboard is a Tyan Thunder K8SD Pro. >=20 > I was using startx to start Xorg with a .xinitrc of=20 >=20 > #xsetroot -solid '#7332AE12B0A3' > xset s on > display -window root pics/freefield_1280x1024.jpg > fvwm2 & > xclock -geometry 85x85-5+3 -fg black -bg red & > xload -geometry 85x85-5+103 -fg blue -bg yellow & > xhost atlas troutmask hpc & > coolmail -geometry 85x85-5+203 -f /var/mail/kargl & > /usr/local/bin/ical -iconposition 1210,1000 & > xterm -fn '10x20' -geometry 80x24 -iconic -name login -sb -sl 512 -fg bla= ck -bg BlanchedAlmond -cr red -ms red=20 >=20 > The panic appears to have occurred during the xhost command, but > I believe it is related to loading Xorg's dri module. If I disable > dri in my xorg.conf file, the system does not panic. If Xorg tries > to load its dri module, I get an error message in Xorg's log file. > Unfortunately, I don't have a copy of the message laying around > here at home. I can panic the system tomorrow to get that=20 > message if you think it is required. >=20 > I suspect that I need to recompile the Xorg server port, but > that isn't mentioned anywhere in src/UPDATING. >=20 --=-hnEUpu1d9OLtU7kYgntx Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEABECAAYFAki+6tgACgkQM4TrQ4qfRONWmQCcDTKLGf5dV/8VpL+5Zh/OpJhj 4hEAoIYVkUR/HKqfkeEOXMduqSOyFH+D =b1Mg -----END PGP SIGNATURE----- --=-hnEUpu1d9OLtU7kYgntx-- From owner-freebsd-current@FreeBSD.ORG Wed Sep 3 19:58:45 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A18EB1065679; Wed, 3 Sep 2008 19:58:45 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.freebsd.org (Postfix) with ESMTP id 6923D8FC17; Wed, 3 Sep 2008 19:58:45 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.3/8.14.3) with ESMTP id m83JwjCO001383; Wed, 3 Sep 2008 12:58:45 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.3/8.14.3/Submit) id m83JwjP1001382; Wed, 3 Sep 2008 12:58:45 -0700 (PDT) (envelope-from sgk) Date: Wed, 3 Sep 2008 12:58:45 -0700 From: Steve Kargl To: Robert Noland Message-ID: <20080903195845.GA1370@troutmask.apl.washington.edu> References: <20080903011612.GA1242@troutmask.apl.washington.edu> <1220416793.1848.1.camel@wombat.2hip.net> <20080903051228.GA2475@troutmask.apl.washington.edu> <1220471512.11763.9.camel@squirrel.corp.cox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1220471512.11763.9.camel@squirrel.corp.cox.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@FreeBSD.org Subject: Re: drm causes kernel panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2008 19:58:45 -0000 On Wed, Sep 03, 2008 at 03:51:52PM -0400, Robert Noland wrote: > On Tue, 2008-09-02 at 22:12 -0700, Steve Kargl wrote: >> >> From dmesg: >> >> vgapci0: port 0xb000-0xb0ff mem 0xfd000000-0xfdffffff,0 >> xfeaff000-0xfeafffff irq 18 at device 6.0 on pci3 >> drm0: on vgapci0 >> info: [drm] Initialized mach64 2.0.0 20060718 > > Ok, I've found the problem... It is easy enough to fix your specific > situation, but doing so will cause problems for other drivers... Which > is the reason that I made that change to begin with. The big problem is > that drm_pci_alloc gets called from a variety of places, some of which > already hold locks while others don't. We aren't allowed to hold locks > over some of the bus_dma functions, so I have to go through all of these > paths and figure out if it is generally safe to always drop the locks, > or if I need to restructure the code somehow... If you want a patch to > just get you going temporarily, just let me know... > I can disable Xorg's dri module. When you have a patch you're happy with, feel free to ping me for testing. -- Steve From owner-freebsd-current@FreeBSD.ORG Wed Sep 3 20:48:06 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D54A81065689 for ; Wed, 3 Sep 2008 20:48:06 +0000 (UTC) (envelope-from dwmalone@maths.tcd.ie) Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [IPv6:2001:770:10:300::86e2:510b]) by mx1.freebsd.org (Postfix) with SMTP id 332F48FC08 for ; Wed, 3 Sep 2008 20:48:06 +0000 (UTC) (envelope-from dwmalone@maths.tcd.ie) Received: from walton.maths.tcd.ie ([134.226.81.10] helo=walton.maths.tcd.ie) by salmon.maths.tcd.ie with SMTP id ; 3 Sep 2008 21:47:59 +0100 (BST) Date: Wed, 3 Sep 2008 21:47:59 +0100 From: David Malone To: ticso@cicely.de Message-ID: <20080903204759.GA4898@walton.maths.tcd.ie> References: <20080903034943.GD11548@cicely7.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080903034943.GD11548@cicely7.cicely.de> User-Agent: Mutt/1.5.6i Sender: dwmalone@maths.tcd.ie Cc: Bernd Walter , freebsd-current@freebsd.org Subject: Re: MTRR fixup? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2008 20:48:06 -0000 On Wed, Sep 03, 2008 at 05:49:44AM +0200, Bernd Walter wrote: > Some boards (including my Intel DG33BU) seem to have problems setting > up the mtrr to cache all RAM. > My system runs fast with 2G and ist about 6 times slower in buildworld > with 6G RAM. > I will try a BIOS update once Intels tells me why their update ISO > just turn the system off instead of updating the BIOS - sigh. > But it seems that Linux is doing some kind of fixup for MTRR: > http://lkml.org/lkml/2008/1/18/170 > Can we do something similar? You may be able to fix this by just using the memcontrol command - it already lets you program the MTRRs. David. From owner-freebsd-current@FreeBSD.ORG Wed Sep 3 21:19:51 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AB8391065676 for ; Wed, 3 Sep 2008 21:19:51 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id 198888FC13 for ; Wed, 3 Sep 2008 21:19:50 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from kobe.laptop (adsl83-19.kln.forthnet.gr [77.49.50.19]) (authenticated bits=128) by igloo.linux.gr (8.14.3/8.14.3/Debian-5) with ESMTP id m83LJcrt030002 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 4 Sep 2008 00:19:44 +0300 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.3/8.14.3) with ESMTP id m83LJaVe002624; Thu, 4 Sep 2008 00:19:37 +0300 (EEST) (envelope-from keramida@freebsd.org) Received: (from keramida@localhost) by kobe.laptop (8.14.3/8.14.3/Submit) id m83LJaw4002623; Thu, 4 Sep 2008 00:19:36 +0300 (EEST) (envelope-from keramida@freebsd.org) From: Giorgos Keramidas To: Tim Kientzle References: <87hc8x74nd.fsf@kobe.laptop> <48BEB5E1.8080906@freebsd.org> Date: Thu, 04 Sep 2008 00:19:35 +0300 In-Reply-To: <48BEB5E1.8080906@freebsd.org> (Tim Kientzle's message of "Wed, 03 Sep 2008 09:05:53 -0700") Message-ID: <87ej41rkpk.fsf@kobe.laptop> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-MailScanner-ID: m83LJcrt030002 X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-4.286, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.11, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@freebsd.org X-Spam-Status: No Cc: freebsd-current@freebsd.org Subject: Re: cpio reporting too many 'blocks' X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2008 21:19:51 -0000 On Wed, 03 Sep 2008 09:05:53 -0700, Tim Kientzle wrote: > Giorgos Keramidas wrote: >> In a CURRENT snapshot built at: >> FreeBSD 8.0-CURRENT #0: Mon Sep 1 03:13:59 EEST 2008 >> >> bsdcpio is reporting _very_ large block counts: >> >> keramida@kobe:/ws/bsd/doc$ find * | cpio -p -dmu /hg/doc/bsd-import >> 757935406 blocks >> keramida@kobe:/ws/bsd/doc$ du -sh . >> 24M . >> keramida@kobe:/ws/bsd/doc$ env | fgrep BLOCK >> BLOCKSIZE=K > > What does 'find * | xargs cat | wc -c' show? This is a clean (but partial) checkout of out doc/ tree: keramida@kobe:/ws/bsd/doc$ find * | xargs cat | wc -c 20948320 keramida@kobe:/ws/bsd/doc$ ls -l total 12 drwxrwxr-x 2 keramida users - 512 Aug 21 22:02 CVS -rw-rw-r-- 1 keramida users - 1691 Apr 15 2007 Makefile -rw-rw-r-- 1 keramida users - 392 Oct 13 2001 README drwxrwxr-x 7 keramida users - 512 Aug 10 11:48 el_GR.ISO8859-7 drwxrwxr-x 8 keramida users - 512 Sep 3 18:28 en_US.ISO8859-1 drwxrwxr-x 12 keramida users - 512 Aug 3 19:22 share keramida@kobe:/ws/bsd/doc$ I'm using this to import snapshots of the CVS doc/ tree to the main translation tree we keep for Greek docs. >> ------------------------------------------------------------------------ >> r182102 | kientzle | 2008-08-24 09:21:00 +0300 (Sun, 24 Aug 2008) | 5 lines >> >> Update the total archive byte counters when writing entries to disk using >> archive_write_disk. >> Update cpio to use this to emit block counts in -p mode. >> Update cpio tests to verify these block counts. > > Prior to this commit, cpio didn't emit block counts in -p mode at all. > I suppose reversing this commit might qualify as "fixing" the problem, > but I'd like to do better. ;-) ACK. If you want me to run any tests or test patches, please feel free to send them this way :-) From owner-freebsd-current@FreeBSD.ORG Wed Sep 3 21:58:24 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 47CCD106569B for ; Wed, 3 Sep 2008 21:58:24 +0000 (UTC) (envelope-from josh.carroll@gmail.com) Received: from mail-gx0-f17.google.com (mail-gx0-f17.google.com [209.85.217.17]) by mx1.freebsd.org (Postfix) with ESMTP id 0246C8FC28 for ; Wed, 3 Sep 2008 21:58:23 +0000 (UTC) (envelope-from josh.carroll@gmail.com) Received: by gxk10 with SMTP id 10so6241769gxk.19 for ; Wed, 03 Sep 2008 14:58:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:reply-to :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=Xv3ICoB/tlqRxfWUEjFae7hQhavc3g9cHDxT24sycuA=; b=n6tvT+wZ3nT590yNKuk0qIombXyaItlJxgXEqJMlcoyBNJ5unXsAJ7Q2ja0al3r5RX 83ru6qe4P3YXqmlcOZWQnzAT17lzm0LZ/yEKsF8tVbHJLJQOnvA7+wQreLFHHtvmyHzT 03IVLOYiSSMqfyNuqF4oOjMtvzzM06DRLBgk0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:reply-to:to:subject:cc:in-reply-to :mime-version:content-type:content-transfer-encoding :content-disposition:references; b=M9jdpnF9mcH+rYgmp9yoY+gg31d/eqEjSNH7rcGTjGcgj8fNFUJ5h6jg9jafDWZ0nT rqzUatZrdEXhP/HtPnHi8rIxhddoFYtZ0fzS1akGNkUBE/ozlzMT/7WumDJxHYmQuCkV FAgtWWG2PgP3dGQhoG1okB9tkiuW/BrVF/reE= Received: by 10.150.58.5 with SMTP id g5mr13201558yba.27.1220479103400; Wed, 03 Sep 2008 14:58:23 -0700 (PDT) Received: by 10.150.140.14 with HTTP; Wed, 3 Sep 2008 14:58:18 -0700 (PDT) Message-ID: <8cb6106e0809031458k51d9e23byd157bc1608613ec8@mail.gmail.com> Date: Wed, 3 Sep 2008 17:58:18 -0400 From: "Josh Carroll" To: "David Malone" In-Reply-To: <20080903204759.GA4898@walton.maths.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20080903034943.GD11548@cicely7.cicely.de> <20080903204759.GA4898@walton.maths.tcd.ie> Cc: Bernd Walter , ticso@cicely.de, freebsd-current@freebsd.org Subject: Re: MTRR fixup? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: josh.carroll@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2008 21:58:24 -0000 > You may be able to fix this by just using the memcontrol command - > it already lets you program the MTRRs. Yes, specifically: memcontrol clear -b 0x... -l 0x.... Where the argument to -b is the first address listed from memcontrol list, and the -l argument is the second address in the list. E.g. for my ranges: 0xd0000000/0x10000000 BIOS uncacheable set-by-firmware active 0xe0000000/0x20000000 BIOS uncacheable set-by-firmware active I used: memcontrol clear -b 0xd0000000 -l 0x10000000 memcontrol clear -b 0xe0000000 -l 0x20000000 No adverse reaction so far... Josh From owner-freebsd-current@FreeBSD.ORG Wed Sep 3 22:08:04 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 944701065671 for ; Wed, 3 Sep 2008 22:08:04 +0000 (UTC) (envelope-from josh.carroll@gmail.com) Received: from mail-gx0-f17.google.com (mail-gx0-f17.google.com [209.85.217.17]) by mx1.freebsd.org (Postfix) with ESMTP id 3AE8A8FC08 for ; Wed, 3 Sep 2008 22:08:03 +0000 (UTC) (envelope-from josh.carroll@gmail.com) Received: by gxk10 with SMTP id 10so6246393gxk.19 for ; Wed, 03 Sep 2008 15:08:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:reply-to :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=HYfyRgovlM7bZxI0pqttdaMW4ArLlJdWxkmA22TfX8g=; b=QG5RaETddRjm0tsESnxDD9NSlW+afgiXekqWUAWXvzOWiurV1p3qMlsSxb5RB8bmVV V1wveXvaDvvkfSMEx4MoTVaEOpclFzWy+U1CPd0u3z0qoNgjNZoT0KjeaoMlmYMok8PO HFtIdHK5HEL/35rCnsuv26knzaTFJT+Ift9dM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:reply-to:to:subject:cc:in-reply-to :mime-version:content-type:content-transfer-encoding :content-disposition:references; b=PDnqMU+jee+uSajcRcGNG4FKD4SHcvHwCNBj9IpH6PXE/sHvydH0DH4qNyrTA2V8Vu PoFbLQagxcFZ06OaHxrTRrw2UWLPkRgFWtubRzaxgsoIQYABjsprj5jcxZNMu3RFIaY4 rCxIjxzsu/WOHQYp/38GLIG37kQUJ8/uEXy0A= Received: by 10.151.42.21 with SMTP id u21mr3267441ybj.40.1220478395357; Wed, 03 Sep 2008 14:46:35 -0700 (PDT) Received: by 10.150.140.14 with HTTP; Wed, 3 Sep 2008 14:46:35 -0700 (PDT) Message-ID: <8cb6106e0809031446i3e2a47dar385125ecfb0275dc@mail.gmail.com> Date: Wed, 3 Sep 2008 17:46:35 -0400 From: "Josh Carroll" To: "David Malone" In-Reply-To: <20080903204759.GA4898@walton.maths.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20080903034943.GD11548@cicely7.cicely.de> <20080903204759.GA4898@walton.maths.tcd.ie> Cc: Bernd Walter , ticso@cicely.de, freebsd-current@freebsd.org Subject: Re: MTRR fixup? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: josh.carroll@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2008 22:08:04 -0000 > You may be able to fix this by just using the memcontrol command - > it already lets you program the MTRRs. Hmm, I think this explains why the amount of ACTIVE memory never exceeds 3G on this box with 4G (with very little WIRED when it "stops" at 3G). I'm guessing this means I am affected: 0xd0000000/0x10000000 BIOS uncacheable set-by-firmware active 0xe0000000/0x20000000 BIOS uncacheable set-by-firmware active I wrote a little script to parse the memcontrol output to make it a little easier to digest at a glance. Memory range [a0000 - a4000] : (640 - 656) is uncacheable {16 KB} Memory range [a4000 - a8000] : (656 - 672) is uncacheable {16 KB} Memory range [a8000 - ac000] : (672 - 688) is uncacheable {16 KB} Memory range [ac000 - b0000] : (688 - 704) is uncacheable {16 KB} Memory range [b0000 - b4000] : (704 - 720) is uncacheable {16 KB} Memory range [b4000 - b8000] : (720 - 736) is uncacheable {16 KB} Memory range [b8000 - bc000] : (736 - 752) is uncacheable {16 KB} Memory range [bc000 - c0000] : (752 - 768) is uncacheable {16 KB} Memory range [d0000000 - e0000000] : (3407872 - 3670016) is uncacheable {262144 KB} Memory range [e0000000 - 100000000] : (3670016 - 4194304) is uncacheable {524288 KB} So if I'm understanding this correctly, the top 768 MB of physical memory on this box is uncacheable, but usable for other purposes? I guess I haven't noticed this since FreeBSD does not (apparently?) start caching from the top of memory like Linux does? I'll have to play with memcontrol to see if I can set those two large ranges as cacheable. So this is a BIOS bug? The board in question is an Asus P5K-E with BIOS revision 1102, which uses an Intel P35 chipset. Can someone confirm whether the above assumptions are correct? Thanks, Josh From owner-freebsd-current@FreeBSD.ORG Wed Sep 3 22:39:31 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2CCAA106566C for ; Wed, 3 Sep 2008 22:39:31 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id B883E8FC16 for ; Wed, 3 Sep 2008 22:39:30 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.local ([192.168.254.200]) (authenticated bits=0) by pooker.samsco.org (8.14.2/8.14.2) with ESMTP id m83MdKav043797; Wed, 3 Sep 2008 16:39:21 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <48BF1218.6000504@samsco.org> Date: Wed, 03 Sep 2008 16:39:20 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.13) Gecko/20080313 SeaMonkey/1.1.9 MIME-Version: 1.0 To: josh.carroll@gmail.com References: <20080903034943.GD11548@cicely7.cicely.de> <20080903204759.GA4898@walton.maths.tcd.ie> <8cb6106e0809031446i3e2a47dar385125ecfb0275dc@mail.gmail.com> In-Reply-To: <8cb6106e0809031446i3e2a47dar385125ecfb0275dc@mail.gmail.com> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.4 required=3.8 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: David Malone , Bernd Walter , ticso@cicely.de, freebsd-current@freebsd.org Subject: Re: MTRR fixup? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2008 22:39:31 -0000 Josh Carroll wrote: >> You may be able to fix this by just using the memcontrol command - >> it already lets you program the MTRRs. > > Hmm, I think this explains why the amount of ACTIVE memory never > exceeds 3G on this box with 4G (with very little WIRED when it "stops" > at 3G). Actually, it likely doesn't. > > I'm guessing this means I am affected: > > 0xd0000000/0x10000000 BIOS uncacheable set-by-firmware active > 0xe0000000/0x20000000 BIOS uncacheable set-by-firmware active All systems reserve the top 256MB of the address space for PCI memory and chipset registers. Modern systems have started reserving even more than that for other new PCI functionality. Note that this is address space, not RAM. The RAM is likely being remapped to some place above the 4GB barrier. > > I wrote a little script to parse the memcontrol output to make it a > little easier to digest at a glance. > > Memory range [a0000 - a4000] : (640 - 656) is uncacheable {16 KB} > Memory range [a4000 - a8000] : (656 - 672) is uncacheable {16 KB} > Memory range [a8000 - ac000] : (672 - 688) is uncacheable {16 KB} > Memory range [ac000 - b0000] : (688 - 704) is uncacheable {16 KB} > Memory range [b0000 - b4000] : (704 - 720) is uncacheable {16 KB} > Memory range [b4000 - b8000] : (720 - 736) is uncacheable {16 KB} > Memory range [b8000 - bc000] : (736 - 752) is uncacheable {16 KB} > Memory range [bc000 - c0000] : (752 - 768) is uncacheable {16 KB} > Memory range [d0000000 - e0000000] : (3407872 - 3670016) is > uncacheable {262144 KB} > Memory range [e0000000 - 100000000] : (3670016 - 4194304) is > uncacheable {524288 KB} > > So if I'm understanding this correctly, the top 768 MB of physical > memory on this box is uncacheable, but usable for other purposes? Used for PCI, yes. > > I guess I haven't noticed this since FreeBSD does not (apparently?) > start caching from the top of memory like Linux does? Irrelevant observation =-) > > I'll have to play with memcontrol to see if I can set those two large > ranges as cacheable. So this is a BIOS bug? The board in question is > an Asus P5K-E with BIOS revision 1102, which uses an Intel P35 > chipset. At best, nothing will happen. But more likely, your box won't boot. Scott From owner-freebsd-current@FreeBSD.ORG Wed Sep 3 22:50:58 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5E51E106566B for ; Wed, 3 Sep 2008 22:50:58 +0000 (UTC) (envelope-from josh.carroll@gmail.com) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.28]) by mx1.freebsd.org (Postfix) with ESMTP id 177CD8FC12 for ; Wed, 3 Sep 2008 22:50:57 +0000 (UTC) (envelope-from josh.carroll@gmail.com) Received: by yx-out-2324.google.com with SMTP id 8so1688131yxb.13 for ; Wed, 03 Sep 2008 15:50:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:reply-to :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=nbrasuIIsihUL/rcW4DV3Kqcjfzo+6iGXI5J6IglbCc=; b=hMKH4z1d8TiPaFDQifDE1ea1i3KH9ImjokaVywPsJgCbZxKPVfWyS36OUXNJ933C/k z6YQ1Wq9ehY6MrGJOgrX34IWdL0dorMkOKRZzzgdmNMR17pAqSB8JNGmZyLuuwIkpzJC TU4EcSii3PCC9lYbM9yncPjm+FkcJIYB+dnfs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:reply-to:to:subject:cc:in-reply-to :mime-version:content-type:content-transfer-encoding :content-disposition:references; b=ZCmDLELtP7ErhQms4MgFxphm35AOLzs1JcNJqlZQeE9AJeD2uBG7u4Wg0RzFW0uHR4 1UH245Jn1XjfBKSazHq+hedpqEHzx8pJ2Fdn0IsUaqLjWu+Panu/Y7RrnvKTiHgZtPKf Bgb9fmXGh7jc2yyPJL9FR868B6k148PcMkcMk= Received: by 10.151.47.7 with SMTP id z7mr13249457ybj.111.1220482257375; Wed, 03 Sep 2008 15:50:57 -0700 (PDT) Received: by 10.150.140.14 with HTTP; Wed, 3 Sep 2008 15:50:57 -0700 (PDT) Message-ID: <8cb6106e0809031550o4960a4fanaf2ef5fe9130fc5b@mail.gmail.com> Date: Wed, 3 Sep 2008 18:50:57 -0400 From: "Josh Carroll" To: "Scott Long" In-Reply-To: <48BF1218.6000504@samsco.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20080903034943.GD11548@cicely7.cicely.de> <20080903204759.GA4898@walton.maths.tcd.ie> <8cb6106e0809031446i3e2a47dar385125ecfb0275dc@mail.gmail.com> <48BF1218.6000504@samsco.org> Cc: David Malone , Bernd Walter , ticso@cicely.de, freebsd-current@freebsd.org Subject: Re: MTRR fixup? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: josh.carroll@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2008 22:50:58 -0000 > Actually, it likely doesn't. Ok, something else then. My second guess (and what I thought prior to seeing this mail thread) was that it was perhaps address space reserved for the kernel? Off topic for this thread I suppose, I can ask elsewhere. > All systems reserve the top 256MB of the address space for PCI > memory and chipset registers. Modern systems have started > reserving even more than that for other new PCI functionality. > Note that this is address space, not RAM. The RAM is likely > being remapped to some place above the 4GB barrier. That makes sense. But is there a way to correlate where the physical memory is mapped with the memory ranges listed in memcontrol list output then? Or how would someone check if they are, in fact, affected by this sort of BIOS bug? >> I'll have to play with memcontrol to see if I can set those two large >> ranges as cacheable. So this is a BIOS bug? The board in question is >> an Asus P5K-E with BIOS revision 1102, which uses an Intel P35 >> chipset. > > At best, nothing will happen. But more likely, your box won't boot. So I'd be stepping on/trashing memory ranges used for PCI device mappings? I guess I probably just started a ticking time bomb then, huh? :) Thanks, Josh From owner-freebsd-current@FreeBSD.ORG Wed Sep 3 23:03:56 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 328D2106568D for ; Wed, 3 Sep 2008 23:03:56 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id D95538FC28 for ; Wed, 3 Sep 2008 23:03:55 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.local ([192.168.254.200]) (authenticated bits=0) by pooker.samsco.org (8.14.2/8.14.2) with ESMTP id m83N3gqU044247; Wed, 3 Sep 2008 17:03:43 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <48BF17CE.1070507@samsco.org> Date: Wed, 03 Sep 2008 17:03:42 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.13) Gecko/20080313 SeaMonkey/1.1.9 MIME-Version: 1.0 To: josh.carroll@gmail.com References: <20080903034943.GD11548@cicely7.cicely.de> <20080903204759.GA4898@walton.maths.tcd.ie> <8cb6106e0809031446i3e2a47dar385125ecfb0275dc@mail.gmail.com> <48BF1218.6000504@samsco.org> <8cb6106e0809031550o4960a4fanaf2ef5fe9130fc5b@mail.gmail.com> In-Reply-To: <8cb6106e0809031550o4960a4fanaf2ef5fe9130fc5b@mail.gmail.com> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.4 required=3.8 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: David Malone , Bernd Walter , ticso@cicely.de, freebsd-current@freebsd.org Subject: Re: MTRR fixup? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2008 23:03:56 -0000 Josh Carroll wrote: >> Actually, it likely doesn't. > > Ok, something else then. My second guess (and what I thought prior to > seeing this mail thread) was that it was perhaps address space > reserved for the kernel? Off topic for this thread I suppose, I can > ask elsewhere. > >> All systems reserve the top 256MB of the address space for PCI >> memory and chipset registers. Modern systems have started >> reserving even more than that for other new PCI functionality. >> Note that this is address space, not RAM. The RAM is likely >> being remapped to some place above the 4GB barrier. > > That makes sense. But is there a way to correlate where the physical > memory is mapped with the memory ranges listed in memcontrol list > output then? Or how would someone check if they are, in fact, affected > by this sort of BIOS bug? > The SMAP table, printed early during boot when bootverbose is set, will tell you what is mapped where. >>> I'll have to play with memcontrol to see if I can set those two large >>> ranges as cacheable. So this is a BIOS bug? The board in question is >>> an Asus P5K-E with BIOS revision 1102, which uses an Intel P35 >>> chipset. >> At best, nothing will happen. But more likely, your box won't boot. > > So I'd be stepping on/trashing memory ranges used for PCI device > mappings? I guess I probably just started a ticking time bomb then, > huh? :) No, you'd made PCI registers be cachable, making any reads from them unreliable and useless. Scott From owner-freebsd-current@FreeBSD.ORG Wed Sep 3 23:17:50 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5330E106568A for ; Wed, 3 Sep 2008 23:17:50 +0000 (UTC) (envelope-from josh.carroll@gmail.com) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.28]) by mx1.freebsd.org (Postfix) with ESMTP id 0B37A8FC16 for ; Wed, 3 Sep 2008 23:17:49 +0000 (UTC) (envelope-from josh.carroll@gmail.com) Received: by yx-out-2324.google.com with SMTP id 8so1693610yxb.13 for ; Wed, 03 Sep 2008 16:17:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:reply-to :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=i1KBLPU6eeMLwXxisRZ9zASPev8VEy0oYMw5t6GSeP0=; b=SiW/hJBxGweThAVA0mTjfDWpXDi9ZldMOLijJWn5N1euRvmANyTX3KMzgFr17bGSNd iAfYRvjG9KGKunpNkVi/zYNVjoBu0q35dmJyNFxtsspuZws8H9E6wBKkiTeG8jcNjQk4 9ejRjJaKFbKESRMy1AmVNgxG7PO7IqKLJEjkw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:reply-to:to:subject:cc:in-reply-to :mime-version:content-type:content-transfer-encoding :content-disposition:references; b=tejKh9J/WLHQRAjbNLx7InPx7j5XIeSriySBkJEgLNkqoKqfn7SdpX6ZfHqpV1mVIw 3gDPJfMPUoDE0uKRPX5Iu+DTby6tNWBbBDx7On4MCypj+PiJ066TnfeP8RzqfgCR8hft RL1BD+k/yx4z2/Nr98k7kCQVvQMuj/YJ0WrSA= Received: by 10.151.143.14 with SMTP id v14mr13292548ybn.64.1220483868902; Wed, 03 Sep 2008 16:17:48 -0700 (PDT) Received: by 10.150.140.14 with HTTP; Wed, 3 Sep 2008 16:17:48 -0700 (PDT) Message-ID: <8cb6106e0809031617p1da39a4fjd299dc60d2736253@mail.gmail.com> Date: Wed, 3 Sep 2008 19:17:48 -0400 From: "Josh Carroll" To: "Scott Long" In-Reply-To: <48BF17CE.1070507@samsco.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20080903034943.GD11548@cicely7.cicely.de> <20080903204759.GA4898@walton.maths.tcd.ie> <8cb6106e0809031446i3e2a47dar385125ecfb0275dc@mail.gmail.com> <48BF1218.6000504@samsco.org> <8cb6106e0809031550o4960a4fanaf2ef5fe9130fc5b@mail.gmail.com> <48BF17CE.1070507@samsco.org> Cc: David Malone , Bernd Walter , ticso@cicely.de, freebsd-current@freebsd.org Subject: Re: MTRR fixup? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: josh.carroll@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2008 23:17:50 -0000 > The SMAP table, printed early during boot when bootverbose is set, will > tell you what is mapped where. Thanks, I'll boot verbose and have a look. I was hoping there was a way to tell from an already booted system so folks could check without a reboot. Is there a way to check other than booting with verbose enabled and looking at the SMAP table? Josh From owner-freebsd-current@FreeBSD.ORG Wed Sep 3 23:46:50 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5625E1065A1E for ; Wed, 3 Sep 2008 23:46:50 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id B8CEB8FC1A for ; Wed, 3 Sep 2008 23:46:49 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from cicely5.cicely.de ([10.1.1.7]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id m83NklJe014143 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 4 Sep 2008 01:46:47 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by cicely5.cicely.de (8.14.2/8.14.2) with ESMTP id m83Nkh40003386 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Sep 2008 01:46:43 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id m83NkhuQ014715; Thu, 4 Sep 2008 01:46:43 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id m83Nkg7K014714; Thu, 4 Sep 2008 01:46:42 +0200 (CEST) (envelope-from ticso) Date: Thu, 4 Sep 2008 01:46:42 +0200 From: Bernd Walter To: David Malone Message-ID: <20080903234642.GA14659@cicely7.cicely.de> References: <20080903034943.GD11548@cicely7.cicely.de> <20080903204759.GA4898@walton.maths.tcd.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080903204759.GA4898@walton.maths.tcd.ie> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED=-1.8, AWL=0.069, BAYES_00=-2.599 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on spamd.cicely.de Cc: Bernd Walter , freebsd-current@freebsd.org, ticso@cicely.de Subject: Re: MTRR fixup? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2008 23:46:50 -0000 On Wed, Sep 03, 2008 at 09:47:59PM +0100, David Malone wrote: > On Wed, Sep 03, 2008 at 05:49:44AM +0200, Bernd Walter wrote: > > Some boards (including my Intel DG33BU) seem to have problems setting > > up the mtrr to cache all RAM. > > My system runs fast with 2G and ist about 6 times slower in buildworld > > with 6G RAM. > > I will try a BIOS update once Intels tells me why their update ISO > > just turn the system off instead of updating the BIOS - sigh. > > But it seems that Linux is doing some kind of fixup for MTRR: > > http://lkml.org/lkml/2008/1/18/170 > > Can we do something similar? > > You may be able to fix this by just using the memcontrol command - > it already lets you program the MTRRs. Oh damn - a new fancy tool to play with ;-) Interesting - the values look good: [...] 0x0/0x80000000 ticso write-back active 0x80000000/0x40000000 ticso write-back active 0xc0000000/0x10000000 ticso write-back active 0xcf800000/0x800000 BIOS uncacheable set-by-firmware active 0xcf400000/0x400000 BIOS uncacheable set-by-firmware active 0x100000000/0x80000000 ticso write-back active 0x180000000/0x20000000 ticso write-back active 0x0/0x1000000000 - uncacheable I've already overwritten it for tests, but it was the same as left by the BIOS. If I set everything uncacheable the system slows down by a factor of two - measured from top CPU usage seen in top. If I set it back to write-back it returns to previous usage, but it is still much slower than with 2G installed. Maybe MTRR is a red hering... But why are the Linux guys claim to fix this with MTRR settings? -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-current@FreeBSD.ORG Thu Sep 4 00:22:56 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B9A6F1065A10 for ; Thu, 4 Sep 2008 00:22:56 +0000 (UTC) (envelope-from alex-goncharov@comcast.net) Received: from QMTA03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [76.96.30.32]) by mx1.freebsd.org (Postfix) with ESMTP id 9F7D08FC1A for ; Thu, 4 Sep 2008 00:22:56 +0000 (UTC) (envelope-from alex-goncharov@comcast.net) Received: from OMTA07.emeryville.ca.mail.comcast.net ([76.96.30.59]) by QMTA03.emeryville.ca.mail.comcast.net with comcast id AKNT1a00c1GXsucA3QNwRY; Thu, 04 Sep 2008 00:22:56 +0000 Received: from daland.home ([24.61.21.4]) by OMTA07.emeryville.ca.mail.comcast.net with comcast id AQNu1a00505H7zL8TQNvpx; Thu, 04 Sep 2008 00:22:55 +0000 X-Authority-Analysis: v=1.0 c=1 a=VpG5av1V1N0A:10 a=y3Be58pVqgkA:10 a=rITDv7nW5hcA:10 a=nPdZA60-BFWM6NXlObwA:9 a=3R1VAQM75_Q1mhpMkpU2zZcHZj0A:4 a=si9q_4b84H0A:10 a=mhQ4J5QMNLoA:10 Received: from algo by daland.home with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kb2cf-0000oX-Mu for freebsd-current@FreeBSD.ORG; Wed, 03 Sep 2008 20:22:53 -0400 From: Alex Goncharov To: freebsd-current@FreeBSD.ORG In-reply-to: <200809031350.m83DoVw6021573@lurza.secnetix.de> (message from Oliver Fromme on Wed, 3 Sep 2008 15:50:31 +0200 (CEST)) References: <200809031350.m83DoVw6021573@lurza.secnetix.de> Message-Id: Sender: Alex Goncharov Date: Wed, 03 Sep 2008 20:22:53 -0400 Cc: Subject: Re: named mystery -- error: dumping master file: ??master/tmp-wTjhUzoix6 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Goncharov List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2008 00:22:56 -0000 ,--- Oliver Fromme (Wed, 3 Sep 2008 15:50:31 +0200 (CEST)) ----* | Of course you can have both dynamic and static entries within the | same zone. But the question is: Is that zone only visible to your | internal network, or is it public? Internal. | If it's only internal, then the BIND jail serving that zone should | be bound to an internal IP address, so an attacker from outside | cannot break into the BIND jail. Of course: it is. Plus the firewall is there, the way is should. | It is usually not a good idea to put dynamic entries of internal | hosts into a zone that is served to the public internet. I don't serve any zones to the public internet. If I were, there would be no dynamic entries in it. On the other hand, it's hard for me to imagine an internal zone, at home or at work, that would not mix static and dynamic addresses these days. | So it is not only an issue of static vs. dynamic, but also | internal vs. public. Right. P.S. What a delight not to see DNS warnings in my logs -- thanks to all who replied to my request! -- Alex -- alex-goncharov@comcast.net -- From owner-freebsd-current@FreeBSD.ORG Thu Sep 4 01:55:16 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C8EBE106579B for ; Thu, 4 Sep 2008 01:55:16 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 709E98FC12 for ; Thu, 4 Sep 2008 01:55:16 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from cicely5.cicely.de ([10.1.1.7]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id m841tDg3017939 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 4 Sep 2008 03:55:14 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by cicely5.cicely.de (8.14.2/8.14.2) with ESMTP id m841t8OR002894 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Sep 2008 03:55:09 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id m841t86U015354; Thu, 4 Sep 2008 03:55:08 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id m841t8xi015353; Thu, 4 Sep 2008 03:55:08 +0200 (CEST) (envelope-from ticso) Date: Thu, 4 Sep 2008 03:55:08 +0200 From: Bernd Walter To: David Malone Message-ID: <20080904015507.GA15328@cicely7.cicely.de> References: <20080903034943.GD11548@cicely7.cicely.de> <20080903204759.GA4898@walton.maths.tcd.ie> <20080903234642.GA14659@cicely7.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080903234642.GA14659@cicely7.cicely.de> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED=-1.8, AWL=0.069, BAYES_00=-2.599 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on spamd.cicely.de Cc: Bernd Walter , freebsd-current@freebsd.org, ticso@cicely.de Subject: Re: MTRR fixup? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2008 01:55:16 -0000 On Thu, Sep 04, 2008 at 01:46:42AM +0200, Bernd Walter wrote: > On Wed, Sep 03, 2008 at 09:47:59PM +0100, David Malone wrote: > > On Wed, Sep 03, 2008 at 05:49:44AM +0200, Bernd Walter wrote: > > > Some boards (including my Intel DG33BU) seem to have problems setting > > > up the mtrr to cache all RAM. > > > My system runs fast with 2G and ist about 6 times slower in buildworld > > > with 6G RAM. > > > I will try a BIOS update once Intels tells me why their update ISO > > > just turn the system off instead of updating the BIOS - sigh. > > > But it seems that Linux is doing some kind of fixup for MTRR: > > > http://lkml.org/lkml/2008/1/18/170 > > > Can we do something similar? > > > > You may be able to fix this by just using the memcontrol command - > > it already lets you program the MTRRs. > > Oh damn - a new fancy tool to play with ;-) > > Interesting - the values look good: > [...] > 0x0/0x80000000 ticso write-back active > 0x80000000/0x40000000 ticso write-back active > 0xc0000000/0x10000000 ticso write-back active > 0xcf800000/0x800000 BIOS uncacheable set-by-firmware active > 0xcf400000/0x400000 BIOS uncacheable set-by-firmware active > 0x100000000/0x80000000 ticso write-back active > 0x180000000/0x20000000 ticso write-back active > 0x0/0x1000000000 - uncacheable Ok - there it is - something is missing: ram0 I/O memory addresses: 0x0-0x9c3ff 0x100000-0xcf212fff 0xcf215000-0xcf2fafff 0xcf3e5000-0xcf3e8fff 0xcf3f2000-0xcf3f2fff 0xcf3ff000-0xcf3fffff 0x100000000-0x1abffffff ram goes up to 0x1abffffff mtrr just goes up to 0x1a0000000 - 1, so the last 192MB are uncached. But memcontrol complains when trying to add the range: [55]cicely14# memcontrol set -b 0x1a0000000 -l 0xc000000 -o ticso write-back memcontrol: can't set range: Invalid argument > > I've already overwritten it for tests, but it was the same as left by > the BIOS. > If I set everything uncacheable the system slows down by a factor of > two - measured from top CPU usage seen in top. > If I set it back to write-back it returns to previous usage, but it is > still much slower than with 2G installed. > Maybe MTRR is a red hering... > But why are the Linux guys claim to fix this with MTRR settings? > > -- > B.Walter http://www.bwct.de > Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-current@FreeBSD.ORG Thu Sep 4 02:00:41 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7772F1065758 for ; Thu, 4 Sep 2008 02:00:41 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id 49CAE8FC1B for ; Thu, 4 Sep 2008 02:00:41 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from [192.168.2.97] (c-71-56-39-94.hsd1.ga.comcast.net [71.56.39.94]) (authenticated bits=0) by gizmo.2hip.net (8.13.8/8.13.8) with ESMTP id m8420bbA037645 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Sep 2008 22:00:38 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Steve Kargl In-Reply-To: <20080903195845.GA1370@troutmask.apl.washington.edu> References: <20080903011612.GA1242@troutmask.apl.washington.edu> <1220416793.1848.1.camel@wombat.2hip.net> <20080903051228.GA2475@troutmask.apl.washington.edu> <1220471512.11763.9.camel@squirrel.corp.cox.com> <20080903195845.GA1370@troutmask.apl.washington.edu> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-flyrfkESakkE2tiRx7wv" Organization: FreeBSD Date: Wed, 03 Sep 2008 22:00:27 -0400 Message-Id: <1220493627.2467.6.camel@wombat.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 FreeBSD GNOME Team Port X-Spam-Status: No, score=-0.9 required=5.0 tests=AWL,BAYES_00, RCVD_IN_SORBS_DUL autolearn=no version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on gizmo.2hip.net Cc: freebsd-current@FreeBSD.org Subject: Re: drm causes kernel panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2008 02:00:41 -0000 --=-flyrfkESakkE2tiRx7wv Content-Type: multipart/mixed; boundary="=-82ZGda6AVxPnsww7BYI+" --=-82ZGda6AVxPnsww7BYI+ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2008-09-03 at 12:58 -0700, Steve Kargl wrote: > On Wed, Sep 03, 2008 at 03:51:52PM -0400, Robert Noland wrote: > > On Tue, 2008-09-02 at 22:12 -0700, Steve Kargl wrote: > >>=20 > >> From dmesg: > >>=20 > >> vgapci0: port 0xb000-0xb0ff mem 0xfd000000-0xfdffffff,0 > >> xfeaff000-0xfeafffff irq 18 at device 6.0 on pci3 > >> drm0: on vgapci0 > >> info: [drm] Initialized mach64 2.0.0 20060718 > >=20 > > Ok, I've found the problem... It is easy enough to fix your specific > > situation, but doing so will cause problems for other drivers... Which > > is the reason that I made that change to begin with. The big problem i= s > > that drm_pci_alloc gets called from a variety of places, some of which > > already hold locks while others don't. We aren't allowed to hold locks > > over some of the bus_dma functions, so I have to go through all of thes= e > > paths and figure out if it is generally safe to always drop the locks, > > or if I need to restructure the code somehow... If you want a patch to > > just get you going temporarily, just let me know... > >=20 >=20 > I can disable Xorg's dri module. When you have a patch you're happy > with, feel free to ping me for testing. Ok, please try the attached patch. I talked it over with another drm developer and it should be safe to drop all the locks while calling drm_pci_alloc(). I think I have fixed this for all drivers / paths that call it. It will log an error now if it is called with either of the two locks that I found being held. I have tested this on my intel 965gm so far and all is well. I also had to touch mach64 and radeon, so I need someone to validate those. (This is a different path from the panic you received previously) robert. --=-82ZGda6AVxPnsww7BYI+ Content-Disposition: attachment; filename=drm_pci_alloc-lock_fix.patch Content-Transfer-Encoding: base64 Content-Type: text/x-patch; name=drm_pci_alloc-lock_fix.patch; charset=utf-8 SW5kZXg6IGRldi9kcm0vZHJtX2J1ZnMuYw0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KLS0tIGRldi9kcm0vZHJtX2J1 ZnMuYwkocmV2aXNpb24gMTgyNDY2KQ0KKysrIGRldi9kcm0vZHJtX2J1ZnMuYwkod29ya2luZyBj b3B5KQ0KQEAgLTU5OCw4ICs1OTgsMTAgQEANCiAJcGFnZV9jb3VudCA9IDA7DQogDQogCXdoaWxl ICggZW50cnktPmJ1Zl9jb3VudCA8IGNvdW50ICkgew0KKwkJRFJNX1NQSU5VTkxPQ0soJmRldi0+ ZG1hX2xvY2spOw0KIAkJZHJtX2RtYV9oYW5kbGVfdCAqZG1haCA9IGRybV9wY2lfYWxsb2MoZGV2 LCBzaXplLCBhbGlnbm1lbnQsDQogCQkgICAgMHhmZmZmZmZmZnVsKTsNCisJCURSTV9TUElOTE9D SygmZGV2LT5kbWFfbG9jayk7DQogCQlpZiAoZG1haCA9PSBOVUxMKSB7DQogCQkJLyogU2V0IGNv dW50IGNvcnJlY3RseSBzbyB3ZSBmcmVlIHRoZSBwcm9wZXIgYW1vdW50LiAqLw0KIAkJCWVudHJ5 LT5idWZfY291bnQgPSBjb3VudDsNCkluZGV4OiBkZXYvZHJtL21hY2g2NF9kbWEuYw0KPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PQ0KLS0tIGRldi9kcm0vbWFjaDY0X2RtYS5jCShyZXZpc2lvbiAxODI0NjYpDQorKysgZGV2 L2RybS9tYWNoNjRfZG1hLmMJKHdvcmtpbmcgY29weSkNCkBAIC04MzcsOCArODM3LDE0IEBADQog DQogCS8qIEZJWE1FOiBnZXQgYSBkbWEgYnVmZmVyIGZyb20gdGhlIGZyZWVsaXN0IGhlcmUgKi8N CiAJRFJNX0RFQlVHKCJBbGxvY2F0aW5nIGRhdGEgbWVtb3J5IC4uLlxuIik7DQorI2lmZGVmIF9f RnJlZUJTRF9fDQorCURSTV9VTkxPQ0soKTsNCisjZW5kaWYNCiAJY3B1X2FkZHJfZG1haCA9DQog CSAgICBkcm1fcGNpX2FsbG9jKGRldiwgMHgxMDAwLCAweDEwMDAsIDB4ZmZmZmZmZmZ1bCk7DQor I2lmZGVmIF9fRnJlZUJTRF9fDQorCURSTV9MT0NLKCk7DQorI2VuZGlmDQogCWlmICghY3B1X2Fk ZHJfZG1haCkgew0KIAkJRFJNX0lORk8oImRhdGEtbWVtb3J5IGFsbG9jYXRpb24gZmFpbGVkIVxu Iik7DQogCQlyZXR1cm4gLUVOT01FTTsNCkluZGV4OiBkZXYvZHJtL2k5MTVfZG1hLmMNCj09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT0NCi0tLSBkZXYvZHJtL2k5MTVfZG1hLmMJKHJldmlzaW9uIDE4MjQ2NikNCisrKyBkZXYv ZHJtL2k5MTVfZG1hLmMJKHdvcmtpbmcgY29weSkNCkBAIC0yNTAsMTYgKzI1MCwyMiBAQA0KIA0K IAkvKiBQcm9ncmFtIEhhcmR3YXJlIFN0YXR1cyBQYWdlICovDQogCWlmICghSTkxNV9ORUVEX0dG WF9IV1MoZGV2KSkgew0KLQkJZGV2X3ByaXYtPnN0YXR1c19wYWdlX2RtYWggPQ0KLQkJCWRybV9w Y2lfYWxsb2MoZGV2LCBQQUdFX1NJWkUsIFBBR0VfU0laRSwgMHhmZmZmZmZmZik7DQotDQotCQlp ZiAoIWRldl9wcml2LT5zdGF0dXNfcGFnZV9kbWFoKSB7DQorCQlkcm1fZG1hX2hhbmRsZV90ICpk bWFoOw0KKyNpZmRlZiBfX0ZyZWVCU0RfXw0KKwkJRFJNX1VOTE9DSygpOw0KKyNlbmRpZg0KKwkJ ZG1haCA9IGRybV9wY2lfYWxsb2MoZGV2LCBQQUdFX1NJWkUsIFBBR0VfU0laRSwgMHhmZmZmZmZm Zik7DQorI2lmZGVmIF9fRnJlZUJTRF9fDQorCQlEUk1fTE9DSygpOw0KKyNlbmRpZg0KKwkJaWYg KCFkbWFoKSB7DQogCQkJaTkxNV9kbWFfY2xlYW51cChkZXYpOw0KIAkJCURSTV9FUlJPUigiQ2Fu IG5vdCBhbGxvY2F0ZSBoYXJkd2FyZSBzdGF0dXMgcGFnZVxuIik7DQogCQkJcmV0dXJuIC1FTk9N RU07DQogCQl9DQotCQlkZXZfcHJpdi0+aHdfc3RhdHVzX3BhZ2UgPSBkZXZfcHJpdi0+c3RhdHVz X3BhZ2VfZG1haC0+dmFkZHI7DQotCQlkZXZfcHJpdi0+ZG1hX3N0YXR1c19wYWdlID0gZGV2X3By aXYtPnN0YXR1c19wYWdlX2RtYWgtPmJ1c2FkZHI7DQorCQlkZXZfcHJpdi0+c3RhdHVzX3BhZ2Vf ZG1haCA9IGRtYWg7DQorCQlkZXZfcHJpdi0+aHdfc3RhdHVzX3BhZ2UgPSBkbWFoLT52YWRkcjsN CisJCWRldl9wcml2LT5kbWFfc3RhdHVzX3BhZ2UgPSBkbWFoLT5idXNhZGRyOw0KIA0KIAkJbWVt c2V0KGRldl9wcml2LT5od19zdGF0dXNfcGFnZSwgMCwgUEFHRV9TSVpFKTsNCiANCkluZGV4OiBk ZXYvZHJtL2RybV9wY2kuYw0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KLS0tIGRldi9kcm0vZHJtX3BjaS5jCShyZXZp c2lvbiAxODI0NjYpDQorKysgZGV2L2RybS9kcm1fcGNpLmMJKHdvcmtpbmcgY29weSkNCkBAIC03 NCw3ICs3NCwxNCBAQA0KIAkJcmV0dXJuIE5VTEw7DQogDQogI2lmZGVmIF9fRnJlZUJTRF9fDQot CURSTV9VTkxPQ0soKTsNCisJLyogTWFrZSBzdXJlIHdlIGFyZW4ndCBob2xkaW5nIGxvY2tzIGhl cmUgKi8NCisJbXR4X2Fzc2VydCgmZGV2LT5kZXZfbG9jaywgTUFfTk9UT1dORUQpOw0KKwlpZiAo bXR4X293bmVkKCZkZXYtPmRldl9sb2NrKSkNCisJICAgIERSTV9FUlJPUigiY2FsbGVkIHdoaWxl IGhvbGRpbmcgZGV2X2xvY2tcbiIpOw0KKwltdHhfYXNzZXJ0KCZkZXYtPmRtYV9sb2NrLCBNQV9O T1RPV05FRCk7DQorCWlmIChtdHhfb3duZWQoJmRldi0+ZG1hX2xvY2spKQ0KKwkgICAgRFJNX0VS Uk9SKCJjYWxsZWQgd2hpbGUgaG9sZGluZyBkbWFfbG9ja1xuIik7DQorDQogCXJldCA9IGJ1c19k bWFfdGFnX2NyZWF0ZShOVUxMLCBhbGlnbiwgMCwgLyogdGFnLCBhbGlnbiwgYm91bmRhcnkgKi8N CiAJICAgIG1heGFkZHIsIEJVU19TUEFDRV9NQVhBRERSLCAvKiBsb3dhZGRyLCBoaWdoYWRkciAq Lw0KIAkgICAgTlVMTCwgTlVMTCwgLyogZmlsdGZ1bmMsIGZpbHRmdW5jYXJncyAqLw0KQEAgLTgz LDcgKzkwLDYgQEANCiAJICAgICZkbWFoLT50YWcpOw0KIAlpZiAocmV0ICE9IDApIHsNCiAJCWZy ZWUoZG1haCwgTV9EUk0pOw0KLQkJRFJNX0xPQ0soKTsNCiAJCXJldHVybiBOVUxMOw0KIAl9DQog DQpAQCAtOTIsMTAgKzk4LDkgQEANCiAJaWYgKHJldCAhPSAwKSB7DQogCQlidXNfZG1hX3RhZ19k ZXN0cm95KGRtYWgtPnRhZyk7DQogCQlmcmVlKGRtYWgsIE1fRFJNKTsNCi0JCURSTV9MT0NLKCk7 DQogCQlyZXR1cm4gTlVMTDsNCiAJfQ0KLQlEUk1fTE9DSygpOw0KKw0KIAlyZXQgPSBidXNfZG1h bWFwX2xvYWQoZG1haC0+dGFnLCBkbWFoLT5tYXAsIGRtYWgtPnZhZGRyLCBzaXplLA0KIAkgICAg ZHJtX3BjaV9idXNkbWFfY2FsbGJhY2ssIGRtYWgsIDApOw0KIAlpZiAocmV0ICE9IDApIHsNCklu ZGV4OiBkZXYvZHJtL2F0aV9wY2lnYXJ0LmMNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCi0tLSBkZXYvZHJtL2F0aV9w Y2lnYXJ0LmMJKHJldmlzaW9uIDE4MjQ2NikNCisrKyBkZXYvZHJtL2F0aV9wY2lnYXJ0LmMJKHdv cmtpbmcgY29weSkNCkBAIC00NSwxMiArNDUsMTcgQEANCiBzdGF0aWMgaW50IGRybV9hdGlfYWxs b2NfcGNpZ2FydF90YWJsZShzdHJ1Y3QgZHJtX2RldmljZSAqZGV2LA0KIAkJCQkgICAgICAgc3Ry dWN0IGRybV9hdGlfcGNpZ2FydF9pbmZvICpnYXJ0X2luZm8pDQogew0KLQlkZXYtPnNnLT5kbWFo ID0gZHJtX3BjaV9hbGxvYyhkZXYsIGdhcnRfaW5mby0+dGFibGVfc2l6ZSwNCi0JCQkJCQlQQUdF X1NJWkUsDQotCQkJCQkJZ2FydF9pbmZvLT50YWJsZV9tYXNrKTsNCi0JaWYgKGRldi0+c2ctPmRt YWggPT0gTlVMTCkNCisJZHJtX2RtYV9oYW5kbGVfdCAqZG1haDsNCisNCisJRFJNX1VOTE9DSygp Ow0KKwlkbWFoID0gZHJtX3BjaV9hbGxvYyhkZXYsIGdhcnRfaW5mby0+dGFibGVfc2l6ZSwgUEFH RV9TSVpFLA0KKwkgICAgZ2FydF9pbmZvLT50YWJsZV9tYXNrKTsNCisJRFJNX0xPQ0soKTsNCisJ aWYgKGRtYWggPT0gTlVMTCkNCiAJCXJldHVybiBFTk9NRU07DQogDQorCWRldi0+c2ctPmRtYWgg PSBkbWFoOw0KKw0KIAlyZXR1cm4gMDsNCiB9DQogDQo= --=-82ZGda6AVxPnsww7BYI+-- --=-flyrfkESakkE2tiRx7wv Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEABECAAYFAki/QTsACgkQM4TrQ4qfRONxfwCeKHi5wj3c141tdhEn4Lo4mDsc aoAAnjM62HTABU5YAe2p3pTwr+nXzED1 =MTVm -----END PGP SIGNATURE----- --=-flyrfkESakkE2tiRx7wv-- From owner-freebsd-current@FreeBSD.ORG Thu Sep 4 02:02:22 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 561FF106569E for ; Thu, 4 Sep 2008 02:02:22 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id F0E988FC08 for ; Thu, 4 Sep 2008 02:02:21 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from cicely5.cicely.de ([10.1.1.7]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id m8422KDL018157 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 4 Sep 2008 04:02:20 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by cicely5.cicely.de (8.14.2/8.14.2) with ESMTP id m8422Fdw003106 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Sep 2008 04:02:16 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id m8422F3Q015384; Thu, 4 Sep 2008 04:02:15 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id m8422Fw4015383; Thu, 4 Sep 2008 04:02:15 +0200 (CEST) (envelope-from ticso) Date: Thu, 4 Sep 2008 04:02:15 +0200 From: Bernd Walter To: David Malone Message-ID: <20080904020215.GB15328@cicely7.cicely.de> References: <20080903034943.GD11548@cicely7.cicely.de> <20080903204759.GA4898@walton.maths.tcd.ie> <20080903234642.GA14659@cicely7.cicely.de> <20080904015507.GA15328@cicely7.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080904015507.GA15328@cicely7.cicely.de> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED=-1.8, AWL=0.069, BAYES_00=-2.599 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on spamd.cicely.de Cc: Bernd Walter , freebsd-current@freebsd.org, ticso@cicely.de Subject: Re: MTRR fixup? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2008 02:02:22 -0000 On Thu, Sep 04, 2008 at 03:55:07AM +0200, Bernd Walter wrote: > On Thu, Sep 04, 2008 at 01:46:42AM +0200, Bernd Walter wrote: > > On Wed, Sep 03, 2008 at 09:47:59PM +0100, David Malone wrote: > > > On Wed, Sep 03, 2008 at 05:49:44AM +0200, Bernd Walter wrote: > > > > Some boards (including my Intel DG33BU) seem to have problems setting > > > > up the mtrr to cache all RAM. > > > > My system runs fast with 2G and ist about 6 times slower in buildworld > > > > with 6G RAM. > > > > I will try a BIOS update once Intels tells me why their update ISO > > > > just turn the system off instead of updating the BIOS - sigh. > > > > But it seems that Linux is doing some kind of fixup for MTRR: > > > > http://lkml.org/lkml/2008/1/18/170 > > > > Can we do something similar? > > > > > > You may be able to fix this by just using the memcontrol command - > > > it already lets you program the MTRRs. > > > > Oh damn - a new fancy tool to play with ;-) > > > > Interesting - the values look good: > > [...] > > 0x0/0x80000000 ticso write-back active > > 0x80000000/0x40000000 ticso write-back active > > 0xc0000000/0x10000000 ticso write-back active > > 0xcf800000/0x800000 BIOS uncacheable set-by-firmware active > > 0xcf400000/0x400000 BIOS uncacheable set-by-firmware active > > 0x100000000/0x80000000 ticso write-back active > > 0x180000000/0x20000000 ticso write-back active > > 0x0/0x1000000000 - uncacheable > > Ok - there it is - something is missing: > ram0 > I/O memory addresses: > 0x0-0x9c3ff > 0x100000-0xcf212fff > 0xcf215000-0xcf2fafff > 0xcf3e5000-0xcf3e8fff > 0xcf3f2000-0xcf3f2fff > 0xcf3ff000-0xcf3fffff > 0x100000000-0x1abffffff > > ram goes up to 0x1abffffff mtrr just goes up to 0x1a0000000 - 1, so the > last 192MB are uncached. > But memcontrol complains when trying to add the range: > [55]cicely14# memcontrol set -b 0x1a0000000 -l 0xc000000 -o ticso write-back > memcontrol: can't set range: Invalid argument Ok - I more or less got it. I have to set 2^n ranges. The first one goes: [56]cicely14# memcontrol set -b 0x1a0000000 -l 0x8000000 -o ticso write-back The second not: [57]cicely14# memcontrol set -b 0x1a8000000 -l 0x4000000 -o ticso write-back memcontrol: can't set range: No space left on device Exit 1 But this is exactly my problem, because if I only set the second one the board instantly speeds up. Something important of the system must be in the last 64MB. Nevertheless I can't use memcontrol to setup everything as cacheable. I could set hw.phymem to get the kernel below the last 64MB or maybe even the last 192MB. If someone has an idea on how to set both ranges... But anyway: Thank you all - this was very usefull, since I can now get almost all memory without massive performance penalty. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-current@FreeBSD.ORG Thu Sep 4 03:43:09 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 770D1106567D for ; Thu, 4 Sep 2008 03:43:09 +0000 (UTC) (envelope-from josh.carroll@gmail.com) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.28]) by mx1.freebsd.org (Postfix) with ESMTP id 2F1D78FC08 for ; Thu, 4 Sep 2008 03:43:08 +0000 (UTC) (envelope-from josh.carroll@gmail.com) Received: by yx-out-2324.google.com with SMTP id 8so1738586yxb.13 for ; Wed, 03 Sep 2008 20:43:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:reply-to :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=3ul4HS2ccayxlHURXaCiy1eh127E2B0I3ehGUx6F49I=; b=BYT4R66mBia4S0dagzKKAkI1bW+U5x5mHnCdm53Xtl6Hp+XefoAf4ApTM0Bfb27Y0R BrSoXYGjJylAgSwKDGBr43VVAe7c4J4Ndp4tkdn2CSi/iByMB+YXwfh6O2ArebY9ZsnK wYp5DzrANowjGbheFtDT2AQ/SN+WLLHQIo9AA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:reply-to:to:subject:cc:in-reply-to :mime-version:content-type:content-transfer-encoding :content-disposition:references; b=lW5IcDzt0Opn4u5h8Jk5UOawOsgpxpBbBFvD5ly2rPrRr4+OL7tl8FZnt8t6CLvqff y2b3UpygNVfywN2JZNRQ7DWN1nF6p8aOp9/EVx+79v53QiBcOQolraMU9JO89gZhtUev vXy3cndywF5aZt3qJlLEMxhGUMO3kfv6EL3aU= Received: by 10.151.158.2 with SMTP id k2mr13647048ybo.118.1220499788275; Wed, 03 Sep 2008 20:43:08 -0700 (PDT) Received: by 10.150.140.14 with HTTP; Wed, 3 Sep 2008 20:43:08 -0700 (PDT) Message-ID: <8cb6106e0809032043x7eeb7aaeoc29473c028a8220f@mail.gmail.com> Date: Wed, 3 Sep 2008 23:43:08 -0400 From: "Josh Carroll" To: freebsd-current@freebsd.org In-Reply-To: <48BF17CE.1070507@samsco.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20080903034943.GD11548@cicely7.cicely.de> <20080903204759.GA4898@walton.maths.tcd.ie> <8cb6106e0809031446i3e2a47dar385125ecfb0275dc@mail.gmail.com> <48BF1218.6000504@samsco.org> <8cb6106e0809031550o4960a4fanaf2ef5fe9130fc5b@mail.gmail.com> <48BF17CE.1070507@samsco.org> Cc: David Malone , Bernd Walter , ticso@cicely.de Subject: Re: MTRR fixup? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: josh.carroll@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2008 03:43:09 -0000 > The SMAP table, printed early during boot when bootverbose is set, will > tell you what is mapped where. Ok, here is my SMAP (I had to transcribe it by hand from a picture, it doesn't appear in dmesg or get written to /var/run/dmesg.boot): SMAP type=01 base=0000000000000000 len=000000000009ec00 SMAP type=02 base=000000000009ec00 len=0000000000001400 SMAP type=02 base=00000000000e4000 len=000000000001c000 SMAP type=01 base=0000000000100000 len=00000000cfe80000 SMAP type=03 base=00000000cff80000 len=000000000000e000 SMAP type=04 base=00000000cff8e000 len=0000000000052000 SMAP type=02 base=00000000cffe0000 len=0000000000020000 SMAP type=02 base=00000000fee00000 len=0000000000001000 SMAP type=02 base=00000000ffe00000 len=0000000000200000 SMAP type=01 base=0000000100000000 len=0000000030000000 Comparing that to the memcontrol list output for uncacheable address ranges (the large high-order ones): 0xd0000000/0x10000000 BIOS uncacheable set-by-firmware active 0xe0000000/0x20000000 BIOS uncacheable set-by-firmware active It looks like there is only overlap for type 02 (which is "reserved" from sys/amd64/include/pc/bios.h) and of just 4K and 2M respectively: SMAP type=02 base=00000000fee00000 len=0000000000001000 (4 KB) resides inside uncacheable range [e0000000,100000000] SMAP type=02 base=00000000ffe00000 len=0000000000200000 (2048 KB) resides inside uncacheable range [e0000000,100000000] So I guess for this particular board/BIOS it is not an issue. >>> At best, nothing will happen. But more likely, your box won't boot. Yes, it caused a deadlock after some increased memory usage. Lesson learned. Josh From owner-freebsd-current@FreeBSD.ORG Thu Sep 4 05:06:49 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EFFBF106564A; Thu, 4 Sep 2008 05:06:49 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from kientzle.com (kientzle.com [66.166.149.50]) by mx1.freebsd.org (Postfix) with ESMTP id C8D398FC24; Thu, 4 Sep 2008 05:06:49 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from [10.0.0.128] (p54.kientzle.com [66.166.149.54]) by kientzle.com (8.12.9/8.12.9) with ESMTP id m8456etv085513; Wed, 3 Sep 2008 22:06:46 -0700 (PDT) (envelope-from kientzle@freebsd.org) Message-ID: <48BF6D2C.4030001@freebsd.org> Date: Wed, 03 Sep 2008 22:07:56 -0700 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20060422 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Giorgos Keramidas References: <87hc8x74nd.fsf@kobe.laptop> <48BEB5E1.8080906@freebsd.org> <87ej41rkpk.fsf@kobe.laptop> In-Reply-To: <87ej41rkpk.fsf@kobe.laptop> Content-Type: multipart/mixed; boundary="------------010309030202020008070802" Cc: freebsd-current@freebsd.org Subject: Re: cpio reporting too many 'blocks' X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2008 05:06:50 -0000 This is a multi-part message in MIME format. --------------010309030202020008070802 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Giorgos Keramidas wrote: > > ACK. If you want me to run any tests or test patches, please feel free > to send them this way :-) I think I found it. Try this and let me know. Tim --------------010309030202020008070802 Content-Type: text/x-patch; name="cpio_blockcount.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="cpio_blockcount.patch" Index: cpio.c =================================================================== --- cpio.c (revision 182102) +++ cpio.c (working copy) @@ -863,7 +863,6 @@ r = archive_write_close(cpio->archive); if (r != ARCHIVE_OK) cpio_errc(1, 0, archive_error_string(cpio->archive)); - archive_write_finish(cpio->archive); if (!cpio->quiet) { blocks = (archive_position_uncompressed(cpio->archive) + 511) @@ -872,6 +871,7 @@ blocks == 1 ? "block" : "blocks"); } + archive_write_finish(cpio->archive); } /* --------------010309030202020008070802-- From owner-freebsd-current@FreeBSD.ORG Thu Sep 4 05:26:42 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 490061065672 for ; Thu, 4 Sep 2008 05:26:42 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id D29888FC19 for ; Thu, 4 Sep 2008 05:26:41 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.local ([192.168.254.200]) (authenticated bits=0) by pooker.samsco.org (8.14.2/8.14.2) with ESMTP id m845QUge046691; Wed, 3 Sep 2008 23:26:31 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <48BF7186.6040603@samsco.org> Date: Wed, 03 Sep 2008 23:26:30 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.13) Gecko/20080313 SeaMonkey/1.1.9 MIME-Version: 1.0 To: josh.carroll@gmail.com References: <20080903034943.GD11548@cicely7.cicely.de> <20080903204759.GA4898@walton.maths.tcd.ie> <8cb6106e0809031446i3e2a47dar385125ecfb0275dc@mail.gmail.com> <48BF1218.6000504@samsco.org> <8cb6106e0809031550o4960a4fanaf2ef5fe9130fc5b@mail.gmail.com> <48BF17CE.1070507@samsco.org> <8cb6106e0809032043x7eeb7aaeoc29473c028a8220f@mail.gmail.com> In-Reply-To: <8cb6106e0809032043x7eeb7aaeoc29473c028a8220f@mail.gmail.com> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.4 required=3.8 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: David Malone , Bernd Walter , freebsd-current@freebsd.org, ticso@cicely.de Subject: Re: MTRR fixup? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2008 05:26:42 -0000 Josh Carroll wrote: >> The SMAP table, printed early during boot when bootverbose is set, will >> tell you what is mapped where. > > Ok, here is my SMAP (I had to transcribe it by hand from a picture, it > doesn't appear in dmesg or get written to /var/run/dmesg.boot): > > SMAP type=01 base=0000000000000000 len=000000000009ec00 > SMAP type=02 base=000000000009ec00 len=0000000000001400 > SMAP type=02 base=00000000000e4000 len=000000000001c000 > SMAP type=01 base=0000000000100000 len=00000000cfe80000 So RAM goes from 0x100000 to 0xcff8000, and is then followed by: > SMAP type=03 base=00000000cff80000 len=000000000000e000 > SMAP type=04 base=00000000cff8e000 len=0000000000052000 > SMAP type=02 base=00000000cffe0000 len=0000000000020000 Then from 0xd0000000 to 0xfee00000, nothing is listed in the table. The absence of type01 means that there is definitely no RAM here, therefore nothing to legitimately mark cachable. > SMAP type=02 base=00000000fee00000 len=0000000000001000 > SMAP type=02 base=00000000ffe00000 len=0000000000200000 And here we've pretty much reached the end of the first 4GB of address space. From 0xd0000000 to 0xffffffff, there is no RAM. This exactly corresponds with the range that memcontrol told you was uncachable. So what happened to this missing 768MB of RAM? > SMAP type=01 base=0000000100000000 len=0000000030000000 Here's where it is. What I don't recall is whether the MTRR understands addresses above 4GB. I lost context, are you using FreeBSD/amd64 or i386+PAE? If so, does memcontrol let you see this RAM? Out of curiosity, do you have a video card with a lot of VRAM on it, or are you using a motherboard that is marketed as a 'gamer' or 'desktop' board? Scott From owner-freebsd-current@FreeBSD.ORG Thu Sep 4 07:39:36 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C458C1065672 for ; Thu, 4 Sep 2008 07:39:36 +0000 (UTC) (envelope-from davidxu@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id B3C678FC21 for ; Thu, 4 Sep 2008 07:39:36 +0000 (UTC) (envelope-from davidxu@freebsd.org) Received: from apple.my.domain (root@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m847dZfR077308 for ; Thu, 4 Sep 2008 07:39:36 GMT (envelope-from davidxu@freebsd.org) Message-ID: <48BF911F.4000600@freebsd.org> Date: Thu, 04 Sep 2008 15:41:19 +0800 From: David Xu User-Agent: Thunderbird 2.0.0.9 (X11/20080612) MIME-Version: 1.0 To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: lockmgr_args, lock order reversal: (sleepable after non-sleepable) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2008 07:39:36 -0000 I saw so many LORs like following, I think this is a false reporting because the interlock is released by lockmgr whether the thread is blocked or not, shouldn't WITNESS_CHECKORDER bypass this interlock ? lock order reversal: (sleepable after non-sleepable) 1st 0xc48d728c vnode interlock (vnode interlock) @ fs/devfs/devfs_vnops.c:286 2nd 0xc48d7270 devfs (devfs) @ kern/vfs_subr.c:2051 KDB: stack backtrace: db_trace_self_wrapper(c0b6d1e1,c4199a2c,c07f1d35,4,c0b68bf7,...) at db_trace_self_wrapper+0x26 kdb_backtrace(4,c0b68bf7,c0de8a58,c44768d0,c4199b64,...) at kdb_backtrace+0x29 _witness_debugger(c0b6fa7b,c48d6000,c0b761c4,c44768d0,c0b7679d,...) at _witness_debugger+0x25 witness_checkorder(c48d6000,1,c0b76794,174,c0b68bf7,...) at witness_checkorder+0x7c9 __lockmgr_args(c48d6000,200100,c48d601c,0,0,...) at __lockmgr_args+0x230 vfs_busy(c48d6000,200,0,1,c44c6d20,...) at vfs_busy+0x1bc vfs_mount_alloc(0,c0c3bae0,c0b7653a,c44b1400,c0831580,...) at vfs_mount_alloc+0x74 vfs_mountroot(c0caef30,4,c0b64bc9,264,0,...) at vfs_mountroot+0x272 start_init(0,c4199d38,c0b66578,322,c44c4d0c,...) at start_init+0x65 fork_exit(c077a040,0,c4199d38) at fork_exit+0xb8 David Xu From owner-freebsd-current@FreeBSD.ORG Thu Sep 4 08:09:55 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 819351065673; Thu, 4 Sep 2008 08:09:55 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 6DA608FC19; Thu, 4 Sep 2008 08:09:54 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <48BF97D2.3020900@FreeBSD.org> Date: Thu, 04 Sep 2008 17:39:54 +0930 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: Julian Elischer References: <200808291636.10656.jhb@FreeBSD.org> <48B86BB3.30705@elischer.org> <200809021036.53908.jhb@freebsd.org> <48BD7C17.70800@elischer.org> In-Reply-To: <48BD7C17.70800@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: rtentry panic with FIB X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2008 08:09:55 -0000 Julian Elischer wrote: > John Baldwin wrote: >> On Friday 29 August 2008 05:35:47 pm Julian Elischer wrote: >>> John Baldwin wrote: >>>> Unfortunately it hung trying to dump, so all I have is the stack trace >> from >>>> DDB. This is recent HEAD running stress2 >>>> >>>> panic: _mtx_lock_sleep: recursed on non-recursive mutex rtentry @ >>>> ../../1 >>>> >>> do you know what lock it was talking about? >> >> All I have is what I included in the original e-mail. So it's an >> "rtentry" mutex, but that's all I know. You can try running the 'udp' >> test from stress2 locally perhaps to see if you can trigger it. >> > > > > 'scuse the ignorance but is that checked in somewhere? http://people.freebsd.org/~pho/stress/index.html Kris From owner-freebsd-current@FreeBSD.ORG Thu Sep 4 09:09:04 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ACB60106567C for ; Thu, 4 Sep 2008 09:09:04 +0000 (UTC) (envelope-from gb@isis.u-strasbg.fr) Received: from mailhost.u-strasbg.fr (mailhost.u-strasbg.fr [IPv6:2001:660:2402::154]) by mx1.freebsd.org (Postfix) with ESMTP id 361E28FC28 for ; Thu, 4 Sep 2008 09:09:04 +0000 (UTC) (envelope-from gb@isis.u-strasbg.fr) Received: from 6nq.u-strasbg.fr (mojito.u-strasbg.fr [IPv6:2001:660:4701:1002::3]) by mailhost.u-strasbg.fr (8.14.2/jtpda-5.5pre1) with ESMTP id m84992KL016700 for ; Thu, 4 Sep 2008 11:09:02 +0200 (CEST) Received: by 6nq.u-strasbg.fr (Postfix, from userid 1001) id 4FAEB707F; Thu, 4 Sep 2008 11:08:43 +0200 (CEST) Date: Thu, 4 Sep 2008 11:08:43 +0200 From: Guy Brand To: freebsd-current@freebsd.org Message-ID: <20080904090842.GA1677@isis.u-strasbg.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline x-gpg-fingerprint: B423 4924 012E 52F3 BA9E 547F CC8C 0BC5 9C0E B1CA x-gpg-key: 9C0EB1CA User-Agent: Mutt/1.5.18 (2008-05-17) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (mailhost.u-strasbg.fr [IPv6:2001:660:2402::154]); Thu, 04 Sep 2008 11:09:02 +0200 (CEST) X-Virus-Scanned: ClamAV 0.93.1/8155/Thu Sep 4 09:16:44 2008 on mr4.u-strasbg.fr X-Virus-Status: Clean X-Spam-Status: No, score=-0.0 required=5.0 tests=NO_RELAYS autolearn=disabled version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mr4.u-strasbg.fr Subject: Panic at shutdown X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2008 09:09:04 -0000 Hello, With 8.0-CURRENT from yesterday (Wed Sep 3 21:49:10 CEST 2008) on an i386 laptop with the following kernel config: include GENERIC cpu I686_CPU ident LENOVO nodevice cpufreq nodevice sbp nodevice fwe nodevice fwip I get a panic (hand transcripted below) on every reboot: All buffers synced. Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0xc fault code = supervisor write, page not present instruction pointer = 0x20:0x80e281d9 stack pointer = 0x28:0x84dfba70 frame pointer = 0x28:0x84dfba8c code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 1 (init) [thread pid 1 tid 100002 ] Stopped at gfs_dir_create+0x39: movl $0,0xc(%ebx) db> trace Tracing pid 1 tid 100002 td 0x850afd20 gfs_dir_create(7c,858c3430,85834a80,80ea89c0,0,...) at gfs_dir_create+0x39 zfsctl_mknode_snapdir(858c3430,80e9fa03,275,25d,861049a0,...) at zfsctl_mknode_snapdir+0x53 gfs_dir_lookup(858c3430,80ea5171,84dfbb68,80ac8818,84dfbb34,...) at gfs_dir_lookup+0x1bf zfsctl_root_lookup(858c3430,80ea5171,84dfbb68,0,0,...) at zfsctl_root_lookup+0xc5 zfsctl_umount_snapshots(85834a80,80000,8509a600,80e918b5,85803044,...) at zfsctl_umount_snapshots+0x4e zfs_umount(85834a80,80000,850afd20,850afd20,0,...) at zfs_umount+0x52 dounmount(85834a80,80000,850afd20,ad0e5830,0,...) at dounmount+0x4f3 vfs_unmountall(80b72886,0,80b72925,117,84dfbc50,...) at vfs_unmountall+0x33 boot(850afd20,8,0,fffffffe,850afd20,...) at boot+0x439 reboot(850afd20,84dfbcf8,4,0,e,...) at reboot+0x67 syscall(84dfbd38) at syscall+0x325 Xint0x80_syscall() at syscall+0x20 --- syscall (55, FreeBSD ELF32, reboot), eip = 0x8051103, esp = 0x7fbfe8bc, ebp = 0x7fbfe998 --- This is my ZFS setup: NAME USED AVAIL REFER MOUNTPOINT pool 51.4G 52.0G 24K /pool pool/bunker 14.1M 52.0G 14.1M /bunker pool/doc 25.1M 52.0G 25.1M /usr/doc pool/home 38.6G 52.0G 38.6G /home pool/tmp 52.5K 512M 52.5K /tmp pool/usr 12.5G 52.0G 12.5G /usr pool/var 253M 1.75G 253M /var NAME SIZE USED AVAIL CAP HEALTH ALTROOT pool 105G 51.4G 53.6G 48% ONLINE - The root filesystem is on UFS: # Device Mountpoint FStype Options Dump Pass# /dev/ad4s1b none swap sw 0 0 /dev/ad4s1a / ufs rw 1 1 If there is any other information I could provide, please let me know. Regards, -- bug From owner-freebsd-current@FreeBSD.ORG Thu Sep 4 09:44:05 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 57B05106566C for ; Thu, 4 Sep 2008 09:44:05 +0000 (UTC) (envelope-from oliver@nemesis.charlie.mouhaha.de) Received: from nemesis.charlie.mouhaha.de (nemesis.charlie.mouhaha.de [78.47.10.193]) by mx1.freebsd.org (Postfix) with ESMTP id 1383F8FC14 for ; Thu, 4 Sep 2008 09:44:04 +0000 (UTC) (envelope-from oliver@nemesis.charlie.mouhaha.de) Received: from localhost (nemesis.charlie.mouhaha.de [78.47.10.193]) by nemesis.charlie.mouhaha.de (Postfix) with ESMTP id 1EF3C4203D; Thu, 4 Sep 2008 10:27:43 +0100 (BST) X-Virus-Scanned: amavisd-new at mouhaha.de Received: from nemesis.charlie.mouhaha.de ([78.47.10.193]) by localhost (nemesis.charlie.mouhaha.de [78.47.10.193]) (amavisd-new, port 10024) with ESMTP id 8PrRPaHPoMWu; Thu, 4 Sep 2008 10:27:41 +0100 (BST) Received: by nemesis.charlie.mouhaha.de (Postfix, from userid 1001) id E0EDE42031; Thu, 4 Sep 2008 10:27:40 +0100 (BST) Date: Thu, 4 Sep 2008 10:27:40 +0100 From: Oliver Peter To: Guy Brand Message-ID: <20080904092740.GA32453@nemesis.frida.mouhaha.de> References: <20080904090842.GA1677@isis.u-strasbg.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080904090842.GA1677@isis.u-strasbg.fr> X-Operating-System: FreeBSD 7.0-RELEASE-p3 amd64 User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-current@freebsd.org Subject: Re: Panic at shutdown X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2008 09:44:05 -0000 On Thu, Sep 04, 2008 at 11:08:43AM +0200, Guy Brand wrote: > Hello, > > > With 8.0-CURRENT from yesterday (Wed Sep 3 21:49:10 CEST 2008) on an > i386 laptop with the following kernel config: > > include GENERIC > cpu I686_CPU > ident LENOVO > nodevice cpufreq > nodevice sbp > nodevice fwe > nodevice fwip > > I get a panic (hand transcripted below) on every reboot: Same here on my laptop with latest 8.0-CURRENT/i386/ZFS. I'll provide some debug information later this day. -- Oliver PETER, email: oliver@peter.de.com, ICQ# 113969174 "I like to con people. And I like to insult people. If you combine con & insult, you get consult!" -- Dogbert From owner-freebsd-current@FreeBSD.ORG Thu Sep 4 11:11:31 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E356A1065673; Thu, 4 Sep 2008 11:11:31 +0000 (UTC) (envelope-from gabor@kovesdan.org) Received: from server.mypc.hu (server.mypc.hu [87.229.73.95]) by mx1.freebsd.org (Postfix) with ESMTP id 92C938FC23; Thu, 4 Sep 2008 11:11:31 +0000 (UTC) (envelope-from gabor@kovesdan.org) Received: from localhost (localhost [127.0.0.1]) by server.mypc.hu (Postfix) with ESMTP id C532814D77F0; Thu, 4 Sep 2008 13:11:29 +0200 (CEST) X-Virus-Scanned: amavisd-new at t-hosting.hu Received: from server.mypc.hu ([127.0.0.1]) by localhost (server.mypc.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id AhrxXzCtWV6g; Thu, 4 Sep 2008 13:11:27 +0200 (CEST) Received: from [78.131.25.160] (78-131-25-160.pool.hdsnet.hu [78.131.25.160]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by server.mypc.hu (Postfix) with ESMTPSA id D219C14D77EF; Thu, 4 Sep 2008 13:11:26 +0200 (CEST) Message-ID: <48BFC257.2010000@kovesdan.org> Date: Thu, 04 Sep 2008 13:11:19 +0200 From: Gabor Kovesdan User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Andrey Chernov , Gabor Kovesdan , hackers@freebsd.org, Max Khon , dougb@freebsd.org, krion@freebsd.org, current@freebsd.org References: <48B44A7D.3070108@kovesdan.org> <20080827013221.GA82176@nagual.pp.ru> In-Reply-To: <20080827013221.GA82176@nagual.pp.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Thu, 04 Sep 2008 11:27:49 +0000 Cc: Subject: Re: CFT: BSD grep X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2008 11:11:32 -0000 Andrey Chernov ha scritto: > Just from quick looking at the sources... > > This code looks suspicious: > > wend = sscanf(&l->dat[pmatch.rm_eo], "%lc", &wend); > > Perhaps it should be > > if (sscanf(&l->dat[pmatch.rm_eo], "%lc", &wend) != 1) > r = REG_NOMATCH; > > The next thing is that perhaps each r = REG_NOMATCH; case should be > isolated from others in this block (with "else if"?) > F.e. failing mbstowcs() can leave buffer for sscanf() in junk. > > wbegin = grep_malloc(mbstowcs(NULL, l->dat, pmatch.rm_so)); > > grep_malloc() here could terminate program for invalid mbstowcs() > sequence, but really must set only r = REG_NOMATCH; > > Think about files which, for various reasons, may contain not only valid > MB sequences. > > fgrepcomp() uses toupper()/tolower() while should use wide chars analogs > (MB chars can be in the pattern too). There are also many other places > where pattern treated as single chars one, fastcomp() etc. grep_cmp() > compares single chars toupper(data[]) too. There must be no plain ctype > usage in the whole data _and_ pattern handling code. > Hello Andrey, thanks for the detailed description of the current deficiencies, I'll fix them soon. I've been busy with moving to another flat, that's why I haven't replied yet, sorry for that. Gábor From owner-freebsd-current@FreeBSD.ORG Thu Sep 4 12:50:19 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 00999106566C; Thu, 4 Sep 2008 12:50:19 +0000 (UTC) (envelope-from Benjamin.Close@clearchain.com) Received: from ipmail04.adl2.internode.on.net (ipmail04.adl2.internode.on.net [203.16.214.57]) by mx1.freebsd.org (Postfix) with ESMTP id 7D12A8FC18; Thu, 4 Sep 2008 12:50:17 +0000 (UTC) (envelope-from Benjamin.Close@clearchain.com) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai8FAMNzv0h5LRXq/2dsb2JhbACBZq8WhxqBZw X-IronPort-AV: E=Sophos;i="4.32,320,1217773800"; d="scan'208";a="200976631" Received: from ppp121-45-21-234.lns10.adl2.internode.on.net (HELO mail.clearchain.com) ([121.45.21.234]) by ipmail04.adl2.internode.on.net with ESMTP; 04 Sep 2008 22:20:13 +0930 Received: from [192.168.155.234] (taurus.internal.clearchain.com [192.168.155.234]) (authenticated bits=0) by mail.clearchain.com (8.14.2/8.14.2) with ESMTP id m84Co19h001571 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Sep 2008 22:20:02 +0930 (CST) (envelope-from Benjamin.Close@clearchain.com) Message-ID: <48BFD989.6010809@clearchain.com> Date: Thu, 04 Sep 2008 22:20:17 +0930 From: Benjamin Close User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: John Baldwin References: <200808230003.44081.jhb@freebsd.org> <48B6BC81.5060300@clearchain.com> <20080901.013117.74700691.Tor.Egge@cvsup.no.freebsd.org> <200809021608.57542.jhb@freebsd.org> In-Reply-To: <200809021608.57542.jhb@freebsd.org> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on pegasus.clearchain.com X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (mail.clearchain.com [192.168.154.1]); Thu, 04 Sep 2008 22:20:03 +0930 (CST) Cc: pjd@freebsd.org, attilio@freebsd.org, freebsd-current@freebsd.org, kib@freebsd.org, kevinxlinuz@163.com Subject: Re: [BUG] I think sleepqueue need to be protected in sleepq_broadcast X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2008 12:50:19 -0000 John Baldwin wrote: > On Sunday 31 August 2008 09:31:17 pm Tor Egge wrote: > >> sleepq_resume_thread() contains an ownership handover of sq if the resumed >> thread is the last one blocked on the wait channel. After the handover, sq >> > is > >> no longer protected by the sleep queue chain lock and should no longer be >> accessed by sleepq_broadcast(). >> >> Normally, when sleepq_broadcast() incorrectly accesses sq after the >> > handover, > >> it will find the sq->sq_blocked queue to be empty, and the code appears to >> work. >> >> If the last correctly woken thread manages to go to sleep again very quickly >> > on > >> another wait channel, sleepq_broadcast() might incorrectly determine that >> > the > >> sq->sq_blocked queue isn't empty, and start doing the wrong thing. >> > > So disregard my earlier e-mail. Here is a simple fix for the sleepq case: > > Index: subr_sleepqueue.c > =================================================================== > --- subr_sleepqueue.c (revision 182679) > +++ subr_sleepqueue.c (working copy) > @@ -779,7 +779,7 @@ > sleepq_broadcast(void *wchan, int flags, int pri, int queue) > { > struct sleepqueue *sq; > - struct thread *td; > + struct thread *td, *tdn; > int wakeup_swapper; > > CTR2(KTR_PROC, "sleepq_broadcast(%p, %d)", wchan, flags); > @@ -793,8 +793,7 @@ > > /* Resume all blocked threads on the sleep queue. */ > wakeup_swapper = 0; > - while (!TAILQ_EMPTY(&sq->sq_blocked[queue])) { > - td = TAILQ_FIRST(&sq->sq_blocked[queue]); > + TAILQ_FOREACH_SAFE(td, &sq->sq_blocked[queue], td_slpq, tdn) { > thread_lock(td); > if (sleepq_resume_thread(sq, td, pri)) > wakeup_swapper = 1; > > This only uses 'sq' to fetch the head of the queue once up front. It won't > use it again once it has started waking up threads. > > >> A similar (but probably much more difficult to trigger) issue is present >> > with > >> regards to thread_lock() and turnstiles. >> >> The caller of thread_lock() might have performed sufficient locking to >> > ensure > >> that the thread to be locked doesn't go away, but any turnstile spin lock >> pointed to by td->td_lock isn't protected. Making turnstiles type stable >> (setting UMA_ZONE_NOFREE flag for turnstile_zone) should fix that issue. >> > > Note that unlike the sleepq case, turnstiles are not made runnable until all > of them are dequeued from the turnstile and assigned a new turnstile. Only > after all that is settled are the threads made runnable in turnstile_unpend(). > > However, that doesn't fix this specific race (though it means the turnstile > code is not subject to the same exact race as the sleepq code above). Making > turnstiles type-stable is indeed probably the only fix for this. :-/ > > I can confirm this patch fixes the repeatable panic which was causing: panic: mutex sleepq chain (0xffffffff8102c460) not owned .... type messages for me when DDB was enabled, deadlocks without it. It's the first time I've been able run a complete zpool scrub in multiuser mode in since 7.0 was released. Tor, nice catch! Jb, thanks for the fix. This also I believe solves amd64/124200 Cheers, Benjamin From owner-freebsd-current@FreeBSD.ORG Thu Sep 4 13:23:04 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 67A5C1065670; Thu, 4 Sep 2008 13:23:04 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 26E568FC13; Thu, 4 Sep 2008 13:23:04 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m84DMwVY001793; Thu, 4 Sep 2008 09:22:58 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.3/8.14.3) with ESMTP id m84DMw3a077317; Thu, 4 Sep 2008 09:22:58 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 0BEDD73039; Thu, 4 Sep 2008 09:22:57 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080904132258.0BEDD73039@freebsd-current.sentex.ca> Date: Thu, 4 Sep 2008 09:22:57 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on clamscanner3 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2008 13:23:04 -0000 TB --- 2008-09-04 11:55:39 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-09-04 11:55:39 - starting HEAD tinderbox run for ia64/ia64 TB --- 2008-09-04 11:55:39 - cleaning the object tree TB --- 2008-09-04 11:56:12 - cvsupping the source tree TB --- 2008-09-04 11:56:12 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/ia64/ia64/supfile TB --- 2008-09-04 11:56:19 - building world (CFLAGS=-O -pipe) TB --- 2008-09-04 11:56:19 - cd /src TB --- 2008-09-04 11:56:19 - /usr/bin/make -B buildworld >>> World build started on Thu Sep 4 11:56:21 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Thu Sep 4 13:13:42 UTC 2008 TB --- 2008-09-04 13:13:42 - generating LINT kernel config TB --- 2008-09-04 13:13:42 - cd /src/sys/ia64/conf TB --- 2008-09-04 13:13:42 - /usr/bin/make -B LINT TB --- 2008-09-04 13:13:42 - building LINT kernel (COPTFLAGS=) TB --- 2008-09-04 13:13:42 - cd /src TB --- 2008-09-04 13:13:42 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Sep 4 13:13:43 UTC 2008 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/security/audit/audit_syscalls.c:403: error: expected identifier or '(' before 'break' /src/sys/security/audit/audit_syscalls.c:405: error: expected identifier or '(' before 'case' /src/sys/security/audit/audit_syscalls.c:409: error: expected identifier or '(' before 'return' /src/sys/security/audit/audit_syscalls.c:411: error: expected identifier or '(' before 'default' /src/sys/security/audit/audit_syscalls.c:413: error: expected identifier or '(' before '}' token /src/sys/security/audit/audit_syscalls.c:418: error: expected identifier or '(' before 'switch' /src/sys/security/audit/audit_syscalls.c:437: error: expected identifier or '(' before 'return' /src/sys/security/audit/audit_syscalls.c:438: error: expected identifier or '(' before '}' token *** Error code 1 Stop in /obj/ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-09-04 13:22:57 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-09-04 13:22:57 - ERROR: failed to build lint kernel TB --- 2008-09-04 13:22:57 - tinderbox aborted TB --- 3926.97 user 416.55 system 5238.63 real http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Thu Sep 4 14:12:20 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EF2EE106566B; Thu, 4 Sep 2008 14:12:20 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id AFEAC8FC1E; Thu, 4 Sep 2008 14:12:20 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.14.2/8.14.2) with ESMTP id m84ECIod049346; Thu, 4 Sep 2008 10:12:18 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.2/8.14.2) with ESMTP id m84ECH78050569; Thu, 4 Sep 2008 10:12:17 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 929A673039; Thu, 4 Sep 2008 10:12:17 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080904141217.929A673039@freebsd-current.sentex.ca> Date: Thu, 4 Sep 2008 10:12:17 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.93, clamav-milter version 0.93 on clamscanner2 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 205.211.164.50 Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2008 14:12:21 -0000 TB --- 2008-09-04 12:56:35 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-09-04 12:56:35 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2008-09-04 12:56:35 - cleaning the object tree TB --- 2008-09-04 12:57:00 - cvsupping the source tree TB --- 2008-09-04 12:57:00 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2008-09-04 12:57:07 - building world (CFLAGS=-O -pipe) TB --- 2008-09-04 12:57:07 - cd /src TB --- 2008-09-04 12:57:07 - /usr/bin/make -B buildworld >>> World build started on Thu Sep 4 12:57:09 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Thu Sep 4 14:05:34 UTC 2008 TB --- 2008-09-04 14:05:35 - generating LINT kernel config TB --- 2008-09-04 14:05:35 - cd /src/sys/powerpc/conf TB --- 2008-09-04 14:05:35 - /usr/bin/make -B LINT TB --- 2008-09-04 14:05:35 - building LINT kernel (COPTFLAGS=) TB --- 2008-09-04 14:05:35 - cd /src TB --- 2008-09-04 14:05:35 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Sep 4 14:05:35 UTC 2008 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/security/audit/audit_syscalls.c:403: error: expected identifier or '(' before 'break' /src/sys/security/audit/audit_syscalls.c:405: error: expected identifier or '(' before 'case' /src/sys/security/audit/audit_syscalls.c:409: error: expected identifier or '(' before 'return' /src/sys/security/audit/audit_syscalls.c:411: error: expected identifier or '(' before 'default' /src/sys/security/audit/audit_syscalls.c:413: error: expected identifier or '(' before '}' token /src/sys/security/audit/audit_syscalls.c:418: error: expected identifier or '(' before 'switch' /src/sys/security/audit/audit_syscalls.c:437: error: expected identifier or '(' before 'return' /src/sys/security/audit/audit_syscalls.c:438: error: expected identifier or '(' before '}' token *** Error code 1 Stop in /obj/powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-09-04 14:12:17 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-09-04 14:12:17 - ERROR: failed to build lint kernel TB --- 2008-09-04 14:12:17 - tinderbox aborted TB --- 3388.59 user 399.48 system 4541.91 real http://tinderbox.des.no/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Thu Sep 4 14:30:12 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F01BB106566B; Thu, 4 Sep 2008 14:30:12 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id 5138C8FC08; Thu, 4 Sep 2008 14:30:12 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from kobe.laptop (adsl57-66.kln.forthnet.gr [77.49.184.66]) (authenticated bits=128) by igloo.linux.gr (8.14.3/8.14.3/Debian-5) with ESMTP id m84ETpLW003671 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 4 Sep 2008 17:29:57 +0300 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.3/8.14.3) with ESMTP id m84ETp9B003770; Thu, 4 Sep 2008 17:29:51 +0300 (EEST) (envelope-from keramida@freebsd.org) Received: (from keramida@localhost) by kobe.laptop (8.14.3/8.14.3/Submit) id m84ETo0m003769; Thu, 4 Sep 2008 17:29:50 +0300 (EEST) (envelope-from keramida@freebsd.org) From: Giorgos Keramidas To: Tim Kientzle References: <87hc8x74nd.fsf@kobe.laptop> <48BEB5E1.8080906@freebsd.org> <87ej41rkpk.fsf@kobe.laptop> <48BF6D2C.4030001@freebsd.org> Date: Thu, 04 Sep 2008 17:29:50 +0300 In-Reply-To: <48BF6D2C.4030001@freebsd.org> (Tim Kientzle's message of "Wed, 03 Sep 2008 22:07:56 -0700") Message-ID: <87ljy8j869.fsf@kobe.laptop> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-MailScanner-ID: m84ETpLW003671 X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-4.284, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.12, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@freebsd.org X-Spam-Status: No Cc: freebsd-current@freebsd.org Subject: Re: cpio reporting too many 'blocks' X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2008 14:30:13 -0000 On Wed, 03 Sep 2008 22:07:56 -0700, Tim Kientzle wrote: >Giorgos Keramidas wrote: >> ACK. If you want me to run any tests or test patches, please feel free >> to send them this way :-) > > I think I found it. Try this and let me know. > > Tim > Index: cpio.c > =================================================================== > --- cpio.c (revision 182102) > +++ cpio.c (working copy) > @@ -863,7 +863,6 @@ > r = archive_write_close(cpio->archive); > if (r != ARCHIVE_OK) > cpio_errc(1, 0, archive_error_string(cpio->archive)); > - archive_write_finish(cpio->archive); > > if (!cpio->quiet) { > blocks = (archive_position_uncompressed(cpio->archive) + 511) > @@ -872,6 +871,7 @@ > blocks == 1 ? "block" : "blocks"); > } > > + archive_write_finish(cpio->archive); > } That's it. Not the blocks reported look more sensible: keramida@kobe:/ws/bsd/doc$ find * | cpio -p -dmu /hg/doc/bsd-import 40345 blocks keramida@kobe:/ws/bsd/doc$ echo $(( $( find * | xargs cat | wc -c ) / 512 )) 40916 Thanks :) From owner-freebsd-current@FreeBSD.ORG Thu Sep 4 15:34:44 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0D4051065674 for ; Thu, 4 Sep 2008 15:34:44 +0000 (UTC) (envelope-from josh.carroll@gmail.com) Received: from mail-gx0-f17.google.com (mail-gx0-f17.google.com [209.85.217.17]) by mx1.freebsd.org (Postfix) with ESMTP id A2BA88FC08 for ; Thu, 4 Sep 2008 15:34:43 +0000 (UTC) (envelope-from josh.carroll@gmail.com) Received: by gxk10 with SMTP id 10so6451868gxk.19 for ; Thu, 04 Sep 2008 08:34:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:reply-to :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=v5/mqYVYYw/jPP7VpQREL2eKFV2J1MM1CQBfgbR6JgU=; b=eYPXXHPZhX3AbwWi+E3ztkK8lgRxfYy8fHi3lZr3l7UHRibB+UMJAuVFXP1HSJ1Bfj tBxLio6b1N2+Smij8hlggedNg1NjWB+YDEHicf+p9XxoB7H8sU95ShwksbR303wRQoHU WZCfg+FhWI9IRvPm823sjyuZE5h4NLK0kFFXc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:reply-to:to:subject:cc:in-reply-to :mime-version:content-type:content-transfer-encoding :content-disposition:references; b=YSYnmARxDo/oFlJHdtq1mLZKcLN4RDMEZIKfA71RtnWCkN8lLMdSl1pCm8G7k1zzto fOVA9V+S0ANRMSR8L/3MWjIQb32Wwz12Z493cP3dks/A2qj4RCtBqGhw08FSCYiet0op y7Cy1YEojyAdHg9ZlbVg2k3xL5mU9Ry8WkVWY= Received: by 10.151.156.7 with SMTP id i7mr14623882ybo.115.1220542482832; Thu, 04 Sep 2008 08:34:42 -0700 (PDT) Received: by 10.150.140.14 with HTTP; Thu, 4 Sep 2008 08:34:42 -0700 (PDT) Message-ID: <8cb6106e0809040834h4a32ca25qfc4a2c706519a6b3@mail.gmail.com> Date: Thu, 4 Sep 2008 11:34:42 -0400 From: "Josh Carroll" To: "Scott Long" In-Reply-To: <48BF7186.6040603@samsco.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20080903034943.GD11548@cicely7.cicely.de> <20080903204759.GA4898@walton.maths.tcd.ie> <8cb6106e0809031446i3e2a47dar385125ecfb0275dc@mail.gmail.com> <48BF1218.6000504@samsco.org> <8cb6106e0809031550o4960a4fanaf2ef5fe9130fc5b@mail.gmail.com> <48BF17CE.1070507@samsco.org> <8cb6106e0809032043x7eeb7aaeoc29473c028a8220f@mail.gmail.com> <48BF7186.6040603@samsco.org> Cc: David Malone , Bernd Walter , freebsd-current@freebsd.org, ticso@cicely.de Subject: Re: MTRR fixup? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: josh.carroll@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2008 15:34:44 -0000 Hi Scott, First, I really appreciate the in-depth explanation here. Always good to learn something new. > Here's where it is. What I don't recall is whether the MTRR understands > addresses above 4GB. I lost context, are you using FreeBSD/amd64 or > i386+PAE? If so, does memcontrol let you see this RAM? It's 7.1-PRERELEASE/amd64 . Below is the full memcontrol list output, and devinfo -r output (for the portions pertaining to ram0) - which shows the type=01 address ranges. I wasn't aware of that, but Bernd pointed that out. > Out of curiosity, do you have a video card with a lot of VRAM on it, or > are you using a motherboard that is marketed as a 'gamer' or 'desktop' > board? The video card in question is just a cheapo $25 PCI-E video card, "BIOSTAR V6202EL16 GeForce 6200LE 256MB TurboCache(128M VRAM on board) 64-bit GDDR2 PCI Express x16 Low Profile". Here's the pciconf output for it: vgapci0@pci0:1:0:0: class=0x030000 card=0x00000000 chip=0x016310de rev=0xa1 hdr=0x00 vendor = 'Nvidia Corp' device = 'GeForce 6200 LE' class = display subclass = VGA I believe it has 128MB onboard and the "turbocache" is just their buzzword term for using 128M of shared system memory. Here is the devinfo -r information on the I/O ranges for it: vgapci0 I/O memory addresses: 0xd0000000-0xdfffffff 0xfc000000-0xfcffffff 0xfd000000-0xfdffffff The first range is a 256MB chunk (framebuffer?) and corresponds to an uncacheable area from memcontrol list: 0xd0000000/0x10000000 BIOS uncacheable set-by-firmware active But this address range does not intersect any of the SMAP ranges. So I'm not entirely sure how the extra 128MB comes into play. Perhaps the "turbocache" feature requires that the OS know about it and handles the memory ranges appropriately? Do you have any ideas how that might work? Perhaps it just limits the available VRAM to 128MB if the OS does not support "TurboCache"? The board itself is the Asus P5K-E, with no on-board video. I'll have to poke around the BIOS and play with whatever the PCI-E equivalent of "AGP aperture size" is, and see if/how that affects the SMAP and/or mtrrs. Thanks, Josh memcontrol list output: 0x0/0x10000 BIOS write-back fixed-base fixed-length set-by-firmware active 0x10000/0x10000 BIOS write-back fixed-base fixed-length set-by-firmware active 0x20000/0x10000 BIOS write-back fixed-base fixed-length set-by-firmware active 0x30000/0x10000 BIOS write-back fixed-base fixed-length set-by-firmware active 0x40000/0x10000 BIOS write-back fixed-base fixed-length set-by-firmware active 0x50000/0x10000 BIOS write-back fixed-base fixed-length set-by-firmware active 0x60000/0x10000 BIOS write-back fixed-base fixed-length set-by-firmware active 0x70000/0x10000 BIOS write-back fixed-base fixed-length set-by-firmware active 0x80000/0x4000 BIOS write-back fixed-base fixed-length set-by-firmware active 0x84000/0x4000 BIOS write-back fixed-base fixed-length set-by-firmware active 0x88000/0x4000 BIOS write-back fixed-base fixed-length set-by-firmware active 0x8c000/0x4000 BIOS write-back fixed-base fixed-length set-by-firmware active 0x90000/0x4000 BIOS write-back fixed-base fixed-length set-by-firmware active 0x94000/0x4000 BIOS write-back fixed-base fixed-length set-by-firmware active 0x98000/0x4000 BIOS write-back fixed-base fixed-length set-by-firmware active 0x9c000/0x4000 BIOS write-back fixed-base fixed-length set-by-firmware active 0xa0000/0x4000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xa4000/0x4000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xa8000/0x4000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xac000/0x4000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xb0000/0x4000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xb4000/0x4000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xb8000/0x4000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xbc000/0x4000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xc0000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xc1000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xc2000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xc3000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xc4000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xc5000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xc6000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xc7000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xc8000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xc9000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xca000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xcb000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xcc000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xcd000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xce000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xcf000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xd0000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xd1000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xd2000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xd3000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xd4000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xd5000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xd6000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xd7000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xd8000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xd9000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xda000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xdb000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xdc000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xdd000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xde000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xdf000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xe0000/0x1000 BIOS write-through fixed-base fixed-length set-by-firmware active 0xe1000/0x1000 BIOS write-through fixed-base fixed-length set-by-firmware active 0xe2000/0x1000 BIOS write-through fixed-base fixed-length set-by-firmware active 0xe3000/0x1000 BIOS write-through fixed-base fixed-length set-by-firmware active 0xe4000/0x1000 BIOS write-through fixed-base fixed-length set-by-firmware active 0xe5000/0x1000 BIOS write-through fixed-base fixed-length set-by-firmware active 0xe6000/0x1000 BIOS write-through fixed-base fixed-length set-by-firmware active 0xe7000/0x1000 BIOS write-through fixed-base fixed-length set-by-firmware active 0xe8000/0x1000 BIOS write-through fixed-base fixed-length set-by-firmware active 0xe9000/0x1000 BIOS write-through fixed-base fixed-length set-by-firmware active 0xea000/0x1000 BIOS write-through fixed-base fixed-length set-by-firmware active 0xeb000/0x1000 BIOS write-through fixed-base fixed-length set-by-firmware active 0xec000/0x1000 BIOS write-through fixed-base fixed-length set-by-firmware active 0xed000/0x1000 BIOS write-through fixed-base fixed-length set-by-firmware active 0xee000/0x1000 BIOS write-through fixed-base fixed-length set-by-firmware active 0xef000/0x1000 BIOS write-through fixed-base fixed-length set-by-firmware active 0xf0000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xf1000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xf2000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xf3000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xf4000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xf5000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xf6000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xf7000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xf8000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xf9000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xfa000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xfb000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xfc000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xfd000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xfe000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xff000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xd0000000/0x10000000 BIOS uncacheable set-by-firmware active 0xe0000000/0x20000000 BIOS uncacheable set-by-firmware active 0x0/0x100000000 BIOS write-back set-by-firmware active 0x100000000/0x20000000 BIOS write-back set-by-firmware active 0x120000000/0x10000000 BIOS write-back set-by-firmware active devinfo -r output (snipped): ram0 I/O memory addresses: 0x0-0x9ebff 0x100000-0xcff7ffff 0x100000000-0x12fffffff From owner-freebsd-current@FreeBSD.ORG Thu Sep 4 17:02:09 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 096A61065685; Thu, 4 Sep 2008 17:02:09 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.freebsd.org (Postfix) with ESMTP id DAC9D8FC12; Thu, 4 Sep 2008 17:02:08 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.3/8.14.3) with ESMTP id m84H28Cu001482; Thu, 4 Sep 2008 10:02:08 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.3/8.14.3/Submit) id m84H285l001481; Thu, 4 Sep 2008 10:02:08 -0700 (PDT) (envelope-from sgk) Date: Thu, 4 Sep 2008 10:02:08 -0700 From: Steve Kargl To: Robert Noland Message-ID: <20080904170208.GA1463@troutmask.apl.washington.edu> References: <20080903011612.GA1242@troutmask.apl.washington.edu> <1220416793.1848.1.camel@wombat.2hip.net> <20080903051228.GA2475@troutmask.apl.washington.edu> <1220471512.11763.9.camel@squirrel.corp.cox.com> <20080903195845.GA1370@troutmask.apl.washington.edu> <1220493627.2467.6.camel@wombat.2hip.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1220493627.2467.6.camel@wombat.2hip.net> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@FreeBSD.org Subject: Re: drm causes kernel panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2008 17:02:09 -0000 On Wed, Sep 03, 2008 at 10:00:27PM -0400, Robert Noland wrote: > > Ok, please try the attached patch. I talked it over with another drm > developer and it should be safe to drop all the locks while calling > drm_pci_alloc(). I think I have fixed this for all drivers / paths that > call it. It will log an error now if it is called with either of the > two locks that I found being held. I have tested this on my intel 965gm > so far and all is well. I also had to touch mach64 and radeon, so I > need someone to validate those. (This is a different path from the > panic you received previously) > Your patch fixes the problem. With a new kernel and Xorg's dri module loaded, I now see in /var/log/Xorg.0.log (II) MACH64(0): [drm] SAREA 2200+1208: 3408 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 9, (OK) drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 9, (OK) drmOpenByBusid: Searching for BusID pci:0000:03:06.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 9, (OK) drmOpenByBusid: drmOpenMinor returns 9 drmOpenByBusid: drmGetBusid reports pci:0000:03:06.0 (II) [drm] DRM interface version 1.2 (II) [drm] DRM open master succeeded. (II) MACH64(0): [drm] Using the DRM lock SAREA also for drawables. (II) MACH64(0): [drm] framebuffer handle = 0xfd000000 (II) MACH64(0): [drm] added 1 reserved context for kernel (II) MACH64(0): X context handle = 0x1 (II) MACH64(0): [drm] installed DRM signal handler (II) MACH64(0): [drm] Will request asynchronous DMA mode (==) MACH64(0): [drm] Using 2 MB for DMA buffers (II) MACH64(0): [pci] ring handle = 0x64a34000 (II) MACH64(0): [pci] Ring mapped at 0x2006d4000 (II) MACH64(0): [drm] register handle = 0xfeaff000 (II) MACH64(0): [dri] Visual configs initialized (II) MACH64(0): [dri] Block 0 base at 0xfeaff400 (WW) MACH64(0): Not enough memory for local textures, disabling DRI (II) MACH64(0): [drm] removed 1 reserved context for kernel (II) MACH64(0): [drm] unmapping 8192 bytes of SAREA 0xfffffffe40962000 at 0x2006d2000 (II) MACH64(0): [drm] Closed DRM master. -- Steve From owner-freebsd-current@FreeBSD.ORG Thu Sep 4 17:53:16 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8C0461065677 for ; Thu, 4 Sep 2008 17:53:16 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id 4FA308FC26 for ; Thu, 4 Sep 2008 17:53:16 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from [192.168.166.46] ([68.0.14.34]) (authenticated bits=0) by gizmo.2hip.net (8.13.8/8.13.8) with ESMTP id m84HrAnh042902 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Sep 2008 13:53:10 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Steve Kargl In-Reply-To: <20080904170208.GA1463@troutmask.apl.washington.edu> References: <20080903011612.GA1242@troutmask.apl.washington.edu> <1220416793.1848.1.camel@wombat.2hip.net> <20080903051228.GA2475@troutmask.apl.washington.edu> <1220471512.11763.9.camel@squirrel.corp.cox.com> <20080903195845.GA1370@troutmask.apl.washington.edu> <1220493627.2467.6.camel@wombat.2hip.net> <20080904170208.GA1463@troutmask.apl.washington.edu> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-zxcLd3NzslpwgLSevtCf" Organization: FreeBSD Date: Thu, 04 Sep 2008 13:53:05 -0400 Message-Id: <1220550785.54710.33.camel@squirrel.corp.cox.com> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 FreeBSD GNOME Team Port X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on gizmo.2hip.net Cc: freebsd-current@FreeBSD.org Subject: Re: drm causes kernel panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2008 17:53:16 -0000 --=-zxcLd3NzslpwgLSevtCf Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2008-09-04 at 10:02 -0700, Steve Kargl wrote: > On Wed, Sep 03, 2008 at 10:00:27PM -0400, Robert Noland wrote: > >=20 > > Ok, please try the attached patch. I talked it over with another drm > > developer and it should be safe to drop all the locks while calling > > drm_pci_alloc(). I think I have fixed this for all drivers / paths tha= t > > call it. It will log an error now if it is called with either of the > > two locks that I found being held. I have tested this on my intel 965g= m > > so far and all is well. I also had to touch mach64 and radeon, so I > > need someone to validate those. (This is a different path from the > > panic you received previously) > >=20 >=20 > Your patch fixes the problem. With a new kernel and Xorg's dri > module loaded, I now see in /var/log/Xorg.0.log >=20 > (II) MACH64(0): [drm] SAREA 2200+1208: 3408 > drmOpenDevice: node name is /dev/dri/card0 > drmOpenDevice: open result is 9, (OK) > drmOpenDevice: node name is /dev/dri/card0 > drmOpenDevice: open result is 9, (OK) > drmOpenByBusid: Searching for BusID pci:0000:03:06.0 > drmOpenDevice: node name is /dev/dri/card0 > drmOpenDevice: open result is 9, (OK) > drmOpenByBusid: drmOpenMinor returns 9 > drmOpenByBusid: drmGetBusid reports pci:0000:03:06.0 > (II) [drm] DRM interface version 1.2 > (II) [drm] DRM open master succeeded. > (II) MACH64(0): [drm] Using the DRM lock SAREA also for drawables. > (II) MACH64(0): [drm] framebuffer handle =3D 0xfd000000 > (II) MACH64(0): [drm] added 1 reserved context for kernel > (II) MACH64(0): X context handle =3D 0x1 > (II) MACH64(0): [drm] installed DRM signal handler > (II) MACH64(0): [drm] Will request asynchronous DMA mode > (=3D=3D) MACH64(0): [drm] Using 2 MB for DMA buffers > (II) MACH64(0): [pci] ring handle =3D 0x64a34000 > (II) MACH64(0): [pci] Ring mapped at 0x2006d4000 > (II) MACH64(0): [drm] register handle =3D 0xfeaff000 > (II) MACH64(0): [dri] Visual configs initialized > (II) MACH64(0): [dri] Block 0 base at 0xfeaff400 > (WW) MACH64(0): Not enough memory for local textures, disabling DRI > (II) MACH64(0): [drm] removed 1 reserved context for kernel > (II) MACH64(0): [drm] unmapping 8192 bytes of SAREA 0xfffffffe40962000 at= 0x2006d2000 > (II) MACH64(0): [drm] Closed DRM master. I'm guessing that this is a pci based card like mine? So, I assume this is the same case as before the updates? robert. >=20 >=20 >=20 >=20 --=-zxcLd3NzslpwgLSevtCf Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEABECAAYFAkjAIIEACgkQM4TrQ4qfROOKxgCeLW3b5P0SOXR4HI41Q3w9bGjh 8P8An0A2dDgQY4tCM8g63iZVjaumXT+A =kUkM -----END PGP SIGNATURE----- --=-zxcLd3NzslpwgLSevtCf-- From owner-freebsd-current@FreeBSD.ORG Thu Sep 4 18:52:06 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 01578106567A; Thu, 4 Sep 2008 18:52:06 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.freebsd.org (Postfix) with ESMTP id B7F988FC1A; Thu, 4 Sep 2008 18:52:05 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.3/8.14.3) with ESMTP id m84Iq5HA002760; Thu, 4 Sep 2008 11:52:05 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.3/8.14.3/Submit) id m84Iq5fw002759; Thu, 4 Sep 2008 11:52:05 -0700 (PDT) (envelope-from sgk) Date: Thu, 4 Sep 2008 11:52:05 -0700 From: Steve Kargl To: Robert Noland Message-ID: <20080904185205.GA2699@troutmask.apl.washington.edu> References: <20080903011612.GA1242@troutmask.apl.washington.edu> <1220416793.1848.1.camel@wombat.2hip.net> <20080903051228.GA2475@troutmask.apl.washington.edu> <1220471512.11763.9.camel@squirrel.corp.cox.com> <20080903195845.GA1370@troutmask.apl.washington.edu> <1220493627.2467.6.camel@wombat.2hip.net> <20080904170208.GA1463@troutmask.apl.washington.edu> <1220550785.54710.33.camel@squirrel.corp.cox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1220550785.54710.33.camel@squirrel.corp.cox.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@FreeBSD.org Subject: Re: drm causes kernel panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2008 18:52:06 -0000 On Thu, Sep 04, 2008 at 01:53:05PM -0400, Robert Noland wrote: > On Thu, 2008-09-04 at 10:02 -0700, Steve Kargl wrote: > > > > Your patch fixes the problem. With a new kernel and Xorg's dri > > module loaded, I now see in /var/log/Xorg.0.log > > > > (II) MACH64(0): [drm] SAREA 2200+1208: 3408 > > drmOpenDevice: node name is /dev/dri/card0 > > drmOpenDevice: open result is 9, (OK) > > drmOpenDevice: node name is /dev/dri/card0 > > drmOpenDevice: open result is 9, (OK) > > drmOpenByBusid: Searching for BusID pci:0000:03:06.0 > > drmOpenDevice: node name is /dev/dri/card0 > > drmOpenDevice: open result is 9, (OK) > > drmOpenByBusid: drmOpenMinor returns 9 > > drmOpenByBusid: drmGetBusid reports pci:0000:03:06.0 > > (II) [drm] DRM interface version 1.2 > > (II) [drm] DRM open master succeeded. > > (II) MACH64(0): [drm] Using the DRM lock SAREA also for drawables. > > (II) MACH64(0): [drm] framebuffer handle = 0xfd000000 > > (II) MACH64(0): [drm] added 1 reserved context for kernel > > (II) MACH64(0): X context handle = 0x1 > > (II) MACH64(0): [drm] installed DRM signal handler > > (II) MACH64(0): [drm] Will request asynchronous DMA mode > > (==) MACH64(0): [drm] Using 2 MB for DMA buffers > > (II) MACH64(0): [pci] ring handle = 0x64a34000 > > (II) MACH64(0): [pci] Ring mapped at 0x2006d4000 > > (II) MACH64(0): [drm] register handle = 0xfeaff000 > > (II) MACH64(0): [dri] Visual configs initialized > > (II) MACH64(0): [dri] Block 0 base at 0xfeaff400 > > (WW) MACH64(0): Not enough memory for local textures, disabling DRI > > (II) MACH64(0): [drm] removed 1 reserved context for kernel > > (II) MACH64(0): [drm] unmapping 8192 bytes of SAREA 0xfffffffe40962000 at 0x2006d2000 > > (II) MACH64(0): [drm] Closed DRM master. > > I'm guessing that this is a pci based card like mine? So, I assume this > is the same case as before the updates? > Yes, it is pci based. It's actually an integrate ATI Rage XL on the Tyan motherboard. I updated my Xorg installation, so the previous behavior isn't relevant. Prior to the Xorg update, Xorg's dri module refused to load because the drm version is 1.2, which was previously unsupported. -- Steve From owner-freebsd-current@FreeBSD.ORG Thu Sep 4 19:28:39 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A85741065674 for ; Thu, 4 Sep 2008 19:28:39 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id 7756F8FC1E for ; Thu, 4 Sep 2008 19:28:38 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from [192.168.166.46] ([68.0.14.34]) (authenticated bits=0) by gizmo.2hip.net (8.13.8/8.13.8) with ESMTP id m84JSZhF045413 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Sep 2008 15:28:36 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Steve Kargl In-Reply-To: <20080904185205.GA2699@troutmask.apl.washington.edu> References: <20080903011612.GA1242@troutmask.apl.washington.edu> <1220416793.1848.1.camel@wombat.2hip.net> <20080903051228.GA2475@troutmask.apl.washington.edu> <1220471512.11763.9.camel@squirrel.corp.cox.com> <20080903195845.GA1370@troutmask.apl.washington.edu> <1220493627.2467.6.camel@wombat.2hip.net> <20080904170208.GA1463@troutmask.apl.washington.edu> <1220550785.54710.33.camel@squirrel.corp.cox.com> <20080904185205.GA2699@troutmask.apl.washington.edu> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-NE/jSCzcGR/H2beSbO7k" Organization: FreeBSD Date: Thu, 04 Sep 2008 15:28:30 -0400 Message-Id: <1220556510.54710.49.camel@squirrel.corp.cox.com> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 FreeBSD GNOME Team Port X-Spam-Status: No, score=-0.9 required=5.0 tests=AWL,BAYES_00, RCVD_IN_SORBS_DUL autolearn=no version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on gizmo.2hip.net Cc: freebsd-current@FreeBSD.org Subject: Re: drm causes kernel panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2008 19:28:39 -0000 --=-NE/jSCzcGR/H2beSbO7k Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2008-09-04 at 11:52 -0700, Steve Kargl wrote: > On Thu, Sep 04, 2008 at 01:53:05PM -0400, Robert Noland wrote: > > On Thu, 2008-09-04 at 10:02 -0700, Steve Kargl wrote: > > >=20 > > > Your patch fixes the problem. With a new kernel and Xorg's dri > > > module loaded, I now see in /var/log/Xorg.0.log > > >=20 > > > (II) MACH64(0): [drm] SAREA 2200+1208: 3408 > > > drmOpenDevice: node name is /dev/dri/card0 > > > drmOpenDevice: open result is 9, (OK) > > > drmOpenDevice: node name is /dev/dri/card0 > > > drmOpenDevice: open result is 9, (OK) > > > drmOpenByBusid: Searching for BusID pci:0000:03:06.0 > > > drmOpenDevice: node name is /dev/dri/card0 > > > drmOpenDevice: open result is 9, (OK) > > > drmOpenByBusid: drmOpenMinor returns 9 > > > drmOpenByBusid: drmGetBusid reports pci:0000:03:06.0 > > > (II) [drm] DRM interface version 1.2 > > > (II) [drm] DRM open master succeeded. > > > (II) MACH64(0): [drm] Using the DRM lock SAREA also for drawables. > > > (II) MACH64(0): [drm] framebuffer handle =3D 0xfd000000 > > > (II) MACH64(0): [drm] added 1 reserved context for kernel > > > (II) MACH64(0): X context handle =3D 0x1 > > > (II) MACH64(0): [drm] installed DRM signal handler > > > (II) MACH64(0): [drm] Will request asynchronous DMA mode > > > (=3D=3D) MACH64(0): [drm] Using 2 MB for DMA buffers > > > (II) MACH64(0): [pci] ring handle =3D 0x64a34000 > > > (II) MACH64(0): [pci] Ring mapped at 0x2006d4000 > > > (II) MACH64(0): [drm] register handle =3D 0xfeaff000 > > > (II) MACH64(0): [dri] Visual configs initialized > > > (II) MACH64(0): [dri] Block 0 base at 0xfeaff400 > > > (WW) MACH64(0): Not enough memory for local textures, disabling DRI > > > (II) MACH64(0): [drm] removed 1 reserved context for kernel > > > (II) MACH64(0): [drm] unmapping 8192 bytes of SAREA 0xfffffffe4096200= 0 at 0x2006d2000 > > > (II) MACH64(0): [drm] Closed DRM master. > >=20 > > I'm guessing that this is a pci based card like mine? So, I assume thi= s > > is the same case as before the updates? > >=20 >=20 > Yes, it is pci based. It's actually an integrate ATI Rage XL on > the Tyan motherboard. I updated my Xorg installation, so the > previous behavior isn't relevant. Prior to the Xorg update,=20 > Xorg's dri module refused to load because the drm version is > 1.2, which was previously unsupported. Ok, I have one system like that. So this seems good on mach64 and intel... Now, if I can just get a report on radeon... robert. >=20 --=-NE/jSCzcGR/H2beSbO7k Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEABECAAYFAkjANt4ACgkQM4TrQ4qfROP6BQCeJdz4+WlKuURExSFBi7aItkLE 84cAn3ND8GEPU22CkpZij3gR34L32SsQ =cagv -----END PGP SIGNATURE----- --=-NE/jSCzcGR/H2beSbO7k-- From owner-freebsd-current@FreeBSD.ORG Thu Sep 4 22:16:20 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4F83D106564A for ; Thu, 4 Sep 2008 22:16:20 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id CF0AA8FC15 for ; Thu, 4 Sep 2008 22:16:19 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from kobe.laptop (athedsl-4457771.home.otenet.gr [79.129.245.27]) (authenticated bits=128) by igloo.linux.gr (8.14.3/8.14.3/Debian-5) with ESMTP id m84MG8Lx010652 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 5 Sep 2008 01:16:14 +0300 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.3/8.14.3) with ESMTP id m84MG3DE002809 for ; Fri, 5 Sep 2008 01:16:03 +0300 (EEST) (envelope-from keramida@freebsd.org) Received: (from keramida@localhost) by kobe.laptop (8.14.3/8.14.3/Submit) id m84MG3C8002808; Fri, 5 Sep 2008 01:16:03 +0300 (EEST) (envelope-from keramida@freebsd.org) From: Giorgos Keramidas To: freebsd-current@freebsd.org Date: Fri, 05 Sep 2008 01:15:56 +0300 Message-ID: <87prnjh80z.fsf@kobe.laptop> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (berkeley-unix) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" X-MailScanner-ID: m84MG8Lx010652 X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-4.399, required 5, autolearn=not spam, ALL_TRUSTED -1.80, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@freebsd.org X-Spam-Status: No Subject: panic in rt_check_fib() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2008 22:16:20 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable A kernel that I built last night to test Ed's "packet mode" for ptys included all the changes up to 182743 panics with: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D root@kobe:/var/crash# kgdb /boot/kernel/kernel vmcore.5 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain condition= s. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"... Unread portion of the kernel message buffer: panic: _mtx_lock_sleep: recursed on non-recursive mutex rtentry @ /home/bui= ld/src/sys/net/route.c:1742 cpuid =3D 0 Uptime: 5m26s Physical memory: 2026 MB Dumping 80 MB: 65 49 33 17 1 Reading symbols from /boot/kernel/snd_hda.ko...Reading symbols from /boot/k= ernel/snd_hda.ko.symbols...done. done. Loaded symbols for /boot/kernel/snd_hda.ko Reading symbols from /boot/kernel/sound.ko...Reading symbols from /boot/ker= nel/sound.ko.symbols...done. done. Loaded symbols for /boot/kernel/sound.ko Reading symbols from /boot/kernel/if_iwn.ko...Reading symbols from /boot/ke= rnel/if_iwn.ko.symbols...done. done. Loaded symbols for /boot/kernel/if_iwn.ko Reading symbols from /boot/kernel/acpi.ko...Reading symbols from /boot/kern= el/acpi.ko.symbols...done. done. Loaded symbols for /boot/kernel/acpi.ko Reading symbols from /boot/kernel/snake_saver.ko...Reading symbols from /bo= ot/kernel/snake_saver.ko.symbols...done. done. Loaded symbols for /boot/kernel/snake_saver.ko #0 doadump () at pcpu.h:221 221 pcpu.h: No such file or directory. in pcpu.h (kgdb) list 216 in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:221 #1 0xc05e13ac in boot (howto=3D260) at /home/build/src/sys/kern/kern_shutd= own.c:418 #2 0xc05e1678 in panic (fmt=3DVariable "fmt" is not available. ) at /home/build/src/sys/kern/kern_shutdown.c:572 #3 0xc05d3fda in _mtx_lock_sleep (m=3D0xc573eba4, tid=3D3314466816, opts= =3D0, file=3D0xc08f457a "/home/build/src/sys/net/route.c", line=3D1742) at = /home/build/src/sys/kern/kern_mutex.c:310 #4 0xc05d422f in _mtx_lock_flags (m=3D0xc573eba4, opts=3D0, file=3D0xc08f4= 57a "/home/build/src/sys/net/route.c", line=3D1742) at /home/build/src/sys/= kern/kern_mutex.c:182 #5 0xc0694ad8 in rt_check_fib (lrt=3D0xe7c299ec, lrt0=3D0xe7c29a08, dst=3D= 0xc5550710, fibnum=3D0) at /home/build/src/sys/net/route.c:1742 #6 0xc06caf36 in in_rt_check (lrt=3D0xe7c299ec, lrt0=3D0xe7c29a08, dst=3D0= xc5550710, fibnum=3D0) at /home/build/src/sys/netinet/in_rmx.c:472 #7 0xc06c0ecd in arpresolve (ifp=3D0xc51fd800, rt0=3D0xc573eca8, m=3D0xc59= c2200, dst=3D0xc5550710, desten=3D0xe7c29a22 "") at /home/build/src/sys/net= inet/if_ether.c:388 #8 0xc0689a9e in ether_output (ifp=3D0xc51fd800, m=3D0xc59c2200, dst=3D0xc= 5550710, rt0=3D0xc573eca8) at /home/build/src/sys/net/if_ethersubr.c:183 #9 0xc06d1bf1 in ip_output (m=3D0xc59c2200, opt=3D0x0, ro=3D0xe7c29aa8, fl= ags=3DVariable "flags" is not available. ) at /home/build/src/sys/netinet/ip_output.c:563 #10 0xc073ecfb in udp_send (so=3D0xc573b498, flags=3D0, m=3D0xc59c2200, add= r=3D0xc597e2f0, control=3D0x0, td=3D0xc58ec000) at /home/build/src/sys/neti= net/udp_usrreq.c:1060 #11 0xc064530f in sosend_dgram (so=3D0xc573b498, addr=3D0xc597e2f0, uio=3D0= xe7c29bd4, top=3D0xc59c2200, control=3D0x0, flags=3DVariable "flags" is not= available. ) at /home/build/src/sys/kern/uipc_socket.c:1059 #12 0xc0643054 in sosend (so=3D0xc573b498, addr=3D0xc597e2f0, uio=3D0xe7c29= bd4, top=3D0x0, control=3D0x0, flags=3D0, td=3D0xc58ec000) at /home/build/s= rc/sys/kern/uipc_socket.c:1292 #13 0xc064bf15 in kern_sendit (td=3D0xc58ec000, s=3D516, mp=3D0xe7c29c54, f= lags=3D0, control=3D0x0, segflg=3DUIO_USERSPACE) at /home/build/src/sys/ker= n/uipc_syscalls.c:782 #14 0xc064c121 in sendit (td=3D0xc58ec000, s=3D516, mp=3D0xe7c29c54, flags= =3D0) at /home/build/src/sys/kern/uipc_syscalls.c:719 #15 0xc064c1d1 in sendmsg (td=3D0xc58ec000, uap=3D0xe7c29cf8) at /home/buil= d/src/sys/kern/uipc_syscalls.c:915 #16 0xc0884d13 in syscall (frame=3D0xe7c29d38) at /home/build/src/sys/i386/= i386/trap.c:1090 #17 0xc0869020 in Xint0x80_syscall () at /home/build/src/sys/i386/i386/exce= ption.s:261 #18 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From=20the limited testing I could do today it seems that the following changes might be useful to track down why this is happening: /head@182698 -> ok so far /head@182743 -> panic I don't see any rt_check_fib() changes in this commit range, so it may be false that /head@182698 is ok. It just doesn't panic immediately when I try to bring up my re0 interface and set the default route. =2D Giorgos --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkjAXiIACgkQ1g+UGjGGA7ZGYwCgvZiUKcB4FfDjCJdTjJE3VztP Eu8AniQOMV5JqMwoiXX1rrrK2+KpmRYP =5C43 -----END PGP SIGNATURE----- --=-=-=-- From owner-freebsd-current@FreeBSD.ORG Thu Sep 4 23:38:39 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B7603106567B for ; Thu, 4 Sep 2008 23:38:39 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from ik-out-1112.google.com (ik-out-1112.google.com [66.249.90.183]) by mx1.freebsd.org (Postfix) with ESMTP id 3D4CE8FC34 for ; Thu, 4 Sep 2008 23:38:38 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by ik-out-1112.google.com with SMTP id c30so150450ika.3 for ; Thu, 04 Sep 2008 16:38:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; 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; bh=/T6XhfJ9+4e8bOT7+NK/XCUqys+UmWEvyf3lg9AB8V0=; b=xSpqW46pjPldZrw8h0j8xO8rhfNl/ZabEP9jQ7qv8OjVBSdNRzOCu5QAjzxGXzV9vL KEdyW5p63Zf3Pu+mluN2TFv+oxif6NxbR25HfxVs0pg0/5BliXr7ZhL2bPtKcPw0h69u FqQPITFeuCZwCeEuT3KcmnXL8mllPaO9i1l1k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=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=FgpTFFyet4+HK0B5b6FODyD30VD3o5ClMybkT3bwc0Wx+2tUR+15vvW6ycNDJabCp0 L5qs4eS1RyO7o6hB4BfOo3JZQRh8GS1nkCUMcu358bvLQecT5zc/pHLlxAVcWTBQy3iV QU4JASRDnF2SjyMyV9F7LRBd1xPa9yhDboaz4= Received: by 10.102.253.13 with SMTP id a13mr7405969mui.74.1220571517597; Thu, 04 Sep 2008 16:38:37 -0700 (PDT) Received: by 10.103.239.14 with HTTP; Thu, 4 Sep 2008 16:38:37 -0700 (PDT) Message-ID: <3bbf2fe10809041638l52e73516r2cd11ce3eb8366c@mail.gmail.com> Date: Fri, 5 Sep 2008 01:38:37 +0200 From: "Attilio Rao" Sender: asmrookie@gmail.com To: "John Baldwin" In-Reply-To: <200809021608.57542.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200808230003.44081.jhb@freebsd.org> <48B6BC81.5060300@clearchain.com> <20080901.013117.74700691.Tor.Egge@cvsup.no.freebsd.org> <200809021608.57542.jhb@freebsd.org> X-Google-Sender-Auth: 3861be1d62fddda3 Cc: kevinxlinuz@163.com, freebsd-current@freebsd.org, Benjamin.Close@clearchain.com, kib@freebsd.org Subject: Re: [BUG] I think sleepqueue need to be protected in sleepq_broadcast X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2008 23:38:39 -0000 2008/9/2, John Baldwin : > On Sunday 31 August 2008 09:31:17 pm Tor Egge wrote: > > > > > sleepq_resume_thread() contains an ownership handover of sq if the resumed > > thread is the last one blocked on the wait channel. After the handover, sq > is > > no longer protected by the sleep queue chain lock and should no longer be > > accessed by sleepq_broadcast(). > > > > Normally, when sleepq_broadcast() incorrectly accesses sq after the > handover, > > it will find the sq->sq_blocked queue to be empty, and the code appears to > > work. > > > > If the last correctly woken thread manages to go to sleep again very quickly > on > > another wait channel, sleepq_broadcast() might incorrectly determine that > the > > sq->sq_blocked queue isn't empty, and start doing the wrong thing. > > > So disregard my earlier e-mail. Here is a simple fix for the sleepq case: > > Index: subr_sleepqueue.c > =================================================================== > --- subr_sleepqueue.c (revision 182679) > +++ subr_sleepqueue.c (working copy) > @@ -779,7 +779,7 @@ > > sleepq_broadcast(void *wchan, int flags, int pri, int queue) > { > struct sleepqueue *sq; > - struct thread *td; > > + struct thread *td, *tdn; > > int wakeup_swapper; > > CTR2(KTR_PROC, "sleepq_broadcast(%p, %d)", wchan, flags); > > @@ -793,8 +793,7 @@ > > > /* Resume all blocked threads on the sleep queue. */ > wakeup_swapper = 0; > - while (!TAILQ_EMPTY(&sq->sq_blocked[queue])) { > - td = TAILQ_FIRST(&sq->sq_blocked[queue]); > > + TAILQ_FOREACH_SAFE(td, &sq->sq_blocked[queue], td_slpq, tdn) { > thread_lock(td); > > if (sleepq_resume_thread(sq, td, pri)) > wakeup_swapper = 1; > > > This only uses 'sq' to fetch the head of the queue once up front. It won't > use it again once it has started waking up threads. > > > > A similar (but probably much more difficult to trigger) issue is present > with > > regards to thread_lock() and turnstiles. > > > > The caller of thread_lock() might have performed sufficient locking to > ensure > > that the thread to be locked doesn't go away, but any turnstile spin lock > > pointed to by td->td_lock isn't protected. Making turnstiles type stable > > (setting UMA_ZONE_NOFREE flag for turnstile_zone) should fix that issue. > > > Note that unlike the sleepq case, turnstiles are not made runnable until all > of them are dequeued from the turnstile and assigned a new turnstile. Only > after all that is settled are the threads made runnable in turnstile_unpend(). > > However, that doesn't fix this specific race (though it means the turnstile > code is not subject to the same exact race as the sleepq code above). Making > turnstiles type-stable is indeed probably the only fix for this. :-/ What about setting a flag meaning "turnstile recycled but still used" and allow turnstile_wait() to spin until it gets unset before to access to td_turnstile? Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Fri Sep 5 02:45:06 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BF934106564A for ; Fri, 5 Sep 2008 02:45:06 +0000 (UTC) (envelope-from rmtodd@ichotolot.servalan.com) Received: from mx1.synetsystems.com (mx1.synetsystems.com [76.10.206.14]) by mx1.freebsd.org (Postfix) with ESMTP id 97AF78FC16 for ; Fri, 5 Sep 2008 02:45:06 +0000 (UTC) (envelope-from rmtodd@ichotolot.servalan.com) Received: by mx1.synetsystems.com (Postfix, from userid 66) id 1035CC6C; Thu, 4 Sep 2008 22:45:06 -0400 (EDT) Received: from rmtodd by servalan.servalan.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1KbRGa-0003rt-Hv; Thu, 04 Sep 2008 21:41:44 -0500 To: Rink Springer , freebsd-current@freebsd.org References: <20080903034943.GD11548@cicely7.cicely.de> <20080903161916.GC95039@rink.nu> From: Richard Todd Date: Wed, 03 Sep 2008 22:00:25 -0500 In-Reply-To: (Rink Springer's message of "Wed, 3 Sep 2008 18:19:16 +0200") Message-ID: User-Agent: Gnus/5.1008 (Gnus v5.10.8) XEmacs/21.4.21 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Subject: Re: MTRR fixup? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2008 02:45:06 -0000 Rink Springer writes: > Hi Bernd, > > On Wed, Sep 03, 2008 at 05:49:44AM +0200, Bernd Walter wrote: >> Some boards (including my Intel DG33BU) seem to have problems setting >> up the mtrr to cache all RAM. >> My system runs fast with 2G and ist about 6 times slower in buildworld >> with 6G RAM. >> I will try a BIOS update once Intels tells me why their update ISO >> just turn the system off instead of updating the BIOS - sigh. >> But it seems that Linux is doing some kind of fixup for MTRR: >> http://lkml.org/lkml/2008/1/18/170 >> Can we do something similar? > > This is interesting, my motherboard (Intel DP965LT) seems to suffer from > the same problem: putting 4GB of memory in it makes it dog slow, while > putting 2GB in it makes it lightning fast... > > I've just given up trying to put 4GB of memory in this machine, but I > believe this may help... Yes, several Intel 965-based boards, including the DP965LT (which I have) suffer from this problem. See, e.g., http://article.gmane.org/gmane.os.freebsd.stable/50135/match=dp965lt and the link therein. > Please, keep me posted if the BIOS update fixes it for you. I honestly haven't checked recently to see if there are recent BIOS upgrades that fixed the problem; at the time I was messing with this last year, I found that the BIOS upgrade their site claimed fixed the problem of "slowness in machines with 4G or more RAM" did not in fact do so. However, as someone else on this thread pointed out, you can fix the bogus MTRR entry with memcontrol, so I just stuck the appropriate script in /etc/rc.d to solve the problem. From owner-freebsd-current@FreeBSD.ORG Fri Sep 5 04:29:32 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7CC561065670 for ; Fri, 5 Sep 2008 04:29:32 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.delphij.net (unknown [IPv6:2001:470:1f03:2c9::2]) by mx1.freebsd.org (Postfix) with ESMTP id 28AD78FC16 for ; Fri, 5 Sep 2008 04:29:32 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [211.166.10.233]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.delphij.net (Postfix) with ESMTPS id 11BAF28448 for ; Fri, 5 Sep 2008 12:29:31 +0800 (CST) Received: from localhost (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id 881B7F62FF2; Fri, 5 Sep 2008 12:29:30 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by localhost (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with ESMTP id ALWwjuIOG-1A; Fri, 5 Sep 2008 12:29:25 +0800 (CST) Received: from charlie.delphij.net (71.5.7.139.ptr.us.xo.net [71.5.7.139]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id 5EDFCF62F86; Fri, 5 Sep 2008 12:29:23 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:subject:x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=hOH9SK18wScx3X8tNypC5hBLMK37GlNnXKBBr0H0IYvbrsnJ7z2JbOw12yoLc2552 z40TXM4sIysXNX/CEEITQ== Message-ID: <48C0B59F.4030200@delphij.net> Date: Thu, 04 Sep 2008 21:29:19 -0700 From: Xin LI Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.16 (X11/20080725) MIME-Version: 1.0 To: FreeBSD Current X-Enigmail-Version: 0.95.7 OpenPGP: id=18EDEBA0; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: panic on shutdown anyone (insmntque())? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2008 04:29:32 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Anyone get panic (kernel trap 12) near insmntque() during the last stage of shutdown? It seems to be 100% reproducible with INVARIANTS/WITNESS - -CURRENT kernel and seems to be a regression introduced during the past week. Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkjAtZ8ACgkQi+vbBBjt66BtFwCfWsfNZF+09gY4gQOr22DmfCTE 0BgAn1gQVWOWWM5bl19tRqpwBTO5YSzW =4p9u -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Fri Sep 5 04:37:22 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 756D81065672 for ; Fri, 5 Sep 2008 04:37:22 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id AE5C78FC1E; Fri, 5 Sep 2008 04:37:21 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <48C0B781.40200@FreeBSD.org> Date: Fri, 05 Sep 2008 14:07:21 +0930 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: d@delphij.net References: <48C0B59F.4030200@delphij.net> In-Reply-To: <48C0B59F.4030200@delphij.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: panic on shutdown anyone (insmntque())? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2008 04:37:22 -0000 Xin LI wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > Anyone get panic (kernel trap 12) near insmntque() during the last stage > of shutdown? It seems to be 100% reproducible with INVARIANTS/WITNESS > - -CURRENT kernel and seems to be a regression introduced during the past > week. Are you using ZFS? Kris From owner-freebsd-current@FreeBSD.ORG Fri Sep 5 04:39:12 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 776311065671; Fri, 5 Sep 2008 04:39:12 +0000 (UTC) (envelope-from fbsd-current@mawer.org) Received: from outbound.icp-qv1-irony-out3.iinet.net.au (outbound.icp-qv1-irony-out3.iinet.net.au [203.59.1.148]) by mx1.freebsd.org (Postfix) with ESMTP id AED1F8FC20; Fri, 5 Sep 2008 04:39:11 +0000 (UTC) (envelope-from fbsd-current@mawer.org) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AocBALtNwEjLzq3r/2dsb2JhbAAIsBaHCoFl X-IronPort-AV: E=Sophos;i="4.32,320,1217779200"; d="scan'208";a="312201650" Received: from unknown (HELO [10.24.1.1]) ([203.206.173.235]) by outbound.icp-qv1-irony-out3.iinet.net.au with ESMTP; 05 Sep 2008 12:09:36 +0800 Message-ID: <48C0B06A.5090904@mawer.org> Date: Fri, 05 Sep 2008 14:07:06 +1000 From: Antony Mawer User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: gavin@freebsd.org Subject: Panic on boot on Lenovo ThinkCentre, before copyright message appears X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2008 04:39:12 -0000 I've been having trouble getting 6.x, 7.x and 8.0 to boot on a Lenovo ThinkCentre M-series, model 6081 AG1. The system panics on boot, what seems to be as soon as it goes to boot the kernel (it loads the kernel and modules like acpi.ko fine)... System is running the latest BIOS (2KRT50AUS) from 22 July 2008; we have successfully booted Windows and Linux on the same system, and it has survived several hours of memtest'ing. The panic (manually transcribed, so I hope I haven't made any typos) as seen from the 200807/i386 snapshot CD: /boot/kernel/acpi.ko text=0x54624 data=0x2640+0x182c syms=0x4+0x8b70+0x4+0xbe09] GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fatal virtual address = 0xf000ff53 fault code = supervisor read, page not present instruction pointer = 0x20:0xf000ff53 stack pointer = 0x28:0xc1421f0c frame pointer = 0x28:0xc1421f9c code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 0 () [thread pid 0 tid 0 ] Stopped at 0xf000ff53: *** error reading from address f000ff53 *** db> bt Tracing pid 0 tid 0 td 0xc0c837c0 trap(c1421fa8) at trap+0x66f calltrap() at calltrap+0x6 --- trap 0x9, eip = 0x3fbb, esp = 0xfd2, ebp = 0 --- db> sh reg cs 0x20 ds 0x28 es 0x28 fs 0x8 ss 0x28 eax 0xf000ff53 ecx 0x9 edx 0xa ebx 0x9 esp 0xc1421f0c ebp 0xc1421f9c esi 0xc1421fa8 edi 0xc0c837c0 thread0 eip 0xf000ff53 efl 0x10286 0xf000ff53: *** error reading from address f000ff53 *** db> Is there any additional information I can provide from the DDB prompt that may help tracking down why this machine is unable to boot (I have included the output from backtrace above, but it does not appear to help much...)? Cheers Antony From owner-freebsd-current@FreeBSD.ORG Fri Sep 5 04:52:54 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7834A106566C; Fri, 5 Sep 2008 04:52:54 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.delphij.net (unknown [IPv6:2001:470:1f03:2c9::2]) by mx1.freebsd.org (Postfix) with ESMTP id 6487B8FC13; Fri, 5 Sep 2008 04:52:53 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [211.166.10.233]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.delphij.net (Postfix) with ESMTPS id 21B052844E; Fri, 5 Sep 2008 12:52:52 +0800 (CST) Received: from localhost (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id C9E74F63006; Fri, 5 Sep 2008 12:52:51 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by localhost (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with ESMTP id wbVKg2XRrfGY; Fri, 5 Sep 2008 12:52:47 +0800 (CST) Received: from charlie.delphij.net (71.5.7.139.ptr.us.xo.net [71.5.7.139]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id BE6F1EC45D5; Fri, 5 Sep 2008 12:52:45 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=aqLivX7F2jJh9EEnp3XbJN3mtO8Q8RiUcZ8+CJClYZYZZMFeiaNISk4v/oykIaliq EFyyomb6bP8AvuQHOGjTA== Message-ID: <48C0BB1A.4020906@delphij.net> Date: Thu, 04 Sep 2008 21:52:42 -0700 From: Xin LI Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.16 (X11/20080725) MIME-Version: 1.0 To: Kris Kennaway References: <48C0B59F.4030200@delphij.net> <48C0B781.40200@FreeBSD.org> In-Reply-To: <48C0B781.40200@FreeBSD.org> X-Enigmail-Version: 0.95.7 OpenPGP: id=18EDEBA0; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Current , d@delphij.net Subject: Re: panic on shutdown anyone (insmntque())? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2008 04:52:54 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Kris Kennaway wrote: > Xin LI wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Hi, >> >> Anyone get panic (kernel trap 12) near insmntque() during the last stage >> of shutdown? It seems to be 100% reproducible with INVARIANTS/WITNESS >> - -CURRENT kernel and seems to be a regression introduced during the past >> week. > > Are you using ZFS? Yes, ZFS as root... Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkjAuxoACgkQi+vbBBjt66CFowCff5Lu3O7Oa7Z1I2AsEal25ttU hzMAoIVUymDM73YDO8anmL18G4k+Oyxy =vTlF -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Fri Sep 5 04:58:41 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2C6A61065674; Fri, 5 Sep 2008 04:58:41 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 1809B8FC1C; Fri, 5 Sep 2008 04:58:39 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <48C0BC80.3000107@FreeBSD.org> Date: Fri, 05 Sep 2008 14:28:40 +0930 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: d@delphij.net References: <48C0B59F.4030200@delphij.net> <48C0B781.40200@FreeBSD.org> <48C0BB1A.4020906@delphij.net> In-Reply-To: <48C0BB1A.4020906@delphij.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current , Pawel Jakub Dawidek Subject: Re: panic on shutdown anyone (insmntque())? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2008 04:58:41 -0000 Xin LI wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Kris Kennaway wrote: >> Xin LI wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> Hi, >>> >>> Anyone get panic (kernel trap 12) near insmntque() during the last stage >>> of shutdown? It seems to be 100% reproducible with INVARIANTS/WITNESS >>> - -CURRENT kernel and seems to be a regression introduced during the past >>> week. >> Are you using ZFS? > > Yes, ZFS as root... pjd has a fix in his p4 branch. Kris From owner-freebsd-current@FreeBSD.ORG Fri Sep 5 05:36:43 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E35681065683 for ; Fri, 5 Sep 2008 05:36:43 +0000 (UTC) (envelope-from thierry@herbelot.com) Received: from postfix2-g20.free.fr (postfix2-g20.free.fr [212.27.60.43]) by mx1.freebsd.org (Postfix) with ESMTP id B101B8FC12 for ; Fri, 5 Sep 2008 05:36:41 +0000 (UTC) (envelope-from thierry@herbelot.com) Received: from smtp4-g19.free.fr (smtp4-g19.free.fr [212.27.42.30]) by postfix2-g20.free.fr (Postfix) with ESMTP id 1FE8229D1A76 for ; Fri, 5 Sep 2008 05:05:55 +0200 (CEST) Received: from smtp4-g19.free.fr (localhost.localdomain [127.0.0.1]) by smtp4-g19.free.fr (Postfix) with ESMTP id D96453EA0E2 for ; Fri, 5 Sep 2008 07:06:11 +0200 (CEST) Received: from mail.herbelot.nom (bne75-4-82-227-159-103.fbx.proxad.net [82.227.159.103]) by smtp4-g19.free.fr (Postfix) with ESMTP id 1AAD43EA0DF for ; Fri, 5 Sep 2008 07:06:10 +0200 (CEST) Received: from diversion.herbelot.nom (diversion.herbelot.nom [192.168.2.6]) by mail.herbelot.nom (8.14.1/8.14.1) with ESMTP id m85569LM015526 for ; Fri, 5 Sep 2008 07:06:09 +0200 (CEST) From: Thierry Herbelot To: FreeBSD Current Date: Fri, 5 Sep 2008 07:06:01 +0200 User-Agent: KMail/1.9.10 X-Warning: Windows can lose your files X-Op-Sys: Le FriBi de la mort qui tue X-Org: TfH&Co X-MailScanner: Found to be clean MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200809050706.01747.thierry@herbelot.com> Subject: (another) panic on shutdown (spin lock held too long) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: thierry@herbelot.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2008 05:36:44 -0000 Hello, I was just rebooting a recent SMP -current machine, running a straight GENERIC kernel, with only / mounted read-only, and I got the following panic : TfH # mount /dev/mirror/gm0a on / (ufs, local, read-only) devfs on /dev (devfs, local) # reboot Waiting (max 60 seconds) for system process `vnlru' to stop...done Waiting (max 60 seconds) for system process `bufdaemon' to stop...done Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining...0 0 0 0 0 0 0 0 0 done All buffers synced. Uptime: 11m36s GEOM_MIRROR: Device gm0: provider mirror/gm0 destroyed. Rebooting... cpu_reset: Stopping other CPUs spin lock 0xc0cb4e00 (sched lock 1) held by 0xc2cc2d20 (tid 100002) too long panic: spin lock held too long cpuid = 0 KDB: enter: panic [thread pid 34 tid 100056 ] Stopped at kdb_enter+0x3a: movl $0,kdb_why db> where Tracing pid 34 tid 100056 td 0xc2fbe000 kdb_enter(c0b6aaea,c0b6aaea,c0b697e9,e011ca58,0,...) at kdb_enter+0x3a panic(c0b697e9,c2cc2d20,c0cb5448,c2cc2d20,186a2,...) at panic+0x12c _mtx_lock_spin_failed(1,c2fbe000,c0cb4e00,10,e011cab0,...) at _mtx_lock_spin_failed+0x51 _mtx_lock_spin(c0cb4e00,c2fbe000,10,c0b6c6e7,316,...) at _mtx_lock_spin+0x75 _mtx_lock_spin_flags(c0cb4e00,10,c0b6c6e7,316,c0cbc760,...) at _mtx_lock_spin_flags+0x13e tdq_lock_pair(c0cbc760,e011cafc,e011cb0c,c0cbc760,ffffffff,...) at tdq_lock_pair+0x54 sched_balance_group(c0cb4780,0,c0b6c6e7,309,0,...) at sched_balance_group+0xba sched_balance(c0cb4780,4,c0b6c6e7,839,0,...) at sched_balance+0x8a sched_clock(c2fbe000,2,c0b65818,1f7,c0e31320,...) at sched_clock+0x6b statclock(0,c0acc759,0,40,49e57b9c,...) at statclock+0x11e lapic_handle_timer(e011cbb0) at lapic_handle_timer+0x101 Xtimerint() at Xtimerint+0x1f --- interrupt, eip = 0xc0acc75b, esp = 0xe011cbf0, ebp = 0xe011cc0c --- DELAY(f4240,0,c2ca9960,e011cc2c,c07b2ab3,...) at DELAY+0x8b cpu_reset(f4240,e011cc68,c07b358f,0,0,...) at cpu_reset+0xd5 shutdown_reset(0,0,c0b6a99c,1a5,0,...) at shutdown_reset+0x23 boot(c0cb0630,0,c0b6a99c,ab,e011cd2c,...) at boot+0x75f reboot(c2fbe000,e011ccf8,4,c0b71f60,c0c40d48,...) at reboot+0x4b syscall(e011cd38) at syscall+0x2a3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (55, FreeBSD ELF32, reboot), eip = 0x280be56b, esp = 0xbfbfee1c, ebp = 0xbfbfee58 --- db> show locks; exclusive sleep mutex Giant (Giant) r = 0 (0xc0cb0630) locked @ /tank/files1/src/sys/kern/kern_module.c:102 db> show alllocks; Process 34 (reboot) thread 0xc2fbe000 (100056) exclusive sleep mutex Giant (Giant) r = 0 (0xc0cb0630) locked @ /tank/files1/src/sys/kern/kern_module.c:102 Process 26 (softdepflush) thread 0xc2deeaf0 (100048) Process 25 (vnlru) thread 0xc2deed20 (100047) Process 24 (syncer) thread 0xc2e4a000 (100046) Process 23 (bufdaemon) thread 0xc2e4a230 (100045) Process 22 (pagezero) thread 0xc2e4a460 (100044) Process 21 (vmdaemon) thread 0xc2e4a690 (100043) Process 9 (pagedaemon) thread 0xc2e4a8c0 (100042) Process 7 (sctp_iterator) thread 0xc2e4ad20 (100040) Process 6 (fdc0) thread 0xc2ded230 (100036) Process 20 (usb4) thread 0xc2ded8c0 (100033) Process 19 (usb3) thread 0xc2dedd20 (100031) Process 18 (usb2) thread 0xc2dee230 (100029) Process 17 (usb1) thread 0xc2d07690 (100027) Process 16 (usbtask-dr) thread 0xc2d078c0 (100026) Process 15 (usbtask-hc) thread 0xc2d07af0 (100025) Process 14 (usb0) thread 0xc2d07d20 (100024) Process 5 (xpt_thrd) thread 0xc2dc4af0 (100018) Process 13 (yarrow) thread 0xc2cc4af0 (100013) Process 4 (g_down) thread 0xc2cc4d20 (100012) Process 3 (g_up) thread 0xc2d07000 (100011) Process 2 (g_event) thread 0xc2d07230 (100010) exclusive sx gmirror:lock (gmirror:lock) r = 0 (0xc2e4762c) locked @ /tank/files1/src/sys/modules/geom/geom_mirror/../../../geom/mirror/g_mirror.c:2977 Process 12 (swi0: uart uart) thread 0xc2dc4d20 (100038) Process 12 (irq15: ata1) thread 0xc2dc4230 (100022) Process 12 (irq14: ata0) thread 0xc2dc4460 (100021) Process 12 (swi6: task queue) thread 0xc2cc4460 (100016) Process 12 (swi4: clock) thread 0xc2cc2690 (100005) Process 1 (init) thread 0xc2cc2d20 (100002) exclusive sleep mutex process lock (process lock) r = 0 (0xc2cc0d94) locked @ /tank/files1/src/sys/kern/kern_sig.c:1831 Process 10 (audit) thread 0xc2cc4000 (100001) Process 0 (kqueue taskq) thread 0xc2cc4230 (100017) Process 0 (thread taskq) thread 0xc2cc48c0 (100014) Process 0 (firmware taskq) thread 0xc2d07460 (100009) Process 0 (swapper) thread 0xc0caed20 (100000) db> show lockedvnods Locked vnodes db> bt Tracing pid 34 tid 100056 td 0xc2fbe000 kdb_enter(c0b6aaea,c0b6aaea,c0b697e9,e011ca58,0,...) at kdb_enter+0x3a panic(c0b697e9,c2cc2d20,c0cb5448,c2cc2d20,186a2,...) at panic+0x12c _mtx_lock_spin_failed(1,c2fbe000,c0cb4e00,10,e011cab0,...) at _mtx_lock_spin_failed+0x51 _mtx_lock_spin(c0cb4e00,c2fbe000,10,c0b6c6e7,316,...) at _mtx_lock_spin+0x75 _mtx_lock_spin_flags(c0cb4e00,10,c0b6c6e7,316,c0cbc760,...) at _mtx_lock_spin_flags+0x13e tdq_lock_pair(c0cbc760,e011cafc,e011cb0c,c0cbc760,ffffffff,...) at tdq_lock_pair+0x54 sched_balance_group(c0cb4780,0,c0b6c6e7,309,0,...) at sched_balance_group+0xba sched_balance(c0cb4780,4,c0b6c6e7,839,0,...) at sched_balance+0x8a sched_clock(c2fbe000,2,c0b65818,1f7,c0e31320,...) at sched_clock+0x6b statclock(0,c0acc759,0,40,49e57b9c,...) at statclock+0x11e lapic_handle_timer(e011cbb0) at lapic_handle_timer+0x101 Xtimerint() at Xtimerint+0x1f --- interrupt, eip = 0xc0acc75b, esp = 0xe011cbf0, ebp = 0xe011cc0c --- DELAY(f4240,0,c2ca9960,e011cc2c,c07b2ab3,...) at DELAY+0x8b cpu_reset(f4240,e011cc68,c07b358f,0,0,...) at cpu_reset+0xd5 shutdown_reset(0,0,c0b6a99c,1a5,0,...) at shutdown_reset+0x23 boot(c0cb0630,0,c0b6a99c,ab,e011cd2c,...) at boot+0x75f reboot(c2fbe000,e011ccf8,4,c0b71f60,c0c40d48,...) at reboot+0x4b syscall(e011cd38) at syscall+0x2a3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (55, FreeBSD ELF32, reboot), eip = 0x280be56b, esp = 0xbfbfee1c, ebp = 0xbfbfee58 --- db> ps pid ppid pgrp uid state wmesg wchan cmd 34 1 34 0 R+ CPU 0 reboot 26 0 0 0 SL sdflush 0xc0e224e0 [softdepflush] 25 0 0 0 SL kpsusp 0xc2f21874 [vnlru] 24 0 0 0 SL kpsusp 0xc2d39874 [syncer] 23 0 0 0 SL kpsusp 0xc2d39b10 [bufdaemon] 22 0 0 0 SL pgzero 0xc0e230d4 [pagezero] 21 0 0 0 SL psleep 0xc0e22cfc [vmdaemon] 9 0 0 0 SL psleep 0xc0e22cc4 [pagedaemon] 7 0 0 0 SL waiting_ 0xc0e18280 [sctp_iterator] 6 0 0 0 SL - 0xc2dff23c [fdc0] 20 0 0 0 SL usbevt 0xc2dbf210 [usb4] 19 0 0 0 SL usbevt 0xc2df9210 [usb3] 18 0 0 0 SL usbevt 0xc2de0210 [usb2] 17 0 0 0 SL usbevt 0xc2de2210 [usb1] 16 0 0 0 SL usbtsk 0xc0cae294 [usbtask-dr] 15 0 0 0 SL usbtsk 0xc0cae280 [usbtask-hc] 14 0 0 0 SL usbevt 0xc2dd1210 [usb0] 5 0 0 0 SL ccb_scan 0xc0c7e054 [xpt_thrd] 13 0 0 0 SL - 0xc0cb0bc4 [yarrow] 4 0 0 0 RL [g_down] 3 0 0 0 SL - 0xc0cae9c0 [g_up] 2 0 0 0 RL [g_event] 12 0 0 0 LL (threaded) intr 100039 I [irq5: pcm1] 100038 I [swi0: uart uart] 100037 I [irq7: ppbus0 ppc0] 100035 I [irq12: psm0] 100034 I [irq1: atkbd0] 100032 I [irq18: ehci0++] 100030 I [irq17: ohci2] 100028 I [irq16: ohci1] 100023 I [irq19: pcm0 dc0++] 100022 I [irq15: ata1] 100021 I [irq14: ata0] 100020 I [swi5: +] 100019 I [swi2: cambio] 100016 I [swi6: task queue] 100015 I [swi6: Giant taskq] 100008 I [swi3: vm] 100007 I [swi1: net] 100006 I [swi4: clock] 100005 L *Giant 0xc2c8b2d0 [swi4: clock] 11 0 0 0 RL (threaded) idle 100004 CanRun [idle: cpu0] 100003 CanRun [idle: cpu1] 1 0 1 0 RLs CPU 1 [init] 10 0 0 0 SL audit_wo 0xc0e21ee0 [audit] 0 0 0 0 SLs (threaded) kernel 100017 D - 0xc2db1140 [kqueue taskq] 100014 D - 0xc2db1280 [thread taskq] 100009 D - 0xc2ca2700 [firmware taskq] 100000 D sched 0xc0caea80 [swapper] db> alltrace Tracing command reboot pid 34 tid 100056 td 0xc2fbe000 kdb_enter(c0b6aaea,c0b6aaea,c0b697e9,e011ca58,0,...) at kdb_enter+0x3a panic(c0b697e9,c2cc2d20,c0cb5448,c2cc2d20,186a2,...) at panic+0x12c _mtx_lock_spin_failed(1,c2fbe000,c0cb4e00,10,e011cab0,...) at _mtx_lock_spin_failed+0x51 _mtx_lock_spin(c0cb4e00,c2fbe000,10,c0b6c6e7,316,...) at _mtx_lock_spin+0x75 _mtx_lock_spin_flags(c0cb4e00,10,c0b6c6e7,316,c0cbc760,...) at _mtx_lock_spin_flags+0x13e tdq_lock_pair(c0cbc760,e011cafc,e011cb0c,c0cbc760,ffffffff,...) at tdq_lock_pair+0x54 sched_balance_group(c0cb4780,0,c0b6c6e7,309,0,...) at sched_balance_group+0xba sched_balance(c0cb4780,4,c0b6c6e7,839,0,...) at sched_balance+0x8a sched_clock(c2fbe000,2,c0b65818,1f7,c0e31320,...) at sched_clock+0x6b statclock(0,c0acc759,0,40,49e57b9c,...) at statclock+0x11e lapic_handle_timer(e011cbb0) at lapic_handle_timer+0x101 Xtimerint() at Xtimerint+0x1f --- interrupt, eip = 0xc0acc75b, esp = 0xe011cbf0, ebp = 0xe011cc0c --- DELAY(f4240,0,c2ca9960,e011cc2c,c07b2ab3,...) at DELAY+0x8b cpu_reset(f4240,e011cc68,c07b358f,0,0,...) at cpu_reset+0xd5 shutdown_reset(0,0,c0b6a99c,1a5,0,...) at shutdown_reset+0x23 boot(c0cb0630,0,c0b6a99c,ab,e011cd2c,...) at boot+0x75f reboot(c2fbe000,e011ccf8,4,c0b71f60,c0c40d48,...) at reboot+0x4b syscall(e011cd38) at syscall+0x2a3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (55, FreeBSD ELF32, reboot), eip = 0x280be56b, esp = 0xbfbfee1c, ebp = 0xbfbfee58 --- Tracing command softdepflush pid 26 tid 100048 td 0xc2deeaf0 sched_switch(c2deeaf0,0,104,17e,1fffe200,...) at sched_switch+0x437 mi_switch(104,0,c0b6ec3d,1d2,44,...) at mi_switch+0x200 sleepq_switch(c2deeaf0,0,c0b6ec3d,26a,0,...) at sleepq_switch+0x15f sleepq_timedwait(c0e224e0,44,c0b8db18,0,0,...) at sleepq_timedwait+0x6b _sleep(c0e224e0,c0e22484,44,c0b8db18,3e8,...) at _sleep+0x2f9 softdep_flush(0,df41ad38,c0b66eb8,322,c2f21538,...) at softdep_flush+0x2b5 fork_exit(c09b0a60,0,df41ad38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xdf41ad70, ebp = 0 --- Tracing command vnlru pid 25 tid 100047 td 0xc2deed20 sched_switch(c2deed20,0,104,17e,7217c14a,...) at sched_switch+0x437 mi_switch(104,0,c0b6ec3d,1d2,68,...) at mi_switch+0x200 sleepq_switch(c2deed20,0,c0b6ec3d,247,0,...) at sleepq_switch+0x15f sleepq_wait(c2f21874,68,c0b676c7,0,0,...) at sleepq_wait+0x63 _sleep(c2f21874,c2f2185c,68,c0b676c7,0,...) at _sleep+0x32b kproc_suspend_check(c2f217d4,c0e16870,250,c0b782a8,3e8,...) at kproc_suspend_check+0x7c vnlru_proc(0,df417d38,c0b66eb8,322,c2f217d4,...) at vnlru_proc+0x68 fork_exit(c083bd80,0,df417d38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xdf417d70, ebp = 0 --- Tracing command syncer pid 24 tid 100046 td 0xc2e4a000 sched_switch(c2e4a000,0,104,17e,301bdf40,...) at sched_switch+0x437 mi_switch(104,0,c0b6ec3d,1d2,68,...) at mi_switch+0x200 sleepq_switch(c2e4a000,0,c0b6ec3d,247,0,...) at sleepq_switch+0x15f sleepq_wait(c2d39874,68,c0b676c7,0,0,...) at sleepq_wait+0x63 _sleep(c2d39874,c2d3985c,68,c0b676c7,0,...) at _sleep+0x32b kproc_suspend_check(c2d397d4,0,c0b77505,6ae,4e20,...) at kproc_suspend_check+0x7c sched_sync(0,df414d38,c0b66eb8,322,c2d397d4,...) at sched_sync+0xdc fork_exit(c083b200,0,df414d38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xdf414d70, ebp = 0 --- Tracing command bufdaemon pid 23 tid 100045 td 0xc2e4a230 sched_switch(c2e4a230,0,104,17e,7efee33c,...) at sched_switch+0x437 mi_switch(104,0,c0b6ec3d,1d2,68,...) at mi_switch+0x200 sleepq_switch(c2e4a230,0,c0b6ec3d,247,0,...) at sleepq_switch+0x15f sleepq_wait(c2d39b10,68,c0b676c7,0,0,...) at sleepq_wait+0x63 _sleep(c2d39b10,c2d39af8,68,c0b676c7,0,...) at _sleep+0x32b kproc_suspend_check(c2d39a70,0,c0b75392,7ed,3e8,...) at kproc_suspend_check+0x7c buf_daemon(0,df411d38,c0b66eb8,322,c2d39a70,...) at buf_daemon+0xa0 fork_exit(c0824d40,0,df411d38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xdf411d70, ebp = 0 --- Tracing command pagezero pid 22 tid 100044 td 0xc2e4a460 sched_switch(c2e4a460,0,104,17e,12c8a303,...) at sched_switch+0x437 mi_switch(104,0,c0b6ec3d,1d2,0,...) at mi_switch+0x200 sleepq_switch(c2e4a460,0,c0b6ec3d,26a,0,...) at sleepq_switch+0x15f sleepq_timedwait(c0e230d4,0,c0b92c20,0,0,...) at sleepq_timedwait+0x6b _sleep(c0e230d4,c0e22c90,0,c0b92c20,493e0,...) at _sleep+0x2f9 vm_pagezero(0,df40ed38,c0b66eb8,322,c2d39d0c,...) at vm_pagezero+0xdc fork_exit(c09e9ce0,0,df40ed38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xdf40ed70, ebp = 0 --- Tracing command vmdaemon pid 21 tid 100043 td 0xc2e4a690 sched_switch(c2e4a690,0,104,17e,3e7a2087,...) at sched_switch+0x437 mi_switch(104,0,c0b6ec3d,1d2,68,...) at mi_switch+0x200 sleepq_switch(c2e4a690,0,c0b6ec3d,247,0,...) at sleepq_switch+0x15f sleepq_wait(c0e22cfc,68,c0b7598a,0,0,...) at sleepq_wait+0x63 _sleep(c0e22cfc,c0e22d00,68,c0b7598a,0,...) at _sleep+0x32b vm_daemon(0,df40bd38,c0b66eb8,322,c2e01000,...) at vm_daemon+0x59 fork_exit(c09e4200,0,df40bd38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xdf40bd70, ebp = 0 --- Tracing command pagedaemon pid 9 tid 100042 td 0xc2e4a8c0 sched_switch(c2e4a8c0,0,104,17e,d97047cb,...) at sched_switch+0x437 mi_switch(104,0,c0b6ec3d,1d2,44,...) at mi_switch+0x200 sleepq_switch(c2e4a8c0,0,c0b6ec3d,26a,0,...) at sleepq_switch+0x15f sleepq_timedwait(c0e22cc4,44,c0b7598a,0,0,...) at sleepq_timedwait+0x6b _sleep(c0e22cc4,c0e22c90,44,c0b7598a,1388,...) at _sleep+0x2f9 vm_pageout(0,df408d38,c0b66eb8,322,c2e0129c,...) at vm_pageout+0x2bb fork_exit(c09e4d70,0,df408d38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xdf408d70, ebp = 0 --- Tracing command sctp_iterator pid 7 tid 100040 td 0xc2e4ad20 sched_switch(c2e4ad20,0,104,17e,1e9208b1,...) at sched_switch+0x437 mi_switch(104,0,c0b6ec3d,1d2,0,...) at mi_switch+0x200 sleepq_switch(c2e4ad20,0,c0b6ec3d,247,0,...) at sleepq_switch+0x15f sleepq_wait(c0e18280,0,c0b813da,0,0,...) at sleepq_wait+0x63 _sleep(c0e18280,c0e18194,0,c0b813da,0,...) at _sleep+0x32b sctp_iterator_thread(0,df402d38,c0b66eb8,322,c2e017d4,...) at sctp_iterator_thread+0x60 fork_exit(c08ae1f0,0,df402d38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xdf402d70, ebp = 0 --- Tracing command fdc0 pid 6 tid 100036 td 0xc2ded230 sched_switch(c2ded230,0,104,17e,2009f35a,...) at sched_switch+0x437 mi_switch(104,0,c0b6ec3d,1d2,4c,...) at mi_switch+0x200 sleepq_switch(c2ded230,0,c0b6ec3d,26a,0,...) at sleepq_switch+0x15f sleepq_timedwait(c2dff23c,4c,c0b61a9d,0,0,...) at sleepq_timedwait+0x6b _sleep(c2dff23c,c2dff2f0,4c,c0b61a9d,3e8,...) at _sleep+0x2f9 fdc_thread(c2dff200,df3efd38,c0b66eb8,322,c2e01a70,...) at fdc_thread+0x2b8 fork_exit(c0a8a890,c2dff200,df3efd38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xdf3efd70, ebp = 0 --- Tracing command usb4 pid 20 tid 100033 td 0xc2ded8c0 sched_switch(c2ded8c0,0,104,17e,f2da2b2f,...) at sched_switch+0x437 mi_switch(104,0,c0b6ec3d,1d2,5c,...) at mi_switch+0x200 sleepq_switch(c2ded8c0,0,c0b6ec3d,26a,0,...) at sleepq_switch+0x15f sleepq_timedwait(c2dbf210,5c,c0b5db5c,0,0,...) at sleepq_timedwait+0x6b _sleep(c2dbf210,0,5c,c0b5db5c,ea60,...) at _sleep+0x2f9 usb_event_thread(c2def940,df3d4d38,c0b66eb8,322,c2e01d0c,...) at usb_event_thread+0xca fork_exit(c071c160,c2def940,df3d4d38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xdf3d4d70, ebp = 0 --- Tracing command usb3 pid 19 tid 100031 td 0xc2dedd20 sched_switch(c2dedd20,0,104,17e,f2daf221,...) at sched_switch+0x437 mi_switch(104,0,c0b6ec3d,1d2,5c,...) at mi_switch+0x200 sleepq_switch(c2dedd20,0,c0b6ec3d,26a,0,...) at sleepq_switch+0x15f sleepq_timedwait(c2df9210,5c,c0b5db5c,0,0,...) at sleepq_timedwait+0x6b _sleep(c2df9210,0,5c,c0b5db5c,ea60,...) at _sleep+0x2f9 usb_event_thread(c2df05c0,df3bed38,c0b66eb8,322,c2cc129c,...) at usb_event_thread+0xca fork_exit(c071c160,c2df05c0,df3bed38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xdf3bed70, ebp = 0 --- Tracing command usb2 pid 18 tid 100029 td 0xc2dee230 sched_switch(c2dee230,0,104,17e,f2dab3b5,...) at sched_switch+0x437 mi_switch(104,0,c0b6ec3d,1d2,5c,...) at mi_switch+0x200 sleepq_switch(c2dee230,0,c0b6ec3d,26a,0,...) at sleepq_switch+0x15f sleepq_timedwait(c2de0210,5c,c0b5db5c,0,0,...) at sleepq_timedwait+0x6b _sleep(c2de0210,0,5c,c0b5db5c,ea60,...) at _sleep+0x2f9 usb_event_thread(c2df0d40,df3b7d38,c0b66eb8,322,c2cc1538,...) at usb_event_thread+0xca fork_exit(c071c160,c2df0d40,df3b7d38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xdf3b7d70, ebp = 0 --- Tracing command usb1 pid 17 tid 100027 td 0xc2d07690 sched_switch(c2d07690,0,104,17e,f2d9ecdc,...) at sched_switch+0x437 mi_switch(104,0,c0b6ec3d,1d2,5c,...) at mi_switch+0x200 sleepq_switch(c2d07690,0,c0b6ec3d,26a,0,...) at sleepq_switch+0x15f sleepq_timedwait(c2de2210,5c,c0b5db5c,0,0,...) at sleepq_timedwait+0x6b _sleep(c2de2210,0,5c,c0b5db5c,ea60,...) at _sleep+0x2f9 usb_event_thread(c2dc9b80,df3b0d38,c0b66eb8,322,c2cc17d4,...) at usb_event_thread+0xca fork_exit(c071c160,c2dc9b80,df3b0d38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xdf3b0d70, ebp = 0 --- Tracing command usbtask-dr pid 16 tid 100026 td 0xc2d078c0 sched_switch(c2d078c0,0,104,17e,1e986354,...) at sched_switch+0x437 mi_switch(104,0,c0b6ec3d,1d2,5c,...) at mi_switch+0x200 sleepq_switch(c2d078c0,0,c0b6ec3d,247,0,...) at sleepq_switch+0x15f sleepq_wait(c0cae294,5c,c0b5db4e,0,0,...) at sleepq_wait+0x63 _sleep(c0cae294,0,5c,c0b5db4e,0,...) at _sleep+0x32b usb_task_thread(c0cae294,df3a9d38,c0b66eb8,322,c2cc1a70,...) at usb_task_thread+0x62 fork_exit(c071c020,c0cae294,df3a9d38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xdf3a9d70, ebp = 0 --- Tracing command usbtask-hc pid 15 tid 100025 td 0xc2d07af0 sched_switch(c2d07af0,0,104,17e,1e9847cf,...) at sched_switch+0x437 mi_switch(104,0,c0b6ec3d,1d2,5c,...) at mi_switch+0x200 sleepq_switch(c2d07af0,0,c0b6ec3d,247,0,...) at sleepq_switch+0x15f sleepq_wait(c0cae280,5c,c0b5db4e,0,0,...) at sleepq_wait+0x63 _sleep(c0cae280,0,5c,c0b5db4e,0,...) at _sleep+0x32b usb_task_thread(c0cae280,df3a6d38,c0b66eb8,322,c2cc1d0c,...) at usb_task_thread+0x62 fork_exit(c071c020,c0cae280,df3a6d38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xdf3a6d70, ebp = 0 --- Tracing command usb0 pid 14 tid 100024 td 0xc2d07d20 sched_switch(c2d07d20,0,104,17e,f2daa198,...) at sched_switch+0x437 mi_switch(104,0,c0b6ec3d,1d2,5c,...) at mi_switch+0x200 sleepq_switch(c2d07d20,0,c0b6ec3d,26a,0,...) at sleepq_switch+0x15f sleepq_timedwait(c2dd1210,5c,c0b5db5c,0,0,...) at sleepq_timedwait+0x6b _sleep(c2dd1210,0,5c,c0b5db5c,ea60,...) at _sleep+0x2f9 usb_event_thread(c2dd6a40,df3a3d38,c0b66eb8,322,c2d39000,...) at usb_event_thread+0xca fork_exit(c071c160,c2dd6a40,df3a3d38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xdf3a3d70, ebp = 0 --- Tracing command xpt_thrd pid 5 tid 100018 td 0xc2dc4af0 sched_switch(c2dc4af0,0,104,17e,1e980473,...) at sched_switch+0x437 mi_switch(104,0,c0b6ec3d,1d2,4c,...) at mi_switch+0x200 sleepq_switch(c2dc4af0,0,c0b6ec3d,247,0,...) at sleepq_switch+0x15f sleepq_wait(c0c7e054,4c,c0b16e25,0,0,...) at sleepq_wait+0x63 _sleep(c0c7e054,c0c7e06c,4c,c0b16e25,0,...) at _sleep+0x32b xpt_scanner_thread(0,df368d38,c0b66eb8,322,c2d3929c,...) at xpt_scanner_thread+0x41 fork_exit(c0471620,0,df368d38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xdf368d70, ebp = 0 --- Tracing command yarrow pid 13 tid 100013 td 0xc2cc4af0 sched_switch(c2cc4af0,0,104,17e,34db65ae,...) at sched_switch+0x437 mi_switch(104,0,c0b6ec3d,1d2,0,...) at mi_switch+0x200 sleepq_switch(c2cc4af0,0,c0b6ec3d,26a,2,...) at sleepq_switch+0x15f sleepq_timedwait(c0cb0bc4,0,c0b61a9d,2,0,...) at sleepq_timedwait+0x6b _sleep(c0cb0bc4,0,0,c0b61a9d,64,...) at _sleep+0x2f9 pause(c0b61a9d,64,c0b53550,112,0,...) at pause+0x47 random_kthread(0,c2bfcd38,c0b66eb8,322,c2d39538,...) at random_kthread+0x1d9 fork_exit(c068adc0,0,c2bfcd38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xc2bfcd70, ebp = 0 --- Tracing command g_down pid 4 tid 100012 td 0xc2cc4d20 sched_switch(c2cc4d20,0,104,17e,34da50b6,...) at sched_switch+0x437 mi_switch(104,0,c0b6ec3d,1d2,4c,...) at mi_switch+0x200 sleepq_switch(c2cc4d20,0,c0b6ec3d,26a,0,...) at sleepq_switch+0x15f sleepq_timedwait(c0cae9c4,4c,c0b61a9d,0,0,...) at sleepq_timedwait+0x6b _sleep(c0cae9c4,c0cae928,24c,c0b61a9d,64,...) at _sleep+0x2f9 g_io_schedule_down(c2cc4d20,0,c0b63202,74,0,...) at g_io_schedule_down+0x6b g_down_procbody(0,c2bf9d38,c0b66eb8,322,c2cc0000,...) at g_down_procbody+0x8d fork_exit(c07600e0,0,c2bf9d38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xc2bf9d70, ebp = 0 --- Tracing command g_up pid 3 tid 100011 td 0xc2d07000 sched_switch(c2d07000,0,104,17e,487e35fa,...) at sched_switch+0x437 mi_switch(104,0,c0b6ec3d,1d2,4c,...) at mi_switch+0x200 sleepq_switch(c2d07000,0,c0b6ec3d,26a,0,...) at sleepq_switch+0x15f sleepq_timedwait(c0cae9c0,4c,c0b61a9d,0,0,...) at sleepq_timedwait+0x6b _sleep(c0cae9c0,c0cae948,24c,c0b61a9d,64,...) at _sleep+0x2f9 g_io_schedule_up(c2d07000,0,c0b63202,5d,0,...) at g_io_schedule_up+0x133 g_up_procbody(0,c2bf6d38,c0b66eb8,322,c2cc029c,...) at g_up_procbody+0x8d fork_exit(c0760170,0,c2bf6d38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xc2bf6d70, ebp = 0 --- Tracing command g_event pid 2 tid 100010 td 0xc2d07230 sched_switch(c2d07230,0,104,17e,4383ceef,...) at sched_switch+0x437 mi_switch(104,0,c0b6ec3d,1d2,4c,...) at mi_switch+0x200 sleepq_switch(c2d07230,0,c0b6ec3d,26a,0,...) at sleepq_switch+0x15f sleepq_timedwait(c2f05738,4c,c0b6315f,0,0,...) at sleepq_timedwait+0x6b _sleep(c2f05738,c2c8a7b8,4c,c0b6315f,64,...) at _sleep+0x2f9 biowait(c2f05738,c0b6315f,0,c2bf3b10,c2bf3c10,...) at biowait+0x7d g_write_data(c2e3ea40,2b476000,1,c2f4b200,200,...) at g_write_data+0xae g_mirror_write_metadata(c2e47600,c2e9de80,c2bf3b90,2de,4d4f4547,...) at g_mirror_write_metadata+0x3c0 g_mirror_update_metadata(c2e9de80,4,c0f8512a,205,c2e4762c,...) at g_mirror_update_metadata+0x82 g_mirror_destroy_device(c2e4762c,0,c0f8512a,ba1,c8,...) at g_mirror_destroy_device+0x90 g_mirror_destroy(c2e47600,0,c0f8512a,ad9,c2e4762c,...) at g_mirror_destroy+0x229 g_mirror_destroy_delayed(c2e47600,0,c0b62d0c,d2,20,...) at g_mirror_destroy_delayed+0xa6 g_run_events(c0cae9b8,0,4c,c0b61a9d,64,...) at g_run_events+0x31e g_event_procbody(0,c2bf3d38,c0b66eb8,322,c2cc0538,...) at g_event_procbody+0x8a fork_exit(c0760200,0,c2bf3d38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xc2bf3d70, ebp = 0 --- Tracing command intr pid 12 tid 100039 td 0xc2e4d000 fork_trampoline() at fork_trampoline Tracing command intr pid 12 tid 100038 td 0xc2dc4d20 sched_switch(c2dc4d20,0,109,17e,e3949f63,...) at sched_switch+0x437 mi_switch(109,0,c0b67156,4cd,c2e3c7ec,...) at mi_switch+0x200 ithread_loop(c2e46610,df3f5d38,c0b66eb8,322,c2cc07d4,...) at ithread_loop+0x34c fork_exit(c0795810,c2e46610,df3f5d38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xdf3f5d70, ebp = 0 --- Tracing command intr pid 12 tid 100037 td 0xc2ded000 fork_trampoline() at fork_trampoline Tracing command intr pid 12 tid 100035 td 0xc2ded460 fork_trampoline() at fork_trampoline Tracing command intr pid 12 tid 100034 td 0xc2ded690 fork_trampoline() at fork_trampoline Tracing command intr pid 12 tid 100032 td 0xc2dedaf0 fork_trampoline() at fork_trampoline Tracing command intr pid 12 tid 100030 td 0xc2dee000 fork_trampoline() at fork_trampoline Tracing command intr pid 12 tid 100028 td 0xc2dee460 fork_trampoline() at fork_trampoline Tracing command intr pid 12 tid 100023 td 0xc2dc4000 fork_trampoline() at fork_trampoline Tracing command intr pid 12 tid 100022 td 0xc2dc4230 sched_switch(c2dc4230,0,109,17e,34e83fe0,...) at sched_switch+0x437 mi_switch(109,0,c0b67156,4cd,c2ce676c,...) at mi_switch+0x200 ithread_loop(c2dd2930,df39cd38,c0b66eb8,322,c2cc07d4,...) at ithread_loop+0x34c fork_exit(c0795810,c2dd2930,df39cd38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xdf39cd70, ebp = 0 --- Tracing command intr pid 12 tid 100021 td 0xc2dc4460 sched_switch(c2dc4460,0,109,17e,e4f9f209,...) at sched_switch+0x437 mi_switch(109,0,c0b67156,4cd,c2ce67ec,...) at mi_switch+0x200 ithread_loop(c2dd2aa0,df395d38,c0b66eb8,322,c2cc07d4,...) at ithread_loop+0x34c fork_exit(c0795810,c2dd2aa0,df395d38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xdf395d70, ebp = 0 --- Tracing command intr pid 12 tid 100020 td 0xc2dc4690 fork_trampoline() at fork_trampoline Tracing command intr pid 12 tid 100019 td 0xc2dc48c0 fork_trampoline() at fork_trampoline Tracing command intr pid 12 tid 100016 td 0xc2cc4460 sched_switch(c2cc4460,0,109,17e,357cc14c,...) at sched_switch+0x437 mi_switch(109,0,c0b67156,4cd,c2d0f86c,...) at mi_switch+0x200 ithread_loop(c2dc31e0,df362d38,c0b66eb8,322,c2cc07d4,...) at ithread_loop+0x34c fork_exit(c0795810,c2dc31e0,df362d38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xdf362d70, ebp = 0 --- Tracing command intr pid 12 tid 100015 td 0xc2cc4690 fork_trampoline() at fork_trampoline Tracing command intr pid 12 tid 100008 td 0xc2cc2000 fork_trampoline() at fork_trampoline Tracing command intr pid 12 tid 100007 td 0xc2cc2230 fork_trampoline() at fork_trampoline Tracing command intr pid 12 tid 100006 td 0xc2cc2460 sched_switch(c2cc2460,0,109,17e,487e1a5b,...) at sched_switch+0x437 mi_switch(109,0,c0b67156,4cd,c2ce62ec,...) at mi_switch+0x200 ithread_loop(c2cbf6b0,c2be7d38,c0b66eb8,322,c2cc07d4,...) at ithread_loop+0x34c fork_exit(c0795810,c2cbf6b0,c2be7d38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xc2be7d70, ebp = 0 --- Tracing command intr pid 12 tid 100005 td 0xc2cc2690 sched_switch(c2cc2690,0,103,179,353ee944,...) at sched_switch+0x437 mi_switch(103,0,c0b6f4b6,2e0,c2c8b2d0,...) at mi_switch+0x200 turnstile_wait(c2c8b2d0,c2fbe000,0,188,c0cb0630,...) at turnstile_wait+0x48a _mtx_lock_sleep(c0cb0630,c2cc2690,0,c0b695d3,89,...) at _mtx_lock_sleep+0x18e _mtx_lock_flags(c0cb0630,0,c0b695d3,89,c2be4cc4,...) at _mtx_lock_flags+0xef lock_mtx(c0cb0630,1,c0b6bee1,16b,c0cb0df4,...) at lock_mtx+0x29 softclock(c0cb0dc0,0,c0b67156,4d3,c2ce636c,...) at softclock+0x1e5 ithread_loop(c2cbf6c0,c2be4d38,c0b66eb8,322,c2cc07d4,...) at ithread_loop+0x1b5 fork_exit(c0795810,c2cbf6c0,c2be4d38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xc2be4d70, ebp = 0 --- Tracing command idle pid 11 tid 100004 td 0xc2cc28c0 sched_switch(c2cc28c0,0,608,179,34e7a79b,...) at sched_switch+0x437 mi_switch(608,0,c0b6b1be,bc,0,...) at mi_switch+0x200 critical_exit(c2ce525c,c2cc28c0,c2ce525c,c2ce6700,f,...) at critical_exit+0xa8 intr_event_handle(c2ce6700,c2be0c68,1f9,2710,0,...) at intr_event_handle+0xba intr_execute_handlers(c2ce525c,c2be0c68,c2be0ca8,c0aad244,31,...) at intr_execute_handlers+0x4f lapic_handle_intr(31,c2be0c68) at lapic_handle_intr+0x3f Xapic_isr1() at Xapic_isr1+0x34 --- interrupt, eip = 0xc0ab6a22, esp = 0xc2be0ca8, ebp = 0xc2be0ca8 --- cpu_idle_acpi(1,c2be0cf8,c07d4d86,1,c2be0cd8,...) at cpu_idle_acpi+0x22 cpu_idle(1,c2be0cd8,c0b6c6e7,3a3,c2cc28c0,...) at cpu_idle+0x1b sched_idletd(0,c2be0d38,c0b66eb8,322,c2cc0a70,...) at sched_idletd+0x216 fork_exit(c07d4b70,0,c2be0d38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xc2be0d70, ebp = 0 --- Tracing command idle pid 11 tid 100003 td 0xc2cc2af0 sched_switch(c2cc2af0,0,108,179,31195894,...) at sched_switch+0x437 mi_switch(108,0,c0b6c6e7,3a1,c2cc2af0,...) at mi_switch+0x200 sched_idletd(0,c2bddd38,c0b66eb8,322,c2cc0a70,...) at sched_idletd+0x178 fork_exit(c07d4b70,0,c2bddd38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xc2bddd70, ebp = 0 --- Tracing command init pid 1 tid 100002 td 0xc2cc2d20 cpustop_handler(2,c2bd9b88,c0ac8add,c2c70340,c2bd9b0c,...) at cpustop_handler+0x32 ipi_nmi_handler(c2c70340,c2bd9b0c,c07f0ef7,c0af18fa,c2cc0d0c,...) at ipi_nmi_handler+0x2f trap(c2bd9b94) at trap+0x2d calltrap() at calltrap+0x6 --- trap 0x13, eip = 0xc07a5ebf, esp = 0xc2bd9bd4, ebp = 0xc2bd9be8 --- _mtx_unlock_spin_flags(c2cc0d1c,0,c0b6ab59,8ff,0,...) at _mtx_unlock_spin_flags+0xef tdsigwakeup(4,b,c2bd9ccc,7ea,0,...) at tdsigwakeup+0x212 tdsignal(c2cc0d0c,c2cc2d20,b,c2bd9ccc,a,...) at tdsignal+0x897 trapsignal(c2cc2d20,c2bd9ccc,c0b9ee1a,c2c73330,c2cc0d0c,...) at trapsignal+0x297 trap(c2bd9d38) at trap+0x6ad calltrap() at calltrap+0x6 --- trap 0xc, eip = 0x8048870, esp = 0xbfbfe62c, ebp = 0xbfbfe978 --- Tracing command audit pid 10 tid 100001 td 0xc2cc4000 sched_switch(c2cc4000,0,104,17e,1e93e7fd,...) at sched_switch+0x437 mi_switch(104,0,c0b6ec3d,1d2,0,...) at mi_switch+0x200 sleepq_switch(c2cc4000,0,c0b6ec3d,247,c2cc4000,...) at sleepq_switch+0x15f sleepq_wait(c0e21ee0,0,c0b8b0fc,1,0,...) at sleepq_wait+0x63 _cv_wait(c0e21ee0,c0e21ec4,c0b8badb,18d,0,...) at _cv_wait+0x213 audit_worker(0,c2bd6d38,c0b66eb8,322,c2cc1000,...) at audit_worker+0x84 fork_exit(c0994b50,0,c2bd6d38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xc2bd6d70, ebp = 0 --- Tracing command kernel pid 0 tid 100017 td 0xc2cc4230 sched_switch(c2cc4230,0,104,17e,1e9ddb91,...) at sched_switch+0x437 mi_switch(104,0,c0b6ec3d,1d2,0,...) at mi_switch+0x200 sleepq_switch(c2cc4230,0,c0b6ec3d,247,0,...) at sleepq_switch+0x15f sleepq_wait(c2db1140,0,c0b61a9d,0,0,...) at sleepq_wait+0x63 _sleep(c2db1140,c2db115c,0,c0b61a9d,0,...) at _sleep+0x32b taskqueue_thread_loop(c0caf1bc,df365d38,c0b66eb8,322,c0caea80,...) at taskqueue_thread_loop+0xb4 fork_exit(c07eb240,c0caf1bc,df365d38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xdf365d70, ebp = 0 --- Tracing command kernel pid 0 tid 100014 td 0xc2cc48c0 sched_switch(c2cc48c0,0,104,17e,1e9d88a2,...) at sched_switch+0x437 mi_switch(104,0,c0b6ec3d,1d2,0,...) at mi_switch+0x200 sleepq_switch(c2cc48c0,0,c0b6ec3d,247,0,...) at sleepq_switch+0x15f sleepq_wait(c2db1280,0,c0b61a9d,0,0,...) at sleepq_wait+0x63 _sleep(c2db1280,c2db129c,0,c0b61a9d,0,...) at _sleep+0x32b taskqueue_thread_loop(c0cbc868,c2bffd38,c0b66eb8,322,c0caea80,...) at taskqueue_thread_loop+0xb4 fork_exit(c07eb240,c0cbc868,c2bffd38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xc2bffd70, ebp = 0 --- Tracing command kernel pid 0 tid 100009 td 0xc2d07460 sched_switch(c2d07460,0,104,17e,737ce18c,...) at sched_switch+0x437 mi_switch(104,0,c0b6ec3d,1d2,0,...) at mi_switch+0x200 sleepq_switch(c2d07460,0,c0b6ec3d,247,0,...) at sleepq_switch+0x15f sleepq_wait(c2ca2700,0,c0b61a9d,0,0,...) at sleepq_wait+0x63 _sleep(c2ca2700,c2ca271c,0,c0b61a9d,0,...) at _sleep+0x32b taskqueue_thread_loop(c0cbb4e0,c2bf0d38,c0b66eb8,322,c0caea80,...) at taskqueue_thread_loop+0xb4 fork_exit(c07eb240,c0cbb4e0,c2bf0d38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xc2bf0d70, ebp = 0 --- Tracing command kernel pid 0 tid 100000 td 0xc0caed20 sched_switch(c0caed20,0,104,17e,34dc1ee6,...) at sched_switch+0x437 mi_switch(104,0,c0b6ec3d,1d2,44,...) at mi_switch+0x200 sleepq_switch(c0caed20,0,c0b6ec3d,26a,0,...) at sleepq_switch+0x15f sleepq_timedwait(c0caea80,44,c0b6ce40,0,0,...) at sleepq_timedwait+0x6b _sleep(c0caea80,0,44,c0b6ce40,2710,...) at _sleep+0x2f9 scheduler(0,141ec00,141ec00,141e000,1425000,...) at scheduler+0x23e mi_startup() at mi_startup+0x96 begin() at begin+0x2c db> From owner-freebsd-current@FreeBSD.ORG Fri Sep 5 08:49:05 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 816251065673 for ; Fri, 5 Sep 2008 08:49:05 +0000 (UTC) (envelope-from lists@peter.de.com) Received: from nemesis.charlie.mouhaha.de (nemesis.charlie.mouhaha.de [78.47.10.193]) by mx1.freebsd.org (Postfix) with ESMTP id 365878FC18 for ; Fri, 5 Sep 2008 08:49:05 +0000 (UTC) (envelope-from lists@peter.de.com) Received: from localhost (nemesis.charlie.mouhaha.de [78.47.10.193]) by nemesis.charlie.mouhaha.de (Postfix) with ESMTP id CB24343512 for ; Fri, 5 Sep 2008 09:29:27 +0100 (BST) X-Virus-Scanned: amavisd-new at mouhaha.de Received: from nemesis.charlie.mouhaha.de ([78.47.10.193]) by localhost (nemesis.charlie.mouhaha.de [78.47.10.193]) (amavisd-new, port 10024) with ESMTP id FsDDTsr872L0 for ; Fri, 5 Sep 2008 09:29:25 +0100 (BST) Received: from nemesis.charlie.mouhaha.de (nemesis.charlie.mouhaha.de [78.47.10.193]) by nemesis.charlie.mouhaha.de (Postfix) with SMTP id A5663434FE for ; Fri, 5 Sep 2008 09:29:25 +0100 (BST) Received: from dilbert.office.centralnic.com (office.centralnic.net [82.68.174.118]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by nemesis.charlie.mouhaha.de (Postfix) with ESMTPSA id 484D3434EC; Fri, 5 Sep 2008 09:29:24 +0100 (BST) Date: Fri, 5 Sep 2008 09:29:22 +0100 From: Oliver Peter To: Kris Kennaway Message-ID: <20080905092922.1aaa95f0@dilbert.office.centralnic.com> In-Reply-To: <48C0BC80.3000107@FreeBSD.org> References: <48C0B59F.4030200@delphij.net> <48C0B781.40200@FreeBSD.org> <48C0BB1A.4020906@delphij.net> <48C0BC80.3000107@FreeBSD.org> X-Mailer: Claws Mail 3.0.2 (GTK+ 2.10.4; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Jakub Dawidek , Pawel, FreeBSD Current , d@delphij.net Subject: Re: panic on shutdown anyone (insmntque())? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lists@peter.de.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2008 08:49:05 -0000 On Fri, 05 Sep 2008 14:28:40 +0930 Kris Kennaway wrote: > >>> Anyone get panic (kernel trap 12) near insmntque() during the > >>> last stage of shutdown? It seems to be 100% reproducible with > >>> INVARIANTS/WITNESS > >>> - -CURRENT kernel and seems to be a regression introduced during > >>> the past week. > >> Are you using ZFS? > > > > Yes, ZFS as root... > > pjd has a fix in his p4 branch. Same problem here with ZFS on root. Where can I find this patch? Would be happy to test it. -- Oliver PETER, email: oliver@peter.de.com, ICQ# 113969174 "I like to con people. And I like to insult people. If you combine con & insult, you get consult!" -- Dogbert From owner-freebsd-current@FreeBSD.ORG Fri Sep 5 08:51:46 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 64355106566C; Fri, 5 Sep 2008 08:51:46 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 2CF2A8FC1E; Fri, 5 Sep 2008 08:51:44 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <48C0F320.5040002@FreeBSD.org> Date: Fri, 05 Sep 2008 18:21:44 +0930 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: lists@peter.de.com References: <48C0B59F.4030200@delphij.net> <48C0B781.40200@FreeBSD.org> <48C0BB1A.4020906@delphij.net> <48C0BC80.3000107@FreeBSD.org> <20080905092922.1aaa95f0@dilbert.office.centralnic.com> In-Reply-To: <20080905092922.1aaa95f0@dilbert.office.centralnic.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Pawel Jakub Dawidek , FreeBSD Current , d@delphij.net Subject: Re: panic on shutdown anyone (insmntque())? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2008 08:51:46 -0000 Oliver Peter wrote: > On Fri, 05 Sep 2008 14:28:40 +0930 > Kris Kennaway wrote: > >>>>> Anyone get panic (kernel trap 12) near insmntque() during the >>>>> last stage of shutdown? It seems to be 100% reproducible with >>>>> INVARIANTS/WITNESS >>>>> - -CURRENT kernel and seems to be a regression introduced during >>>>> the past week. >>>> Are you using ZFS? >>> Yes, ZFS as root... >> pjd has a fix in his p4 branch. > > Same problem here with ZFS on root. Where can I find this patch? > Would be happy to test it. It was committed earlier today. Kris From owner-freebsd-current@FreeBSD.ORG Fri Sep 5 16:41:19 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C85101065671 for ; Fri, 5 Sep 2008 16:41:19 +0000 (UTC) (envelope-from jille@quis.cx) Received: from smtp6.versatel.nl (smtp6.versatel.nl [62.58.50.97]) by mx1.freebsd.org (Postfix) with ESMTP id D2EF68FC20 for ; Fri, 5 Sep 2008 16:41:18 +0000 (UTC) (envelope-from jille@quis.cx) Received: (qmail 22009 invoked by uid 0); 5 Sep 2008 16:14:37 -0000 Received: from ip83-113-174-82.adsl2.static.versatel.nl (HELO istud.quis.cx) ([82.174.113.83]) (envelope-sender ) by smtp6.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 5 Sep 2008 16:14:37 -0000 Received: from [192.168.1.4] (ille [192.168.1.4]) by istud.quis.cx (Postfix) with ESMTP id 19E465C1D; Fri, 5 Sep 2008 18:14:37 +0200 (CEST) Message-ID: <48C15AEA.4070704@quis.cx> Date: Fri, 05 Sep 2008 18:14:34 +0200 From: Jille Timmermans User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: FreeBSD Current X-Enigmail-Version: 0.95.7 Content-Type: multipart/mixed; boundary="------------090302050406070102040701" Cc: Ed Schouten Subject: Segmentation fault in malloc_usable_size() (libc) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2008 16:41:19 -0000 This is a multi-part message in MIME format. --------------090302050406070102040701 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello current, I switched over to current a fews days ago. And I ran into a bug (file attached, log pasted): [quis@blackbox ~/crash]$ cc -o crash-thread crash-thread.c -lpthread [quis@blackbox ~/crash]$ gdb crash-thread GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"...(no debugging symbols found)... (gdb) run Starting program: /usr/home/quis/crash/crash-thread (no debugging symbols found)...[New LWP 100073] (no debugging symbols found)...(no debugging symbols found)...[New Thread 0x8101140 (LWP 100073)] [New Thread 0x8119140 (LWP 100047)] [Thread 0x8101140 (LWP 100073) exited] [New Thread 0x8101140 (LWP 100073)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x8119140 (LWP 100047)] 0x281028f6 in malloc_usable_size () from /lib/libc.so.7 (gdb) bt #0 0x281028f6 in malloc_usable_size () from /lib/libc.so.7 #1 0x28105ec1 in calloc () from /lib/libc.so.7 #2 0x2809143d in pthread_mutexattr_init () from /lib/libthr.so.3 #3 0x28091740 in pthread_mutex_getyieldloops_np () from /lib/libthr.so.3 #4 0x00000001 in ?? () #5 0x28075978 in ?? () from /libexec/ld-elf.so.1 #6 0x2815bb10 in bsearch () from /lib/libc.so.7 Previous frame inner to this frame (corrupt stack?) I am running world + kernel r182722 (with the packet-mode patch from Ed Schouten). When removing the malloc() from the code, it won't crash. When stepping through, the crash happens when you execute pthread_exit(NULL). Ed told me he saw this (some day) before on livefs. -- Jille Timmermans --------------090302050406070102040701 Content-Type: text/plain; name="crash-thread.c" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="crash-thread.c" #include #include #include void * server(void *self) { malloc(1); } int main(int argc, char **argv) { pthread_t thr; pthread_create(&thr, NULL, (void *)server, NULL); pthread_exit(NULL); } --------------090302050406070102040701-- From owner-freebsd-current@FreeBSD.ORG Fri Sep 5 20:26:11 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 198ED106564A for ; Fri, 5 Sep 2008 20:26:11 +0000 (UTC) (envelope-from gb@isis.u-strasbg.fr) Received: from mailhost.u-strasbg.fr (mailhost.u-strasbg.fr [IPv6:2001:660:2402::159]) by mx1.freebsd.org (Postfix) with ESMTP id 9245F8FC26 for ; Fri, 5 Sep 2008 20:26:10 +0000 (UTC) (envelope-from gb@isis.u-strasbg.fr) Received: from 6nq.u-strasbg.fr (mojito.u-strasbg.fr [IPv6:2001:660:4701:1002::3]) by mailhost.u-strasbg.fr (8.14.2/jtpda-5.5pre1) with ESMTP id m85KQ8Dl053418 for ; Fri, 5 Sep 2008 22:26:09 +0200 (CEST) Received: by 6nq.u-strasbg.fr (Postfix, from userid 1001) id 9FCF27050; Fri, 5 Sep 2008 22:25:25 +0200 (CEST) Date: Fri, 5 Sep 2008 22:25:25 +0200 From: Guy Brand To: freebsd-current@freebsd.org Message-ID: <20080905202525.GB1656@isis.u-strasbg.fr> References: <48C0B59F.4030200@delphij.net> <48C0B781.40200@FreeBSD.org> <48C0BB1A.4020906@delphij.net> <48C0BC80.3000107@FreeBSD.org> <20080905092922.1aaa95f0@dilbert.office.centralnic.com> <48C0F320.5040002@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <48C0F320.5040002@FreeBSD.org> x-gpg-fingerprint: B423 4924 012E 52F3 BA9E 547F CC8C 0BC5 9C0E B1CA x-gpg-key: 9C0EB1CA User-Agent: Mutt/1.5.18 (2008-05-17) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (mailhost.u-strasbg.fr [IPv6:2001:660:2402::159]); Fri, 05 Sep 2008 22:26:09 +0200 (CEST) X-Virus-Scanned: ClamAV 0.93.1/8168/Fri Sep 5 20:38:03 2008 on mr9.u-strasbg.fr X-Virus-Status: Clean X-Spam-Status: No, score=-0.0 required=5.0 tests=NO_RELAYS autolearn=disabled version=3.2.4 X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on mr9.u-strasbg.fr Subject: Re: panic on shutdown anyone (insmntque())? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2008 20:26:11 -0000 Kris Kennaway (kris@freebsd.org) on 05/09/2008 at 18:21 wrote: > >> pjd has a fix in his p4 branch. > > > > Same problem here with ZFS on root. Where can I find this patch? > > Would be happy to test it. > > It was committed earlier today. It fixed my shutdown panic. Thanks pjd -- bug From owner-freebsd-current@FreeBSD.ORG Fri Sep 5 23:08:03 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D9A7F106566B for ; Fri, 5 Sep 2008 23:08:03 +0000 (UTC) (envelope-from nork@ninth-nine.com) Received: from sakura.ninth-nine.com (unknown [IPv6:2001:2f0:104:80a0:230:48ff:fe41:2455]) by mx1.freebsd.org (Postfix) with ESMTP id 6F7998FC1B for ; Fri, 5 Sep 2008 23:08:03 +0000 (UTC) (envelope-from nork@ninth-nine.com) Received: from nadesico.ninth-nine.com (nadesico.ninth-nine.com [219.127.74.122]) by sakura.ninth-nine.com (8.14.1/8.14.1/NinthNine) with ESMTP id m85N82Tq046610 for ; Sat, 6 Sep 2008 08:08:02 +0900 (JST) (envelope-from nork@ninth-nine.com) Date: Sat, 6 Sep 2008 08:08:01 +0900 From: Norikatsu Shigemura To: freebsd-current@freebsd.org Message-Id: <20080906080801.8099c753.nork@ninth-nine.com> In-Reply-To: <20080826005920.8aca164b.nork@FreeBSD.org> References: <20080826005920.8aca164b.nork@FreeBSD.org> X-Mailer: Sylpheed 2.5.0 (GTK+ 2.12.11; i386-portbld-freebsd8.0) 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.2 (sakura.ninth-nine.com [219.127.74.121]); Sat, 06 Sep 2008 08:08:02 +0900 (JST) Subject: Do you need x11-drivers/xf86-video-radeonhd-devel? (Re: How about AMD Puma platform support?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2008 23:08:03 -0000 On Tue, 26 Aug 2008 00:59:20 +0900 Norikatsu Shigemura wrote: > ??: AMD M780G (ATI Radeon HD 3200) > I don't test, yet. OK, I confirmed that latest xf86-video-radeonhd driver is good works. To get that result, I made a ports/x11-drivers/xf86-video- radeonhd-devel port. Anyone do you need this port, too? From owner-freebsd-current@FreeBSD.ORG Sat Sep 6 00:45:08 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C6836106567F for ; Sat, 6 Sep 2008 00:45:08 +0000 (UTC) (envelope-from rmtodd@ichotolot.servalan.com) Received: from mx1.synetsystems.com (mx1.synetsystems.com [76.10.206.14]) by mx1.freebsd.org (Postfix) with ESMTP id 914638FC2A for ; Sat, 6 Sep 2008 00:45:08 +0000 (UTC) (envelope-from rmtodd@ichotolot.servalan.com) Received: by mx1.synetsystems.com (Postfix, from userid 66) id 3CF60C84; Fri, 5 Sep 2008 20:45:07 -0400 (EDT) Received: from rmtodd by servalan.servalan.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1KblFT-0001ry-JN; Fri, 05 Sep 2008 19:01:55 -0500 To: freebsd-current@freebsd.org References: <48C0B59F.4030200@delphij.net> <48C0B781.40200@FreeBSD.org> <48C0BB1A.4020906@delphij.net> <48C0BC80.3000107@FreeBSD.org> <20080905092922.1aaa95f0@dilbert.office.centralnic.com> <48C0F320.5040002@FreeBSD.org> <20080905202525.GB1656@isis.u-strasbg.fr> From: Richard Todd Date: Fri, 05 Sep 2008 19:01:55 -0500 In-Reply-To: (Guy Brand's message of "Fri, 5 Sep 2008 22:25:25 +0200") Message-ID: User-Agent: Gnus/5.1008 (Gnus v5.10.8) XEmacs/21.4.21 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: panic on shutdown anyone (insmntque())? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Sep 2008 00:45:08 -0000 Guy Brand writes: > Kris Kennaway (kris@freebsd.org) on 05/09/2008 at 18:21 wrote: > >> >> pjd has a fix in his p4 branch. >> > >> > Same problem here with ZFS on root. Where can I find this patch? >> > Would be happy to test it. >> >> It was committed earlier today. > > It fixed my shutdown panic. Thanks pjd But appears not to fix the panic I've seen trying to boot any kernel since the insmntque patches went in, just at the point where it tries to mount the root FS: Trying to mount root from zfs:rootpool/tolot-root KDB: stack backtrace: db_trace_self_wrapper(80bbd824,86ce5784,8086a0c3,874b4dc8,86ce5784,...) at db_trace_self_wrapper+0x26 kdb_backtrace(874b4dc8,86ce5784,80b1a6b5,86ce5794,874b4d70,...) at kdb_backtrace+0x29 vfs_badlock(8107eda0,86ce5794,80cd8c20,874b4d70) at vfs_badlock+0x23 assert_vop_elocked(874b4d70,80bc7ddf,87ae406c,87ae406c,157,...) at assert_vop_elocked+0x55 insmntque1(874b4d70,87b06670,80871200,0,86ce5808,...) at insmntque1+0x1c7 insmntque(874b4d70,87b06670,157,155,3,...) at insmntque+0x28 zfs_znode_alloc(3,0,e00,0,86ce585c,...) at zfs_znode_alloc+0x10d zfs_zget(87ae4000,3,0,86ce5950,8,...) at zfs_zget+0x1ce zfs_init_fs(87ae4000,86ce5950,8708fd00,87ae4008,2,...) at zfs_init_fs+0x2a0 zfs_mount(87b06670,870c4d20,80bc68f2,3f4,0,...) at zfs_mount+0x35a vfs_donmount(20,87af34e0,87af44c0,6,86ce5b78,...) at vfs_donmount+0x13ca kernel_mount(87af34e0,4001,87b03b80,ffffffff,86ce5bc0) at kernel_mount+0x78 kernel_vmount(4001,80bc6bdf,87af34c0,80bc6bee,80bb3d40,...) at kernel_vmount+0x63 vfs_mountroot_try(80bc6ef1,80bb3d40,80bab4a8,1,80864c00,...) at vfs_mountroot_try+0x132 vfs_mountroot(80d0ceb0,4,80bb5090,264,870c2d94,...) at vfs_mountroot+0x423 start_init(0,86ce5d38,80bb6ae4,322,870c2d0c,...) at start_init+0x65 fork_exit(807aca80,0,86ce5d38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0x86ce5d70, ebp = 0 --- insmntque: mp-safe fs and non-locked vp: 0x874b4d70 is not exclusive locked but should be KDB: enter: lock violation [thread pid 1 tid 100002 ] Stopped at kdb_enter+0x3a: movl $0,kdb_why db> From owner-freebsd-current@FreeBSD.ORG Sat Sep 6 02:27:17 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 14DF81065673 for ; Sat, 6 Sep 2008 02:27:17 +0000 (UTC) (envelope-from mike@jellydonut.org) Received: from mail4.sea5.speakeasy.net (mail4.sea5.speakeasy.net [69.17.117.6]) by mx1.freebsd.org (Postfix) with ESMTP id E070F8FC08 for ; Sat, 6 Sep 2008 02:27:16 +0000 (UTC) (envelope-from mike@jellydonut.org) Received: (qmail 5783 invoked from network); 6 Sep 2008 02:00:35 -0000 Received: from marconi.jellydonut.org (HELO localhost) ([216.27.165.148]) (envelope-sender ) by mail4.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 6 Sep 2008 02:00:34 -0000 Received: from plato.localnet (192.168.0.11) by marconi.localnet Message-ID: <48C1E43C.1010902@jellydonut.org> Date: Fri, 05 Sep 2008 22:00:28 -0400 From: Michael Proto User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.16) Gecko/20080708 Lightning/0.8 Thunderbird/2.0.0.16 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: sysctls and if_bridge X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Sep 2008 02:27:17 -0000 Ran into a strange problem the other day, hoping someone can shed some light on this. Updated 8-CURRENT from 6/14 to 9/02 and noticed a strange thing with my if_bridge interface. It appears as though the sysctls for determining where to enable/disable filtering don't seem to be working. My router has an IP, 1.2.3.4/24 on its vr2 interface, which is bridged to a second vr1 interface for my 3 other static IPs. /etc/rc.conf: ifconfig_vr2="inet 1.2.3.4 netmask 255.255.255.0" ifconfig_vr1="up" cloned_interfaces="bridge0" ifconfig_bridge0="addm vr2 addm vr1 up" /etc/sysctl.conf: net.link.bridge.pfil_member=1 net.link.bridge.pfil_bridge=0 Based on what I've read from the man pages (and how it worked before), this should enable filtering on the vr2 and vr1 interfaces, and not the bridge0 interface. After updating to 8-CURRENT 9/02 it appears that these sysctl settings no longer matter, and filtering is enabled on both the bridge and member interfaces. I ultimately had to tweak my /etc/pf.conf and set all my inbound-from-the-Internet vr2 rules to reference bridge0 instead. Outbound rules still use vr2, and I've flipped both sysctl settings with no change in behavior. Traffic flows now, but it appears these sysctls are not working as they should, or I'm really missing something. Thanks, Michael Proto From owner-freebsd-current@FreeBSD.ORG Sat Sep 6 02:46:20 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9570D1065670; Sat, 6 Sep 2008 02:46:20 +0000 (UTC) (envelope-from naddy@mips.inka.de) Received: from mail-in-12.arcor-online.net (mail-in-12.arcor-online.net [151.189.21.52]) by mx1.freebsd.org (Postfix) with ESMTP id 4041C8FC18; Sat, 6 Sep 2008 02:46:20 +0000 (UTC) (envelope-from naddy@mips.inka.de) Received: from mail-in-07-z2.arcor-online.net (mail-in-07-z2.arcor-online.net [151.189.8.19]) by mail-in-12.arcor-online.net (Postfix) with ESMTP id 452154C4A7; Sat, 6 Sep 2008 04:46:18 +0200 (CEST) Received: from mail-in-08.arcor-online.net (mail-in-08.arcor-online.net [151.189.21.48]) by mail-in-07-z2.arcor-online.net (Postfix) with ESMTP id 305AF2C6E6D; Sat, 6 Sep 2008 04:46:18 +0200 (CEST) Received: from lorvorc.mips.inka.de (dslb-092-075-208-057.pools.arcor-ip.net [92.75.208.57]) by mail-in-08.arcor-online.net (Postfix) with ESMTP id 1485A2BB6F5; Sat, 6 Sep 2008 04:46:18 +0200 (CEST) Received: from lorvorc.mips.inka.de (localhost [127.0.0.1]) by lorvorc.mips.inka.de (8.14.3/8.14.3) with ESMTP id m862kGMp002137; Sat, 6 Sep 2008 04:46:16 +0200 (CEST) (envelope-from naddy@lorvorc.mips.inka.de) Received: (from naddy@localhost) by lorvorc.mips.inka.de (8.14.3/8.14.3/Submit) id m862kGmm002136; Sat, 6 Sep 2008 04:46:16 +0200 (CEST) (envelope-from naddy) Date: Sat, 6 Sep 2008 04:46:16 +0200 From: Christian Weisgerber To: Pascal Hofstee Message-ID: <20080906024616.GA1961@lorvorc.mips.inka.de> References: <20080830010551.GA2090@lorvorc.mips.inka.de> <200809021033.55033.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) X-Virus-Scanned: ClamAV 0.93.3/8170/Fri Sep 5 22:36:43 2008 on mail-in-08.arcor-online.net X-Virus-Status: Clean Cc: freebsd-current@freebsd.org Subject: Re: No root filesystem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Sep 2008 02:46:20 -0000 Pascal Hofstee: > > http://www.FreeBSD.org/~jhb/patches/pcie.patch > > panic: pci_cfgread(0:24:0, 11, 1) => 0x6, 0xff I get essentially the same result: pci0: on pcib0 panic: pci_cfgread(0:24:0, 14, 1) => 0x80, 0xff > According to pciconf -lv on a working kernel device 0:24:0 is the following: > hostb0@pci0:0:24:0: class=0x060000 card=0x00000000 chip=0x11001022 > rev=0x00 hdr=0x00 > vendor = 'Advanced Micro Devices (AMD)' > device = '(K8) Athlon 64/Opteron HyperTransport Technology Same here. -- Christian "naddy" Weisgerber naddy@mips.inka.de From owner-freebsd-current@FreeBSD.ORG Sat Sep 6 03:05:46 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EA9E51065672; Sat, 6 Sep 2008 03:05:46 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id A46AB8FC1B; Sat, 6 Sep 2008 03:05:45 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <48C1F389.1090108@FreeBSD.org> Date: Sat, 06 Sep 2008 12:35:45 +0930 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: Richard Todd References: <48C0B59F.4030200@delphij.net> <48C0B781.40200@FreeBSD.org> <48C0BB1A.4020906@delphij.net> <48C0BC80.3000107@FreeBSD.org> <20080905092922.1aaa95f0@dilbert.office.centralnic.com> <48C0F320.5040002@FreeBSD.org> <20080905202525.GB1656@isis.u-strasbg.fr> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Pawel Jakub Dawidek , freebsd-current@freebsd.org, kib@FreeBSD.org Subject: Re: panic on shutdown anyone (insmntque())? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Sep 2008 03:05:47 -0000 Richard Todd wrote: > Guy Brand writes: > >> Kris Kennaway (kris@freebsd.org) on 05/09/2008 at 18:21 wrote: >> >>>>> pjd has a fix in his p4 branch. >>>> Same problem here with ZFS on root. Where can I find this patch? >>>> Would be happy to test it. >>> It was committed earlier today. >> It fixed my shutdown panic. Thanks pjd > > But appears not to fix the panic I've seen trying to boot any kernel since > the insmntque patches went in, just at the point where it tries to mount > the root FS: > > Trying to mount root from zfs:rootpool/tolot-root > KDB: stack backtrace: > db_trace_self_wrapper(80bbd824,86ce5784,8086a0c3,874b4dc8,86ce5784,...) at db_trace_self_wrapper+0x26 > kdb_backtrace(874b4dc8,86ce5784,80b1a6b5,86ce5794,874b4d70,...) at kdb_backtrace+0x29 > vfs_badlock(8107eda0,86ce5794,80cd8c20,874b4d70) at vfs_badlock+0x23 > assert_vop_elocked(874b4d70,80bc7ddf,87ae406c,87ae406c,157,...) at assert_vop_elocked+0x55 > insmntque1(874b4d70,87b06670,80871200,0,86ce5808,...) at insmntque1+0x1c7 > insmntque(874b4d70,87b06670,157,155,3,...) at insmntque+0x28 > zfs_znode_alloc(3,0,e00,0,86ce585c,...) at zfs_znode_alloc+0x10d > zfs_zget(87ae4000,3,0,86ce5950,8,...) at zfs_zget+0x1ce > zfs_init_fs(87ae4000,86ce5950,8708fd00,87ae4008,2,...) at zfs_init_fs+0x2a0 > zfs_mount(87b06670,870c4d20,80bc68f2,3f4,0,...) at zfs_mount+0x35a > vfs_donmount(20,87af34e0,87af44c0,6,86ce5b78,...) at vfs_donmount+0x13ca > kernel_mount(87af34e0,4001,87b03b80,ffffffff,86ce5bc0) at kernel_mount+0x78 > kernel_vmount(4001,80bc6bdf,87af34c0,80bc6bee,80bb3d40,...) at kernel_vmount+0x63 > vfs_mountroot_try(80bc6ef1,80bb3d40,80bab4a8,1,80864c00,...) at vfs_mountroot_try+0x132 > vfs_mountroot(80d0ceb0,4,80bb5090,264,870c2d94,...) at vfs_mountroot+0x423 > start_init(0,86ce5d38,80bb6ae4,322,870c2d0c,...) at start_init+0x65 > fork_exit(807aca80,0,86ce5d38) at fork_exit+0xb8 > fork_trampoline() at fork_trampoline+0x8 > --- trap 0, eip = 0, esp = 0x86ce5d70, ebp = 0 --- > insmntque: mp-safe fs and non-locked vp: 0x874b4d70 is not exclusive locked but should be > KDB: enter: lock violation > [thread pid 1 tid 100002 ] > Stopped at kdb_enter+0x3a: movl $0,kdb_why > db> Yep, looks different. Kris From owner-freebsd-current@FreeBSD.ORG Sat Sep 6 08:10:04 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 26C34106564A; Sat, 6 Sep 2008 08:10:04 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.terabit.net.ua (mail.terabit.net.ua [195.137.202.147]) by mx1.freebsd.org (Postfix) with ESMTP id A0A2A8FC1C; Sat, 6 Sep 2008 08:10:03 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from skuns.zoral.com.ua ([91.193.166.194] helo=mail.zoral.com.ua) by mail.terabit.net.ua with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1Kbsro-0006zD-Rk; Sat, 06 Sep 2008 11:10:00 +0300 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m8689vrd061064 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 6 Sep 2008 11:09:57 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m8689vvp076787; Sat, 6 Sep 2008 11:09:57 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id m8689vHV076786; Sat, 6 Sep 2008 11:09:57 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 6 Sep 2008 11:09:57 +0300 From: Kostik Belousov To: Kris Kennaway Message-ID: <20080906080956.GY2038@deviant.kiev.zoral.com.ua> References: <48C0B59F.4030200@delphij.net> <48C0B781.40200@FreeBSD.org> <48C0BB1A.4020906@delphij.net> <48C0BC80.3000107@FreeBSD.org> <20080905092922.1aaa95f0@dilbert.office.centralnic.com> <48C0F320.5040002@FreeBSD.org> <20080905202525.GB1656@isis.u-strasbg.fr> <48C1F389.1090108@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/YLrkxBeBoBPjrwx" Content-Disposition: inline In-Reply-To: <48C1F389.1090108@FreeBSD.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua X-Virus-Scanned: mail.terabit.net.ua 1Kbsro-0006zD-Rk 3ea8d3e568b573a7f5fb3a4ced494885 X-Terabit: YES Cc: Richard Todd , Pawel Jakub Dawidek , freebsd-current@freebsd.org Subject: Re: panic on shutdown anyone (insmntque())? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Sep 2008 08:10:04 -0000 --/YLrkxBeBoBPjrwx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Sep 06, 2008 at 12:35:45PM +0930, Kris Kennaway wrote: > Richard Todd wrote: > >Guy Brand writes: > > > >>Kris Kennaway (kris@freebsd.org) on 05/09/2008 at 18:21 wrote: > >> > >>>>>pjd has a fix in his p4 branch. > >>>>Same problem here with ZFS on root. Where can I find this patch? > >>>> Would be happy to test it. > >>>It was committed earlier today. > >>It fixed my shutdown panic. Thanks pjd > > > >But appears not to fix the panic I've seen trying to boot any kernel sin= ce > >the insmntque patches went in, just at the point where it tries to mount > >the root FS: > > > >Trying to mount root from zfs:rootpool/tolot-root > >KDB: stack backtrace: > >db_trace_self_wrapper(80bbd824,86ce5784,8086a0c3,874b4dc8,86ce5784,...) = at=20 > >db_trace_self_wrapper+0x26 > >kdb_backtrace(874b4dc8,86ce5784,80b1a6b5,86ce5794,874b4d70,...) at=20 > >kdb_backtrace+0x29 > >vfs_badlock(8107eda0,86ce5794,80cd8c20,874b4d70) at vfs_badlock+0x23 > >assert_vop_elocked(874b4d70,80bc7ddf,87ae406c,87ae406c,157,...) at=20 > >assert_vop_elocked+0x55 > >insmntque1(874b4d70,87b06670,80871200,0,86ce5808,...) at insmntque1+0x1c7 > >insmntque(874b4d70,87b06670,157,155,3,...) at insmntque+0x28 > >zfs_znode_alloc(3,0,e00,0,86ce585c,...) at zfs_znode_alloc+0x10d > >zfs_zget(87ae4000,3,0,86ce5950,8,...) at zfs_zget+0x1ce > >zfs_init_fs(87ae4000,86ce5950,8708fd00,87ae4008,2,...) at zfs_init_fs+0x= 2a0 > >zfs_mount(87b06670,870c4d20,80bc68f2,3f4,0,...) at zfs_mount+0x35a > >vfs_donmount(20,87af34e0,87af44c0,6,86ce5b78,...) at vfs_donmount+0x13ca > >kernel_mount(87af34e0,4001,87b03b80,ffffffff,86ce5bc0) at kernel_mount+0= x78 > >kernel_vmount(4001,80bc6bdf,87af34c0,80bc6bee,80bb3d40,...) at=20 > >kernel_vmount+0x63 > >vfs_mountroot_try(80bc6ef1,80bb3d40,80bab4a8,1,80864c00,...) at=20 > >vfs_mountroot_try+0x132 > >vfs_mountroot(80d0ceb0,4,80bb5090,264,870c2d94,...) at vfs_mountroot+0x4= 23 > >start_init(0,86ce5d38,80bb6ae4,322,870c2d0c,...) at start_init+0x65 > >fork_exit(807aca80,0,86ce5d38) at fork_exit+0xb8 > >fork_trampoline() at fork_trampoline+0x8 > >--- trap 0, eip =3D 0, esp =3D 0x86ce5d70, ebp =3D 0 --- > >insmntque: mp-safe fs and non-locked vp: 0x874b4d70 is not exclusive=20 > >locked but should be > >KDB: enter: lock violation > >[thread pid 1 tid 100002 ] > >Stopped at kdb_enter+0x3a: movl $0,kdb_why > >db>=20 >=20 > Yep, looks different. Yes, but I had an impression that pjd@ patch taken care of the issue too. The assert was added to the insmntque() function, verifying that filesystem marked mpsafe insterts exclusively locked vnode. --/YLrkxBeBoBPjrwx Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkjCOtQACgkQC3+MBN1Mb4j4QgCfdeeByaqTmCC+rBFXVQMScZdk 59sAoPP0ppUP4GIxY7ICdO4a4kLV7fO2 =qhJJ -----END PGP SIGNATURE----- --/YLrkxBeBoBPjrwx-- From owner-freebsd-current@FreeBSD.ORG Sat Sep 6 12:01:54 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BE2C01065687; Sat, 6 Sep 2008 12:01:54 +0000 (UTC) (envelope-from Yuriy.Tsibizov@gfk.com) Received: from mx2.gfk.ru (mx2.gfk.ru [84.21.231.139]) by mx1.freebsd.org (Postfix) with ESMTP id 05BD78FC1A; Sat, 6 Sep 2008 12:01:53 +0000 (UTC) (envelope-from Yuriy.Tsibizov@gfk.com) Received: from ex.hhp.local by mx2.gfk.ru (MDaemon PRO v9.6.0) with ESMTP id md50001797785.msg; Sat, 06 Sep 2008 16:02:04 +0400 Received: from [10.0.6.10] ([10.0.6.10]) by ex.hhp.local with Microsoft SMTPSVC(6.0.3790.1830); Sat, 6 Sep 2008 16:02:16 +0400 Date: Sat, 6 Sep 2008 16:02:08 +0400 (MSD) From: Yuriy Tsibizov X-X-Sender: chibis@free.home.local To: ed@freebsd.org Message-ID: <20080906160008.I2344@free.home.local> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 06 Sep 2008 12:02:17.0627 (UTC) FILETIME=[688F96B0:01C91018] X-Spam-Processed: mx2.gfk.ru, Sat, 06 Sep 2008 16:02:04 +0400 (not processed: message from valid local sender) X-MDRemoteIP: 10.0.0.30 X-Return-Path: Yuriy.Tsibizov@gfk.com X-Envelope-From: Yuriy.Tsibizov@gfk.com X-MDAV-Processed: mx2.gfk.ru, Sat, 06 Sep 2008 16:02:04 +0400 Cc: Yuriy.Tsibizov@gfk.ru, freebsd-current@freebsd.org Subject: ppp not passing long packets (probably after MPSAFE_TTY) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Sep 2008 12:01:54 -0000 Ed, I have one problem with ppp modem connection. I use mpd for dial-up connections, but ng_tty is not working any more and I had to switch back to ppp. With ping -s 960 I'm getting ~0% loss, with ping -s 980 I'm almost always getting 100% loss... But: modem TX light turns on on every attempt to send ICMP packet. Dial-up server is Windows 2000 RAS, and I had no problems with it for last five years, mostly with mpd but ppp was OK too... I can't say, was ppp broken before MPSAFE_TTY changes, but in 7-CURRENT days it was in good shape. Yuriy Tsibizov, GfK RUS Network Administrator From owner-freebsd-current@FreeBSD.ORG Sat Sep 6 12:50:41 2008 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 547671065671 for ; Sat, 6 Sep 2008 12:50:41 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [87.251.61.211]) by mx1.freebsd.org (Postfix) with ESMTP id 20B888FC0A for ; Sat, 6 Sep 2008 12:50:41 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 26CD01CC73; Sat, 6 Sep 2008 14:25:16 +0200 (CEST) Resent-From: ed@80386.nl Resent-Date: Sat, 6 Sep 2008 14:25:16 +0200 Resent-Message-ID: <20080906122516.GE99951@hoeg.nl> Resent-To: current@FreeBSD.org Date: Sat, 6 Sep 2008 14:06:43 +0200 From: Ed Schouten To: Yuriy Tsibizov Message-ID: <20080906120643.GD99951@hoeg.nl> References: <20080906152422.C2175@free.home.local> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="g9zNbg3GlIYyhcQ6" Content-Disposition: inline In-Reply-To: <20080906152422.C2175@free.home.local> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Subject: Re: ppp not passing long packets (probably after MPSAFE_TTY) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Sep 2008 12:50:41 -0000 --g9zNbg3GlIYyhcQ6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Yuriy, Thanks for reporting this issue. We should fix this. * Yuriy Tsibizov wrote: > Ed, > > I have one problem with ppp modem connection. I use mpd for dial-up =20 > connections, but ng_tty is not working any more and I had to switch back = =20 > to ppp. > > With ping -s 960 I'm getting ~0% loss, with ping -s 980 I'm almost always= =20 > getting 100% loss... But: modem TX light turns on on every attempt to=20 > send ICMP packet. > > Dial-up server is Windows 2000 RAS, and I had no problems with it for=20 > last five years, mostly with mpd but ppp was OK too... > > I can't say, was ppp broken before MPSAFE_TTY changes, but in 7-CURRENT = =20 > days it was in good shape. Could you give me the output of `pstat -t' while using `ppp'? What device node/device driver are you using? I know there are some things fishy w.r.t. flow control, so there are a lot of things we can look in to. Is it somehow possible to get some kind of `debug output' from the Windows machine as well? Thanks! --=20 Ed Schouten WWW: http://80386.nl/ --g9zNbg3GlIYyhcQ6 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkjCclMACgkQ52SDGA2eCwXvMgCfZJ+RSCbMLOpBGa9tuD8ZPNt4 AgUAn077wVDgtFHmOn2FC+ezudzvYYvn =9Y88 -----END PGP SIGNATURE----- --g9zNbg3GlIYyhcQ6-- From owner-freebsd-current@FreeBSD.ORG Sat Sep 6 12:52:08 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E6D9D1065679 for ; Sat, 6 Sep 2008 12:52:07 +0000 (UTC) (envelope-from Yuriy.Tsibizov@gfk.com) Received: from mx2.gfk.ru (mx2.gfk.ru [84.21.231.139]) by mx1.freebsd.org (Postfix) with ESMTP id 441CB8FC25 for ; Sat, 6 Sep 2008 12:52:06 +0000 (UTC) (envelope-from Yuriy.Tsibizov@gfk.com) Received: from ex.hhp.local by mx2.gfk.ru (MDaemon PRO v9.6.0) with ESMTP id md50001797896.msg for ; Sat, 06 Sep 2008 16:52:15 +0400 Received: from [10.0.6.4] ([10.0.6.4]) by ex.hhp.local with Microsoft SMTPSVC(6.0.3790.1830); Sat, 6 Sep 2008 16:51:01 +0400 Date: Sat, 6 Sep 2008 16:50:54 +0400 (MSD) From: Yuriy Tsibizov X-X-Sender: chibis@free.home.local To: Ed Schouten In-Reply-To: <20080906120643.GD99951@hoeg.nl> Message-ID: <20080906164146.F2728@free.home.local> References: <20080906152422.C2175@free.home.local> <20080906120643.GD99951@hoeg.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 06 Sep 2008 12:52:16.0344 (UTC) FILETIME=[63EF7D80:01C9101F] X-Spam-Processed: mx2.gfk.ru, Sat, 06 Sep 2008 16:52:15 +0400 (not processed: message from valid local sender) X-MDRemoteIP: 10.0.0.30 X-Return-Path: Yuriy.Tsibizov@gfk.com X-Envelope-From: Yuriy.Tsibizov@gfk.com X-MDaemon-Deliver-To: freebsd-current@freebsd.org X-MDAV-Processed: mx2.gfk.ru, Sat, 06 Sep 2008 16:52:17 +0400 Cc: Yuriy Tsibizov , freebsd-current@freebsd.org Subject: Re: ppp not passing long packets (probably after MPSAFE_TTY) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Sep 2008 12:52:08 -0000 On Sat, 6 Sep 2008, Ed Schouten wrote: > Thanks for reporting this issue. We should fix this. > >> Ed, >> >> I have one problem with ppp modem connection. I use mpd for dial-up >> connections, but ng_tty is not working any more and I had to switch back >> to ppp. >> >> With ping -s 960 I'm getting ~0% loss, with ping -s 980 I'm almost always >> getting 100% loss... But: modem TX light turns on on every attempt to >> send ICMP packet. >> >> Dial-up server is Windows 2000 RAS, and I had no problems with it for >> last five years, mostly with mpd but ppp was OK too... >> >> I can't say, was ppp broken before MPSAFE_TTY changes, but in 7-CURRENT >> days it was in good shape. > > Could you give me the output of `pstat -t' while using `ppp'? What > device node/device driver are you using? I know there are some things > fishy w.r.t. flow control, so there are a lot of things we can look in > to. free# pstat -t LINE INQ CAN LIN LOW OUTQ USE LOW COL SESS PGID STATE sysmouse 0 0 0 0 0 0 0 0 0 0 - dcons 7680 0 0 768 7812 0 782 0 0 0 Oi dgdb 0 0 0 0 0 0 0 0 0 0 - ttyv0 7680 0 0 768 7812 0 782 175 1741 1741 Oil ttyv1 7680 0 0 768 7812 0 782 13 1742 2718 Oi ttyv2 7680 0 0 768 7812 0 782 0 1743 2729 Oi ttyv3 7680 0 0 768 7812 0 782 30417 1744 2439 Oi ttyv4 7680 0 0 768 7812 0 782 7 1745 1745 Oil ttyv5 7680 0 0 768 7812 0 782 10 1746 2728 Oi ttyv6 7680 0 0 768 7812 0 782 103319 1747 1919 Oi ttyv7 7680 0 0 768 7812 0 782 24922 1748 2719 Oi ttyv8 0 0 0 0 0 0 0 0 0 0 - ttyv9 0 0 0 0 0 0 0 0 0 0 - ttyva 0 0 0 0 0 0 0 0 0 0 - ttyvb 0 0 0 0 0 0 0 0 0 0 - ttyvc 0 0 0 0 0 0 0 0 0 0 - ttyvd 0 0 0 0 0 0 0 0 0 0 - ttyve 0 0 0 0 0 0 0 0 0 0 - ttyvf 0 0 0 0 0 0 0 0 0 0 - consolectl 7680 0 0 768 7812 0 782 0 0 0 Oi ttyu0 0 0 0 0 0 0 0 0 0 0 IC ttyu1 23040 0 0 2304 23184 0 2319 4757976 0 0 ICOol free# uname -a FreeBSD free.home.local 8.0-CURRENT FreeBSD 8.0-CURRENT #1: Sun Aug 31 08:48:35MSD 2008 chibis@free.home.local:/usr/obj/usr/src/sys/GENERIC i386 free# dmesg | grep uart uart0: <16550 or compatible> at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 uart0: [FILTER] uart1: <16550 or compatible> at port 0x2f8-0x2ff irq 3 on isa0 uart1: [FILTER] > > Is it somehow possible to get some kind of `debug output' from the > Windows machine as well? Thanks! hm... Not shure if I can dig any debugging from it. I can try to move modems to FreeBSD (6.3 or 7.0) machine, but it will take some time. Yuriy Tsibizov, GfK RUS Network Administrator From owner-freebsd-current@FreeBSD.ORG Sat Sep 6 12:52:10 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CFB671065676 for ; Sat, 6 Sep 2008 12:52:10 +0000 (UTC) (envelope-from Yuriy.Tsibizov@gfk.com) Received: from mx2.gfk.ru (mx2.gfk.ru [84.21.231.139]) by mx1.freebsd.org (Postfix) with ESMTP id 2C3708FC35 for ; Sat, 6 Sep 2008 12:52:09 +0000 (UTC) (envelope-from Yuriy.Tsibizov@gfk.com) Received: from ex.hhp.local by mx2.gfk.ru (MDaemon PRO v9.6.0) with ESMTP id md50001797897.msg for ; Sat, 06 Sep 2008 16:52:20 +0400 Received: from [10.0.6.4] ([10.0.6.4]) by ex.hhp.local with Microsoft SMTPSVC(6.0.3790.1830); Sat, 6 Sep 2008 16:52:27 +0400 Date: Sat, 6 Sep 2008 16:52:21 +0400 (MSD) From: Yuriy Tsibizov X-X-Sender: chibis@free.home.local To: Ed Schouten In-Reply-To: <20080906120643.GD99951@hoeg.nl> Message-ID: <20080906165203.K2728@free.home.local> References: <20080906152422.C2175@free.home.local> <20080906120643.GD99951@hoeg.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 06 Sep 2008 12:52:27.0938 (UTC) FILETIME=[6AD89820:01C9101F] X-Spam-Processed: mx2.gfk.ru, Sat, 06 Sep 2008 16:52:20 +0400 (not processed: message from valid local sender) X-MDRemoteIP: 10.0.0.30 X-Return-Path: Yuriy.Tsibizov@gfk.com X-Envelope-From: Yuriy.Tsibizov@gfk.com X-MDaemon-Deliver-To: freebsd-current@freebsd.org X-MDAV-Processed: mx2.gfk.ru, Sat, 06 Sep 2008 16:52:21 +0400 Cc: Yuriy Tsibizov , freebsd-current@freebsd.org Subject: Re: ppp not passing long packets (probably after MPSAFE_TTY) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Sep 2008 12:52:10 -0000 On Sat, 6 Sep 2008, Ed Schouten wrote: > Thanks for reporting this issue. We should fix this. > >> Ed, >> >> I have one problem with ppp modem connection. I use mpd for dial-up >> connections, but ng_tty is not working any more and I had to switch back >> to ppp. >> >> With ping -s 960 I'm getting ~0% loss, with ping -s 980 I'm almost always >> getting 100% loss... But: modem TX light turns on on every attempt to >> send ICMP packet. >> >> Dial-up server is Windows 2000 RAS, and I had no problems with it for >> last five years, mostly with mpd but ppp was OK too... >> >> I can't say, was ppp broken before MPSAFE_TTY changes, but in 7-CURRENT >> days it was in good shape. > > Could you give me the output of `pstat -t' while using `ppp'? What > device node/device driver are you using? I know there are some things > fishy w.r.t. flow control, so there are a lot of things we can look in > to. free# pstat -t LINE INQ CAN LIN LOW OUTQ USE LOW COL SESS PGID STATE sysmouse 0 0 0 0 0 0 0 0 0 0 - dcons 7680 0 0 768 7812 0 782 0 0 0 Oi dgdb 0 0 0 0 0 0 0 0 0 0 - ttyv0 7680 0 0 768 7812 0 782 175 1741 1741 Oil ttyv1 7680 0 0 768 7812 0 782 13 1742 2718 Oi ttyv2 7680 0 0 768 7812 0 782 0 1743 2729 Oi ttyv3 7680 0 0 768 7812 0 782 30417 1744 2439 Oi ttyv4 7680 0 0 768 7812 0 782 7 1745 1745 Oil ttyv5 7680 0 0 768 7812 0 782 10 1746 2728 Oi ttyv6 7680 0 0 768 7812 0 782 103319 1747 1919 Oi ttyv7 7680 0 0 768 7812 0 782 24922 1748 2719 Oi ttyv8 0 0 0 0 0 0 0 0 0 0 - ttyv9 0 0 0 0 0 0 0 0 0 0 - ttyva 0 0 0 0 0 0 0 0 0 0 - ttyvb 0 0 0 0 0 0 0 0 0 0 - ttyvc 0 0 0 0 0 0 0 0 0 0 - ttyvd 0 0 0 0 0 0 0 0 0 0 - ttyve 0 0 0 0 0 0 0 0 0 0 - ttyvf 0 0 0 0 0 0 0 0 0 0 - consolectl 7680 0 0 768 7812 0 782 0 0 0 Oi ttyu0 0 0 0 0 0 0 0 0 0 0 IC ttyu1 23040 0 0 2304 23184 0 2319 4757976 0 0 ICOol free# uname -a FreeBSD free.home.local 8.0-CURRENT FreeBSD 8.0-CURRENT #1: Sun Aug 31 08:48:35MSD 2008 chibis@free.home.local:/usr/obj/usr/src/sys/GENERIC i386 free# dmesg | grep uart uart0: <16550 or compatible> at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 uart0: [FILTER] uart1: <16550 or compatible> at port 0x2f8-0x2ff irq 3 on isa0 uart1: [FILTER] > > Is it somehow possible to get some kind of `debug output' from the > Windows machine as well? Thanks! hm... Not shure if I can dig any debugging from it. I can try to move modems to FreeBSD (6.3 or 7.0) machine, but it will take some time. Yuriy Tsibizov, GfK RUS Network Administrator From owner-freebsd-current@FreeBSD.ORG Sat Sep 6 16:28:43 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7758A1065688 for ; Sat, 6 Sep 2008 16:28:43 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from services.ipt.ru (services.ipt.ru [194.62.233.110]) by mx1.freebsd.org (Postfix) with ESMTP id 3BB288FC1E for ; Sat, 6 Sep 2008 16:28:43 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from bb.ipt.ru ([194.62.233.89]) by services.ipt.ru with esmtp (Exim 4.54 (FreeBSD)) id 1Kc0JO-0001a9-NB; Sat, 06 Sep 2008 20:06:58 +0400 To: Norikatsu Shigemura References: <20080826005920.8aca164b.nork@FreeBSD.org> <20080906080801.8099c753.nork@ninth-nine.com> From: Boris Samorodov Date: Sat, 06 Sep 2008 20:06:50 +0400 In-Reply-To: <20080906080801.8099c753.nork@ninth-nine.com> (Norikatsu Shigemura's message of "Sat\, 6 Sep 2008 08\:08\:01 +0900") Message-ID: <47655429@bb.ipt.ru> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-current@freebsd.org Subject: Re: Do you need x11-drivers/xf86-video-radeonhd-devel? (Re: How about AMD Puma platform support?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Sep 2008 16:28:43 -0000 On Sat, 6 Sep 2008 08:08:01 +0900 Norikatsu Shigemura wrote: > On Tue, 26 Aug 2008 00:59:20 +0900 > Norikatsu Shigemura wrote: > > ??: AMD M780G (ATI Radeon HD 3200) > > I don't test, yet. > OK, I confirmed that latest xf86-video-radeonhd driver is good > works. To get that result, I made a ports/x11-drivers/xf86-video- > radeonhd-devel port. Anyone do you need this port, too? Sure. Thanks! WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-current@FreeBSD.ORG Sat Sep 6 17:24:44 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 98247106568E; Sat, 6 Sep 2008 17:24:44 +0000 (UTC) (envelope-from jasone@FreeBSD.org) Received: from canonware.com (canonware.com [64.183.146.166]) by mx1.freebsd.org (Postfix) with ESMTP id 6AA0C8FC15; Sat, 6 Sep 2008 17:24:44 +0000 (UTC) (envelope-from jasone@FreeBSD.org) Received: from [192.168.168.201] (unknown [192.168.168.201]) by canonware.com (Postfix) with ESMTP id D70E61298C0; Sat, 6 Sep 2008 10:00:41 -0700 (PDT) Message-ID: <48C2B6EB.5000608@FreeBSD.org> Date: Sat, 06 Sep 2008 09:59:23 -0700 From: Jason Evans User-Agent: Thunderbird 2.0.0.16 (X11/20080724) MIME-Version: 1.0 To: Jille Timmermans References: <48C15AEA.4070704@quis.cx> In-Reply-To: <48C15AEA.4070704@quis.cx> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current , David Xu Subject: Re: Segmentation fault in malloc_usable_size() (libc) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Sep 2008 17:24:44 -0000 Jille Timmermans wrote: > I switched over to current a fews days ago. > And I ran into a bug (file attached, log pasted): The stack trace you got is totally bogus, but the problem is real. This crash is due to recent changes in malloc that use TLS for thread-specific caching. The problem is that malloc is being used after a thread has effectively exited. #0 0x00000008007c7b35 in arena_malloc (arena=0x500a98, size=80, zero=true) at /usr/src/lib/libc/stdlib/malloc.c:3223 #1 0x00000008007caf4b in calloc (num=1, size=80) at /usr/src/lib/libc/stdlib/malloc.c:3395 #2 0x0000000800649c94 in mutex_init (mutex=0x8009785c0, mutex_attr=Variable "mutex_attr" is not available. ) at /usr/src/lib/libthr/thread/thr_mutex.c:144 #3 0x0000000800649f41 in init_static (thread=0x608e40, mutex=0x8009785c0) at /usr/src/lib/libthr/thread/thr_mutex.c:188 #4 0x000000080064ab31 in __pthread_mutex_lock (mutex=0x8009785c0) at /usr/src/lib/libthr/thread/thr_mutex.c:445 #5 0x000000080081c63c in __cxa_finalize (dso=0x0) at /usr/src/lib/libc/stdlib/atexit.c:161 #6 0x00000008007ccbe7 in exit (status=0) at /usr/src/lib/libc/stdlib/exit.c:67 #7 0x000000080064e5c6 in _pthread_exit (status=Variable "status" is not available. ) at /usr/src/lib/libthr/thread/thr_exit.c:109 #8 0x0000000800646219 in thread_start (curthread=0x608e40) at /usr/src/lib/libthr/thread/thr_create.c:288 #9 0x0000000000000000 in ?? () The call to _malloc_thread_cleanup() in _pthread_exit() I added at /usr/src/lib/libthr/thread/thr_exit.c:100 is too early in the case that _thread_active_threads is decremented to 0 below. I don't know off the top of my head what the best fix is (i.e. where the _malloc_thread_cleanup() call is really safe); perhaps David Xu has a suggestion. Thanks, Jason From owner-freebsd-current@FreeBSD.ORG Sat Sep 6 18:12:50 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9B02A106566B for ; Sat, 6 Sep 2008 18:12:50 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello087206045140.chello.pl [87.206.45.140]) by mx1.freebsd.org (Postfix) with ESMTP id B0C468FC1B for ; Sat, 6 Sep 2008 18:12:48 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id DDFDA45C9C; Sat, 6 Sep 2008 20:12:46 +0200 (CEST) Received: from localhost (abhz137.neoplus.adsl.tpnet.pl [83.7.115.137]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 7FA63456AB; Sat, 6 Sep 2008 20:12:41 +0200 (CEST) Date: Sat, 6 Sep 2008 20:12:43 +0200 From: Pawel Jakub Dawidek To: Richard Todd Message-ID: <20080906181243.GA1209@garage.freebsd.pl> References: <48C0B59F.4030200@delphij.net> <48C0B781.40200@FreeBSD.org> <48C0BB1A.4020906@delphij.net> <48C0BC80.3000107@FreeBSD.org> <20080905092922.1aaa95f0@dilbert.office.centralnic.com> <48C0F320.5040002@FreeBSD.org> <20080905202525.GB1656@isis.u-strasbg.fr> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="h31gzZEtNLTqOjlF" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 8.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-0.6 required=3.0 tests=BAYES_00,RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: freebsd-current@freebsd.org Subject: Re: panic on shutdown anyone (insmntque())? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Sep 2008 18:12:50 -0000 --h31gzZEtNLTqOjlF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 05, 2008 at 07:01:55PM -0500, Richard Todd wrote: > Guy Brand writes: >=20 > > Kris Kennaway (kris@freebsd.org) on 05/09/2008 at 18:21 wrote: > > > >> >> pjd has a fix in his p4 branch. > >> >=20 > >> > Same problem here with ZFS on root. Where can I find this patch? > >> > Would be happy to test it. > >>=20 > >> It was committed earlier today. > > > > It fixed my shutdown panic. Thanks pjd >=20 > But appears not to fix the panic I've seen trying to boot any kernel since > the insmntque patches went in, just at the point where it tries to mount > the root FS: [...] I committed another fix, try now. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --h31gzZEtNLTqOjlF Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFIwsgbForvXbEpPzQRAv0HAJ9IBjNQuCDP1qbFPf40z8UrufvRLgCfVtc5 5qKJADfXX1kWE0rgFvBcygE= =d7S5 -----END PGP SIGNATURE----- --h31gzZEtNLTqOjlF--