From owner-freebsd-current@FreeBSD.ORG Sun Jun 14 00:37:26 2009 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 2C8CF106564A for ; Sun, 14 Jun 2009 00:37:26 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout018.mac.com (asmtpout018.mac.com [17.148.16.93]) by mx1.freebsd.org (Postfix) with ESMTP id 18B7B8FC08 for ; Sun, 14 Jun 2009 00:37:26 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from MacBook-Pro.lan.xcllnt.net (mail.xcllnt.net [75.101.29.67]) by asmtp018.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KL7000JOAYD3R70@asmtp018.mac.com> for freebsd-current@FreeBSD.org; Sat, 13 Jun 2009 16:37:25 -0700 (PDT) Message-id: From: Marcel Moolenaar To: Alexander Best In-reply-to: Date: Sat, 13 Jun 2009 16:37:25 -0700 References: X-Mailer: Apple Mail (2.935.3) Cc: freebsd-current@FreeBSD.org Subject: Re: `gpart show` and secondary GPT header 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, 14 Jun 2009 00:37:26 -0000 On Jun 13, 2009, at 11:53 AM, Alexander Best wrote: > hi there, > > i already posted this message to freebsd-questions but didn't get > any reply. > that's why i'm sending it to freebsd-current. > > i have a question about gpart. when id do `gpart show ad0` i get the > following > output: > > => 34 488394988 ad0 GPT (233G) > 34 20971486 1 freebsd-swap (10G) > 20971520 467423502 2 freebsd-ufs (223G) > > which is just what i want. however i'm a bit curious about the GPT > header. > only the primary header from 0 - 33 is being shown. what about the > secondary/backup GPT header. is it present and just now shown by > gpart or > doesn't it exist at all? if it's just not shown it would be great if > gpart had > a verbose switch or something like that. gpart(8) does not show headers at all. The first line merely shows the first possible LBA that can be assigned to a partition and the amount of space that can be assigned (starting from the first LBA). This information also applies to any other scheme, eg: ns1% gpart show ad0 => 63 80293185 ad0 MBR (38G) 63 80292807 1 freebsd [active] (38G) 80292870 378 - free - (189K) ns1% gpart show ad0s1 => 0 80292807 ad0s1 BSD (38G) 0 2097152 1 freebsd-ufs (1.0G) 2097152 16777216 2 freebsd-swap (8.0G) 18874368 16777216 4 freebsd-ufs (8.0G) 35651584 44641223 5 freebsd-ufs (21G) Typically the sector before the first allocatable LBA and extending beyond the allocatable space are used for metadata (i.e. the GPT headers), but that may not be the case. In any case: the primary and secondary GPT headers and tables are in fact on the disk. They're there, trust me :-) > > because in 7-STABLE e.g. `pt show ad0` also displays the secondary > GPT header > at the end of the disk. gpart(8) is unlike gpt(8) in having in-depth knowledge of the on-disk representation. This is a deliberate abstraction. FYI, -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Sun Jun 14 00:56:22 2009 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 0DC141065670 for ; Sun, 14 Jun 2009 00:56:22 +0000 (UTC) (envelope-from james-freebsd-current@jrv.org) Received: from mail.jrv.org (rrcs-24-73-246-106.sw.biz.rr.com [24.73.246.106]) by mx1.freebsd.org (Postfix) with ESMTP id C55238FC1B for ; Sun, 14 Jun 2009 00:56:21 +0000 (UTC) (envelope-from james-freebsd-current@jrv.org) Received: from kremvax.housenet.jrv (kremvax.housenet.jrv [192.168.3.124]) by mail.jrv.org (8.14.3/8.14.3) with ESMTP id n5E0uKkJ009823; Sat, 13 Jun 2009 19:56:20 -0500 (CDT) (envelope-from james-freebsd-current@jrv.org) Authentication-Results: mail.jrv.org; domainkeys=pass (testing) header.from=james-freebsd-current@jrv.org DomainKey-Signature: a=rsa-sha1; s=enigma; d=jrv.org; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=kj75XokHCPL69Sir7o/PzIvyp8cdTHitDcmr9yGSIxPhC8Rvwr3yBGQY6cSj+Kuur T9/hPdzDju6ooHpP7XWKF26VnAs7qTC8FEk86qowK/mEw9BoMiI6s2E9B3SlBsgRGxI H4DSGW70OLK7AzN/mBKJv8nggMgWZGcCQdii32w= Message-ID: <4A344A9F.5020708@jrv.org> Date: Sat, 13 Jun 2009 19:55:59 -0500 From: "James R. Van Artsdalen" User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Alexander Best , FreeBSD Current , Marcel Moolenaar Subject: Re: `gpart show` and secondary GPT header 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, 14 Jun 2009 00:56:22 -0000 Marcel Moolenaar wrote: > In any case: the primary and secondary GPT headers > and tables are in fact on the disk. They're there, > trust me :-) Unless you're using a Silicon Image 3124 controller :-( FYI - the option ROM on this card appears to clobber the secondary GPT table. Moving disks to a 3124 results in this: Jun 13 06:31:42 bigback kernel: GEOM: ad4: the secondary GPT table is corrupt or invalid. Jun 13 06:31:42 bigback kernel: GEOM: ad4: using the primary only -- recovery suggested. Jun 13 06:31:42 bigback kernel: GEOM: ad12: the secondary GPT table is corrupt or invalid. Jun 13 06:31:42 bigback kernel: GEOM: ad12: using the primary only -- recovery suggested. Not our fault - just thought I'd mention it in case it comes up again, or if someone searches for that error message. PS. The man page might make a mention of what "recovery" is if there's some way other than dd(1) to do it. From owner-freebsd-current@FreeBSD.ORG Sun Jun 14 00:59:27 2009 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 5FB2F106566C for ; Sun, 14 Jun 2009 00:59:27 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout022.mac.com (asmtpout022.mac.com [17.148.16.97]) by mx1.freebsd.org (Postfix) with ESMTP id 4A5398FC16 for ; Sun, 14 Jun 2009 00:59:27 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed Received: from marcelm-sslvpn-nc.jnpr.net (nat-service4.juniper.net [66.129.225.151]) by asmtp022.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KL700EYIER1L340@asmtp022.mac.com> for freebsd-current@freebsd.org; Sat, 13 Jun 2009 17:59:27 -0700 (PDT) Message-id: From: Marcel Moolenaar To: "James R. Van Artsdalen" In-reply-to: <4A344A9F.5020708@jrv.org> Date: Sat, 13 Jun 2009 17:59:25 -0700 References: <4A344A9F.5020708@jrv.org> X-Mailer: Apple Mail (2.935.3) Cc: Alexander Best , FreeBSD Current Subject: Re: `gpart show` and secondary GPT header 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, 14 Jun 2009 00:59:27 -0000 On Jun 13, 2009, at 5:55 PM, James R. Van Artsdalen wrote: > Marcel Moolenaar wrote: >> In any case: the primary and secondary GPT headers >> and tables are in fact on the disk. They're there, >> trust me :-) > > Unless you're using a Silicon Image 3124 controller :-( > > FYI - the option ROM on this card appears to clobber the secondary GPT > table. Moving disks to a 3124 results in this: > Jun 13 06:31:42 bigback kernel: GEOM: ad4: the secondary GPT table is > corrupt or invalid. > Jun 13 06:31:42 bigback kernel: GEOM: ad4: using the primary only -- > recovery suggested. > Jun 13 06:31:42 bigback kernel: GEOM: ad12: the secondary GPT table is > corrupt or invalid. > Jun 13 06:31:42 bigback kernel: GEOM: ad12: using the primary only -- > recovery suggested. Are you using gmirror by any chance? -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Sun Jun 14 01:03:57 2009 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 6956E1065675 for ; Sun, 14 Jun 2009 01:03:57 +0000 (UTC) (envelope-from james-freebsd-current@jrv.org) Received: from mail.jrv.org (rrcs-24-73-246-106.sw.biz.rr.com [24.73.246.106]) by mx1.freebsd.org (Postfix) with ESMTP id 1062E8FC16 for ; Sun, 14 Jun 2009 01:03:56 +0000 (UTC) (envelope-from james-freebsd-current@jrv.org) Received: from kremvax.housenet.jrv (kremvax.housenet.jrv [192.168.3.124]) by mail.jrv.org (8.14.3/8.14.3) with ESMTP id n5E13ujP009874; Sat, 13 Jun 2009 20:03:56 -0500 (CDT) (envelope-from james-freebsd-current@jrv.org) Authentication-Results: mail.jrv.org; domainkeys=pass (testing) header.from=james-freebsd-current@jrv.org DomainKey-Signature: a=rsa-sha1; s=enigma; d=jrv.org; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=XVEA2AfNQQozZDlPrMRQzAU3BggvGKg42WmiBXYu7pkpMKHvQh3k2un8twlArYA3X 4idGv7vl5GnlJL7bP1Z27g707W0vYfaaeclNjY6ZiDu9IzGfgWHyCuEddzKLddctMGl Mt4XjpkA5kj5cpnB0lQhYPMzkWs9rFJ0QxHiHpU= Message-ID: <4A344C67.8000101@jrv.org> Date: Sat, 13 Jun 2009 20:03:35 -0500 From: "James R. Van Artsdalen" User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Marcel Moolenaar References: <4A344A9F.5020708@jrv.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Alexander Best , FreeBSD Current Subject: Re: `gpart show` and secondary GPT header 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, 14 Jun 2009 01:03:57 -0000 Marcel Moolenaar wrote: > > On Jun 13, 2009, at 5:55 PM, James R. Van Artsdalen wrote: > > >> Jun 13 06:31:42 bigback kernel: GEOM: ad4: the secondary GPT table is >> corrupt or invalid. >> Jun 13 06:31:42 bigback kernel: GEOM: ad4: using the primary only -- >> recovery suggested. >> Jun 13 06:31:42 bigback kernel: GEOM: ad12: the secondary GPT table is >> corrupt or invalid. >> Jun 13 06:31:42 bigback kernel: GEOM: ad12: using the primary only -- >> recovery suggested. > > Are you using gmirror by any chance? Partitions 2-6 use gmirror. # gpart show ad4 => 34 2930277101 ad4 GPT (1.4T) 34 128 1 freebsd-boot (64K) 162 8388608 2 freebsd-ufs (4.0G) 8388770 41943040 3 freebsd-swap (20G) 50331810 8388608 4 freebsd-ufs (4.0G) 58720418 67108864 5 freebsd-ufs (32G) 125829282 8388608 6 freebsd-ufs (4.0G) 134217890 2796059245 7 freebsd-zfs (1.3T) # gmirror status Name Status Components mirror/bigroot COMPLETE ad4p2 ad12p2 mirror/bigswap COMPLETE ad4p3 ad12p3 mirror/bigtmp COMPLETE ad4p4 ad12p4 mirror/bigusr COMPLETE ad4p5 ad12p5 mirror/bigvar COMPLETE ad4p6 ad12p6 From owner-freebsd-current@FreeBSD.ORG Sun Jun 14 05:23:36 2009 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 E653B1065670 for ; Sun, 14 Jun 2009 05:23:36 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout013.mac.com (asmtpout013.mac.com [17.148.16.88]) by mx1.freebsd.org (Postfix) with ESMTP id D1C3F8FC08 for ; Sun, 14 Jun 2009 05:23:36 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from MacBook-Pro.lan.xcllnt.net (mail.xcllnt.net [75.101.29.67]) by asmtp013.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KL700HS5QZ64S70@asmtp013.mac.com> for freebsd-current@freebsd.org; Sat, 13 Jun 2009 22:23:36 -0700 (PDT) Message-id: From: Marcel Moolenaar To: "James R. Van Artsdalen" In-reply-to: <4A344C67.8000101@jrv.org> Date: Sat, 13 Jun 2009 22:23:29 -0700 References: <4A344A9F.5020708@jrv.org> <4A344C67.8000101@jrv.org> X-Mailer: Apple Mail (2.935.3) Cc: Alexander Best , FreeBSD Current Subject: Re: `gpart show` and secondary GPT header 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, 14 Jun 2009 05:23:37 -0000 On Jun 13, 2009, at 6:03 PM, James R. Van Artsdalen wrote: > Marcel Moolenaar wrote: >> >> On Jun 13, 2009, at 5:55 PM, James R. Van Artsdalen wrote: >> >> >>> Jun 13 06:31:42 bigback kernel: GEOM: ad4: the secondary GPT table >>> is >>> corrupt or invalid. >>> Jun 13 06:31:42 bigback kernel: GEOM: ad4: using the primary only -- >>> recovery suggested. >>> Jun 13 06:31:42 bigback kernel: GEOM: ad12: the secondary GPT >>> table is >>> corrupt or invalid. >>> Jun 13 06:31:42 bigback kernel: GEOM: ad12: using the primary only >>> -- >>> recovery suggested. >> >> Are you using gmirror by any chance? > > Partitions 2-6 use gmirror. Ok. Unrelated then. When gmirror is used on the whole disk, then it's possible that you get this error. The problem is that there's no guarantee that gpart tastes always before or always after gmirror. If you put gpart on top of gmirror, then gpart sees a disk that's 1 sector smaller than the disk gmirror sees. If gpart gets to taste before gmirror, it won't find the backup header in the last sector, because it's where gmirror puts its metadata. Mirroring partitions does not have this problem... -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Sun Jun 14 07:11:27 2009 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 46BFD1065670 for ; Sun, 14 Jun 2009 07:11:27 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from mout2.freenet.de (mout2.freenet.de [IPv6:2001:748:100:40::2:4]) by mx1.freebsd.org (Postfix) with ESMTP id D51C18FC17 for ; Sun, 14 Jun 2009 07:11:26 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from [195.4.92.11] (helo=1.mx.freenet.de) by mout2.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #88) id 1MFjsD-0001UP-E4 for freebsd-current@freebsd.org; Sun, 14 Jun 2009 09:11:25 +0200 Received: from t8599.t.pppool.de ([89.55.133.153]:53862 helo=ernst.jennejohn.org) by 1.mx.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #79) id 1MFjsD-00049o-3K for freebsd-current@freebsd.org; Sun, 14 Jun 2009 09:11:25 +0200 Date: Sun, 14 Jun 2009 09:11:24 +0200 From: Gary Jennejohn To: freebsd-current@freebsd.org Message-ID: <20090614091124.26e7e959@ernst.jennejohn.org> In-Reply-To: <59048837.48941.1244927528071.JavaMail.apache@mail51.abv.bg> References: <59048837.48941.1244927528071.JavaMail.apache@mail51.abv.bg> X-Mailer: Claws Mail 3.7.1 (GTK+ 2.14.7; amd64-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Call For Testing] VirtualBox for FreeBSD! take 6 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gary.jennejohn@freenet.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jun 2009 07:11:27 -0000 On Sun, 14 Jun 2009 00:12:08 +0300 (EEST) Mario Pavlov wrote: > anyway, it's very nice to have a real virtualization software on FreeBSD! :) > thanks to all who made this possible!! > Hear, hear! I now have Windows XP, Windows 7 RC and openSUSE 11.1 running in VirtualBox and I just love it! Beats the hell out of installing on real hardware. --- Gary Jennejohn From owner-freebsd-current@FreeBSD.ORG Sun Jun 14 07:48:53 2009 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 E6C97106566C for ; Sun, 14 Jun 2009 07:48:53 +0000 (UTC) (envelope-from freebsd@abv.bg) Received: from smtp-out.abv.bg (smtp-out.abv.bg [194.153.145.99]) by mx1.freebsd.org (Postfix) with ESMTP id 26CF28FC13 for ; Sun, 14 Jun 2009 07:48:51 +0000 (UTC) (envelope-from freebsd@abv.bg) Received: from mail54.abv.bg (mail54.ni.bg [192.168.151.57]) by smtp-out.abv.bg (Postfix) with ESMTP id C128014EBDE for ; Sun, 14 Jun 2009 10:48:23 +0300 (EEST) DomainKey-Signature: a=rsa-sha1; s=smtp-out; d=abv.bg; c=simple; q=dns; b=xekPiJ3kVqrICDZTaIfuVFoaQh9qgzyLTAgE7G5lfBNvQt2wZjbXvocOTnwDOjbwo beVHljSxk/wuxa/1Y4WZi77vHyNaPFLmN9szG3kxotUvAzUZ0dzCj9tBcZVFkAXzEzz d1bdSBPUwOqpbT5Q7N9dgJHd39frsCskBT4iY/U= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=abv.bg; s=smtp-out; t=1244965703; bh=fbI6PoYqJpPj4H475Umq4SkwvUInIH2SxPA9qlLP66Q=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type:DKIM; b=S+SVbLgrSFTvXqwJwe6rfL9LjbNg0L9DbaQ+Hg1GCgqSyJ37gsXepZRzUMvnytAWB +E4m98pXohJ51R/g/AUOKr9CfAakJ4kyUPrVA4lx+2OJMCMv1YQpconXlOAWxXfdYIM RpcEHOdCnFokkEhiOhjKcAKbDfFrCa2d36LJafM= Received: from mail54.abv.bg (mail54.abv.bg [127.0.0.1]) by mail54.abv.bg (Postfix) with ESMTP id AF02A11EE64 for ; Sun, 14 Jun 2009 10:48:50 +0300 (EEST) Date: Sun, 14 Jun 2009 10:48:50 +0300 (EEST) From: Mario Pavlov To: freebsd-current@freebsd.org Message-ID: <1926329041.48429.1244965730715.JavaMail.apache@mail54.abv.bg> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_48427_467409884.1244965730704" X-Priority: 3 X-Mailer: AbvMail 1.0 X-Originating-IP: 78.128.21.208 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: Re: [Call For Testing] VirtualBox for FreeBSD! take 6 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, 14 Jun 2009 07:48:54 -0000 ------=_Part_48427_467409884.1244965730704 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Hi, I just wanted to see if someone has this problem please find attached a screenshot ...on the host OS the round-trip time is no more than 3-4ms but on the guess OS it jumps a lot higher (500-600ms)... regards, mgp ------=_Part_48427_467409884.1244965730704-- From owner-freebsd-current@FreeBSD.ORG Sun Jun 14 08:25:07 2009 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 04E2C106564A for ; Sun, 14 Jun 2009 08:25:07 +0000 (UTC) (envelope-from uucp@gromit.grondar.org) Received: from gromit.grondar.org (unknown [IPv6:2001:ba8:0:1d5:216:d4ff:fe0d:d845]) by mx1.freebsd.org (Postfix) with ESMTP id 9A75F8FC20 for ; Sun, 14 Jun 2009 08:25:06 +0000 (UTC) (envelope-from uucp@gromit.grondar.org) Received: from uucp by gromit.grondar.org with local (Exim 4.69) (envelope-from ) id 1MFlG0-0003uf-VB for current@freebsd.org; Sun, 14 Jun 2009 09:40:04 +0100 Received: from localhost ([127.0.0.1] helo=greatest.grondar.org) by greatest.grondar.org with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MFkyG-000IUX-Ia; Sun, 14 Jun 2009 09:21:44 +0100 To: Marcel Moolenaar In-reply-to: <1464A93A-D187-476F-A143-E37EB6BB01EF@mac.com> References: <1464A93A-D187-476F-A143-E37EB6BB01EF@mac.com> From: Mark Murray Date: Sun, 14 Jun 2009 09:21:44 +0100 Message-Id: Sender: UNIX-to-UNIX Copy Cc: "current@freebsd.org" Subject: Re: Build is polluted by host build environment. 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, 14 Jun 2009 08:25:07 -0000 Marcel Moolenaar writes: > cc_tools is supposed to use /usr/include when it's building the cross > tools, so your email does not demonstrate a problem per se. I said in the original email that the building was fine for all the tools stuff, and that the failure occurred once the "real" build got under way. If you look at the patch I supplied, you'll see that I only break /usr/include once the tools are done. Having done that, the real build proceeds, and breaks in cc_tools for the reason stated. Full build log available on request. M -- Mark R V Murray Cert APS(Open) Dip Phys(Open) BSc Open(Open) BSc(Hons)(Open) From owner-freebsd-current@FreeBSD.ORG Sun Jun 14 08:27:23 2009 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 EDD02106566B for ; Sun, 14 Jun 2009 08:27:23 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-gx0-f207.google.com (mail-gx0-f207.google.com [209.85.217.207]) by mx1.freebsd.org (Postfix) with ESMTP id A65628FC08 for ; Sun, 14 Jun 2009 08:27:23 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: by gxk3 with SMTP id 3so4898153gxk.19 for ; Sun, 14 Jun 2009 01:27:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=SWs4zupim+dzL4Isi/BeHOe/urXMhMgo7LWijlrCgCU=; b=lEyO5uXMzvbk5M87IL0wO/U8I5hfzeAbgkqtOA4fENOLt2vb+j15ASisG/hwXvKSeg 5iZOb3tfWpauaDD2AvsF88z5Qbwx7rNfroqT/Hs3qGgyecjw0IlV+f+4zWrMr6auwJGP K9O9xjlTVNWSfGIevuvdD9Gww9r3Q+8aWq/dY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=gr3eEe8yP0xOZVxUfeChvLJmCg8pDGOziVjkZ5HhpFShmuPfqFxgIaAn8YSjPi18tb hTysnTaqL8gWgRL0Xl66zivOdyL0QHT7btsQtXWTzJhhya1rjrIaVnlwS9Le1RCIZMPm D2G6YU+mWrr+ZVGJOzY14Suj2tlw7qtJyKWOs= MIME-Version: 1.0 Received: by 10.151.130.1 with SMTP id h1mr10845321ybn.172.1244968042582; Sun, 14 Jun 2009 01:27:22 -0700 (PDT) In-Reply-To: <200906132311.15359.ianjhart@ntlworld.com> References: <200906132311.15359.ianjhart@ntlworld.com> Date: Sun, 14 Jun 2009 01:27:22 -0700 Message-ID: From: Freddie Cash To: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: zpool scrub errors on 3ware 9550SXU 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, 14 Jun 2009 08:27:24 -0000 On Sat, Jun 13, 2009 at 3:11 PM, ian j hart wrote: > [long post with long lines, sorry] > > I have the following old hardware which I'm trying to make into a storage > server (back story elided). > > Tyan Thunder K8WE with dual Opteron 270 > 8GB REG ECC RAM > 3ware/AMCC 9550SXU-16 SATA controller > Adaptec 29160 SCSI card -> Quantum LTO3 tape > ChenBro case and backplanes. > 'don't remember' PSU. I do remember paying =C2=A398 3 years ago, so not c= heap! > floppy > > Some Seagate Barracuda drives. Two old 500GB for the O/S and 14 new 1.5TB > for > data (plus some spares). > > Astute readers will know that the 1.5TB units have a chequered history. > > I went to considerable effort to avoid being stuck with a bricked unit, s= o > imagine my dismay when, just before I was about to post this, I discovere= d > there's a new issue with these drives where they reallocate sectors, from > new. > > I don't want to get sucked into a discussion about whether these disks ar= e > faulty or not. I want to examine what seems to be a regression between > 7.2-RELEASE and 8-CURRENT. If you can't resist, start a thread in chat an= d > CC > me. > > Anyway, here's the full story (from memory I'm afraid). > > All disks exported as single drives (no JBOD anymore). > Install current snapshot on da0 and gmirror with da1, both 500GB disks. > Create a pool with the 14 1.5TB disks. Raidz2. > Are you using a single raidz2 vdev using all 14 drives? If so, that's probably (one of) the source of the issues. You really shouldn't use more than 8 or 9 drives in a singel raidz vdev. Bad things happen. Especially during resilvers and scrubs. We learned this the hard way, trying to replace a drive in a 24-drive raidz2 vdev. If possible, try to rebuild the pool using multiple, smaller raidz (1 or 2) vdevs. --=20 Freddie Cash fjwcash@gmail.com From owner-freebsd-current@FreeBSD.ORG Sun Jun 14 09:15:07 2009 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 34557106566C for ; Sun, 14 Jun 2009 09:15:07 +0000 (UTC) (envelope-from uucp@gromit.grondar.org) Received: from gromit.grondar.org (unknown [IPv6:2001:ba8:0:1d5:216:d4ff:fe0d:d845]) by mx1.freebsd.org (Postfix) with ESMTP id F13F68FC0A for ; Sun, 14 Jun 2009 09:15:06 +0000 (UTC) (envelope-from uucp@gromit.grondar.org) Received: from uucp by gromit.grondar.org with local (Exim 4.69) (envelope-from ) id 1MFm2P-0006Ul-Ib for current@freebsd.org; Sun, 14 Jun 2009 10:30:05 +0100 Received: from localhost ([127.0.0.1] helo=greatest.grondar.org) by greatest.grondar.org with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MFll6-000IZx-3G for current@freebsd.org; Sun, 14 Jun 2009 10:12:12 +0100 To: current@freebsd.org From: Mark Murray Date: Sun, 14 Jun 2009 10:12:12 +0100 Message-Id: Sender: UNIX-to-UNIX Copy Cc: Subject: Knobs for src/Make* for SVN "make update" 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, 14 Jun 2009 09:15:07 -0000 Hi Any comments on the attached patch to allow "make update" to work with SVN? Any brave soul prepared to officially review it? :-) M -- Mark R V Murray Cert APS(Open) Dip Phys(Open) BSc Open(Open) BSc(Hons)(Open) From owner-freebsd-current@FreeBSD.ORG Sun Jun 14 10:10:07 2009 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 A80861065676 for ; Sun, 14 Jun 2009 10:10:07 +0000 (UTC) (envelope-from uucp@gromit.grondar.org) Received: from gromit.grondar.org (unknown [IPv6:2001:ba8:0:1d5:216:d4ff:fe0d:d845]) by mx1.freebsd.org (Postfix) with ESMTP id 46D218FC21 for ; Sun, 14 Jun 2009 10:10:07 +0000 (UTC) (envelope-from uucp@gromit.grondar.org) Received: from uucp by gromit.grondar.org with local (Exim 4.69) (envelope-from ) id 1MFmtd-0000or-TY for current@freebsd.org; Sun, 14 Jun 2009 11:25:05 +0100 Received: from localhost ([127.0.0.1] helo=greatest.grondar.org) by greatest.grondar.org with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MFmdP-000Ieu-F2 for current@freebsd.org; Sun, 14 Jun 2009 11:08:19 +0100 To: current@freebsd.org From: Mark Murray MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" Content-ID: <71725.1244974071.0@greatest.grondar.org> Date: Sun, 14 Jun 2009 11:08:19 +0100 Message-Id: Sender: UNIX-to-UNIX Copy Cc: Subject: Knobs for src/Make* for SVN "make update" (patch attached) 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, 14 Jun 2009 10:10:08 -0000 ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <71725.1244974071.1@greatest.grondar.org> Hi Any comments on the attached patch to allow "make update" to work with SVN? This time the actual patch is enclosed. :-] Any brave soul prepared to officially review it? :-) M -- Mark R V Murray Cert APS(Open) Dip Phys(Open) BSc Open(Open) BSc(Hons)(Open) ------- =_aaaaaaaaaa0 Content-Type: text/plain; file="src_makefile.diff"; charset="us-ascii" Content-ID: <71725.1244974071.2@greatest.grondar.org> Content-Description: src_makefile.diff Index: Makefile.inc1 =================================================================== --- Makefile.inc1 (revision 194177) +++ Makefile.inc1 (working copy) @@ -94,6 +94,8 @@ CVS?= cvs CVSFLAGS?= -A -P -d -I! +SVN?= svn +SVNFLAGS?= -r HEAD SUP?= /usr/bin/csup SUPFLAGS?= -g -L 2 .if defined(SUPHOST) @@ -854,11 +867,25 @@ .endif .endif .if defined(CVS_UPDATE) - @echo "--------------------------------------------------------------" - @echo ">>> Updating ${.CURDIR} from CVS repository" ${CVSROOT} - @echo "--------------------------------------------------------------" - cd ${.CURDIR}; ${CVS} -R -q update ${CVSFLAGS} + @cd ${.CURDIR} ; \ + if [ -d CVS ] ; then \ + echo "--------------------------------------------------------------" ; \ + echo ">>> Updating ${.CURDIR} from CVS repository" ${CVSROOT} ; \ + echo "--------------------------------------------------------------" ; \ + echo ${CVS} -R -q update ${CVSFLAGS} ; \ + ${CVS} -R -q update ${CVSFLAGS} ; \ + fi .endif +.if defined(SVN_UPDATE) + @cd ${.CURDIR} ; \ + if [ -d .svn ] ; then \ + echo "--------------------------------------------------------------" ; \ + echo ">>> Updating ${.CURDIR} using Subversion" ; \ + echo "--------------------------------------------------------------" ; \ + echo ${SVN} update ${SVNFLAGS} ; \ + ${SVN} update ${SVNFLAGS} ; \ + fi +.endif # # ------------------------------------------------------------------------ ------- =_aaaaaaaaaa0-- From owner-freebsd-current@FreeBSD.ORG Sun Jun 14 13:27:45 2009 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 2607E1065675 for ; Sun, 14 Jun 2009 13:27:45 +0000 (UTC) (envelope-from ianjhart@ntlworld.com) Received: from mtaout01-winn.ispmail.ntl.com (mtaout01-winn.ispmail.ntl.com [81.103.221.47]) by mx1.freebsd.org (Postfix) with ESMTP id A3F5F8FC0A for ; Sun, 14 Jun 2009 13:27:44 +0000 (UTC) (envelope-from ianjhart@ntlworld.com) Received: from aamtaout01-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout01-winn.ispmail.ntl.com (InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP id <20090614132743.VZJE6742.mtaout01-winn.ispmail.ntl.com@aamtaout01-winn.ispmail.ntl.com> for ; Sun, 14 Jun 2009 14:27:43 +0100 Received: from cpc1-cove3-0-0-cust909.sol2.cable.ntl.com ([86.20.31.142]) by aamtaout01-winn.ispmail.ntl.com (InterMail vG.2.02.00.01 201-2161-120-102-20060912) with ESMTP id <20090614132743.ZVWE13254.aamtaout01-winn.ispmail.ntl.com@cpc1-cove3-0-0-cust909.sol2.cable.ntl.com> for ; Sun, 14 Jun 2009 14:27:43 +0100 X-Virus-Scanned: amavisd-new at cpc2-cove3-0-0-cust311.sol2.cable.ntl.com Received: from gamma.private.lan (gamma.private.lan [192.168.0.12]) by cpc1-cove3-0-0-cust909.sol2.cable.ntl.com (8.14.3/8.14.3) with ESMTP id n5EDR8YU096188; Sun, 14 Jun 2009 14:27:08 +0100 (BST) (envelope-from ianjhart@ntlworld.com) From: ian j hart To: freebsd-current@freebsd.org Date: Sun, 14 Jun 2009 14:27:08 +0100 User-Agent: KMail/1.9.10 References: <200906132311.15359.ianjhart@ntlworld.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200906141427.08397.ianjhart@ntlworld.com> X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on cpc1-cove3-0-0-cust909.sol2.cable.ntl.com X-Cloudmark-Analysis: v=1.0 c=1 a=ERehf_AEJYYA:10 a=NLZqzBF-AAAA:8 a=cyPt2eo1X11ld7FjuZ4A:9 a=YBHpFZlM06wofzdCsFpcykCZw48A:4 a=_dQi-Dcv4p4A:10 a=Vgu9YVKAPQfWkwmj:21 a=VDCMgUDYjoeEWV6C:21 Cc: Freddie Cash Subject: Re: zpool scrub errors on 3ware 9550SXU 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, 14 Jun 2009 13:27:45 -0000 On Sunday 14 June 2009 09:27:22 Freddie Cash wrote: > On Sat, Jun 13, 2009 at 3:11 PM, ian j hart wrote: > > [long post with long lines, sorry] > > > > I have the following old hardware which I'm trying to make into a stora= ge > > server (back story elided). > > > > Tyan Thunder K8WE with dual Opteron 270 > > 8GB REG ECC RAM > > 3ware/AMCC 9550SXU-16 SATA controller > > Adaptec 29160 SCSI card -> Quantum LTO3 tape > > ChenBro case and backplanes. > > 'don't remember' PSU. I do remember paying =C2=A398 3 years ago, so not= cheap! > > floppy > > > > Some Seagate Barracuda drives. Two old 500GB for the O/S and 14 new 1.5= TB > > for > > data (plus some spares). > > > > Astute readers will know that the 1.5TB units have a chequered history. > > > > I went to considerable effort to avoid being stuck with a bricked unit, > > so imagine my dismay when, just before I was about to post this, I > > discovered there's a new issue with these drives where they reallocate > > sectors, from new. > > > > I don't want to get sucked into a discussion about whether these disks > > are faulty or not. I want to examine what seems to be a regression > > between 7.2-RELEASE and 8-CURRENT. If you can't resist, start a thread = in > > chat and CC > > me. > > > > Anyway, here's the full story (from memory I'm afraid). > > > > All disks exported as single drives (no JBOD anymore). > > Install current snapshot on da0 and gmirror with da1, both 500GB disks. > > Create a pool with the 14 1.5TB disks. Raidz2. > > Are you using a single raidz2 vdev using all 14 drives? If so, that's > probably (one of) the source of the issues. You really shouldn't use more > than 8 or 9 drives in a singel raidz vdev. Bad things happen. Especially > during resilvers and scrubs. We learned this the hard way, trying to > replace a drive in a 24-drive raidz2 vdev. > > If possible, try to rebuild the pool using multiple, smaller raidz (1 or = 2) > vdevs. Did you post this issue to the list or open a PR? This is not listed in zfsknownproblems. Does opensolaris have this issue? Cheers =2D-=20 ian j hart From owner-freebsd-current@FreeBSD.ORG Sun Jun 14 13:51:01 2009 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 72A24106564A for ; Sun, 14 Jun 2009 13:51:01 +0000 (UTC) (envelope-from admin@lissyara.su) Received: from hosting.lissyara.su (hosting.lissyara.su [77.221.149.162]) by mx1.freebsd.org (Postfix) with ESMTP id 2F34B8FC15 for ; Sun, 14 Jun 2009 13:51:00 +0000 (UTC) (envelope-from admin@lissyara.su) Received: from [89.178.149.112] (port=26337 helo=HP.lissyara.su) by hosting.lissyara.su with esmtpa (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MFq6t-000HKM-Ez for freebsd-current@freebsd.org; Sun, 14 Jun 2009 17:50:59 +0400 Message-ID: <4A35006D.8030205@lissyara.su> Date: Sun, 14 Jun 2009 17:51:41 +0400 From: Alex Keda User-Agent: Thunderbird 2.0.0.21 (X11/20090405) MIME-Version: 1.0 To: freebsd-current Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Description: if spam count > 60 - this is spam X-Spam-Count: 0 X-Descriptions: powered by www.lissyara.su X-Bounce-ID: hosting.lissyara.su Subject: panic: blockable sleep lock (sleep mutex) 64 @ /usr/srv/sys/vm/uma_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: Sun, 14 Jun 2009 13:51:01 -0000 Today, I update sources and rebuild world and kernel. After reboot, I have panic. (my system is amd64) panic: blockable sleep lock (sleep mutex) 64 @ /usr/srv/sys/vm/uma_core. cpuid = 1 KDB: enter: panic [thread pid 12 tid 100026 ] Stopped at kdb_enter+0x3d: movq $0,0x6846d0(%rip) db> =========== back trace: Tracing pid 12 tid 100026 td 0xffffff0002357720 kdb_enter() at kdb_enter+0x3d panic() at panic+0x17b whitness_checkorder() at whitness_checkorder+0x948 _mtx_lock_flags() at mtx_lock_flags+0x78 uma_zalloc_arg() at uma_zalloc_arg+0x2ae malloc() at malloc+0x9a AcpiOsExecute() at AcpiOsExecute+0x3c AcpiEvGpeDispatch() at AcpiEvGpeDispatch+0x8c AcpiEvGpeDetect() at AcpiEvGpeDetect+0xe4 AcpiEvSciXruptHandler() at AcpiEvSciXruptHandler+0x24 intr_event_execute_handlers() at intr_event_execute_handlers+0x68 ithread_loop() at ithread_loop+0xb2 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8000093d40, rbp = 0 --- From owner-freebsd-current@FreeBSD.ORG Sun Jun 14 14:05:43 2009 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 DA9D9106564A for ; Sun, 14 Jun 2009 14:05:43 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-bw0-f228.google.com (mail-bw0-f228.google.com [209.85.218.228]) by mx1.freebsd.org (Postfix) with ESMTP id 632CB8FC12 for ; Sun, 14 Jun 2009 14:05:43 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by bwz28 with SMTP id 28so152598bwz.43 for ; Sun, 14 Jun 2009 07:05:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=6cEj4NwZNM42rCK1MtalEYQ6O9he0RjuVhI3Deir95k=; b=t8sKdkm7YikT7LL01pBa7Jx+zIO2aGpYHR6EGK74P9bMKntFtEM5tnXs40Bsg9IqME Eo883ULwhi34FmEHX0rcRY2hGuVS72c4wcG0e5GpZUlmBPYUiMTDanAcdxJ2QtQznIav YV3khGPEF58s7wSiqLa+Hw2bDUG+hTCt+oHvM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=HlqjyI3VNEZ5P6DJL2U3d+EwdfKhtaYyzCTJy+g0+hkJk1THjWbKEMYQRcvRJpt1yZ 4oLHtVJ/sooodt/akLMtLRY854V6cf4naXcjq6l1ocG+uBCNb6kwI/OpgWxL8n98AE/e 254OK7p2YdZqZp33cp/N40vKzcWukW9OWsqxQ= MIME-Version: 1.0 Received: by 10.204.61.9 with SMTP id r9mr2177998bkh.156.1244988342089; Sun, 14 Jun 2009 07:05:42 -0700 (PDT) In-Reply-To: <4A35006D.8030205@lissyara.su> References: <4A35006D.8030205@lissyara.su> Date: Sun, 14 Jun 2009 16:05:39 +0200 Message-ID: <3a142e750906140705y44166057q7b1debb92fad37d3@mail.gmail.com> From: "Paul B. Mahol" To: Alex Keda Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current Subject: Re: panic: blockable sleep lock (sleep mutex) 64 @ /usr/srv/sys/vm/uma_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: Sun, 14 Jun 2009 14:05:44 -0000 On 6/14/09, Alex Keda wrote: > Today, I update sources and rebuild world and kernel. > After reboot, I have panic. (my system is amd64) You forgot to mention which revision. -- Paul From owner-freebsd-current@FreeBSD.ORG Sun Jun 14 14:12:32 2009 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 0FB90106564A; Sun, 14 Jun 2009 14:12:32 +0000 (UTC) (envelope-from mister.olli@googlemail.com) Received: from mail-fx0-f228.google.com (mail-fx0-f228.google.com [209.85.220.228]) by mx1.freebsd.org (Postfix) with ESMTP id 6A31F8FC18; Sun, 14 Jun 2009 14:12:30 +0000 (UTC) (envelope-from mister.olli@googlemail.com) Received: by fxm28 with SMTP id 28so522619fxm.43 for ; Sun, 14 Jun 2009 07:12:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:subject:from:reply-to:to:cc :in-reply-to:references:content-type:date:message-id:mime-version :x-mailer:content-transfer-encoding; bh=Elthq2lDjW2oq46Vp+GV9G+hYzZ18298LiWM54OYL2Q=; b=ZdlBg2eRW25IcsgCeSZEZSkUu8E6j5X/m5Y4LzvcRKvT6FH37AMQWJDERR/SbVKN+g ghtDOVNUVpzWIgv5FAeFCrjdEjOT8T276abkLFQPmpJxUMG6Sbpa52xXz/TMBL3euwd2 uRwXH/dhzKyhoOs4IQFwH3RI6DwSvqLv0pO7c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=subject:from:reply-to:to:cc:in-reply-to:references:content-type :date:message-id:mime-version:x-mailer:content-transfer-encoding; b=MUqg5kGY83Q/iahaTRgV8GOwuomrOBCeYxWN9sfYHIJSFmFYw/2GzLMZtOXlVaCyj/ hsikUsl7cyLlO9XQ5hw1m8dfnqKi2jk2WtykDQFPtmky3X6y+BST3apFNBPD2glauvON fSLNFgKx8/ngEuiQ68oxbPyOZ58wm5TOyBhkw= Received: by 10.86.95.8 with SMTP id s8mr5832468fgb.2.1244988749709; Sun, 14 Jun 2009 07:12:29 -0700 (PDT) Received: from ?88.128.34.150? ([88.128.34.150]) by mx.google.com with ESMTPS id 12sm8351759fgg.15.2009.06.14.07.12.24 (version=SSLv3 cipher=RC4-MD5); Sun, 14 Jun 2009 07:12:26 -0700 (PDT) From: Mister Olli To: Kip Macy In-Reply-To: <3c1674c90906131457p3656732ka64c8d0ded3269a6@mail.gmail.com> References: <1244928181.6570.1.camel@phoenix.blechhirn.net> <3c1674c90906131457p3656732ka64c8d0ded3269a6@mail.gmail.com> Content-Type: text/plain Date: Sun, 14 Jun 2009 16:12:18 +0200 Message-Id: <1244988738.6570.2.camel@phoenix.blechhirn.net> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 Content-Transfer-Encoding: 7bit Cc: freebsd-xen@freebsd.org, freebsd-current@freebsd.org Subject: Re: XEN kernel fails to build with 8-CURRENT t194017 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mister.olli@googlemail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jun 2009 14:12:32 -0000 Hi, compiles works like a charm. Great work :-)) Thanks. Regards, --- Mr. Olli On Sat, 2009-06-13 at 14:57 -0700, Kip Macy wrote: > Should be fixed now. > > Cheers, > Kip > > On Sat, Jun 13, 2009 at 2:23 PM, Mister Olli wrote: > > Hi, > > > > during 'make buildkernel KERNCONF=XEN' I currently get the following error: > > > > > > cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror /usr/src/sys/dev/xen/blkfront/blkfront.c > > cc1: warnings being treated as errors > > /usr/src/sys/dev/xen/blkfront/blkfront.c:1104: warning: pointer type mismatch in conditional expression > > *** Error code 1 > > > > Stop in /usr/obj/usr/src/sys/XEN. > > *** Error code 1 > > > > Stop in /usr/src. > > *** Error code 1 > > > > Stop in /usr/src. > > template-8_CURRENT# svn info /usr/src > > Path: /usr/src > > URL: http://svn.freebsd.org/base/head > > Repository Root: http://svn.freebsd.org/base > > Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f > > Revision: 194107 > > Node Kind: directory > > Schedule: normal > > Last Changed Author: edwin > > Last Changed Rev: 194107 > > Last Changed Date: 2009-06-13 15:35:18 +0200 (Sat, 13 Jun 2009) > > > > > > > > > > Regards, > > --- > > Mr. Olli > > > > _______________________________________________ > > freebsd-xen@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-xen > > To unsubscribe, send any mail to "freebsd-xen-unsubscribe@freebsd.org" > > > > > From owner-freebsd-current@FreeBSD.ORG Sun Jun 14 14:12:54 2009 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 670691065702 for ; Sun, 14 Jun 2009 14:12:54 +0000 (UTC) (envelope-from thomas+freebsd@lotterer.net) Received: from angel.hellmouth.lotterer.net (angel.hellmouth.lotterer.net [88.198.53.82]) by mx1.freebsd.org (Postfix) with ESMTP id DEA648FC18 for ; Sun, 14 Jun 2009 14:12:53 +0000 (UTC) (envelope-from thomas+freebsd@lotterer.net) Received: from buffy.sunnydale.lotterer.net (ppp-93-104-163-93.dynamic.mnet-online.de [93.104.163.93]) by angel.hellmouth.lotterer.net (Postfix) with ESMTPS id 6BC181EC274; Sun, 14 Jun 2009 16:12:52 +0200 (CEST) Received: from [172.17.16.141] (faith.sunnydale.lotterer.net [172.17.16.141]) by buffy.sunnydale.lotterer.net (Postfix) with ESMTPSA id F25671073BF; Sun, 14 Jun 2009 14:12:44 +0000 (UTC) Message-ID: <4A350565.3070504@lotterer.net> Date: Sun, 14 Jun 2009 16:12:53 +0200 From: Thomas Lotterer User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: pyunyh@gmail.com References: <4A2DA8D9.2030300@lotterer.net> <20090610024959.GD63941@michelle.cdnetworks.co.kr> <4A2FF8E3.4060501@lotterer.net> <20090611002923.GA68519@michelle.cdnetworks.co.kr> <4A30FD94.4030409@lotterer.net> <20090611130557.GB68519@michelle.cdnetworks.co.kr> <4A312517.9030206@lotterer.net> <20090612055032.GD72855@michelle.cdnetworks.co.kr> <4A32BAE7.40605@lotterer.net> In-Reply-To: <4A32BAE7.40605@lotterer.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=3.0 tests=UNPARSEABLE_RELAY autolearn=failed version=3.2.5-openpkg X-Spam-Checker-Version: SpamAssassin 3.2.5-openpkg (2008-06-10) on angel.hellmouth.lotterer.net Cc: freebsd-current@freebsd.org Subject: Re: suspect bug in vge(4) 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, 14 Jun 2009 14:12:54 -0000 Thomas Lotterer wrote: > Pyun YongHyeon wrote: >> On Thu, Jun 11, 2009 at 05:39:03PM +0200, Thomas Lotterer wrote: >>> Pyun YongHyeon wrote: >>>> Could you show me dmesg output(only vge(4) related one)? >>> # dmesg | grep vge >>> vge0: port 0xec00-0xecff mem >>> 0xdf7ff000-0xdf7ff0ff irq 28 at device 0.0 on pci2 >>> vge0: MSIX count : 0 >>> vge0: MSI count : 1 >> >> I wonder why "Using 1 MSI messages" message is missing. > I stud if_vge.c with device_printf() statements. Turns out pci_alloc_msi() returns 6 = ENXIO The pci_alloc_msi_method() in /usr/src/sys/dev/pci/pci.c lists three cases returning ENXIO and all are located at the very top of the function. - If rid 0 is allocated, then fail. - Already have allocated messages? - If MSI is blacklisted for this system, fail. The pci_msi_blacklisted() and pci_msi_device_blacklisted() in /usr/src/sys/dev/pci/pci.c seem to check chipsets, devices and tunables Regarding the chipset # dmesg | egrep ^acpi acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 7bde0000 (3) failed acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 Regarding the tunables # sysctl -a | fgrep hw.pci. hw.pci.honor_msi_blacklist: 1 hw.pci.enable_msix: 1 hw.pci.enable_msi: 1 hw.pci.do_power_resume: 1 hw.pci.do_power_nodriver: 0 hw.pci.enable_io_modes: 1 hw.pci.host_mem_start: 2147483648 hw.pci.mcfg: 1 hw.pci.irq_override_mask: 57080 No cheating here # sysctl hw.pci.honor_msi_blacklist=0 sysctl: oid 'hw.pci.honor_msi_blacklist' is read only Ideas and suggestions welcome. -- http://thomas.lotterer.net From owner-freebsd-current@FreeBSD.ORG Sun Jun 14 14:28:03 2009 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 EC02B106566C for ; Sun, 14 Jun 2009 14:28:03 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-out3.uni-muenster.de (ZIVM-OUT3.UNI-MUENSTER.DE [128.176.192.18]) by mx1.freebsd.org (Postfix) with ESMTP id 2457C8FC0C for ; Sun, 14 Jun 2009 14:27:58 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) X-IronPort-AV: E=Sophos;i="4.42,217,1243807200"; d="c'?jpg'145?scan'145,208,145";a="5878556" Received: from zivmaildisp2.uni-muenster.de (HELO ZIVMAILUSER05.UNI-MUENSTER.DE) ([128.176.188.143]) by zivm-relay3.uni-muenster.de with ESMTP; 14 Jun 2009 16:27:57 +0200 Received: by ZIVMAILUSER05.UNI-MUENSTER.DE (Postfix, from userid 149459) id 4734C1B07E4; Sun, 14 Jun 2009 16:27:57 +0200 (CEST) Date: Sun, 14 Jun 2009 16:27:45 +0200 (CEST) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=+permail-20090614142745f7e55a9d00004f58-a_best01+ X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: linux syscall get_robust_list causes 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: Sun, 14 Jun 2009 14:28:04 -0000 This is a MIME encoded multipart message. --+permail-20090614142745f7e55a9d00004f58-a_best01+ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit hi there, i tried to run the latest release (20090531) of the linux test project (ltp) with emulators/linux_dist-gentoo-stage3. however the kernel panics after ltp's get_robust_list(2) test. set_robust_list(2) passes without any problems. i've attached a screenshot of the panic and the source which is causing the panic. you won't be able to compile it without ltp however. after installing and compiling ltp the source and the executable can be found in "/usr/local/gentoo-stage3/ltp-full-20090531/testcases/kernel/syscalls/get_robust_list". simply running the "/usr/local/gentoo-stage3/ltp-full-20090531/testcases/kernel/syscalls/get_robust_list/get_robust_list01" executable results in a panic. unfortunately i cannot supply a complete bt, because i only own a usb keyboard which doesn't respond after the panic. actually i'm a bit surprised the debugger was started, because i have "KDB_UNATTENDED" in my kernel conf. any reason the machine doesn't reboot and save the dump to /var/crash/vmcore.*? i'm running r193846 (CURRENT). cheers. --+permail-20090614142745f7e55a9d00004f58-a_best01+ Content-Type: application/octet-stream Content-Transfer-Encoding: Base64 Content-Disposition: attachment; filename="getrobustlist01.c" LyoKICoKICogICBDb3B5cmlnaHQgKGMpIEludGVybmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMg IENvcnAuLCAyMDAxCiAqCiAqICAgVGhpcyBwcm9ncmFtIGlzIGZyZWUgc29mdHdhcmU7ICB5b3Ug Y2FuIHJlZGlzdHJpYnV0ZSBpdCBhbmQvb3IgbW9kaWZ5CiAqICAgaXQgdW5kZXIgdGhlIHRlcm1z IG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSBhcyBwdWJsaXNoZWQgYnkKICogICB0 aGUgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uOyBlaXRoZXIgdmVyc2lvbiAyIG9mIHRoZSBMaWNl bnNlLCBvcgogKiAgIChhdCB5b3VyIG9wdGlvbikgYW55IGxhdGVyIHZlcnNpb24uCiAqCiAqICAg VGhpcyBwcm9ncmFtIGlzIGRpc3RyaWJ1dGVkIGluIHRoZSBob3BlIHRoYXQgaXQgd2lsbCBiZSB1 c2VmdWwsCiAqICAgYnV0IFdJVEhPVVQgQU5ZIFdBUlJBTlRZOyAgd2l0aG91dCBldmVuIHRoZSBp bXBsaWVkIHdhcnJhbnR5IG9mCiAqICAgTUVSQ0hBTlRBQklMSVRZIG9yIEZJVE5FU1MgRk9SIEEg UEFSVElDVUxBUiBQVVJQT1NFLiAgU2VlCiAqICAgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNl bnNlIGZvciBtb3JlIGRldGFpbHMuCiAqCiAqICAgWW91IHNob3VsZCBoYXZlIHJlY2VpdmVkIGEg Y29weSBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UKICogICBhbG9uZyB3aXRoIHRo aXMgcHJvZ3JhbTsgIGlmIG5vdCwgd3JpdGUgdG8gdGhlIEZyZWUgU29mdHdhcmUKICogICBGb3Vu ZGF0aW9uLCBJbmMuLCA1OSBUZW1wbGUgUGxhY2UsIFN1aXRlIDMzMCwgQm9zdG9uLCBNQSAwMjEx MS0xMzA3IFVTQQogKi8KCi8qCiAqIFRlc3QgTmFtZTogZ2V0X3JvYnVzdF9saXN0MDEKICoKICog VGVzdCBEZXNjcmlwdGlvbjoKICogIFZlcmlmeSB0aGF0IGdldF9yb2J1c3RfbGlzdCgpIHJldHVy bnMgdGhlIHByb3BlciBlcnJubyBmb3IgdmFyaW91cyBmYWlsdXJlCiAqICBjYXNlcwogKgogKiBV c2FnZTogIDxmb3IgY29tbWFuZC1saW5lPgogKiAgZ2V0X3JvYnVzdF9saXN0MDEgWy1jIG5dIFst ZV1bLWkgbl0gWy1JIHhdIFstcCB4XSBbLXRdCiAqCXdoZXJlLCAgLWMgbiA6IFJ1biBuIGNvcGll cyBjb25jdXJyZW50bHkuCiAqCQktZSAgIDogVHVybiBvbiBlcnJubyBsb2dnaW5nLgogKgkJLWkg biA6IEV4ZWN1dGUgdGVzdCBuIHRpbWVzLgogKgkJLUkgeCA6IEV4ZWN1dGUgdGVzdCBmb3IgeCBz ZWNvbmRzLgogKgkJLVAgeCA6IFBhdXNlIGZvciB4IHNlY29uZHMgYmV0d2VlbiBpdGVyYXRpb25z LgogKgkJLXQgICA6IFR1cm4gb24gc3lzY2FsbCB0aW1pbmcuCiAqCiAqIEhpc3RvcnkKICoJMDcv MjAwOCBSYW1vbiBkZSBDYXJ2YWxobyBWYWxsZSA8cmN2YWxsZUBici5pYm0uY29tPgogKgkJLUNy ZWF0ZWQKICoKICogUmVzdHJpY3Rpb25zOgogKiAgTm9uZS4KICoKICovCgojaW5jbHVkZSA8c3Rk aW8uaD4KI2luY2x1ZGUgPHN0ZGxpYi5oPgojaW5jbHVkZSA8ZXJybm8uaD4KCiNpbmNsdWRlIDxz eXMvc3lzY2FsbC5oPgojaW5jbHVkZSA8c3lzL3R5cGVzLmg+CgojaW5jbHVkZSAidGVzdC5oIgoj aW5jbHVkZSAidXNjdGVzdC5oIgoKY2hhciAqVENJRCA9ICJnZXRfcm9idXN0X2xpc3QwMSI7CS8q IHRlc3QgcHJvZ3JhbSBpZGVudGlmaWVyLiAgICAgICAgICAgICAgKi8KaW50IFRTVF9UT1RBTCA9 IDU7CQkvKiB0b3RhbCBudW1iZXIgb2YgdGVzdHMgaW4gdGhpcyBmaWxlLiAgICovCgojaWZkZWYg X19OUl9nZXRfcm9idXN0X2xpc3QKCnN0cnVjdCByb2J1c3RfbGlzdCB7CglzdHJ1Y3Qgcm9idXN0 X2xpc3QgKm5leHQ7Cn07CgpzdHJ1Y3Qgcm9idXN0X2xpc3RfaGVhZCB7CglzdHJ1Y3Qgcm9idXN0 X2xpc3QgbGlzdDsKCWxvbmcgZnV0ZXhfb2Zmc2V0OwoJc3RydWN0IHJvYnVzdF9saXN0ICpsaXN0 X29wX3BlbmRpbmc7Cn07CgpleHRlcm4gaW50IFRzdF9jb3VudDsJCS8qIGNvdW50ZXIgZm9yIHRz dF94eHggcm91dGluZXMuICAgICAgICAgKi8KCmludCBleHBfZW5vc1tdID0geyBFU1JDSCwgRVBF Uk0sIEVGQVVMVCwgMCB9OwoKdm9pZCBzZXR1cCh2b2lkKTsKdm9pZCBjbGVhbnVwKHZvaWQpOwoK aW50IG1haW4oaW50IGFyZ2MsIGNoYXIgKiphcmd2KQp7CglpbnQgbGM7CQkJLyogbG9vcCBjb3Vu dGVyICovCgljaGFyICptc2c7CQkvKiBtZXNzYWdlIHJldHVybmVkIGZyb20gcGFyc2Vfb3B0cyAq LwoJc3RydWN0IHJvYnVzdF9saXN0X2hlYWQgaGVhZDsKCXNpemVfdCBsZW5fcHRyOwkJLyogc2l6 ZSBvZiBzdHJ1Y3R1cmUgc3RydWN0IHJvYnVzdF9saXN0X2hlYWQgKi8KCWludCByZXR2YWw7CgoJ bXNnID0gcGFyc2Vfb3B0cyhhcmdjLCBhcmd2LCAob3B0aW9uX3QgKikgTlVMTCwgTlVMTCk7Cglp ZiAobXNnICE9IChjaGFyICopTlVMTCkgewoJCXRzdF9icmttKFRCUk9LLCBOVUxMLCAiT1BUSU9O IFBBUlNJTkcgRVJST1IgLSAlcyIsIG1zZyk7CgkJdHN0X2V4aXQoKTsKCX0KCglzZXR1cCgpOwoK CWxlbl9wdHIgPSBzaXplb2Yoc3RydWN0IHJvYnVzdF9saXN0X2hlYWQpOwoKCWZvciAobGMgPSAw OyBURVNUX0xPT1BJTkcobGMpOyArK2xjKSB7CgkJVHN0X2NvdW50ID0gMDsKCgkJLyoKCQkgKiBU aGUgZ2V0X3JvYnVzdF9saXN0IGZ1bmN0aW9uIGZhaWxzIHdpdGggRUZBVUxUIGlmIHRoZSBzaXpl IG9mIHRoZQoJCSAqIHN0cnVjdCByb2J1c3RfbGlzdF9oZWFkIGNhbid0IGJlIHN0b3JlZCBpbiB0 aGUgbWVtb3J5IGFkZHJlc3Mgc3BhY2UKCQkgKiBzcGVjaWZpZWQgYnkgbGVuX3B0ciBhcmd1bWVu dCwgb3IgdGhlIGhlYWQgb2YgdGhlIHJvYnVzdCBsaXN0IGNhbid0CgkJICogYmUgc3RvcmVkIGlu IHRoZSBtZW1vcnkgYWRkcmVzcyBzcGFjZSBzcGVjaWZpZWQgYnkgdGhlIGhlYWRfcHRyCgkJICog YXJndW1lbnQuCgkJICovCgoJCVRFU1QocmV0dmFsID0gc3lzY2FsbChfX05SX2dldF9yb2J1c3Rf bGlzdCwgMCwKCQkJCSAgICAgIChzdHJ1Y3Qgcm9idXN0X2xpc3RfaGVhZCAqKSZoZWFkLAoJCQkJ ICAgICAgKHNpemVfdCAqKSBOVUxMKSk7CgoJCWlmIChURVNUX1JFVFVSTikgewoJCQlpZiAoVEVT VF9FUlJOTyA9PSBFRkFVTFQpCgkJCQl0c3RfcmVzbShUUEFTUywKCQkJCQkgImdldF9yb2J1c3Rf bGlzdDogcmV0dmFsID0gJWQgKGV4cGVjdGVkICVkKSwgIgoJCQkJCSAiZXJybm8gPSAlZCAoZXhw ZWN0ZWQgJWQpIiwKCQkJCQkgVEVTVF9SRVRVUk4sIC0xLCBURVNUX0VSUk5PLCBFRkFVTFQpOwoJ CQllbHNlCgkJCQl0c3RfcmVzbShURkFJTCwKCQkJCQkgImdldF9yb2J1c3RfbGlzdDogcmV0dmFs ID0gJWQgKGV4cGVjdGVkICVkKSwgIgoJCQkJCSAiZXJybm8gPSAlZCAoZXhwZWN0ZWQgJWQpIiwK CQkJCQkgVEVTVF9SRVRVUk4sIC0xLCBURVNUX0VSUk5PLCBFRkFVTFQpOwoJCX0gZWxzZSB7CgkJ CXRzdF9yZXNtKFRGQUlMLAoJCQkJICJnZXRfcm9idXN0X2xpc3Q6IHJldHZhbCA9ICVkIChleHBl Y3RlZCAlZCksICIKCQkJCSAiZXJybm8gPSAlZCAoZXhwZWN0ZWQgJWQpIiwgVEVTVF9SRVRVUk4s IC0xLAoJCQkJIFRFU1RfRVJSTk8sIEVGQVVMVCk7CgkJfQoKCQlURVNUKHJldHZhbCA9IHN5c2Nh bGwoX19OUl9nZXRfcm9idXN0X2xpc3QsIDAsCgkJCQkgICAgICAoc3RydWN0IHJvYnVzdF9saXN0 X2hlYWQgKiopTlVMTCwKCQkJCSAgICAgICZsZW5fcHRyKSk7CgoJCWlmIChURVNUX1JFVFVSTikg ewoJCQlpZiAoVEVTVF9FUlJOTyA9PSBFRkFVTFQpCgkJCQl0c3RfcmVzbShUUEFTUywKCQkJCQkg ImdldF9yb2J1c3RfbGlzdDogcmV0dmFsID0gJWQgKGV4cGVjdGVkICVkKSwgIgoJCQkJCSAiZXJy bm8gPSAlZCAoZXhwZWN0ZWQgJWQpIiwKCQkJCQkgVEVTVF9SRVRVUk4sIC0xLCBURVNUX0VSUk5P LCBFRkFVTFQpOwoJCQllbHNlCgkJCQl0c3RfcmVzbShURkFJTCwKCQkJCQkgImdldF9yb2J1c3Rf bGlzdDogcmV0dmFsID0gJWQgKGV4cGVjdGVkICVkKSwgIgoJCQkJCSAiZXJybm8gPSAlZCAoZXhw ZWN0ZWQgJWQpIiwKCQkJCQkgVEVTVF9SRVRVUk4sIC0xLCBURVNUX0VSUk5PLCBFRkFVTFQpOwoJ CX0gZWxzZSB7CgkJCXRzdF9yZXNtKFRGQUlMLAoJCQkJICJnZXRfcm9idXN0X2xpc3Q6IHJldHZh bCA9ICVkIChleHBlY3RlZCAlZCksICIKCQkJCSAiZXJybm8gPSAlZCAoZXhwZWN0ZWQgJWQpIiwg VEVTVF9SRVRVUk4sIC0xLAoJCQkJIFRFU1RfRVJSTk8sIEVGQVVMVCk7CgkJfQoKCQkvKgoJCSAq IFRoZSBnZXRfcm9idXN0X2xpc3QgZnVuY3Rpb24gZmFpbHMgd2l0aCBFU1JDSCBpZiBpdCBjYW4n dCBmaW5kIHRoZQoJCSAqIHRhc2sgc3BlY2lmaWVkIGJ5IHRoZSBwaWQgYXJndW1lbnQuIFRoZSB2 YWx1ZSA2NTUzNSBpcyB1c2VkIGFzIHRoZQoJCSAqIHBpZCBhcmd1bWVudC4KCQkgKi8KCgkJVEVT VChyZXR2YWwgPSBzeXNjYWxsKF9fTlJfZ2V0X3JvYnVzdF9saXN0LCA2NTUzNSwKCQkJCSAgICAg IChzdHJ1Y3Qgcm9idXN0X2xpc3RfaGVhZCAqKSZoZWFkLAoJCQkJICAgICAgJmxlbl9wdHIpKTsK CgkJaWYgKFRFU1RfUkVUVVJOKSB7CgkJCWlmIChURVNUX0VSUk5PID09IEVTUkNIKQoJCQkJdHN0 X3Jlc20oVFBBU1MsCgkJCQkJICJnZXRfcm9idXN0X2xpc3Q6IHJldHZhbCA9ICVkIChleHBlY3Rl ZCAlZCksICIKCQkJCQkgImVycm5vID0gJWQgKGV4cGVjdGVkICVkKSIsCgkJCQkJIFRFU1RfUkVU VVJOLCAtMSwgVEVTVF9FUlJOTywgRVNSQ0gpOwoJCQllbHNlCgkJCQl0c3RfcmVzbShURkFJTCwK CQkJCQkgImdldF9yb2J1c3RfbGlzdDogcmV0dmFsID0gJWQgKGV4cGVjdGVkICVkKSwgIgoJCQkJ CSAiZXJybm8gPSAlZCAoZXhwZWN0ZWQgJWQpIiwKCQkJCQkgVEVTVF9SRVRVUk4sIC0xLCBURVNU X0VSUk5PLCBFU1JDSCk7CgkJfSBlbHNlIHsKCQkJdHN0X3Jlc20oVEZBSUwsCgkJCQkgImdldF9y b2J1c3RfbGlzdDogcmV0dmFsID0gJWQgKGV4cGVjdGVkICVkKSwgIgoJCQkJICJlcnJubyA9ICVk IChleHBlY3RlZCAlZCkiLCBURVNUX1JFVFVSTiwgLTEsCgkJCQkgVEVTVF9FUlJOTywgRVNSQ0gp OwoJCX0KCgkJLyoKCQkgKiBUaGUgZ2V0X3JvYnVzdF9saXN0IGZ1bmN0aW9uIGZhaWxzIHdpdGgg RVBFUk0gaWYgaXQgaGFzIG5vCgkJICogcGVybWlzc2lvbiB0byBhY2Nlc3MgdGhlIHRhc2sgc3Bl Y2lmaWVkIGJ5IHRoZSBwaWQgYXJndW1lbnQuCgkJICogVGhlIGN1cnJlbnQgdXNlciBpZCBvZiB0 aGUgcHJvY2VzcyBpcyBjaGFuZ2VkIHRvIDEgKGJpbiksIGFuZCB0aGUKCQkgKiB2YWx1ZSBvZiAx IChpbml0KSBpcyB1c2VkIGFzIHRoZSBwaWQgYXJndW1lbnQuCgkJICovCgoJCS8qCgkJICogVGVt cG9yYXJpbHkgZHJvcCByb290IHByaXZsZWdlcy4KCQkgKi8KCQlzZXRldWlkKDEpOwoKCQlURVNU KHJldHZhbCA9IHN5c2NhbGwoX19OUl9nZXRfcm9idXN0X2xpc3QsIDEsCgkJCQkgICAgICAoc3Ry dWN0IHJvYnVzdF9saXN0X2hlYWQgKikmaGVhZCwKCQkJCSAgICAgICZsZW5fcHRyKSk7CgoJCWlm IChURVNUX1JFVFVSTikgewoJCQlpZiAoVEVTVF9FUlJOTyA9PSBFUEVSTSkKCQkJCXRzdF9yZXNt KFRQQVNTLAoJCQkJCSAiZ2V0X3JvYnVzdF9saXN0OiByZXR2YWwgPSAlZCAoZXhwZWN0ZWQgJWQp LCAiCgkJCQkJICJlcnJubyA9ICVkIChleHBlY3RlZCAlZCkiLAoJCQkJCSBURVNUX1JFVFVSTiwg LTEsIFRFU1RfRVJSTk8sIEVQRVJNKTsKCQkJZWxzZQoJCQkJdHN0X3Jlc20oVEZBSUwsCgkJCQkJ ICJnZXRfcm9idXN0X2xpc3Q6IHJldHZhbCA9ICVkIChleHBlY3RlZCAlZCksICIKCQkJCQkgImVy cm5vID0gJWQgKGV4cGVjdGVkICVkKSIsCgkJCQkJIFRFU1RfUkVUVVJOLCAtMSwgVEVTVF9FUlJO TywgRVBFUk0pOwoJCX0gZWxzZSB7CgkJCXRzdF9yZXNtKFRGQUlMLAoJCQkJICJnZXRfcm9idXN0 X2xpc3Q6IHJldHZhbCA9ICVkIChleHBlY3RlZCAlZCksICIKCQkJCSAiZXJybm8gPSAlZCAoZXhw ZWN0ZWQgJWQpIiwgVEVTVF9SRVRVUk4sIC0xLAoJCQkJIFRFU1RfRVJSTk8sIEVQRVJNKTsKCQl9 CgoJCS8qCgkJICogUmVnYWluIHJvb3QgcHJpdmlsZWdlcy4KCQkgKi8KCQlzZXRldWlkKDApOwoK CQkvKgoJCSAqIFRoaXMgY2FsbCB0byBnZXRfcm9idXN0X2xpc3QgZnVuY3Rpb24gc2hvdWxkIGJl IHN1Y2Vzc2Z1bC4KCQkgKi8KCgkJVEVTVChyZXR2YWwgPSBzeXNjYWxsKF9fTlJfZ2V0X3JvYnVz dF9saXN0LCAwLAoJCQkJICAgICAgKHN0cnVjdCByb2J1c3RfbGlzdF9oZWFkICoqKSZoZWFkLAoJ CQkJICAgICAgJmxlbl9wdHIpKTsKCgkJaWYgKFRFU1RfUkVUVVJOID09IDApIHsKCQkJdHN0X3Jl c20oVFBBU1MsCgkJCQkgImdldF9yb2J1c3RfbGlzdDogcmV0dmFsID0gJWQgKGV4cGVjdGVkICVk KSwgIgoJCQkJICJlcnJubyA9ICVkIChleHBlY3RlZCAlZCkiLCBURVNUX1JFVFVSTiwgMCwKCQkJ CSBURVNUX0VSUk5PLCAwKTsKCQl9IGVsc2UgewoJCQl0c3RfcmVzbShURkFJTCwKCQkJCSAiZ2V0 X3JvYnVzdF9saXN0OiByZXR2YWwgPSAlZCAoZXhwZWN0ZWQgJWQpLCAiCgkJCQkgImVycm5vID0g JWQgKGV4cGVjdGVkICVkKSIsIFRFU1RfUkVUVVJOLCAwLAoJCQkJIFRFU1RfRVJSTk8sIDApOwoJ CX0KCgl9CgoJY2xlYW51cCgpOwoKCWV4aXQoRVhJVF9TVUNDRVNTKTsKfQoKdm9pZCBzZXR1cCh2 b2lkKQp7CglURVNUX0VYUF9FTk9TKGV4cF9lbm9zKTsKCglURVNUX1BBVVNFOwp9Cgp2b2lkIGNs ZWFudXAodm9pZCkKewoJVEVTVF9DTEVBTlVQOwoKCXRzdF9leGl0KCk7Cn0KCiNlbHNlCgppbnQg bWFpbigpCnsKCXRzdF9yZXNtKFRDT05GLCAiZ2V0X3JvYnVzdF9saXN0OiBzeXN0ZW0gY2FsbCBu b3QgYXZhaWxhYmxlIik7Cgl0c3RfZXhpdCgpOwp9CgojZW5kaWYK --+permail-20090614142745f7e55a9d00004f58-a_best01+-- From owner-freebsd-current@FreeBSD.ORG Sun Jun 14 14:35:23 2009 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 92E761065670 for ; Sun, 14 Jun 2009 14:35:23 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-out1.uni-muenster.de (ZIVM-OUT1.UNI-MUENSTER.DE [128.176.192.8]) by mx1.freebsd.org (Postfix) with ESMTP id 27C648FC1B for ; Sun, 14 Jun 2009 14:35:22 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) X-IronPort-AV: E=Sophos;i="4.42,218,1243807200"; d="scan'208";a="274469656" Received: from zivmaildisp2.uni-muenster.de (HELO ZIVMAILUSER05.UNI-MUENSTER.DE) ([128.176.188.143]) by zivm-relay1.uni-muenster.de with ESMTP; 14 Jun 2009 16:35:22 +0200 Received: by ZIVMAILUSER05.UNI-MUENSTER.DE (Postfix, from userid 149459) id CC7DD1B07E4; Sun, 14 Jun 2009 16:35:21 +0200 (CEST) Date: Sun, 14 Jun 2009 16:35:21 +0200 (CEST) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Subject: Re: linux syscall get_robust_list causes 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: Sun, 14 Jun 2009 14:35:23 -0000 here's a picture of the panic since the attachment got scrubbed: http://picasaweb.google.de/lh/photo/vgUhJP7flyNIeduggpm0oQ?feat=directlink From owner-freebsd-current@FreeBSD.ORG Sun Jun 14 14:42:00 2009 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 917BA106564A for ; Sun, 14 Jun 2009 14:42:00 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-fx0-f228.google.com (mail-fx0-f228.google.com [209.85.220.228]) by mx1.freebsd.org (Postfix) with ESMTP id 24F978FC1C for ; Sun, 14 Jun 2009 14:41:59 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by fxm28 with SMTP id 28so533213fxm.43 for ; Sun, 14 Jun 2009 07:41:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=MKFixQeoYV7TXukHS9m4JuBYjVYZw5bS1LJrPRK+948=; b=OKK0ECrNVZo5GagzIjXmX2998lB5pUpJEbrgPzPdh0T6N4uzS/u9K9lFlBQF+SXc7O nyhCS/6/Oh/qPK8zE2wwX3vkF2zQput6qI+4tVHtSspYqHrzpur5ZO58HqGZfOOCuUg2 z2DLcglx1wAGHvRLe1AJmcwfoJZtGdj15j/y8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=g/FO5C3Z2FkbiZmDUFO28UBLLN0/22g96XiN8yRyYbzAfjrCon6qppW0pvvzQJSk52 fwIk+XKx/HBZA5MD30XljjMyGiH1psDOi1ENcbVGtOM82FuffoDeILORyxc+deehHfjQ A1e+cACO8CcOYDPDyOeG+7BNc7ZNCQiKlK3C0= MIME-Version: 1.0 Received: by 10.204.123.83 with SMTP id o19mr5972489bkr.12.1244990519197; Sun, 14 Jun 2009 07:41:59 -0700 (PDT) In-Reply-To: References: Date: Sun, 14 Jun 2009 16:41:59 +0200 Message-ID: <3a142e750906140741r438affb6oa8434709aa2bc8f2@mail.gmail.com> From: "Paul B. Mahol" To: Alexander Best Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: linux syscall get_robust_list causes 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: Sun, 14 Jun 2009 14:42:00 -0000 On 6/14/09, Alexander Best wrote: > hi there, > > i tried to run the latest release (20090531) of the linux test project (ltp) > with emulators/linux_dist-gentoo-stage3. however the kernel panics after > ltp's > get_robust_list(2) test. set_robust_list(2) passes without any problems. > > i've attached a screenshot of the panic and the source which is causing the > panic. you won't be able to compile it without ltp however. after installing > and compiling ltp the source and the executable can be found in > "/usr/local/gentoo-stage3/ltp-full-20090531/testcases/kernel/syscalls/get_robust_list". > simply running the > "/usr/local/gentoo-stage3/ltp-full-20090531/testcases/kernel/syscalls/get_robust_list/get_robust_list01" > executable results in a panic. > > unfortunately i cannot supply a complete bt, because i only own a usb > keyboard > which doesn't respond after the panic. actually i'm a bit surprised the > debugger was started, because i have "KDB_UNATTENDED" in my kernel conf. any > reason the machine doesn't reboot and save the dump to /var/crash/vmcore.*? sysctl debug.debugger_on_panic=0 -- Paul From owner-freebsd-current@FreeBSD.ORG Sun Jun 14 15:18:52 2009 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 58D61106566B for ; Sun, 14 Jun 2009 15:18:52 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-out3.uni-muenster.de (ZIVM-OUT3.UNI-MUENSTER.DE [128.176.192.18]) by mx1.freebsd.org (Postfix) with ESMTP id E08388FC12 for ; Sun, 14 Jun 2009 15:18:51 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) X-IronPort-AV: E=Sophos;i="4.42,218,1243807200"; d="scan'208";a="5880703" Received: from zivmaildisp2.uni-muenster.de (HELO ZIVMAILUSER03.UNI-MUENSTER.DE) ([128.176.188.143]) by zivm-relay3.uni-muenster.de with ESMTP; 14 Jun 2009 17:18:50 +0200 Received: by ZIVMAILUSER03.UNI-MUENSTER.DE (Postfix, from userid 149459) id 93B6E1B075E; Sun, 14 Jun 2009 17:18:50 +0200 (CEST) Date: Sun, 14 Jun 2009 17:18:50 +0200 (CEST) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: "Paul B. Mahol" Message-ID: In-Reply-To: <3a142e750906140741r438affb6oa8434709aa2bc8f2@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: linux syscall get_robust_list causes 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: Sun, 14 Jun 2009 15:18:52 -0000 [arundel@~ - 04:02 pm] sysctl sysctl debug.debugger_on_panic debug.debugger_on_panic: 0 maybe a bug? Paul B. Mahol schrieb am 2009-06-14: > On 6/14/09, Alexander Best wrote: > > hi there, > > i tried to run the latest release (20090531) of the linux test > > project (ltp) > > with emulators/linux_dist-gentoo-stage3. however the kernel panics > > after > > ltp's > > get_robust_list(2) test. set_robust_list(2) passes without any > > problems. > > i've attached a screenshot of the panic and the source which is > > causing the > > panic. you won't be able to compile it without ltp however. after > > installing > > and compiling ltp the source and the executable can be found in > > "/usr/local/gentoo-stage3/ltp-full-20090531/testcases/kernel/syscalls/get_robust_list". > > simply running the > > "/usr/local/gentoo-stage3/ltp-full-20090531/testcases/kernel/syscalls/get_robust_list/get_robust_list01" > > executable results in a panic. > > unfortunately i cannot supply a complete bt, because i only own a > > usb > > keyboard > > which doesn't respond after the panic. actually i'm a bit surprised > > the > > debugger was started, because i have "KDB_UNATTENDED" in my kernel > > conf. any > > reason the machine doesn't reboot and save the dump to > > /var/crash/vmcore.*? > sysctl debug.debugger_on_panic=0 From owner-freebsd-current@FreeBSD.ORG Sun Jun 14 15:30:46 2009 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 D1447106566C for ; Sun, 14 Jun 2009 15:30:46 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-out1.uni-muenster.de (ZIVM-OUT1.UNI-MUENSTER.DE [128.176.192.8]) by mx1.freebsd.org (Postfix) with ESMTP id 64ADE8FC2A for ; Sun, 14 Jun 2009 15:30:45 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) X-IronPort-AV: E=Sophos;i="4.42,218,1243807200"; d="scan'208";a="274472288" Received: from zivmaildisp2.uni-muenster.de (HELO ZIVMAILUSER03.UNI-MUENSTER.DE) ([128.176.188.143]) by zivm-relay1.uni-muenster.de with ESMTP; 14 Jun 2009 17:30:45 +0200 Received: by ZIVMAILUSER03.UNI-MUENSTER.DE (Postfix, from userid 149459) id 466631B075E; Sun, 14 Jun 2009 17:30:45 +0200 (CEST) Date: Sun, 14 Jun 2009 17:30:44 +0200 (CEST) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: Chagin Dmitry Message-ID: In-Reply-To: <20090614151717.GA26276@dchagin.static.corbina.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: linux syscall get_robust_list causes 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: Sun, 14 Jun 2009 15:30:47 -0000 wow. thanks for the fix. after applying the patch the panic no longer occurs. great job! :-) hope this'll make it into CURRENT quickly. ;) cheers. Chagin Dmitry schrieb am 2009-06-14: > On Sun, Jun 14, 2009 at 04:27:45PM +0200, Alexander Best wrote: > > hi there, > > i tried to run the latest release (20090531) of the linux test > > project (ltp) > > with emulators/linux_dist-gentoo-stage3. however the kernel panics > > after ltp's > > get_robust_list(2) test. set_robust_list(2) passes without any > > problems. > > i've attached a screenshot of the panic and the source which is > > causing the > > panic. you won't be able to compile it without ltp however. after > > installing > > and compiling ltp the source and the executable can be found in > > "/usr/local/gentoo-stage3/ltp-full-20090531/testcases/kernel/syscalls/get_robust_list". > > simply running the > > "/usr/local/gentoo-stage3/ltp-full-20090531/testcases/kernel/syscalls/get_robust_list/get_robust_list01" > > executable results in a panic. > > unfortunately i cannot supply a complete bt, because i only own a > > usb keyboard > > which doesn't respond after the panic. actually i'm a bit surprised > > the > > debugger was started, because i have "KDB_UNATTENDED" in my kernel > > conf. any > > reason the machine doesn't reboot and save the dump to > > /var/crash/vmcore.*? > please, try inlined patch. > diff --git a/sys/compat/linux/linux_futex.c > b/sys/compat/linux/linux_futex.c > index cb04cd8..0f781fc 100644 > --- a/sys/compat/linux/linux_futex.c > +++ b/sys/compat/linux/linux_futex.c > @@ -707,8 +707,10 @@ linux_get_robust_list(struct thread *td, struct > linux_get_robust_list_args *args > /* XXX: ptrace? */ > if (priv_check(td, PRIV_CRED_SETUID) || > priv_check(td, PRIV_CRED_SETEUID) || > - p_candebug(td, p)) > + p_candebug(td, p)) { > + PROC_UNLOCK(p); > return (EPERM); > + } > head = em->robust_futexes; > PROC_UNLOCK(p); From owner-freebsd-current@FreeBSD.ORG Sun Jun 14 15:34:49 2009 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 D1CC5106564A for ; Sun, 14 Jun 2009 15:34:49 +0000 (UTC) (envelope-from dchagin@dchagin.static.corbina.ru) Received: from contrabass.post.ru (contrabass.post.ru [85.21.78.5]) by mx1.freebsd.org (Postfix) with ESMTP id 7D4EB8FC1F for ; Sun, 14 Jun 2009 15:34:49 +0000 (UTC) (envelope-from dchagin@dchagin.static.corbina.ru) Received: from corbina.ru (mail.post.ru [195.14.50.16]) by contrabass.post.ru (Postfix) with ESMTP id D44AAA0296; Sun, 14 Jun 2009 19:17:22 +0400 (MSD) X-Virus-Scanned: by cgpav Uf39PSi9pFi9oFi9 Received: from [10.208.17.3] (HELO dchagin.static.corbina.ru) by corbina.ru (CommuniGate Pro SMTP 5.1.14) with ESMTPS id 1829531595; Sun, 14 Jun 2009 19:17:22 +0400 Received: from dchagin.static.corbina.ru (localhost.chd.net [127.0.0.1]) by dchagin.static.corbina.ru (8.14.3/8.14.3) with ESMTP id n5EFHMNA026420; Sun, 14 Jun 2009 19:17:22 +0400 (MSD) (envelope-from dchagin@dchagin.static.corbina.ru) Received: (from dchagin@localhost) by dchagin.static.corbina.ru (8.14.3/8.14.3/Submit) id n5EFHHJf026419; Sun, 14 Jun 2009 19:17:17 +0400 (MSD) (envelope-from dchagin) Date: Sun, 14 Jun 2009 19:17:17 +0400 From: Chagin Dmitry To: Alexander Best Message-ID: <20090614151717.GA26276@dchagin.static.corbina.ru> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="sm4nu43k4a2Rpi4c" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) Cc: freebsd-current@freebsd.org Subject: Re: linux syscall get_robust_list causes 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: Sun, 14 Jun 2009 15:34:50 -0000 --sm4nu43k4a2Rpi4c Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jun 14, 2009 at 04:27:45PM +0200, Alexander Best wrote: > hi there, >=20 > i tried to run the latest release (20090531) of the linux test project (l= tp) > with emulators/linux_dist-gentoo-stage3. however the kernel panics after = ltp's > get_robust_list(2) test. set_robust_list(2) passes without any problems. >=20 > i've attached a screenshot of the panic and the source which is causing t= he > panic. you won't be able to compile it without ltp however. after install= ing > and compiling ltp the source and the executable can be found in > "/usr/local/gentoo-stage3/ltp-full-20090531/testcases/kernel/syscalls/get= _robust_list". > simply running the > "/usr/local/gentoo-stage3/ltp-full-20090531/testcases/kernel/syscalls/get= _robust_list/get_robust_list01" > executable results in a panic. >=20 > unfortunately i cannot supply a complete bt, because i only own a usb key= board > which doesn't respond after the panic. actually i'm a bit surprised the > debugger was started, because i have "KDB_UNATTENDED" in my kernel conf. = any > reason the machine doesn't reboot and save the dump to /var/crash/vmcore.= *? >=20 please, try inlined patch. diff --git a/sys/compat/linux/linux_futex.c b/sys/compat/linux/linux_futex.c index cb04cd8..0f781fc 100644 --- a/sys/compat/linux/linux_futex.c +++ b/sys/compat/linux/linux_futex.c @@ -707,8 +707,10 @@ linux_get_robust_list(struct thread *td, struct linux_= get_robust_list_args *args /* XXX: ptrace? */ if (priv_check(td, PRIV_CRED_SETUID) ||=20 priv_check(td, PRIV_CRED_SETEUID) || - p_candebug(td, p)) + p_candebug(td, p)) { + PROC_UNLOCK(p); return (EPERM); + } head =3D em->robust_futexes; =09 PROC_UNLOCK(p); --=20 Have fun! chd --sm4nu43k4a2Rpi4c Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (FreeBSD) iEYEARECAAYFAko1FHwACgkQ0t2Tb3OO/O37DACfT2a3X+nsrt4tuqEaImv/EFiq 0/wAoLv/C8DJkb5GHNY7/tpEhuPccvRR =P0zv -----END PGP SIGNATURE----- --sm4nu43k4a2Rpi4c-- From owner-freebsd-current@FreeBSD.ORG Sun Jun 14 08:09:19 2009 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 8B62B1065670 for ; Sun, 14 Jun 2009 08:09:19 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: from mail-ew0-f212.google.com (mail-ew0-f212.google.com [209.85.219.212]) by mx1.freebsd.org (Postfix) with ESMTP id 8487C8FC17 for ; Sun, 14 Jun 2009 08:09:17 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: by ewy8 with SMTP id 8so3466021ewy.43 for ; Sun, 14 Jun 2009 01:09:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=oAFFnorD+aUuwU/4/xvRrt+EpTEhRmOR3TVTMQiOOf0=; b=xdOsUYrxpRlM6TnKG8mynxgQnB1yaBj+OyieEiGIBdNsB9mox5KTlvV+US3G+gBJMG 0oTQQi7GaaDDxFnnLO7RNYfMY+ICWF/9Orrp9aISFvWEMeK8w1MQ8JL+6XYyNwN28qLx LMoGQxrRPNy+su1oh7AusrnYWa3xwGpS5WwVI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=FM5koSk1m4C1+F36BDRlm8V290S1IUT6mzEI+o3sTwYsDT6lVcGj3j8rp0DwDPjb0V xN0LAuKnvETc6h1Fbj+E0A8OQD150C5jElhrNksE8e6VDMqRevejp8g5B27kLVZQ5utF WziEfYr+H29AwNi98rCmhvmBQ0ru6zEptn5Gk= MIME-Version: 1.0 Received: by 10.216.39.194 with SMTP id d44mr1962913web.116.1244966956130; Sun, 14 Jun 2009 01:09:16 -0700 (PDT) Date: Sun, 14 Jun 2009 03:09:15 -0500 Message-ID: <11167f520906140109s52df389ode319bfded32613c@mail.gmail.com> From: "Sam Fourman Jr." To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 14 Jun 2009 15:41:46 +0000 Subject: FreeBSD 8.0 Asus P5N64 WS Professional ACPI error 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, 14 Jun 2009 08:09:19 -0000 hello, I am putting this information out there for archival pourposes, but I was wondering if someone would know how to fix this error in the dmesg I am not sure if this is somthing to worry about or not. atrtc1: port 0x70-0x71 on acpi0 cpu0: on acpi0 ACPI Warning (tbutils-0243): Incorrect checksum in table [OEMB] - D6, should be CE [20070320] here is a link to the motherboard http://www.asus.com/product.aspx?P_ID=o5ztautLyFiNMFcJ&templete=2 # dmesg Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-CURRENT #2: Mon Apr 13 18:21:46 CDT 2009 sfourman@:/usr/obj/usr/src/sys/Ziggy3 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 Quad CPU Q8400 @ 2.66GHz (2666.65-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x1067a Stepping = 10 Features=0xbfebfbff Features2=0x408e3bd AMD Features=0x20100000 AMD Features2=0x1 TSC: P-state invariant Cores per package: 4 real memory = 4294967296 (4096 MB) avail memory = 3139842048 (2994 MB) ACPI APIC Table: <101308 APIC1117> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: <101308 XSDT1117> on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of fec00000, 1000 (3) failed acpi0: reservation of fee00000, 1000 (3) failed acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, bff00000 (3) failed Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x2008-0x200b on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 25000000 Hz quality 900 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: at device 0.1 (no driver attached) pci0: at device 0.2 (no driver attached) pci0: at device 0.3 (no driver attached) pci0: at device 0.4 (no driver attached) pci0: at device 0.5 (no driver attached) pci0: at device 0.6 (no driver attached) pci0: at device 0.7 (no driver attached) pci0: at device 1.0 (no driver attached) pci0: at device 1.1 (no driver attached) pci0: at device 1.2 (no driver attached) pci0: at device 1.3 (no driver attached) pci0: at device 1.4 (no driver attached) pci0: at device 1.5 (no driver attached) pci0: at device 1.6 (no driver attached) pci0: at device 1.7 (no driver attached) pcib1: irq 16 at device 2.0 on pci0 pci1: on pcib1 vgapci0: port 0xdc00-0xdc7f mem 0xfa000000-0xfaffffff,0xd0000000-0xdfffffff,0xf8000000-0xf9ffffff irq 16 at device 0.0 on pci1 nvidia0: on vgapci0 vgapci0: child nvidia0 requested pci_enable_busmaster vgapci0: child nvidia0 requested pci_enable_io vgapci0: child nvidia0 requested pci_enable_io nvidia0: [GIANT-LOCKED] nvidia0: [ITHREAD] pcib2: irq 17 at device 4.0 on pci0 pci2: on pcib2 pci0: at device 9.0 (no driver attached) isab0: port 0x2f00-0x2f7f at device 10.0 on pci0 isa0: on isab0 pci0: at device 10.1 (no driver attached) ohci0: mem 0xf7ffb000-0xf7ffbfff irq 22 at device 11.0 on pci0 ohci0: [ITHREAD] usbus0: on ohci0 ehci0: mem 0xf7ffac00-0xf7ffacff irq 23 at device 11.1 on pci0 ehci0: [ITHREAD] usbus1: EHCI version 1.0 usbus1: on ehci0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 13.0 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] atapci1: port 0xc400-0xc407,0xc080-0xc083,0xc000-0xc007,0xbc00-0xbc03,0xb880-0xb88f mem 0xf7ff9000-0xf7ff9fff irq 21 at device 14.0 on pci0 atapci1: [ITHREAD] ata2: on atapci1 ata2: [ITHREAD] ata3: on atapci1 ata3: [ITHREAD] atapci2: port 0xb800-0xb807,0xb480-0xb483,0xb400-0xb407,0xb080-0xb083,0xb000-0xb00f mem 0xf7ff8000-0xf7ff8fff irq 22 at device 14.1 on pci0 atapci2: [ITHREAD] ata4: on atapci2 ata4: [ITHREAD] ata5: on atapci2 ata5: [ITHREAD] atapci3: port 0xac00-0xac07,0xa880-0xa883,0xa800-0xa807,0xa480-0xa483,0xa400-0xa40f mem 0xf7ff7000-0xf7ff7fff irq 23 at device 14.2 on pci0 atapci3: [ITHREAD] ata6: on atapci3 ata6: [ITHREAD] ata7: on atapci3 ata7: [ITHREAD] pcib3: at device 15.0 on pci0 pci3: on pcib3 fwohci0: port 0xec00-0xec7f mem 0xfbfff800-0xfbffffff irq 18 at device 7.0 on pci3 fwohci0: [ITHREAD] fwohci0: OHCI version 1.10 (ROM=1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:1e:8c:00:01:af:44:a4 fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 dcons_crom0: on firewire0 dcons_crom0: bus_addr 0xbcba8000 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:1e:8c:af:44:a4 fwe0: Ethernet address: 02:1e:8c:af:44:a4 fwip0: on firewire0 fwip0: Firewire address: 00:1e:8c:00:01:af:44:a4 @ 0xfffe00000000, S400, maxrec 2048 sbp0: on firewire0 fwohci0: Initiate bus reset fwohci0: fwohci_intr_core: BUS reset fwohci0: fwohci_intr_core: node_id=0x00000000, SelfID Count=1, CYCLEMASTER mode hdac0: mem 0xf7ff0000-0xf7ff3fff irq 21 at device 15.1 on pci0 hdac0: HDA Driver Revision: 20090401_0132 hdac0: [ITHREAD] nfe0: port 0xa080-0xa087 mem 0xf7ff6000-0xf7ff6fff,0xf7ffa800-0xf7ffa8ff,0xf7ffa400-0xf7ffa40f irq 20 at device 17.0 on pci0 miibus0: on nfe0 e1000phy0: PHY 1 on miibus0 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX-FDX, auto nfe0: Ethernet address: 00:23:54:96:dd:8d nfe0: [FILTER] nfe0: [FILTER] nfe0: [FILTER] nfe0: [FILTER] nfe0: [FILTER] nfe0: [FILTER] nfe0: [FILTER] nfe0: [FILTER] nfe1: port 0xa000-0xa007 mem 0xf7ff5000-0xf7ff5fff,0xf7ffa000-0xf7ffa0ff,0xf7ff4c00-0xf7ff4c0f irq 20 at device 18.0 on pci0 miibus1: on nfe1 e1000phy1: PHY 2 on miibus1 e1000phy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX-FDX, auto nfe1: Ethernet address: 00:23:54:96:de:2f nfe1: [FILTER] nfe1: [FILTER] nfe1: [FILTER] nfe1: [FILTER] nfe1: [FILTER] nfe1: [FILTER] nfe1: [FILTER] nfe1: [FILTER] pcib4: at device 19.0 on pci0 pci4: on pcib4 pcib5: at device 22.0 on pci0 pci5: on pcib5 pcib6: at device 23.0 on pci0 pci6: on pcib6 pcib7: at device 24.0 on pci0 pci7: on pcib7 acpi_button0: on acpi0 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FILTER] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 atrtc1: port 0x70-0x71 on acpi0 cpu0: on acpi0 ACPI Warning (tbutils-0243): Incorrect checksum in table [OEMB] - D6, should be CE [20070320] coretemp0: on cpu0 est0: on cpu0 p4tcc0: on cpu0 cpu1: on acpi0 coretemp1: on cpu1 est1: on cpu1 p4tcc1: on cpu1 cpu2: on acpi0 coretemp2: on cpu2 est2: on cpu2 p4tcc2: on cpu2 cpu3: on acpi0 coretemp3: on cpu3 est3: on cpu3 p4tcc3: on cpu3 pmtimer0 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] atrtc0: at port 0x70 irq 8 on isa0 atrtc0: Warning: Couldn't map I/O. atrtc0: Warning: Couldn't map Interrupt. ppc0: parallel port not found. Timecounters tick every 1.000 msec firewire0: 1 nodes, maxhop <= 0 Not IRM capable irm(-1) usbus0: 12Mbps Full Speed USB v1.0 usbus1: 480Mbps High Speed USB v2.0 ad4: 152627MB at ata2-master SATA300 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ad6: 152627MB at ata3-master SATA300 ad10: 238475MB at ata5-master SATA300 acd0: DVDR at ata6-master SATA150 acd1: DVDR at ata7-master SATA150 hdac0: HDA Codec #0: Analog Devices AD1988B pcm0: at cad 0 nid 1 on hdac0 pcm1: at cad 0 nid 1 on hdac0 pcm2: at cad 0 nid 1 on hdac0 uhub0: 10 ports with 10 removable, self powered GEOM: ad6: partition 1 does not end on a track boundary. GEOM: ad4s1: geometry does not match label (255h,63s != 16h,63s). GEOM_LABEL: Label for provider ad4s2 is ufsid/49e566dc1068ba46. GEOM_LABEL: Label for provider ad4s1a is ufsid/488e4b3067839641. GEOM_LABEL: Label for provider ad4s1d is ufsid/488e4b32de16fc7b. GEOM_LABEL: Label for provider ad4s1e is ufsid/488e4b305fbaa0dc. GEOM_LABEL: Label for provider ad4s1f is ufsid/488e4b30ef1fe83e. GEOM_LABEL: Label for provider ad10s1a is ufsid/4a34732705581f46. (probe8:ata4:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe8:ata4:0:0:0): CAM Status: SCSI Status Error (probe8:ata4:0:0:0): SCSI Status: Check Condition (probe8:ata4:0:0:0): NOT READY asc:3a,0 (probe8:ata4:0:0:0): Medium not present (probe8:ata4:0:0:0): Unretryable error uhub1: 10 ports with 10 removable, self powered (probe7:ata3:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe7:ata3:0:0:0): CAM Status: SCSI Status Error (probe7:ata3:0:0:0): SCSI Status: Check Condition (probe7:ata3:0:0:0): NOT READY asc:3a,0 (probe7:ata3:0:0:0): Medium not present (probe7:ata3:0:0:0): Unretryable error cd0 at ata3 bus 0 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 3.300MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present cd1 at ata4 bus 0 target 0 lun 0 cd1: Removable CD-ROM SCSI-0 device cd1: 3.300MB/s transfers cd1: Attempt to query device size failed: NOT READY, Medium not present SMP: AP CPU #1 Launched! SMP: AP CPU #3 Launched! SMP: AP CPU #2 Launched! Root mount waiting for: usbus1 Root mount waiting for: usbus1 ugen0.2: at usbus0 uhub2: on usbus0 ugen1.2: at usbus1 Trying to mount root from ufs:/dev/ad4s1a uhub2: 4 ports with 2 removable, bus powered GEOM_LABEL: Label ufsid/488e4b3067839641 removed. GEOM_LABEL: Label for provider ad4s1a is ufsid/488e4b3067839641. GEOM_LABEL: Label ufsid/488e4b305fbaa0dc removed. GEOM_LABEL: Label for provider ad4s1e is ufsid/488e4b305fbaa0dc. GEOM_LABEL: Label ufsid/488e4b30ef1fe83e removed. GEOM_LABEL: Label for provider ad4s1f is ufsid/488e4b30ef1fe83e. GEOM_LABEL: Label ufsid/488e4b32de16fc7b removed. GEOM_LABEL: Label for provider ad4s1d is ufsid/488e4b32de16fc7b. GEOM_LABEL: Label ufsid/49e566dc1068ba46 removed. GEOM_LABEL: Label for provider ad4s2 is ufsid/49e566dc1068ba46. GEOM_LABEL: Label ufsid/488e4b3067839641 removed. ugen0.3: at usbus0 ukbd0: on usbus0 kbd2 at ukbd0 uhid0: on usbus0 GEOM_LABEL: Label ufsid/488e4b305fbaa0dc removed. GEOM_LABEL: Label ufsid/488e4b30ef1fe83e removed. GEOM_LABEL: Label ufsid/488e4b32de16fc7b removed. warning: KLD '/boot/kernel.working/linprocfs.ko' is newer than the linker.hints file GEOM_LABEL: Label ufsid/49e566dc1068ba46 removed. ugen0.4: at usbus0 ums0: on usbus0 ums0: 8 buttons and [XYZ] coordinates ID=0 ugen0.5: at usbus0 uhid1: on usbus0 hid_get_item:286: Number of items truncated to 255 hid_get_item:286: Number of items truncated to 255 hid_get_item:286: Number of items truncated to 255 fuse4bsd: version 0.3.9-pre1, FUSE ABI 7.8 nfe0: link state changed to UP # Here is a acpidump # acpidump -t -d < acpi.txt /* RSD PTR: OEM=ACPIAM, ACPI_Rev=2.0x (2) XSDT=0xbff40100, length=36, cksum=40 */ /* XSDT: Length=76, Revision=1, Checksum=63, OEMID=101308, OEM Table ID=XSDT1117, OEM Revision=0x20081013, Creator ID=MSFT, Creator Revision=0x97 Entries={ 0xbff40290, 0xbff40390, 0xbff40410, 0xbff4e040, 0xbff49370 } */ /* FACP: Length=244, Revision=3, Checksum=195, OEMID=101308, OEM Table ID=FACP1117, OEM Revision=0x20081013, Creator ID=MSFT, Creator Revision=0x97 FACS=0xbff4e000, DSDT=0xbff40450 INT_MODEL=APIC Preferred_PM_Profile=Desktop (1) SCI_INT=9 SMI_CMD=0x242e, ACPI_ENABLE=0xe1, ACPI_DISABLE=0x1e, S4BIOS_REQ=0x0 PSTATE_CNT=0xe2 PM1a_EVT_BLK=0x2000-0x2003 PM1a_CNT_BLK=0x2004-0x2005 PM_TMR_BLK=0x2008-0x200b GPE0_BLK=0x2020-0x2027 GPE1_BLK=0x24a0-0x24af, GPE1_BASE=32 CST_CNT=0xe3 P_LVL2_LAT=101 us, P_LVL3_LAT=1001 us FLUSH_SIZE=1024, FLUSH_STRIDE=16 DUTY_OFFSET=1, DUTY_WIDTH=3 DAY_ALRM=125, MON_ALRM=126, CENTURY=50 IAPC_BOOT_ARCH={LEGACY_DEV,8042} Flags={WBINVD,PROC_C1,SLP_BUTTON,RTC_S4} X_FACS=0xbff4e000, X_DSDT=0xbff40450 X_PM1a_EVT_BLK=0x2000:0[32] (IO) X_PM1a_CNT_BLK=0x2004:0[16] (IO) X_PM_TMR_BLK=0x2008:0[32] (IO) X_GPE0_BLK=0x2020:0[64] (IO) X_GPE1_BLK=0x24a0:0[128] (IO) */ /* FACS: Length=64, HwSig=0x00000000, Firm_Wake_Vec=0x00000000 Global_Lock= Flags= Version=1 */ /* DSDT: Length=36639, Revision=1, Checksum=208, OEMID=A0939, OEM Table ID=A0939058, OEM Revision=0x58, Creator ID=INTL, Creator Revision=0x20060113 */ /* APIC: Length=128, Revision=1, Checksum=187, OEMID=101308, OEM Table ID=APIC1117, OEM Revision=0x20081013, Creator ID=MSFT, Creator Revision=0x97 Local APIC ADDR=0xfee00000 Flags={PC-AT} Type=Local APIC ACPI CPU=1 Flags={ENABLED} APIC ID=0 Type=Local APIC ACPI CPU=2 Flags={ENABLED} APIC ID=1 Type=Local APIC ACPI CPU=3 Flags={ENABLED} APIC ID=2 Type=Local APIC ACPI CPU=4 Flags={ENABLED} APIC ID=3 Type=IO APIC APIC ID=4 INT BASE=0 ADDR=0x00000000fec00000 Type=INT Override BUS=0 IRQ=0 INTR=2 Flags={Polarity=conforming, Trigger=conforming} Type=INT Override BUS=0 IRQ=9 INTR=9 Flags={Polarity=active-hi, Trigger=level} Type=INT Override BUS=0 IRQ=14 INTR=14 Flags={Polarity=active-hi, Trigger=edge} Type=INT Override BUS=0 IRQ=15 INTR=15 Flags={Polarity=active-hi, Trigger=edge} */ /* MCFG: Length=60, Revision=1, Checksum=96, OEMID=101308, OEM Table ID=OEMMCFG, OEM Revision=0x20081013, Creator ID=MSFT, Creator Revision=0x97 Base Address= 0x00000000e0000000 Segment Group= 0x0000 Start Bus= 0 End Bus= 255 */ /* HPET: Length=56, Revision=1, Checksum=159, OEMID=101308, OEM Table ID=OEMHPET0, OEM Revision=0x20081013, Creator ID=MSFT, Creator Revision=0x97 HPET Number=0 ADDR=0xfed00000:0[8] (Memory) HW Rev=0x1 Comparitors=2 Counter Size=0 Legacy IRQ routing capable={TRUE} PCI Vendor ID=0x10de Minimal Tick=14318 */ /* * Intel ACPI Component Architecture * AML Disassembler version 20070320 * * Disassembly of /tmp/acpidump.ghdSXi, Sun Jun 14 02:28:43 2009 * * * Original Table Header: * Signature "DSDT" * Length 0x00008F1F (36639) * Revision 0x01 * OEM ID "A0939" * OEM Table ID "A0939058" * OEM Revision 0x00000058 (88) * Creator ID "INTL" * Creator Revision 0x20060113 (537264403) */ DefinitionBlock ("/tmp/acpidump.aml", "DSDT", 1, "A0939", "A0939058", 0x00000058) { Scope (_PR) { Processor (CPU1, 0x01, 0x00002010, 0x06) { OperationRegion (STBL, SystemMemory, 0xBFF4E0C0, 0x01D2) Name (NCPU, 0x04) Name (TYPE, 0x80000000) Name (HNDL, 0x80000000) Name (CFGD, 0x01000007) Name (TBLD, 0x80) Method (_PDC, 1, NotSerialized) { CreateDWordField (Arg0, Zero, REVS) CreateDWordField (Arg0, 0x04, SIZE) Store (SizeOf (Arg0), Local0) Store (Subtract (Local0, 0x08), Local1) CreateField (Arg0, 0x40, Multiply (Local1, 0x08), TEMP) Name (STS0, Buffer (0x04) { 0x00, 0x00, 0x00, 0x00 }) Concatenate (STS0, TEMP, Local2) _OSC (Buffer (0x10) { /* 0000 */ 0x16, 0xA6, 0x77, 0x40, 0x0C, 0x29, 0xBE, 0x47, /* 0008 */ 0x9E, 0xBD, 0xD8, 0x70, 0x58, 0x71, 0x39, 0x53 }, REVS, SIZE, Local2) } Method (_OSC, 4, NotSerialized) { CreateDWordField (Arg3, Zero, STS0) CreateDWordField (Arg3, 0x04, CAP0) CreateDWordField (Arg0, Zero, IID0) CreateDWordField (Arg0, 0x04, IID1) CreateDWordField (Arg0, 0x08, IID2) CreateDWordField (Arg0, 0x0C, IID3) Name (UID0, Buffer (0x10) { /* 0000 */ 0x16, 0xA6, 0x77, 0x40, 0x0C, 0x29, 0xBE, 0x47, /* 0008 */ 0x9E, 0xBD, 0xD8, 0x70, 0x58, 0x71, 0x39, 0x53 }) CreateDWordField (UID0, Zero, EID0) CreateDWordField (UID0, 0x04, EID1) CreateDWordField (UID0, 0x08, EID2) CreateDWordField (UID0, 0x0C, EID3) If (LNot (LAnd (LAnd (LEqual (IID0, EID0), LEqual (IID1, EID1)), LAnd (LEqual (IID2, EID2), LEqual (IID3, EID3))))) { Store (0x06, STS0) Return (Arg3) } If (LNotEqual (Arg1, One)) { Store (0x0A, STS0) Return (Arg3) } Or (And (TYPE, 0x7FFFFFFF), CAP0, TYPE) If (And (CFGD, One)) { If (LAnd (LAnd (And (CFGD, 0x01000000), LEqual (And (TYPE, 0x09), 0x09)), LNot (And (TBLD, One)))) { Or (TBLD, One, TBLD) Load (STBL, HNDL) } } If (And (CFGD, 0xF0)) { If (LAnd (LAnd (And (CFGD, 0x01000000), And (TYPE, 0x18 )), LNot (And (TBLD, 0x02)))) { Or (TBLD, 0x02, TBLD) } } Return (Arg3) } } } Scope (_PR) { Processor (CPU2, 0x02, 0x00000810, 0x06) { OperationRegion (STBL, SystemMemory, 0xBFF4E2A0, 0x0143) Name (NCPU, 0x04) Name (TYPE, 0x80000000) Name (HNDL, 0x80000000) Name (CFGD, 0x01000007) Name (TBLD, 0x80) Method (_PDC, 1, NotSerialized) { CreateDWordField (Arg0, Zero, REVS) CreateDWordField (Arg0, 0x04, SIZE) Store (SizeOf (Arg0), Local0) Store (Subtract (Local0, 0x08), Local1) CreateField (Arg0, 0x40, Multiply (Local1, 0x08), TEMP) Name (STS1, Buffer (0x04) { 0x00, 0x00, 0x00, 0x00 }) Concatenate (STS1, TEMP, Local2) _OSC (Buffer (0x10) { /* 0000 */ 0x16, 0xA6, 0x77, 0x40, 0x0C, 0x29, 0xBE, 0x47, /* 0008 */ 0x9E, 0xBD, 0xD8, 0x70, 0x58, 0x71, 0x39, 0x53 }, REVS, SIZE, Local2) } Method (_OSC, 4, NotSerialized) { CreateDWordField (Arg3, Zero, STS1) CreateDWordField (Arg3, 0x04, CAP1) CreateDWordField (Arg0, Zero, IID0) CreateDWordField (Arg0, 0x04, IID1) CreateDWordField (Arg0, 0x08, IID2) CreateDWordField (Arg0, 0x0C, IID3) Name (UID0, Buffer (0x10) { /* 0000 */ 0x16, 0xA6, 0x77, 0x40, 0x0C, 0x29, 0xBE, 0x47, /* 0008 */ 0x9E, 0xBD, 0xD8, 0x70, 0x58, 0x71, 0x39, 0x53 }) CreateDWordField (UID0, Zero, EID0) CreateDWordField (UID0, 0x04, EID1) CreateDWordField (UID0, 0x08, EID2) CreateDWordField (UID0, 0x0C, EID3) If (LNot (LAnd (LAnd (LEqual (IID0, EID0), LEqual (IID1, EID1)), LAnd (LEqual (IID2, EID2), LEqual (IID3, EID3))))) { Store (0x06, STS1) Return (Arg3) } If (LNotEqual (Arg1, One)) { Store (0x0A, STS1) Return (Arg3) } Or (And (TYPE, 0x7FFFFFFF), CAP1, TYPE) If (And (CFGD, One)) { If (LAnd (LAnd (And (CFGD, 0x01000000), LEqual (And (TYPE, 0x09), 0x09)), LNot (And (TBLD, One)))) { Or (TBLD, One, TBLD) Load (STBL, HNDL) } } If (And (CFGD, 0xF0)) { If (LAnd (LAnd (And (CFGD, 0x01000000), And (TYPE, 0x18 )), LNot (And (TBLD, 0x02)))) { Or (TBLD, 0x02, TBLD) } } Return (Arg3) } } } Scope (_PR) { Processor (CPU3, 0x03, 0x00000810, 0x06) { OperationRegion (STBL, SystemMemory, 0xBFF4E3F0, 0x0143) Name (NCPU, 0x04) Name (TYPE, 0x80000000) Name (HNDL, 0x80000000) Name (CFGD, 0x01000007) Name (TBLD, 0x80) Method (_PDC, 1, NotSerialized) { CreateDWordField (Arg0, Zero, REVS) CreateDWordField (Arg0, 0x04, SIZE) Store (SizeOf (Arg0), Local0) Store (Subtract (Local0, 0x08), Local1) CreateField (Arg0, 0x40, Multiply (Local1, 0x08), TEMP) Name (STS2, Buffer (0x04) { 0x00, 0x00, 0x00, 0x00 }) Concatenate (STS2, TEMP, Local2) _OSC (Buffer (0x10) { /* 0000 */ 0x16, 0xA6, 0x77, 0x40, 0x0C, 0x29, 0xBE, 0x47, /* 0008 */ 0x9E, 0xBD, 0xD8, 0x70, 0x58, 0x71, 0x39, 0x53 }, REVS, SIZE, Local2) } Method (_OSC, 4, NotSerialized) { CreateDWordField (Arg3, Zero, STS2) CreateDWordField (Arg3, 0x04, CAP2) CreateDWordField (Arg0, Zero, IID0) CreateDWordField (Arg0, 0x04, IID1) CreateDWordField (Arg0, 0x08, IID2) CreateDWordField (Arg0, 0x0C, IID3) Name (UID0, Buffer (0x10) { /* 0000 */ 0x16, 0xA6, 0x77, 0x40, 0x0C, 0x29, 0xBE, 0x47, /* 0008 */ 0x9E, 0xBD, 0xD8, 0x70, 0x58, 0x71, 0x39, 0x53 }) CreateDWordField (UID0, Zero, EID0) CreateDWordField (UID0, 0x04, EID1) CreateDWordField (UID0, 0x08, EID2) CreateDWordField (UID0, 0x0C, EID3) If (LNot (LAnd (LAnd (LEqual (IID0, EID0), LEqual (IID1, EID1)), LAnd (LEqual (IID2, EID2), LEqual (IID3, EID3))))) { Store (0x06, STS2) Return (Arg3) } If (LNotEqual (Arg1, One)) { Store (0x0A, STS2) Return (Arg3) } Or (And (TYPE, 0x7FFFFFFF), CAP2, TYPE) If (And (CFGD, One)) { If (LAnd (LAnd (And (CFGD, 0x01000000), LEqual (And (TYPE, 0x09), 0x09)), LNot (And (TBLD, One)))) { Or (TBLD, One, TBLD) Load (STBL, HNDL) } } If (And (CFGD, 0xF0)) { If (LAnd (LAnd (And (CFGD, 0x01000000), And (TYPE, 0x18 )), LNot (And (TBLD, 0x02)))) { Or (TBLD, 0x02, TBLD) } } Return (Arg3) } } } Scope (_PR) { Processor (CPU4, 0x04, 0x00000810, 0x06) { OperationRegion (STBL, SystemMemory, 0xBFF4E540, 0x0143) Name (NCPU, 0x04) Name (TYPE, 0x80000000) Name (HNDL, 0x80000000) Name (CFGD, 0x01000007) Name (TBLD, 0x80) Method (_PDC, 1, NotSerialized) { CreateDWordField (Arg0, Zero, REVS) CreateDWordField (Arg0, 0x04, SIZE) Store (SizeOf (Arg0), Local0) Store (Subtract (Local0, 0x08), Local1) CreateField (Arg0, 0x40, Multiply (Local1, 0x08), TEMP) Name (STS3, Buffer (0x04) { 0x00, 0x00, 0x00, 0x00 }) Concatenate (STS3, TEMP, Local2) _OSC (Buffer (0x10) { /* 0000 */ 0x16, 0xA6, 0x77, 0x40, 0x0C, 0x29, 0xBE, 0x47, /* 0008 */ 0x9E, 0xBD, 0xD8, 0x70, 0x58, 0x71, 0x39, 0x53 }, REVS, SIZE, Local2) } Method (_OSC, 4, NotSerialized) { CreateDWordField (Arg3, Zero, STS3) CreateDWordField (Arg3, 0x04, CAP3) CreateDWordField (Arg0, Zero, IID0) CreateDWordField (Arg0, 0x04, IID1) CreateDWordField (Arg0, 0x08, IID2) CreateDWordField (Arg0, 0x0C, IID3) Name (UID0, Buffer (0x10) { /* 0000 */ 0x16, 0xA6, 0x77, 0x40, 0x0C, 0x29, 0xBE, 0x47, /* 0008 */ 0x9E, 0xBD, 0xD8, 0x70, 0x58, 0x71, 0x39, 0x53 }) CreateDWordField (UID0, Zero, EID0) CreateDWordField (UID0, 0x04, EID1) CreateDWordField (UID0, 0x08, EID2) CreateDWordField (UID0, 0x0C, EID3) If (LNot (LAnd (LAnd (LEqual (IID0, EID0), LEqual (IID1, EID1)), LAnd (LEqual (IID2, EID2), LEqual (IID3, EID3))))) { Store (0x06, STS3) Return (Arg3) } If (LNotEqual (Arg1, One)) { Store (0x0A, STS3) Return (Arg3) } Or (And (TYPE, 0x7FFFFFFF), CAP3, TYPE) If (And (CFGD, One)) { If (LAnd (LAnd (And (CFGD, 0x01000000), LEqual (And (TYPE, 0x09), 0x09)), LNot (And (TBLD, One)))) { Or (TBLD, One, TBLD) Load (STBL, HNDL) } } If (And (CFGD, 0xF0)) { If (LAnd (LAnd (And (CFGD, 0x01000000), And (TYPE, 0x18 )), LNot (And (TBLD, 0x02)))) { Or (TBLD, 0x02, TBLD) } } Return (Arg3) } } } Name (FZTF, Buffer (0x07) { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xF5 }) Name (DP80, 0x80) Name (DP90, 0x90) Name (SPIO, 0x2E) Name (IOPB, 0x0C00) Name (IOPL, 0x10) Name (IOEB, 0x0D00) Name (IOEL, 0x10) Name (IOGB, 0x0A20) Name (IOGL, 0x10) Name (IODB, 0x0A30) Name (IODL, 0x10) Name (IO1B, 0x0A20) Name (IO1L, 0x08) Name (IO3B, 0x0D00) Name (IO3L, 0x80) Name (SSMI, 0x242E) Name (SSEP, 0x99) Name (SSEN, One) Name (SHPB, 0xFED00000) Name (SHPL, 0x1000) Name (PMBS, 0x2000) Name (PMLN, 0x0100) Name (SCBS, 0x2400) Name (SCLN, 0x0100) Name (ACBS, 0x2800) Name (ACLN, 0x0100) Name (MTAB, 0x2F00) Name (MTAL, 0x0100) Name (IGPB, 0x2C00) Name (IGLN, 0x0100) Name (ACA4, 0x20A4) Name (SCIO, 0x2400) Name (SCTL, 0x2090) Name (EXTS, Zero) Name (MUAE, Zero) Name (APIC, One) Name (T1OF, Zero) Name (T2OF, Zero) Name (T3OF, Zero) Name (CQST, 0x3C) Name (PCIB, 0xE0000000) Name (PCIL, 0x10000000) Name (SMIT, 0x242E) Name (CMRQ, 0xE0) Name (CMER, 0xE1) Name (CMOR, 0xE3) Name (NSLB, 0xD0000000) Name (SMBS, 0x2D00) OperationRegion (BIOS, SystemMemory, 0xBFF4E064, 0xFF) Field (BIOS, ByteAcc, NoLock, Preserve) { SS1, 1, SS2, 1, SS3, 1, SS4, 1, Offset (0x01), IOST, 16, TOPM, 32, ROMS, 32, MG1B, 32, MG1L, 32, MG2B, 32, MG2L, 32, Offset (0x1C), DMAX, 8, HPTA, 32, CPB0, 32, CPB1, 32, CPB2, 32, CPB3, 32, ASSB, 8, AOTB, 8, AAXB, 32, SMIF, 8, DTSE, 8, DTS1, 8, DTS2, 8, MPEN, 8, TPMF, 8, MG3B, 32, MG3L, 32, MH1B, 32, MH1L, 32 } Method (RRIO, 4, NotSerialized) { Store ("RRIO", Debug) } Method (RDMA, 3, NotSerialized) { Store ("rDMA", Debug) } Name (PICM, Zero) Method (_PIC, 1, NotSerialized) { If (Arg0) { Store (0xAA, DBG8) } Else { Store (0xAC, DBG8) } Store (Arg0, PICM) } Name (OSVR, Ones) Method (OSFL, 0, NotSerialized) { If (LNotEqual (OSVR, Ones)) { Return (OSVR) } If (LEqual (PICM, Zero)) { Store (0xAC, DBG8) } Store (One, OSVR) If (CondRefOf (_OSI, Local1)) { If (_OSI ("Windows 2000")) { Store (0x04, OSVR) } If (_OSI ("Windows 2001")) { Store (Zero, OSVR) } If (_OSI ("Windows 2001 SP1")) { Store (Zero, OSVR) } If (_OSI ("Windows 2001 SP2")) { Store (Zero, OSVR) } If (_OSI ("Windows 2001.1")) { Store (Zero, OSVR) } If (_OSI ("Windows 2001.1 SP1")) { Store (Zero, OSVR) } If (_OSI ("Windows 2006")) { Store (Zero, OSVR) } } Else { If (MCTH (_OS, "Microsoft Windows NT")) { Store (0x04, OSVR) } Else { If (MCTH (_OS, "Microsoft WindowsME: Millennium Edition")) { Store (0x02, OSVR) } If (MCTH (_OS, "Linux")) { Store (0x03, OSVR) } } } Return (OSVR) } Method (MCTH, 2, NotSerialized) { If (LLess (SizeOf (Arg0), SizeOf (Arg1))) { Return (Zero) } Add (SizeOf (Arg0), One, Local0) Name (BUF0, Buffer (Local0) {}) Name (BUF1, Buffer (Local0) {}) Store (Arg0, BUF0) Store (Arg1, BUF1) While (Local0) { Decrement (Local0) If (LNotEqual (DerefOf (Index (BUF0, Local0)), DerefOf (Index ( BUF1, Local0)))) { Return (Zero) } } Return (One) } Name (PRWP, Package (0x02) { Zero, Zero }) Method (GPRW, 2, NotSerialized) { Store (Arg0, Index (PRWP, Zero)) Store (ShiftLeft (SS1, One), Local0) Or (Local0, ShiftLeft (SS2, 0x02), Local0) Or (Local0, ShiftLeft (SS3, 0x03), Local0) Or (Local0, ShiftLeft (SS4, 0x04), Local0) If (And (ShiftLeft (One, Arg1), Local0)) { Store (Arg1, Index (PRWP, One)) } Else { ShiftRight (Local0, One, Local0) If (LOr (LEqual (OSFL (), One), LEqual (OSFL (), 0x02))) { FindSetLeftBit (Local0, Index (PRWP, One)) } Else { FindSetRightBit (Local0, Index (PRWP, One)) } } Return (PRWP) } Name (WAKP, Package (0x02) { Zero, Zero }) OperationRegion (DEB0, SystemIO, DP80, One) Field (DEB0, ByteAcc, NoLock, Preserve) { DBG8, 8 } OperationRegion (DEB1, SystemIO, DP90, 0x02) Field (DEB1, WordAcc, NoLock, Preserve) { DBG9, 16 } Scope (_SB) { Name (PR00, Package (0x36) { Package (0x04) { 0x000AFFFF, Zero, LSMB, Zero }, Package (0x04) { 0x000AFFFF, One, LPMU, Zero }, Package (0x04) { 0x000BFFFF, One, LUB2, Zero }, Package (0x04) { 0x0011FFFF, Zero, LMAC, Zero }, Package (0x04) { 0x0012FFFF, Zero, LMAD, Zero }, Package (0x04) { 0x000EFFFF, Zero, LSA0, Zero }, Package (0x04) { 0x000EFFFF, One, LSA1, Zero }, Package (0x04) { 0x000EFFFF, 0x02, LSA2, Zero }, Package (0x04) { 0x000FFFFF, One, LAZA, Zero }, Package (0x04) { 0x0018FFFF, Zero, LNEA, Zero }, Package (0x04) { 0x0018FFFF, One, LNEB, Zero }, Package (0x04) { 0x0018FFFF, 0x02, LNEC, Zero }, Package (0x04) { 0x0018FFFF, 0x03, LNED, Zero }, Package (0x04) { 0x0017FFFF, Zero, LNEB, Zero }, Package (0x04) { 0x0017FFFF, One, LNEC, Zero }, Package (0x04) { 0x0017FFFF, 0x02, LNED, Zero }, Package (0x04) { 0x0017FFFF, 0x03, LNEA, Zero }, Package (0x04) { 0x0016FFFF, Zero, LNEC, Zero }, Package (0x04) { 0x0016FFFF, One, LNED, Zero }, Package (0x04) { 0x0016FFFF, 0x02, LNEA, Zero }, Package (0x04) { 0x0016FFFF, 0x03, LNEC, Zero }, Package (0x04) { 0x0015FFFF, Zero, LNED, Zero }, Package (0x04) { 0x0015FFFF, One, LNEA, Zero }, Package (0x04) { 0x0015FFFF, 0x02, LNEB, Zero }, Package (0x04) { 0x0015FFFF, 0x03, LNEC, Zero }, Package (0x04) { 0x0014FFFF, Zero, LNEA, Zero }, Package (0x04) { 0x0014FFFF, One, LNEB, Zero }, Package (0x04) { 0x0014FFFF, 0x02, LNEC, Zero }, Package (0x04) { 0x0014FFFF, 0x03, LNED, Zero }, Package (0x04) { 0x0013FFFF, Zero, LNEB, Zero }, Package (0x04) { 0x0013FFFF, One, LNEC, Zero }, Package (0x04) { 0x0013FFFF, 0x02, LNED, Zero }, Package (0x04) { 0x0013FFFF, 0x03, LNEA, Zero }, Package (0x04) { 0x0002FFFF, Zero, LNEA, Zero }, Package (0x04) { 0x0002FFFF, One, LNEB, Zero }, Package (0x04) { 0x0002FFFF, 0x02, LNEC, Zero }, Package (0x04) { 0x0002FFFF, 0x03, LNED, Zero }, Package (0x04) { 0x0003FFFF, Zero, LNEB, Zero }, Package (0x04) { 0x0003FFFF, One, LNEC, Zero }, Package (0x04) { 0x0003FFFF, 0x02, LNED, Zero }, Package (0x04) { 0x0003FFFF, 0x03, LNEA, Zero }, Package (0x04) { 0x0004FFFF, Zero, LNEC, Zero }, Package (0x04) { 0x0004FFFF, One, LNED, Zero }, Package (0x04) { 0x0004FFFF, 0x02, LNEA, Zero }, Package (0x04) { 0x0004FFFF, 0x03, LNEB, Zero }, Package (0x04) { 0x0005FFFF, Zero, LNED, Zero }, Package (0x04) { 0x0005FFFF, One, LNEA, Zero }, Package (0x04) { 0x0005FFFF, 0x02, LNEB, Zero }, Package (0x04) { 0x0005FFFF, 0x03, LNEC, Zero }, Package (0x04) { 0x0006FFFF, Zero, LNEA, Zero }, Package (0x04) { 0x0006FFFF, One, LNEB, Zero }, Package (0x04) { 0x0006FFFF, 0x02, LNEC, Zero }, Package (0x04) { 0x0006FFFF, 0x03, LNED, Zero }, Package (0x04) { 0x000BFFFF, Zero, LUB0, Zero } }) Name (AR00, Package (0x36) { Package (0x04) { 0x000AFFFF, Zero, LSMB, Zero }, Package (0x04) { 0x000AFFFF, One, LPMU, Zero }, Package (0x04) { 0x000BFFFF, One, LUB2, Zero }, Package (0x04) { 0x0011FFFF, Zero, LMAC, Zero }, Package (0x04) { 0x0012FFFF, Zero, LMAD, Zero }, Package (0x04) { 0x000EFFFF, Zero, LSA0, Zero }, Package (0x04) { 0x000EFFFF, One, LSA1, Zero }, Package (0x04) { 0x000EFFFF, 0x02, LSA2, Zero }, Package (0x04) { 0x000FFFFF, One, LAZA, Zero }, Package (0x04) { 0x0018FFFF, Zero, LNEA, Zero }, Package (0x04) { 0x0018FFFF, One, LNEB, Zero }, Package (0x04) { 0x0018FFFF, 0x02, LNEC, Zero }, Package (0x04) { 0x0018FFFF, 0x03, LNED, Zero }, Package (0x04) { 0x0017FFFF, Zero, LNEB, Zero }, Package (0x04) { 0x0017FFFF, One, LNEC, Zero }, Package (0x04) { 0x0017FFFF, 0x02, LNED, Zero }, Package (0x04) { 0x0017FFFF, 0x03, LNEA, Zero }, Package (0x04) { 0x0016FFFF, Zero, LNEC, Zero }, Package (0x04) { 0x0016FFFF, One, LNED, Zero }, Package (0x04) { 0x0016FFFF, 0x02, LNEA, Zero }, Package (0x04) { 0x0016FFFF, 0x03, LNEB, Zero }, Package (0x04) { 0x0015FFFF, Zero, LNED, Zero }, Package (0x04) { 0x0015FFFF, One, LNEA, Zero }, Package (0x04) { 0x0015FFFF, 0x02, LNEB, Zero }, Package (0x04) { 0x0015FFFF, 0x03, LNEC, Zero }, Package (0x04) { 0x0014FFFF, Zero, LNEA, Zero }, Package (0x04) { 0x0014FFFF, One, LNEB, Zero }, Package (0x04) { 0x0014FFFF, 0x02, LNEC, Zero }, Package (0x04) { 0x0014FFFF, 0x03, LNED, Zero }, Package (0x04) { 0x0013FFFF, Zero, LNEB, Zero }, Package (0x04) { 0x0013FFFF, One, LNEC, Zero }, Package (0x04) { 0x0013FFFF, 0x02, LNED, Zero }, Package (0x04) { 0x0013FFFF, 0x03, LNEA, Zero }, Package (0x04) { 0x0002FFFF, Zero, LNEA, Zero }, Package (0x04) { 0x0002FFFF, One, LNEB, Zero }, Package (0x04) { 0x0002FFFF, 0x02, LNEC, Zero }, Package (0x04) { 0x0002FFFF, 0x03, LNED, Zero }, Package (0x04) { 0x0003FFFF, Zero, LNEB, Zero }, Package (0x04) { 0x0003FFFF, One, LNEC, Zero }, Package (0x04) { 0x0003FFFF, 0x02, LNED, Zero }, Package (0x04) { 0x0003FFFF, 0x03, LNEA, Zero }, Package (0x04) { 0x0004FFFF, Zero, LNEC, Zero }, Package (0x04) { 0x0004FFFF, One, LNED, Zero }, Package (0x04) { 0x0004FFFF, 0x02, LNEA, Zero }, Package (0x04) { 0x0004FFFF, 0x03, LNEB, Zero }, Package (0x04) { 0x0005FFFF, Zero, LNED, Zero }, Package (0x04) { 0x0005FFFF, One, LNEA, Zero }, Package (0x04) { 0x0005FFFF, 0x02, LNEB, Zero }, Package (0x04) { 0x0005FFFF, 0x03, LNEC, Zero }, Package (0x04) { 0x0006FFFF, Zero, LNEA, Zero }, Package (0x04) { 0x0006FFFF, One, LNEB, Zero }, Package (0x04) { 0x0006FFFF, 0x02, LNEC, Zero }, Package (0x04) { 0x0006FFFF, 0x03, LNED, Zero }, Package (0x04) { 0x000BFFFF, Zero, LUB0, Zero } }) Name (PR10, Package (0x04) { Package (0x04) { 0xFFFF, Zero, LNEA, Zero }, Package (0x04) { 0xFFFF, One, LNEB, Zero }, Package (0x04) { 0xFFFF, 0x02, LNEC, Zero }, Package (0x04) { 0xFFFF, 0x03, LNED, Zero } }) Name (AR10, Package (0x04) { Package (0x04) { 0xFFFF, Zero, LNEA, Zero }, Package (0x04) { 0xFFFF, One, LNEB, Zero }, Package (0x04) { 0xFFFF, 0x02, LNEC, Zero }, Package (0x04) { 0xFFFF, 0x03, LNED, Zero } }) Name (PR11, Package (0x04) { Package (0x04) { 0xFFFF, Zero, LNEB, Zero }, Package (0x04) { 0xFFFF, One, LNEC, Zero }, Package (0x04) { 0xFFFF, 0x02, LNED, Zero }, Package (0x04) { 0xFFFF, 0x03, LNEA, Zero } }) Name (AR11, Package (0x04) { Package (0x04) { 0xFFFF, Zero, LNEB, Zero }, Package (0x04) { 0xFFFF, One, LNEC, Zero }, Package (0x04) { 0xFFFF, 0x02, LNED, Zero }, Package (0x04) { 0xFFFF, 0x03, LNEA, Zero } }) Name (PR12, Package (0x04) { Package (0x04) { 0xFFFF, Zero, LNEC, Zero }, Package (0x04) { 0xFFFF, One, LNED, Zero }, Package (0x04) { 0xFFFF, 0x02, LNEA, Zero }, Package (0x04) { 0xFFFF, 0x03, LNEB, Zero } }) Name (AR12, Package (0x04) { Package (0x04) { 0xFFFF, Zero, LNEC, Zero }, Package (0x04) { 0xFFFF, One, LNED, Zero }, Package (0x04) { 0xFFFF, 0x02, LNEA, Zero }, Package (0x04) { 0xFFFF, 0x03, LNEB, Zero } }) Name (PR13, Package (0x04) { Package (0x04) { 0xFFFF, Zero, LNED, Zero }, Package (0x04) { 0xFFFF, One, LNEA, Zero }, Package (0x04) { 0xFFFF, 0x02, LNEB, Zero }, Package (0x04) { 0xFFFF, 0x03, LNEC, Zero } }) Name (AR13, Package (0x04) { Package (0x04) { 0xFFFF, Zero, LNED, Zero }, Package (0x04) { 0xFFFF, One, LNEA, Zero }, Package (0x04) { 0xFFFF, 0x02, LNEB, Zero }, Package (0x04) { 0xFFFF, 0x03, LNEC, Zero } }) Name (PR14, Package (0x04) { Package (0x04) { 0xFFFF, Zero, LNEA, Zero }, Package (0x04) { 0xFFFF, One, LNEB, Zero }, Package (0x04) { 0xFFFF, 0x02, LNEC, Zero }, Package (0x04) { 0xFFFF, 0x03, LNED, Zero } }) Name (AR14, Package (0x04) { Package (0x04) { 0xFFFF, Zero, LNEA, Zero }, Package (0x04) { 0xFFFF, One, LNEB, Zero }, Package (0x04) { 0xFFFF, 0x02, LNEC, Zero }, Package (0x04) { 0xFFFF, 0x03, LNED, Zero } }) Name (PR15, Package (0x04) { Package (0x04) { 0xFFFF, Zero, LNEB, Zero }, Package (0x04) { 0xFFFF, One, LNEC, Zero }, Package (0x04) { 0xFFFF, 0x02, LNED, Zero }, Package (0x04) { 0xFFFF, 0x03, LNEA, Zero } }) Name (AR15, Package (0x04) { Package (0x04) { 0xFFFF, Zero, LNEB, Zero }, Package (0x04) { 0xFFFF, One, LNEC, Zero }, Package (0x04) { 0xFFFF, 0x02, LNED, Zero }, Package (0x04) { 0xFFFF, 0x03, LNEA, Zero } }) Name (PR08, Package (0x04) { Package (0x04) { 0xFFFF, Zero, LNEA, Zero }, Package (0x04) { 0xFFFF, One, LNEB, Zero }, Package (0x04) { 0xFFFF, 0x02, LNEC, Zero }, Package (0x04) { 0xFFFF, 0x03, LNED, Zero } }) Name (AR08, Package (0x04) { Package (0x04) { 0xFFFF, Zero, LNEA, Zero }, Package (0x04) { 0xFFFF, One, LNEB, Zero }, Package (0x04) { 0xFFFF, 0x02, LNEC, Zero }, Package (0x04) { 0xFFFF, 0x03, LNED, Zero } }) Name (PR0A, Package (0x04) { Package (0x04) { 0xFFFF, Zero, LNEB, Zero }, Package (0x04) { 0xFFFF, One, LNEC, Zero }, Package (0x04) { 0xFFFF, 0x02, LNED, Zero }, Package (0x04) { 0xFFFF, 0x03, LNEA, Zero } }) Name (AR0A, Package (0x04) { Package (0x04) { 0xFFFF, Zero, LNEB, Zero }, Package (0x04) { 0xFFFF, One, LNEC, Zero }, Package (0x04) { 0xFFFF, 0x02, LNED, Zero }, Package (0x04) { 0xFFFF, 0x03, LNEA, Zero } }) Name (PR0B, Package (0x04) { Package (0x04) { 0xFFFF, Zero, LNEC, Zero }, Package (0x04) { 0xFFFF, One, LNED, Zero }, Package (0x04) { 0xFFFF, 0x02, LNEA, Zero }, Package (0x04) { 0xFFFF, 0x03, LNEB, Zero } }) Name (AR0B, Package (0x04) { Package (0x04) { 0xFFFF, Zero, LNEC, Zero }, Package (0x04) { 0xFFFF, One, LNED, Zero }, Package (0x04) { 0xFFFF, 0x02, LNEA, Zero }, Package (0x04) { 0xFFFF, 0x03, LNEB, Zero } }) Name (PR0C, Package (0x04) { Package (0x04) { 0xFFFF, Zero, LNED, Zero }, Package (0x04) { 0xFFFF, One, LNEA, Zero }, Package (0x04) { 0xFFFF, 0x02, LNEB, Zero }, Package (0x04) { 0xFFFF, 0x03, LNEC, Zero } }) Name (AR0C, Package (0x04) { Package (0x04) { 0xFFFF, Zero, LNED, Zero }, Package (0x04) { 0xFFFF, One, LNEA, Zero }, Package (0x04) { 0xFFFF, 0x02, LNEB, Zero }, Package (0x04) { 0xFFFF, 0x03, LNEC, Zero } }) Name (PR0D, Package (0x04) { Package (0x04) { 0xFFFF, Zero, LNEA, Zero }, Package (0x04) { 0xFFFF, One, LNEB, Zero }, Package (0x04) { 0xFFFF, 0x02, LNEC, Zero }, Package (0x04) { 0xFFFF, 0x03, LNED, Zero } }) Name (AR0D, Package (0x04) { Package (0x04) { 0xFFFF, Zero, LNEA, Zero }, Package (0x04) { 0xFFFF, One, LNEB, Zero }, Package (0x04) { 0xFFFF, 0x02, LNEC, Zero }, Package (0x04) { 0xFFFF, 0x03, LNED, Zero } }) Name (PR01, Package (0x09) { Package (0x04) { 0x000AFFFF, Zero, LNKA, Zero }, Package (0x04) { 0x000AFFFF, One, LNKB, Zero }, Package (0x04) { 0x000AFFFF, 0x02, LNKC, Zero }, Package (0x04) { 0x000AFFFF, 0x03, LNKD, Zero }, Package (0x04) { 0x0009FFFF, Zero, LNKB, Zero }, Package (0x04) { 0x0009FFFF, One, LNKC, Zero }, Package (0x04) { 0x0009FFFF, 0x02, LNKD, Zero }, Package (0x04) { 0x0009FFFF, 0x03, LNKA, Zero }, Package (0x04) { 0x0007FFFF, Zero, LNKD, Zero } }) Name (AR01, Package (0x09) { Package (0x04) { 0x000AFFFF, Zero, LNKA, Zero }, Package (0x04) { 0x000AFFFF, One, LNKB, Zero }, Package (0x04) { 0x000AFFFF, 0x02, LNKC, Zero }, Package (0x04) { 0x000AFFFF, 0x03, LNKD, Zero }, Package (0x04) { 0x0009FFFF, Zero, LNKB, Zero }, Package (0x04) { 0x0009FFFF, One, LNKC, Zero }, Package (0x04) { 0x0009FFFF, 0x02, LNKD, Zero }, Package (0x04) { 0x0009FFFF, 0x03, LNKA, Zero }, Package (0x04) { 0x0007FFFF, Zero, LNKD, Zero } }) Name (PRSA, ResourceTemplate () { IRQ (Level, ActiveLow, Shared, ) {5,7,10,11,14} }) Alias (PRSA, PRSB) Alias (PRSA, PRSC) Alias (PRSA, PRSD) Alias (PRSA, RSEA) Alias (PRSA, RSEB) Alias (PRSA, RSEC) Alias (PRSA, RSED) Alias (PRSA, RSMB) Alias (PRSA, RSB2) Alias (PRSA, RSMU) Alias (PRSA, RSA1) Alias (PRSA, RSA0) Alias (PRSA, RSB0) Alias (PRSA, RSAD) Alias (PRSA, RSAC) Alias (PRSA, RSZA) Alias (PRSA, RSTA) Alias (PRSA, RSA2) Name (RSIR, ResourceTemplate () { Interrupt (ResourceConsumer, Level, ActiveLow, Shared, ,, ) { 0x00000010, 0x00000011, 0x00000012, 0x00000013, } }) Name (RS20, ResourceTemplate () { Interrupt (ResourceConsumer, Level, ActiveLow, Shared, ,, ) { 0x00000014, } }) Name (RSII, ResourceTemplate () { Interrupt (ResourceConsumer, Level, ActiveLow, Shared, ,, ) { 0x00000015, 0x00000016, 0x00000017, } }) Device (PCI0) { Name (_HID, EisaId ("PNP0A03")) Name (_ADR, Zero) Method (^BN00, 0, NotSerialized) { Return (Zero) } Method (_BBN, 0, NotSerialized) { Return (BN00 ()) } Name (_UID, Zero) Method (_PRT, 0, NotSerialized) { If (PICM) { Return (AR00) } Return (PR00) } Method (NPTS, 1, NotSerialized) { } Method (NWAK, 1, NotSerialized) { } Device (MICP) { Name (_ADR, 0x02) } Device (SBRG) { Name (_ADR, 0x000A0000) Method (SPTS, 1, NotSerialized) { Store (Arg0, ^^IDE0.PTS0) Store (^^IDE0.ID20, ^^IDE0.SID0) Store (^^IDE0.IDTS, ^^IDE0.SID1) Store (^^IDE0.IDTP, ^^IDE0.SID2) Store (^^IDE0.ID22, ^^IDE0.SID3) Store (^^IDE0.UMSS, ^^IDE0.SID4) Store (^^IDE0.UMSP, ^^IDE0.SID5) Store (One, PS1S) Store (One, PS1E) Store (One, SLPS) } Method (SWAK, 1, NotSerialized) { Store (Zero, SLPS) Store (Zero, PS1E) Store (0x02, S1CT) Store (0x02, S3CT) Store (0x02, S4CT) Store (0x02, S5CT) } OperationRegion (SMIE, SystemIO, SCIO, 0x08) Field (SMIE, ByteAcc, NoLock, Preserve) { , 15, PS1S, 1, , 31, PS1E, 1, Offset (0x08) } OperationRegion (SXCT, SystemIO, SCTL, 0x10) Field (SXCT, ByteAcc, NoLock, Preserve) { S1CT, 2, Offset (0x04), S3CT, 2, Offset (0x08), S4CT, 2, Offset (0x0C), S5CT, 2, Offset (0x10) } Scope (\_SB) { OperationRegion (\SCPP, SystemIO, SSMI, One) Field (SCPP, ByteAcc, NoLock, Preserve) { SMIP, 8 } OperationRegion (\APA4, SystemIO, ACA4, 0x04) Field (APA4, ByteAcc, NoLock, Preserve) { Offset (0x02), LCTM, 1, LCNM, 1 } Name (SLPS, Zero) Device (SLPB) { Name (_HID, EisaId ("PNP0C0E")) Method (_STA, 0, NotSerialized) { If (EXTS) { Return (0x0F) } Return (Zero) } Method (SBEV, 0, NotSerialized) { If (SLPS) { Notify (SLPB, 0x02) } Else { Notify (SLPB, 0x80) } } Method (\_GPE._L01, 0, NotSerialized) { \_SB.SLPB.SBEV () } Method (_PRW, 0, NotSerialized) { Return (Package (0x02) { One, 0x04 }) } } Scope (PCI0) { Method (_S3D, 0, NotSerialized) { If (LEqual (OSFL (), 0x02)) { Return (0x02) } Else { Return (0x03) } } Name (_S1D, One) Name (NATA, Package (0x01) { 0x00050000 }) Device (NVRB) { Name (_HID, "NVRAID20") Name (FNVR, 0xFF) Method (_DIS, 0, NotSerialized) { Store (Zero, FNVR) } Method (_SRS, 1, NotSerialized) { Store (0xFF, FNVR) } Method (_STA, 0, NotSerialized) { If (And (CPB0, One)) { If (LEqual (FNVR, 0xFF)) { Return (0x0F) } Else { Return (0x0D) } } Else { Return (Zero) } } Name (_CRS, ResourceTemplate () { IO (Decode16, 0x04D2, // Range Minimum 0x04D2, // Range Maximum 0x01, // Alignment 0x01, // Length ) }) } } } OperationRegion (UCFG, PCI_Config, 0x78, One) Field (UCFG, ByteAcc, NoLock, Preserve) { U1CF, 8 } Device (MUAR) { Name (_UID, 0xFF) Name (_HID, EisaId ("PNP0501")) Method (_STA, 0, NotSerialized) { If (MUAE) { And (U1CF, 0x83, Local0) If (LEqual (Local0, 0x82)) { Return (0x0F) } } Return (Zero) } Method (_CRS, 0, NotSerialized) { If (LEqual (U1CF, 0xC2)) { Store (0x03F8, UIO1) ShiftLeft (One, 0x04, UIRQ) Store (One, _UID) } If (LEqual (U1CF, 0xA6)) { Store (0x02F8, UIO1) ShiftLeft (One, 0x03, UIRQ) Store (0x02, _UID) } Store (UIO1, UIO2) Return (UCRS) } Name (UCRS, ResourceTemplate () { IO (Decode16, 0x0000, // Range Minimum 0x0000, // Range Maximum 0x01, // Alignment 0x08, // Length _Y01) IRQNoFlags (_Y00) {} DMA (Compatibility, NotBusMaster, Transfer8, ) {} }) CreateWordField (UCRS, \_SB.PCI0.SBRG.MUAR._Y00._INT, UIRQ) CreateWordField (UCRS, \_SB.PCI0.SBRG.MUAR._Y01._MIN, UIO1) CreateWordField (UCRS, \_SB.PCI0.SBRG.MUAR._Y01._MAX, UIO2) } OperationRegion (PIMC, PCI_Config, 0x7C, 0x0C) Field (PIMC, ByteAcc, NoLock, Preserve) { PIRA, 4, PIRB, 4, PIRC, 4, PIRD, 4, PREA, 4, PREB, 4, PREC, 4, PRED, 4, , 4, Offset (0x05), PIRM, 4, PIU2, 4, , 4, PMUD, 4, SIID, 4, PIID, 4, PIU0, 4, PILM, 4, PILN, 4, PAZA, 4, , 4, Offset (0x0B), PR0E, 4, SIR2, 4 } Device (PIC) { Name (_HID, EisaId ("PNP0000")) Name (_CRS, ResourceTemplate () { IO (Decode16, 0x0020, // Range Minimum 0x0020, // Range Maximum 0x00, // Alignment 0x02, // Length ) IO (Decode16, 0x00A0, // Range Minimum 0x00A0, // Range Maximum 0x00, // Alignment 0x02, // Length ) IRQNoFlags () {2} }) } Device (DMAD) { Name (_HID, EisaId ("PNP0200")) Name (_CRS, ResourceTemplate () { DMA (Compatibility, BusMaster, Transfer8, ) {4} IO (Decode16, 0x0000, // Range Minimum 0x0000, // Range Maximum 0x00, // Alignment 0x10, // Length ) IO (Decode16, 0x0081, // Range Minimum 0x0081, // Range Maximum 0x00, // Alignment 0x03, // Length ) IO (Decode16, 0x0087, // Range Minimum 0x0087, // Range Maximum 0x00, // Alignment 0x01, // Length ) IO (Decode16, 0x0089, // Range Minimum 0x0089, // Range Maximum 0x00, // Alignment 0x03, // Length ) IO (Decode16, 0x008F, // Range Minimum 0x008F, // Range Maximum 0x00, // Alignment 0x01, // Length ) IO (Decode16, 0x00C0, // Range Minimum 0x00C0, // Range Maximum 0x00, // Alignment 0x20, // Length ) }) } Device (SPKR) { Name (_HID, EisaId ("PNP0800")) Name (_CRS, ResourceTemplate () { IO (Decode16, 0x0061, // Range Minimum 0x0061, // Range Maximum 0x00, // Alignment 0x01, // Length ) }) } Device (COPR) { Name (_HID, EisaId ("PNP0C04")) Name (_CRS, ResourceTemplate () { IO (Decode16, 0x00F0, // Range Minimum 0x00F0, // Range Maximum 0x00, // Alignment 0x10, // Length ) IRQNoFlags () {13} }) } Device (FDC) { Name (_HID, EisaId ("PNP0700")) Method (_FDE, 0, NotSerialized) { Name (FDEP, Package (0x05) { Zero, Zero, 0x02, 0x02, 0x02 }) If (_STA ()) { Store (One, Index (FDEP, Zero)) } Return (FDEP) } Method (_STA, 0, NotSerialized) { Return (DSTA (0x03)) } Method (_DIS, 0, NotSerialized) { DCNT (0x03, Zero) } Method (_CRS, 0, NotSerialized) { DCRS (0x03, One) Store (IRQM, IRQE) Store (DMAM, DMAE) Store (IO11, IO21) Store (IO12, IO22) Store (0x06, LEN2) Add (IO21, 0x07, IO31) Store (IO31, IO32) Store (One, LEN3) Return (CRS2) } Method (_SRS, 1, NotSerialized) { DSRS (Arg0, 0x03) CreateWordField (Arg0, 0x11, IRQE) CreateByteField (Arg0, 0x14, DMAE) ENFG (CGLD (0x03)) If (IRQE) { FindSetRightBit (IRQE, Local0) Subtract (Local0, One, INTR) } Else { Store (Zero, INTR) } If (DMAE) { FindSetRightBit (DMAE, Local0) Subtract (Local0, One, DMCH) } Else { Store (0x04, DMCH) } EXFG () } Name (_PRS, ResourceTemplate () { StartDependentFn (0x00, 0x00) { IO (Decode16, 0x03F0, // Range Minimum 0x03F0, // Range Maximum 0x01, // Alignment 0x06, // Length ) IO (Decode16, 0x03F7, // Range Minimum 0x03F7, // Range Maximum 0x01, // Alignment 0x01, // Length ) IRQNoFlags () {6} DMA (Compatibility, NotBusMaster, Transfer8, ) {2} } StartDependentFnNoPri () { IO (Decode16, 0x03F0, // Range Minimum 0x03F0, // Range Maximum 0x01, // Alignment 0x06, // Length ) IO (Decode16, 0x03F7, // Range Minimum 0x03F7, // Range Maximum 0x01, // Alignment 0x01, // Length ) IRQNoFlags () {3,4,5,6,7,10,11,12} DMA (Compatibility, NotBusMaster, Transfer8, ) {0,1,2,3} } StartDependentFnNoPri () { IO (Decode16, 0x0370, // Range Minimum 0x0370, // Range Maximum 0x01, // Alignment 0x06, // Length ) IO (Decode16, 0x0377, // Range Minimum 0x0377, // Range Maximum 0x01, // Alignment 0x01, // Length ) IRQNoFlags () {3,4,5,6,7,10,11,12} DMA (Compatibility, NotBusMaster, Transfer8, ) {0,1,2,3} } EndDependentFn () }) } Device (SIOR) { Name (_HID, EisaId ("PNP0C02")) Method (_UID, 0, NotSerialized) { Return (SPIO) } Name (CRS, ResourceTemplate () { IO (Decode16, 0x0000, // Range Minimum 0x0000, // Range Maximum 0x00, // Alignment 0x00, // Length _Y02) IO (Decode16, 0x0000, // Range Minimum 0x0000, // Range Maximum 0x00, // Alignment 0x00, // Length _Y03) IO (Decode16, 0x0000, // Range Minimum 0x0000, // Range Maximum 0x00, // Alignment 0x00, // Length _Y04) IO (Decode16, 0x0000, // Range Minimum 0x0000, // Range Maximum 0x00, // Alignment 0x00, // Length _Y05) IO (Decode16, 0x0000, // Range Minimum 0x0000, // Range Maximum 0x00, // Alignment 0x00, // Length _Y06) }) Method (_CRS, 0, NotSerialized) { If (LAnd (LNotEqual (SPIO, 0x03F0), LGreater (SPIO, 0xF0))) { CreateWordField (CRS, \_SB.PCI0.SBRG.SIOR._Y02._MIN, GP10) CreateWordField (CRS, \_SB.PCI0.SBRG.SIOR._Y02._MAX, GP11) CreateByteField (CRS, \_SB.PCI0.SBRG.SIOR._Y02._LEN, GPL1) Store (SPIO, GP10) Store (SPIO, GP11) Store (0x02, GPL1) } If (IOPB) { CreateWordField (CRS, \_SB.PCI0.SBRG.SIOR._Y03._MIN, GP20) CreateWordField (CRS, \_SB.PCI0.SBRG.SIOR._Y03._MAX, GP21) CreateByteField (CRS, \_SB.PCI0.SBRG.SIOR._Y03._LEN, GPL2) Store (IOPB, GP20) Store (IOPB, GP21) Store (IOPL, GPL2) } If (IOEB) { CreateWordField (CRS, \_SB.PCI0.SBRG.SIOR._Y04._MIN, GP30) CreateWordField (CRS, \_SB.PCI0.SBRG.SIOR._Y04._MAX, GP31) CreateByteField (CRS, \_SB.PCI0.SBRG.SIOR._Y04._LEN, GPL3) Store (IOEB, GP30) Store (IOEB, GP31) Store (IOEL, GPL3) } If (IOGB) { CreateWordField (CRS, \_SB.PCI0.SBRG.SIOR._Y05._MIN, GP40) CreateWordField (CRS, \_SB.PCI0.SBRG.SIOR._Y05._MAX, GP41) CreateByteField (CRS, \_SB.PCI0.SBRG.SIOR._Y05._LEN, GPL4) Store (IOGB, GP40) Store (IOGB, GP41) Store (IOGL, GPL4) } If (IODB) { CreateWordField (CRS, \_SB.PCI0.SBRG.SIOR._Y06._MIN, GP50) CreateWordField (CRS, \_SB.PCI0.SBRG.SIOR._Y06._MAX, GP51) CreateByteField (CRS, \_SB.PCI0.SBRG.SIOR._Y06._LEN, GPL5) Store (IODB, GP50) Store (IODB, GP51) Store (IODL, GPL5) } Return (CRS) } } Name (DCAT, Package (0x16) { One, 0x02, 0x03, Zero, 0xFF, 0x08, 0xFF, 0xFF, 0x09, 0xFF, 0x05, 0x04, 0xFF, 0xFF, 0xFF, 0xFF, 0x0A, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF }) Name (IKEY, Package (0x02) { Package (0x04) { 0x87, One, 0x55, 0x55 }, Package (0x04) { 0x87, One, 0x55, 0xAA } }) Name (KBFG, One) Name (MSFG, One) Name (UR1F, One) Method (ENFG, 1, NotSerialized) { Store (Zero, Local1) If (LEqual (SPIO, 0x2E)) { Store (Zero, Local1) } If (LEqual (SPIO, 0x4E)) { Store (One, Local1) } Store (Zero, Local0) While (LNotEqual (Local0, 0x04)) { Store (DerefOf (Index (DerefOf (Index (IKEY, Local1)), Local0)), INDX) Increment (Local0) } Store (Arg0, LDN) } Method (ENTR, 0, NotSerialized) { Store (0x87, INDX) Store (One, INDX) Store (0x55, INDX) If (LEqual (SPIO, 0x2E)) { Store (0x55, INDX) } Else { Store (0xAA, INDX) } } Method (EXFG, 0, NotSerialized) { Store (0x02, INDX) Store (0x02, DATA) } Method (LPTM, 1, NotSerialized) { ENFG (CGLD (Arg0)) And (OPT0, 0x02, Local0) EXFG () Return (Local0) } Method (UHID, 1, NotSerialized) { ENFG (CGLD (Arg0)) And (OPT0, 0x70, Local0) EXFG () If (Local0) { Return (0x1005D041) } Return (0x0105D041) } Method (ORF0, 1, NotSerialized) { ENTR () Or (OPT0, Arg0, OPT0) EXFG () } Method (ORF1, 1, NotSerialized) { ENTR () Or (OPT1, Arg0, OPT1) EXFG () } Method (ORF2, 1, NotSerialized) { ENTR () Or (OPT2, Arg0, OPT2) EXFG () } Method (ANF0, 1, NotSerialized) { ENTR () And (OPT0, Arg0, OPT0) EXFG () } Method (ANF2, 1, NotSerialized) { ENTR () And (OPT2, Arg0, OPT2) EXFG () } Method (ANF4, 1, NotSerialized) { ENTR () And (OPT4, Arg0, OPT4) EXFG () } Method (STF0, 1, NotSerialized) { ENTR () Store (Arg0, OPT0) EXFG () } Method (STF1, 1, NotSerialized) { ENTR () Store (Arg0, OPT1) EXFG () } Method (SIOS, 1, NotSerialized) { Store ("SIOS", Debug) Store (Zero, GP10) If (LLess (Arg0, 0x05)) { ENFG (0x04) Store (One, ACTR) EXFG () ANF4 (0xFC) ORF1 (0x18) If (KBFG) { ORF0 (0x08) } Else { ANF0 (0xF7) } If (MSFG) { ORF0 (0x10) } Else { ANF0 (0xEF) ENFG (0x06) Store (Zero, ACTR) EXFG () } ENFG (0x04) ANF2 (0xF0) } Else { } } Method (SIOW, 1, NotSerialized) { Store (One, GP10) Store (One, GP40) Store ("SIOW", Debug) ENFG (0x04) Store (Zero, ACTR) EXFG () STF0 (Zero) STF1 (0xFF) ENFG (0x07) Or (OP29, 0x10, OP29) Or (OPC0, One, OPC0) Or (OPC3, One, OPC3) EXFG () ENFG (0x05) Or (ACTR, One, ACTR) EXFG () ENFG (0x06) Or (ACTR, One, ACTR) EXFG () ENFG (0x04) Store (One, ACTR) EXFG () } Method (SIOH, 0, NotSerialized) { Store ("SIOH", Debug) } OperationRegion (IOID, SystemIO, SPIO, 0x02) Field (IOID, ByteAcc, NoLock, Preserve) { INDX, 8, DATA, 8 } IndexField (INDX, DATA, ByteAcc, NoLock, Preserve) { Offset (0x07), LDN, 8, Offset (0x29), OP29, 8, Offset (0x30), ACTR, 8, Offset (0x60), IOAH, 8, IOAL, 8, IOH2, 8, IOL2, 8, Offset (0x70), INTR, 8, Offset (0x74), DMCH, 8, Offset (0xC0), OPC0, 8, OPC1, 8, OPC2, 8, OPC3, 8, Offset (0xF0), OPT0, 8, OPT1, 8, OPT2, 8, OPT3, 8, OPT4, 8, Offset (0xF8), OPF8, 8, OPF9, 8, OPFA, 8, OPFB, 8 } Method (CGLD, 1, NotSerialized) { Return (DerefOf (Index (DCAT, Arg0))) } Method (DSTA, 1, NotSerialized) { ENFG (CGLD (Arg0)) Store (ACTR, Local0) EXFG () If (LEqual (Local0, 0xFF)) { Return (Zero) } And (Local0, One, Local0) Or (IOST, ShiftLeft (Local0, Arg0), IOST) If (Local0) { Return (0x0F) } Else { If (And (ShiftLeft (One, Arg0), IOST)) { Return (0x0D) } Else { Return (Zero) } } } Method (DCNT, 2, NotSerialized) { ENFG (CGLD (Arg0)) ShiftLeft (IOAH, 0x08, Local1) Or (IOAL, Local1, Local1) RRIO (Arg0, Arg1, Local1, 0x08) If (LAnd (LLess (DMCH, 0x04), LNotEqual (And (DMCH, 0x03, Local1), Zero))) { RDMA (Arg0, Arg1, Increment (Local1)) } Store (Arg1, ACTR) EXFG () } Name (CRS1, ResourceTemplate () { IO (Decode16, 0x0000, // Range Minimum 0x0000, // Range Maximum 0x01, // Alignment 0x00, // Length _Y09) IRQNoFlags (_Y07) {} DMA (Compatibility, NotBusMaster, Transfer8, _Y08) {} }) CreateWordField (CRS1, \_SB.PCI0.SBRG._Y07._INT, IRQM) CreateByteField (CRS1, \_SB.PCI0.SBRG._Y08._DMA, DMAM) CreateWordField (CRS1, \_SB.PCI0.SBRG._Y09._MIN, IO11) CreateWordField (CRS1, \_SB.PCI0.SBRG._Y09._MAX, IO12) CreateByteField (CRS1, \_SB.PCI0.SBRG._Y09._LEN, LEN1) Name (CRS2, ResourceTemplate () { IO (Decode16, 0x0000, // Range Minimum 0x0000, // Range Maximum 0x01, // Alignment 0x00, // Length _Y0C) IO (Decode16, 0x0000, // Range Minimum 0x0000, // Range Maximum 0x01, // Alignment 0x00, // Length _Y0D) IRQNoFlags (_Y0A) {6} DMA (Compatibility, NotBusMaster, Transfer8, _Y0B) {2} }) CreateWordField (CRS2, \_SB.PCI0.SBRG._Y0A._INT, IRQE) CreateByteField (CRS2, \_SB.PCI0.SBRG._Y0B._DMA, DMAE) CreateWordField (CRS2, \_SB.PCI0.SBRG._Y0C._MIN, IO21) CreateWordField (CRS2, \_SB.PCI0.SBRG._Y0C._MAX, IO22) CreateByteField (CRS2, \_SB.PCI0.SBRG._Y0C._LEN, LEN2) CreateWordField (CRS2, \_SB.PCI0.SBRG._Y0D._MIN, IO31) CreateWordField (CRS2, \_SB.PCI0.SBRG._Y0D._MAX, IO32) CreateByteField (CRS2, \_SB.PCI0.SBRG._Y0D._LEN, LEN3) Method (DCRS, 2, NotSerialized) { ENFG (CGLD (Arg0)) ShiftLeft (IOAH, 0x08, IO11) Or (IOAL, IO11, IO11) Store (IO11, IO12) Subtract (FindSetRightBit (IO11), One, Local0) ShiftLeft (One, Local0, LEN1) If (INTR) { ShiftLeft (One, INTR, IRQM) } Else { Store (Zero, IRQM) } If (LOr (LGreater (DMCH, 0x03), LEqual (Arg1, Zero))) { Store (Zero, DMAM) } Else { And (DMCH, 0x03, Local1) ShiftLeft (One, Local1, DMAM) } EXFG () Return (CRS1) } Method (DSRS, 2, NotSerialized) { CreateWordField (Arg0, 0x09, IRQM) CreateByteField (Arg0, 0x0C, DMAM) CreateWordField (Arg0, 0x02, IO11) ENFG (CGLD (Arg1)) And (IO11, 0xFF, IOAL) ShiftRight (IO11, 0x08, IOAH) If (IRQM) { FindSetRightBit (IRQM, Local0) Subtract (Local0, One, INTR) } Else { Store (Zero, INTR) } If (DMAM) { FindSetRightBit (DMAM, Local0) Subtract (Local0, One, DMCH) } Else { Store (0x04, DMCH) } EXFG () DCNT (Arg1, One) } OperationRegion (GPIO, SystemIO, IO1B, 0x04) Field (GPIO, ByteAcc, NoLock, Preserve) { GP10, 1, GP11, 1, GP12, 1, GP13, 1, GO14, 1, GO15, 1, GO16, 1, GO17, 1, GP20, 1, GP21, 1, GP22, 1, GP23, 1, GO24, 1, GO25, 1, GO26, 1, GO27, 1, GP30, 1, GP31, 1, GP32, 1, GP33, 1, GO34, 1, GO35, 1, GO36, 1, GO37, 1, GP40, 1, GP41, 1, GP42, 1, GP43, 1, GO44, 1, GO45, 1, GO46, 1, GO47, 1 } Device (RMSC) { Name (_HID, EisaId ("PNP0C02")) Name (_UID, 0x10) Name (CRS, ResourceTemplate () { DWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, Cacheable, ReadWrite, 0x00000000, // Granularity 0x000D0000, // Range Minimum 0x000D3FFF, // Range Maximum 0x00000000, // Translation Offset 0x00004000, // Length ,, , AddressRangeMemory, TypeStatic) DWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, Cacheable, ReadWrite, 0x00000000, // Granularity 0x000D4000, // Range Minimum 0x000D7FFF, // Range Maximum 0x00000000, // Translation Offset 0x00004000, // Length ,, , AddressRangeMemory, TypeStatic) DWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, Cacheable, ReadWrite, 0x00000000, // Granularity 0x000DE000, // Range Minimum 0x000DFFFF, // Range Maximum 0x00000000, // Translation Offset 0x00002000, // Length ,, , AddressRangeMemory, TypeStatic) IO (Decode16, 0x0010, // Range Minimum 0x0010, // Range Maximum 0x00, // Alignment 0x10, // Length ) IO (Decode16, 0x0022, // Range Minimum 0x0022, // Range Maximum 0x00, // Alignment 0x1E, // Length ) IO (Decode16, 0x0044, // Range Minimum 0x0044, // Range Maximum 0x00, // Alignment 0x1C, // Length ) IO (Decode16, 0x0062, // Range Minimum 0x0062, // Range Maximum 0x00, // Alignment 0x02, // Length ) IO (Decode16, 0x0065, // Range Minimum 0x0065, // Range Maximum 0x00, // Alignment 0x0B, // Length ) IO (Decode16, 0x0072, // Range Minimum 0x0072, // Range Maximum 0x00, // Alignment 0x0E, // Length ) IO (Decode16, 0x0080, // Range Minimum 0x0080, // Range Maximum 0x00, // Alignment 0x01, // Length ) IO (Decode16, 0x0084, // Range Minimum 0x0084, // Range Maximum 0x00, // Alignment 0x03, // Length ) IO (Decode16, 0x0088, // Range Minimum 0x0088, // Range Maximum 0x00, // Alignment 0x01, // Length ) IO (Decode16, 0x008C, // Range Minimum 0x008C, // Range Maximum 0x00, // Alignment 0x03, // Length ) IO (Decode16, 0x0090, // Range Minimum 0x0090, // Range Maximum 0x00, // Alignment 0x10, // Length ) IO (Decode16, 0x00A2, // Range Minimum 0x00A2, // Range Maximum 0x00, // Alignment 0x1E, // Length ) IO (Decode16, 0x00E0, // Range Minimum 0x00E0, // Range Maximum 0x00, // Alignment 0x10, // Length ) IO (Decode16, 0x04D0, // Range Minimum 0x04D0, // Range Maximum 0x00, // Alignment 0x02, // Length ) IO (Decode16, 0x0800, // Range Minimum 0x0800, // Range Maximum 0x00, // Alignment 0x10, // Length ) IO (Decode16, 0x0000, // Range Minimum 0x0000, // Range Maximum 0x00, // Alignment 0x00, // Length _Y0E) IO (Decode16, 0x0000, // Range Minimum 0x0000, // Range Maximum 0x00, // Alignment 0x00, // Length _Y0F) IO (Decode16, 0x0000, // Range Minimum 0x0000, // Range Maximum 0x00, // Alignment 0x00, // Length _Y10) IO (Decode16, 0x0000, // Range Minimum 0x0000, // Range Maximum 0x00, // Alignment 0x00, // Length _Y11) IO (Decode16, 0x0000, // Range Minimum 0x0000, // Range Maximum 0x00, // Alignment 0x00, // Length _Y12) IO (Decode16, 0x0000, // Range Minimum 0x0000, // Range Maximum 0x00, // Alignment 0x00, // Length _Y13) IO (Decode16, 0x0000, // Range Minimum 0x0000, // Range Maximum 0x00, // Alignment 0x00, // Length _Y14) IO (Decode16, 0x0000, // Range Minimum 0x0000, // Range Maximum 0x00, // Alignment 0x00, // Length _Y15) Memory32Fixed (ReadOnly, 0x00000000, // Address Base 0x00000000, // Address Length _Y16) Memory32Fixed (ReadOnly, 0xFEE01000, // Address Base 0x000FF000, // Address Length ) }) Method (_CRS, 0, NotSerialized) { CreateWordField (CRS, \_SB.PCI0.SBRG.RMSC._Y0E._MIN, GP00) CreateWordField (CRS, \_SB.PCI0.SBRG.RMSC._Y0E._MAX, GP01) CreateByteField (CRS, \_SB.PCI0.SBRG.RMSC._Y0E._LEN, GP0L) CreateWordField (CRS, \_SB.PCI0.SBRG.RMSC._Y0F._MIN, GP10) CreateWordField (CRS, \_SB.PCI0.SBRG.RMSC._Y0F._MAX, GP11) CreateByteField (CRS, \_SB.PCI0.SBRG.RMSC._Y0F._LEN, GP1L) Store (PMBS, GP00) Store (PMBS, GP01) If (LGreaterEqual (PMLN, 0x0100)) { ShiftRight (PMLN, One, GP0L) Add (GP00, GP0L, GP10) Add (GP01, GP0L, GP11) Subtract (PMLN, GP0L, GP1L) } Else { Store (PMLN, GP0L) } If (SCBS) { CreateWordField (CRS, \_SB.PCI0.SBRG.RMSC._Y10._MIN, SC00) CreateWordField (CRS, \_SB.PCI0.SBRG.RMSC._Y10._MAX, SC01) CreateByteField (CRS, \_SB.PCI0.SBRG.RMSC._Y10._LEN, SC0L) CreateWordField (CRS, \_SB.PCI0.SBRG.RMSC._Y11._MIN, SC10) CreateWordField (CRS, \_SB.PCI0.SBRG.RMSC._Y11._MAX, SC11) CreateByteField (CRS, \_SB.PCI0.SBRG.RMSC._Y11._LEN, SC1L) Store (SCBS, SC00) Store (SCBS, SC01) If (LGreaterEqual (SCLN, 0x0100)) { ShiftRight (SCLN, One, SC0L) Add (SC00, SC0L, SC10) Add (SC01, SC0L, SC11) Subtract (SCLN, SC0L, SC1L) } Else { Store (SCLN, SC0L) } } If (ACBS) { CreateWordField (CRS, \_SB.PCI0.SBRG.RMSC._Y12._MIN, AC00) CreateWordField (CRS, \_SB.PCI0.SBRG.RMSC._Y12._MAX, AC01) CreateByteField (CRS, \_SB.PCI0.SBRG.RMSC._Y12._LEN, AC0L) CreateWordField (CRS, \_SB.PCI0.SBRG.RMSC._Y13._MIN, AC10) CreateWordField (CRS, \_SB.PCI0.SBRG.RMSC._Y13._MAX, AC11) CreateByteField (CRS, \_SB.PCI0.SBRG.RMSC._Y13._LEN, AC1L) Store (ACBS, AC00) Store (ACBS, AC01) If (LGreaterEqual (ACLN, 0x0100)) { ShiftRight (ACLN, One, AC0L) Add (AC00, AC0L, AC10) Add (AC01, AC0L, AC11) Subtract (ACLN, AC0L, AC1L) } Else { Store (ACLN, AC0L) } } If (IGPB) { CreateWordField (CRS, \_SB.PCI0.SBRG.RMSC._Y14._MIN, IC00) CreateWordField (CRS, \_SB.PCI0.SBRG.RMSC._Y14._MAX, IC01) CreateByteField (CRS, \_SB.PCI0.SBRG.RMSC._Y14._LEN, IC0L) CreateWordField (CRS, \_SB.PCI0.SBRG.RMSC._Y15._MIN, IC10) CreateWordField (CRS, \_SB.PCI0.SBRG.RMSC._Y15._MAX, IC11) CreateByteField (CRS, \_SB.PCI0.SBRG.RMSC._Y15._LEN, IC1L) Store (IGPB, IC00) Store (IGPB, IC01) If (LGreaterEqual (IGLN, 0x0100)) { ShiftRight (IGLN, One, IC0L) Add (IC00, IC0L, IC10) Add (IC01, IC0L, IC11) Subtract (IGLN, IC0L, IC1L) } Else { Store (IGLN, IC0L) } } CreateDWordField (CRS, \_SB.PCI0.SBRG.RMSC._Y16._BAS, MB01) CreateDWordField (CRS, \_SB.PCI0.SBRG.RMSC._Y16._LEN, ML01) Store (CPB1, MB01) Store (CPB2, ML01) Return (CRS) } } Scope (\) { OperationRegion (RAMW, SystemMemory, 0xBFFF0000, 0x00010000) Field (RAMW, ByteAcc, NoLock, Preserve) { PAR0, 32, PAR1, 32, PAR2, 32 } OperationRegion (IOB2, SystemIO, 0x242E, 0x02) Field (IOB2, ByteAcc, NoLock, Preserve) { SMIC, 8, SMIS, 8 } Method (ISMI, 1, Serialized) { Store (Arg0, SMIC) } Method (GNVS, 1, Serialized) { Store (Arg0, PAR0) ISMI (0x70) Return (PAR1) } Method (SNVS, 2, Serialized) { Store (Arg0, PAR0) Store (Arg1, PAR1) ISMI (0x71) } Method (GMAX, 1, Serialized) { Store (Arg0, PAR0) ISMI (0x74) Return (PAR1) } Method (GMDX, 1, Serialized) { Store (Arg0, PAR0) ISMI (0x75) Return (PAR1) } Method (GCAX, 1, Serialized) { Store (Arg0, PAR0) ISMI (0x76) Return (PAR1) } Method (GCDX, 1, Serialized) { Store (Arg0, PAR0) ISMI (0x77) Return (PAR1) } } Scope (\_SB.PCI0.SBRG) { Device (ASOC) { Name (_HID, "ATK0110") Name (_UID, 0x01010110) Method (_STA, 0, NotSerialized) { Return (0x0F) } Method (_INI, 0, NotSerialized) { If (LGreater (And (GCAX (One), 0x0FF0, Local0), 0x06F0)) { Store (GMAX (0x2C), Local0) And (ShiftRight (Local0, 0x08), 0xFF, Local2) And (Local0, 0xFF, Local1) Subtract (Local1, Local2, Local0) Store (GMDX (0x0198), Local7) And (ShiftRight (Local7, 0x08), 0xFF, Local7) If (LLess (Local7, Local0)) { Store (Local1, Local7) } } Else { Store (GMAX (0x17), Local0) And (ShiftRight (Local0, 0x08), 0x1F, Local1) Store (Local1, Local7) Store (GMAX (0x0198), Local0) And (ShiftRight (Local0, 0x18), 0x1F, Local0) } Multiply (Local0, 0x0A, Local2) Or (Local2, 0xFF000000, Index (G3T2, 0x04)) If (And (GMAX (0x0198), 0x80000000)) { Store (0x1F, Local1) } If (And (GMAX (0x17), 0x00800000)) { And (GMAX (0x17), 0x4000, Local2) Store (0x05, Index (G3T2, 0x05)) Store (ShiftRight (And (GMAX (0x17), 0x4000), 0x0E), Local5) Store (Subtract (Local7, Local0), Local4) Multiply (Local4, 0x02, Local6) Add (Local6, Local5, Index (G3T2, 0x03)) Multiply (Subtract (Local1, Local0, Local3), 0x02, Local3) Add (Local3, One, Local3) If (Local2) { Add (Local3, One, Local3) } Store (Local3, Index (G3T2, 0x06)) } Else { Store (0x0A, Index (G3T2, 0x05)) Store (Subtract (Local7, Local0), Index (G3T2, 0x03)) Add (Subtract (Local1, Local0, Local3), One, Index (G3T2, 0x06)) } } Name (MBIF, Package (0x08) { 0x03, "P5N64-WS", 0x01000101, 0x01000100, 0xE0000000, Zero, Zero, Zero }) Name (ASBF, Buffer (0x08) { /* 0000 */ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 }) CreateDWordField (ASBF, Zero, ASB0) CreateDWordField (ASBF, 0x04, ASB1) Method (GGRP, 1, Serialized) { Name (_T_0, Zero) Store (Arg0, _T_0) If (LEqual (_T_0, Zero)) { Return (GRP0) } Else { If (LEqual (_T_0, 0x03)) { Return (GRP3) } Else { If (LEqual (_T_0, 0x04)) { Return (GRP4) } Else { If (LEqual (_T_0, 0x06)) { Return (GRP6) } Else { If (LEqual (_T_0, 0x09)) { Return (GRP9) } Else { If (LEqual (_T_0, 0x0B)) { Return (GRPB) } Else { If (LEqual (_T_0, 0x0E)) { Return (GRPE) } Else { Return (Zero) } } } } } } } } Method (GITM, 1, Serialized) { CreateDWordField (Arg0, Zero, PRM0) CreateByteField (Arg0, 0x03, GPID) Store (One, ASB0) Name (_T_0, Zero) Store (GPID, _T_0) If (LEqual (_T_0, Zero)) { GIT0 (PRM0) } Else { If (LEqual (_T_0, 0x03)) { GIT3 (PRM0) } Else { If (LEqual (_T_0, 0x04)) { GIT4 (PRM0) } Else { If (LEqual (_T_0, 0x06)) { GIT6 (PRM0) } Else { If (LEqual (_T_0, 0x09)) { GIT9 (PRM0) } Else { If (LEqual (_T_0, 0x0B)) { GITB (PRM0) } Else { If (LEqual (_T_0, 0x0E)) { GITE (PRM0) } Else { Store (Zero, ASB0) } } } } } } } Return (ASBF) } Method (SITM, 1, Serialized) { CreateDWordField (Arg0, Zero, PRM0) CreateDWordField (Arg0, 0x04, PRM1) CreateDWordField (Arg0, 0x08, PRM2) CreateByteField (Arg0, 0x03, GPID) Store (One, ASB0) Name (_T_0, Zero) Store (GPID, _T_0) If (LEqual (_T_0, Zero)) { SIT0 (PRM0, PRM1, PRM2) } Else { If (LEqual (_T_0, 0x03)) { SIT3 (PRM0, PRM1, PRM2) } Else { If (LEqual (_T_0, 0x04)) { SIT4 (PRM0, PRM1, PRM2) } Else { If (LEqual (_T_0, 0x06)) { SIT6 (PRM0, PRM1, PRM2) } Else { If (LEqual (_T_0, 0x09)) { SIT9 (PRM0, PRM1, PRM2) } Else { If (LEqual (_T_0, 0x0B)) { SITB (PRM0, PRM1, PRM2) } Else { If (LEqual (_T_0, 0x0E)) { SITE (PRM0, PRM1, PRM2) } Else { Store (Zero, ASB0) } } } } } } } Return (ASBF) } Method (OP2V, 2, NotSerialized) { Store (DerefOf (Index (Arg1, 0x04)), Local0) Store (DerefOf (Index (Arg1, 0x05)), Local1) Multiply (Arg0, Local1, Local1) Add (Local0, Local1, Local0) Return (Local0) } Method (V2OP, 2, NotSerialized) { Store (DerefOf (Index (Arg1, 0x04)), Local0) Store (DerefOf (Index (Arg1, 0x05)), Local1) Subtract (Arg0, Local0, Local0) Divide (Local0, Local1, Local1, Local0) Return (Local0) } } } Device (HPET) { Name (_HID, EisaId ("PNP0103")) Name (_UID, Zero) Name (CRS0, ResourceTemplate () { }) Name (CRS1, ResourceTemplate () { Memory32Fixed (ReadWrite, 0x00000000, // Address Base 0x00000000, // Address Length _Y17) IRQNoFlags () {0} IRQNoFlags () {8} }) Method (_STA, 0, NotSerialized) { If (LEqual (OSFL (), Zero)) { If (LEqual (NVID, 0x10DE)) { Return (0x0F) } Else { Return (Zero) } } Else { Return (Zero) } } Method (_CRS, 0, NotSerialized) { CreateDWordField (CRS1, \_SB.PCI0.SBRG.HPET._Y17._BAS, HPX1) CreateDWordField (CRS1, \_SB.PCI0.SBRG.HPET._Y17._LEN, HPX2) If (LEqual (NVID, 0x10DE)) { Store (SHPB, HPX1) Store (SHPL, HPX2) Return (CRS1) } Else { Return (CRS0) } } OperationRegion (HPTE, SystemMemory, SHPB, 0x04) Field (HPTE, ByteAcc, NoLock, Preserve) { Offset (0x02), NVID, 16 } } OperationRegion (LPDC, PCI_Config, 0xA0, 0x06) Field (LPDC, ByteAcc, NoLock, Preserve) { S3F8, 1, S2F8, 1, , 3, S2E8, 1, , 1, S3E8, 1, , 4, M300, 1, , 2, M330, 1, , 4, FDC0, 1, Offset (0x03), P378, 1, P278, 1, P3BC, 1, Offset (0x04), G200, 8, G208, 8 } Method (RRIO, 4, NotSerialized) { If (LOr (LEqual (Arg0, Zero), LEqual (Arg0, One))) { If (LEqual (Arg2, 0x03F8)) { Store (Arg1, S3F8) } If (LEqual (Arg2, 0x02F8)) { Store (Arg1, S2F8) } If (LEqual (Arg2, 0x03E8)) { Store (Arg1, S3E8) } If (LEqual (Arg2, 0x02E8)) { Store (Arg1, S2E8) } } If (LEqual (Arg0, 0x02)) { If (LEqual (Arg2, 0x0378)) { Store (Arg1, P378) } If (LEqual (Arg2, 0x0278)) { Store (Arg1, P278) } If (LEqual (Arg2, 0x03BC)) { Store (Arg1, P3BC) } } If (LEqual (Arg0, 0x03)) { Store (Arg1, FDC0) } If (LEqual (Arg0, 0x05)) { If (LEqual (Arg2, 0x0330)) { Store (Arg1, M330) } If (LEqual (Arg2, 0x0300)) { Store (Arg1, M300) } } If (LEqual (Arg0, 0x08)) { Store (Zero, Local0) If (Arg1) { Store (0xFF, Local0) } If (LEqual (Arg2, 0x0200)) { Store (Local0, G200) } If (LEqual (Arg2, 0x0208)) { Store (Local0, G208) } } } Method (RDMA, 3, NotSerialized) { } Device (TMR) { Name (_HID, EisaId ("PNP0100")) Name (CRS0, ResourceTemplate () { IO (Decode16, 0x0040, // Range Minimum 0x0040, // Range Maximum 0x00, // Alignment 0x04, // Length ) IRQNoFlags () {0} }) Name (CRS1, ResourceTemplate () { IO (Decode16, 0x0040, // Range Minimum 0x0040, // Range Maximum 0x00, // Alignment 0x04, // Length ) }) Method (_CRS, 0, NotSerialized) { If (LEqual (^^HPET.NVID, 0x10DE)) { Return (CRS1) } Return (CRS0) } } Device (RTC0) { Name (_HID, EisaId ("PNP0B00")) Name (CRS0, ResourceTemplate () { IO (Decode16, 0x0070, // Range Minimum 0x0070, // Range Maximum 0x00, // Alignment 0x02, // Length ) IRQNoFlags () {8} }) Name (CRS1, ResourceTemplate () { IO (Decode16, 0x0070, // Range Minimum 0x0070, // Range Maximum 0x00, // Alignment 0x02, // Length ) }) Method (_CRS, 0, NotSerialized) { If (LEqual (^^HPET.NVID, 0x10DE)) { Return (CRS1) } Return (CRS0) } } Device (^PCIE) { Name (_HID, EisaId ("PNP0C02")) Name (_UID, 0x11) Name (CRS, ResourceTemplate () { Memory32Fixed (ReadOnly, 0xE0000000, // Address Base 0x10000000, // Address Length _Y18) }) Method (_CRS, 0, NotSerialized) { CreateDWordField (CRS, \_SB.PCI0.PCIE._Y18._BAS, BAS1) CreateDWordField (CRS, \_SB.PCI0.PCIE._Y18._LEN, LEN1) Store (PCIB, BAS1) Store (PCIL, LEN1) Return (CRS) } } Scope (\_GPE) { Method (_L31, 0, NotSerialized) { Notify (\_SB.PCI0.SBRG.ASOC, One) Sleep (0x03E8) } } Scope (ASOC) { Name (VESL, Zero) Method (SPLV, 1, Serialized) { And (Arg0, 0xFFFF, VESL) Store (VESL, PAR0) ISMI (0x88) Store (And (PAR0, 0xFFFF), Local0) Return (Local0) } Method (GPLV, 0, Serialized) { Return (VESL) } } Device (PS2K) { Name (_HID, EisaId ("PNP0303")) Name (_CID, 0x0B03D041) Method (_STA, 0, NotSerialized) { ShiftLeft (One, 0x0A, Local0) If (And (IOST, Local0)) { Return (0x0F) } Return (Zero) } Name (_CRS, ResourceTemplate () { IO (Decode16, 0x0060, // Range Minimum 0x0060, // Range Maximum 0x00, // Alignment 0x01, // Length ) IO (Decode16, 0x0064, // Range Minimum 0x0064, // Range Maximum 0x00, // Alignment 0x01, // Length ) IRQNoFlags () {1} }) } Method (PS2K._PRW, 0, NotSerialized) { Return (GPRW (0x10, 0x04)) } Device (UAR1) { Name (_UID, One) Method (_HID, 0, NotSerialized) { Return (UHID (Zero)) } Method (_STA, 0, NotSerialized) { Return (DSTA (Zero)) } Method (_DIS, 0, NotSerialized) { DCNT (Zero, Zero) } Method (_CRS, 0, NotSerialized) { Return (DCRS (Zero, One)) } Method (_SRS, 1, NotSerialized) { DSRS (Arg0, Zero) } Method (_PRS, 0, NotSerialized) { Return (CMPR) } Name (CMPR, ResourceTemplate () { StartDependentFn (0x00, 0x00) { IO (Decode16, 0x03F8, // Range Minimum 0x03F8, // Range Maximum 0x01, // Alignment 0x08, // Length ) IRQNoFlags () {4} DMA (Compatibility, NotBusMaster, Transfer8, ) {} } StartDependentFnNoPri () { IO (Decode16, 0x03F8, // Range Minimum 0x03F8, // Range Maximum 0x01, // Alignment 0x08, // Length ) IRQNoFlags () {3,4,5,6,7,10,11,12} DMA (Compatibility, NotBusMaster, Transfer8, ) {} } StartDependentFnNoPri () { IO (Decode16, 0x02F8, // Range Minimum 0x02F8, // Range Maximum 0x01, // Alignment 0x08, // Length ) IRQNoFlags () {3,4,5,6,7,10,11,12} DMA (Compatibility, NotBusMaster, Transfer8, ) {} } StartDependentFnNoPri () { IO (Decode16, 0x03E8, // Range Minimum 0x03E8, // Range Maximum 0x01, // Alignment 0x08, // Length ) IRQNoFlags () {3,4,5,6,7,10,11,12} DMA (Compatibility, NotBusMaster, Transfer8, ) {} } StartDependentFnNoPri () { IO (Decode16, 0x02E8, // Range Minimum 0x02E8, // Range Maximum 0x01, // Alignment 0x08, // Length ) IRQNoFlags () {3,4,5,6,7,10,11,12} DMA (Compatibility, NotBusMaster, Transfer8, ) {} } StartDependentFnNoPri () { IO (Decode16, 0x03F8, // Range Minimum 0x03F8, // Range Maximum 0x01, // Alignment 0x08, // Length ) IRQNoFlags () {3,4,5,6,7,10,11,12} DMA (Compatibility, NotBusMaster, Transfer8, ) {0,1,2,3} } StartDependentFnNoPri () { IO (Decode16, 0x02F8, // Range Minimum 0x02F8, // Range Maximum 0x01, // Alignment 0x08, // Length ) IRQNoFlags () {3,4,5,6,7,10,11,12} DMA (Compatibility, NotBusMaster, Transfer8, ) {0,1,2,3} } StartDependentFnNoPri () { IO (Decode16, 0x03E8, // Range Minimum 0x03E8, // Range Maximum 0x01, // Alignment 0x08, // Length ) IRQNoFlags () {3,4,5,6,7,10,11,12} DMA (Compatibility, NotBusMaster, Transfer8, ) {0,1,2,3} } StartDependentFnNoPri () { IO (Decode16, 0x02E8, // Range Minimum 0x02E8, // Range Maximum 0x01, // Alignment 0x08, // Length ) IRQNoFlags () {3,4,5,6,7,10,11,12} DMA (Compatibility, NotBusMaster, Transfer8, ) {0,1,2,3} } EndDependentFn () }) } Method (UAR1._PRW, 0, NotSerialized) { Return (GPRW (0x03, 0x04)) } Device (OMSC) { Name (_HID, EisaId ("PNP0C02")) Name (_UID, Zero) Name (CRS, ResourceTemplate () { Memory32Fixed (ReadOnly, 0x00000000, // Address Base 0x00000000, // Address Length _Y19) Memory32Fixed (ReadOnly, 0x00000000, // Address Base 0x00000000, // Address Length _Y1A) }) Name (CRS1, ResourceTemplate () { FixedIO ( 0x0060, // Address 0x01, // Length ) FixedIO ( 0x0064, // Address 0x01, // Length ) Memory32Fixed (ReadOnly, 0x00000000, // Address Base 0x00000000, // Address Length _Y1B) Memory32Fixed (ReadOnly, 0x00000000, // Address Base 0x00000000, // Address Length _Y1C) }) Method (_CRS, 0, NotSerialized) { If (APIC) { CreateDWordField (CRS, \_SB.PCI0.SBRG.OMSC._Y19._LEN, ML01) CreateDWordField (CRS, \_SB.PCI0.SBRG.OMSC._Y19._BAS, MB01) CreateDWordField (CRS, \_SB.PCI0.SBRG.OMSC._Y1A._LEN, ML02) CreateDWordField (CRS, \_SB.PCI0.SBRG.OMSC._Y1A._BAS, MB02) Store (0xFEC00000, MB01) Store (0x1000, ML01) Store (0xFEE00000, MB02) Store (0x1000, ML02) CreateDWordField (CRS1, \_SB.PCI0.SBRG.OMSC._Y1B._LEN, ML03) CreateDWordField (CRS1, \_SB.PCI0.SBRG.OMSC._Y1B._BAS, MB03) CreateDWordField (CRS1, \_SB.PCI0.SBRG.OMSC._Y1C._LEN, ML04) CreateDWordField (CRS1, \_SB.PCI0.SBRG.OMSC._Y1C._BAS, MB04) Store (0xFEC00000, MB03) Store (0x1000, ML03) Store (0xFEE00000, MB04) Store (0x1000, ML04) } ShiftLeft (0x05, 0x0A, Local0) If (And (IOST, Local0)) { Return (CRS) } Else { Return (CRS1) } } } Device (^^RMEM) { Name (_HID, EisaId ("PNP0C01")) Name (_UID, One) Name (CRS, ResourceTemplate () { Memory32Fixed (ReadWrite, 0x00000000, // Address Base 0x000A0000, // Address Length ) Memory32Fixed (ReadOnly, 0x00000000, // Address Base 0x00000000, // Address Length _Y1D) Memory32Fixed (ReadOnly, 0x000E0000, // Address Base 0x00020000, // Address Length _Y1E) Memory32Fixed (ReadWrite, 0x00100000, // Address Base 0x00000000, // Address Length _Y1F) Memory32Fixed (ReadOnly, 0x00000000, // Address Base 0x00000000, // Address Length _Y20) }) Method (_CRS, 0, NotSerialized) { CreateDWordField (CRS, \_SB.RMEM._Y1D._BAS, BAS1) CreateDWordField (CRS, \_SB.RMEM._Y1D._LEN, LEN1) CreateDWordField (CRS, \_SB.RMEM._Y1E._BAS, BAS2) CreateDWordField (CRS, \_SB.RMEM._Y1E._LEN, LEN2) CreateDWordField (CRS, \_SB.RMEM._Y1F._LEN, LEN3) CreateDWordField (CRS, \_SB.RMEM._Y20._BAS, BAS4) CreateDWordField (CRS, \_SB.RMEM._Y20._LEN, LEN4) If (OSFL ()) {} Else { If (MG1B) { If (LGreater (MG1B, 0x000C0000)) { Store (0x000C0000, BAS1) Subtract (MG1B, BAS1, LEN1) } } Else { Store (0x000C0000, BAS1) Store (0x00020000, LEN1) } If (Add (MG1B, MG1L, Local0)) { Store (Local0, BAS2) Subtract (0x00100000, BAS2, LEN2) } } Subtract (MG2B, 0x00100000, LEN3) Store (MH1B, BAS4) Subtract (Zero, BAS4, LEN4) Return (CRS) } } } Device (NSMB) { Name (_ADR, 0x000A0001) Method (_PRW, 0, NotSerialized) { Return (GPRW (0x09, 0x04)) } } Device (USB2) { Name (_ADR, 0x000B0001) Name (_S1D, One) Method (_S3D, 0, NotSerialized) { If (LOr (LEqual (OSFL (), One), LEqual (OSFL (), 0x02))) { Return (0x02) } Else { Return (0x03) } } Method (_PRW, 0, NotSerialized) { Return (GPRW (0x05, 0x03)) } } Device (NMAC) { Name (_ADR, 0x00110000) Name (_PRW, Package (0x02) { 0x0B, 0x05 }) Scope (\_GPE) { Method (_L0B, 0, NotSerialized) { Notify (\_SB.PCI0.NMAC, 0x02) Notify (\_SB.PWRB, 0x02) } } } Device (NMAD) { Name (_ADR, 0x00120000) Name (_PRW, Package (0x02) { 0x0A, 0x05 }) Scope (\_GPE) { Method (_L0A, 0, NotSerialized) { Notify (\_SB.PCI0.NMAD, 0x02) Notify (\_SB.PWRB, 0x02) } } } Device (IDE0) { Name (_ADR, 0x000D0000) Name (PTS0, Zero) Name (SID0, Zero) Name (SID1, Zero) Name (SID2, Zero) Name (SID3, Zero) Name (SID4, Zero) Name (SID5, Zero) OperationRegion (IRQM, SystemIO, 0x21, One) Field (IRQM, ByteAcc, NoLock, Preserve) { IR0M, 1 } Name (REGF, One) Method (_REG, 2, NotSerialized) { If (LEqual (Arg0, 0x02)) { Store (Arg1, REGF) } } OperationRegion (A090, PCI_Config, 0x50, 0x18) Field (A090, DWordAcc, NoLock, Preserve) { ID20, 16, Offset (0x08), IDTS, 16, IDTP, 16, ID22, 32, UMSS, 16, UMSP, 16 } Name (TIM0, Package (0x07) { Package (0x05) { 0x3C, 0x78, 0xB4, 0xF0, 0x0384 }, Package (0x05) { 0x11, 0x20, 0x22, 0x47, 0xA8 }, Package (0x07) { 0x78, 0x49, 0x3C, 0x2D, 0x1E, 0x14, 0x0F }, Package (0x05) { 0x05, 0x04, 0x03, 0x02, Zero }, Package (0x04) { 0x02, One, Zero, Zero }, Package (0x08) { 0x02, One, Zero, Zero, 0x03, 0x04, 0x05, 0x06 }, Package (0x07) { 0x02, One, Zero, 0x04, 0x05, 0x06, 0x07 } }) Name (TMD0, Buffer (0x14) {}) CreateDWordField (TMD0, Zero, PIO0) CreateDWordField (TMD0, 0x04, DMA0) CreateDWordField (TMD0, 0x08, PIO1) CreateDWordField (TMD0, 0x0C, DMA1) CreateDWordField (TMD0, 0x10, CHNF) OperationRegion (CFG2, PCI_Config, 0x58, 0x0C) Field (CFG2, DWordAcc, NoLock, Preserve) { SSPT, 8, SMPT, 8, PSPT, 8, PMPT, 8, SSAS, 2, SMAS, 2, PSAS, 2, PMAS, 2, Offset (0x06), SDDR, 4, SDDA, 4, PDDR, 4, PDDA, 4, SSUT, 3, , 3, SSUE, 2, SMUT, 3, , 3, SMUE, 2, PSUT, 3, , 3, PSUE, 2, PMUT, 3, , 3, PMUE, 2 } Name (GMPT, Zero) Name (GMUE, Zero) Name (GMUT, Zero) Name (GSPT, Zero) Name (GSUE, Zero) Name (GSUT, Zero) Device (CHN0) { Name (_ADR, Zero) Method (_GTM, 0, NotSerialized) { Store ("GTM_CHN0", Debug) Return (GTM (PMPT, PMUE, PMUT, PSPT, PSUE, PSUT)) } Method (_STM, 3, NotSerialized) { Store ("STM_CHN0", Debug) Store (Arg0, Debug) Store (Arg0, TMD0) Store (PMPT, GMPT) Store (PMUE, GMUE) Store (PMUT, GMUT) Store (PSPT, GSPT) Store (PSUE, GSUE) Store (PSUT, GSUT) STM () Store (GMPT, PMPT) Store (GMUE, PMUE) Store (GMUT, PMUT) Store (GSPT, PSPT) Store (GSUE, PSUE) Store (GSUT, PSUT) Store (GTF (Zero, Arg1), ATA0) Store (GTF (One, Arg2), ATA1) } Device (DRV0) { Name (_ADR, Zero) Method (_GTF, 0, NotSerialized) { Store ("_GTF_CHN0_DRV0", Debug) Return (Concatenate (RATA (ATA0), FZTF)) } } Device (DRV1) { Name (_ADR, One) Method (_GTF, 0, NotSerialized) { Store ("_GTF_CHN0_DRV1", Debug) Return (Concatenate (RATA (ATA1), FZTF)) } } } Device (CHN1) { Name (_ADR, One) Method (_GTM, 0, NotSerialized) { Store ("GTM_CHN1", Debug) Return (GTM (SMPT, SMUE, SMUT, SSPT, SSUE, SSUT)) } Method (_STM, 3, NotSerialized) { Store (Arg0, Debug) Store (Arg0, TMD0) Store (SMPT, GMPT) Store (SMUE, GMUE) Store (SMUT, GMUT) Store (SSPT, GSPT) Store (SSUE, GSUE) Store (SSUT, GSUT) STM () Store (GMPT, SMPT) Store (GMUE, SMUE) Store (GMUT, SMUT) Store (GSPT, SSPT) Store (GSUE, SSUE) Store (GSUT, SSUT) Store (GTF (Zero, Arg1), ATA2) Store (GTF (One, Arg2), ATA3) } Device (DRV0) { Name (_ADR, Zero) Method (_GTF, 0, NotSerialized) { Store ("_GTF_CHN1_DRV0", Debug) Return (Concatenate (RATA (ATA2), FZTF)) } } Device (DRV1) { Name (_ADR, One) Method (_GTF, 0, NotSerialized) { Store ("_GTF_CHN1_DRV1", Debug) Return (Concatenate (RATA (ATA3), FZTF)) } } } Method (DRMP, 0, NotSerialized) { ShiftRight (CPB0, 0x04, Local1) And (Local1, 0x0F, Local0) Return (Local0) } Method (GTM, 6, Serialized) { Store (Ones, PIO0) Store (Ones, PIO1) Store (Ones, DMA0) Store (Ones, DMA1) Store (0x10, CHNF) If (REGF) {} Else { Return (TMD0) } If (LEqual (PTS0, One)) { If (OSFL ()) { Store (One, IR0M) } } Store (Match (DerefOf (Index (TIM0, One)), MEQ, Arg0, MTR, Zero, Zero), Local6) Store (DerefOf (Index (DerefOf (Index (TIM0, Zero)), Local6)), Local7) Store (Local7, DMA0) Store (Local7, PIO0) Store (Match (DerefOf (Index (TIM0, One)), MEQ, Arg3, MTR, Zero, Zero), Local6) Store (DerefOf (Index (DerefOf (Index (TIM0, Zero)), Local6)), Local7) Store (Local7, DMA1) Store (Local7, PIO1) If (Arg1) { Store (DerefOf (Index (DerefOf (Index (TIM0, 0x05)), Arg2)), Local5) Store (DerefOf (Index (DerefOf (Index (TIM0, 0x02)), Local5)), DMA0) Or (CHNF, One, CHNF) } If (Arg4) { Store (DerefOf (Index (DerefOf (Index (TIM0, 0x05)), Arg5)), Local5) Store (DerefOf (Index (DerefOf (Index (TIM0, 0x02)), Local5)), DMA1) Or (CHNF, 0x04, CHNF) } Store (TMD0, Debug) Return (TMD0) } Method (STM, 0, Serialized) { If (REGF) {} Else { Return (Zero) } If (PTS0) { Store (SID0, ID20) Store (SID1, IDTS) Store (SID2, IDTP) Store (SID3, ID22) Store (SID4, UMSS) Store (SID5, UMSP) } Else { Store (ID20, SID0) Store (IDTS, SID1) Store (IDTP, SID2) Store (ID22, SID3) Store (UMSS, SID4) Store (UMSP, SID5) } Store (Zero, PTS0) Store (Zero, GMUE) Store (Zero, GMUT) Store (Zero, GSUE) Store (Zero, GSUT) If (And (CHNF, One)) { Store (Match (DerefOf (Index (TIM0, 0x02)), MLE, DMA0, MTR, Zero, Zero), Local0) If (LGreater (Local0, 0x06)) { Store (0x06, Local0) } Store (DerefOf (Index (DerefOf (Index (TIM0, 0x06)), Local0)), GMUT) Or (GMUE, 0x03, GMUE) } Else { If (Or (LEqual (PIO0, Ones), LEqual (PIO0, Zero))) { If (And (LLess (DMA0, Ones), LGreater (DMA0, Zero))) { Store (DMA0, PIO0) } } } If (And (CHNF, 0x04)) { Store (Match (DerefOf (Index (TIM0, 0x02)), MLE, DMA1, MTR, Zero, Zero), Local0) If (LGreater (Local0, 0x06)) { Store (0x06, Local0) } Store (DerefOf (Index (DerefOf (Index (TIM0, 0x06)), Local0)), GSUT) Or (GSUE, 0x03, GSUE) } Else { If (Or (LEqual (PIO1, Ones), LEqual (PIO1, Zero))) { If (And (LLess (DMA1, Ones), LGreater (DMA1, Zero))) { Store (DMA1, PIO1) } } } And (Match (DerefOf (Index (TIM0, Zero)), MGE, PIO0, MTR, Zero, Zero), 0x07, Local0) Store (DerefOf (Index (DerefOf (Index (TIM0, One)), Local0)), Local1) Store (Local1, GMPT) And (Match (DerefOf (Index (TIM0, Zero)), MGE, PIO1, MTR, Zero, Zero), 0x07, Local0) Store (DerefOf (Index (DerefOf (Index (TIM0, One)), Local0)), Local1) Store (Local1, GSPT) Return (Zero) } Name (AT01, Buffer (0x07) { 0x03, 0x00, 0x00, 0x00, 0x00, 0x00, 0xEF }) Name (AT02, Buffer (0x07) { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x90 }) Name (AT03, Buffer (0x07) { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xC6 }) Name (AT04, Buffer (0x07) { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x91 }) Name (ATA0, Buffer (0x1D) {}) Name (ATA1, Buffer (0x1D) {}) Name (ATA2, Buffer (0x1D) {}) Name (ATA3, Buffer (0x1D) {}) Name (ATAB, Buffer (0x1D) {}) CreateByteField (ATAB, Zero, CMDC) Method (GTFB, 3, Serialized) { Multiply (CMDC, 0x38, Local0) Add (Local0, 0x08, Local1) CreateField (ATAB, Local1, 0x38, CMDX) Multiply (CMDC, 0x07, Local0) CreateByteField (ATAB, Add (Local0, 0x02), A001) CreateByteField (ATAB, Add (Local0, 0x06), A005) Store (Arg0, CMDX) Store (Arg1, A001) Store (Arg2, A005) Increment (CMDC) } Method (GTF, 2, Serialized) { Store ("GTF_Entry", Debug) Store (Arg1, Debug) Store (Zero, CMDC) Name (ID49, 0x0C00) Name (ID59, Zero) Name (ID53, 0x04) Name (ID63, 0x0F00) Name (ID88, 0x0F00) Name (IRDY, One) Name (PIOT, Zero) Name (DMAT, Zero) If (LEqual (SizeOf (Arg1), 0x0200)) { CreateWordField (Arg1, 0x62, IW49) Store (IW49, ID49) CreateWordField (Arg1, 0x6A, IW53) Store (IW53, ID53) CreateWordField (Arg1, 0x7E, IW63) Store (IW63, ID63) CreateWordField (Arg1, 0x76, IW59) Store (IW59, ID59) CreateWordField (Arg1, 0xB0, IW88) Store (IW88, ID88) } Store (0xA0, Local7) If (Arg0) { Store (0xB0, Local7) And (CHNF, 0x08, IRDY) If (And (CHNF, 0x10)) { Store (PIO1, PIOT) } Else { Store (PIO0, PIOT) } If (And (CHNF, 0x04)) { If (And (CHNF, 0x10)) { Store (DMA1, DMAT) } Else { Store (DMA0, DMAT) } } } Else { And (CHNF, 0x02, IRDY) Store (PIO0, PIOT) If (And (CHNF, One)) { Store (DMA0, DMAT) } } If (LAnd (LAnd (And (ID53, 0x04), And (ID88, 0xFF00 )), DMAT)) { Store (Match (DerefOf (Index (TIM0, 0x02)), MLE, DMAT, MTR, Zero, Zero), Local1) If (LGreater (Local1, 0x06)) { Store (0x06, Local1) } GTFB (AT01, Or (0x40, Local1), Local7) } Else { If (LAnd (And (ID63, 0xFF00), PIOT)) { And (Match (DerefOf (Index (TIM0, Zero)), MGE, PIOT, MTR, Zero, Zero), 0x03, Local0) Or (0x20, DerefOf (Index (DerefOf (Index (TIM0, 0x04)), Local0 )), Local1) GTFB (AT01, Local1, Local7) } } If (IRDY) { And (Match (DerefOf (Index (TIM0, Zero)), MGE, PIOT, MTR, Zero, Zero), 0x07, Local0) Or (0x08, DerefOf (Index (DerefOf (Index (TIM0, 0x03)), Local0 )), Local1) GTFB (AT01, Local1, Local7) } Else { If (And (ID49, 0x0400)) { GTFB (AT01, One, Local7) } } If (LAnd (And (ID59, 0x0100), And (ID59, 0xFF))) { GTFB (AT03, And (ID59, 0xFF), Local7) } Store ("ATAB_GTF", Debug) Store (ATAB, Debug) Return (ATAB) } Method (RATA, 1, NotSerialized) { CreateByteField (Arg0, Zero, CMDN) Multiply (CMDN, 0x38, Local0) CreateField (Arg0, 0x08, Local0, RETB) Store (RETB, Debug) Return (RETB) } } Device (ATA0) { Name (_ADR, 0x000E0000) Device (PRI0) { Name (_ADR, Zero) Name (SPTM, Buffer (0x14) { /* 0000 */ 0x78, 0x00, 0x00, 0x00, 0x0F, 0x00, 0x00, 0x00, /* 0008 */ 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, /* 0010 */ 0x13, 0x00, 0x00, 0x00 }) Method (_GTM, 0, NotSerialized) { Return (SPTM) } Method (_STM, 3, NotSerialized) { Store (Arg0, SPTM) } Device (MAST) { Name (_ADR, Zero) Method (_GTF, 0, NotSerialized) { If (SSEN) { Store (SSEP, SMIP) } Store (Buffer (0x07) { 0x03, 0x46, 0x00, 0x00, 0x00, 0xA0, 0xEF }, Local0) Return (Concatenate (Local0, FZTF)) } } } Device (SEC0) { Name (_ADR, One) Name (SSTM, Buffer (0x14) { /* 0000 */ 0x78, 0x00, 0x00, 0x00, 0x0F, 0x00, 0x00, 0x00, /* 0008 */ 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, /* 0010 */ 0x13, 0x00, 0x00, 0x00 }) Method (_GTM, 0, NotSerialized) { Return (SSTM) } Method (_STM, 3, NotSerialized) { Store (Arg0, SSTM) } Device (MAST) { Name (_ADR, Zero) Method (_GTF, 0, NotSerialized) { If (SSEN) { Store (SSEP, SMIP) } Store (Buffer (0x07) { 0x03, 0x46, 0x00, 0x00, 0x00, 0xA0, 0xEF }, Local0) Return (Concatenate (Local0, FZTF)) } } } Method (DRMP, 0, NotSerialized) { Store (0x10, Local0) If (LEqual (And (_ADR, 0x0F), One)) { Store (0x0C, Local0) } If (LEqual (And (_ADR, 0x0F), Zero)) { Store (0x08, Local0) } ShiftRight (CPB0, Local0, Local1) And (Local1, 0x0F, Local0) Return (Local0) } } Device (ATA1) { Name (_ADR, 0x000E0001) Device (PRI0) { Name (_ADR, Zero) Name (SPTM, Buffer (0x14) { /* 0000 */ 0x78, 0x00, 0x00, 0x00, 0x0F, 0x00, 0x00, 0x00, /* 0008 */ 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, /* 0010 */ 0x13, 0x00, 0x00, 0x00 }) Method (_GTM, 0, NotSerialized) { Return (SPTM) } Method (_STM, 3, NotSerialized) { Store (Arg0, SPTM) } Device (MAST) { Name (_ADR, Zero) Method (_GTF, 0, NotSerialized) { If (SSEN) { Store (SSEP, SMIP) } Store (Buffer (0x07) { 0x03, 0x46, 0x00, 0x00, 0x00, 0xA0, 0xEF }, Local0) Return (Concatenate (Local0, FZTF)) } } } Device (SEC0) { Name (_ADR, One) Name (SSTM, Buffer (0x14) { /* 0000 */ 0x78, 0x00, 0x00, 0x00, 0x0F, 0x00, 0x00, 0x00, /* 0008 */ 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, /* 0010 */ 0x13, 0x00, 0x00, 0x00 }) Method (_GTM, 0, NotSerialized) { Return (SSTM) } Method (_STM, 3, NotSerialized) { Store (Arg0, SSTM) } Device (MAST) { Name (_ADR, Zero) Method (_GTF, 0, NotSerialized) { If (SSEN) { Store (SSEP, SMIP) } Store (Buffer (0x07) { 0x03, 0x46, 0x00, 0x00, 0x00, 0xA0, 0xEF }, Local0) Return (Concatenate (Local0, FZTF)) } } } Method (DRMP, 0, NotSerialized) { Store (0x10, Local0) If (LEqual (And (_ADR, 0x0F), One)) { Store (0x0C, Local0) } If (LEqual (And (_ADR, 0x0F), Zero)) { Store (0x08, Local0) } ShiftRight (CPB0, Local0, Local1) And (Local1, 0x0F, Local0) Return (Local0) } } Device (ATA2) { Name (_ADR, 0x000E0002) Device (PRI0) { Name (_ADR, Zero) Name (SPTM, Buffer (0x14) { /* 0000 */ 0x78, 0x00, 0x00, 0x00, 0x0F, 0x00, 0x00, 0x00, /* 0008 */ 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, /* 0010 */ 0x13, 0x00, 0x00, 0x00 }) Method (_GTM, 0, NotSerialized) { Return (SPTM) } Method (_STM, 3, NotSerialized) { Store (Arg0, SPTM) } Device (MAST) { Name (_ADR, Zero) Method (_GTF, 0, NotSerialized) { If (SSEN) { Store (SSEP, SMIP) } Store (Buffer (0x07) { 0x03, 0x46, 0x00, 0x00, 0x00, 0xA0, 0xEF }, Local0) Return (Concatenate (Local0, FZTF)) } } } Device (SEC0) { Name (_ADR, One) Name (SSTM, Buffer (0x14) { /* 0000 */ 0x78, 0x00, 0x00, 0x00, 0x0F, 0x00, 0x00, 0x00, /* 0008 */ 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, /* 0010 */ 0x13, 0x00, 0x00, 0x00 }) Method (_GTM, 0, NotSerialized) { Return (SSTM) } Method (_STM, 3, NotSerialized) { Store (Arg0, SSTM) } Device (MAST) { Name (_ADR, Zero) Method (_GTF, 0, NotSerialized) { If (SSEN) { Store (SSEP, SMIP) } Store (Buffer (0x07) { 0x03, 0x46, 0x00, 0x00, 0x00, 0xA0, 0xEF }, Local0) Return (Concatenate (Local0, FZTF)) } } } Method (DRMP, 0, NotSerialized) { Store (0x10, Local0) If (LEqual (And (_ADR, 0x0F), One)) { Store (0x0C, Local0) } If (LEqual (And (_ADR, 0x0F), Zero)) { Store (0x08, Local0) } ShiftRight (CPB0, Local0, Local1) And (Local1, 0x0F, Local0) Return (Local0) } } Device (P0P1) { Name (_ADR, 0x000F0000) Method (_PRW, 0, NotSerialized) { Return (GPRW (Zero, 0x04)) } Method (_PRT, 0, NotSerialized) { If (PICM) { Return (AR01) } Return (PR01) } } Device (HDAC) { Name (_ADR, 0x000F0001) Method (_PRW, 0, NotSerialized) { Return (GPRW (0x15, 0x04)) } } Device (BR10) { Name (_ADR, 0x00180000) Method (_PRW, 0, NotSerialized) { Return (GPRW (0x11, 0x04)) } Method (_PRT, 0, NotSerialized) { If (PICM) { Return (AR10) } Return (PR10) } } Device (BR11) { Name (_ADR, 0x00170000) Method (_PRW, 0, NotSerialized) { Return (GPRW (0x11, 0x04)) } Method (_PRT, 0, NotSerialized) { If (PICM) { Return (AR11) } Return (PR11) } } Device (BR12) { Name (_ADR, 0x00160000) Method (_PRW, 0, NotSerialized) { Return (GPRW (0x11, 0x04)) } Method (_PRT, 0, NotSerialized) { If (PICM) { Return (AR12) } Return (PR12) } } Device (BR13) { Name (_ADR, 0x00150000) Method (_PRW, 0, NotSerialized) { Return (GPRW (0x11, 0x04)) } Method (_PRT, 0, NotSerialized) { If (PICM) { Return (AR13) } Return (PR13) } } Device (BR14) { Name (_ADR, 0x00140000) Method (_PRW, 0, NotSerialized) { Return (GPRW (0x11, 0x04)) } Method (_PRT, 0, NotSerialized) { If (PICM) { Return (AR14) } Return (PR14) } } Device (BR15) { Name (_ADR, 0x00130000) Method (_PRW, 0, NotSerialized) { Return (GPRW (0x11, 0x04)) } Method (_PRT, 0, NotSerialized) { If (PICM) { Return (AR15) } Return (PR15) } } Device (P0P8) { Name (_ADR, 0x00020000) Method (_PRW, 0, NotSerialized) { Return (GPRW (0x11, 0x04)) } Method (_PRT, 0, NotSerialized) { If (PICM) { Return (AR08) } Return (PR08) } } Device (P0PA) { Name (_ADR, 0x00030000) Method (_PRT, 0, NotSerialized) { If (PICM) { Return (AR0A) } Return (PR0A) } } Device (P0PB) { Name (_ADR, 0x00040000) Method (_PRW, 0, NotSerialized) { Return (GPRW (0x11, 0x04)) } Method (_PRT, 0, NotSerialized) { If (PICM) { Return (AR0B) } Return (PR0B) } } Device (P0PC) { Name (_ADR, 0x00050000) Method (_PRT, 0, NotSerialized) { If (PICM) { Return (AR0C) } Return (PR0C) } } Device (P0PD) { Name (_ADR, 0x00060000) Method (_PRT, 0, NotSerialized) { If (PICM) { Return (AR0D) } Return (PR0D) } } Device (USB0) { Name (_ADR, 0x000B0000) Name (_S1D, One) Method (_S3D, 0, NotSerialized) { If (LOr (LEqual (OSFL (), One), LEqual (OSFL (), 0x02))) { Return (0x02) } Else { Return (0x03) } } Method (_PRW, 0, NotSerialized) { Return (GPRW (0x0D, 0x04)) } } } Scope (\_GPE) { Method (_L10, 0, NotSerialized) { \_SB.PCI0.SBRG.SIOH () } Method (_L03, 0, NotSerialized) { \_SB.PCI0.SBRG.SIOH () Notify (\_SB.PWRB, 0x02) } Method (_L09, 0, NotSerialized) { Notify (\_SB.PCI0.NSMB, 0x02) Notify (\_SB.PWRB, 0x02) } Method (_L05, 0, NotSerialized) { Notify (\_SB.PCI0.USB2, 0x02) Notify (\_SB.PWRB, 0x02) } Method (_L00, 0, NotSerialized) { Notify (\_SB.PCI0.P0P1, 0x02) Notify (\_SB.PWRB, 0x02) } Method (_L15, 0, NotSerialized) { Notify (\_SB.PCI0.HDAC, 0x02) Notify (\_SB.PWRB, 0x02) } Method (_L11, 0, NotSerialized) { Notify (\_SB.PCI0.BR10, 0x02) Notify (\_SB.PCI0.BR11, 0x02) Notify (\_SB.PCI0.BR12, 0x02) Notify (\_SB.PCI0.BR13, 0x02) Notify (\_SB.PCI0.BR14, 0x02) Notify (\_SB.PCI0.BR15, 0x02) Notify (\_SB.PCI0.P0P8, 0x02) Notify (\_SB.PCI0.P0PB, 0x02) Notify (\_SB.PWRB, 0x02) } Method (_L0D, 0, NotSerialized) { Notify (\_SB.PCI0.USB0, 0x02) Notify (\_SB.PWRB, 0x02) } } Device (PWRB) { Name (_HID, EisaId ("PNP0C0C")) Name (_UID, 0xAA) Name (_STA, 0x0B) Method (_PRW, 0, NotSerialized) { Return (GPRW (0x03, 0x04)) } } } Scope (_SB) { Name (BUFA, ResourceTemplate () { IRQ (Level, ActiveLow, Shared, ) {15} }) CreateWordField (BUFA, One, ICRS) Method (LSTA, 1, NotSerialized) { If (Arg0) { Return (0x0B) } Else { Return (0x09) } } Method (LPRS, 2, NotSerialized) { If (PICM) { Return (Arg1) } Else { Return (Arg0) } } Method (LCRS, 1, NotSerialized) { If (PICM) { Name (BUFB, ResourceTemplate () { Interrupt (ResourceConsumer, Level, ActiveLow, Shared, ,, _Y21) { 0x00000011, } }) CreateByteField (BUFB, \_SB.LCRS._Y21._INT, AIRQ) Store (Arg0, AIRQ) If (LEqual (Arg0, One)) { Store (0x17, AIRQ) } If (LEqual (Arg0, 0x02)) { Store (0x16, AIRQ) } If (LEqual (Arg0, 0x03)) { Store (0x10, AIRQ) } If (LEqual (Arg0, 0x04)) { Store (0x11, AIRQ) } If (LEqual (Arg0, 0x06)) { Store (0x12, AIRQ) } If (LEqual (Arg0, 0x08)) { Store (0x14, AIRQ) } If (LEqual (Arg0, 0x0C)) { Store (0x13, AIRQ) } If (LEqual (Arg0, 0x0D)) { Store (0x15, AIRQ) } Return (BUFB) } Else { ShiftLeft (One, Arg0, ICRS) Return (BUFA) } } Method (LCRO, 1, NotSerialized) { If (PICM) { Name (BUFB, ResourceTemplate () { Interrupt (ResourceConsumer, Level, ActiveLow, Shared, ,, _Y22) { 0x00000014, } }) CreateByteField (BUFB, \_SB.LCRO._Y22._INT, AIRQ) Store (Arg0, AIRQ) If (LEqual (Arg0, One)) { Store (0x17, AIRQ) } If (LEqual (Arg0, 0x02)) { Store (0x16, AIRQ) } If (LEqual (Arg0, 0x03)) { Store (0x10, AIRQ) } If (LEqual (Arg0, 0x04)) { Store (0x11, AIRQ) } If (LEqual (Arg0, 0x06)) { Store (0x12, AIRQ) } If (LEqual (Arg0, 0x08)) { Store (0x14, AIRQ) } If (LEqual (Arg0, 0x0C)) { Store (0x13, AIRQ) } If (LEqual (Arg0, 0x0D)) { Store (0x15, AIRQ) } Return (BUFB) } Else { ShiftLeft (One, Arg0, ICRS) Return (BUFA) } } Method (LSRS, 1, NotSerialized) { If (PICM) { CreateByteField (Arg0, 0x05, SAIR) Store (SAIR, Local0) If (LEqual (Local0, 0x17)) { Store (One, Local0) } If (LEqual (Local0, 0x16)) { Store (0x02, Local0) } If (LEqual (Local0, 0x10)) { Store (0x03, Local0) } If (LEqual (Local0, 0x11)) { Store (0x04, Local0) } If (LEqual (Local0, 0x12)) { Store (0x06, Local0) } If (LEqual (Local0, 0x14)) { Store (0x08, Local0) } If (LEqual (Local0, 0x13)) { Store (0x0C, Local0) } If (LEqual (Local0, 0x15)) { Store (0x0D, Local0) } Return (Local0) } Else { CreateWordField (Arg0, One, ISRS) FindSetRightBit (ISRS, Local0) Return (Decrement (Local0)) } } Method (LSRO, 1, NotSerialized) { If (PICM) { CreateByteField (Arg0, 0x05, SAIR) Store (SAIR, Local0) If (LEqual (Local0, 0x14)) { Store (0x08, Local0) } If (LEqual (Local0, 0x15)) { Store (0x0D, Local0) } If (LEqual (Local0, 0x16)) { Store (0x02, Local0) } If (LEqual (Local0, 0x17)) { Store (One, Local0) } Return (Local0) } Else { CreateWordField (Arg0, One, ISRS) FindSetRightBit (ISRS, Local0) Return (Decrement (Local0)) } } Device (LNKA) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, One) Method (_STA, 0, NotSerialized) { Return (LSTA (^^PCI0.SBRG.PIRA)) } Method (_PRS, 0, NotSerialized) { Return (LPRS (PRSA, RSIR)) } Method (_DIS, 0, NotSerialized) { Store (Zero, ^^PCI0.SBRG.PIRA) } Method (_CRS, 0, NotSerialized) { Return (LCRS (^^PCI0.SBRG.PIRA)) } Method (_SRS, 1, NotSerialized) { Store (LSRS (Arg0), ^^PCI0.SBRG.PIRA) } } Device (LNKB) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, 0x02) Method (_STA, 0, NotSerialized) { Return (LSTA (^^PCI0.SBRG.PIRB)) } Method (_PRS, 0, NotSerialized) { Return (LPRS (PRSB, RSIR)) } Method (_DIS, 0, NotSerialized) { Store (Zero, ^^PCI0.SBRG.PIRB) } Method (_CRS, 0, NotSerialized) { Return (LCRS (^^PCI0.SBRG.PIRB)) } Method (_SRS, 1, NotSerialized) { Store (LSRS (Arg0), ^^PCI0.SBRG.PIRB) } } Device (LNKC) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, 0x03) Method (_STA, 0, NotSerialized) { Return (LSTA (^^PCI0.SBRG.PIRC)) } Method (_PRS, 0, NotSerialized) { Return (LPRS (PRSC, RSIR)) } Method (_DIS, 0, NotSerialized) { Store (Zero, ^^PCI0.SBRG.PIRC) } Method (_CRS, 0, NotSerialized) { Return (LCRS (^^PCI0.SBRG.PIRC)) } Method (_SRS, 1, NotSerialized) { Store (LSRS (Arg0), ^^PCI0.SBRG.PIRC) } } Device (LNKD) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, 0x04) Method (_STA, 0, NotSerialized) { Return (LSTA (^^PCI0.SBRG.PIRD)) } Method (_PRS, 0, NotSerialized) { Return (LPRS (PRSD, RSIR)) } Method (_DIS, 0, NotSerialized) { Store (Zero, ^^PCI0.SBRG.PIRD) } Method (_CRS, 0, NotSerialized) { Return (LCRS (^^PCI0.SBRG.PIRD)) } Method (_SRS, 1, NotSerialized) { Store (LSRS (Arg0), ^^PCI0.SBRG.PIRD) } } Device (LNEA) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, 0x05) Method (_STA, 0, NotSerialized) { Return (LSTA (^^PCI0.SBRG.PREA)) } Method (_PRS, 0, NotSerialized) { Return (LPRS (PRSA, RSIR)) } Method (_DIS, 0, NotSerialized) { Store (Zero, ^^PCI0.SBRG.PREA) } Method (_CRS, 0, NotSerialized) { Return (LCRS (^^PCI0.SBRG.PREA)) } Method (_SRS, 1, NotSerialized) { Store (LSRS (Arg0), ^^PCI0.SBRG.PREA) } } Device (LNEB) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, 0x06) Method (_STA, 0, NotSerialized) { Return (LSTA (^^PCI0.SBRG.PREB)) } Method (_PRS, 0, NotSerialized) { Return (LPRS (PRSB, RSIR)) } Method (_DIS, 0, NotSerialized) { Store (Zero, ^^PCI0.SBRG.PREB) } Method (_CRS, 0, NotSerialized) { Return (LCRS (^^PCI0.SBRG.PREB)) } Method (_SRS, 1, NotSerialized) { Store (LSRS (Arg0), ^^PCI0.SBRG.PREB) } } Device (LNEC) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, 0x07) Method (_STA, 0, NotSerialized) { Return (LSTA (^^PCI0.SBRG.PREC)) } Method (_PRS, 0, NotSerialized) { Return (LPRS (PRSC, RSIR)) } Method (_DIS, 0, NotSerialized) { Store (Zero, ^^PCI0.SBRG.PREC) } Method (_CRS, 0, NotSerialized) { Return (LCRS (^^PCI0.SBRG.PREC)) } Method (_SRS, 1, NotSerialized) { Store (LSRS (Arg0), ^^PCI0.SBRG.PREC) } } Device (LNED) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, 0x08) Method (_STA, 0, NotSerialized) { Return (LSTA (^^PCI0.SBRG.PRED)) } Method (_PRS, 0, NotSerialized) { Return (LPRS (PRSD, RSIR)) } Method (_DIS, 0, NotSerialized) { Store (Zero, ^^PCI0.SBRG.PRED) } Method (_CRS, 0, NotSerialized) { Return (LCRS (^^PCI0.SBRG.PRED)) } Method (_SRS, 1, NotSerialized) { Store (LSRS (Arg0), ^^PCI0.SBRG.PRED) } } Device (LUB0) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, 0x09) Method (_STA, 0, NotSerialized) { Return (LSTA (^^PCI0.SBRG.PIU0)) } Method (_PRS, 0, NotSerialized) { Return (LPRS (RSB0, RSII)) } Method (_DIS, 0, NotSerialized) { Store (Zero, ^^PCI0.SBRG.PIU0) } Method (_CRS, 0, NotSerialized) { Return (LCRO (^^PCI0.SBRG.PIU0)) } Method (_SRS, 1, NotSerialized) { Store (LSRO (Arg0), ^^PCI0.SBRG.PIU0) } } Device (LMAD) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, 0x0A) Method (_STA, 0, NotSerialized) { Return (LSTA (^^PCI0.SBRG.PILM)) } Method (_PRS, 0, NotSerialized) { Return (LPRS (RSAD, RS20)) } Method (_DIS, 0, NotSerialized) { Store (Zero, ^^PCI0.SBRG.PILM) } Method (_CRS, 0, NotSerialized) { Return (LCRO (^^PCI0.SBRG.PILM)) } Method (_SRS, 1, NotSerialized) { Store (LSRO (Arg0), ^^PCI0.SBRG.PILM) } } Device (LUB2) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, 0x0B) Method (_STA, 0, NotSerialized) { Return (LSTA (^^PCI0.SBRG.PIU2)) } Method (_PRS, 0, NotSerialized) { Return (LPRS (RSB2, RSII)) } Method (_DIS, 0, NotSerialized) { Store (Zero, ^^PCI0.SBRG.PIU2) } Method (_CRS, 0, NotSerialized) { Return (LCRO (^^PCI0.SBRG.PIU2)) } Method (_SRS, 1, NotSerialized) { Store (LSRO (Arg0), ^^PCI0.SBRG.PIU2) } } Device (LMAC) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, 0x0C) Method (_STA, 0, NotSerialized) { Return (LSTA (^^PCI0.SBRG.PILN)) } Method (_PRS, 0, NotSerialized) { Return (LPRS (RSAC, RS20)) } Method (_DIS, 0, NotSerialized) { Store (Zero, ^^PCI0.SBRG.PILN) } Method (_CRS, 0, NotSerialized) { Return (LCRO (^^PCI0.SBRG.PILN)) } Method (_SRS, 1, NotSerialized) { Store (LSRO (Arg0), ^^PCI0.SBRG.PILN) } } Device (LAZA) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, 0x0D) Method (_STA, 0, NotSerialized) { Return (LSTA (^^PCI0.SBRG.PAZA)) } Method (_PRS, 0, NotSerialized) { Return (LPRS (RSZA, RSII)) } Method (_DIS, 0, NotSerialized) { Store (Zero, ^^PCI0.SBRG.PAZA) } Method (_CRS, 0, NotSerialized) { Return (LCRO (^^PCI0.SBRG.PAZA)) } Method (_SRS, 1, NotSerialized) { Store (LSRO (Arg0), ^^PCI0.SBRG.PAZA) } } Device (LSMB) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, 0x10) Method (_STA, 0, NotSerialized) { Return (LSTA (^^PCI0.SBRG.PIRM)) } Method (_PRS, 0, NotSerialized) { Return (LPRS (RSMB, RSII)) } Method (_DIS, 0, NotSerialized) { Store (Zero, ^^PCI0.SBRG.PIRM) } Method (_CRS, 0, NotSerialized) { Return (LCRO (^^PCI0.SBRG.PIRM)) } Method (_SRS, 1, NotSerialized) { Store (LSRO (Arg0), ^^PCI0.SBRG.PIRM) } } Device (LPMU) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, 0x11) Method (_STA, 0, NotSerialized) { Return (LSTA (^^PCI0.SBRG.PMUD)) } Method (_PRS, 0, NotSerialized) { Return (LPRS (RSMU, RSII)) } Method (_DIS, 0, NotSerialized) { Store (Zero, ^^PCI0.SBRG.PMUD) } Method (_CRS, 0, NotSerialized) { Return (LCRO (^^PCI0.SBRG.PMUD)) } Method (_SRS, 1, NotSerialized) { Store (LSRO (Arg0), ^^PCI0.SBRG.PMUD) } } Device (LSA0) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, 0x12) Method (_STA, 0, NotSerialized) { Return (LSTA (^^PCI0.SBRG.PIID)) } Method (_PRS, 0, NotSerialized) { Return (LPRS (RSA0, RSII)) } Method (_DIS, 0, NotSerialized) { Store (Zero, ^^PCI0.SBRG.PIID) } Method (_CRS, 0, NotSerialized) { Return (LCRO (^^PCI0.SBRG.PIID)) } Method (_SRS, 1, NotSerialized) { Store (LSRO (Arg0), Local0) Store (Local0, ^^PCI0.SBRG.PIID) } } Device (LSA1) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, 0x13) Method (_STA, 0, NotSerialized) { Return (LSTA (^^PCI0.SBRG.SIID)) } Method (_PRS, 0, NotSerialized) { Return (LPRS (RSA1, RSII)) } Method (_DIS, 0, NotSerialized) { Store (Zero, ^^PCI0.SBRG.SIID) } Method (_CRS, 0, NotSerialized) { Return (LCRO (^^PCI0.SBRG.SIID)) } Method (_SRS, 1, NotSerialized) { Store (LSRO (Arg0), Local0) Store (Local0, ^^PCI0.SBRG.SIID) } } Device (LATA) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, 0x14) Method (_STA, 0, NotSerialized) { Return (LSTA (^^PCI0.SBRG.PR0E)) } Method (_PRS, 0, NotSerialized) { Return (LPRS (RSTA, RSII)) } Method (_DIS, 0, NotSerialized) { Store (Zero, ^^PCI0.SBRG.PR0E) } Method (_CRS, 0, NotSerialized) { If (OSFL ()) { Return (Zero) } Else { Return (LCRO (^^PCI0.SBRG.PR0E)) } } Method (_SRS, 1, NotSerialized) { Store (LSRO (Arg0), ^^PCI0.SBRG.PR0E) } } Device (LSA2) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, 0x15) Method (_STA, 0, NotSerialized) { Return (LSTA (^^PCI0.SBRG.SIR2)) } Method (_PRS, 0, NotSerialized) { Return (LPRS (RSA2, RSII)) } Method (_DIS, 0, NotSerialized) { Store (Zero, ^^PCI0.SBRG.SIR2) } Method (_CRS, 0, NotSerialized) { Return (LCRO (^^PCI0.SBRG.SIR2)) } Method (_SRS, 1, NotSerialized) { Store (LSRO (Arg0), Local0) Store (Local0, ^^PCI0.SBRG.SIR2) } } } Scope (_SB) { Name (XCPD, Zero) Name (XNPT, One) Name (XCAP, 0x02) Name (XDCP, 0x04) Name (XDCT, 0x08) Name (XDST, 0x0A) Name (XLCP, 0x0C) Name (XLCT, 0x10) Name (XLST, 0x12) Name (XSCP, 0x14) Name (XSCT, 0x18) Name (XSST, 0x1A) Name (XRCT, 0x1C) Mutex (MUTE, 0x00) Method (RBPE, 1, NotSerialized) { Acquire (MUTE, 0x03E8) Add (Arg0, PCIB, Local0) OperationRegion (PCFG, SystemMemory, Local0, One) Field (PCFG, ByteAcc, NoLock, Preserve) { XCFG, 8 } Release (MUTE) Return (XCFG) } Method (RWPE, 1, NotSerialized) { Acquire (MUTE, 0x03E8) And (Arg0, 0xFFFFFFFE, Arg0) Add (Arg0, PCIB, Local0) OperationRegion (PCFG, SystemMemory, Local0, 0x02) Field (PCFG, WordAcc, NoLock, Preserve) { XCFG, 16 } Release (MUTE) Return (XCFG) } Method (RDPE, 1, NotSerialized) { Acquire (MUTE, 0x03E8) And (Arg0, 0xFFFFFFFC, Arg0) Add (Arg0, PCIB, Local0) OperationRegion (PCFG, SystemMemory, Local0, 0x04) Field (PCFG, DWordAcc, NoLock, Preserve) { XCFG, 32 } Release (MUTE) Return (XCFG) } Method (WBPE, 2, NotSerialized) { Acquire (MUTE, 0x0FFF) Add (Arg0, PCIB, Local0) OperationRegion (PCFG, SystemMemory, Local0, One) Field (PCFG, ByteAcc, NoLock, Preserve) { XCFG, 8 } Store (Arg1, XCFG) Release (MUTE) } Method (WWPE, 2, NotSerialized) { Acquire (MUTE, 0x03E8) And (Arg0, 0xFFFFFFFE, Arg0) Add (Arg0, PCIB, Local0) OperationRegion (PCFG, SystemMemory, Local0, 0x02) Field (PCFG, WordAcc, NoLock, Preserve) { XCFG, 16 } Store (Arg1, XCFG) Release (MUTE) } Method (WDPE, 2, NotSerialized) { Acquire (MUTE, 0x03E8) And (Arg0, 0xFFFFFFFC, Arg0) Add (Arg0, PCIB, Local0) OperationRegion (PCFG, SystemMemory, Local0, 0x04) Field (PCFG, DWordAcc, NoLock, Preserve) { XCFG, 32 } Store (Arg1, XCFG) Release (MUTE) } Method (RWDP, 3, NotSerialized) { Acquire (MUTE, 0x03E8) And (Arg0, 0xFFFFFFFC, Arg0) Add (Arg0, PCIB, Local0) OperationRegion (PCFG, SystemMemory, Local0, 0x04) Field (PCFG, DWordAcc, NoLock, Preserve) { XCFG, 32 } And (XCFG, Arg2, Local1) Or (Local1, Arg1, XCFG) Release (MUTE) } Method (RPME, 1, NotSerialized) { Add (Arg0, 0x84, Local0) Store (RDPE (Local0), Local1) If (LEqual (Local1, Ones)) { Return (Zero) } Else { If (LAnd (Local1, 0x00010000)) { WDPE (Local0, And (Local1, 0x00010000)) Return (One) } Return (Zero) } } } Scope (_SB.PCI0) { Name (SUPP, Zero) Name (CTRL, Zero) Method (_OSC, 4, NotSerialized) { If (LEqual (Arg0, Buffer (0x10) { /* 0000 */ 0x5B, 0x4D, 0xDB, 0x33, 0xF7, 0x1F, 0x1C, 0x40, /* 0008 */ 0x96, 0x57, 0x74, 0x41, 0xC0, 0x3D, 0xD7, 0x66 })) { CreateDWordField (Arg3, Zero, CDW1) CreateDWordField (Arg3, 0x04, CDW2) CreateDWordField (Arg3, 0x08, CDW3) Store (CDW2, SUPP) Store (CDW3, CTRL) If (LNotEqual (And (SUPP, 0x16), 0x16)) { And (CTRL, 0x1E, CTRL) } And (CTRL, 0x1D, CTRL) If (Not (And (CDW1, One))) { If (And (CTRL, One)) {} If (And (CTRL, 0x04)) {} If (And (CTRL, 0x10)) {} } If (LNotEqual (Arg1, One)) { Or (CDW1, 0x08, CDW1) } If (LNotEqual (CDW3, CTRL)) { Or (CDW1, 0x10, CDW1) } Store (CTRL, CDW3) Return (Arg3) } Else { Or (CDW1, 0x04, CDW1) Return (Arg3) } } } OperationRegion (SMRG, SystemIO, 0x2D00, 0x50) Field (SMRG, ByteAcc, NoLock, Preserve) { PRTC, 8, HSTS, 8, HADR, 8, HCMD, 8, HDT0, 8, Offset (0x3C), DAT1, 8, DAT2, 8 } OperationRegion (S2RG, SystemIO, 0x2E00, 0x50) Field (S2RG, ByteAcc, NoLock, Preserve) { P2TC, 8, H2TS, 8, H2DR, 8, H2MD, 8, H2T0, 8, Offset (0x3C), D2T1, 8, D2T2, 8 } Method (RBYT, 2, NotSerialized) { Return (And (SCMD (Arg0, Arg1, Zero, 0x07), 0xFF)) } Method (WBYT, 3, NotSerialized) { Return (And (SCMD (Arg0, Arg1, Arg2, 0x06), 0xFF)) } Method (R2BT, 2, NotSerialized) { Return (And (S2MD (Arg0, Arg1, Zero, 0x07), 0xFF)) } Method (W2BT, 3, NotSerialized) { Return (And (S2MD (Arg0, Arg1, Arg2, 0x06), 0xFF)) } Method (SCMD, 4, Serialized) { Store (0x1F, HSTS) Store (One, DAT1) Store (0x07, DAT2) Store (0x05, Local0) While (Local0) { Store (Arg0, HADR) Store (Arg3, PRTC) Store (Arg1, HCMD) If (LEqual (Arg3, 0x06)) { Store (Arg2, HDT0) } Stall (0xFF) If (LNotEqual (HSTS, 0x80)) { Decrement (Local0) } Else { If (LEqual (Arg3, 0x07)) { Return (HDT0) } Else { Return (Zero) } } } Return (Ones) } Method (S2MD, 4, Serialized) { Store (0x1F, H2TS) Store (One, D2T1) Store (0x07, D2T2) Store (0x05, Local0) While (Local0) { Store (Arg0, H2DR) Store (Arg3, P2TC) Store (Arg1, H2MD) If (LEqual (Arg3, 0x06)) { Store (Arg2, H2T0) } Stall (0xFF) If (LNotEqual (H2TS, 0x80)) { Decrement (Local0) } Else { If (LEqual (Arg3, 0x07)) { Return (H2T0) } Else { Return (Zero) } } } Return (Ones) } Method (SBYT, 2, NotSerialized) { } Method (WWRD, 3, NotSerialized) { } Method (RSBT, 2, NotSerialized) { Store (Zero, Local0) Return (Local0) } Method (RWRD, 2, NotSerialized) { Store (Zero, Local0) Return (Local0) } Method (WBLK, 4, NotSerialized) { } Method (RBLK, 3, NotSerialized) { Store (Zero, Local0) Return (Local0) } Scope (_SB.PCI0.SBRG.ASOC) { Name (G0T0, Package (0x07) { 0x00060000, "AP version", 0x40000000, Zero, Zero, One, 0x02 }) Name (G0T1, Package (0x07) { 0x00060001, "Feature flag", 0x40000000, Zero, Zero, One, 0x08 }) Name (G0T2, Package (0x07) { 0x00070002, "ASAP function", 0x40000000, Zero, Zero, Zero, 0x02 }) Name (G0T3, Package (0x07) { 0x00070003, "AMD Cool&Quiet", 0x20000000, Zero, Zero, Zero, 0x02 }) Name (GRP0, Package (0x04) { G0T0, G0T1, G0T2, G0T3 }) Method (GIT0, 1, NotSerialized) { Name (_T_0, Zero) Store (And (Arg0, 0xFFFF), _T_0) If (LEqual (_T_0, Zero)) { Store (Zero, ASB1) } Else { If (LEqual (_T_0, One)) { Store (One, ASB1) } Else { If (LEqual (_T_0, 0x02)) { Store (0x02, ASB1) } Else { If (LEqual (_T_0, 0x03)) { Store (0x03, ASB1) } Else { Store (Zero, ASB0) } } } } } Method (SIT0, 3, NotSerialized) { Name (_T_0, Zero) Store (And (Arg0, 0xFFFF), _T_0) If (LEqual (_T_0, Zero)) { Store (0x0300, DBG8) } Else { If (LEqual (_T_0, One)) { Store (0x0301, DBG8) } Else { If (LEqual (_T_0, 0x02)) { Store (0x0302, DBG8) } Else { If (LEqual (_T_0, 0x03)) { Store (0x0303, DBG8) } Else { Store (Zero, ASB0) } } } } } } Scope (_SB.PCI0.SBRG.ASOC) { Name (G3T0, Package (0x07) { 0x03010011, "CPU Frequency", Zero, Zero, 0x4E20, 0x64, 0x0259 }) Name (G3T2, Package (0x07) { 0x03060013, "CPU Ratio", Zero, Zero, 0x06, One, 0x19 }) Name (G321, Package (0x09) { 0x03820032, "DRAM Voltage", Zero, Zero, 0x05DC, 0x14, 0x50, One, "Auto" }) Name (G322, Package (0x10) { 0x03080031, "DRAM Frequency", Zero, Zero, 0x0B, "Auto", "800 MHz", "833 MHz", "886 MHz", "1000 MHz", "1067 MHz", "1111 MHz", "1333 MHz", "1600 MHz", "1800 MHz", "2000 MHz" }) Name (G340, Package (0x09) { 0x03810051, "PCIE Frequency", Zero, Zero, 0x2710, 0x64, 0x33, One, "Auto" }) Name (GRP3, Package (0x05) { G3T0, G3T2, G321, G322, G340 }) Name (IDEX, Zero) Method (GIT3, 1, NotSerialized) { Name (_T_0, Zero) Store (And (Arg0, 0xFFFF), _T_0) If (LEqual (_T_0, 0x11)) { Divide (GNVS (0x02A8), 0x04, , Local0) Subtract (Local0, 0xC8, ASB1) } Else { If (LEqual (_T_0, 0x13)) { If (LGreater (And (GCAX (One), 0x0FF0, Local0), 0x06F0)) { Store (GMAX (0x2C), Local0) And (ShiftRight (Local0, 0x08), 0xFF, Local2) And (Local0, 0xFF, Local1) Subtract (Local1, Local2, Local0) Store (GMDX (0x0198), Local7) And (ShiftRight (Local7, 0x08), 0xFF, Local7) If (LLess (Local7, Local0)) { Store (Local1, Local7) } } Else { Store (GMDX (0x0198), Local0) And (ShiftRight (Local0, 0x08), 0x1F, Local1) Store (Local1, Local7) Store (GMAX (0x0198), Local0) And (ShiftRight (Local0, 0x18), 0x1F, Local0) } If (LEqual (GNVS (0x1660), Zero)) { If (And (GMAX (0x17), 0x00800000)) { Store (ShiftRight (And (GMAX (0x17), 0x4000), 0x0E), Local5) Store (Subtract (Local7, Local0), Local4) Multiply (Local4, 0x02, Local6) Add (Local6, Local5, ASB1) } Else { Store (Subtract (Local7, Local0), ASB1) } } Else { If (And (GMAX (0x17), 0x00800000)) { Store (ShiftRight (And (GNVS (0x8298), 0x40), 0x06), Local5) Store (Subtract (And (GNVS (0x8298), 0x1F), Local0), Local4) Multiply (Local4, 0x02, Local6) Add (Local6, Local5, ASB1) } Else { Store (Subtract (And (GNVS (0x8298), 0x1F), Local0), ASB1) } } Store (ASB1, IDEX) } Else { If (LEqual (_T_0, 0x31)) { If (LEqual (GNVS (0x2350), 0x02)) { Store (GNVS (0xC2D0), Local0) Store (0x0A, Local1) Store (Zero, Local2) While (LNotEqual (Local1, Local2)) { If (LEqual (Local0, DerefOf (Index (MEMF, Local2)))) { Increment (Local2) Store (Local2, ASB1) Store (Local1, Local2) Store (One, Local0) } Else { Increment (Local2) } } If (LNotEqual (Local0, One)) { Store (Zero, ASB1) } Store (One, ASB0) } } Else { If (LEqual (_T_0, 0x32)) { Store (GNVS (0x7388), Local0) If (LEqual (Local0, Zero)) { Store (Zero, ASB1) Store (One, ASB0) } Else { Store (Local0, ASB1) Store (One, ASB0) } } Else { If (LEqual (_T_0, 0x51)) { Store (GNVS (0x7370), Local0) Increment (Local0) Store (Local0, ASB1) Store (One, ASB0) } Else { Store (Zero, ASB0) } } } } } } Method (SIT3, 3, NotSerialized) { Name (_T_0, Zero) Store (And (Arg0, 0xFFFF), _T_0) If (LEqual (_T_0, 0x11)) { Store (Arg1, Local0) Add (Local0, 0xC8, Local0) If (LEqual (Arg1, Zero)) { Store (CPTP (), Local0) Store (DerefOf (Index (CPFS, Local0)), Local0) } Or (ASB0, 0x02, ASB0) Multiply (Local0, 0x04, Local0) SNVS (0x02A8, Local0) SNVS (0x2360, Zero) } Else { If (LEqual (_T_0, 0x13)) { If (LNotEqual (IDEX, Arg1)) { If (And (Arg2, One)) { SNVS (0x35B3, 0x04) SNVS (0x1660, One) If (LGreater (And (GCAX (One), 0x0FF0, Local0), 0x06F0)) { Store (GMAX (0x2C), Local0) And (ShiftRight (Local0, 0x08), 0xFF, Local2) And (Local0, 0xFF, Local1) Subtract (Local1, Local2, Local3) } Else { Store (GMDX (0x0198), Local0) And (ShiftRight (Local0, 0x08), 0x1F, Local1) Store (GMAX (0x0198), Local0) And (ShiftRight (Local0, 0x18), 0x1F, Local3) } If (And (GMAX (0x17), 0x00800000)) { Store (Arg1, Local2) And (Local2, One, Local0) ShiftRight (Local2, One, Arg1) Add (Arg1, Local3, Arg1) } Else { Store (Zero, Local0) Add (Arg1, Local3, Arg1) } Or (Arg1, ShiftLeft (Local0, 0x06), Arg1) SNVS (0x8298, Arg1) } Or (ASB0, 0x02, ASB0) } } Else { If (LEqual (_T_0, 0x32)) { If (LNotEqual (GNVS (0x7388), Arg1)) { If (And (Arg2, One)) { SNVS (0x7388, Arg1) W2BT (0x3C, Zero, Arg1) W2BT (0x3C, One, One) W2BT (0x3C, 0x02, One) W2BT (0x3C, 0x40, One) } } } Else { If (LEqual (_T_0, 0x31)) { If (LNotEqual (Arg1, Zero)) { Subtract (Arg1, One, Local0) Store (DerefOf (Index (MEMF, Local0)), Local0) If (And (Arg2, One)) { SNVS (0x2350, 0x02) SNVS (0xC2D0, Local0) SNVS (0xC2F0, Local0) } Or (ASB0, 0x02, ASB0) } Else { If (And (Arg2, One)) { SNVS (0x2350, Zero) } Or (ASB0, 0x02, ASB0) } } Else { If (LEqual (_T_0, 0x51)) { If (LNotEqual (GNVS (0x7370), Arg1)) { If (And (Arg2, One)) { Decrement (Arg1) SNVS (0x7370, Arg1) } Or (ASB0, 0x02, ASB0) } } Else { Store (Zero, ASB0) } } } } } } Name (CPFS, Package (0x04) { 0xC8, 0x010B, 0x014D, 0x0190 }) Name (MEMF, Package (0x0A) { 0x0320, 0x0341, 0x0376, 0x03E8, 0x042B, 0x0457, 0x0535, 0x0640, 0x0708, 0x07D0 }) } Scope (_SB.PCI0.SBRG.ASOC) { Name (G4T0, Package (0x04) { 0x04070010, "CPU Q-FAN Control", 0x80000000, Zero }) Name (G4T1, Package (0x08) { 0x04080011, "CPU Q-FAN Profile", 0x00100001, Zero, 0x03, "Performance", "Optimal", "Silent" }) Name (G420, Package (0x04) { 0x04070070, "Chassis Q-FAN Control", 0x80000000, Zero }) Name (G421, Package (0x0A) { 0x04080071, "Chassis FAN Ratio", 0x00700001, Zero, 0x05, "Auto", "90%", "80%", "70%", "60%" }) Name (GRP4, Package (0x04) { G4T0, G4T1, G420, G421 }) Method (GIT4, 1, NotSerialized) { Name (_T_0, Zero) Store (And (Arg0, 0xFFFF), _T_0) If (LEqual (_T_0, 0x10)) { Store (GNVS (0x16A5), ASB1) } Else { If (LEqual (_T_0, 0x11)) { Store (GNVS (0x261E), ASB1) } Else { If (LEqual (_T_0, 0x70)) { Store (GNVS (0x16A6), ASB1) } Else { If (LEqual (_T_0, 0x71)) { Store (GNVS (0x35D8), ASB1) } Else { Store (Zero, ASB0) } } } } } Method (SIT4, 3, NotSerialized) { Name (_T_0, Zero) Store (And (Arg0, 0xFFFF), _T_0) If (LEqual (_T_0, 0x10)) { If (LNotEqual (GNVS (0x16A5), Arg1)) { If (And (Arg2, One)) { SNVS (0x16A5, Arg1) Store (0x77, PAR0) ISMI (0x88) } } } Else { If (LEqual (_T_0, 0x11)) { If (LNotEqual (GNVS (0x261E), Arg1)) { If (And (Arg2, One)) { SNVS (0x261E, Arg1) Store (0x77, PAR0) ISMI (0x88) } } } Else { If (LEqual (_T_0, 0x70)) { If (LNotEqual (GNVS (0x16A6), Arg1)) { If (And (Arg2, One)) { SNVS (0x16A6, Arg1) Store (0x78, PAR0) ISMI (0x88) } } } Else { If (LEqual (_T_0, 0x71)) { If (LNotEqual (GNVS (0x35D8), Arg1)) { If (And (Arg2, One)) { Store (Arg1, DBG8) SNVS (0x35D8, Arg1) Store (0x78, PAR0) ISMI (0x88) } } } Else { Store (Zero, ASB0) } } } } } } Scope (_SB.PCI0.SBRG.ASOC) { Name (G6T1, Package (0x07) { 0x06020011, "Vcore Voltage", 0x20000000, Zero, 0x0352, 0x02EE, 0x02 }) Name (G6T2, Package (0x07) { 0x06030012, "CPU Temperature", 0x20000000, Zero, 0x0258, 0x015E, 0x02 }) Name (G6T3, Package (0x07) { 0x06040013, "CPU FAN Speed", 0x20000000, Zero, 0x0258, 0x1900, 0x02 }) Name (G6T4, Package (0x07) { 0x06040073, "Chassis FAN Speed", 0x20000000, Zero, 0x0258, 0x1900, 0x02 }) Name (G6T5, Package (0x07) { 0x060400C3, "Power FAN Speed", 0x20000000, Zero, 0x0258, 0x1900, 0x02 }) Name (G6T6, Package (0x07) { 0x06020061, "+12V Voltage", 0x20000000, 0x2EE0, 0x27D8, 0x0E10, 0x02 }) Name (G6T7, Package (0x07) { 0x06020062, "+5V Voltage", 0x20000000, 0x1388, 0x1194, 0x03E8, 0x02 }) Name (G6T8, Package (0x07) { 0x06020063, "+3.3V Voltage", 0x20000000, 0x0CE4, 0x0B9A, 0x0294, 0x02 }) Name (G6T9, Package (0x07) { 0x06030074, "MB Temperature", 0x20000000, Zero, 0x01C2, 0x01F4, 0x02 }) Name (GRP6, Package (0x09) { G6T1, G6T2, G6T3, G6T4, G6T5, G6T6, G6T7, G6T8, G6T9 }) Method (GIT6, 1, NotSerialized) { Name (_T_0, Zero) Store (And (Arg0, 0xFFFF), _T_0) If (LEqual (_T_0, 0x11)) { Multiply (^^SIOR.HWV0 (), ASB1) } Else { If (LEqual (_T_0, 0x12)) { Store (^^SIOR.HWT1 (), ASB1) } Else { If (LEqual (_T_0, 0x13)) { Store (^^SIOR.HWF1 (), ASB1) } Else { If (LEqual (_T_0, 0x73)) { Store (^^SIOR.HWF2 (), ASB1) } Else { If (LEqual (_T_0, 0xC3)) { Store (^^SIOR.HWF3 (), ASB1) } Else { If (LEqual (_T_0, 0x61)) { Multiply (^^SIOR.HWV4 (), ASB1) } Else { If (LEqual (_T_0, 0x62)) { Multiply (^^SIOR.HWV3 (), ASB1) } Else { If (LEqual (_T_0, 0x63)) { Multiply (^^SIOR.HWV1 (), ASB1) } Else { If (LEqual (_T_0, 0x74)) { Store (^^SIOR.HWT2 (), ASB1) } } } } } } } } } } Method (SIT6, 3, NotSerialized) { Name (_T_0, Zero) Store (And (Arg0, 0xFFFF), _T_0) If (LEqual (_T_0, 0x11)) { Multiply (^^SIOR.HWV0 (), ASB1) } Else { If (LEqual (_T_0, 0x12)) { Store (^^SIOR.HWT1 (), ASB1) } Else { If (LEqual (_T_0, 0x13)) { Store (^^SIOR.HWF1 (), ASB1) } Else { If (LEqual (_T_0, 0x73)) { Store (^^SIOR.HWF2 (), ASB1) } Else { If (LEqual (_T_0, 0xC3)) { Store (^^SIOR.HWF3 (), ASB1) } Else { If (LEqual (_T_0, 0x61)) { Multiply (^^SIOR.HWV4 (), ASB1) } Else { If (LEqual (_T_0, 0x62)) { Multiply (^^SIOR.HWV3 (), ASB1) } Else { If (LEqual (_T_0, 0x63)) { Multiply (^^SIOR.HWV1 (), ASB1) } Else { If (LEqual (_T_0, 0x74)) { Store (^^SIOR.HWT2 (), ASB1) } Else { Store (Zero, ASB0) } } } } } } } } } } } Scope (_SB.PCI0.SBRG.ASOC) { Name (G9T0, Package (0x0B) { 0x09080000, "AI Overclocking", Zero, One, 0x06, "Manual", "Auto", "Standard", Zero, "N.O.S.", Zero }) Name (GRP9, Package (0x01) { G9T0 }) Method (GIT9, 1, NotSerialized) { Name (_T_0, Zero) Store (And (Arg0, 0xFFFF), _T_0) If (LEqual (_T_0, Zero)) { Store (GNVS (0x2350), Local0) Store (GNVS (0x4358), Local1) Name (_T_1, Zero) Store (Or (Local0, Local1, Local0), _T_1) If (LEqual (_T_1, Zero)) { Store (One, ASB1) } Else { Store (Zero, ASB1) } Store (One, ASB0) } Else { Store (Zero, ASB0) } } Method (SIT9, 3, NotSerialized) { Name (_T_0, Zero) Store (And (Arg0, 0xFFFF), _T_0) If (LEqual (_T_0, Zero)) { Name (_T_1, Zero) Store (And (Arg1, 0x0F), _T_1) If (LEqual (_T_1, Zero)) { If (LNotEqual (GNVS (0x2350), One)) { If (And (Arg2, One)) { If (LNotEqual (GNVS (0x2350), 0x02)) { SNVS (0x2350, One) } } } } Else { If (LEqual (_T_1, One)) { If (LNotEqual (GNVS (0x2350), Zero)) { If (And (Arg2, One)) { SNVS (0x2350, Zero) } Or (ASB0, 0x02, ASB0) } } Else { If (LEqual (_T_1, 0x02)) { If (LNotEqual (GNVS (0x2350), Zero)) { If (And (Arg2, One)) { SNVS (0x2350, Zero) } Or (ASB0, 0x02, ASB0) } } Else { Store (Zero, ASB0) } } } } Else { Store (Zero, ASB0) } } Method (RTAM, 0, NotSerialized) { Store (0xC1, DBG8) Store (CPTP (), Local0) Store (DerefOf (Index (CPFS, Local0)), Local0) Multiply (Local0, 0x04, Local0) SNVS (0x02A8, Local0) Store (Local0, DBG8) CALC (Local0) } } Scope (_SB.PCI0.SBRG.ASOC) { Name (GBT0, Package (0x07) { 0x0B060001, "System Performance", Zero, Zero, 0x03, One, 0x04 }) Name (GBT1, Package (0x07) { 0x0B060002, "System Performance Control", Zero, Zero, Zero, Zero, Zero }) Name (GBT2, Package (0x07) { 0x0B060003, "System GUI", 0x02, Zero, Zero, Zero, Zero }) Name (GRPB, Package (0x03) { GBT0, GBT1, GBT2 }) Method (GITB, 1, NotSerialized) { Name (_T_0, Zero) Store (And (Arg0, 0xFFFF), _T_0) If (LEqual (_T_0, One)) { Store (And (DerefOf (Index (GBT0, 0x02)), 0xFFFF), ASB1) } Else { If (LEqual (_T_0, 0x02)) { Store (DerefOf (Index (GBT1, 0x02)), ASB1) } Else { If (LEqual (_T_0, 0x03)) { Store (DerefOf (Index (GBT2, 0x02)), ASB1) } Else { Store (Zero, ASB0) } } } } Method (SITB, 3, NotSerialized) { Name (_T_0, Zero) Store (And (Arg0, 0xFFFF), _T_0) If (LEqual (_T_0, One)) { Name (_T_1, Zero) Store (And (Arg2, 0xFFFF), _T_1) If (LEqual (_T_1, Zero)) { Store (And (DerefOf (Index (GBT0, 0x02)), 0xFFFF), Local0) If (LEqual (Local0, Zero)) { Store (Local0, PAR0) } } Else { If (LEqual (_T_1, One)) { And (Arg1, 0xFFFF, Local0) Store (Local0, Index (GBT0, 0x02)) SICL (Local0) Store (Local0, PAR0) ISMI (0x88) } Else { Store (One, ASB0) } } } Else { If (LEqual (_T_0, 0x02)) { Store (And (Arg1, 0xFF), Local0) If (LEqual (ITCG (Local0), One)) { Store (Local0, Index (GBT1, 0x02)) Store (One, ASB0) } Else { Store (Zero, ASB0) } } Else { Store (Zero, ASB0) } } } } Scope (_GPE) { Method (_L2A, 0, NotSerialized) { Notify (\_SB.PCI0.SBRG.ASOC, 0x05) Store (0x0B, DBUG) If (LEqual (\_SB.PCI0.SBRG.ASOC.AIGC, One)) { \_SB.PCI0.SBRG.ASOC.GITE (0x0E060001) \_SB.PCI0.SBRG.ASOC.SICL (Or (0x8010, \_SB.PCI0.SBRG.ASOC.ASB1)) } \_SB.PCI0.SBRG.ASOC.RCAS () } } OperationRegion (_SB.PCI0.MICP.PFSB, PCI_Config, 0x44, 0x20) Field (\_SB.PCI0.MICP.PFSB, ByteAcc, NoLock, Preserve) { FSP1, 8, FSP2, 8, FSP3, 8, FSPC, 8 } OperationRegion (_SB.PCI0.MICP.FPMN, PCI_Config, 0x78, 0x20) Field (\_SB.PCI0.MICP.FPMN, ByteAcc, NoLock, Preserve) { FP4M, 8, FP4N, 8 } OperationRegion (_SB.PCI0.MICP.PFSC, PCI_Config, 0x58, 0x20) Field (\_SB.PCI0.MICP.PFSC, ByteAcc, NoLock, Preserve) { PEAC, 8 } OperationRegion (DEBU, SystemIO, DP80, One) Field (DEBU, ByteAcc, NoLock, Preserve) { DBUG, 8 } Scope (_SB.PCI0.SBRG.ASOC) { Name (GET1, Package (0x07) { 0x0E060001, "OC Status", Zero, Zero, Zero, Zero, Zero }) Name (GET2, Package (0x07) { 0x0E0A0011, "ICPU Value", Zero, Zero, Zero, Zero, Zero }) Name (GET3, Package (0x07) { 0x0E020012, "VCPU Value", Zero, Zero, Zero, Zero, Zero }) Name (GET4, Package (0x07) { 0x0E0B0013, "PCPU Value", Zero, Zero, Zero, Zero, Zero }) Name (GET5, Package (0x07) { 0x0E0A0014, "OC Threshold1", Zero, Zero, Zero, Zero, Zero }) Name (GET6, Package (0x07) { 0x0E0A0015, "OC Threshold2", Zero, Zero, Zero, Zero, Zero }) Name (GET7, Package (0x07) { 0x0E0A0016, "OC Threshold3", Zero, Zero, Zero, Zero, Zero }) Name (GRPE, Package (0x07) { GET1, GET2, GET3, GET4, GET5, GET6, GET7 }) Name (ADP3, Package (0x0D) { 0x40, 0x3B, 0x48, 0x4A, 0x4C, 0x69, 0x6A, 0x6B, 0x56, 0x5C, 0x37, 0x38, 0x36 }) Name (OCST, Buffer (0x04) { 0x00, 0x01, 0x02, 0x03 }) Method (GITE, 1, NotSerialized) { Name (_T_0, Zero) Store (And (Arg0, 0xFFFF), _T_0) If (LEqual (_T_0, One)) { Store (DerefOf (Index (OCST, RBYT (DerefOf (Index (ADP3, Zero)), DerefOf (Index (ADP3, One))))), ASB1) } Else { If (LEqual (_T_0, 0x11)) { Store (RBYT (DerefOf (Index (ADP3, Zero)), DerefOf (Index (ADP3, 0x02))), Local0) Store (RBYT (DerefOf (Index (ADP3, Zero)), Add (DerefOf (Index ( ADP3, 0x02)), One)), Local1) Or (ShiftLeft (Local1, 0x02), And (Local0, 0x03), ASB1) } Else { If (LEqual (_T_0, 0x12)) { Store (RBYT (DerefOf (Index (ADP3, Zero)), DerefOf (Index (ADP3, 0x03))), Local0) Store (RBYT (DerefOf (Index (ADP3, Zero)), Add (DerefOf (Index ( ADP3, 0x03)), One)), Local1) Or (ShiftLeft (Local1, 0x02), And (Local0, 0x03), ASB1) } Else { If (LEqual (_T_0, 0x13)) { Store (RBYT (DerefOf (Index (ADP3, Zero)), DerefOf (Index (ADP3, 0x04))), Local0) Store (RBYT (DerefOf (Index (ADP3, Zero)), Add (DerefOf (Index ( ADP3, 0x04)), One)), Local1) Or (ShiftLeft (Local1, 0x08), Local0, ASB1) } Else { If (LEqual (_T_0, 0x14)) { Store (RBYT (DerefOf (Index (ADP3, Zero)), DerefOf (Index (ADP3, 0x05))), ASB1) } Else { If (LEqual (_T_0, 0x15)) { Store (RBYT (DerefOf (Index (ADP3, Zero)), DerefOf (Index (ADP3, 0x06))), ASB1) } Else { If (LEqual (_T_0, 0x16)) { Store (RBYT (DerefOf (Index (ADP3, Zero)), DerefOf (Index (ADP3, 0x07))), ASB1) } Else { Store (Zero, ASB0) } } } } } } } } Method (SITE, 3, NotSerialized) { Name (_T_0, Zero) Store (And (Arg0, 0xFFFF), _T_0) If (LEqual (_T_0, 0x14)) { WBYT (DerefOf (Index (ADP3, Zero)), DerefOf (Index (ADP3, 0x05 )), Arg1) } Else { If (LEqual (_T_0, 0x15)) { WBYT (DerefOf (Index (ADP3, Zero)), DerefOf (Index (ADP3, 0x06 )), Arg1) } Else { If (LEqual (_T_0, 0x16)) { WBYT (DerefOf (Index (ADP3, Zero)), DerefOf (Index (ADP3, 0x07 )), Arg1) } Else { Store (Zero, ASB0) } } } } Method (ITCG, 1, NotSerialized) { Store (CPTP (), Local0) Sleep (0x03E8) And (PEAC, 0xFE, PEAC) Name (_T_0, Zero) Store (And (Arg0, 0xFF), _T_0) If (LEqual (_T_0, Zero)) { MAPF (Local0, One) } Else { If (LEqual (_T_0, One)) { MAPF (Local0, Zero) } Else { Return (Zero) } } Return (One) } Name (MAPT, Package (0x04) { Package (0x04) { 0xD2, 0xC8, 0xBE, 0xB4 }, Package (0x04) { 0x0118, 0x010B, 0xFC, 0xEE }, Package (0x04) { 0x015E, 0x014D, 0x013C, 0x012B }, Package (0x04) { 0x01A4, 0x0190, 0x017C, 0x0168 } }) Method (MAPF, 2, NotSerialized) { Store (Arg0, Local0) Store (Arg1, Local1) Store (DerefOf (Index (DerefOf (Index (MAPT, Local0)), Local1)), Local0) CALC (Local0) } Method (CALC, 1, NotSerialized) { Store (Arg0, Local0) Store (FSPC, Local3) And (Local3, 0xFD, Local3) If (LAnd (Local3, 0xFF)) { Store (0x02, Local3) Multiply (Local0, Local3, Local2) } Multiply (Local2, FSP1, Local2) Multiply (Local2, FP4M, Local2) Store (FP4N, Local3) Multiply (Local3, 0x19, Local3) Divide (Local2, Local3, , Local2) Store (FSP2, Local4) Store (FSP3, Local3) And (Local3, One, Local3) ShiftLeft (Local3, 0x08, Local3) Or (Local4, Local3, Local3) Divide (Local3, 0x02, , Local3) If (LLess (Local3, Local2)) { Increment (Local2) } Else { Decrement (Local2) } While (LNotEqual (Local3, Local2)) { Multiply (Local3, 0x02, Local1) Store (Local1, FSP2) ShiftRight (Local1, 0x08, Local1) And (Local1, One, Local1) Store (FSP3, Local4) And (Local4, 0xFE, Local4) Or (Local1, Local4, Local1) Store (Local1, FSP3) Or (FSPC, 0x40, FSPC) And (FSPC, 0xBF, FSPC) If (LLess (Local3, Local2)) { Increment (Local3) } Else { Decrement (Local3) } } } Method (CPTP, 0, NotSerialized) { Name (_T_0, Zero) Store (GNVS (0x8720), _T_0) If (LEqual (_T_0, Zero)) { Store (0x02, Local0) } Else { If (LEqual (_T_0, One)) { Store (One, Local0) } Else { If (LEqual (_T_0, 0x02)) { Store (Zero, Local0) } Else { If (LEqual (_T_0, 0x03)) { Store (0x02, Local0) } Else { If (LEqual (_T_0, 0x04)) { Store (One, Local0) } Else { If (LEqual (_T_0, 0x05)) { Store (0x02, Local0) } Else { If (LEqual (_T_0, 0x06)) { Store (One, Local0) } Else { If (LEqual (_T_0, 0x07)) { Store (0x02, Local0) } Else { If (LEqual (_T_0, 0x08)) { Store (One, Local0) } Else { If (LEqual (_T_0, 0x09)) { Store (0x03, Local0) } Else { If (LEqual (_T_0, 0x0A)) { Store (0x03, Local0) } Else { If (LEqual (_T_0, 0x0B)) { Store (Zero, Local0) } Else { If (LEqual (_T_0, 0x7E)) { Store (Zero, Local0) } Else { If (LEqual (_T_0, 0x7F)) { Store (One, Local0) } Else { Store (Zero, Local0) } } } } } } } } } } } } } } Return (Local0) } Name (AIGC, Zero) Method (SICL, 1, NotSerialized) { If (And (Arg0, 0x8000)) { Store (One, AIGC) Name (_T_0, Zero) Store (And (Arg0, 0xFF), _T_0) If (LEqual (_T_0, 0x10)) { SPIC (Zero) Store (Zero, PICL) Store (0x10, DBUG) } Else { If (LEqual (_T_0, 0x11)) { SPIC (One) Store (One, PICL) Store (0x11, DBUG) } Else { If (LEqual (_T_0, 0x12)) { SPIC (0x02) Store (0x02, PICL) Store (0x12, DBUG) } Else { If (LEqual (_T_0, 0x13)) { SPIC (0x03) Store (0x03, PICL) Store (0x13, DBUG) } Else { } } } } } Else { Store (Zero, AIGC) If (And (Arg0, 0x4000)) { SPIC (Zero) Store (Zero, PICL) } Else { Name (_T_1, Zero) Store (And (Arg0, 0xFF), _T_1) If (LEqual (_T_1, Zero)) { SPIC (One) Store (One, PICL) } Else { If (LEqual (_T_1, One)) { SPIC (0x02) Store (0x02, PICL) } Else { If (LEqual (_T_1, 0x02)) { SPIC (0x03) Store (0x03, PICL) } Else { Return (Zero) } } } } } Return (One) } Name (PICL, One) Name (PSLV, Package (0x04) { Package (0x05) { Zero, Zero, Zero, Zero, 0x10 }, Package (0x05) { Zero, Zero, 0xFF, Zero, 0x10 }, Package (0x05) { Zero, 0xFF, 0xFF, 0x36, 0x08 }, Package (0x05) { 0xFF, 0xFF, 0xFF, 0x2C, 0x08 } }) Method (SPIC, 1, NotSerialized) { If (LLessEqual (Arg0, PICL)) { WBYT (DerefOf (Index (ADP3, Zero)), DerefOf (Index (ADP3, 0x08 )), DerefOf (Index (DerefOf (Index (PSLV, Arg0)), 0x03))) WBYT (DerefOf (Index (ADP3, Zero)), DerefOf (Index (ADP3, 0x09 )), DerefOf (Index (DerefOf (Index (PSLV, Arg0)), 0x04))) If (LEqual (AIGC, Zero)) { WBYT (DerefOf (Index (ADP3, Zero)), DerefOf (Index (ADP3, 0x05 )), DerefOf (Index (DerefOf (Index (PSLV, Arg0)), Zero))) Sleep (0x03E8) WBYT (DerefOf (Index (ADP3, Zero)), DerefOf (Index (ADP3, 0x06 )), DerefOf (Index (DerefOf (Index (PSLV, Arg0)), One))) Sleep (0x03E8) WBYT (DerefOf (Index (ADP3, Zero)), DerefOf (Index (ADP3, 0x07 )), DerefOf (Index (DerefOf (Index (PSLV, Arg0)), 0x02))) Sleep (0x03E8) } Store (CPTP (), Local0) Store (Arg0, Local1) MAPF (Local0, Local1) } Else { If (LEqual (AIGC, Zero)) { WBYT (DerefOf (Index (ADP3, Zero)), DerefOf (Index (ADP3, 0x07 )), DerefOf (Index (DerefOf (Index (PSLV, Arg0)), 0x02))) Sleep (0x03E8) WBYT (DerefOf (Index (ADP3, Zero)), DerefOf (Index (ADP3, 0x06 )), DerefOf (Index (DerefOf (Index (PSLV, Arg0)), One))) Sleep (0x03E8) WBYT (DerefOf (Index (ADP3, Zero)), DerefOf (Index (ADP3, 0x05 )), DerefOf (Index (DerefOf (Index (PSLV, Arg0)), Zero))) Sleep (0x03E8) } Store (CPTP (), Local0) Store (Arg0, Local1) MAPF (Local0, Local1) WBYT (DerefOf (Index (ADP3, Zero)), DerefOf (Index (ADP3, 0x09 )), DerefOf (Index (DerefOf (Index (PSLV, Arg0)), 0x04))) WBYT (DerefOf (Index (ADP3, Zero)), DerefOf (Index (ADP3, 0x08 )), DerefOf (Index (DerefOf (Index (PSLV, Arg0)), 0x03))) } RCAS () } Method (RCAS, 0, NotSerialized) { Store (RBYT (DerefOf (Index (ADP3, Zero)), DerefOf (Index (ADP3, 0x0A))), Local0) And (Local0, 0x10, Local0) While (LEqual (Local0, 0x10)) { Store (RBYT (DerefOf (Index (ADP3, Zero)), DerefOf (Index (ADP3, 0x0A))), Local0) And (Local0, 0x10, Local0) } RBYT (DerefOf (Index (ADP3, Zero)), DerefOf (Index (ADP3, 0x0B ))) RBYT (DerefOf (Index (ADP3, Zero)), DerefOf (Index (ADP3, 0x0C ))) } } Scope (_SB.PCI0.SBRG.SIOR) { Method (HWV0, 0, NotSerialized) { Return (Multiply (VIV0, 0x10)) } Method (HWV1, 0, NotSerialized) { Return (Multiply (VIV1, 0x10)) } Method (HWV2, 0, NotSerialized) { Return (Multiply (VIV2, 0x10)) } Method (HWV3, 0, NotSerialized) { Return (Multiply (VIV3, 0x10)) } Method (HWV4, 0, NotSerialized) { Return (Multiply (VIV4, 0x10)) } Method (HWV5, 0, NotSerialized) { Return (Multiply (VIV5, 0x10)) } Method (HWV6, 0, NotSerialized) { Return (Multiply (VIV6, 0x10)) } Method (HWV7, 0, NotSerialized) { Return (Multiply (VIV7, 0x10)) } Method (HWT1, 0, NotSerialized) { Store (TPI1, Local0) If (LGreater (Local0, 0x80)) { Subtract (0x0100, Local0, Local0) } Add (Local0, T1OF, Local0) Return (Multiply (Local0, 0x0A)) } Method (HWT2, 0, NotSerialized) { Store (TPI2, Local0) If (LGreater (Local0, 0x80)) { Subtract (0x0100, Local0, Local0) } Add (Local0, T2OF, Local0) Return (Multiply (Local0, 0x0A)) } Method (HWT3, 0, NotSerialized) { Store (TPI3, Local0) If (LGreater (Local0, 0x80)) { Subtract (0x0100, Local0, Local0) } Add (Local0, T3OF, Local0) Return (Multiply (Local0, 0x0A)) } Method (HWF1, 0, NotSerialized) { If (LEqual (ETD1, One)) { Or (ShiftLeft (EFN1, 0x08), FTC1, Local0) Return (CF16 (Local0)) } Store (FTC1, Local0) Store (One, Local2) While (LAnd (LOr (LLessEqual (Local0, FHMT), LGreaterEqual (Local0, FLMT)), LEqual (Local2, One))) { If (LLessEqual (Local0, FHMT)) { Store (FTD1, Local1) If (LGreater (Local1, Zero)) { Decrement (Local1) Store (Local1, FTD1) } Else { Store (Zero, Local2) } } Else { Store (FTD1, Local1) If (LLess (Local1, 0x07)) { Increment (Local1) Store (Local1, FTD1) } Else { Store (Zero, Local2) } } Sleep (0x012C) Store (FTC1, Local0) } Return (CF08 (Local0, DerefOf (Index (DTB1, FTD1)))) } Method (HWF2, 0, NotSerialized) { If (LEqual (ETD2, One)) { Or (ShiftLeft (EFN2, 0x08), FTC2, Local0) Return (CF16 (Local0)) } Store (FTC2, Local0) Store (One, Local2) While (LAnd (LOr (LLessEqual (Local0, FHMT), LGreaterEqual (Local0, FLMT)), LEqual (Local2, One))) { If (LLessEqual (Local0, FHMT)) { Store (FTD2, Local1) If (LGreater (Local1, Zero)) { Decrement (Local1) Store (Local1, FTD2) } Else { Store (Zero, Local2) } } Else { Store (FTD2, Local1) If (LLess (Local1, 0x07)) { Increment (Local1) Store (Local1, FTD2) } Else { Store (Zero, Local2) } } Sleep (0x012C) Store (FTC2, Local0) } Return (CF08 (Local0, DerefOf (Index (DTB1, FTD2)))) } Method (HWF3, 0, NotSerialized) { If (LEqual (ETD3, One)) { Or (ShiftLeft (EFN3, 0x08), FTC3, Local0) Return (CF16 (Local0)) } Store (FTC3, Local0) If (LLessEqual (Local0, FHM3)) { Store (FTD3, Local1) If (LGreater (Local1, Zero)) { Decrement (Local1) Store (Local1, FTD3) Sleep (0x012C) Store (FTC3, Local0) } } Else { If (LGreaterEqual (Local0, FLMT)) { Store (FTD3, Local1) If (LLess (Local1, One)) { Increment (Local1) Store (Local1, FTD3) Sleep (0x012C) Store (FTC3, Local0) } } } Return (CF08 (Local0, DerefOf (Index (DTB1, FTD3)))) } Method (HWF4, 0, NotSerialized) { Or (ShiftLeft (EFN4, 0x08), FTC4, Local0) Return (CF16 (Local0)) } Method (HWF5, 0, NotSerialized) { Or (ShiftLeft (EFN5, 0x08), FTC5, Local0) Return (CF16 (Local0)) } Method (CF08, 2, NotSerialized) { If (LOr (LEqual (Arg0, Zero), LEqual (Arg0, 0xFF))) { Return (Zero) } Divide (FTFR, Multiply (Arg0, Arg1), , Local0) Return (Local0) } Method (CF16, 1, NotSerialized) { If (LOr (LEqual (Arg0, Zero), LEqual (Arg0, 0xFFFF))) { Return (Zero) } Divide (FTFR, Multiply (Arg0, 0x02), , Local0) Return (Local0) } Name (FTFR, 0x00149970) Name (FHMT, 0x78) Name (FHM3, 0x3C) Name (FLMT, 0xFE) Name (DTB1, Package (0x08) { One, 0x02, 0x04, 0x08, 0x10, 0x20, 0x40, 0x80 }) Name (DTB2, Package (0x02) { 0x02, 0x08 }) OperationRegion (ECRE, SystemIO, IOEB, 0x20) Field (ECRE, ByteAcc, NoLock, Preserve) { Offset (0x05), HIDX, 8, HDAT, 8 } IndexField (HIDX, HDAT, ByteAcc, NoLock, Preserve) { Offset (0x0B), FTD1, 3, FTD2, 3, FTD3, 1, Offset (0x0C), ETD1, 1, ETD2, 1, ETD3, 1, Offset (0x0D), FTC1, 8, FTC2, 8, FTC3, 8, Offset (0x18), EFN1, 8, EFN2, 8, EFN3, 8, Offset (0x20), VIV0, 8, VIV1, 8, VIV2, 8, VIV3, 8, VIV4, 8, VIV5, 8, VIV6, 8, VIV7, 8, Offset (0x29), TPI1, 8, TPI2, 8, TPI3, 8, Offset (0x80), FTC4, 8, EFN4, 8, FTC5, 8, EFN5, 8 } } Scope (\) { Field (RAMW, ByteAcc, NoLock, Preserve) { Offset (0x20), CPUQ, 8, CPVL, 16, CPVH, 16, CPVC, 1 } } Scope (_SB.PCI0.SBRG.ASOC) { Name (CORV, Package (0x05) { 0x06020000, "Vcore Voltage", 0x0352, 0x0640, One }) Name (V3VV, Package (0x05) { 0x06020001, " +3.3 Voltage", 0x0B9A, 0x0E2E, One }) Name (V5VV, Package (0x05) { 0x06020002, " +5 Voltage", 0x1194, 0x157C, One }) Name (VV12, Package (0x05) { 0x06020003, " +12 Voltage", 0x27D8, 0x35E8, One }) Name (VPAR, Package (0x04) { Package (0x03) { Zero, One, Zero }, Package (0x03) { Zero, One, Zero }, Package (0x03) { 0x22, 0x32, Zero }, Package (0x03) { 0x32, 0x11, Zero } }) Name (VBUF, Package (0x05) { 0x04, CORV, V3VV, V5VV, VV12 }) Method (VGET, 1, NotSerialized) { If (LEqual (Arg0, Zero)) { Return (^^SIOR.HWV0 ()) } If (LEqual (Arg0, One)) { Return (^^SIOR.HWV1 ()) } If (LEqual (Arg0, 0x02)) { Return (^^SIOR.HWV3 ()) } If (LEqual (Arg0, 0x03)) { Return (^^SIOR.HWV4 ()) } } Name (CPUT, Package (0x05) { 0x06030000, "CPU Temperature", 0x0258, 0x03B6, 0x00010001 }) Name (MBTP, Package (0x05) { 0x06030001, "MB Temperature", 0x01C2, 0x03B6, 0x00010001 }) Name (TBUF, Package (0x03) { 0x02, CPUT, MBTP }) Method (TGET, 1, NotSerialized) { If (LEqual (Arg0, Zero)) { Return (^^SIOR.HWT1 ()) } If (LEqual (Arg0, One)) { Return (^^SIOR.HWT2 ()) } } Name (CPUF, Package (0x05) { 0x06040000, "CPU FAN Speed", 0x0320, 0x1C20, 0x00010001 }) Name (CHAF, Package (0x05) { 0x06040001, "CHASSIS FAN Speed", 0x04B0, 0x1C20, 0x00010001 }) Name (CHF2, Package (0x05) { 0x06040002, "CHASSIS FAN 2 Speed", 0x0320, 0x1C20, 0x00010001 }) Name (CHF3, Package (0x05) { 0x06040003, "CHASSIS FAN 3 Speed", 0x0320, 0x1C20, 0x00010001 }) Name (PWRF, Package (0x05) { 0x06040004, "POWER FAN Speed", 0x0708, 0x1C20, 0x00010001 }) Name (FBUF, Package (0x06) { 0x05, CPUF, CHAF, CHF2, CHF3, PWRF }) Method (FGET, 1, NotSerialized) { If (LEqual (Arg0, Zero)) { Return (^^SIOR.HWF1 ()) } If (LEqual (Arg0, One)) { Return (^^SIOR.HWF2 ()) } If (LEqual (Arg0, 0x02)) { Return (^^SIOR.HWF3 ()) } If (LEqual (Arg0, 0x03)) { Return (^^SIOR.HWF5 ()) } If (LEqual (Arg0, 0x04)) { Return (^^SIOR.HWF4 ()) } } Name (QCFN, Package (0x06) { 0x04060003, "CPU Q-Fan Control", Zero, One, 0x02, 0x00010000 }) Name (QBUF, Package (0x02) { One, QCFN }) Method (VSIF, 0, NotSerialized) { Return (VBUF) } Method (RVLT, 1, NotSerialized) { And (Arg0, 0xFFFF, Local0) Store (VGET (Local0), Local1) Store (DerefOf (Index (DerefOf (Index (VPAR, Local0)), Zero)), Local2) Store (DerefOf (Index (DerefOf (Index (VPAR, Local0)), One)), Local3) Store (DerefOf (Index (DerefOf (Index (VPAR, Local0)), 0x02)), Local4) Multiply (Local1, Add (Local2, Local3), Local5) Divide (Local5, Local3, , Local5) Add (Local5, Local4, Local5) Return (Local5) } Method (SVLT, 1, NotSerialized) { And (DerefOf (Index (Arg0, Zero)), 0xFFFF, Local0) Store (DerefOf (Index (VBUF, Zero)), Local1) If (LGreaterEqual (Local0, Local1)) { Return (Zero) } Increment (Local0) Store (DerefOf (Index (Arg0, One)), Index (DerefOf (Index (VBUF, Local0)), One)) Store (DerefOf (Index (Arg0, 0x02)), Index (DerefOf (Index (VBUF, Local0)), 0x02)) Store (DerefOf (Index (Arg0, 0x03)), Index (DerefOf (Index (VBUF, Local0)), 0x03)) Store (DerefOf (Index (Arg0, 0x04)), Index (DerefOf (Index (VBUF, Local0)), 0x04)) Return (One) } Method (TSIF, 0, NotSerialized) { Return (TBUF) } Method (RTMP, 1, NotSerialized) { And (Arg0, 0xFFFF, Local0) Store (TGET (Local0), Local1) Return (Local1) } Method (STMP, 1, NotSerialized) { Store (And (DerefOf (Index (Arg0, Zero)), 0xFFFF), Local0) Store (DerefOf (Index (TBUF, Zero)), Local1) If (LGreaterEqual (Local0, Local1)) { Return (Zero) } Increment (Local0) Store (DerefOf (Index (Arg0, One)), Index (DerefOf (Index (TBUF, Local0)), One)) Store (DerefOf (Index (Arg0, 0x02)), Index (DerefOf (Index (TBUF, Local0)), 0x02)) Store (DerefOf (Index (Arg0, 0x03)), Index (DerefOf (Index (TBUF, Local0)), 0x03)) Store (DerefOf (Index (Arg0, 0x04)), Index (DerefOf (Index (TBUF, Local0)), 0x04)) Return (One) } Method (FSIF, 0, NotSerialized) { Return (FBUF) } Method (RFAN, 1, NotSerialized) { And (Arg0, 0xFFFF, Local0) Store (FGET (Local0), Local1) Return (Local1) } Method (SFAN, 1, NotSerialized) { And (DerefOf (Index (Arg0, Zero)), 0xFFFF, Local0) Store (DerefOf (Index (FBUF, Zero)), Local1) If (LGreaterEqual (Local0, Local1)) { Return (Zero) } Increment (Local0) Store (DerefOf (Index (Arg0, One)), Index (DerefOf (Index (FBUF, Local0)), One)) Store (DerefOf (Index (Arg0, 0x02)), Index (DerefOf (Index (FBUF, Local0)), 0x02)) Store (DerefOf (Index (Arg0, 0x03)), Index (DerefOf (Index (FBUF, Local0)), 0x03)) Store (DerefOf (Index (Arg0, 0x04)), Index (DerefOf (Index (FBUF, Local0)), 0x04)) Return (One) } Method (QFIF, 0, NotSerialized) { If (LEqual (CPUQ, Zero)) { And (DerefOf (Index (QCFN, 0x05)), 0xFFFDFFFF, Local0) Store (Local0, Index (QCFN, 0x05)) } Else { Or (DerefOf (Index (QCFN, 0x05)), 0x00020000, Local0) Store (Local0, Index (QCFN, 0x05)) } Return (QBUF) } Method (GCQV, 1, NotSerialized) { If (LEqual (Arg0, Zero)) { Return (CPVL) } If (LEqual (Arg0, One)) { Return (CPVH) } If (LEqual (Arg0, 0x02)) { Return (CPVC) } Return (Zero) } Method (QFST, 1, NotSerialized) { If (LEqual (Arg0, DerefOf (Index (QCFN, Zero)))) { Return (CQST) } Return (Zero) } } Scope (_SB) { Scope (PCI0) { Name (CRS, ResourceTemplate () { WordBusNumber (ResourceProducer, MinFixed, MaxFixed, PosDecode, 0x0000, // Granularity 0x0000, // Range Minimum 0x00FF, // Range Maximum 0x0000, // Translation Offset 0x0100, // Length ,, ) IO (Decode16, 0x0CF8, // Range Minimum 0x0CF8, // Range Maximum 0x01, // Alignment 0x08, // Length ) WordIO (ResourceProducer, MinFixed, MaxFixed, PosDecode, EntireRange, 0x0000, // Granularity 0x0000, // Range Minimum 0x0CF7, // Range Maximum 0x0000, // Translation Offset 0x0CF8, // Length ,, , TypeStatic) WordIO (ResourceProducer, MinFixed, MaxFixed, PosDecode, EntireRange, 0x0000, // Granularity 0x0D00, // Range Minimum 0xFFFF, // Range Maximum 0x0000, // Translation Offset 0xF300, // Length ,, , TypeStatic) DWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, Cacheable, ReadWrite, 0x00000000, // Granularity 0x000A0000, // Range Minimum 0x000BFFFF, // Range Maximum 0x00000000, // Translation Offset 0x00020000, // Length ,, , AddressRangeMemory, TypeStatic) DWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, Cacheable, ReadWrite, 0x00000000, // Granularity 0x000C0000, // Range Minimum 0x000DFFFF, // Range Maximum 0x00000000, // Translation Offset 0x00020000, // Length ,, _Y23, AddressRangeMemory, TypeStatic) DWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, Cacheable, ReadWrite, 0x00000000, // Granularity 0x00000000, // Range Minimum 0x00000000, // Range Maximum 0x00000000, // Translation Offset 0x00000000, // Length ,, _Y24, AddressRangeMemory, TypeStatic) DWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, Cacheable, ReadWrite, 0x00000000, // Granularity 0x00000000, // Range Minimum 0x00000000, // Range Maximum 0x00000000, // Translation Offset 0x00000000, // Length ,, _Y25, AddressRangeMemory, TypeStatic) }) CreateDWordField (CRS, \_SB.PCI0._Y23._MIN, MIN5) CreateDWordField (CRS, \_SB.PCI0._Y23._MAX, MAX5) CreateDWordField (CRS, \_SB.PCI0._Y23._LEN, LEN5) CreateDWordField (CRS, \_SB.PCI0._Y24._MIN, MIN6) CreateDWordField (CRS, \_SB.PCI0._Y24._MAX, MAX6) CreateDWordField (CRS, \_SB.PCI0._Y24._LEN, LEN6) CreateDWordField (CRS, \_SB.PCI0._Y25._MIN, MIN7) CreateDWordField (CRS, \_SB.PCI0._Y25._MAX, MAX7) CreateDWordField (CRS, \_SB.PCI0._Y25._LEN, LEN7) Method (_CRS, 0, NotSerialized) { Store (MG1L, Local0) If (Local0) { Store (MG1B, MIN5) Store (MG1L, LEN5) Add (MIN5, Decrement (Local0), MAX5) } Store (MG2B, MIN6) Store (MG2L, LEN6) Store (MG2L, Local0) Add (MIN6, Decrement (Local0), MAX6) Store (MG3B, MIN7) Store (MG3L, LEN7) Store (MG3L, Local0) Add (MIN7, Decrement (Local0), MAX7) Return (CRS) } } } Name (WOTB, Zero) Name (WSSB, Zero) Name (WAXB, Zero) Method (_PTS, 1, NotSerialized) { Store (Arg0, DBG8) PTS (Arg0) Store (Zero, Index (WAKP, Zero)) Store (Zero, Index (WAKP, One)) If (LAnd (LEqual (Arg0, 0x04), LEqual (OSFL (), 0x02))) { Sleep (0x0BB8) } Store (ASSB, WSSB) Store (AOTB, WOTB) Store (AAXB, WAXB) Store (Arg0, ASSB) Store (OSFL (), AOTB) Store (Zero, AAXB) } Method (_WAK, 1, NotSerialized) { ShiftLeft (Arg0, 0x04, DBG8) WAK (Arg0) If (ASSB) { Store (WSSB, ASSB) Store (WOTB, AOTB) Store (WAXB, AAXB) } If (DerefOf (Index (WAKP, Zero))) { Store (Zero, Index (WAKP, One)) } Else { Store (Arg0, Index (WAKP, One)) } Return (WAKP) } Device (_SB.PCI0.SBRG.TPM) { Name (_HID, EisaId ("PNP0C31")) Name (_CID, 0x310CD041) Name (_UID, One) Name (_CRS, ResourceTemplate () { Memory32Fixed (ReadWrite, 0xFED40000, // Address Base 0x00005000, // Address Length ) }) Method (_STA, 0, NotSerialized) { If (_OSI ("Windows 2006")) { If (TPMF) { Return (0x0F) } Else { Return (Zero) } } Else { Return (Zero) } } } Scope (_SB.PCI0.SBRG.TPM) { Name (TAAX, Zero) OperationRegion (MIPT, SystemIO, SMIT, One) Field (MIPT, ByteAcc, NoLock, Preserve) { PSMI, 8 } Name (PPI1, Package (0x02) { Zero, Zero }) Name (PPI2, Package (0x03) { Zero, Zero, Zero }) Name (MBUF, Buffer (0x04) {}) CreateByteField (MBUF, Zero, BUF0) CreateByteField (MBUF, One, BUF1) CreateByteField (MBUF, 0x02, BUF2) CreateByteField (MBUF, 0x03, BUF3) Method (_DSM, 4, NotSerialized) { If (LEqual (Arg0, Buffer (0x10) { /* 0000 */ 0xA6, 0xFA, 0xDD, 0x3D, 0x1B, 0x36, 0xB4, 0x4E, /* 0008 */ 0xA4, 0x24, 0x8D, 0x10, 0x08, 0x9D, 0x16, 0x53 })) { Name (_T_0, Zero) Store (ToInteger (Arg2), _T_0) If (LEqual (_T_0, Zero)) { Return (Buffer (One) { 0x7F }) } Else { If (LEqual (_T_0, One)) { Return ("1.0") } Else { If (LEqual (_T_0, 0x02)) { Store (AAXB, TAAX) Store (CMRQ, BUF0) Store (0xF0, BUF1) Store (ToInteger (DerefOf (Index (Arg3, Zero))), BUF2) Store (One, BUF3) Store (MBUF, AAXB) Store (0xFB, PSMI) Sleep (0x0BB8) Store (TAAX, AAXB) Return (Zero) } Else { If (LEqual (_T_0, 0x03)) { Store (AAXB, TAAX) Store (CMRQ, BUF0) Store (0x0F, BUF1) Store (Zero, BUF2) Store (Zero, BUF3) Store (MBUF, AAXB) Store (0xFB, PSMI) Sleep (0x0BB8) Store (AAXB, MBUF) Store (BUF2, Local3) Store (Zero, Index (PPI1, Zero)) Store (Local3, Index (PPI1, One)) Store (TAAX, AAXB) Return (PPI1) } Else { If (LEqual (_T_0, 0x04)) { Return (0x02) } Else { If (LEqual (_T_0, 0x05)) { Store (AAXB, TAAX) Store (CMRQ, BUF0) Store (0xF0, BUF1) Store (Zero, BUF2) Store (Zero, BUF3) Store (MBUF, AAXB) Store (0xFB, PSMI) Sleep (0x0BB8) Store (AAXB, MBUF) ShiftRight (BUF2, 0x04) Store (BUF2, Local3) Store (CMER, BUF0) Store (0xFF, BUF1) Store (Zero, BUF2) Store (Zero, BUF3) Store (MBUF, AAXB) Store (0xFB, PSMI) Sleep (0x0BB8) Store (AAXB, MBUF) Store (BUF2, Local6) Add (CMER, One, Local4) Store (Local4, BUF0) Store (0xFF, BUF1) Store (Zero, BUF2) Store (Zero, BUF3) Store (MBUF, AAXB) Store (0xFB, PSMI) Sleep (0x0BB8) Store (AAXB, MBUF) Store (BUF2, Local7) Multiply (Local7, 0x0100, Local2) Add (Local2, Local6, Local2) Store (Zero, Index (PPI2, Zero)) Store (Local3, Index (PPI2, One)) If (LEqual (Local2, 0xFFF0)) { Store (0xFFFFFFF0, Index (PPI2, 0x02)) } Else { If (LEqual (Local2, 0xFFF1)) { Store (0xFFFFFFF1, Index (PPI2, 0x02)) } Else { Store (Local2, Index (PPI2, 0x02)) } } Store (TAAX, AAXB) Return (PPI2) } Else { If (LEqual (_T_0, 0x06)) { Return (Zero) } Else { } } } } } } } } Else { If (LEqual (Arg0, Buffer (0x10) { /* 0000 */ 0xED, 0x54, 0x60, 0x37, 0x13, 0xCC, 0x75, 0x46, /* 0008 */ 0x90, 0x1C, 0x47, 0x56, 0xD7, 0xF2, 0xD4, 0x5D })) { Name (_T_1, Zero) Store (ToInteger (Arg2), _T_1) If (LEqual (_T_1, Zero)) { Return (Buffer (One) { 0x03 }) } Else { If (LEqual (_T_1, One)) { Store (AAXB, TAAX) Store (CMOR, BUF0) Store (0xFE, BUF1) Store (ToInteger (DerefOf (Index (Arg3, Zero))), BUF2) Store (One, BUF3) Store (MBUF, AAXB) Store (0xFB, PSMI) Sleep (0x0BB8) Store (TAAX, AAXB) Return (Zero) } Else { } } } } Return (Buffer (One) { 0x00 }) } } Name (_S0, Package (0x04) { Zero, Zero, Zero, Zero }) If (SS1) { Name (_S1, Package (0x04) { One, Zero, Zero, Zero }) } If (SS3) { Name (_S3, Package (0x04) { 0x05, Zero, Zero, Zero }) } If (SS4) { Name (_S4, Package (0x04) { 0x06, Zero, Zero, Zero }) } Name (_S5, Package (0x04) { 0x07, Zero, Zero, Zero }) Method (PTS, 1, NotSerialized) { If (Arg0) { \_SB.PCI0.SBRG.SIOS (Arg0) \_SB.PCI0.NPTS (Arg0) \_SB.PCI0.SBRG.SPTS (Arg0) } } Method (WAK, 1, NotSerialized) { \_SB.PCI0.SBRG.SIOW (Arg0) \_SB.PCI0.NWAK (Arg0) \_SB.PCI0.SBRG.SWAK (Arg0) } } Thank you Sam Fourman Jr. From owner-freebsd-current@FreeBSD.ORG Sun Jun 14 15:44:29 2009 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 244621065672 for ; Sun, 14 Jun 2009 15:44:29 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-ew0-f212.google.com (mail-ew0-f212.google.com [209.85.219.212]) by mx1.freebsd.org (Postfix) with ESMTP id A01C08FC20 for ; Sun, 14 Jun 2009 15:44:28 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by ewy8 with SMTP id 8so3623899ewy.43 for ; Sun, 14 Jun 2009 08:44:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=pc79JvGBe/ai1nzwBTc0FA08usZx6bS+sA4xyQAgr1I=; b=XVozopWn6+zm1uOEl8OkW9I+loQuD9uqyzStFHHPkQIyJOZHf5Nsm98cyvFzChIRBi pPcLO/DyI9B6aui/jgZNC/LrtwhIMwE43Dtv5izWvET2hCxvZxdWpxtwY5q5TFR34N2c yM+A+5xyHE3ykRcHAH8ESzkVSHx6V6WsWfXVY= 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; b=GKdOm/hb+NrJjIkpVctbo1e7u8gmWIT0Yxgf5c2CHq/HmkGj1Gu6Y4Y4bTf2TaDVXn GA2/OP7j+wLrgbCwxP1qZaXwvXVtF8hL17zRC6kyTvtJRl9BMCDl3JylOOp+IgmJvn54 y7qauGdiUMvI755IPzSH+j0KrJ1+ul7QIvEts= Received: by 10.211.195.15 with SMTP id x15mr3396034ebp.18.1244992438633; Sun, 14 Jun 2009 08:13:58 -0700 (PDT) Received: from gmail.com (sdferwer192.net.autocom.pl [77.236.1.49]) by mx.google.com with ESMTPS id 24sm416918eyx.33.2009.06.14.08.13.54 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 14 Jun 2009 08:13:57 -0700 (PDT) Date: Sun, 14 Jun 2009 17:13:46 +0200 From: Mateusz Guzik To: Alexander Best Message-ID: <20090614151343.GA89156@skucha.lan> References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) Cc: freebsd-current@freebsd.org Subject: Re: linux syscall get_robust_list causes 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: Sun, 14 Jun 2009 15:44:29 -0000 On Sun, Jun 14, 2009 at 04:27:45PM +0200, Alexander Best wrote: > hi there, > > i tried to run the latest release (20090531) of the linux test project (ltp) > with emulators/linux_dist-gentoo-stage3. however the kernel panics after ltp's > get_robust_list(2) test. set_robust_list(2) passes without any problems. > > i've attached a screenshot of the panic and the source which is causing the > panic. you won't be able to compile it without ltp however. after installing > and compiling ltp the source and the executable can be found in > "/usr/local/gentoo-stage3/ltp-full-20090531/testcases/kernel/syscalls/get_robust_list". > simply running the > "/usr/local/gentoo-stage3/ltp-full-20090531/testcases/kernel/syscalls/get_robust_list/get_robust_list01" > executable results in a panic. > > unfortunately i cannot supply a complete bt, because i only own a usb keyboard > which doesn't respond after the panic. actually i'm a bit surprised the > debugger was started, because i have "KDB_UNATTENDED" in my kernel conf. any > reason the machine doesn't reboot and save the dump to /var/crash/vmcore.*? > > i'm running r193846 (CURRENT). > > cheers. Just a guess: it looks like linux_get_robust_list can return EPERM without unlocking process found by pfind. Can you add PROC_UNLOCK(p) before that return and check it? Unfortunately I can't do that right now. -- Mateusz Guzik From owner-freebsd-current@FreeBSD.ORG Sun Jun 14 15:48:39 2009 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 A011C106564A for ; Sun, 14 Jun 2009 15:48:39 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-bw0-f228.google.com (mail-bw0-f228.google.com [209.85.218.228]) by mx1.freebsd.org (Postfix) with ESMTP id 2A8B68FC16 for ; Sun, 14 Jun 2009 15:48:38 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by bwz28 with SMTP id 28so182467bwz.43 for ; Sun, 14 Jun 2009 08:48:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=SYMczojsRK+xqe3ekbKYTgELY03B2lkJCXNwk/iMyII=; b=igJuiu7eKkQ3imqr0FuV8Ufc6wo5oY0DUTGYBMK8LtzJ+6lxX2yXASximO3aVE81fQ UGSwIq75wkMitsIovoZSn9VoIcj52fQcyflpDk60EI+VuTZ+gdwddzYID5qHbUysNlWP l+3rYCsuVp8VNE1YNjbSr+tUwQEaUbXyxZiuo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=FqMzXvrX/4k6v2Q2HGXzGQUnXTetrbvpx96ahYaS5I3EJ7KJcXDN7f0vng1smpLqjy AR7/UsRRGFL3BY92GhOHf1afyEA3iCwoA9o4h5MnM3c9Ycn+5l+u3Uhm7LFgm6HzcbaA cEfoAIuzDyz7joks/6z23A0ZZ+Z5LuEo2LhMo= MIME-Version: 1.0 Received: by 10.204.31.75 with SMTP id x11mr6051132bkc.0.1244994518180; Sun, 14 Jun 2009 08:48:38 -0700 (PDT) In-Reply-To: <11167f520906140109s52df389ode319bfded32613c@mail.gmail.com> References: <11167f520906140109s52df389ode319bfded32613c@mail.gmail.com> Date: Sun, 14 Jun 2009 17:48:38 +0200 Message-ID: <3a142e750906140848lbe51ed2tbf45d00ecc36ca84@mail.gmail.com> From: "Paul B. Mahol" To: "Sam Fourman Jr." Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: FreeBSD 8.0 Asus P5N64 WS Professional ACPI error 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, 14 Jun 2009 15:48:39 -0000 On 6/14/09, Sam Fourman Jr. wrote: > hello, > > I am putting this information out there for archival pourposes, but I > was wondering if someone would know how to fix this error in the dmesg > I am not sure if this is somthing to worry about or not. > > atrtc1: port 0x70-0x71 on acpi0 > cpu0: on acpi0 > ACPI Warning (tbutils-0243): Incorrect checksum in table [OEMB] - D6, > should be CE [20070320] > > > here is a link to the motherboard > http://www.asus.com/product.aspx?P_ID=o5ztautLyFiNMFcJ&templete=2 > > # dmesg > Copyright (c) 1992-2009 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 8.0-CURRENT #2: Mon Apr 13 18:21:46 CDT 2009 Recent CURRENT have newer acpica 20090521. -- Paul From owner-freebsd-current@FreeBSD.ORG Sun Jun 14 15:49:43 2009 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 757271065670; Sun, 14 Jun 2009 15:49:43 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello087206192061.chello.pl [87.206.192.61]) by mx1.freebsd.org (Postfix) with ESMTP id ADD7D8FC20; Sun, 14 Jun 2009 15:49:42 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id B3FEC45E9C; Sun, 14 Jun 2009 17:49:39 +0200 (CEST) Received: from localhost (chello087206192061.chello.pl [87.206.192.61]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 5D16F4569A; Sun, 14 Jun 2009 17:49:34 +0200 (CEST) Date: Sun, 14 Jun 2009 17:49:38 +0200 From: Pawel Jakub Dawidek To: "James R. Van Artsdalen" Message-ID: <20090614154938.GC1848@garage.freebsd.pl> References: <920A69B1-4F06-477E-A13B-63CC22A13120@exscape.org> <3c1674c90906121401s19105167vf4535566321b45de@mail.gmail.com> <20090613150627.GB1848@garage.freebsd.pl> <4A3411EF.5000307@jrv.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mvpLiMfbWzRoNl4x" Content-Disposition: inline In-Reply-To: <4A3411EF.5000307@jrv.org> 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=4.5 tests=BAYES_00,RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: freebsd-fs@FreeBSD.org, Kip Macy , FreeBSD Current , Thomas Backman Subject: Re: ZFS: Silent/hidden errors, nothing logged anywhere 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, 14 Jun 2009 15:49:44 -0000 --mvpLiMfbWzRoNl4x Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jun 13, 2009 at 03:54:07PM -0500, James R. Van Artsdalen wrote: > Pawel Jakub Dawidek wrote: > > > > We do log such errors. Solaris uses FMA and for FreeBSD I use devd. You > > can find the following entry in /etc/devd.conf: > > > > notify 10 { > > match "system" "ZFS"; > > match "type" "checksum"; > > action "logger -p kern.warn 'ZFS: checksum mismatch, zpool=3D$p= ool path=3D$vdev_path offset=3D$zio_offset size=3D$zio_size'"; > > }; > > > > If you see nothing in your logs, there must be a bug with reporting the > > problem somewhere or devd is not running (it should be enabled by > > default). > > =20 >=20 > Looking at vsyslog(3), I don't think logger(1) can ever log with > facility KERN. LOG_KERN is 0, so this in vsyslog >=20 > /* Set default facility if none specified. */ > if ((pri & LOG_FACMASK) =3D=3D 0) > pri |=3D LogFacility; >=20 > will always change the KERN facility is to LogFacility, which defaults > to LOG_USER. > =20 > So the devd output is really going to user.warn and a syslog.conf line li= ke >=20 > kern.* /var/log/kernel.log >=20 > will capture kernel messages, but not the devd logger output, and if you > look in kernel.log you won't find the checksum errors. Could be, I'm most of the time just use *.* /var/log/all.log. We could easly log directly from inside the kernel, but this is just an example devd entry so one can replace it with, eg. mailing the problem to the system administrator or whatever. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --mvpLiMfbWzRoNl4x Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFKNRwSForvXbEpPzQRAlJwAKC/wgqzMzX+/LO2A4YqY8Rm6DAk6ACgrgQh ONb32i62rHj7RVg8J8PwZrE= =OCAq -----END PGP SIGNATURE----- --mvpLiMfbWzRoNl4x-- From owner-freebsd-current@FreeBSD.ORG Sun Jun 14 15:44:41 2009 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 AD1421065702; Sun, 14 Jun 2009 15:44:41 +0000 (UTC) (envelope-from trond@fagskolen.gjovik.no) Received: from ramstind.fig.ol.no (smtp.fagskolen.gjovik.no [IPv6:2001:700:1100:1:250:4ff:fe43:9d15]) by mx1.freebsd.org (Postfix) with ESMTP id 1B4F28FC1C; Sun, 14 Jun 2009 15:44:40 +0000 (UTC) (envelope-from trond@fagskolen.gjovik.no) Received: from ramstind.fig.ol.no (trond@localhost [127.0.0.1]) by ramstind.fig.ol.no (8.13.8/8.13.8) with ESMTP id n5EFiW2x034926 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 14 Jun 2009 17:44:32 +0200 (CEST) (envelope-from trond@fagskolen.gjovik.no) Received: from localhost (trond@localhost) by ramstind.fig.ol.no (8.13.8/8.13.8/Submit) with ESMTP id n5EFiWZ7034922; Sun, 14 Jun 2009 17:44:32 +0200 (CEST) (envelope-from trond@fagskolen.gjovik.no) X-Authentication-Warning: ramstind.fig.ol.no: trond owned process doing -bs Date: Sun, 14 Jun 2009 17:44:27 +0200 (CEST) From: =?ISO-8859-1?Q?Trond_Endrest=F8l?= Sender: Trond.Endrestol@fagskolen.gjovik.no To: freebsd-hackers@freebsd.org, FreeBSD current In-Reply-To: Message-ID: <20090614172116.C55547@ramstind.fig.ol.no> References: <4A2E84DC.1010900@unsane.co.uk> Organization: =?ISO-8859-1?Q?Fagskolen_i_Gj=F8vik?= OpenPGP: url=http://fagskolen.gjovik.no/~trond/trond.key MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1121150211-1244993917=:55547" Content-ID: <20090614173858.T55547@ramstind.fig.ol.no> X-Spam-Status: No, hits=-0.9 required=5.0 tests=AWL,BAYES_50 autolearn=ham X-Spam-Checker-Version: SpamAssassin on ramstind.fig.ol.no X-Mailman-Approved-At: Sun, 14 Jun 2009 16:02:28 +0000 Cc: Subject: Re: sysinstall, GJOURNAL and ZFS 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, 14 Jun 2009 15:44:42 -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. --0-1121150211-1244993917=:55547 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1 Content-Transfer-Encoding: 8BIT Content-ID: <20090614173858.M55547@ramstind.fig.ol.no> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sat, 13 Jun 2009 01:07+0300, Dan Naumov wrote: > screen: The screen states that in order to do a > manual installation " login as root, and follow the instructions > given in the file /README". There is no indication regarding how the > user is supposed to open the README file, at least ONE sane option > should be suggested (for example: login as root and type "vi README" > at the command prompt to read the instructions regarding installing > FreeBSD manually. Although longer to type, "less /README" would be a better alternative than using vi to view the contents of the file. You could otherwise risk the user destroying the README file due to unfamiliarity with this particular editor. OTOH, why not adopt OpenBSD's afterboot(8) man page? === Almost completely off-topic: An /altroot mechanism would be nice to have in FreeBSD. ;-) There are at least two schools of thought regarding /altroot. One school of thought would be to simply dd the contents of the root partition on to the altroot partition and run fsck on /altroot, assuming /root and /altroot have the same size. I believe this is how OpenBSD handles /altroot when configured to do so. My school of thought, given a system with more than one hard drive, physical or virtual (as in RAID volumes), is to have /altroot appear as a regular root file system (partition a) on the other drive and thus being able to (manually) boot from the available root file system. Both hard drives should be made bootable with the EasyBoot loader placed in the MBRs and with regular boot blocks in the FreeBSD slices. Of course, /altroot should normally remain unmounted. There is also the possible need of having /etc/fstab files with specific contents for each root file system. For instance, /'s /altroot should be mounted as /altroot's /. I'm not sure how to handle this scenario with either installers as you probably need to perform the installation twice, that's how I did it on a couple of recently installed systems, not to mention how to handle make install{kernel,world} for both of the two root file systems. Just some random thoughts, Trond. - -- - ---------------------------------------------------------------------- Trond Endrestøl | Trond.Endrestol@fagskolen.gjovik.no ACM, NAS, NUUG, SAGE, USENIX | FreeBSD 6.2-STABLE & Pine 4.64 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFKNRrfbYWZalUoElsRAnzTAJ0StVu1t2FY1rr9JjI2MVQ0jexsAgCfZICv kbpbqm4Vzv/vGYVTZEPwmfw= =dPhW -----END PGP SIGNATURE----- --0-1121150211-1244993917=:55547-- From owner-freebsd-current@FreeBSD.ORG Sun Jun 14 16:06:38 2009 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 292FE106566C for ; Sun, 14 Jun 2009 16:06:38 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from ch-smtp01.sth.basefarm.net (ch-smtp01.sth.basefarm.net [80.76.149.212]) by mx1.freebsd.org (Postfix) with ESMTP id D15EC8FC19 for ; Sun, 14 Jun 2009 16:06:37 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from c83-253-252-234.bredband.comhem.se ([83.253.252.234]:57875 helo=mx.exscape.org) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.69) (envelope-from ) id 1MFsE4-0002II-6C; Sun, 14 Jun 2009 18:06:34 +0200 Received: from [192.168.1.5] (macbookpro [192.168.1.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx.exscape.org (Postfix) with ESMTPSA id B3D72699EF; Sun, 14 Jun 2009 18:06:01 +0200 (CEST) Message-Id: <7CE0A11C-217A-41D9-8A99-179A5BB838E7@exscape.org> From: Thomas Backman To: =?ISO-8859-1?Q?Trond_Endrest=F8l?= In-Reply-To: <20090614172116.C55547@ramstind.fig.ol.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sun, 14 Jun 2009 18:05:59 +0200 References: <4A2E84DC.1010900@unsane.co.uk> <20090614172116.C55547@ramstind.fig.ol.no> X-Mailer: Apple Mail (2.935.3) X-Originating-IP: 83.253.252.234 X-Scan-Result: No virus found in message 1MFsE4-0002II-6C. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1MFsE4-0002II-6C e6a06719fa3728ad15866b5aaf3638a7 Cc: freebsd-hackers@freebsd.org, FreeBSD current Subject: Re: sysinstall, GJOURNAL and ZFS 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, 14 Jun 2009 16:06:38 -0000 On Jun 14, 2009, at 05:44 PM, Trond Endrest=F8l wrote: > > Although longer to type, "less /README" would be a better alternative > than using vi to view the contents of the file. You could otherwise > risk the user destroying the README file due to unfamiliarity with > this particular editor. I'd say the bigger risk is that the user goes "what the heck is =20 this?!" and gives up, not even managing to quit vi. ;) (Been there, done that! I'm an avid vim user now, but sure wasn't five =20= years ago.) Regards, Thomas= From owner-freebsd-current@FreeBSD.ORG Sun Jun 14 16:56:13 2009 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 151B51065672; Sun, 14 Jun 2009 16:56:13 +0000 (UTC) (envelope-from tmclaugh@sdf.lonestar.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id EEEAE8FC08; Sun, 14 Jun 2009 16:56:12 +0000 (UTC) (envelope-from tmclaugh@sdf.lonestar.org) Received: from straycat.dhs.org (tmclaugh@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n5EGuBh8095442; Sun, 14 Jun 2009 16:56:12 GMT (envelope-from tmclaugh@sdf.lonestar.org) Received: from tomcat.straycat.dhs.org (tomcat.straycat.dhs.org [192.168.3.130]) by straycat.dhs.org (8.14.1/8.14.1) with ESMTP id n5EGti2w003570; Sun, 14 Jun 2009 12:55:44 -0400 (EDT) Message-ID: <4A352B8B.3080104@sdf.lonestar.org> Date: Sun, 14 Jun 2009 12:55:39 -0400 From: Tom McLaughlin User-Agent: Thunderbird 2.0.0.21 (X11/20090320) MIME-Version: 1.0 To: Jack Vogel References: <20090606162235.GA49444@triton.kn-bremen.de> <2a41acea0906091104q17aeb174l8a34bf7464a80509@mail.gmail.com> <20090609195141.GA4982@triton.kn-bremen.de> <2a41acea0906091412k4fc58f4dt2c4ebbbb6dbd46dd@mail.gmail.com> In-Reply-To: <2a41acea0906091412k4fc58f4dt2c4ebbbb6dbd46dd@mail.gmail.com> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-emulation@freebsd.org, freebsd-current@freebsd.org, Juergen Lock Subject: Re: flash10 vs f10; em(4) now broken in -current in qemu/vbox 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, 14 Jun 2009 16:56:13 -0000 Jack Vogel wrote, On 06/09/2009 05:12 PM: > Your change would work, but as its shared code and there are other OS's and > their issues to worry about, what I am going to do is a bit different. I am > including > a patch if you would try this now, there will be a full driver update soon. > > Anyone set up to test this please post your results here. > > Cheers, > > Jack > Thanks for the patch Jack. My em device on VMware ESXi 3.5u4 is back again. :) tom -- | tmclaugh at sdf.lonestar.org tmclaugh at FreeBSD.org | | FreeBSD http://www.FreeBSD.org | From owner-freebsd-current@FreeBSD.ORG Sun Jun 14 17:55:26 2009 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 853011065678 for ; Sun, 14 Jun 2009 17:55:26 +0000 (UTC) (envelope-from dchagin@dchagin.static.corbina.ru) Received: from contrabass.post.ru (contrabass.post.ru [85.21.78.5]) by mx1.freebsd.org (Postfix) with ESMTP id 2FA3E8FC0C for ; Sun, 14 Jun 2009 17:55:25 +0000 (UTC) (envelope-from dchagin@dchagin.static.corbina.ru) Received: from corbina.ru (mail.post.ru [195.14.50.16]) by contrabass.post.ru (Postfix) with ESMTP id 47C15A36AF; Sun, 14 Jun 2009 21:55:24 +0400 (MSD) X-Virus-Scanned: by cgpav Uf39PSi9pFi9oFi9 Received: from [10.208.17.3] (HELO dchagin.static.corbina.ru) by corbina.ru (CommuniGate Pro SMTP 5.1.14) with ESMTPS id 1829589851; Sun, 14 Jun 2009 21:55:24 +0400 Received: from dchagin.static.corbina.ru (localhost.chd.net [127.0.0.1]) by dchagin.static.corbina.ru (8.14.3/8.14.3) with ESMTP id n5EHtNVt028711; Sun, 14 Jun 2009 21:55:23 +0400 (MSD) (envelope-from dchagin@dchagin.static.corbina.ru) Received: (from dchagin@localhost) by dchagin.static.corbina.ru (8.14.3/8.14.3/Submit) id n5EHtIU3028710; Sun, 14 Jun 2009 21:55:18 +0400 (MSD) (envelope-from dchagin) Date: Sun, 14 Jun 2009 21:55:18 +0400 From: Chagin Dmitry To: Alexander Best Message-ID: <20090614175518.GA28675@dchagin.static.corbina.ru> References: <20090614151717.GA26276@dchagin.static.corbina.ru> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GvXjxJ+pjyke8COw" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) Cc: freebsd-current@freebsd.org Subject: Re: linux syscall get_robust_list causes 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: Sun, 14 Jun 2009 17:55:26 -0000 --GvXjxJ+pjyke8COw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jun 14, 2009 at 05:30:44PM +0200, Alexander Best wrote: > wow. >=20 > thanks for the fix. after applying the patch the panic no longer occurs. = great > job! :-) hope this'll make it into CURRENT quickly. ;) >=20 > cheers. >=20 commited (r194203). thnx! --=20 Have fun! chd --GvXjxJ+pjyke8COw Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (FreeBSD) iEYEARECAAYFAko1OYUACgkQ0t2Tb3OO/O3UFQCgk2BaaP2s5qDm/7YXkSr/HQ+L FwoAnRgOM+9lhnetz3FjgOSDB+5xiEAE =fag1 -----END PGP SIGNATURE----- --GvXjxJ+pjyke8COw-- From owner-freebsd-current@FreeBSD.ORG Sun Jun 14 18:15:07 2009 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 2CD02106567A; Sun, 14 Jun 2009 18:15:07 +0000 (UTC) (envelope-from geekounet@poildetroll.net) Received: from tritus.poildetroll.net (tritus.poildetroll.net [81.93.245.19]) by mx1.freebsd.org (Postfix) with ESMTP id DA6998FC13; Sun, 14 Jun 2009 18:15:06 +0000 (UTC) (envelope-from geekounet@poildetroll.net) Received: from korriban.poildetroll.net (kashyyyk.poildetroll.net [88.162.190.61]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tritus.poildetroll.net (Postfix) with ESMTPSA id 38C243C2; Sun, 14 Jun 2009 20:15:05 +0200 (CEST) Message-ID: <4A353E21.1080001@poildetroll.net> Date: Sun, 14 Jun 2009 20:14:57 +0200 From: Pierre Guinoiseau Organization: Poil de Troll User-Agent: Thunderbird 2.0.0.21 (X11/20090404) MIME-Version: 1.0 To: Attilio Rao References: <951233.95131.qm@web39108.mail.mud.yahoo.com> <3c1674c90905302055g542cfadarf201cc273639977d@mail.gmail.com> <4A23919F.8050905@mail.zedat.fu-berlin.de> <4A2B3040.7020509@poildetroll.net> <3bbf2fe10906070339k663bace7qe5142702248ce6c9@mail.gmail.com> <4A2BBDC0.6000801@poildetroll.net> <3bbf2fe10906070623o65ce021fkb7f59fe1924cc1ec@mail.gmail.com> In-Reply-To: <3bbf2fe10906070623o65ce021fkb7f59fe1924cc1ec@mail.gmail.com> X-Enigmail-Version: 0.95.7 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig34B997EAE9F179E61B9BAC6B" Cc: bf , "O. Hartmann" , freebsd-current@freebsd.org, Kip Macy Subject: Re: signifanctly slowdown of FreeBSD 8.0-CURRENT/amd64 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, 14 Jun 2009 18:15:07 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig34B997EAE9F179E61B9BAC6B Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi again, I don't know if it can be of better help or not, but I made 2 other dumps, before and after the slowdown, and without X running and all... I recompiled some packages several times to make the slowdown appear. The dumps are here : http://foo.poildetroll.net/freebsd/ktr/ Thanks again for your help! Pierre Guinoiseau Attilio Rao wrote: > 2009/6/7 Pierre Guinoiseau : >> Ok, here is a ktr output. This time, the slowdown appeared while >> recompiling thunderbird. I have 2 core at 2.2Ghz (and powerd running, = I >> don't know if it matters). >> >> BTW, what is the use of py-tkinter ? If it was in order to cause the >> bug, it failed, it needed a higher load. :) >=20 > Ah sorry, I was supposed to let you run schedgraph but I'm going to do > that, so you actually didn't need it > I will let you know if something cames up. > If others can report the same it will be great. >=20 > Thanks, > Attilio > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg" --------------enig34B997EAE9F179E61B9BAC6B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAko1PigACgkQJikNJSAyef9W/gCgu0P4TIhjkNp6vVlYtC8gL3UB rVkAnj1XdPWlH+Z8ycEYjL3qrQUygqqp =CLv6 -----END PGP SIGNATURE----- --------------enig34B997EAE9F179E61B9BAC6B-- From owner-freebsd-current@FreeBSD.ORG Sun Jun 14 18:22:04 2009 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 190FD10656C3 for ; Sun, 14 Jun 2009 18:22:04 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:7b8:613:100::211]) by mx1.freebsd.org (Postfix) with ESMTP id A2E648FC14 for ; Sun, 14 Jun 2009 18:22:03 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 9F5551CC2E; Sun, 14 Jun 2009 20:22:02 +0200 (CEST) Date: Sun, 14 Jun 2009 20:22:02 +0200 From: Ed Schouten To: Chuck Robey Message-ID: <20090614182202.GN48776@hoeg.nl> References: <20090604093831.GE48776@hoeg.nl> <20090608.120552.756910862.imp@bsdimp.com> <4A353D49.1050202@telenix.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="srAoGIOs8asUHz4E" Content-Disposition: inline In-Reply-To: <4A353D49.1050202@telenix.org> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: current@freebsd.org, "M. Warner Losh" Subject: Re: Clang: now available from a SVN server near you! 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, 14 Jun 2009 18:22:04 -0000 --srAoGIOs8asUHz4E Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Chuck, * Chuck Robey wrote: > I feel a bit like an idiot needing to ask this, but I downloaded the stuf= f on > llvm/clang, but I don't know the name of the directories, and I need to a= sk some > items. (Before someone kindly points this out, I've been running -current > fairly regularly since 1.0, and I'm completely aware that running current= is > very nearly completely a "run at your own risk" thing. I have a pretty g= ood > track record and being able to fix things, and I accept this risk just li= ke the > earlier ones). So, I need the next very few questions to help me on my w= ay: You're not being an idiot; it's something that I should mention somewhere anyway. > First is the complete set of llvm/clang code in that new src/cddl subdire= ctory? > I looked really hard for directories named either clang or llvm, and si= nce I > didn't find anything, is there anything like a README that explains what's > sitting where? I mean, stuff like what's in the currently available src/= README, > but in a little additional detail for the new llvm/clang stuff. This is = likely > stuff that others might be curious about also, those who didn't konw any = more > about llvm than I do. Because Clang could be integrated into the LLVM repository somewhere in the very far future, I just followed the existing practice of storing the Clang source tree inside the LLVM source directory. This is also done when building llvm-devel from Ports. Sources are stored at: contrib/llvm contrib/llvm/tools/clang Both source trees contain some small modifications, mainly related to changing the compiler's default include paths. The Makefiles I wrote are all stored in: usr.bin/clang Because LLVM and Clang consists of a lot of libraries, there is a lib/ subdirectory. I initially placed this directory at lib/clang, but the problem then is that the lib32 build on amd64 will also build the Clang libraries for nothing. I'm not entirely happy with the pathnames yet, but I think it's reasonable to work with. > Is the rest of the stuff I downloaded, the rest of that tree, being kept = up to > date with the rest of the FreeBSD-current's HEAD? Or, is that being held= for > llvm testing? BTW, my insurance method here is to have a complete prebui= lt > -current tree (with gcc built and ready to be installed) sitting on the s= ide, so > if suddenly llvm won't operate, I only need to install from that other tr= ee to > get me a good gcc again. Not that I'm expecting any code problem, but I = could > cause myself some local problem, possibly, I want to protect myself from > anything. I'm honestly mostly worried about the stiching up of the new l= lvm > code with the rest of the tree, or if that needs something extra (beyond = merely > getting llvm working)? Now that there are other people who are starting to use the clangbsd branch for tests (for example Erwin's port builds), I integrate the FreeBSD, LLVM and Clang source once or twice a week. Before I commit, I usually run two buildworlds on an amd64 box, to make sure the system is at least capable of bootstrapping itself. Being able to do that still doesn't bring a lot of guarantees, but at least makes it less likely for you to completely hose your system. --=20 Ed Schouten WWW: http://80386.nl/ --srAoGIOs8asUHz4E Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAko1P8oACgkQ52SDGA2eCwU9agCeLnF7KZ+hfdKKPCtxab2022dK XwIAnA2l1RUD87mS3KyyqhHbPXb5g6wB =cND1 -----END PGP SIGNATURE----- --srAoGIOs8asUHz4E-- From owner-freebsd-current@FreeBSD.ORG Sun Jun 14 18:38:35 2009 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 90B5A106566C for ; Sun, 14 Jun 2009 18:38:35 +0000 (UTC) (envelope-from chuckr@telenix.org) Received: from mail1.sea5.speakeasy.net (mail1.sea5.speakeasy.net [69.17.117.3]) by mx1.freebsd.org (Postfix) with ESMTP id 6D5A48FC14 for ; Sun, 14 Jun 2009 18:38:35 +0000 (UTC) (envelope-from chuckr@telenix.org) Received: (qmail 21725 invoked from network); 14 Jun 2009 18:10:33 -0000 Received: from april.chuckr.org (HELO april.telenix.org) (chuckr@[66.92.151.30]) (envelope-sender ) by mail1.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 14 Jun 2009 18:10:33 -0000 Message-ID: <4A353D49.1050202@telenix.org> Date: Sun, 14 Jun 2009 14:11:21 -0400 From: Chuck Robey User-Agent: Thunderbird 2.0.0.19 (X11/20090121) MIME-Version: 1.0 To: "M. Warner Losh" References: <20090604093831.GE48776@hoeg.nl> <20090608.120552.756910862.imp@bsdimp.com> In-Reply-To: <20090608.120552.756910862.imp@bsdimp.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ed@80386.nl, current@freebsd.org Subject: Re: Clang: now available from a SVN server near you! 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, 14 Jun 2009 18:38:36 -0000 M. Warner Losh wrote: > In message: <20090604093831.GE48776@hoeg.nl> > Ed Schouten writes: > : Good news everyone! > ... > : So far we've only done testing on amd64 and i386. A lot of ports are > : probably still broken. Caveat emptor. Beware of dog. Slippery when wet. > > "objects in mirror may be larger than they appear" > > Do you have size or run-time performance comparisons yet? I feel a bit like an idiot needing to ask this, but I downloaded the stuff on llvm/clang, but I don't know the name of the directories, and I need to ask some items. (Before someone kindly points this out, I've been running -current fairly regularly since 1.0, and I'm completely aware that running current is very nearly completely a "run at your own risk" thing. I have a pretty good track record and being able to fix things, and I accept this risk just like the earlier ones). So, I need the next very few questions to help me on my way: First is the complete set of llvm/clang code in that new src/cddl subdirectory? I looked really hard for directories named either clang or llvm, and since I didn't find anything, is there anything like a README that explains what's sitting where? I mean, stuff like what's in the currently available src/README, but in a little additional detail for the new llvm/clang stuff. This is likely stuff that others might be curious about also, those who didn't konw any more about llvm than I do. Is the rest of the stuff I downloaded, the rest of that tree, being kept up to date with the rest of the FreeBSD-current's HEAD? Or, is that being held for llvm testing? BTW, my insurance method here is to have a complete prebuilt -current tree (with gcc built and ready to be installed) sitting on the side, so if suddenly llvm won't operate, I only need to install from that other tree to get me a good gcc again. Not that I'm expecting any code problem, but I could cause myself some local problem, possibly, I want to protect myself from anything. I'm honestly mostly worried about the stiching up of the new llvm code with the rest of the tree, or if that needs something extra (beyond merely getting llvm working)? Thanks for letting me bother you about this. From owner-freebsd-current@FreeBSD.ORG Sun Jun 14 18:51:06 2009 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 80AEF1065670; Sun, 14 Jun 2009 18:51:06 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-out2.uni-muenster.de (ZIVM-OUT2.UNI-MUENSTER.DE [128.176.192.9]) by mx1.freebsd.org (Postfix) with ESMTP id 6A5328FC08; Sun, 14 Jun 2009 18:51:04 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) X-IronPort-AV: E=Sophos;i="4.42,218,1243807200"; d="scan'208";a="216147077" Received: from zivmaildisp2.uni-muenster.de (HELO ZIVMAILUSER05.UNI-MUENSTER.DE) ([128.176.188.143]) by zivm-relay2.uni-muenster.de with ESMTP; 14 Jun 2009 20:51:03 +0200 Received: by ZIVMAILUSER05.UNI-MUENSTER.DE (Postfix, from userid 149459) id 8C5D51B07E4; Sun, 14 Jun 2009 20:51:03 +0200 (CEST) Date: Sun, 14 Jun 2009 20:50:57 +0200 (CEST) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: Chagin Dmitry Message-ID: In-Reply-To: <20090614175518.GA28675@dchagin.static.corbina.ru> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=+permail-20090614185057f7e55a9d00006462-a_best01+ Cc: freebsd-current@freebsd.org Subject: Re: linux syscall get_robust_list causes 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: Sun, 14 Jun 2009 18:51:06 -0000 This is a MIME encoded multipart message. --+permail-20090614185057f7e55a9d00006462-a_best01+ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit thanks for comitting this fix so fast. while running the ltp i stumbled upon another problem, which isn't causing a panic however. the "testcases/kernel/ipc/ipc_stress/message_queue_test_02_rcv" test seems to stall at sone point and needs to be killed. the test doesn't get past this line (message_queue_test_02_rcv.c/line 131): if (msgrcv (msqid, message, BUF_SIZE, 0, 0) < 0) sys_error ("msgrcv failed", __LINE__); i attached a linux_kdump. cheers. Chagin Dmitry schrieb am 2009-06-14: > On Sun, Jun 14, 2009 at 05:30:44PM +0200, Alexander Best wrote: > > wow. > > thanks for the fix. after applying the patch the panic no longer > > occurs. great > > job! :-) hope this'll make it into CURRENT quickly. ;) > > cheers. > commited (r194203). thnx! --+permail-20090614185057f7e55a9d00006462-a_best01+ Content-Type: application/octet-stream Content-Transfer-Encoding: Base64 Content-Disposition: attachment; filename="messagequeuetest02rcv.c.kdump" ICAxODYzIGt0cmFjZSAgIFJFVCAgIGxpbnV4X2JyayAwCiAgMTg2MyBrdHJhY2UgICBDQUxMICBs aW51eF9vbGR1bmFtZSgweGJmYmZlZGVmLDB4YmZiZmVjZGMsMHhiZmJmZWNlNCkKICAxODYzIGt0 cmFjZSAgIE5BTUkgICIuL21lc3NhZ2VfcXVldWVfdGVzdF8wMl9yY3YiCiAgMTg2MyBrdHJhY2Ug ICBOQU1JICAiL2NvbXBhdC9saW51eC9saWIvbGQtbGludXguc28uMiIKICAxODYzIG1lc3NhZ2Vf cXVldWVfdGVzdF8gUkVUICAgbGludXhfb2xkdW5hbWUgMAogIDE4NjMgbWVzc2FnZV9xdWV1ZV90 ZXN0XyBDQUxMICBsaW51eF9icmsoMCkKICAxODYzIG1lc3NhZ2VfcXVldWVfdGVzdF8gUkVUICAg bGludXhfYnJrIDEzNDUyNDkyOC8weDgwNGIwMDAKICAxODYzIG1lc3NhZ2VfcXVldWVfdGVzdF8g Q0FMTCAgbGludXhfbmV3dW5hbWUoMHhiZmJmZTg5YSkKICAxODYzIG1lc3NhZ2VfcXVldWVfdGVz dF8gUkVUICAgbGludXhfbmV3dW5hbWUgMAogIDE4NjMgbWVzc2FnZV9xdWV1ZV90ZXN0XyBDQUxM ICBsaW51eF9hY2Nlc3MoMHgyODA2NWI1NCwweDQpCiAgMTg2MyBtZXNzYWdlX3F1ZXVlX3Rlc3Rf IE5BTUkgICIvY29tcGF0L2xpbnV4L2V0Yy9sZC5zby5wcmVsb2FkIgogIDE4NjMgbWVzc2FnZV9x dWV1ZV90ZXN0XyBOQU1JICAiL2V0Yy9sZC5zby5wcmVsb2FkIgogIDE4NjMgbWVzc2FnZV9xdWV1 ZV90ZXN0XyBSRVQgICBsaW51eF9hY2Nlc3MgSlVTVFJFVFVSTgogIDE4NjMgbWVzc2FnZV9xdWV1 ZV90ZXN0XyBDQUxMICBsaW51eF9vcGVuKDB4MjgwNjVlMjcsMCwwKQogIDE4NjMgbWVzc2FnZV9x dWV1ZV90ZXN0XyBOQU1JICAiL2NvbXBhdC9saW51eC9ldGMvbGQuc28uY2FjaGUiCiAgMTg2MyBt ZXNzYWdlX3F1ZXVlX3Rlc3RfIE5BTUkgICIvY29tcGF0L2xpbnV4IgogIDE4NjMgbWVzc2FnZV9x dWV1ZV90ZXN0XyBOQU1JICAiL2NvbXBhdC9saW51eC9ldGMvbGQuc28uY2FjaGUiCiAgMTg2MyBt ZXNzYWdlX3F1ZXVlX3Rlc3RfIFJFVCAgIGxpbnV4X29wZW4gMwogIDE4NjMgbWVzc2FnZV9xdWV1 ZV90ZXN0XyBDQUxMICBsaW51eF9mc3RhdDY0KDB4MywweGJmYmZlNGQ4LDB4MjgwNjlmZDApCiAg MTg2MyBtZXNzYWdlX3F1ZXVlX3Rlc3RfIFVOS05PV04oOCkgICAgMTg2MyBtZXNzYWdlX3F1ZXVl X3Rlc3RfIFJFVCAgIGxpbnV4X2ZzdGF0NjQgMAogIDE4NjMgbWVzc2FnZV9xdWV1ZV90ZXN0XyBD QUxMICBsaW51eF9tbWFwMigwLDB4MzYwNSwweDEsMHgyLDB4MywwKQogIDE4NjMgbWVzc2FnZV9x dWV1ZV90ZXN0XyBSRVQgICBsaW51eF9tbWFwMiA2NzE1MjY5MTIvMHgyODA2YjAwMAogIDE4NjMg bWVzc2FnZV9xdWV1ZV90ZXN0XyBDQUxMICBjbG9zZSgweDMpCiAgMTg2MyBtZXNzYWdlX3F1ZXVl X3Rlc3RfIFJFVCAgIGNsb3NlIDAKICAxODYzIG1lc3NhZ2VfcXVldWVfdGVzdF8gQ0FMTCAgbGlu dXhfb3BlbigweDI4MDZkMjMwLDAsMHg4MDQ4MzdkKQogIDE4NjMgbWVzc2FnZV9xdWV1ZV90ZXN0 XyBOQU1JICAiL2NvbXBhdC9saW51eC9saWIvbGlicHRocmVhZC5zby4wIgogIDE4NjMgbWVzc2Fn ZV9xdWV1ZV90ZXN0XyBOQU1JICAiL2NvbXBhdC9saW51eCIKICAxODYzIG1lc3NhZ2VfcXVldWVf dGVzdF8gTkFNSSAgIi9jb21wYXQvbGludXgvbGliL2xpYnB0aHJlYWQuc28uMCIKICAxODYzIG1l c3NhZ2VfcXVldWVfdGVzdF8gUkVUICAgbGludXhfb3BlbiAzCiAgMTg2MyBtZXNzYWdlX3F1ZXVl X3Rlc3RfIENBTEwgIHJlYWQoMHgzLDB4YmZiZmU2MzAsMHgyMDApCiAgMTg2MyBtZXNzYWdlX3F1 ZXVlX3Rlc3RfIEdJTyAgIGZkIDMgcmVhZCA1MTIgYnl0ZXMKICAgICAgICJcXj9FTEZcXkFcXkFc XkFcMFwwXDBcMFwwXDBcMFwwXDBcXkNcMFxeQ1wwXF5BXDBcMFwwwEdcMFwwMDA0XDBcMFwwYFwK CVxeQ1xeQlwwXDBcMFwwXDAwMDRcMCBcMAlcMChcMCZcMCVcMFxeRlwwXDBcMDAwNFwwXDBcMDAw NFwwXDBcCglcMDAwNFwwXDBcMCBcXkFcMFwwIFxeQVwwXDBcXkVcMFwwXDBcXkRcMFwwXDBcXkNc MFwwXDC0XHJcXkFcMLRcclxeQVwwXAoJtFxyXF5BXDBcXlNcMFwwXDBcXlNcMFwwXDBcXkRcMFww XDBcXkFcMFwwXDBcXkFcMFwwXDBcMFwwXDBcMFwwXDBcMFwwXAoJXDBcMFwwXDD8VVxeQVww/FVc XkFcMFxeRVwwXDBcMFwwXF5QXDBcMFxeQVwwXDBcMLxdXF5BXDC8bVxeQVwwvG1cXkFcMFwKCXRc XkNcMFwwJCRcMFwwXF5GXDBcMFwwXDBcXlBcMFwwXF5CXDBcMFww1F5cXkFcMNRuXF5BXDDUblxe QVww+FwwXDBcMPhcCglcMFwwXDBcXkZcMFwwXDBcXkRcMFwwXDBcXkRcMFwwXDBUXF5BXDBcMFRc XkFcMFwwVFxeQVwwXDBEXDBcMFwwRFwwXDBcCglcMFxeRFwwXDBcMFxeRFwwXDBcMFDldGTIXHJc XkFcMMhcclxeQVwwyFxyXF5BXDBcXlQKCVwwXDBcXlQKCVwwXDBcXkRcMFwwXDBcXkRcMFwwXDBR 5XRkXDBcMFwwXDBcMFwwXDBcMFwwXDBcMFwwXDBcMFwwXDBcMFwwXDBcMFxeRlwKCVwwXDBcMFxe RFwwXDBcMFLldGS8XVxeQVwwvG1cXkFcMLxtXF5BXDBEXF5CXDBcMERcXkJcMFwwXF5EXDBcMFww XF5BXDBcCglcMFwwXF5EXDBcMFwwXF5UXDBcMFwwXF5DXDBcMFwwR05VXDD7XF5etlxNXklcTV5E uavBwlxeRid2RLGjpElcXl4z8lwKCVxeRFwwXDBcMFxeUFwwXDBcMFxeQVwwXDBcMEdOVVwwXDBc MFwwXDBcXkJcMFwwXDBcXkZcMFwwXDAJXDBcMFwwXAoJslxeQVwwXDBMXDBcMFwwQFwwXDBcMFx2 XDBcMFwwXF5ZIVxeQlxNXlFcXkEKCVxeUCJASCDZXF5DXDBJNFxNXkBcMFwwQFwwIFxNXkBcTV5A XF5RUGBAQFxeUlxNXktcXkIwRFwwXDBcXlBcMFwwXF5CXDBcCglcXkFcclwwXE1eRAoJ8FxeQViw XHJcMjQwXE1eQFxiICRcTV5EXF5QQqIpbVxiR1xNXlxWXF5QXDBcTV5UIFxNXkQkXGJcMEgoXF5B XE1eUlxeXFwKCcFCXDI0MFxNXlBcXlJcYlxmIFxeQiIKICAxODYzIG1lc3NhZ2VfcXVldWVfdGVz dF8gUkVUICAgcmVhZCA1MTIvMHgyMDAKICAxODYzIG1lc3NhZ2VfcXVldWVfdGVzdF8gQ0FMTCAg bGludXhfZnN0YXQ2NCgweDMsMHhiZmJmZTU0MCwweDI4MDY5ZmQwKQogIDE4NjMgbWVzc2FnZV9x dWV1ZV90ZXN0XyBVTktOT1dOKDgpICAgIDE4NjMgbWVzc2FnZV9xdWV1ZV90ZXN0XyBSRVQgICBs aW51eF9mc3RhdDY0IDAKICAxODYzIG1lc3NhZ2VfcXVldWVfdGVzdF8gQ0FMTCAgbGludXhfbW1h cDIoMCwweDE5MWUwLDB4NSwweDgwMiwweDMsMCkKICAxODYzIG1lc3NhZ2VfcXVldWVfdGVzdF8g UkVUICAgbGludXhfbW1hcDIgNjcxNTQzMjk2LzB4MjgwNmYwMDAKICAxODYzIG1lc3NhZ2VfcXVl dWVfdGVzdF8gQ0FMTCAgbGludXhfbW1hcDIoMHgyODA4NTAwMCwweDIwMDAsMHgzLDB4ODEyLDB4 MywweDE1KQogIDE4NjMgbWVzc2FnZV9xdWV1ZV90ZXN0XyBSRVQgICBsaW51eF9tbWFwMiA2NzE2 MzM0MDgvMHgyODA4NTAwMAogIDE4NjMgbWVzc2FnZV9xdWV1ZV90ZXN0XyBDQUxMICBsaW51eF9t bWFwMigweDI4MDg3MDAwLDB4MTFlMCwweDMsMHgzMiwweGZmZmZmZmZmLDApCiAgMTg2MyBtZXNz YWdlX3F1ZXVlX3Rlc3RfIFJFVCAgIGxpbnV4X21tYXAyIDY3MTY0MTYwMC8weDI4MDg3MDAwCiAg MTg2MyBtZXNzYWdlX3F1ZXVlX3Rlc3RfIENBTEwgIGNsb3NlKDB4MykKICAxODYzIG1lc3NhZ2Vf cXVldWVfdGVzdF8gUkVUICAgY2xvc2UgMAogIDE4NjMgbWVzc2FnZV9xdWV1ZV90ZXN0XyBDQUxM ICBsaW51eF9vcGVuKDB4MjgwNmRmNDQsMCwweDgwNDgzYzEpCiAgMTg2MyBtZXNzYWdlX3F1ZXVl X3Rlc3RfIE5BTUkgICIvY29tcGF0L2xpbnV4L2xpYi9saWJjLnNvLjYiCiAgMTg2MyBtZXNzYWdl X3F1ZXVlX3Rlc3RfIE5BTUkgICIvY29tcGF0L2xpbnV4IgogIDE4NjMgbWVzc2FnZV9xdWV1ZV90 ZXN0XyBOQU1JICAiL2NvbXBhdC9saW51eC9saWIvbGliYy5zby42IgogIDE4NjMgbWVzc2FnZV9x dWV1ZV90ZXN0XyBSRVQgICBsaW51eF9vcGVuIDMKICAxODYzIG1lc3NhZ2VfcXVldWVfdGVzdF8g Q0FMTCAgcmVhZCgweDMsMHhiZmJmZTYxNCwweDIwMCkKICAxODYzIG1lc3NhZ2VfcXVldWVfdGVz dF8gR0lPICAgZmQgMyByZWFkIDUxMiBieXRlcwogICAgICAgIlxeP0VMRlxeQVxeQVxeQVwwXDBc MFwwXDBcMFwwXDBcMFxeQ1wwXF5DXDBcXkFcMFwwXDBAaFxeQVwwMDA0XDBcMFwwwMZcCglcXltc MFwwXDBcMFwwMDA0XDAgXDAKCVwwKFwwR1wwRlwwXF5GXDBcMFwwMDA0XDBcMFwwMDA0XDBcMFww MDA0XDBcMFwwQFxeQVwwXDBAXF5BXDBcMFxeRVwwXDBcCglcMFxeRFwwXDBcMFxeQ1wwXDBcMECi XF5UXDBAolxeVFwwQKJcXlRcMFxeU1wwXDBcMFxeU1wwXDBcMFxeRFwwXDBcMFwKCVxeQVwwXDBc MFxeQVwwXDBcMFwwXDBcMFwwXDBcMFwwXDBcMFwwXDBcMPhcXlRcXldcMPhcXlRcXldcMFxeRVww XDBcMFwKCVwwXF5QXDBcMFxeQVwwXDBcMOQhXF5XXDDkIVxeV1ww5CFcXldcMFxNXlgnXDBcMGxU XDBcMFxeRlwwXDBcMFwwXF5QXDBcCglcMFxeQlwwXDBcMHw9XF5XXDB8PVxeV1wwfD1cXldcMPhc MFwwXDD4XDBcMFwwXF5GXDBcMFwwXF5EXDBcMFwwXF5EXDBcCglcMFwwdFxeQVwwXDB0XF5BXDBc MHRcXkFcMFwwRFwwXDBcMERcMFwwXDBcXkRcMFwwXDBcXkRcMFwwXDBcYVwwXDBcMOQhXAoJXF5X XDDkIVxeV1ww5CFcXldcMFxiXDBcMFwwQFwwXDBcMFxeRFwwXDBcMFxeRFwwXDBcMFDldGRUolxe VFwwVKJcXlRcMFwKCVSiXF5UXDD0aVwwXDD0aVwwXDBcXkRcMFwwXDBcXkRcMFwwXDBR5XRkXDBc MFwwXDBcMFwwXDBcMFwwXDBcMFwwXDBcMFwKCVwwXDBcMFwwXDBcMFxeRlwwXDBcMFxeRFwwXDBc MFLldGTkIVxeV1ww5CFcXldcMOQhXF5XXDBcXlxcXl5cMFwwXF5cXAoJXF5eXDBcMFxeRFwwXDBc MFxeQVwwXDBcMFxeRFwwXDBcMFxeVFwwXDBcMFxeQ1wwXDBcMEdOVVww6O9aT1xeUKj5L1xeTlwK CdlkIFxNXkPCXF5DejlcXlx1tlxeRFwwXDBcMFxeUFwwXDBcMFxeQVwwXDBcMEdOVVwwXDBcMFww XDBcXkJcMFwwXDBcXkZcCglcMFwwXDAJXDBcMFww81xeQ1wwXDAJXDBcMFwwXDBcXkJcMFwwXF5O XDBcMFwwXDI0MDBcXlBEXE1eQCBcXkJcXkFcCglcTV5MXF5D5lxNXlBBRVxNXkhcMFxNXkRcMFxi XDBBXE1eQFwwQMBcTV5AXDBcZlxeQlxmXDBcXkEwXDBcYkAiXGKmXF5EXAoJXE1eSEg2bFwyNDBc XlYwXDAmXE1eRFxNXkBcTV5OXF5EXGJCJCIKICAxODYzIG1lc3NhZ2VfcXVldWVfdGVzdF8gUkVU ICAgcmVhZCA1MTIvMHgyMDAKICAxODYzIG1lc3NhZ2VfcXVldWVfdGVzdF8gQ0FMTCAgbGludXhf bW1hcDIoMCwweDEwMDAsMHgzLDB4MjIsMHhmZmZmZmZmZiwwKQogIDE4NjMgbWVzc2FnZV9xdWV1 ZV90ZXN0XyBSRVQgICBsaW51eF9tbWFwMiA2NzE2NDk3OTIvMHgyODA4OTAwMAogIDE4NjMgbWVz c2FnZV9xdWV1ZV90ZXN0XyBDQUxMICBsaW51eF9mc3RhdDY0KDB4MywweGJmYmZlNTI0LDB4Mjgw NjlmZDApCiAgMTg2MyBtZXNzYWdlX3F1ZXVlX3Rlc3RfIFVOS05PV04oOCkgICAgMTg2MyBtZXNz YWdlX3F1ZXVlX3Rlc3RfIFJFVCAgIGxpbnV4X2ZzdGF0NjQgMAogIDE4NjMgbWVzc2FnZV9xdWV1 ZV90ZXN0XyBDQUxMICBsaW51eF9tbWFwMigwLDB4MTc3NjUwLDB4NSwweDgwMiwweDMsMCkKICAx ODYzIG1lc3NhZ2VfcXVldWVfdGVzdF8gUkVUICAgbGludXhfbW1hcDIgNjcxNjUzODg4LzB4Mjgw OGEwMDAKICAxODYzIG1lc3NhZ2VfcXVldWVfdGVzdF8gQ0FMTCAgbGludXhfbW1hcDIoMHgyODFm YzAwMCwweDMwMDAsMHgzLDB4ODEyLDB4MywweDE3MikKICAxODYzIG1lc3NhZ2VfcXVldWVfdGVz dF8gUkVUICAgbGludXhfbW1hcDIgNjczMTY5NDA4LzB4MjgxZmMwMDAKICAxODYzIG1lc3NhZ2Vf cXVldWVfdGVzdF8gQ0FMTCAgbGludXhfbW1hcDIoMHgyODFmZjAwMCwweDI2NTAsMHgzLDB4MzIs MHhmZmZmZmZmZiwwKQogIDE4NjMgbWVzc2FnZV9xdWV1ZV90ZXN0XyBSRVQgICBsaW51eF9tbWFw MiA2NzMxODE2OTYvMHgyODFmZjAwMAogIDE4NjMgbWVzc2FnZV9xdWV1ZV90ZXN0XyBDQUxMICBj bG9zZSgweDMpCiAgMTg2MyBtZXNzYWdlX3F1ZXVlX3Rlc3RfIFJFVCAgIGNsb3NlIDAKICAxODYz IG1lc3NhZ2VfcXVldWVfdGVzdF8gQ0FMTCAgbGludXhfbW1hcDIoMCwweDEwMDAsMHgzLDB4MjIs MHhmZmZmZmZmZiwwKQogIDE4NjMgbWVzc2FnZV9xdWV1ZV90ZXN0XyBSRVQgICBsaW51eF9tbWFw MiA2NzMxOTM5ODQvMHgyODIwMjAwMAogIDE4NjMgbWVzc2FnZV9xdWV1ZV90ZXN0XyBDQUxMICBs aW51eF9zZXRfdGhyZWFkX2FyZWEoMHhiZmJmZWE1MCkKICAxODYzIG1lc3NhZ2VfcXVldWVfdGVz dF8gUkVUICAgbGludXhfc2V0X3RocmVhZF9hcmVhIDAKICAxODYzIG1lc3NhZ2VfcXVldWVfdGVz dF8gQ0FMTCAgbGludXhfbXByb3RlY3QoMHgyODFmYzAwMCwweDIwMDAsMHgxKQogIDE4NjMgbWVz c2FnZV9xdWV1ZV90ZXN0XyBSRVQgICBsaW51eF9tcHJvdGVjdCAwCiAgMTg2MyBtZXNzYWdlX3F1 ZXVlX3Rlc3RfIENBTEwgIGxpbnV4X21wcm90ZWN0KDB4MjgwODUwMDAsMHgxMDAwLDB4MSkKICAx ODYzIG1lc3NhZ2VfcXVldWVfdGVzdF8gUkVUICAgbGludXhfbXByb3RlY3QgMAogIDE4NjMgbWVz c2FnZV9xdWV1ZV90ZXN0XyBDQUxMICBsaW51eF9tcHJvdGVjdCgweDgwNDkwMDAsMHgxMDAwLDB4 MSkKICAxODYzIG1lc3NhZ2VfcXVldWVfdGVzdF8gUkVUICAgbGludXhfbXByb3RlY3QgMAogIDE4 NjMgbWVzc2FnZV9xdWV1ZV90ZXN0XyBDQUxMICBsaW51eF9tcHJvdGVjdCgweDI4MDY5MDAwLDB4 MTAwMCwweDEpCiAgMTg2MyBtZXNzYWdlX3F1ZXVlX3Rlc3RfIFJFVCAgIGxpbnV4X21wcm90ZWN0 IDAKICAxODYzIG1lc3NhZ2VfcXVldWVfdGVzdF8gQ0FMTCAgbXVubWFwKDB4MjgwNmIwMDAsMHgz NjA1KQogIDE4NjMgbWVzc2FnZV9xdWV1ZV90ZXN0XyBSRVQgICBtdW5tYXAgMAogIDE4NjMgbWVz c2FnZV9xdWV1ZV90ZXN0XyBDQUxMICBsaW51eF9zZXRfdGlkX2FkZHJlc3MoMHgyODIwMjcwOCkK ICAxODYzIG1lc3NhZ2VfcXVldWVfdGVzdF8gUkVUICAgbGludXhfc2V0X3RpZF9hZGRyZXNzIDE4 NjMvMHg3NDcKICAxODYzIG1lc3NhZ2VfcXVldWVfdGVzdF8gQ0FMTCAgbGludXhfc2V0X3JvYnVz dF9saXN0KDB4MjgyMDI3MTAsMHhjKQogIDE4NjMgbWVzc2FnZV9xdWV1ZV90ZXN0XyBSRVQgICBs aW51eF9zZXRfcm9idXN0X2xpc3QgMAogIDE4NjMgbWVzc2FnZV9xdWV1ZV90ZXN0XyBDQUxMICBs aW51eF9zeXNfZnV0ZXgoMHhiZmJmZWM4MCwweDgxLDB4MSwweDI4MjAyNmMwLDB4MjgwODVmZjQs MHhiZmJmZWM5MCkKICAxODYzIG1lc3NhZ2VfcXVldWVfdGVzdF8gUkVUICAgbGludXhfc3lzX2Z1 dGV4IDAKICAxODYzIG1lc3NhZ2VfcXVldWVfdGVzdF8gQ0FMTCAgbGludXhfcnRfc2lnYWN0aW9u KDB4MjAsMHhiZmJmZTkzOCwwLDB4OCkKICAxODYzIG1lc3NhZ2VfcXVldWVfdGVzdF8gUkVUICAg bGludXhfcnRfc2lnYWN0aW9uIDAKICAxODYzIG1lc3NhZ2VfcXVldWVfdGVzdF8gQ0FMTCAgbGlu dXhfcnRfc2lnYWN0aW9uKDB4MjEsMHhiZmJmZTkzOCwwLDB4OCkKICAxODYzIG1lc3NhZ2VfcXVl dWVfdGVzdF8gUkVUICAgbGludXhfcnRfc2lnYWN0aW9uIDAKICAxODYzIG1lc3NhZ2VfcXVldWVf dGVzdF8gQ0FMTCAgbGludXhfcnRfc2lncHJvY21hc2soMHgxLDB4YmZiZmViZWMsMCwweDgpCiAg MTg2MyBtZXNzYWdlX3F1ZXVlX3Rlc3RfIFJFVCAgIGxpbnV4X3J0X3NpZ3Byb2NtYXNrIDAKICAx ODYzIG1lc3NhZ2VfcXVldWVfdGVzdF8gQ0FMTCAgbGludXhfZ2V0cmxpbWl0KDB4MywweGJmYmZl Yzc0KQogIDE4NjMgbWVzc2FnZV9xdWV1ZV90ZXN0XyBSRVQgICBsaW51eF9nZXRybGltaXQgMAog IDE4NjMgbWVzc2FnZV9xdWV1ZV90ZXN0XyBDQUxMICBsaW51eF9uZXd1bmFtZSgweGJmYmZlOWU4 KQogIDE4NjMgbWVzc2FnZV9xdWV1ZV90ZXN0XyBSRVQgICBsaW51eF9uZXd1bmFtZSAwCiAgMTg2 MyBtZXNzYWdlX3F1ZXVlX3Rlc3RfIENBTEwgIGxpbnV4X3N0YXQ2NCgweDgwNDg5YjIsMHhiZmJm ZWJlNCwweDI4MWZkZmY0KQogIDE4NjMgbWVzc2FnZV9xdWV1ZV90ZXN0XyBOQU1JICAiL2NvbXBh dC9saW51eC90bXAvbWVzc2FnZV9xdWV1ZV90ZXN0IgogIDE4NjMgbWVzc2FnZV9xdWV1ZV90ZXN0 XyBOQU1JICAiL3RtcC9tZXNzYWdlX3F1ZXVlX3Rlc3QiCiAgMTg2MyBtZXNzYWdlX3F1ZXVlX3Rl c3RfIFVOS05PV04oOCkgICAgMTg2MyBtZXNzYWdlX3F1ZXVlX3Rlc3RfIFJFVCAgIGxpbnV4X3N0 YXQ2NCAwCiAgMTg2MyBtZXNzYWdlX3F1ZXVlX3Rlc3RfIENBTEwgIGxpbnV4X2lwYygweGQsMHgx NDZiOGMwNywweDE4MCwwLDAsMHhiZmJmZWM0OCkKICAxODYzIG1lc3NhZ2VfcXVldWVfdGVzdF8g UkVUICAgbGludXhfaXBjIDQ1ODc1Mi8weDcwMDAwCiAgMTg2MyBtZXNzYWdlX3F1ZXVlX3Rlc3Rf IENBTEwgIGxpbnV4X2JyaygwKQogIDE4NjMgbWVzc2FnZV9xdWV1ZV90ZXN0XyBSRVQgICBsaW51 eF9icmsgMTM0NTI0OTI4LzB4ODA0YjAwMAogIDE4NjMgbWVzc2FnZV9xdWV1ZV90ZXN0XyBDQUxM ICBsaW51eF9icmsoMHg4MDZjMDAwKQogIDE4NjMgbWVzc2FnZV9xdWV1ZV90ZXN0XyBSRVQgICBs aW51eF9icmsgMTM0NjYwMDk2LzB4ODA2YzAwMAogIDE4NjMgbWVzc2FnZV9xdWV1ZV90ZXN0XyBD QUxMICBsaW51eF9pcGMoMHhjLDB4NzAwMDAsMHgxMDAsMCwweGJmYmZlYzIwLDB4YmZiZmVjMzgp CiAgMTg2MyBtZXNzYWdlX3F1ZXVlX3Rlc3RfIFJFVCAgIGxpbnV4X2lwYyAtMSBlcnJubyA0IElu dGVycnVwdGVkIHN5c3RlbSBjYWxsCi0+IHRoaXMgaXMgd2hlcmUgaSBraWxsZWQgdGhlIHByb2Nl c3MgYmVjYXVzZSBpdCBzdGFsbGVkCiAgMTg2MyBtZXNzYWdlX3F1ZXVlX3Rlc3RfIFBTSUcgIFNJ R0lOVCBTSUdfREZMCg== --+permail-20090614185057f7e55a9d00006462-a_best01+-- From owner-freebsd-current@FreeBSD.ORG Sun Jun 14 20:31:56 2009 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 3E144106566B for ; Sun, 14 Jun 2009 20:31:56 +0000 (UTC) (envelope-from mister.olli@googlemail.com) Received: from mail-bw0-f228.google.com (mail-bw0-f228.google.com [209.85.218.228]) by mx1.freebsd.org (Postfix) with ESMTP id B6E3F8FC17 for ; Sun, 14 Jun 2009 20:31:55 +0000 (UTC) (envelope-from mister.olli@googlemail.com) Received: by bwz28 with SMTP id 28so264285bwz.43 for ; Sun, 14 Jun 2009 13:31:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:subject:from:reply-to:to:cc :in-reply-to:references:content-type:date:message-id:mime-version :x-mailer:content-transfer-encoding; bh=QTSV6lMcMCDw4tAbkPvzLtviIGEmNhXAFDIPqhzglhM=; b=Qr4PIwFg+qcreoCPrSSUl8jVSBgkK3ZLxAjTLVY0dTbW0wJNE0LcSdMybfBeTg/oHS ogCvVVQlOjrAuCWR9xyv+zWa3gRP8gk+Dhxmen6Cnme3+cz4i6z20f/EHu14/X46kkEB 9OgZVsBNcX3OETAvXGkmz4V6t/OFnBt0cWeH8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=subject:from:reply-to:to:cc:in-reply-to:references:content-type :date:message-id:mime-version:x-mailer:content-transfer-encoding; b=ooLCgeCp0jB9PO1aqmZ+3fL5FPk5l/SpuJNv7/rX4kmFtg9UiEMAuryxfZcxxm4CUx yUuivFr+RnIVdIZz8zYxNq9eo4vHifzj1FNOCtKlZ8KY3TbaX0BhRXFWSl8KiuuGvFZW RrmtSuJ/9SbU450EZgfjJgpOrO/OWFoR7gGoU= Received: by 10.103.252.17 with SMTP id e17mr3253989mus.14.1245011514682; Sun, 14 Jun 2009 13:31:54 -0700 (PDT) Received: from ?192.168.220.100? (Zc037.z.pppool.de [89.61.192.55]) by mx.google.com with ESMTPS id e10sm1811609muf.14.2009.06.14.13.31.53 (version=SSLv3 cipher=RC4-MD5); Sun, 14 Jun 2009 13:31:54 -0700 (PDT) From: Mister Olli To: "Bjoern A. Zeeb" In-Reply-To: <20090613131026.M22887@maildrop.int.zabbadoz.net> References: <1244896319.5456.9.camel@phoenix.blechhirn.net> <20090613131026.M22887@maildrop.int.zabbadoz.net> Content-Type: text/plain Date: Sun, 14 Jun 2009 22:31:37 +0200 Message-Id: <1245011497.6570.8.camel@phoenix.blechhirn.net> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Error loading zfs.ko X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mister.olli@googlemail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jun 2009 20:31:56 -0000 Hi, great the fix works perfectly. ZFS loads like a charm. Great work :-)) Regards, --- Mr. Olli On Sat, 2009-06-13 at 13:10 +0000, Bjoern A. Zeeb wrote: > On Sat, 13 Jun 2009, Mister Olli wrote: > > Hi, > > > When trying to load 'zfs.ko' I get a link_elf failure. Does anyone know > > how to fix this? > > http://svn.freebsd.org/viewvc/base?view=revision&revision=194106 > > /bz > From owner-freebsd-current@FreeBSD.ORG Mon Jun 15 01:27:54 2009 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 0D300106564A for ; Mon, 15 Jun 2009 01:27:54 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-px0-f192.google.com (mail-px0-f192.google.com [209.85.216.192]) by mx1.freebsd.org (Postfix) with ESMTP id CAF9A8FC1D for ; Mon, 15 Jun 2009 01:27:53 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by pxi30 with SMTP id 30so2530694pxi.3 for ; Sun, 14 Jun 2009 18:27:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=pVBz6UCf6NExh6U10n4/vcVUKajtuzQ8UiC/kTZGoHQ=; b=K/kcS6NM5lH8Um8EuN8sWhslxYqRylXL/jTuKCe5FNtVQJSPnKQB0r8e/tByVIOSzL j6skwR5OrcD5FEOMwBwlTx4a0onGFRmgi5qDLklI4LZWGQT1WYvpZVaiV3z9XEMYS3Z4 e2p1oDyN4RDYpMIm9f0YANlfCsPyka1Pz/+is= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=RC8o7tXQe2d0NUI8QV5JmJPi7/0XHvuxe56IPRauNs6CXc0YcMKW0T4v4rWqV+2UNd xR9eM4XwyJ8x2UyzikO8PkqxW7emcQ5yXs+BqUHq7xbGHpSZxM3zMvLUaEcxsn0MPrNl 15QdXYWeRBOPiJWgkRCrsRCYY8feJcDEnDjP4= Received: by 10.114.25.19 with SMTP id 19mr10780976way.89.1245029272323; Sun, 14 Jun 2009 18:27:52 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ([114.111.62.249]) by mx.google.com with ESMTPS id j34sm5282952waf.64.2009.06.14.18.27.45 (version=SSLv3 cipher=RC4-MD5); Sun, 14 Jun 2009 18:27:46 -0700 (PDT) Received: by michelle.cdnetworks.co.kr (sSMTP sendmail emulation); Mon, 15 Jun 2009 10:31:07 +0900 From: Pyun YongHyeon Date: Mon, 15 Jun 2009 10:31:06 +0900 To: Thomas Lotterer Message-ID: <20090615013106.GA78415@michelle.cdnetworks.co.kr> References: <4A2DA8D9.2030300@lotterer.net> <20090610024959.GD63941@michelle.cdnetworks.co.kr> <4A2FF8E3.4060501@lotterer.net> <20090611002923.GA68519@michelle.cdnetworks.co.kr> <4A30FD94.4030409@lotterer.net> <20090611130557.GB68519@michelle.cdnetworks.co.kr> <4A312517.9030206@lotterer.net> <20090612055032.GD72855@michelle.cdnetworks.co.kr> <4A32BAE7.40605@lotterer.net> <4A350565.3070504@lotterer.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A350565.3070504@lotterer.net> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: suspect bug in vge(4) 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, 15 Jun 2009 01:27:54 -0000 On Sun, Jun 14, 2009 at 04:12:53PM +0200, Thomas Lotterer wrote: > Thomas Lotterer wrote: > >Pyun YongHyeon wrote: > >>On Thu, Jun 11, 2009 at 05:39:03PM +0200, Thomas Lotterer wrote: > >>>Pyun YongHyeon wrote: > >>>>Could you show me dmesg output(only vge(4) related one)? > >>># dmesg | grep vge > >>>vge0: port 0xec00-0xecff mem > >>>0xdf7ff000-0xdf7ff0ff irq 28 at device 0.0 on pci2 > >>>vge0: MSIX count : 0 > >>>vge0: MSI count : 1 > >> > >>I wonder why "Using 1 MSI messages" message is missing. > > > I stud if_vge.c with device_printf() statements. > > Turns out pci_alloc_msi() returns 6 = ENXIO > > The pci_alloc_msi_method() in /usr/src/sys/dev/pci/pci.c > lists three cases returning ENXIO and all are located at the very top of > the function. > > - If rid 0 is allocated, then fail. > - Already have allocated messages? > - If MSI is blacklisted for this system, fail. > > The pci_msi_blacklisted() and pci_msi_device_blacklisted() in > /usr/src/sys/dev/pci/pci.c > seem to check chipsets, devices and tunables > Correct. FreeBSD maintains a quirk table of known devices that do not work with MSI. These buggy devices are black listed by default. Compare your device ids with the list. Use pciconf(8) to get PCI device ids. > Regarding the chipset > # dmesg | egrep ^acpi > acpi0: on motherboard > acpi0: [ITHREAD] > acpi0: Power Button (fixed) > acpi0: reservation of 0, a0000 (3) failed > acpi0: reservation of 100000, 7bde0000 (3) failed > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 > acpi_button0: on acpi0 > acpi_button1: on acpi0 > > Regarding the tunables > # sysctl -a | fgrep hw.pci. > hw.pci.honor_msi_blacklist: 1 > hw.pci.enable_msix: 1 > hw.pci.enable_msi: 1 > hw.pci.do_power_resume: 1 > hw.pci.do_power_nodriver: 0 > hw.pci.enable_io_modes: 1 > hw.pci.host_mem_start: 2147483648 > hw.pci.mcfg: 1 > hw.pci.irq_override_mask: 57080 > > No cheating here > # sysctl hw.pci.honor_msi_blacklist=0 > sysctl: oid 'hw.pci.honor_msi_blacklist' is read only > That tunable is read only. You can set it in /boot/loader.conf. hw.pci.honor_msi_blacklist="0" > Ideas and suggestions welcome. > -- > http://thomas.lotterer.net From owner-freebsd-current@FreeBSD.ORG Mon Jun 15 01:29:59 2009 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 37100106566C; Mon, 15 Jun 2009 01:29:59 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout014.mac.com (asmtpout014.mac.com [17.148.16.89]) by mx1.freebsd.org (Postfix) with ESMTP id 1FF058FC0C; Mon, 15 Jun 2009 01:29:59 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed Received: from MacBook-Pro.lan.xcllnt.net (mail.xcllnt.net [75.101.29.67]) by asmtp014.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KL9006AAATXVN10@asmtp014.mac.com>; Sun, 14 Jun 2009 18:29:59 -0700 (PDT) Message-id: From: Marcel Moolenaar To: Mark Murray In-reply-to: Date: Sun, 14 Jun 2009 18:29:56 -0700 References: <1464A93A-D187-476F-A143-E37EB6BB01EF@mac.com> X-Mailer: Apple Mail (2.935.3) Cc: "current@freebsd.org" Subject: Re: Build is polluted by host build environment. 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, 15 Jun 2009 01:30:00 -0000 On Jun 14, 2009, at 1:21 AM, Mark Murray wrote: > Marcel Moolenaar writes: >> cc_tools is supposed to use /usr/include when it's building the cross >> tools, so your email does not demonstrate a problem per se. > > I said in the original email that the building was fine for all the > tools stuff, and that the failure occurred once the "real" build got > under way. Ok. But still, cc_tools builds programs that run on the host and as such *must* use headers in /usr/include. The GCC build is too convoluted to state that the observed breakage is a problem or that it isn't a problem without detailed analysis of what was being built and how it's used. > If you look at the patch I supplied, you'll see that I only break > /usr/include once the tools are done. Unfortunately that is not exactly true. > Having done that, the real build proceeds, and breaks in cc_tools for > the reason stated. Full build log available on request. Please make the full logs available somewhere. -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Mon Jun 15 01:51:46 2009 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 2AE12106564A for ; Mon, 15 Jun 2009 01:51:46 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-px0-f192.google.com (mail-px0-f192.google.com [209.85.216.192]) by mx1.freebsd.org (Postfix) with ESMTP id E90EE8FC08 for ; Mon, 15 Jun 2009 01:51:45 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by pxi30 with SMTP id 30so2539063pxi.3 for ; Sun, 14 Jun 2009 18:51:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=XYo1MLV/YmoBynGZyMm4DxYKFLNxDUTwSfVXGn1Hv08=; b=CHNlf4W2+Uoaio111EeT49aPof5xRjMfLamL6twrtsxrSHJdsUq+0JkEusnbHdTCTG nCe0BYQogtEHUOcQ/LCLzWCm1/2LtiQGnfFeSt2S8JPHMLWiGl4dFcSIl+/OF9/XPg/u rlkRHwjqehWARlK/BicV+WZWNI3Y7YVJoSaMM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=MHv9jsmciFnD24PlWH7wLOLcCacyU6TFA36qRqeHy4hPlOew10X+XgqJXmfhpOYxSK zi+LvAS38mqrYPLJt2r4LK9xhmzZUJ47XtoHeWlb5de02bmxJCWMwbEN/YpSiEkPG7yY umlgrMrRLPpuSyEJ3DJYgSVMeb8kwE4U5IqwE= Received: by 10.114.157.1 with SMTP id f1mr10938146wae.43.1245030705649; Sun, 14 Jun 2009 18:51:45 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ([114.111.62.249]) by mx.google.com with ESMTPS id j26sm5309214waf.28.2009.06.14.18.51.43 (version=SSLv3 cipher=RC4-MD5); Sun, 14 Jun 2009 18:51:44 -0700 (PDT) Received: by michelle.cdnetworks.co.kr (sSMTP sendmail emulation); Mon, 15 Jun 2009 10:55:05 +0900 From: Pyun YongHyeon Date: Mon, 15 Jun 2009 10:55:05 +0900 To: Thomas Lotterer Message-ID: <20090615015505.GB78415@michelle.cdnetworks.co.kr> References: <4A2DA8D9.2030300@lotterer.net> <20090610024959.GD63941@michelle.cdnetworks.co.kr> <4A2FF8E3.4060501@lotterer.net> <20090611002923.GA68519@michelle.cdnetworks.co.kr> <4A30FD94.4030409@lotterer.net> <20090611130557.GB68519@michelle.cdnetworks.co.kr> <4A312517.9030206@lotterer.net> <20090612055032.GD72855@michelle.cdnetworks.co.kr> <4A32BAE7.40605@lotterer.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A32BAE7.40605@lotterer.net> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: suspect bug in vge(4) 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, 15 Jun 2009 01:51:46 -0000 On Fri, Jun 12, 2009 at 10:30:31PM +0200, Thomas Lotterer wrote: > Pyun YongHyeon wrote: > >On Thu, Jun 11, 2009 at 05:39:03PM +0200, Thomas Lotterer wrote: > >>Pyun YongHyeon wrote: > >>>Could you show me dmesg output(only vge(4) related one)? > >>> > >># dmesg | grep vge > >>vge0: port 0xec00-0xecff mem > >>0xdf7ff000-0xdf7ff0ff irq 28 at device 0.0 on pci2 > >>vge0: MSIX count : 0 > >>vge0: MSI count : 1 > > > >I wonder why "Using 1 MSI messages" message is missing. > > > Never seen that message. Maybe more verbose/debug needed? > > OK, next round. Here are today's findings. I switched from statically > linked to dynamically loaded drivers to accelerate the build+test > process. Finally, the results with both vge(4) drivers dynamically > loaded and statically linked were the same. > > The good news is that the "yongari" driver actually works in one of > three or four cases. The situation with the driver when auto detecting > GigE is as already described: > > >># ifconfig vge0 > >>vge0: flags=8843 metric 0 mtu 1500 > >>options=389b > >> ether 00:40:63:xx:xx:xx > >> inet [...] > >> media: Ethernet autoselect (1000baseT ) > >> status: active > >> > >>Unfortunately, no traffic could be sent and tcpdump(1) does not show any > >>incoming packages either, not even broadcasts. > > However, sometimes the driver (incorrectly) auto selects 100BaseTX > > media: Ethernet autoselect (100baseTX ) > > in which case it works well. I was able to copy 1500MB of data from the > server and back in three parallel running CIFS connections. The > "original problem" driver always broke upload before 100MB barrier. > > >>Interesting side effect is that after that test the kernel with my > >>previous "original problem" vge(4) driver rebooted when initializing the > >>network card. No logs at this stage, sorry. Reboot did not help. Hard > >>reset did not help. Power cycle did help. Behavior was reproducible on a > >>second attempt. > > My experience after countless reboots is that both drivers always show > this problem after the "yongari" driver was loaded previously. However, > enabling "boot from VIA Ethernet" in BIOS has been found to be a better > and more reliable workaround than power cycling. Not that I want to boot > from the network, it just seems the BIOS is resetting the NIC properly. > > Also I was able to capture the error log from the screen: > > vge0: port 0xec00-0xecff mem > 0xdf7ff000-0xdf7ff0ff irg 11 at device 0.0 on pci2 > vge0: MII read timed out > vge0: failed to start MII autopoll > vge0: MII without any phy! This is message from stock vge(4). It indicates driver failed to disable a autopolling feature of MII. MII autopolling can be used to detect link state changes so stock vge(4) turned the feature on. Correct link state tracking is very important to know when it lost link, which link was established etc. The problem of MII autopolling is driver should disable autopolling feature whenever it want to access one of MII registers. So vge(4) used to disable autopolling before accessing MII registers and reenabled autopolling after the register access. To drive auto-negotiation timer and link lost/establishment mii(4) requires periodic access of MII registers so enabling/disabling time-consuming MII autpolling was one of big issue to me. In my patched vge(4), I completely removed that autopolling feature and implemented link state tracking with mii(4). Maybe this could be one of root cause why you can't establish giga link. The VIA datasheet is not clear about MII autopolling so I need more experimentation on real hardware. > panic: Assertion mtx_unowned(m) failed at /usr/src/sys/kern/kern_mutex.c:827 This looks locking bug in driver. Show me backtrace info. > Uptime: 1s > Automatic reboot in 15 seconds - press a key on the console to abort > Rebooting ... > > -- > http://thomas.lotterer.net From owner-freebsd-current@FreeBSD.ORG Mon Jun 15 02:12:42 2009 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 531A71065677 for ; Mon, 15 Jun 2009 02:12:42 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-gx0-f207.google.com (mail-gx0-f207.google.com [209.85.217.207]) by mx1.freebsd.org (Postfix) with ESMTP id 0A01C8FC1B for ; Mon, 15 Jun 2009 02:12:41 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: by gxk3 with SMTP id 3so5436350gxk.19 for ; Sun, 14 Jun 2009 19:12:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=SVko4OFBqGC9f3mQDTLbr9gExcZcxA2t5LOcNpdGqOs=; b=thyOYVnTG9jCqHsDjY6a8uxBH62Dx3aOD1cvr4n5O/Bd0zK4c631lpzAEUlaCjv7it yRlJE818CdogJq0u1j/lfRS8c6JFAhh3fK2y4GlUuMh9M5pAyzztB0Sc3WEuOHTGvzA0 Gc80+LuRdRsAaR0OCSxCzbfbtX6SqECx1l8nM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=S3wGItZCJn2KVoIQwmwsmZlqq4Vrq5qyT7HrtO4BHydopZvQeDU+BVHrw/DKJyA/Cw b1cfNM0hDgpsaFoo8eUwESkfLhD935UCk25M5G1Ssn7fnxle0hPiBpEa7J10C248kred L73H9bP3/85Mucg1PTpNwLTwtBoHetnAMiVMg= MIME-Version: 1.0 Received: by 10.151.72.2 with SMTP id z2mr12246450ybk.3.1245031961497; Sun, 14 Jun 2009 19:12:41 -0700 (PDT) In-Reply-To: <200906141427.08397.ianjhart@ntlworld.com> References: <200906132311.15359.ianjhart@ntlworld.com> <200906141427.08397.ianjhart@ntlworld.com> Date: Sun, 14 Jun 2009 19:12:41 -0700 Message-ID: From: Freddie Cash To: current@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: zpool scrub errors on 3ware 9550SXU 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, 15 Jun 2009 02:12:42 -0000 On Sun, Jun 14, 2009 at 6:27 AM, ian j hart wrote: > On Sunday 14 June 2009 09:27:22 Freddie Cash wrote: > > On Sat, Jun 13, 2009 at 3:11 PM, ian j hart > wrote: > > > [long post with long lines, sorry] > > > > > > I have the following old hardware which I'm trying to make into a > storage > > > server (back story elided). > > > > > > Tyan Thunder K8WE with dual Opteron 270 > > > 8GB REG ECC RAM > > > 3ware/AMCC 9550SXU-16 SATA controller > > > Adaptec 29160 SCSI card -> Quantum LTO3 tape > > > ChenBro case and backplanes. > > > 'don't remember' PSU. I do remember paying =C2=A398 3 years ago, so n= ot > cheap! > > > floppy > > > > > > Some Seagate Barracuda drives. Two old 500GB for the O/S and 14 new > 1.5TB > > > for > > > data (plus some spares). > > > > > > Astute readers will know that the 1.5TB units have a chequered histor= y. > > > > > > I went to considerable effort to avoid being stuck with a bricked uni= t, > > > so imagine my dismay when, just before I was about to post this, I > > > discovered there's a new issue with these drives where they reallocat= e > > > sectors, from new. > > > > > > I don't want to get sucked into a discussion about whether these disk= s > > > are faulty or not. I want to examine what seems to be a regression > > > between 7.2-RELEASE and 8-CURRENT. If you can't resist, start a threa= d > in > > > chat and CC > > > me. > > > > > > Anyway, here's the full story (from memory I'm afraid). > > > > > > All disks exported as single drives (no JBOD anymore). > > > Install current snapshot on da0 and gmirror with da1, both 500GB disk= s. > > > Create a pool with the 14 1.5TB disks. Raidz2. > > > > Are you using a single raidz2 vdev using all 14 drives? If so, that's > > probably (one of) the source of the issues. You really shouldn't use > more > > than 8 or 9 drives in a singel raidz vdev. Bad things happen. > Especially > > during resilvers and scrubs. We learned this the hard way, trying to > > replace a drive in a 24-drive raidz2 vdev. > > > > If possible, try to rebuild the pool using multiple, smaller raidz (1 o= r > 2) > > vdevs. > > Did you post this issue to the list or open a PR? No, as it's a known issue with ZFS itself, and not just the FreeBSD port. > > This is not listed in zfsknownproblems. It's listed in the OpenSolaris/Solaris documentation, best practises guides= , blog posts, and wiki entries. > > Does opensolaris have this issue? > Yes. --=20 Freddie Cash fjwcash@gmail.com From owner-freebsd-current@FreeBSD.ORG Mon Jun 15 04:37:45 2009 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 29B421065670 for ; Mon, 15 Jun 2009 04:37:45 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.179]) by mx1.freebsd.org (Postfix) with ESMTP id EF3AE8FC14 for ; Mon, 15 Jun 2009 04:37:44 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by wa-out-1112.google.com with SMTP id m38so1176673waf.27 for ; Sun, 14 Jun 2009 21:37:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:subject :message-id:reply-to:mime-version:content-type:content-disposition :user-agent; bh=FkBgoVW/MMl7/xo1ZXzxp6jBPFRyWXF3ZiGuArA1/kA=; b=FUZT2axMcOMfyTNVEm7dz+JYOnGYedNCZbXSEbVjySES05zZYb+YmDKmicmMb1jdfs D88cwfrNnjm38vkUCKmJyt4TwVEIrGrEXmWLGSFh04kxKAuoSLRRJiuvdM9GEMqROoUN NiY4t5ZVAWyxKQ+4bbh8rNVC7P51Y1XWO+M4Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:subject:message-id:reply-to:mime-version:content-type :content-disposition:user-agent; b=kILCP9KUqBM+jdTQwCGROVPsn93CUtv4C0De2wQZRMZTGwtq3iYUw0xKGnbzhCooKE f6GSnonpXHhCVTvqIqE/rXlV+9H94eQuSjA3aQeNSSxBMaqcsOGyG4eCUCuA41496Z3W BiQQa8M/CU5Zasn6L3ZTd8ZYjhXuOgW4W/TFg= Received: by 10.114.112.4 with SMTP id k4mr4316187wac.140.1245040664473; Sun, 14 Jun 2009 21:37:44 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ([114.111.62.249]) by mx.google.com with ESMTPS id m34sm5526787waf.56.2009.06.14.21.37.42 (version=SSLv3 cipher=RC4-MD5); Sun, 14 Jun 2009 21:37:43 -0700 (PDT) Received: by michelle.cdnetworks.co.kr (sSMTP sendmail emulation); Mon, 15 Jun 2009 13:41:06 +0900 From: Pyun YongHyeon Date: Mon, 15 Jun 2009 13:41:06 +0900 To: freebsd-current@freebsd.org Message-ID: <20090615044106.GC78415@michelle.cdnetworks.co.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Subject: CFT: fxp(4) 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, 15 Jun 2009 04:37:45 -0000 Please test the patch in the following URL if you have fxp(4) hardwares. The patch contains various accumulated fixes for multicast handling, bus_dma fixes, more sane initialization and enhanced lockup detection for buggy controllers. The patch also enables WOL and Rx checksum offloading for all ICH(I/O Controller Hub) based fxp(4) controllers. I guess this patch shall fix non-working fxp(4) on PAE but I couldn't test that due to lack of hardwares. The patch was generated against latest CURRENT. http://people.freebsd.org/~yongari/fxp/fxp.patch.20090615 From owner-freebsd-current@FreeBSD.ORG Mon Jun 15 07:44:19 2009 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 2553C1065672 for ; Mon, 15 Jun 2009 07:44:19 +0000 (UTC) (envelope-from ianjhart@ntlworld.com) Received: from mtaout01-winn.ispmail.ntl.com (mtaout01-winn.ispmail.ntl.com [81.103.221.47]) by mx1.freebsd.org (Postfix) with ESMTP id DEAAC8FC18 for ; Mon, 15 Jun 2009 07:44:13 +0000 (UTC) (envelope-from ianjhart@ntlworld.com) Received: from aamtaout01-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout01-winn.ispmail.ntl.com (InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP id <20090615074412.MFAN6742.mtaout01-winn.ispmail.ntl.com@aamtaout01-winn.ispmail.ntl.com>; Mon, 15 Jun 2009 08:44:12 +0100 Received: from cpc1-cove3-0-0-cust909.sol2.cable.ntl.com ([86.20.31.142]) by aamtaout01-winn.ispmail.ntl.com (InterMail vG.2.02.00.01 201-2161-120-102-20060912) with ESMTP id <20090615074410.HSPN13254.aamtaout01-winn.ispmail.ntl.com@cpc1-cove3-0-0-cust909.sol2.cable.ntl.com>; Mon, 15 Jun 2009 08:44:10 +0100 X-Virus-Scanned: amavisd-new at cpc2-cove3-0-0-cust311.sol2.cable.ntl.com Received: from gamma.private.lan (gamma.private.lan [192.168.0.12]) by cpc1-cove3-0-0-cust909.sol2.cable.ntl.com (8.14.3/8.14.3) with ESMTP id n5F7i70E015777; Mon, 15 Jun 2009 08:44:07 +0100 (BST) (envelope-from ianjhart@ntlworld.com) From: ian j hart To: freebsd-current@freebsd.org Date: Mon, 15 Jun 2009 08:44:06 +0100 User-Agent: KMail/1.9.10 References: <200906132311.15359.ianjhart@ntlworld.com> <200906141427.08397.ianjhart@ntlworld.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200906150844.07051.ianjhart@ntlworld.com> X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on cpc1-cove3-0-0-cust909.sol2.cable.ntl.com X-Cloudmark-Analysis: v=1.0 c=1 a=ERehf_AEJYYA:10 a=NLZqzBF-AAAA:8 a=9j1b5nMnVflRJ0j7BSIA:9 a=3uwRrXoBA2XqH4HQsZUA:7 a=jHSem3sT_7aIZVnpNZK5-gALfLQA:4 a=_dQi-Dcv4p4A:10 a=yfNnSpLjPolWWjHE:21 a=Fi2_HzFAWuLqeZxb:21 Cc: Freddie Cash , current@freebsd.org Subject: Re: zpool scrub errors on 3ware 9550SXU 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, 15 Jun 2009 07:44:19 -0000 On Monday 15 June 2009 03:12:41 Freddie Cash wrote: > On Sun, Jun 14, 2009 at 6:27 AM, ian j hart wrote: > > On Sunday 14 June 2009 09:27:22 Freddie Cash wrote: > > > On Sat, Jun 13, 2009 at 3:11 PM, ian j hart > > > > wrote: > > > > [long post with long lines, sorry] > > > > > > > > I have the following old hardware which I'm trying to make into a > > > > storage > > > > > > server (back story elided). > > > > > > > > Tyan Thunder K8WE with dual Opteron 270 > > > > 8GB REG ECC RAM > > > > 3ware/AMCC 9550SXU-16 SATA controller > > > > Adaptec 29160 SCSI card -> Quantum LTO3 tape > > > > ChenBro case and backplanes. > > > > 'don't remember' PSU. I do remember paying =C2=A398 3 years ago, so= not > > > > cheap! > > > > > > floppy > > > > > > > > Some Seagate Barracuda drives. Two old 500GB for the O/S and 14 new > > > > 1.5TB > > > > > > for > > > > data (plus some spares). > > > > > > > > Astute readers will know that the 1.5TB units have a chequered > > > > history. > > > > > > > > I went to considerable effort to avoid being stuck with a bricked > > > > unit, so imagine my dismay when, just before I was about to post > > > > this, I discovered there's a new issue with these drives where they > > > > reallocate sectors, from new. > > > > > > > > I don't want to get sucked into a discussion about whether these > > > > disks are faulty or not. I want to examine what seems to be a > > > > regression between 7.2-RELEASE and 8-CURRENT. If you can't resist, > > > > start a thread > > > > in > > > > > > chat and CC > > > > me. > > > > > > > > Anyway, here's the full story (from memory I'm afraid). > > > > > > > > All disks exported as single drives (no JBOD anymore). > > > > Install current snapshot on da0 and gmirror with da1, both 500GB > > > > disks. Create a pool with the 14 1.5TB disks. Raidz2. > > > > > > Are you using a single raidz2 vdev using all 14 drives? If so, that's > > > probably (one of) the source of the issues. You really shouldn't use > > > > more > > > > > than 8 or 9 drives in a singel raidz vdev. Bad things happen. > > > > Especially > > > > > during resilvers and scrubs. We learned this the hard way, trying to > > > replace a drive in a 24-drive raidz2 vdev. > > > > > > If possible, try to rebuild the pool using multiple, smaller raidz (1 > > > or > > > > 2) > > > > > vdevs. > > > > Did you post this issue to the list or open a PR? > > No, as it's a known issue with ZFS itself, and not just the FreeBSD port. > > > This is not listed in zfsknownproblems. > > It's listed in the OpenSolaris/Solaris documentation, best practises > guides, blog posts, and wiki entries. I have the Administration guide (June 2009). Page 64 =2E..configuration with 14 disks is better split into a (sic) two 7-disk gr= oupings...single-digit groupings of disks should perform better. This implies it works. Can you point to the small print, my GoogleFoo is weak. > > > Does opensolaris have this issue? > > Yes. Anyway, I broke up the pool into two groups as you suggested. As usual scrubs cleanly on 7.2. Started throwing errors within a few minute= s under 8. Then it paniced, possibly due to scrub -s. It's sat at the DB prompt if there's anything I can do. I'll need idiots gu= ide level instruction. I have a screen dump if someone want to step up. Off= list? Highlight seems to be... Memory modified after free 0xffffff0004da0c00(248) val=3D3000000 @ 0xffffff= 0004dc00 Panic: most recently used by none Cheers =2D-=20 ian j hart From owner-freebsd-current@FreeBSD.ORG Mon Jun 15 07:59:14 2009 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 8C53B106566B for ; Mon, 15 Jun 2009 07:59:14 +0000 (UTC) (envelope-from ianjhart@ntlworld.com) Received: from queueout01-winn.ispmail.ntl.com (queueout01-winn.ispmail.ntl.com [81.103.221.31]) by mx1.freebsd.org (Postfix) with ESMTP id 158B88FC1D for ; Mon, 15 Jun 2009 07:59:13 +0000 (UTC) (envelope-from ianjhart@ntlworld.com) Received: from aamtaout01-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout01-winn.ispmail.ntl.com (InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP id <20090615074412.MFAN6742.mtaout01-winn.ispmail.ntl.com@aamtaout01-winn.ispmail.ntl.com>; Mon, 15 Jun 2009 08:44:12 +0100 Received: from cpc1-cove3-0-0-cust909.sol2.cable.ntl.com ([86.20.31.142]) by aamtaout01-winn.ispmail.ntl.com (InterMail vG.2.02.00.01 201-2161-120-102-20060912) with ESMTP id <20090615074410.HSPN13254.aamtaout01-winn.ispmail.ntl.com@cpc1-cove3-0-0-cust909.sol2.cable.ntl.com>; Mon, 15 Jun 2009 08:44:10 +0100 X-Virus-Scanned: amavisd-new at cpc2-cove3-0-0-cust311.sol2.cable.ntl.com Received: from gamma.private.lan (gamma.private.lan [192.168.0.12]) by cpc1-cove3-0-0-cust909.sol2.cable.ntl.com (8.14.3/8.14.3) with ESMTP id n5F7i70E015777; Mon, 15 Jun 2009 08:44:07 +0100 (BST) (envelope-from ianjhart@ntlworld.com) From: ian j hart To: freebsd-current@freebsd.org Date: Mon, 15 Jun 2009 08:44:06 +0100 User-Agent: KMail/1.9.10 References: <200906132311.15359.ianjhart@ntlworld.com> <200906141427.08397.ianjhart@ntlworld.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200906150844.07051.ianjhart@ntlworld.com> X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on cpc1-cove3-0-0-cust909.sol2.cable.ntl.com X-Cloudmark-Analysis: v=1.0 c=1 a=ERehf_AEJYYA:10 a=NLZqzBF-AAAA:8 a=9j1b5nMnVflRJ0j7BSIA:9 a=3uwRrXoBA2XqH4HQsZUA:7 a=jHSem3sT_7aIZVnpNZK5-gALfLQA:4 a=_dQi-Dcv4p4A:10 a=yfNnSpLjPolWWjHE:21 a=Fi2_HzFAWuLqeZxb:21 Cc: Freddie Cash , current@freebsd.org Subject: Re: zpool scrub errors on 3ware 9550SXU 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, 15 Jun 2009 07:59:14 -0000 On Monday 15 June 2009 03:12:41 Freddie Cash wrote: > On Sun, Jun 14, 2009 at 6:27 AM, ian j hart wrote: > > On Sunday 14 June 2009 09:27:22 Freddie Cash wrote: > > > On Sat, Jun 13, 2009 at 3:11 PM, ian j hart > > > > wrote: > > > > [long post with long lines, sorry] > > > > > > > > I have the following old hardware which I'm trying to make into a > > > > storage > > > > > > server (back story elided). > > > > > > > > Tyan Thunder K8WE with dual Opteron 270 > > > > 8GB REG ECC RAM > > > > 3ware/AMCC 9550SXU-16 SATA controller > > > > Adaptec 29160 SCSI card -> Quantum LTO3 tape > > > > ChenBro case and backplanes. > > > > 'don't remember' PSU. I do remember paying =C2=A398 3 years ago, so= not > > > > cheap! > > > > > > floppy > > > > > > > > Some Seagate Barracuda drives. Two old 500GB for the O/S and 14 new > > > > 1.5TB > > > > > > for > > > > data (plus some spares). > > > > > > > > Astute readers will know that the 1.5TB units have a chequered > > > > history. > > > > > > > > I went to considerable effort to avoid being stuck with a bricked > > > > unit, so imagine my dismay when, just before I was about to post > > > > this, I discovered there's a new issue with these drives where they > > > > reallocate sectors, from new. > > > > > > > > I don't want to get sucked into a discussion about whether these > > > > disks are faulty or not. I want to examine what seems to be a > > > > regression between 7.2-RELEASE and 8-CURRENT. If you can't resist, > > > > start a thread > > > > in > > > > > > chat and CC > > > > me. > > > > > > > > Anyway, here's the full story (from memory I'm afraid). > > > > > > > > All disks exported as single drives (no JBOD anymore). > > > > Install current snapshot on da0 and gmirror with da1, both 500GB > > > > disks. Create a pool with the 14 1.5TB disks. Raidz2. > > > > > > Are you using a single raidz2 vdev using all 14 drives? If so, that's > > > probably (one of) the source of the issues. You really shouldn't use > > > > more > > > > > than 8 or 9 drives in a singel raidz vdev. Bad things happen. > > > > Especially > > > > > during resilvers and scrubs. We learned this the hard way, trying to > > > replace a drive in a 24-drive raidz2 vdev. > > > > > > If possible, try to rebuild the pool using multiple, smaller raidz (1 > > > or > > > > 2) > > > > > vdevs. > > > > Did you post this issue to the list or open a PR? > > No, as it's a known issue with ZFS itself, and not just the FreeBSD port. > > > This is not listed in zfsknownproblems. > > It's listed in the OpenSolaris/Solaris documentation, best practises > guides, blog posts, and wiki entries. I have the Administration guide (June 2009). Page 64 =2E..configuration with 14 disks is better split into a (sic) two 7-disk gr= oupings...single-digit groupings of disks should perform better. This implies it works. Can you point to the small print, my GoogleFoo is weak. > > > Does opensolaris have this issue? > > Yes. Anyway, I broke up the pool into two groups as you suggested. As usual scrubs cleanly on 7.2. Started throwing errors within a few minute= s under 8. Then it paniced, possibly due to scrub -s. It's sat at the DB prompt if there's anything I can do. I'll need idiots gu= ide level instruction. I have a screen dump if someone want to step up. Off= list? Highlight seems to be... Memory modified after free 0xffffff0004da0c00(248) val=3D3000000 @ 0xffffff= 0004dc00 Panic: most recently used by none Cheers =2D-=20 ian j hart From owner-freebsd-current@FreeBSD.ORG Mon Jun 15 08:08:49 2009 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 EC06C1065672 for ; Mon, 15 Jun 2009 08:08:49 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by mx1.freebsd.org (Postfix) with ESMTP id C13A58FC0C for ; Mon, 15 Jun 2009 08:08:49 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id B5662360CD1; Mon, 15 Jun 2009 04:08:48 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Mon, 15 Jun 2009 04:08:48 -0400 X-Sasl-enc: 6nEgxo4HF1PVSpNA/W/eALohAAiCWRKl3RuB755kqTua 1245053327 Received: from anglepoise.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 47CA33145F; Mon, 15 Jun 2009 04:08:47 -0400 (EDT) Message-ID: <4A36018E.2050301@incunabulum.net> Date: Mon, 15 Jun 2009 09:08:46 +0100 From: Bruce Simpson User-Agent: Thunderbird 2.0.0.21 (X11/20090406) MIME-Version: 1.0 To: pyunyh@gmail.com References: <20090615044106.GC78415@michelle.cdnetworks.co.kr> In-Reply-To: <20090615044106.GC78415@michelle.cdnetworks.co.kr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: CFT: fxp(4) 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, 15 Jun 2009 08:08:50 -0000 Pyun YongHyeon wrote: > Please test the patch in the following URL if you have fxp(4) > hardwares. The patch contains various accumulated fixes for > multicast handling, bus_dma fixes, more sane initialization > and enhanced lockup detection for buggy controllers. This is just a note to say that I *have* observed problems with multicast setup in fxp(4) -- it seems to need setting up of the link-layer hash filter for a group to transmit as well as receive. This isn't OK, NICs should be able to transmit w/o receive setup, and may break normal use-cases (esp. IPv6), I posted to freebsd-net@ about this over the past 12 months, but did not have time to reproduce or isolate the issue. So a fix is very, very welcome. Thanks for working on this. I have an fxp(4) but it's in my home server RELENG_7 box... any plans to backport? thanks, BMS From owner-freebsd-current@FreeBSD.ORG Mon Jun 15 08:45:27 2009 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 9F8E11065672 for ; Mon, 15 Jun 2009 08:45:27 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.180]) by mx1.freebsd.org (Postfix) with ESMTP id 6D48A8FC1E for ; Mon, 15 Jun 2009 08:45:27 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by wa-out-1112.google.com with SMTP id m38so1209429waf.27 for ; Mon, 15 Jun 2009 01:45:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=2JS+UGgHqf1kjGiTR3k2z+OofxRAp+k1ZnpuN6GTOIA=; b=aHfolWxR7VjF7CrrKzeXc1wxPY7Q+woZEO2Mt3lWG6NBAfeKTSrKQheR3lH6sIjAFv 2VllGcNm3sxGb7pgI5o2SR9vtbtYRxJYRcr6ZtPIjRtzmSeNpJ+0ChI3O2PhDrn++9VM Yv2D1mS3IfMNWhO8OqxYquzcwqLJd7HdtMZB0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=PITgmTQJp/wGTBKTDjS94iyHk56NBnZQ3LAka0Xg1dw/oamZzzTDeCLGxd5xywzsuU N/6dzo0VJjK8mmoISX5Mx122Oqt5zpAWsFUvIQVUOMjwigf7cbH9q1KPxFds9G6tKn+l +AVudLVqcJd1q/nwhpwFora5+hhxH5mP6WmGI= Received: by 10.114.159.6 with SMTP id h6mr11360706wae.19.1245055526772; Mon, 15 Jun 2009 01:45:26 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ([114.111.62.249]) by mx.google.com with ESMTPS id j39sm5822054waf.45.2009.06.15.01.45.25 (version=SSLv3 cipher=RC4-MD5); Mon, 15 Jun 2009 01:45:26 -0700 (PDT) Received: by michelle.cdnetworks.co.kr (sSMTP sendmail emulation); Mon, 15 Jun 2009 17:48:50 +0900 From: Pyun YongHyeon Date: Mon, 15 Jun 2009 17:48:50 +0900 To: Bruce Simpson Message-ID: <20090615084850.GD78415@michelle.cdnetworks.co.kr> References: <20090615044106.GC78415@michelle.cdnetworks.co.kr> <4A36018E.2050301@incunabulum.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A36018E.2050301@incunabulum.net> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: CFT: fxp(4) 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, 15 Jun 2009 08:45:27 -0000 On Mon, Jun 15, 2009 at 09:08:46AM +0100, Bruce Simpson wrote: > Pyun YongHyeon wrote: > >Please test the patch in the following URL if you have fxp(4) > >hardwares. The patch contains various accumulated fixes for > >multicast handling, bus_dma fixes, more sane initialization > >and enhanced lockup detection for buggy controllers. > > This is just a note to say that I *have* observed problems with > multicast setup in fxp(4) -- it seems to need setting up of the > link-layer hash filter for a group to transmit as well as receive. > I couldn't see this limitation in datasheet. So it could be a bug in stock fxp(4). > This isn't OK, NICs should be able to transmit w/o receive setup, and > may break normal use-cases (esp. IPv6), I posted to freebsd-net@ about > this over the past 12 months, but did not have time to reproduce or > isolate the issue. So a fix is very, very welcome. Thanks for working on > this. So does that patch fixed the issue? I'm not familiar with multicasting but I did my best to make fxp(4) work on multicasting environments. fxp(4) hardwares do not allow multicast hash filter programming when device is not in idle state. So stock fxp(4) used to rely on Tx completion interrupt to program multicast filters. I think that is error-prone/complex and fxp(4) can drop multicat frames until its filter is fully reprogrammed. > > I have an fxp(4) but it's in my home server RELENG_7 box... any plans to > backport? > Yeah, if the patch works. > thanks, > BMS From owner-freebsd-current@FreeBSD.ORG Mon Jun 15 10:17:56 2009 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 02FBB1065674; Mon, 15 Jun 2009 10:17:56 +0000 (UTC) (envelope-from odhiambo@gmail.com) Received: from mail-bw0-f228.google.com (mail-bw0-f228.google.com [209.85.218.228]) by mx1.freebsd.org (Postfix) with ESMTP id EA2ED8FC0C; Mon, 15 Jun 2009 10:17:54 +0000 (UTC) (envelope-from odhiambo@gmail.com) Received: by bwz28 with SMTP id 28so489300bwz.43 for ; Mon, 15 Jun 2009 03:17:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=rlPRim0D1JLSuOMe6PHbl6DohBxUAkIIBraLh3KLX/A=; b=lcIW9JiUIAM8+31fUOu8x12W7FMHcl57T7k9CeazDxkVDBoM6lBZqW9pHCL4u2D9sU KGV4XfgFsqhWnX6ryoTlPZoQ4mttGJ3//T37h7AeEdx1jMlxlCXbi5Yyhng/CF6ZoWwF uFR1sZJNbPYXt57umHFFWxobo6Req4QW6biu4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=CDV1i6YOvLMAmTG8H8/jEMCv3S94xwuQMF4RdYRlf9ycyt9fvGEEi5LciAdhfwF3Kb 0xMfed+HlndyHnoWqOJrmGQgTbTP1CibeuMCbPdkeF05UskrvkWHDIiNOVCpi6IMD0H5 ffyyAP1zra9Rg4UyBSlrEYFQ5+X/jdeueaPBY= MIME-Version: 1.0 Received: by 10.223.110.4 with SMTP id l4mr4038173fap.47.1245061073536; Mon, 15 Jun 2009 03:17:53 -0700 (PDT) In-Reply-To: <4A325423.3000606@icyb.net.ua> References: <20090611194557.GC98175@bsdcrew.de> <4A325423.3000606@icyb.net.ua> Date: Mon, 15 Jun 2009 13:17:53 +0300 Message-ID: <991123400906150317y7edb560anf74c5c1eec0cc293@mail.gmail.com> From: =?UTF-8?B?T2RoaWFtYm8gIOODr+OCt+ODs+ODiOODsw==?= To: Andriy Gapon Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: ports@freebsd.org, freebsd-emulation@freebsd.org, freebsd-current@freebsd.org, Martin Wilke Subject: Re: [Call For Testing] VirtualBox for FreeBSD! take 6 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, 15 Jun 2009 10:17:56 -0000 On Fri, Jun 12, 2009 at 4:12 PM, Andriy Gapon wrote: > on 11/06/2009 22:45 Martin Wilke said the following: > > Huhu, > > > > Yes we life and that's good :-). > > There should be a warning that this version won't start snapshots taken by > the > previous version. > My build is failing (for the first time ever since I started testing:) kmk[1]: Entering directory `/usr/home/wash/VBOX/virtualbox/work/virtualbox-2.2.51r20457' kmk[2]: Entering directory `/usr/home/wash/VBOX/virtualbox/work/virtualbox-2.2.51r20457' kBuild: Linking tstAPI /usr/local/lib/libssl.so.5: undefined reference to `d2i_X509_EXTENSIONS' /usr/local/lib/libssl.so.5: undefined reference to `ENGINE_get_ssl_client_cert_function' /usr/local/lib/libssl.so.5: undefined reference to `HMAC_CTX_set_flags' /usr/local/lib/libssl.so.5: undefined reference to `i2d_X509_EXTENSIONS' /usr/local/lib/libssl.so.5: undefined reference to `ENGINE_load_ssl_client_cert' /usr/local/lib/libssl.so.5: undefined reference to `EVP_idea_cbc' kmk[2]: *** [/usr/home/wash/VBOX/virtualbox/work/virtualbox-2.2.51r20457/out/freebsd.x86/release/obj/tstAPI/tstAPI] Error 1 The failing command: @g++ '-Wl,-rpath,/usr/local/lib/virtualbox' -m32 -o /usr/home/wash/VBOX/virtualbox/work/virtualbox-2.2.51r20457/out/freebsd.x86/release/obj/tstAPI/tstAPI /usr/home/wash/VBOX/virtualbox/work/virtualbox-2.2.51r20457/out/freebsd.x86/release/obj/tstAPI/tstAPI.o -L/usr/lib -L/usr/X11R6/lib -L/usr/local/lib /usr/home/wash/VBOX/virtualbox/work/virtualbox-2.2.51r20457/out/freebsd.x86/release/bin/VBoxRT.so /usr/home/wash/VBOX/virtualbox/work/virtualbox-2.2.51r20457/out/freebsd.x86/release/lib/VBoxCOM.a /usr/home/wash/VBOX/virtualbox/work/virtualbox-2.2.51r20457/out/freebsd.x86/release/bin/VBoxXPCOM.so kmk[2]: Leaving directory `/usr/home/wash/VBOX/virtualbox/work/virtualbox-2.2.51r20457' kmk[1]: *** [pass_binaries_this] Error 2 kmk[1]: Leaving directory `/usr/home/wash/VBOX/virtualbox/work/virtualbox-2.2.51r20457' kmk: *** [pass_binaries_order] Error 2 *** Error code 2 Stop in /usr/home/wash/VBOX/virtualbox. Not sure what is causing this. -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254733744121/+254722743223 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ "If you have nothing good to say about someone, just shut up!." -- Lucky Dube From owner-freebsd-current@FreeBSD.ORG Mon Jun 15 10:26:09 2009 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 2975C106566C; Mon, 15 Jun 2009 10:26:09 +0000 (UTC) (envelope-from miwi@bsdcrew.de) Received: from bsdcrew.de (duro.unixfreunde.de [85.214.90.4]) by mx1.freebsd.org (Postfix) with ESMTP id A9DA28FC13; Mon, 15 Jun 2009 10:26:08 +0000 (UTC) (envelope-from miwi@bsdcrew.de) Received: by bsdcrew.de (Postfix, from userid 1001) id 4E67A4AC60; Mon, 15 Jun 2009 12:26:07 +0200 (CEST) Date: Mon, 15 Jun 2009 12:26:07 +0200 From: Martin Wilke To: Odhiambo ??????????????? Message-ID: <20090615102607.GA45646@bsdcrew.de> References: <20090611194557.GC98175@bsdcrew.de> <4A325423.3000606@icyb.net.ua> <991123400906150317y7edb560anf74c5c1eec0cc293@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed Content-Disposition: inline In-Reply-To: <991123400906150317y7edb560anf74c5c1eec0cc293@mail.gmail.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: ports@freebsd.org, freebsd-emulation@freebsd.org, freebsd-current@freebsd.org, Andriy Gapon Subject: Re: [Call For Testing] VirtualBox for FreeBSD! take 6 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, 15 Jun 2009 10:26:09 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The problem is use openssl from ports. You should deinstall that and rebuild. - - Martin On Mon, Jun 15, 2009 at 01:17:53PM +0300, Odhiambo ??????????????? wrote: > On Fri, Jun 12, 2009 at 4:12 PM, Andriy Gapon wrote: > > > on 11/06/2009 22:45 Martin Wilke said the following: > > > Huhu, > > > > > > Yes we life and that's good :-). > > > > There should be a warning that this version won't start snapshots taken by > > the > > previous version. > > > > > My build is failing (for the first time ever since I started testing:) > > kmk[1]: Entering directory > `/usr/home/wash/VBOX/virtualbox/work/virtualbox-2.2.51r20457' > kmk[2]: Entering directory > `/usr/home/wash/VBOX/virtualbox/work/virtualbox-2.2.51r20457' > kBuild: Linking tstAPI > /usr/local/lib/libssl.so.5: undefined reference to `d2i_X509_EXTENSIONS' > /usr/local/lib/libssl.so.5: undefined reference to > `ENGINE_get_ssl_client_cert_function' > /usr/local/lib/libssl.so.5: undefined reference to `HMAC_CTX_set_flags' > /usr/local/lib/libssl.so.5: undefined reference to `i2d_X509_EXTENSIONS' > /usr/local/lib/libssl.so.5: undefined reference to > `ENGINE_load_ssl_client_cert' > /usr/local/lib/libssl.so.5: undefined reference to `EVP_idea_cbc' > kmk[2]: *** > [/usr/home/wash/VBOX/virtualbox/work/virtualbox-2.2.51r20457/out/freebsd.x86/release/obj/tstAPI/tstAPI] > Error 1 > The failing command: > @g++ '-Wl,-rpath,/usr/local/lib/virtualbox' -m32 -o > /usr/home/wash/VBOX/virtualbox/work/virtualbox-2.2.51r20457/out/freebsd.x86/release/obj/tstAPI/tstAPI > /usr/home/wash/VBOX/virtualbox/work/virtualbox-2.2.51r20457/out/freebsd.x86/release/obj/tstAPI/tstAPI.o > -L/usr/lib -L/usr/X11R6/lib -L/usr/local/lib > /usr/home/wash/VBOX/virtualbox/work/virtualbox-2.2.51r20457/out/freebsd.x86/release/bin/VBoxRT.so > /usr/home/wash/VBOX/virtualbox/work/virtualbox-2.2.51r20457/out/freebsd.x86/release/lib/VBoxCOM.a > /usr/home/wash/VBOX/virtualbox/work/virtualbox-2.2.51r20457/out/freebsd.x86/release/bin/VBoxXPCOM.so > kmk[2]: Leaving directory > `/usr/home/wash/VBOX/virtualbox/work/virtualbox-2.2.51r20457' > kmk[1]: *** [pass_binaries_this] Error 2 > kmk[1]: Leaving directory > `/usr/home/wash/VBOX/virtualbox/work/virtualbox-2.2.51r20457' > kmk: *** [pass_binaries_order] Error 2 > *** Error code 2 > > Stop in /usr/home/wash/VBOX/virtualbox. > > > Not sure what is causing this. > > > -- > Best regards, > Odhiambo WASHINGTON, > Nairobi,KE > +254733744121/+254722743223 > _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ > "If you have nothing good to say about someone, just shut up!." > -- Lucky Dube - -- +-----------------------+-------------------------------+ | PGP : 0xB1E6FCE9 | Jabber : miwi(at)BSDCrew.de | | Skype : splash_111 | Mail : miwi(at)FreeBSD.org | +-----------------------+-------------------------------+ | Mess with the Best, Die like the Rest! | +-----------------------+-------------------------------+ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAko2Ib4ACgkQdLJIhLHm/OkZZQCguicyAg5OlHyBD8fgdA9YSNQ0 Fe0AoI3JBdGvGmyp6lTsE3CguGCkxLeY =YVqR -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Mon Jun 15 10:30:44 2009 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 12CDC1065672; Mon, 15 Jun 2009 10:30:44 +0000 (UTC) (envelope-from odhiambo@gmail.com) Received: from mail-bw0-f228.google.com (mail-bw0-f228.google.com [209.85.218.228]) by mx1.freebsd.org (Postfix) with ESMTP id 0EDFD8FC08; Mon, 15 Jun 2009 10:30:42 +0000 (UTC) (envelope-from odhiambo@gmail.com) Received: by bwz28 with SMTP id 28so495349bwz.43 for ; Mon, 15 Jun 2009 03:30:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=QG0rIHmwVKlgiBvqLpb/Dk+GH9hCMzKMuCJLosfaZb0=; b=IJMX2sSoO06/R++R/EjnEQMJ9yZkRj169xrVQq6Wjgjyz1uZQ+9I5F1M3TMZCFGc2t kPV3HebvtDoGuM3az6BimIh1OV5Vg73TxPajxtHR/lHIYB9dFarvrLRgihx45ByTA8U4 H+ArqxhP+Y8tYGW7gXcAHI9YWH9dDV6pLkkbo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=B3U98Z1iWvpRwG0WuAh9jEC/dLQaByHqlZ2X3soM4yeqQGjHNMUtGxBa1WCqfh6K/Q 9tRKvTiB2oB7VwsAU5lANrnJRRQQRRS5bk12YBqfzO1AjxIm002zClh8eGuBNRn5s935 5XH8aA3v5Bwh33G90CN4iZNayvrlevCor+0VI= MIME-Version: 1.0 Received: by 10.223.106.148 with SMTP id x20mr3239254fao.68.1245061841838; Mon, 15 Jun 2009 03:30:41 -0700 (PDT) In-Reply-To: <20090615102607.GA45646@bsdcrew.de> References: <20090611194557.GC98175@bsdcrew.de> <4A325423.3000606@icyb.net.ua> <991123400906150317y7edb560anf74c5c1eec0cc293@mail.gmail.com> <20090615102607.GA45646@bsdcrew.de> Date: Mon, 15 Jun 2009 13:30:41 +0300 Message-ID: <991123400906150330k7f3aa11am97ea69c0d1be4768@mail.gmail.com> From: =?UTF-8?B?T2RoaWFtYm8gIOODr+OCt+ODs+ODiOODsw==?= To: Martin Wilke Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: ports@freebsd.org, freebsd-emulation@freebsd.org, freebsd-current@freebsd.org, Andriy Gapon Subject: Re: [Call For Testing] VirtualBox for FreeBSD! take 6 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, 15 Jun 2009 10:30:44 -0000 On Mon, Jun 15, 2009 at 1:26 PM, Martin Wilke wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > The problem is use openssl from ports. You should deinstall that > and rebuild. That also means that I have to relink so many of my applications to openssl from BASE, right? Why did this version of virtualbox fail with the openssl from ports? All the others installed successfully? -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254733744121/+254722743223 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ "If you have nothing good to say about someone, just shut up!." -- Lucky Dube From owner-freebsd-current@FreeBSD.ORG Mon Jun 15 10:45:17 2009 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 CF99D1065675; Mon, 15 Jun 2009 10:45:17 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from dd12710.kasserver.com (dd12710.kasserver.com [85.13.134.233]) by mx1.freebsd.org (Postfix) with ESMTP id 7D2E18FC1B; Mon, 15 Jun 2009 10:45:17 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from localhost.my.domain (cazador.sisis.de [193.31.11.193]) by dd12710.kasserver.com (Postfix) with ESMTP id D6854184ECCC0; Mon, 15 Jun 2009 12:45:17 +0200 (CEST) Received: (from guru@localhost) by localhost.my.domain (8.14.3/8.14.3/Submit) id n5FAjFKa004016; Mon, 15 Jun 2009 12:45:15 +0200 (CEST) (envelope-from guru@unixarea.de) X-Authentication-Warning: localhost.my.domain: guru set sender to guru@unixarea.de using -f Date: Mon, 15 Jun 2009 12:45:15 +0200 From: Matthias Apitz To: Odhiambo ??????????????? Message-ID: <20090615104515.GA3983@current.Sisis.de> References: <20090611194557.GC98175@bsdcrew.de> <4A325423.3000606@icyb.net.ua> <991123400906150317y7edb560anf74c5c1eec0cc293@mail.gmail.com> <20090615102607.GA45646@bsdcrew.de> <991123400906150330k7f3aa11am97ea69c0d1be4768@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <991123400906150330k7f3aa11am97ea69c0d1be4768@mail.gmail.com> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 8.0-CURRENT (i386) Cc: ports@freebsd.org, freebsd-emulation@freebsd.org, freebsd-current@freebsd.org, Andriy Gapon , Martin Wilke Subject: Re: [Call For Testing] VirtualBox for FreeBSD! take 6 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Matthias Apitz List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 10:45:18 -0000 El día Monday, June 15, 2009 a las 01:30:41PM +0300, Odhiambo ??????????????? escribió: > On Mon, Jun 15, 2009 at 1:26 PM, Martin Wilke wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > The problem is use openssl from ports. You should deinstall that > > and rebuild. > > > That also means that I have to relink so many of my applications to openssl > from BASE, right? > Why did this version of virtualbox fail with the openssl from ports? All the > others installed successfully? All, Would it be possible to discuss that software in *only* one mailing list, for example only in -emulation, and not cross posting this to three lists? thanks in advance matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.unixarea.de/ People who hate Microsoft Windows use Linux but people who love UNIX use FreeBSD. From owner-freebsd-current@FreeBSD.ORG Mon Jun 15 12:16:33 2009 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 A2E031065670; Mon, 15 Jun 2009 12:16:33 +0000 (UTC) (envelope-from uqs@spoerlein.net) Received: from acme.spoerlein.net (cl-43.dus-01.de.sixxs.net [IPv6:2a01:198:200:2a::2]) by mx1.freebsd.org (Postfix) with ESMTP id 19BB38FC26; Mon, 15 Jun 2009 12:16:32 +0000 (UTC) (envelope-from uqs@spoerlein.net) Received: from roadrunner.spoerlein.net (e180144010.adsl.alicedsl.de [85.180.144.10]) by acme.spoerlein.net (8.14.3/8.14.3) with ESMTP id n5FCGVNA021524 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 15 Jun 2009 14:16:31 +0200 (CEST) (envelope-from uqs@spoerlein.net) Received: from roadrunner.spoerlein.net (localhost [127.0.0.1]) by roadrunner.spoerlein.net (8.14.3/8.14.3) with ESMTP id n5FCGP92006289 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Jun 2009 14:16:25 +0200 (CEST) (envelope-from uqs@spoerlein.net) Received: (from uqs@localhost) by roadrunner.spoerlein.net (8.14.3/8.14.3/Submit) id n5FCGPol006288; Mon, 15 Jun 2009 14:16:25 +0200 (CEST) (envelope-from uqs@spoerlein.net) Date: Mon, 15 Jun 2009 14:16:23 +0200 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: Pyun YongHyeon Message-ID: <20090615121623.GA1479@roadrunner.spoerlein.net> Mail-Followup-To: Pyun YongHyeon , current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.5.19 (2009-01-05) Cc: current@FreeBSD.org Subject: ale(4): Problems with tso, rxcsum and/or txcsum 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, 15 Jun 2009 12:16:33 -0000 Hello Pyun, I have connection problems with the onboard GigE of an Asus P5Q board, using a recent 8-CURRENT ale0: port 0xdc00-0xdc7f mem 0xfe9c0000-0xfe9fffff irq 17 at device 0.0 on pci2 ale0: 960 Tx FIFO, 1024 Rx FIFO ale0: Using 1 MSI messages. ale0: 4GB boundary crossed, switching to 32bit DMA addressing mode. miibus0: on ale0 ale0: Ethernet address: 00:24:8c:36:3e:10 ale0: [FILTER] ale0: link state changed to UP ale0@pci0:2:0:0: class=0x020000 card=0x82261043 chip=0x10261969 rev=0xb0 hdr=0x00 vendor = 'Attansic (Now owned by Atheros)' device = 'PCI-E ETHERNET CONTROLLER (AR8121/AR8113 )' class = network subclass = ethernet ale0: flags=8843 metric 0 mtu 1500 options=311b ether 00:24:8c:36:3e:10 inet 192.168.0.146 netmask 0xffffff00 broadcast 192.168.0.255 media: Ethernet autoselect (100baseTX ) status: active When transferring data to the machine at ~10MB/s (100Mbit network only) the ssh connection will die after a couple of minutes with Disconnecting: Bad packet length 1592360521. After disabling tso, txcsum and rxcsum the connection seems to be stable, though. I fail to figure out a pattern, though. Do I need to down/up the interface for changes to tso or {tr}xcsum to have any effect? Right now I'm rsyncing several GB to the machine and the connection seems stable even though I re-activated tso, rxcum and txcsum. This is rather weird ... Are problems with this chip revision known? Cheers, Ulrich Spörlein -- http://www.dubistterrorist.de/ From owner-freebsd-current@FreeBSD.ORG Mon Jun 15 12:48:29 2009 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 507E4106564A; Mon, 15 Jun 2009 12:48:29 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.179]) by mx1.freebsd.org (Postfix) with ESMTP id 190C58FC0C; Mon, 15 Jun 2009 12:48:28 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by wa-out-1112.google.com with SMTP id m38so1240113waf.27 for ; Mon, 15 Jun 2009 05:48:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:subject :message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=ionKhtvqS2JwgS60U6gv95mZk/HReEPfTgtBRoYDUGA=; b=JLOyqGslqmNGlKZYOoryfBjbA3Oq+vMNYoX8gw0G2xysY0Ej2JIuhgpo0kRhnSDxkb dKWVdQptbdVdiGojVuS1N987fhAH6AedA6A2Y/AqMhuiWHi8Vpx5lECJEcOFotfUtuBE xmuLyXbew/Ne8HwcF0yNg4jdwuFBWQZDj8YB0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=U+gv4m5m3KD+b+trXsLnlds2zwCkCbYJdG0IIJPJFRnpSchB0fk5WWHCAE4ygVblb5 kfEB7o2umYS7jmxF/PYVgHRwOSZBN0X4n0TBfT0td+fx18MKAePuv9HCAsi17ROpWw8j RDsD3dAA0+pmPkzp9rIEMH0lmDOSF0I00GDFw= Received: by 10.114.92.18 with SMTP id p18mr11762951wab.45.1245070108663; Mon, 15 Jun 2009 05:48:28 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ([114.111.62.249]) by mx.google.com with ESMTPS id n30sm6275955wag.6.2009.06.15.05.48.26 (version=SSLv3 cipher=RC4-MD5); Mon, 15 Jun 2009 05:48:27 -0700 (PDT) Received: by michelle.cdnetworks.co.kr (sSMTP sendmail emulation); Mon, 15 Jun 2009 21:51:54 +0900 From: Pyun YongHyeon Date: Mon, 15 Jun 2009 21:51:54 +0900 To: Pyun YongHyeon , current@freebsd.org Message-ID: <20090615125154.GG78415@michelle.cdnetworks.co.kr> References: <20090615121623.GA1479@roadrunner.spoerlein.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090615121623.GA1479@roadrunner.spoerlein.net> User-Agent: Mutt/1.4.2.3i Cc: Subject: Re: ale(4): Problems with tso, rxcsum and/or txcsum 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, 15 Jun 2009 12:48:29 -0000 On Mon, Jun 15, 2009 at 02:16:23PM +0200, Ulrich Sp??rlein wrote: > Hello Pyun, > > I have connection problems with the onboard GigE of an Asus P5Q board, using a recent 8-CURRENT > > ale0: port 0xdc00-0xdc7f mem 0xfe9c0000-0xfe9fffff irq 17 at device 0.0 on pci2 > ale0: 960 Tx FIFO, 1024 Rx FIFO > ale0: Using 1 MSI messages. > ale0: 4GB boundary crossed, switching to 32bit DMA addressing mode. > miibus0: on ale0 > ale0: Ethernet address: 00:24:8c:36:3e:10 > ale0: [FILTER] > ale0: link state changed to UP > > ale0@pci0:2:0:0: class=0x020000 card=0x82261043 chip=0x10261969 rev=0xb0 hdr=0x00 > vendor = 'Attansic (Now owned by Atheros)' > device = 'PCI-E ETHERNET CONTROLLER (AR8121/AR8113 )' > class = network > subclass = ethernet > > ale0: flags=8843 metric 0 mtu 1500 > options=311b > ether 00:24:8c:36:3e:10 > inet 192.168.0.146 netmask 0xffffff00 broadcast 192.168.0.255 > media: Ethernet autoselect (100baseTX ) > status: active > > > When transferring data to the machine at ~10MB/s (100Mbit network only) the ssh > connection will die after a couple of minutes with > > Disconnecting: Bad packet length 1592360521. > > After disabling tso, txcsum and rxcsum the connection seems to be > stable, though. I fail to figure out a pattern, though. Do I need to Hmm, I think this is the second report that could be related with Rx checksum offloading. If disabling Rx checksum fix the issue, I have to disable it by default until I understand what's going on. > down/up the interface for changes to tso or {tr}xcsum to have any > effect? > No, ale(4) does not require interface reinitialization. Instead of turning off all checksum offloading try disabling Rx checksum offload first. > Right now I'm rsyncing several GB to the machine and the connection > seems stable even though I re-activated tso, rxcum and txcsum. This is > rather weird ... Are problems with this chip revision known? > No, I'm not aware of it but as I said it's second report so I guess it's real. From owner-freebsd-current@FreeBSD.ORG Mon Jun 15 13:16:23 2009 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 0CC95106566B for ; Mon, 15 Jun 2009 13:16:23 +0000 (UTC) (envelope-from uqs@spoerlein.net) Received: from acme.spoerlein.net (cl-43.dus-01.de.sixxs.net [IPv6:2a01:198:200:2a::2]) by mx1.freebsd.org (Postfix) with ESMTP id 78A3F8FC14 for ; Mon, 15 Jun 2009 13:16:22 +0000 (UTC) (envelope-from uqs@spoerlein.net) Received: from acme.spoerlein.net (localhost.spoerlein.net [127.0.0.1]) by acme.spoerlein.net (8.14.3/8.14.3) with ESMTP id n5FDGLNn022861 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Jun 2009 15:16:21 +0200 (CEST) (envelope-from uqs@spoerlein.net) Received: (from uqs@localhost) by acme.spoerlein.net (8.14.3/8.14.3/Submit) id n5FDGLBe022860; Mon, 15 Jun 2009 15:16:21 +0200 (CEST) (envelope-from uqs@spoerlein.net) Date: Mon, 15 Jun 2009 15:16:20 +0200 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: "Sam Fourman Jr." Message-ID: <20090615131620.GA22116@acme.spoerlein.net> Mail-Followup-To: "Sam Fourman Jr." , FreeBSD Current References: <11167f520906140109s52df389ode319bfded32613c@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <11167f520906140109s52df389ode319bfded32613c@mail.gmail.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: FreeBSD Current Subject: Re: FreeBSD 8.0 Asus P5Q ACPI errors 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, 15 Jun 2009 13:16:23 -0000 On Sun, 14.06.2009 at 03:09:15 -0500, Sam Fourman Jr. wrote: > hello, > > I am putting this information out there for archival pourposes, but I > was wondering if someone would know how to fix this error in the dmesg > I am not sure if this is somthing to worry about or not. I too see some ACPI warnings on an ASUS P5Q board with most recent BIOS. Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-CURRENT #0 r193930: Wed Jun 10 22:56:01 CEST 2009 uqs@roadrunner.spoerlein.net:/home/data/obj/amd64/home/data/freebsd-head/sys/GENERIC WARNING: WITNESS option enabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 Duo CPU E8600 @ 3.33GHz (3332.97-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x1067a Stepping = 10 Features=0xbfebfbff Features2=0x408e3fd AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant real memory = 4294967296 (4096 MB) avail memory = 4111298560 (3920 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ... acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of fed08000, 1000 (3) failed acpi0: reservation of fed1c000, 4000 (3) failed acpi0: reservation of fed20000, 20000 (3) failed acpi0: reservation of fed50000, 40000 (3) failed acpi0: reservation of ffc00000, 300000 (3) failed acpi0: reservation of fec00000, 1000 (3) failed acpi0: reservation of fee00000, 1000 (3) failed acpi0: reservation of e0000000, 10000000 (3) failed acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, cff00000 (3) failed ... cpu0: on acpi0 ACPI Warning: Incorrect checksum in table [OEMB] - E2, should be E1 20090521 tbutils-275 est0: on cpu0 I can provide ACPI dumps upon request. Cheers, Ulrich Spörlein -- http://www.dubistterrorist.de/ From owner-freebsd-current@FreeBSD.ORG Mon Jun 15 14:33:28 2009 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 C29E5106564A for ; Mon, 15 Jun 2009 14:33:28 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from mout2.freenet.de (mout2.freenet.de [IPv6:2001:748:100:40::2:4]) by mx1.freebsd.org (Postfix) with ESMTP id 5EDF28FC08 for ; Mon, 15 Jun 2009 14:33:28 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from [195.4.92.16] (helo=6.mx.freenet.de) by mout2.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #88) id 1MGDFX-0007HV-6e; Mon, 15 Jun 2009 16:33:27 +0200 Received: from ta650.t.pppool.de ([89.55.166.80]:19933 helo=ernst.jennejohn.org) by 6.mx.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #79) id 1MGDFW-00064D-T9; Mon, 15 Jun 2009 16:33:27 +0200 Date: Mon, 15 Jun 2009 16:33:26 +0200 From: Gary Jennejohn To: pyunyh@gmail.com Message-ID: <20090615163326.10596e69@ernst.jennejohn.org> In-Reply-To: <20090615044106.GC78415@michelle.cdnetworks.co.kr> References: <20090615044106.GC78415@michelle.cdnetworks.co.kr> X-Mailer: Claws Mail 3.7.1 (GTK+ 2.14.7; amd64-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: CFT: fxp(4) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gary.jennejohn@freenet.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 14:33:29 -0000 On Mon, 15 Jun 2009 13:41:06 +0900 Pyun YongHyeon wrote: > Please test the patch in the following URL if you have fxp(4) > hardwares. The patch contains various accumulated fixes for > multicast handling, bus_dma fixes, more sane initialization > and enhanced lockup detection for buggy controllers. The patch also > enables WOL and Rx checksum offloading for all ICH(I/O Controller > Hub) based fxp(4) controllers. > I guess this patch shall fix non-working fxp(4) on PAE but I > couldn't test that due to lack of hardwares. The patch was > generated against latest CURRENT. > I tested this on my IBM X31 laptop and didn't notice any regressions. I'm not doing anything fancy with networking so that may not mean much. --- Gary Jennejohn From owner-freebsd-current@FreeBSD.ORG Mon Jun 15 15:52:41 2009 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 38EC8106566B for ; Mon, 15 Jun 2009 15:52:41 +0000 (UTC) (envelope-from nakal@web.de) Received: from fmmailgate01.web.de (fmmailgate01.web.de [217.72.192.221]) by mx1.freebsd.org (Postfix) with ESMTP id BE62A8FC17 for ; Mon, 15 Jun 2009 15:52:40 +0000 (UTC) (envelope-from nakal@web.de) Received: from smtp07.web.de (fmsmtp07.dlan.cinetic.de [172.20.5.215]) by fmmailgate01.web.de (Postfix) with ESMTP id D3DF9105A9A4D; Mon, 15 Jun 2009 17:33:18 +0200 (CEST) Received: from [217.236.11.4] (helo=zelda.local) by smtp07.web.de with asmtp (TLSv1:AES128-SHA:128) (WEB.DE 4.110 #277) id 1MGEBS-0007S5-00; Mon, 15 Jun 2009 17:33:18 +0200 Date: Mon, 15 Jun 2009 17:33:15 +0200 From: Martin To: Rick Macklem Message-ID: <20090615173315.1cdb39e1@zelda.local> In-Reply-To: References: <4A2504AA.1020406@zedat.fu-berlin.de> <20090603235227.GB15659@hades.panopticon> X-Mailer: Claws Mail 3.7.1 (GTK+ 2.16.2; amd64-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: nakal@web.de X-Sender: nakal@web.de X-Provags-ID: V01U2FsdGVkX19SlzqOohgtddfozeEWklaDcU5dkhHIRu0C5gCR tiR7UfrJKeEUd/BqP5wKnB5T9vVd/pMleZHFOBIE+lqZBBGFBc 91Se4s34s= Cc: freebsd-current@FreeBSD.org, Dmitry Marakasov , "O. Hartmann" , Arnar Mar Sig Subject: Re: RPCPROG_MNT: RPC: Timed out / receiving NFS error when trying to mount NFS file system after make world 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, 15 Jun 2009 15:52:41 -0000 Am Fri, 5 Jun 2009 11:17:10 -0400 (EDT) schrieb Rick Macklem : > It seems that the problem is specific to "udp" and some arches. (I > can't reproduce it on i386 and at least one person sees it on amd64.) > > Maybe people who see the problem can post to the -current list, noting > what arch they are using and network config (running virtualized, what > net hardware, multiple net interfaces, etc). > > Hopefully there is some commonality among them? > > Thanks in advance for any help tracking this down, rick Hi Rick. I've got also a problem mounting nfs over tcp on my amd64 (kernel of yesterday). I tried to find out what is happening and noticed that I don't get a response back from rpcbind. This is being caused by my unusual configuration. I've got a public IP and an internal one (2 NICs). Packets sometimes arrive at one NIC and are being sent back over the other. The real problem is that rpcbind throws away the second "-h" parameter so it does not listen and use the second NIC. I verified it by rpcinfo. It does not use any ports on my second NIC that I specified in rc.conf. As a result, I removed all "-h" options, so rpcbind listens on "*.*". Using this configuration, it works. Please also be careful with the code. I've seen rpcbind adds 127.0.0.1 automatically. Please make it a warning when someone adds localhost addresses instead of showing bind errors on the interface address. It's confusing, because one may think that some other tool blocks the port or stuff like that. And... yeah... I RTFM. Still, it's confusing when you forget it. I hope, I could help you a bit. > _______________________________________________ > 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 Jun 15 16:42:58 2009 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 4D7D8106566C; Mon, 15 Jun 2009 16:42:58 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (cl-162.ewr-01.us.sixxs.net [IPv6:2001:4830:1200:a1::2]) by mx1.freebsd.org (Postfix) with ESMTP id AEC2E8FC27; Mon, 15 Jun 2009 16:42:57 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.3/8.14.3) with ESMTP id n5FGgt08008186; Mon, 15 Jun 2009 11:42:55 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.3/8.14.3/Submit) id n5FGgsDN008185; Mon, 15 Jun 2009 11:42:54 -0500 (CDT) (envelope-from brooks) Date: Mon, 15 Jun 2009 11:42:54 -0500 From: Brooks Davis To: Ed Schouten Message-ID: <20090615164254.GB7180@lor.one-eyed-alien.net> References: <538f43900906120823w388f1c63ic8d0194017faca6d@mail.gmail.com> <20090612165518.GA15530@phenom.cordula.ws> <20090612172740.GA1952@troutmask.apl.washington.edu> <20090612175206.GA77895@freebsd.org> <20090612180906.GA12679@troutmask.apl.washington.edu> <20090612193614.GF48776@hoeg.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="d6Gm4EdcadzBjdND" Content-Disposition: inline In-Reply-To: <20090612193614.GF48776@hoeg.nl> User-Agent: Mutt/1.5.17 (2007-11-01) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (lor.one-eyed-alien.net [127.0.0.1]); Mon, 15 Jun 2009 11:42:55 -0500 (CDT) Cc: Antonio Gonz?lez Castro , Roman Divacky , FreeBSD Current , cpghost , Steve Kargl Subject: Re: RFC: C version of devd daemon. 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, 15 Jun 2009 16:42:58 -0000 --d6Gm4EdcadzBjdND Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jun 12, 2009 at 09:36:14PM +0200, Ed Schouten wrote: > * Steve Kargl wrote: > > The difference is that devd is required for a functioning > > system while neither groff nor libstdc++[1] would be required. >=20 > No, it isn't. Your system just runs fine when you turn off devd. The > biggest disadvantage is probably that your USB mouse won't work when you > plug it in. devd or an equivalent replacement is mandatory for dhcp support. -- Brooks --d6Gm4EdcadzBjdND Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iD8DBQFKNnoOXY6L6fI4GtQRAjclAJ4/QkYgixTjzk3JZ45611L8nB/2qgCfbvT9 exAF/KSfmPENL8zFXOM76Ig= =jHgT -----END PGP SIGNATURE----- --d6Gm4EdcadzBjdND-- From owner-freebsd-current@FreeBSD.ORG Mon Jun 15 18:08:39 2009 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 CA024106564A for ; Mon, 15 Jun 2009 18:08:39 +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 803958FC16 for ; Mon, 15 Jun 2009 18:08:39 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1MGGbl-0002l3-Va for freebsd-current@freebsd.org; Mon, 15 Jun 2009 18:08:38 +0000 Received: from 93-141-49-23.adsl.net.t-com.hr ([93.141.49.23]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 15 Jun 2009 18:08:37 +0000 Received: from ivoras by 93-141-49-23.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 15 Jun 2009 18:08:37 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Mon, 15 Jun 2009 20:07:45 +0200 Lines: 33 Message-ID: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig5107EF8E60CB16FCA7877470" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 93-141-49-23.adsl.net.t-com.hr User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) X-Enigmail-Version: 0.95.7 Sender: news Cc: freebsd-hackers@freebsd.org Subject: tmpfs experimental? 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, 15 Jun 2009 18:08:40 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5107EF8E60CB16FCA7877470 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Are there still known problems with tmpfs? I've been using it for a while in 7-STABLE and 8-CURRENT without noticeable problems - not that there was ever serious load involved (normal /tmp activity). I've just tried it and it survived a couple of rounds of blogbench, even with virtual memory swapping. In other words, is there still reason for the "highly experimental feature" warning? --------------enig5107EF8E60CB16FCA7877470 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAko2jfEACgkQldnAQVacBcghfgCgmHlmf5VtNzqGpIOAppZQXtMw mD0AoJFDUbFSWi6QAAhvr6oFai+R6ckL =xyYD -----END PGP SIGNATURE----- --------------enig5107EF8E60CB16FCA7877470-- From owner-freebsd-current@FreeBSD.ORG Mon Jun 15 18:16:05 2009 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 95EE1106564A for ; Mon, 15 Jun 2009 18:16:05 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from vlakno.cz (77-93-215-190.static.masterinter.net [77.93.215.190]) by mx1.freebsd.org (Postfix) with ESMTP id 4D3C78FC1B for ; Mon, 15 Jun 2009 18:16:03 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from localhost (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id AE53A9CB0E6; Mon, 15 Jun 2009 20:15:58 +0200 (CEST) X-Virus-Scanned: amavisd-new at vlakno.cz Received: from vlakno.cz ([127.0.0.1]) by localhost (lev.vlakno.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UVYyx2t41yoi; Mon, 15 Jun 2009 20:15:56 +0200 (CEST) Received: from vlk.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 029449CB19F; Mon, 15 Jun 2009 20:15:55 +0200 (CEST) Received: (from rdivacky@localhost) by vlk.vlakno.cz (8.14.3/8.14.3/Submit) id n5FIFt2S060617; Mon, 15 Jun 2009 20:15:55 +0200 (CEST) (envelope-from rdivacky) Date: Mon, 15 Jun 2009 20:15:55 +0200 From: Roman Divacky To: current@freebsd.org Message-ID: <20090615181555.GA52009@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vkogqOf2sHV7VnPd" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: jkim@freebsd.org Subject: [RFC]: (void)0 instead of empty defines 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, 15 Jun 2009 18:16:06 -0000 --vkogqOf2sHV7VnPd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable hi in many places we do something like #ifdef SOMETHING #define FOO some_code #else #define FOO #endif I propose to change the second FOO to (void)0 in many places to 1) let this compile cleanly with clang. Clang warns in many places about if (cond) FOO; which has empty if body 2) enforces ; at the end of the expression this does not cost us nothing so I hope this change is ok. patch at: http://www.vlakno.cz/~rdivacky/void-zero.patch = = =20 what do you think? roman p.s. there's also ACPI_DEBUG_PRINT in contrib/acpica which I hope jkim might handle --vkogqOf2sHV7VnPd Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAko2j9sACgkQLVEj6D3CBEzNUACggK81o7hhRvkdYZY9f7qxUXwp AC4Anj/0uBALxsz0TPl4JOyIrCnhraBW =v6i0 -----END PGP SIGNATURE----- --vkogqOf2sHV7VnPd-- From owner-freebsd-current@FreeBSD.ORG Mon Jun 15 18:30:52 2009 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 D08D41065672; Mon, 15 Jun 2009 18:30:52 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.delphij.net (delphij-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:2c9::2]) by mx1.freebsd.org (Postfix) with ESMTP id 74CD28FC1F; Mon, 15 Jun 2009 18:30:52 +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 99B8D5C06F; Tue, 16 Jun 2009 02:30:51 +0800 (CST) Received: from localhost (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id 63BEC55CD43A; Tue, 16 Jun 2009 02:30: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 lWzF3zfT13M0; Tue, 16 Jun 2009 02:30:00 +0800 (CST) Received: from charlie.delphij.net (adsl-76-237-33-62.dsl.pltn13.sbcglobal.net [76.237.33.62]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id 4C74155CD44A; Tue, 16 Jun 2009 02:29:54 +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=kUS5zaMEJsT97gtHRxhWreomeYLMWsG+j2KZ4QRtA/+WmAEZJA2ORBpa92NKyxKTc JSapSsX2z9KR9LgSaA0pw== Message-ID: <4A36930F.2000302@delphij.net> Date: Mon, 15 Jun 2009 11:29:35 -0700 From: Xin LI Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.21 (X11/20090408) MIME-Version: 1.0 To: Ivan Voras References: In-Reply-To: X-Enigmail-Version: 0.95.7 OpenPGP: id=18EDEBA0; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: tmpfs experimental? 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: Mon, 15 Jun 2009 18:30:53 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ivan Voras wrote: > Hi, > > Are there still known problems with tmpfs? > > I've been using it for a while in 7-STABLE and 8-CURRENT without > noticeable problems - not that there was ever serious load involved > (normal /tmp activity). I've just tried it and it survived a couple of > rounds of blogbench, even with virtual memory swapping. > > In other words, is there still reason for the "highly experimental > feature" warning? Last time when I added the warning, it was because some data corruption issue that can be identified by fsx which I didn't got a chance to investigate further. I think tmpfs is Ok for some usual work but maybe not ready for production at that moment. alc@ and kib@ has made a lot of changes on it recently so perhaps we need to re-visit the problems, tmpfs would be a great feature for us. Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAko2kw8ACgkQi+vbBBjt66D8LwCgiEevv8qy5pl/b73rDhXU6oso jr0AoLKo/WGvoLOU7HrivC8KK2yidKo+ =alk6 -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Mon Jun 15 18:31:56 2009 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 E3F42106566B; Mon, 15 Jun 2009 18:31:56 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (cl-162.ewr-01.us.sixxs.net [IPv6:2001:4830:1200:a1::2]) by mx1.freebsd.org (Postfix) with ESMTP id 2B3728FC22; Mon, 15 Jun 2009 18:31:55 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.3/8.14.3) with ESMTP id n5FIW7Nk009081; Mon, 15 Jun 2009 13:32:07 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.3/8.14.3/Submit) id n5FIW7Wh009080; Mon, 15 Jun 2009 13:32:07 -0500 (CDT) (envelope-from brooks) Date: Mon, 15 Jun 2009 13:32:07 -0500 From: Brooks Davis To: Mark Murray Message-ID: <20090615183207.GC7180@lor.one-eyed-alien.net> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TakKZr9L6Hm6aLOc" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (lor.one-eyed-alien.net [127.0.0.1]); Mon, 15 Jun 2009 13:32:07 -0500 (CDT) Cc: current@freebsd.org Subject: Re: Knobs for src/Make* for SVN "make update" (patch attached) 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, 15 Jun 2009 18:31:57 -0000 --TakKZr9L6Hm6aLOc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jun 14, 2009 at 11:08:19AM +0100, Mark Murray wrote: > Hi >=20 > Any comments on the attached patch to allow "make update" to work with > SVN? This time the actual patch is enclosed. :-] >=20 > Any brave soul prepared to officially review it? :-) It basically looks fine to me. I'm not sure why SVNFLAGS needs to be set at all though. Isn't -rHEAD implicit? -- Brooks Content-Description: src_makefile.diff > Index: Makefile.inc1 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- Makefile.inc1 (revision 194177) > +++ Makefile.inc1 (working copy) > @@ -94,6 +94,8 @@ > =20 > CVS?=3D cvs > CVSFLAGS?=3D -A -P -d -I! > +SVN?=3D svn > +SVNFLAGS?=3D -r HEAD > SUP?=3D /usr/bin/csup > SUPFLAGS?=3D -g -L 2 > .if defined(SUPHOST) > @@ -854,11 +867,25 @@ > .endif > .endif > .if defined(CVS_UPDATE) > - @echo "--------------------------------------------------------------" > - @echo ">>> Updating ${.CURDIR} from CVS repository" ${CVSROOT} > - @echo "--------------------------------------------------------------" > - cd ${.CURDIR}; ${CVS} -R -q update ${CVSFLAGS} > + @cd ${.CURDIR} ; \ > + if [ -d CVS ] ; then \ > + echo "--------------------------------------------------------------" = ; \ > + echo ">>> Updating ${.CURDIR} from CVS repository" ${CVSROOT} ; \ > + echo "--------------------------------------------------------------" = ; \ > + echo ${CVS} -R -q update ${CVSFLAGS} ; \ > + ${CVS} -R -q update ${CVSFLAGS} ; \ > + fi > .endif > +.if defined(SVN_UPDATE) > + @cd ${.CURDIR} ; \ > + if [ -d .svn ] ; then \ > + echo "--------------------------------------------------------------" = ; \ > + echo ">>> Updating ${.CURDIR} using Subversion" ; \ > + echo "--------------------------------------------------------------" = ; \ > + echo ${SVN} update ${SVNFLAGS} ; \ > + ${SVN} update ${SVNFLAGS} ; \ > + fi > +.endif > =20 > # > # ----------------------------------------------------------------------= -- > _______________________________________________ > 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" --TakKZr9L6Hm6aLOc Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iD8DBQFKNpOnXY6L6fI4GtQRAg5iAKCrDtotqxInQMnK2wqLpj3mfLNRFgCdFy2O xlVJ9B0MVvBhukYAjU9Gnjg= =CK+U -----END PGP SIGNATURE----- --TakKZr9L6Hm6aLOc-- From owner-freebsd-current@FreeBSD.ORG Mon Jun 15 18:38:34 2009 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 8F7C210656A8 for ; Mon, 15 Jun 2009 18:38:34 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 657468FC23 for ; Mon, 15 Jun 2009 18:38:34 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id n5FIcXZo064967 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Jun 2009 11:38:34 -0700 (PDT) (envelope-from sam@freebsd.org) Message-ID: <4A369529.5090004@freebsd.org> Date: Mon, 15 Jun 2009 11:38:33 -0700 From: Sam Leffler Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.21 (X11/20090411) MIME-Version: 1.0 To: Roman Divacky References: <20090615181555.GA52009@freebsd.org> In-Reply-To: <20090615181555.GA52009@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC-Misty-Metrics: ebb.errno.com; whitelist Cc: current@freebsd.org Subject: Re: [RFC]: (void)0 instead of empty defines 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, 15 Jun 2009 18:38:35 -0000 Roman Divacky wrote: > hi > > in many places we do something like > > #ifdef SOMETHING > #define FOO some_code > #else > #define FOO > #endif > > > I propose to change the second FOO to (void)0 in many places to > > 1) let this compile cleanly with clang. Clang warns in many places > about > if (cond) > FOO; > > which has empty if body > > 2) enforces ; at the end of the expression > > this does not cost us nothing so I hope this change is ok. > > patch at: http://www.vlakno.cz/~rdivacky/void-zero.patch > > what do you think? > > roman > > p.s. there's also ACPI_DEBUG_PRINT in contrib/acpica which I hope > jkim might handle > Are you saying that: if (cond) ; is considered worthy of a warning by the compiler? Is it just "if" or all conditional control constructs (e.g. while)? I can image many instances of this construct arising from debugging facilities. This sounds like a stupid restriction and I would argue we should just disable the warning. Sam From owner-freebsd-current@FreeBSD.ORG Mon Jun 15 16:46:53 2009 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 B997F1065673 for ; Mon, 15 Jun 2009 16:46:53 +0000 (UTC) (envelope-from ibb27@yahoo.co.uk) Received: from web25007.mail.ukl.yahoo.com (web25007.mail.ukl.yahoo.com [217.146.183.110]) by mx1.freebsd.org (Postfix) with SMTP id A9FD38FC19 for ; Mon, 15 Jun 2009 16:46:52 +0000 (UTC) (envelope-from ibb27@yahoo.co.uk) Received: (qmail 10535 invoked by uid 60001); 15 Jun 2009 16:20:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.uk; s=s1024; t=1245082811; bh=T3g6v9qBmN8C2wnLM4mv3iaSSZSDttdN35quEYin7OE=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=RkROpDGhjRqEjRykueCYl77UM2nvQqL5wX9LqkKuGpbZGXMrC5MLRFmor/7O/lI+Wl6rCL6n36VYCpPseX0I4xUHdRt2dLmo3XNvJELi1OOpz1XUfCk4o26X6md63U6bM6WL6z7+yxbsiafTh/7WIrlP13HINhQVyh5f0HweJ5c= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.uk; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=jzhLMUbcdVK6qGvqlxp+Fls21+QytrgxjxMQzKM4eHaVmoqTiYtaBuFaJTlTrniFpWpoY5OduneSOS9/jHhcdzzUcjf2UMUTjNESlYt1kRji4zwEPkA5AN0IxchZwYwJ/0u9hWbNP4PbDD8PLIAJhEVN7yRsYtQvcp6IUq3fwNg=; Message-ID: <549859.9626.qm@web25007.mail.ukl.yahoo.com> X-YMail-OSG: _pE.K6UVM1lb1EPS.7WO55x2q35YDuSAAovRdbJVQC.3vsczNTt_mE4Bv7pVxOwrNDDCrrQdibj_UcAzkJM_iBbCgczGjyUqqDx7IewBHA3mudAumbj8Vm7v8o79XvooxnPXvh0rAwg0acP9DdM45G2NiiAwxtZ9aICPKROdLT6SfNSLy.wVuhyq1ojIyKJWja11JOGAivD9YQsdG.tQxeOGerZRGtVoHH1KePwx9XoMhoktRDrf1Gayg.DBsuYEJlUz02Szww4J1Gs1V0Mwmp_JExmKH9FiiebVSRo5g8IIsrsOfSVXq2tPXJA8THJCbcLy9iJkwih9.JtXLqiyCJI4qKL6CdnyrFfWlw-- Received: from [77.85.139.230] by web25007.mail.ukl.yahoo.com via HTTP; Mon, 15 Jun 2009 16:20:11 GMT X-Mailer: YahooMailClassic/5.4.12 YahooMailWebService/0.7.289.15 Date: Mon, 15 Jun 2009 16:20:11 +0000 (GMT) From: Ivailo Bonev To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Mon, 15 Jun 2009 18:45:00 +0000 Subject: LOR:vfs_bio.c and ufs_dirhash.c 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, 15 Jun 2009 16:46:54 -0000 I've installed 8-CURRENT on my HP laptop, snapshot from pub.allbsd.org with= HEAD sources from yesterday, but on first startup I see LOR. Everything wo= rks ok, though...=20 Here is log from messages: kernel: Copyright (c) 1992-2009 The FreeBSD Project. kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993,= 1994 kernel: The Regents of the University of California. All rights reserved. kernel: FreeBSD is a registered trademark of The FreeBSD Foundation. kernel: FreeBSD 8.0-HEAD-20090615-JPSNAP #0: Mon Jun 15 02:22:17 UTC 2009 kernel: root@build-i386-fbsd-2.allbsd.org:/usr/obj/i386/usr/src/sys/GENERIC kernel: WARNING: WITNESS option enabled, expect reduced performance. kernel: Timecounter "i8254" frequency 1193182 Hz quality 0 Jun 15 17:42:22 ibb kernel: CPU: Pentium(R) Dual-Core CPU T4200 @ 2.= 00GHz (1995.25-MHz 686-class CPU) Jun 15 17:42:22 ibb kernel: Origin =3D "GenuineIntel" Id =3D 0x1067a Step= ping =3D 10 Jun 15 17:42:22 ibb kernel: Features=3D0xbfebfbff Jun 15 17:42:22 ibb kernel: Features2=3D0x400e39d Jun 15 17:42:22 ibb kernel: AMD Features=3D0x20100000 Jun 15 17:42:22 ibb kernel: AMD Features2=3D0x1 Jun 15 17:42:22 ibb kernel: TSC: P-state invariant Jun 15 17:42:22 ibb kernel: real memory =3D 2147483648 (2048 MB) Jun 15 17:42:22 ibb kernel: avail memory =3D 2083385344 (1986 MB) Jun 15 17:42:22 ibb kernel: ACPI APIC Table: Jun 15 17:42:22 ibb kernel: FreeBSD/SMP: Multiprocessor System Detected: 2 = CPUs Jun 15 17:42:22 ibb kernel: FreeBSD/SMP: 1 package(s) x 2 core(s) Jun 15 17:42:22 ibb kernel: cpu0 (BSP): APIC ID: 0 Jun 15 17:42:22 ibb kernel: cpu1 (AP): APIC ID: 1 Jun 15 17:42:22 ibb kernel: ioapic0: Changing APIC ID to 1 Jun 15 17:42:22 ibb kernel: ioapic0 irqs 0-23 on motherboard Jun 15 17:42:22 ibb kernel: kbd1 at kbdmux0 Jun 15 17:42:22 ibb kernel: acpi0: on motherboard Jun 15 17:42:22 ibb kernel: acpi0: [ITHREAD] Jun 15 17:42:22 ibb kernel: acpi0: Power Button (fixed) Jun 15 17:42:22 ibb kernel: Timecounter "HPET" frequency 14318180 Hz qualit= y 900 Jun 15 17:42:22 ibb kernel: Timecounter "ACPI-fast" frequency 3579545 Hz qu= ality 1000 Jun 15 17:42:22 ibb kernel: acpi_timer0: <24-bit timer at 3.579545MHz> port= 0x408-0x40b on acpi0 Jun 15 17:42:22 ibb kernel: acpi_ec0: port = 0x62,0x66 on acpi0 Jun 15 17:42:22 ibb kernel: pcib0: port 0xcf8-0xcff = on acpi0 Jun 15 17:42:22 ibb kernel: pci0: on pcib0 Jun 15 17:42:22 ibb kernel: pcib1: irq 16 at device 1= .0 on pci0 Jun 15 17:42:22 ibb kernel: pci1: on pcib1 Jun 15 17:42:22 ibb kernel: vgapci0: port 0x7000-0= x70ff mem 0x80000000-0x8fffffff,0x98400000-0x9840ffff irq 16 at device 0.0 = on pci1 Jun 15 17:42:22 ibb kernel: uhci0: por= t 0x80c0-0x80df irq 16 at device 26.0 on pci0 Jun 15 17:42:22 ibb kernel: uhci0: [ITHREAD] Jun 15 17:42:22 ibb kernel: uhci0: LegSup =3D 0x0f00 Jun 15 17:42:22 ibb kernel: usbus0: on= uhci0 Jun 15 17:42:22 ibb kernel: uhci1: por= t 0x80a0-0x80bf irq 17 at device 26.1 on pci0 Jun 15 17:42:22 ibb kernel: uhci1: [ITHREAD] Jun 15 17:42:22 ibb kernel: uhci1: LegSup =3D 0x0f00 Jun 15 17:42:22 ibb kernel: usbus1: on= uhci1 Jun 15 17:42:22 ibb kernel: uhci2: por= t 0x8080-0x809f irq 18 at device 26.2 on pci0 Jun 15 17:42:22 ibb kernel: uhci2: [ITHREAD] Jun 15 17:42:22 ibb kernel: uhci2: LegSup =3D 0x0f00 Jun 15 17:42:22 ibb kernel: usbus2: on= uhci2 Jun 15 17:42:22 ibb kernel: ehci0: = mem 0x98504c00-0x98504fff irq 19 at device 26.7 on pci0 Jun 15 17:42:22 ibb kernel: ehci0: [ITHREAD] Jun 15 17:42:22 ibb kernel: usbus3: EHCI version 1.0 Jun 15 17:42:22 ibb kernel: usbus3: on ehci0 Jun 15 17:42:22 ibb kernel: pci0: at device 27.0 (no driv= er attached) Jun 15 17:42:22 ibb kernel: pcib2: irq 16 at device 2= 8.0 on pci0 Jun 15 17:42:22 ibb kernel: pci2: on pcib2 Jun 15 17:42:22 ibb kernel: pcib3: irq 17 at device 2= 8.1 on pci0 Jun 15 17:42:22 ibb kernel: pci3: on pcib3 Jun 15 17:42:22 ibb kernel: pci3: at device 0.0 (no driver attach= ed) Jun 15 17:42:22 ibb kernel: pcib4: irq 18 at device 2= 8.2 on pci0 Jun 15 17:42:22 ibb kernel: pci4: on pcib4 Jun 15 17:42:22 ibb kernel: pcib5: irq 16 at device 2= 8.4 on pci0 Jun 15 17:42:22 ibb kernel: pci69: on pcib5 Jun 15 17:42:22 ibb kernel: pcib6: irq 17 at device 2= 8.5 on pci0 Jun 15 17:42:22 ibb kernel: pci134: on pcib6 Jun 15 17:42:22 ibb kernel: mskc0: = port 0x2000-0x20ff mem 0x90100000-0x90103fff irq 17 at device 0.0 on pci13= 4 Jun 15 17:42:22 ibb kernel: msk0: on mskc0 Jun 15 17:42:22 ibb kernel: msk0: Ethernet address: 00:24:81:47:09:c0 Jun 15 17:42:22 ibb kernel: miibus0: on msk0 Jun 15 17:42:22 ibb kernel: e1000phy0: PHY 0 = on miibus0 Jun 15 17:42:22 ibb kernel: e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 10= 0baseTX-FDX, 1000baseT, 1000baseT-FDX, auto Jun 15 17:42:22 ibb kernel: mskc0: [FILTER] Jun 15 17:42:22 ibb kernel: uhci3: por= t 0x8060-0x807f irq 20 at device 29.0 on pci0 Jun 15 17:42:22 ibb kernel: uhci3: [ITHREAD] Jun 15 17:42:22 ibb kernel: uhci3: LegSup =3D 0x0f00 Jun 15 17:42:22 ibb kernel: usbus4: on= uhci3 Jun 15 17:42:22 ibb kernel: uhci4: por= t 0x8040-0x805f irq 22 at device 29.1 on pci0 Jun 15 17:42:22 ibb kernel: uhci4: [ITHREAD] Jun 15 17:42:22 ibb kernel: uhci4: LegSup =3D 0x0f00 Jun 15 17:42:22 ibb kernel: usbus5: on= uhci4 Jun 15 17:42:22 ibb kernel: uhci5: por= t 0x8020-0x803f irq 18 at device 29.2 on pci0 Jun 15 17:42:22 ibb kernel: uhci5: [ITHREAD] Jun 15 17:42:22 ibb kernel: uhci5: LegSup =3D 0x0f00 Jun 15 17:42:22 ibb kernel: usbus6: on= uhci5 Jun 15 17:42:22 ibb kernel: ehci1: = mem 0x98504800-0x98504bff irq 20 at device 29.7 on pci0 Jun 15 17:42:22 ibb kernel: ehci1: [ITHREAD] Jun 15 17:42:22 ibb kernel: usbus7: EHCI version 1.0 Jun 15 17:42:22 ibb kernel: usbus7: on ehci1 Jun 15 17:42:22 ibb kernel: pcib7: at device 30.0 on = pci0 Jun 15 17:42:22 ibb kernel: pci135: on pcib7 Jun 15 17:42:22 ibb kernel: isab0: at device 31.0 on pci0 Jun 15 17:42:22 ibb kernel: isa0: on isab0 Jun 15 17:42:22 ibb kernel: atapci0: port 0x80e8-0x= 80ef,0x80f4-0x80f7,0x80e0-0x80e7,0x80f0-0x80f3,0x8000-0x801f mem 0x98504000= -0x985047ff irq 21 at device 31.2 on pci0 Jun 15 17:42:22 ibb kernel: atapci0: [ITHREAD] Jun 15 17:42:22 ibb kernel: atapci0: AHCI v1.20 controller with 4 3Gbps por= ts, PM not supported Jun 15 17:42:22 ibb kernel: ata2: on atapci0 Jun 15 17:42:22 ibb kernel: ata2: [ITHREAD] Jun 15 17:42:22 ibb kernel: ata3: on atapci0 Jun 15 17:42:22 ibb kernel: ata3: [ITHREAD] Jun 15 17:42:22 ibb kernel: ata4: on atapci0 Jun 15 17:42:22 ibb kernel: ata4: [ITHREAD] Jun 15 17:42:22 ibb kernel: battery0: on acpi= 0 Jun 15 17:42:22 ibb kernel: acpi_acad0: on acpi0 Jun 15 17:42:22 ibb kernel: acpi_button0: on acpi0 Jun 15 17:42:22 ibb kernel: acpi_lid0: on acpi0 Jun 15 17:42:22 ibb kernel: acpi_tz0: on acpi0 Jun 15 17:42:22 ibb kernel: acpi_tz1: on acpi0 Jun 15 17:42:22 ibb kernel: acpi_tz1: _CRT value is absurd, ignored (256.0C= ) Jun 15 17:42:22 ibb kernel: acpi_tz2: on acpi0 Jun 15 17:42:22 ibb kernel: acpi_tz3: on acpi0 Jun 15 17:42:22 ibb kernel: acpi_tz4: on acpi0 Jun 15 17:42:22 ibb kernel: acpi_tz5: on acpi0 Jun 15 17:42:22 ibb kernel: atrtc0: port 0x70-0x77 irq = 8 on acpi0 Jun 15 17:42:22 ibb kernel: atrtc0: Warning: Couldn't map I/O. Jun 15 17:42:22 ibb kernel: atkbdc0: port 0x6= 0,0x64 irq 1 on acpi0 Jun 15 17:42:22 ibb kernel: atkbd0: irq 1 on atkbdc0 Jun 15 17:42:22 ibb kernel: kbd0 at atkbd0 Jun 15 17:42:22 ibb kernel: atkbd0: [GIANT-LOCKED] Jun 15 17:42:22 ibb kernel: atkbd0: [ITHREAD] Jun 15 17:42:22 ibb kernel: psm0: irq 12 on atkbdc0 Jun 15 17:42:22 ibb kernel: psm0: [GIANT-LOCKED] Jun 15 17:42:22 ibb kernel: psm0: [ITHREAD] Jun 15 17:42:22 ibb kernel: psm0: model IntelliMouse, device ID 3 Jun 15 17:42:22 ibb kernel: cpu0: on acpi0 Jun 15 17:42:22 ibb kernel: est0: on= cpu0 Jun 15 17:42:22 ibb kernel: p4tcc0: on cpu0 Jun 15 17:42:22 ibb kernel: cpu1: on acpi0 Jun 15 17:42:22 ibb kernel: est1: on= cpu1 Jun 15 17:42:22 ibb kernel: p4tcc1: on cpu1 Jun 15 17:42:22 ibb kernel: pmtimer0 on isa0 Jun 15 17:42:22 ibb kernel: sc0: at flags 0x100 on isa0 Jun 15 17:42:22 ibb kernel: sc0: VGA <16 virtual consoles, flags=3D0x300> Jun 15 17:42:22 ibb kernel: vga0: at port 0x3c0-0x3df iom= em 0xa0000-0xbffff on isa0 Jun 15 17:42:22 ibb kernel: ata0 at port 0x1f0-0x1f7,0x3f6 irq 14 on isa0 Jun 15 17:42:22 ibb kernel: ata0: [ITHREAD] Jun 15 17:42:22 ibb kernel: ata1 at port 0x170-0x177,0x376 irq 15 on isa0 Jun 15 17:42:22 ibb kernel: ata1: [ITHREAD] Jun 15 17:42:22 ibb kernel: Timecounters tick every 1.000 msec Jun 15 17:42:22 ibb kernel: usbus1: 12Mbps Full Speed USB v1.0 Jun 15 17:42:22 ibb kernel: usbus2: 12Mbps Full Speed USB v1.0 Jun 15 17:42:22 ibb kernel: usbus3: 480Mbps High Speed USB v2.0 Jun 15 17:42:22 ibb kernel: usbus4: 12Mbps Full Speed USB v1.0 Jun 15 17:42:22 ibb kernel: usbus5: 12Mbps Full Speed USB v1.0 Jun 15 17:42:22 ibb kernel: usbus6: 12Mbps Full Speed USB v1.0 Jun 15 17:42:22 ibb kernel: usbus7: 480Mbps High Speed USB v2.0 Jun 15 17:42:22 ibb kernel: usbus0: 12Mbps Full Speed USB v1.0 Jun 15 17:42:22 ibb kernel: ugen1.1: at usbus1 Jun 15 17:42:22 ibb kernel: uhub0: on usbus1 Jun 15 17:42:22 ibb kernel: ugen2.1: at usbus2 Jun 15 17:42:22 ibb kernel: uhub1: on usbus2 Jun 15 17:42:22 ibb kernel: ugen3.1: at usbus3 Jun 15 17:42:22 ibb kernel: uhub2: on usbus3 Jun 15 17:42:22 ibb kernel: ugen4.1: at usbus4 Jun 15 17:42:22 ibb kernel: uhub3: on usbus4 Jun 15 17:42:22 ibb kernel: ugen5.1: at usbus5 Jun 15 17:42:22 ibb kernel: uhub4: on usbus5 Jun 15 17:42:22 ibb kernel: ugen6.1: at usbus6 Jun 15 17:42:22 ibb kernel: uhub5: on usbus6 Jun 15 17:42:22 ibb kernel: ugen7.1: at usbus7 Jun 15 17:42:22 ibb kernel: uhub6: on usbus7 Jun 15 17:42:22 ibb kernel: ugen0.1: at usbus0 Jun 15 17:42:22 ibb kernel: uhub7: on usbus0 Jun 15 17:42:22 ibb kernel: ad4: 238475MB at ata2-master SATA300 Jun 15 17:42:22 ibb kernel: acpi_tz1: _CRT value is absurd, ignored (256.0C= ) Jun 15 17:42:22 ibb kernel: acd0: DVDR at at= a3-master SATA150 Jun 15 17:42:22 ibb kernel: SMP: AP CPU #1 Launched! Jun 15 17:42:22 ibb kernel: WARNING: WITNESS option enabled, expect reduced= performance. Jun 15 17:42:22 ibb kernel: uhub0: 2 ports with 2 removable, self powered Jun 15 17:42:22 ibb kernel: uhub1: 2 ports with 2 removable, self powered Jun 15 17:42:22 ibb kernel: uhub3: 2 ports with 2 removable, self powered Jun 15 17:42:22 ibb kernel: uhub4: 2 ports with 2 removable, self powered Jun 15 17:42:22 ibb kernel: uhub5: 2 ports with 2 removable, self powered Jun 15 17:42:22 ibb kernel: uhub7: 2 ports with 2 removable, self powered Jun 15 17:42:22 ibb kernel: GEOM: ad4s2: geometry does not match label (255= h,63s !=3D 16h,63s). Jun 15 17:42:22 ibb kernel: Root mount waiting for: usbus7 usbus3 Jun 15 17:42:22 ibb last message repeated 2 times Jun 15 17:42:22 ibb kernel: uhub2: 6 ports with 6 removable, self powered Jun 15 17:42:22 ibb kernel: uhub6: 6 ports with 6 removable, self powered Jun 15 17:42:22 ibb kernel: ugen3.2: at usb= us3 Jun 15 17:42:22 ibb kernel: Trying to mount root from ufs:/dev/ad4s2a Jun 15 17:42:23 ibb kernel: msk0: link state changed to UP Jun 15 17:42:38 ibb login: ROOT LOGIN (root) ON ttyv0 Jun 15 17:46:53 ibb kernel: lock order reversal: Jun 15 17:46:53 ibb kernel: 1st 0xd9537bb0 bufwait (bufwait) @ /usr/src/sys= /kern/vfs_bio.c:2558 Jun 15 17:46:53 ibb kernel: 2nd 0xc5efd000 dirhash (dirhash) @ /usr/src/sys= /ufs/ufs/ufs_dirhash.c:285 Jun 15 17:46:53 ibb kernel: KDB: stack backtrace: Jun 15 17:46:53 ibb kernel: db_trace_self_wrapper(c0c5e1c8,e813a87c,c08b15d= 5,c08a250b,c0c6100b,...) at db_trace_self_wrapper+0x26 Jun 15 17:46:53 ibb kernel: kdb_backtrace(c08a250b,c0c6100b,c552acf0,c5530c= 00,e813a8d8,...) at kdb_backtrace+0x29 Jun 15 17:46:53 ibb kernel: _witness_debugger(c0c6100b,c5efd000,c0c810bd,c5= 530c00,c0c80d56,...) at _witness_debugger+0x25 Jun 15 17:46:53 ibb kernel: witness_checkorder(c5efd000,9,c0c80d56,11d,0,..= .) at witness_checkorder+0x839 Jun 15 17:46:53 ibb kernel: _sx_xlock(c5efd000,0,c0c80d56,11d,c6015c3c,...)= at _sx_xlock+0x85 Jun 15 17:46:53 ibb kernel: ufsdirhash_acquire(d9537b50,da6db800,200,da6db8= 1c,e813a9a8,...) at ufsdirhash_acquire+0x35 Jun 15 17:46:53 ibb kernel: ufsdirhash_add(c6015c3c,e813aa20,81c,e813a994,e= 813a998,...) at ufsdirhash_add+0x13 Jun 15 17:46:53 ibb kernel: ufs_direnter(c5ff596c,c6139218,e813aa20,e813ac0= 4,d956c200,...) at ufs_direnter+0x729 Jun 15 17:46:53 ibb kernel: ufs_mkdir(e813ac28,ead,0,0,e813ab70,...) at ufs= _mkdir+0x897 Jun 15 17:46:53 ibb kernel: VOP_MKDIR_APV(c0d5eec0,e813ac28,e813ac04,e813ab= 70,0,...) at VOP_MKDIR_APV+0xa5 Jun 15 17:46:53 ibb kernel: kern_mkdirat(c5cda480,ffffff9c,28528f80,0,1ed,.= ..) at kern_mkdirat+0x268 Jun 15 17:46:53 ibb kernel: kern_mkdir(c5cda480,28528f80,0,1ed,e813ad2c,...= ) at kern_mkdir+0x2e Jun 15 17:46:53 ibb kernel: mkdir(c5cda480,e813acf8,8,c0c5e284,c0d3f240,...= ) at mkdir+0x29 Jun 15 17:46:53 ibb kernel: syscall(e813ad38) at syscall+0x2a3 Jun 15 17:46:53 ibb kernel: Xint0x80_syscall() at Xint0x80_syscall+0x20 Jun 15 17:46:53 ibb kernel: --- syscall (136, FreeBSD ELF32, mkdir), eip = =3D 0x283063c3, esp =3D 0xbf4f9d1c, ebp =3D 0xbf4f9d48 --- Mail me, if I can help with anything else... =0A=0A=0A From owner-freebsd-current@FreeBSD.ORG Mon Jun 15 16:59:15 2009 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 A92141065676 for ; Mon, 15 Jun 2009 16:59:15 +0000 (UTC) (envelope-from ibb27@yahoo.co.uk) Received: from web25007.mail.ukl.yahoo.com (web25007.mail.ukl.yahoo.com [217.146.183.110]) by mx1.freebsd.org (Postfix) with SMTP id E98BF8FC08 for ; Mon, 15 Jun 2009 16:59:14 +0000 (UTC) (envelope-from ibb27@yahoo.co.uk) Received: (qmail 34780 invoked by uid 60001); 15 Jun 2009 16:59:14 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.uk; s=s1024; t=1245085154; bh=o7ZRBT4pozFM+upHp/YALkKn4AY1DHDBRVwzkcXiWIU=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=qnhyL57P5cB+VigY0uKQ5LrLdban8/g7XtiEvXeJyt46KoX4fCw8z+vgJrOmK+xHP0Xu9B2lGQVHD1c6znPo5+1ds6wb+gle5JdjBfhktkqgYuM2ydNVEm47gSLv/BnQI6dlkWUutXZ6TW8GmnftnlPhrdZM0+qdK5AJDg58zc0= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.uk; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=l6/B7PoTjwpoEdmI/skt9hRv18Mwy2XJmG0khQw9DXDGGfIgEvqXLvNGrms9WeEEHVBwLnRLrmEAxtZY+X4BYFDdZC4OsjB2Os7U8ltM6RKWhwwU9493b5Z2L17SrM8rSPXyNHrFIufy2iXfLFTRCy0+72n3l3JjUQpYr3yoGRQ=; Message-ID: <85981.29732.qm@web25007.mail.ukl.yahoo.com> X-YMail-OSG: BOrmKv8VM1nQlsYvhcm.MrMnr81Yuy1u74j9EomFkAGtWp2BRxMmE67.uIR4w75G3Q9w1rYWsVz7ksGm1lXNxitPxSTtAGlvQzHWvCyNEibKhDAb6AopfRE61SZ1QjODFhtuL8qWsa.hlczaEdEy1jydH5UBm46AqLsVVNrkTRg4J651hoTKPUsm7s.fY1IueoZJn0nH1HmjuFj3s_dPEooCqQB9gEKI3ObPQR_0kO9gbKPiuGU0HCdDoF8U47eNomelEOlDngOtq4wDEW5kk75o87LdOjtguPKjhuXNXiCWECuT8CLR_FaPbNX92EUOPuHhLiV22ti2KDybPunXSDhuW7Nn65RYtqKUvQ-- Received: from [77.85.139.230] by web25007.mail.ukl.yahoo.com via HTTP; Mon, 15 Jun 2009 16:59:13 GMT X-Mailer: YahooMailClassic/5.4.12 YahooMailWebService/0.7.289.15 Date: Mon, 15 Jun 2009 16:59:13 +0000 (GMT) From: Ivailo Bonev To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Mon, 15 Jun 2009 18:45:34 +0000 Subject: Fw: LOR:vfs_bio.c and ufs_dirhash.c 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, 15 Jun 2009 16:59:15 -0000 --- On Mon, 15/6/09, Ivailo Bonev wrote: > From: Ivailo Bonev > Subject: LOR:vfs_bio.c and ufs_dirhash.c > To: freebsd-current@freebsd.org > Date: Monday, 15 June, 2009, 7:20 PM > I've installed 8-CURRENT on my HP > laptop, snapshot from pub.allbsd.org with HEAD sources from > yesterday, but on first startup I see LOR. Everything works > ok, though...=20 > Here is log from messages: > kernel: Copyright (c) 1992-2009 The FreeBSD Project. > kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, > 1991, 1992, 1993, 1994 > kernel: The Regents of the University of California. All > rights reserved. > kernel: FreeBSD is a registered trademark of The FreeBSD > Foundation. > kernel: FreeBSD 8.0-HEAD-20090615-JPSNAP #0: Mon Jun 15 > 02:22:17 UTC 2009 > kernel: root@build-i386-fbsd-2.allbsd.org:/usr/obj/i386/usr/src/sys/GENER= IC > kernel: WARNING: WITNESS option enabled, expect reduced > performance. > kernel: Timecounter "i8254" frequency 1193182 Hz quality 0 > Jun 15 17:42:22 ibb kernel: CPU: Pentium(R) Dual-Core > CPU=A0 =A0 =A0=A0=A0T4200=A0 @ 2.00GHz > (1995.25-MHz 686-class CPU) > Jun 15 17:42:22 ibb kernel: Origin =3D "GenuineIntel"=A0 > Id =3D 0x1067a=A0 Stepping =3D 10 > Jun 15 17:42:22 ibb kernel: > Features=3D0xbfebfbff > Jun 15 17:42:22 ibb kernel: > Features2=3D0x400e39d > Jun 15 17:42:22 ibb kernel: AMD > Features=3D0x20100000 > Jun 15 17:42:22 ibb kernel: AMD Features2=3D0x1 > Jun 15 17:42:22 ibb kernel: TSC: P-state invariant > Jun 15 17:42:22 ibb kernel: real memory=A0 =3D 2147483648 > (2048 MB) > Jun 15 17:42:22 ibb kernel: avail memory =3D 2083385344 (1986 > MB) > Jun 15 17:42:22 ibb kernel: ACPI APIC Table: 30E9=A0 =A0 > > Jun 15 17:42:22 ibb kernel: FreeBSD/SMP: Multiprocessor > System Detected: 2 CPUs > Jun 15 17:42:22 ibb kernel: FreeBSD/SMP: 1 package(s) x 2 > core(s) > Jun 15 17:42:22 ibb kernel: cpu0 (BSP): APIC ID:=A0 0 > Jun 15 17:42:22 ibb kernel: cpu1 (AP): APIC ID:=A0 1 > Jun 15 17:42:22 ibb kernel: ioapic0: Changing APIC ID to 1 > Jun 15 17:42:22 ibb kernel: ioapic0 > irqs 0-23 on motherboard > Jun 15 17:42:22 ibb kernel: kbd1 at kbdmux0 > Jun 15 17:42:22 ibb kernel: acpi0: > on motherboard > Jun 15 17:42:22 ibb kernel: acpi0: [ITHREAD] > Jun 15 17:42:22 ibb kernel: acpi0: Power Button (fixed) > Jun 15 17:42:22 ibb kernel: Timecounter "HPET" frequency > 14318180 Hz quality 900 > Jun 15 17:42:22 ibb kernel: Timecounter "ACPI-fast" > frequency 3579545 Hz quality 1000 > Jun 15 17:42:22 ibb kernel: acpi_timer0: <24-bit timer > at 3.579545MHz> port 0x408-0x40b on acpi0 > Jun 15 17:42:22 ibb kernel: acpi_ec0: Controller: GPE 0x16> port 0x62,0x66 on acpi0 > Jun 15 17:42:22 ibb kernel: pcib0: bridge> port 0xcf8-0xcff on acpi0 > Jun 15 17:42:22 ibb kernel: pci0: on > pcib0 > Jun 15 17:42:22 ibb kernel: pcib1: bridge> irq 16 at device 1.0 on pci0 > Jun 15 17:42:22 ibb kernel: pci1: on > pcib1 > Jun 15 17:42:22 ibb kernel: vgapci0: display> port 0x7000-0x70ff mem > 0x80000000-0x8fffffff,0x98400000-0x9840ffff irq 16 at device > 0.0 on pci1 > Jun 15 17:42:22 ibb kernel: uhci0: USB controller> port 0x80c0-0x80df irq 16 at device 26.0 > on pci0 > Jun 15 17:42:22 ibb kernel: uhci0: [ITHREAD] > Jun 15 17:42:22 ibb kernel: uhci0: LegSup =3D 0x0f00 > Jun 15 17:42:22 ibb kernel: usbus0: USB controller> on uhci0 > Jun 15 17:42:22 ibb kernel: uhci1: USB controller> port 0x80a0-0x80bf irq 17 at device 26.1 > on pci0 > Jun 15 17:42:22 ibb kernel: uhci1: [ITHREAD] > Jun 15 17:42:22 ibb kernel: uhci1: LegSup =3D 0x0f00 > Jun 15 17:42:22 ibb kernel: usbus1: USB controller> on uhci1 > Jun 15 17:42:22 ibb kernel: uhci2: USB controller> port 0x8080-0x809f irq 18 at device 26.2 > on pci0 > Jun 15 17:42:22 ibb kernel: uhci2: [ITHREAD] > Jun 15 17:42:22 ibb kernel: uhci2: LegSup =3D 0x0f00 > Jun 15 17:42:22 ibb kernel: usbus2: USB controller> on uhci2 > Jun 15 17:42:22 ibb kernel: ehci0: USB 2.0 controller> mem 0x98504c00-0x98504fff irq 19 at > device 26.7 on pci0 > Jun 15 17:42:22 ibb kernel: ehci0: [ITHREAD] > Jun 15 17:42:22 ibb kernel: usbus3: EHCI version 1.0 > Jun 15 17:42:22 ibb kernel: usbus3: USB 2.0 controller> on ehci0 > Jun 15 17:42:22 ibb kernel: pci0: > at device 27.0 (no driver attached) > Jun 15 17:42:22 ibb kernel: pcib2: bridge> irq 16 at device 28.0 on pci0 > Jun 15 17:42:22 ibb kernel: pci2: on > pcib2 > Jun 15 17:42:22 ibb kernel: pcib3: bridge> irq 17 at device 28.1 on pci0 > Jun 15 17:42:22 ibb kernel: pci3: on > pcib3 > Jun 15 17:42:22 ibb kernel: pci3: at device > 0.0 (no driver attached) > Jun 15 17:42:22 ibb kernel: pcib4: bridge> irq 18 at device 28.2 on pci0 > Jun 15 17:42:22 ibb kernel: pci4: on > pcib4 > Jun 15 17:42:22 ibb kernel: pcib5: bridge> irq 16 at device 28.4 on pci0 > Jun 15 17:42:22 ibb kernel: pci69: on > pcib5 > Jun 15 17:42:22 ibb kernel: pcib6: bridge> irq 17 at device 28.5 on pci0 > Jun 15 17:42:22 ibb kernel: pci134: on > pcib6 > Jun 15 17:42:22 ibb kernel: mskc0: 88E8072 Gigabit Ethernet> port 0x2000-0x20ff mem > 0x90100000-0x90103fff irq 17 at device 0.0 on pci134 > Jun 15 17:42:22 ibb kernel: msk0: Group Ltd. Yukon EX Id 0xb5 Rev 0x02> on mskc0 > Jun 15 17:42:22 ibb kernel: msk0: Ethernet address: > 00:24:81:47:09:c0 > Jun 15 17:42:22 ibb kernel: miibus0: on > msk0 > Jun 15 17:42:22 ibb kernel: e1000phy0: Gigabit PHY> PHY 0 on miibus0 > Jun 15 17:42:22 ibb kernel: e1000phy0:=A0 10baseT, > 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > 1000baseT-FDX, auto > Jun 15 17:42:22 ibb kernel: mskc0: [FILTER] > Jun 15 17:42:22 ibb kernel: uhci3: USB controller> port 0x8060-0x807f irq 20 at device 29.0 > on pci0 > Jun 15 17:42:22 ibb kernel: uhci3: [ITHREAD] > Jun 15 17:42:22 ibb kernel: uhci3: LegSup =3D 0x0f00 > Jun 15 17:42:22 ibb kernel: usbus4: USB controller> on uhci3 > Jun 15 17:42:22 ibb kernel: uhci4: USB controller> port 0x8040-0x805f irq 22 at device 29.1 > on pci0 > Jun 15 17:42:22 ibb kernel: uhci4: [ITHREAD] > Jun 15 17:42:22 ibb kernel: uhci4: LegSup =3D 0x0f00 > Jun 15 17:42:22 ibb kernel: usbus5: USB controller> on uhci4 > Jun 15 17:42:22 ibb kernel: uhci5: USB controller> port 0x8020-0x803f irq 18 at device 29.2 > on pci0 > Jun 15 17:42:22 ibb kernel: uhci5: [ITHREAD] > Jun 15 17:42:22 ibb kernel: uhci5: LegSup =3D 0x0f00 > Jun 15 17:42:22 ibb kernel: usbus6: USB controller> on uhci5 > Jun 15 17:42:22 ibb kernel: ehci1: USB 2.0 controller> mem 0x98504800-0x98504bff irq 20 at > device 29.7 on pci0 > Jun 15 17:42:22 ibb kernel: ehci1: [ITHREAD] > Jun 15 17:42:22 ibb kernel: usbus7: EHCI version 1.0 > Jun 15 17:42:22 ibb kernel: usbus7: USB 2.0 controller> on ehci1 > Jun 15 17:42:22 ibb kernel: pcib7: bridge> at device 30.0 on pci0 > Jun 15 17:42:22 ibb kernel: pci135: on > pcib7 > Jun 15 17:42:22 ibb kernel: isab0: > at device 31.0 on pci0 > Jun 15 17:42:22 ibb kernel: isa0: on isab0 > Jun 15 17:42:22 ibb kernel: atapci0: controller> port > 0x80e8-0x80ef,0x80f4-0x80f7,0x80e0-0x80e7,0x80f0-0x80f3,0x8000-0x801f > mem 0x98504000-0x985047ff irq 21 at device 31.2 on pci0 > Jun 15 17:42:22 ibb kernel: atapci0: [ITHREAD] > Jun 15 17:42:22 ibb kernel: atapci0: AHCI v1.20 controller > with 4 3Gbps ports, PM not supported > Jun 15 17:42:22 ibb kernel: ata2: on > atapci0 > Jun 15 17:42:22 ibb kernel: ata2: [ITHREAD] > Jun 15 17:42:22 ibb kernel: ata3: on > atapci0 > Jun 15 17:42:22 ibb kernel: ata3: [ITHREAD] > Jun 15 17:42:22 ibb kernel: ata4: on > atapci0 > Jun 15 17:42:22 ibb kernel: ata4: [ITHREAD] > Jun 15 17:42:22 ibb kernel: battery0: Method Battery> on acpi0 > Jun 15 17:42:22 ibb kernel: acpi_acad0: > on acpi0 > Jun 15 17:42:22 ibb kernel: acpi_button0: Button> on acpi0 > Jun 15 17:42:22 ibb kernel: acpi_lid0: Lid Switch> on acpi0 > Jun 15 17:42:22 ibb kernel: acpi_tz0: > on acpi0 > Jun 15 17:42:22 ibb kernel: acpi_tz1: > on acpi0 > Jun 15 17:42:22 ibb kernel: acpi_tz1: _CRT value is absurd, > ignored (256.0C) > Jun 15 17:42:22 ibb kernel: acpi_tz2: > on acpi0 > Jun 15 17:42:22 ibb kernel: acpi_tz3: > on acpi0 > Jun 15 17:42:22 ibb kernel: acpi_tz4: > on acpi0 > Jun 15 17:42:22 ibb kernel: acpi_tz5: > on acpi0 > Jun 15 17:42:22 ibb kernel: atrtc0: clock> port 0x70-0x77 irq 8 on acpi0 > Jun 15 17:42:22 ibb kernel: atrtc0: Warning: Couldn't map > I/O. > Jun 15 17:42:22 ibb kernel: atkbdc0: controller (i8042)> port 0x60,0x64 irq 1 on acpi0 > Jun 15 17:42:22 ibb kernel: atkbd0: irq > 1 on atkbdc0 > Jun 15 17:42:22 ibb kernel: kbd0 at atkbd0 > Jun 15 17:42:22 ibb kernel: atkbd0: [GIANT-LOCKED] > Jun 15 17:42:22 ibb kernel: atkbd0: [ITHREAD] > Jun 15 17:42:22 ibb kernel: psm0: irq 12 > on atkbdc0 > Jun 15 17:42:22 ibb kernel: psm0: [GIANT-LOCKED] > Jun 15 17:42:22 ibb kernel: psm0: [ITHREAD] > Jun 15 17:42:22 ibb kernel: psm0: model IntelliMouse, > device ID 3 > Jun 15 17:42:22 ibb kernel: cpu0: on > acpi0 > Jun 15 17:42:22 ibb kernel: est0: Frequency Control> on cpu0 > Jun 15 17:42:22 ibb kernel: p4tcc0: Thermal Control> on cpu0 > Jun 15 17:42:22 ibb kernel: cpu1: on > acpi0 > Jun 15 17:42:22 ibb kernel: est1: Frequency Control> on cpu1 > Jun 15 17:42:22 ibb kernel: p4tcc1: Thermal Control> on cpu1 > Jun 15 17:42:22 ibb kernel: pmtimer0 on isa0 > Jun 15 17:42:22 ibb kernel: sc0: at > flags 0x100 on isa0 > Jun 15 17:42:22 ibb kernel: sc0: VGA <16 virtual > consoles, flags=3D0x300> > Jun 15 17:42:22 ibb kernel: vga0: > at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > Jun 15 17:42:22 ibb kernel: ata0 at port 0x1f0-0x1f7,0x3f6 > irq 14 on isa0 > Jun 15 17:42:22 ibb kernel: ata0: [ITHREAD] > Jun 15 17:42:22 ibb kernel: ata1 at port 0x170-0x177,0x376 > irq 15 on isa0 > Jun 15 17:42:22 ibb kernel: ata1: [ITHREAD] > Jun 15 17:42:22 ibb kernel: Timecounters tick every 1.000 > msec > Jun 15 17:42:22 ibb kernel: usbus1: 12Mbps Full Speed USB > v1.0 > Jun 15 17:42:22 ibb kernel: usbus2: 12Mbps Full Speed USB > v1.0 > Jun 15 17:42:22 ibb kernel: usbus3: 480Mbps High Speed USB > v2.0 > Jun 15 17:42:22 ibb kernel: usbus4: 12Mbps Full Speed USB > v1.0 > Jun 15 17:42:22 ibb kernel: usbus5: 12Mbps Full Speed USB > v1.0 > Jun 15 17:42:22 ibb kernel: usbus6: 12Mbps Full Speed USB > v1.0 > Jun 15 17:42:22 ibb kernel: usbus7: 480Mbps High Speed USB > v2.0 > Jun 15 17:42:22 ibb kernel: usbus0: 12Mbps Full Speed USB > v1.0 > Jun 15 17:42:22 ibb kernel: ugen1.1: at > usbus1 > Jun 15 17:42:22 ibb kernel: uhub0: class 9/0, rev 1.00/1.00, addr 1> on usbus1 > Jun 15 17:42:22 ibb kernel: ugen2.1: at > usbus2 > Jun 15 17:42:22 ibb kernel: uhub1: class 9/0, rev 1.00/1.00, addr 1> on usbus2 > Jun 15 17:42:22 ibb kernel: ugen3.1: at > usbus3 > Jun 15 17:42:22 ibb kernel: uhub2: class 9/0, rev 2.00/1.00, addr 1> on usbus3 > Jun 15 17:42:22 ibb kernel: ugen4.1: at > usbus4 > Jun 15 17:42:22 ibb kernel: uhub3: class 9/0, rev 1.00/1.00, addr 1> on usbus4 > Jun 15 17:42:22 ibb kernel: ugen5.1: at > usbus5 > Jun 15 17:42:22 ibb kernel: uhub4: class 9/0, rev 1.00/1.00, addr 1> on usbus5 > Jun 15 17:42:22 ibb kernel: ugen6.1: at > usbus6 > Jun 15 17:42:22 ibb kernel: uhub5: class 9/0, rev 1.00/1.00, addr 1> on usbus6 > Jun 15 17:42:22 ibb kernel: ugen7.1: at > usbus7 > Jun 15 17:42:22 ibb kernel: uhub6: class 9/0, rev 2.00/1.00, addr 1> on usbus7 > Jun 15 17:42:22 ibb kernel: ugen0.1: at > usbus0 > Jun 15 17:42:22 ibb kernel: uhub7: class 9/0, rev 1.00/1.00, addr 1> on usbus0 > Jun 15 17:42:22 ibb kernel: ad4: 238475MB HTS543225L9A300 FBEOC40F> at ata2-master SATA300 > Jun 15 17:42:22 ibb kernel: acpi_tz1: _CRT value is absurd, > ignored (256.0C) > Jun 15 17:42:22 ibb kernel: acd0: DVDR AD-7561S/AH03> at ata3-master SATA150 > Jun 15 17:42:22 ibb kernel: SMP: AP CPU #1 Launched! > Jun 15 17:42:22 ibb kernel: WARNING: WITNESS option > enabled, expect reduced performance. > Jun 15 17:42:22 ibb kernel: uhub0: 2 ports with 2 > removable, self powered > Jun 15 17:42:22 ibb kernel: uhub1: 2 ports with 2 > removable, self powered > Jun 15 17:42:22 ibb kernel: uhub3: 2 ports with 2 > removable, self powered > Jun 15 17:42:22 ibb kernel: uhub4: 2 ports with 2 > removable, self powered > Jun 15 17:42:22 ibb kernel: uhub5: 2 ports with 2 > removable, self powered > Jun 15 17:42:22 ibb kernel: uhub7: 2 ports with 2 > removable, self powered > Jun 15 17:42:22 ibb kernel: GEOM: ad4s2: geometry does not > match label (255h,63s !=3D 16h,63s). > Jun 15 17:42:22 ibb kernel: Root mount waiting for: usbus7 > usbus3 > Jun 15 17:42:22 ibb last message repeated 2 times > Jun 15 17:42:22 ibb kernel: uhub2: 6 ports with 6 > removable, self powered > Jun 15 17:42:22 ibb kernel: uhub6: 6 ports with 6 > removable, self powered > Jun 15 17:42:22 ibb kernel: ugen3.2: Electronics Co., Ltd.> at usbus3 > Jun 15 17:42:22 ibb kernel: Trying to mount root from > ufs:/dev/ad4s2a > Jun 15 17:42:23 ibb kernel: msk0: link state changed to UP > Jun 15 17:42:38 ibb login: ROOT LOGIN (root) ON ttyv0 > Jun 15 17:46:53 ibb kernel: lock order reversal: > Jun 15 17:46:53 ibb kernel: 1st 0xd9537bb0 bufwait > (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2558 > Jun 15 17:46:53 ibb kernel: 2nd 0xc5efd000 dirhash > (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:285 > Jun 15 17:46:53 ibb kernel: KDB: stack backtrace: > Jun 15 17:46:53 ibb kernel: > db_trace_self_wrapper(c0c5e1c8,e813a87c,c08b15d5,c08a250b,c0c6100b,...) > at db_trace_self_wrapper+0x26 > Jun 15 17:46:53 ibb kernel: > kdb_backtrace(c08a250b,c0c6100b,c552acf0,c5530c00,e813a8d8,...) > at kdb_backtrace+0x29 > Jun 15 17:46:53 ibb kernel: > _witness_debugger(c0c6100b,c5efd000,c0c810bd,c5530c00,c0c80d56,...) > at _witness_debugger+0x25 > Jun 15 17:46:53 ibb kernel: > witness_checkorder(c5efd000,9,c0c80d56,11d,0,...) at > witness_checkorder+0x839 > Jun 15 17:46:53 ibb kernel: > _sx_xlock(c5efd000,0,c0c80d56,11d,c6015c3c,...) at > _sx_xlock+0x85 > Jun 15 17:46:53 ibb kernel: > ufsdirhash_acquire(d9537b50,da6db800,200,da6db81c,e813a9a8,...) > at ufsdirhash_acquire+0x35 > Jun 15 17:46:53 ibb kernel: > ufsdirhash_add(c6015c3c,e813aa20,81c,e813a994,e813a998,...) > at ufsdirhash_add+0x13 > Jun 15 17:46:53 ibb kernel: > ufs_direnter(c5ff596c,c6139218,e813aa20,e813ac04,d956c200,...) > at ufs_direnter+0x729 > Jun 15 17:46:53 ibb kernel: > ufs_mkdir(e813ac28,ead,0,0,e813ab70,...) at ufs_mkdir+0x897 > Jun 15 17:46:53 ibb kernel: > VOP_MKDIR_APV(c0d5eec0,e813ac28,e813ac04,e813ab70,0,...) at > VOP_MKDIR_APV+0xa5 > Jun 15 17:46:53 ibb kernel: > kern_mkdirat(c5cda480,ffffff9c,28528f80,0,1ed,...) at > kern_mkdirat+0x268 > Jun 15 17:46:53 ibb kernel: > kern_mkdir(c5cda480,28528f80,0,1ed,e813ad2c,...) at > kern_mkdir+0x2e > Jun 15 17:46:53 ibb kernel: > mkdir(c5cda480,e813acf8,8,c0c5e284,c0d3f240,...) at > mkdir+0x29 > Jun 15 17:46:53 ibb kernel: syscall(e813ad38) at > syscall+0x2a3 > Jun 15 17:46:53 ibb kernel: Xint0x80_syscall() at > Xint0x80_syscall+0x20 > Jun 15 17:46:53 ibb kernel: --- syscall (136, FreeBSD > ELF32, mkdir), eip =3D 0x283063c3, esp =3D 0xbf4f9d1c, ebp =3D > 0xbf4f9d48 --- >=20 > Mail me, if I can help with anything else... >=20 More precisely, I see this LOR when I try to configure custom kernel with: #config MYKERN =0A=0A=0A From owner-freebsd-current@FreeBSD.ORG Mon Jun 15 18:58:18 2009 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 EA12B1065690 for ; Mon, 15 Jun 2009 18:58:18 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from vlakno.cz (77-93-215-190.static.masterinter.net [77.93.215.190]) by mx1.freebsd.org (Postfix) with ESMTP id A0EF58FC14 for ; Mon, 15 Jun 2009 18:58:18 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from localhost (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id E52459CB0E6; Mon, 15 Jun 2009 20:58:14 +0200 (CEST) X-Virus-Scanned: amavisd-new at vlakno.cz Received: from vlakno.cz ([127.0.0.1]) by localhost (lev.vlakno.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cqrD+l3bsnh0; Mon, 15 Jun 2009 20:58:12 +0200 (CEST) Received: from vlk.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id A63D29CB19F; Mon, 15 Jun 2009 20:58:12 +0200 (CEST) Received: (from rdivacky@localhost) by vlk.vlakno.cz (8.14.3/8.14.3/Submit) id n5FIwC7i067305; Mon, 15 Jun 2009 20:58:12 +0200 (CEST) (envelope-from rdivacky) Date: Mon, 15 Jun 2009 20:58:12 +0200 From: Roman Divacky To: Sam Leffler Message-ID: <20090615185812.GA67104@freebsd.org> References: <20090615181555.GA52009@freebsd.org> <4A369529.5090004@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A369529.5090004@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: current@freebsd.org Subject: Re: [RFC]: (void)0 instead of empty defines 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, 15 Jun 2009 18:58:19 -0000 On Mon, Jun 15, 2009 at 11:38:33AM -0700, Sam Leffler wrote: > Roman Divacky wrote: > >hi > > > >in many places we do something like > > > >#ifdef SOMETHING > >#define FOO some_code > >#else > >#define FOO > >#endif > > > > > >I propose to change the second FOO to (void)0 in many places to > > > >1) let this compile cleanly with clang. Clang warns in many places > >about > > if (cond) > > FOO; > > > >which has empty if body > > > >2) enforces ; at the end of the expression > > > >this does not cost us nothing so I hope this change is ok. > > > >patch at: http://www.vlakno.cz/~rdivacky/void-zero.patch > > > >what do you think? > > > >roman > > > >p.s. there's also ACPI_DEBUG_PRINT in contrib/acpica which I hope > >jkim might handle > > > > Are you saying that: > > if (cond) > ; > > is considered worthy of a warning by the compiler? Is it just "if" or > all conditional control constructs (e.g. while)? > > I can image many instances of this construct arising from debugging > facilities. This sounds like a stupid restriction and I would argue we > should just disable the warning. it already found a bug in csup (recently fixed by lulf). It sure can be disabled but I'd like it to be discussed a little bit more as it already proved to be useful. roman From owner-freebsd-current@FreeBSD.ORG Mon Jun 15 19:10:03 2009 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 323591065674; Mon, 15 Jun 2009 19:10:03 +0000 (UTC) (envelope-from jh@saunalahti.fi) Received: from gw02.mail.saunalahti.fi (gw02.mail.saunalahti.fi [195.197.172.116]) by mx1.freebsd.org (Postfix) with ESMTP id E671E8FC1A; Mon, 15 Jun 2009 19:10:02 +0000 (UTC) (envelope-from jh@saunalahti.fi) Received: from a91-153-125-115.elisa-laajakaista.fi (a91-153-125-115.elisa-laajakaista.fi [91.153.125.115]) by gw02.mail.saunalahti.fi (Postfix) with SMTP id 9A6B6139549; Mon, 15 Jun 2009 21:52:55 +0300 (EEST) Date: Mon, 15 Jun 2009 21:52:55 +0300 From: Jaakko Heinonen To: Ivan Voras Message-ID: <20090615185254.GA4303@a91-153-125-115.elisa-laajakaista.fi> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: tmpfs experimental? 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, 15 Jun 2009 19:10:03 -0000 On 2009-06-15, Ivan Voras wrote: > Are there still known problems with tmpfs? I think sendfile(2) is still broken on tmpfs. See: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/127213 -- Jaakko From owner-freebsd-current@FreeBSD.ORG Mon Jun 15 19:25:09 2009 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 6F4161065675 for ; Mon, 15 Jun 2009 19:25:09 +0000 (UTC) (envelope-from uucp@gromit.grondar.org) Received: from gromit.grondar.org (unknown [IPv6:2001:ba8:0:1d5:216:d4ff:fe0d:d845]) by mx1.freebsd.org (Postfix) with ESMTP id 363C78FC1C for ; Mon, 15 Jun 2009 19:25:09 +0000 (UTC) (envelope-from uucp@gromit.grondar.org) Received: from uucp by gromit.grondar.org with local (Exim 4.69) (envelope-from ) id 1MGI2O-000440-60 for current@freebsd.org; Mon, 15 Jun 2009 20:40:12 +0100 Received: from localhost ([127.0.0.1] helo=greatest.grondar.org) by greatest.grondar.org with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGHnH-0000Yr-7A; Mon, 15 Jun 2009 20:24:35 +0100 To: Brooks Davis In-reply-to: <20090615183207.GC7180@lor.one-eyed-alien.net> References: <20090615183207.GC7180@lor.one-eyed-alien.net> From: Mark Murray Date: Mon, 15 Jun 2009 20:24:35 +0100 Message-Id: Sender: UNIX-to-UNIX Copy Cc: current@freebsd.org Subject: Re: Knobs for src/Make* for SVN "make update" (patch attached) 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, 15 Jun 2009 19:25:09 -0000 Brooks Davis writes: > It basically looks fine to me. I'm not sure why SVNFLAGS needs to be > set at all though. Isn't -rHEAD implicit? -rHEAD overrides sticky versions. M -- Mark R V Murray Cert APS(Open) Dip Phys(Open) BSc Open(Open) BSc(Hons)(Open) From owner-freebsd-current@FreeBSD.ORG Mon Jun 15 19:38:55 2009 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 2F500106564A for ; Mon, 15 Jun 2009 19:38:55 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout015.mac.com (asmtpout015.mac.com [17.148.16.90]) by mx1.freebsd.org (Postfix) with ESMTP id 17E688FC14 for ; Mon, 15 Jun 2009 19:38:54 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from marcelm-sslvpn-nc.jnpr.net (nat-service4.juniper.net [66.129.225.151]) by asmtp015.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KLA003V0P83PG60@asmtp015.mac.com>; Mon, 15 Jun 2009 12:38:28 -0700 (PDT) Message-id: <53E03A0A-8846-4EED-AE95-A15960FC6724@mac.com> From: Marcel Moolenaar To: Roman Divacky In-reply-to: <20090615185812.GA67104@freebsd.org> Date: Mon, 15 Jun 2009 12:38:27 -0700 References: <20090615181555.GA52009@freebsd.org> <4A369529.5090004@freebsd.org> <20090615185812.GA67104@freebsd.org> X-Mailer: Apple Mail (2.935.3) Cc: Sam Leffler , current@freebsd.org Subject: Re: [RFC]: (void)0 instead of empty defines 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, 15 Jun 2009 19:38:55 -0000 On Jun 15, 2009, at 11:58 AM, Roman Divacky wrote: >> Are you saying that: >> >> if (cond) >> ; >> >> is considered worthy of a warning by the compiler? Is it just "if" >> or >> all conditional control constructs (e.g. while)? >> >> I can image many instances of this construct arising from debugging >> facilities. This sounds like a stupid restriction and I would >> argue we >> should just disable the warning. > > it already found a bug in csup (recently fixed by lulf). It sure can > be > disabled but I'd like it to be discussed a little bit more as it > already > proved to be useful. If the patch is all we need to compile the kernel with the warning enabled and knowing that the warning has already found real bugs, then it's a no-brainer to me: commit. -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Mon Jun 15 19:40:11 2009 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 9E206106567B for ; Mon, 15 Jun 2009 19:40:11 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id 33AF38FC17 for ; Mon, 15 Jun 2009 19:40:11 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 17648 invoked by uid 399); 15 Jun 2009 19:40:09 -0000 Received: from localhost (HELO ?10.9.1.131?) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 15 Jun 2009 19:40:09 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4A36A39F.5020909@FreeBSD.org> Date: Mon, 15 Jun 2009 12:40:15 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Andriy Gapon References: <4A23D5A4.6020009@icyb.net.ua> <4A23F4B8.7000002@freebsd.org> <4A240331.1000803@FreeBSD.org> <20090602141231.67987dnz529yuqgw@webmail.leidinger.net> <4A255F8E.70604@FreeBSD.org> <4A2EA22B.7090208@freebsd.org> <4A301228.30708@freebsd.org> In-Reply-To: <4A301228.30708@freebsd.org> X-Enigmail-Version: 0.95.7 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Alexander Leidinger , freebsd-current@freebsd.org, Dmitry Morozovsky Subject: Re: fsck_y_enable: use -C 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, 15 Jun 2009 19:40:12 -0000 Andriy Gapon wrote: > on 10/06/2009 12:21 Dmitry Morozovsky said the following: >> On Tue, 9 Jun 2009, Andriy Gapon wrote: >> >> AG> > DB> Alexander Leidinger wrote: >> AG> > DB> > What about _flags and also adding a NOP for -C in fsck_msdosfs? >> AG> > DB> >> AG> > DB> Sounds great, I look forward to reviewing your patch. :) >> AG> > >> AG> > What do you think about attached one? >> AG> >> AG> I like the patch very much! >> AG> Please commit, if you can :-) >> >> I'm doc committer, so please commit it yourselves. > > Committed as r193943 and r193944 - big thanks! Andriy, thanks for taking this on, and thanks to Dmitry for writing the patches! Now if only someone could update share/man/man5/rc.conf.5 .... :) Doug From owner-freebsd-current@FreeBSD.ORG Mon Jun 15 19:51:56 2009 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 BC933106566C; Mon, 15 Jun 2009 19:51:56 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 8E38D8FC1C; Mon, 15 Jun 2009 19:51:56 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id n5FJptTa065459 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Jun 2009 12:51:55 -0700 (PDT) (envelope-from sam@freebsd.org) Message-ID: <4A36A65B.9050706@freebsd.org> Date: Mon, 15 Jun 2009 12:51:55 -0700 From: Sam Leffler Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.21 (X11/20090411) MIME-Version: 1.0 To: Marcel Moolenaar References: <20090615181555.GA52009@freebsd.org> <4A369529.5090004@freebsd.org> <20090615185812.GA67104@freebsd.org> <53E03A0A-8846-4EED-AE95-A15960FC6724@mac.com> In-Reply-To: <53E03A0A-8846-4EED-AE95-A15960FC6724@mac.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC-Misty-Metrics: ebb.errno.com; whitelist Cc: Roman Divacky , current@freebsd.org Subject: Re: [RFC]: (void)0 instead of empty defines 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, 15 Jun 2009 19:51:57 -0000 Marcel Moolenaar wrote: > > On Jun 15, 2009, at 11:58 AM, Roman Divacky wrote: > >>> Are you saying that: >>> >>> if (cond) >>> ; >>> >>> is considered worthy of a warning by the compiler? Is it just "if" or >>> all conditional control constructs (e.g. while)? >>> >>> I can image many instances of this construct arising from debugging >>> facilities. This sounds like a stupid restriction and I would argue we >>> should just disable the warning. >> >> it already found a bug in csup (recently fixed by lulf). It sure can be >> disabled but I'd like it to be discussed a little bit more as it already >> proved to be useful. > > If the patch is all we need to compile the kernel with the warning > enabled and knowing that the warning has already found real bugs, > then it's a no-brainer to me: commit. > The patch is incomplete in that it only changes code that makes clang kvetch. There are many other instances in the tree of using #defines for debug facilities and leaving them empty when disabled that this patch does not address. What this change effectively does is impose a new element of style to deal w/ a compiler idiosynchrocy (and/or compilation option). While I can agree finding bugs is good I don't see this as a reason to add this requirement. We could just as easily enable various gcc options and require other coding conventions. Furthermore we have other tools that are supposed to find things like this (e.g. coverity) but they are not being used. Sam From owner-freebsd-current@FreeBSD.ORG Mon Jun 15 20:14:09 2009 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 4CBAC106566C; Mon, 15 Jun 2009 20:14:09 +0000 (UTC) (envelope-from stefan@fafoe.narf.at) Received: from viefep15-int.chello.at (viefep15-int.chello.at [62.179.121.35]) by mx1.freebsd.org (Postfix) with ESMTP id 2A9778FC1B; Mon, 15 Jun 2009 20:14:07 +0000 (UTC) (envelope-from stefan@fafoe.narf.at) Received: from edge02.upc.biz ([192.168.13.237]) by viefep19-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20090615195426.SSKJ8900.viefep19-int.chello.at@edge02.upc.biz>; Mon, 15 Jun 2009 21:54:26 +0200 Received: from lizard.fafoe.narf.at ([213.47.85.26]) by edge02.upc.biz with edge id 4KuQ1c01r0a5KZh02KuRzN; Mon, 15 Jun 2009 21:54:26 +0200 X-SourceIP: 213.47.85.26 Received: by lizard.fafoe.narf.at (Postfix, from userid 1001) id 02ACDBABD; Mon, 15 Jun 2009 21:54:23 +0200 (CEST) Date: Mon, 15 Jun 2009 21:54:23 +0200 From: Stefan Farfeleder To: Sam Leffler Message-ID: <20090615195422.GB1418@lizard.fafoe.narf.at> Mail-Followup-To: Sam Leffler , Roman Divacky , current@freebsd.org References: <20090615181555.GA52009@freebsd.org> <4A369529.5090004@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A369529.5090004@freebsd.org> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: Roman Divacky , current@freebsd.org Subject: Re: [RFC]: (void)0 instead of empty defines 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, 15 Jun 2009 20:14:09 -0000 On Mon, Jun 15, 2009 at 11:38:33AM -0700, Sam Leffler wrote: > > Are you saying that: > > if (cond) > ; > > is considered worthy of a warning by the compiler? Is it just "if" or all > conditional control constructs (e.g. while)? > > I can image many instances of this construct arising from debugging > facilities. This sounds like a stupid restriction and I would argue we > should just disable the warning. GCC warns too with -Wextra. From owner-freebsd-current@FreeBSD.ORG Mon Jun 15 20:19:17 2009 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 7F886106566C for ; Mon, 15 Jun 2009 20:19:17 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 2EEDC8FC14 for ; Mon, 15 Jun 2009 20:19:16 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAJNJNkqDaFvH/2dsb2JhbADWI4QNBQ X-IronPort-AV: E=Sophos;i="4.42,224,1243828800"; d="scan'208";a="38463358" Received: from danube.cs.uoguelph.ca ([131.104.91.199]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 15 Jun 2009 16:19:16 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by danube.cs.uoguelph.ca (Postfix) with ESMTP id 419AA108429C; Mon, 15 Jun 2009 16:19:16 -0400 (EDT) X-Virus-Scanned: amavisd-new at danube.cs.uoguelph.ca Received: from danube.cs.uoguelph.ca ([127.0.0.1]) by localhost (danube.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id khiauUEViCOr; Mon, 15 Jun 2009 16:19:15 -0400 (EDT) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by danube.cs.uoguelph.ca (Postfix) with ESMTP id 6CE0A1084251; Mon, 15 Jun 2009 16:19:15 -0400 (EDT) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id n5FKKxc10998; Mon, 15 Jun 2009 16:20:59 -0400 (EDT) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Mon, 15 Jun 2009 16:20:59 -0400 (EDT) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: Martin In-Reply-To: <20090615173315.1cdb39e1@zelda.local> Message-ID: References: <4A2504AA.1020406@zedat.fu-berlin.de> <20090603235227.GB15659@hades.panopticon> <20090615173315.1cdb39e1@zelda.local> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@FreeBSD.org, Dmitry Marakasov , =?utf-8?B?Ty4NCiBIYXJ0bWFubg==?= , Arnar Mar Sig Subject: Re: RPCPROG_MNT: RPC: Timed out / receiving NFS error when trying to mount NFS file system after make world 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, 15 Jun 2009 20:19:17 -0000 > > Hi Rick. > > I've got also a problem mounting nfs over tcp on my amd64 (kernel of > yesterday). > Are you using a recently built userland? I ask because there have been some recent changes to the rpc routines in libc related to routing replies. One of them used a uint32_t argument to _setsockopt() until it was changed to "int" on May 28. The changes I put in nfsd.c had nothing to do with the "-h" option or use of rpcbind(), so I don't think my changes would be the culprit. rick From owner-freebsd-current@FreeBSD.ORG Mon Jun 15 21:02:18 2009 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 A87E91065688; Mon, 15 Jun 2009 21:02:18 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from kennaway-macbookpro.config (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id AE02E8FC28; Mon, 15 Jun 2009 21:02:17 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <4A36B6D8.8000701@FreeBSD.org> Date: Mon, 15 Jun 2009 22:02:16 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: pav@FreeBSD.org References: <1242075474.72992.118.camel@hood.oook.cz> In-Reply-To: <1242075474.72992.118.camel@hood.oook.cz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dfr@FreeBSD.org, kmacy@FreeBSD.org, current@FreeBSD.org Subject: Re: pointyhat 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: Mon, 15 Jun 2009 21:02:20 -0000 Pav Lucistnik wrote: > panic: mtx_lock() of destroyed mutex @ /usr/src/sys/rpc/clnt_vc.c:953 > cpuid = 2 > KDB: enter: panic > [thread pid 0 tid 100029 ] > Stopped at kdb_enter+0x3d: movq $0,0x3f5fb8(%rip) > db> bt > Tracing pid 0 tid 100029 td 0xffffff00018e1000 > kdb_enter() at kdb_enter+0x3d > panic() at panic+0x17b > _mtx_lock_flags() at _mtx_lock_flags+0xc5 > clnt_vc_soupcall() at clnt_vc_soupcall+0x273 > sowakeup() at sowakeup+0xf8 > tcp_do_segment() at tcp_do_segment+0x23c9 > tcp_input() at tcp_input+0x9ec > ip_input() at ip_input+0xbc > ether_demux() at ether_demux+0x1ed > ether_input() at ether_input+0x171 > em_rxeof() at em_rxeof+0x201 > em_handle_rxtx() at em_handle_rxtx+0x4b > taskqueue_run() at taskqueue_run+0x96 > taskqueue_thread_loop() at taskqueue_thread_loop+0x3f > fork_exit() at fork_exit+0x12a > fork_trampoline() at fork_trampoline+0xe > --- trap 0, rip = 0, rsp = 0xffffffff240a6d40, rbp = 0 --- > > The box is in kdb on serial console for now. May 9 -CURRENT, I think. > This happened again. The trigger was this (^C of a find on a busy netapp volume with a lot of other concurrent nfs traffic to the same mountpoint): pointyhat# find . -name \*.bz2 -mmin -10 ^Cnfs server dumpster:/vol/vol4/pointyhat: not responding nfs server dumpster:/vol/vol4/pointyhat: not responding nfs server dumpster:/vol/vol4/pointyhat: not responding nfs server dumpster:/vol/vol4/pointyhat: not responding nfs server dumpster:/vol/vol4/pointyhat: not responding nfs server dumpster:/vol/vol4/pointyhat: not responding nfs server dumpster:/vol/vol4/pointyhat: not responding nfs server dumpster:/vol/vol4/pointyhat: not responding nfs server dumpster:/vol/vol4/pointyhat: not responding nfs server dumpster:/vol/vol4/pointyhat: not responding nfs server dumpster:/vol/vol4/pointyhat: not responding nfs server dumpster:/vol/vol4/pointyhat: not responding load: 4.54 cmd: find 93357 [rpccon] 11.19u 111.62s 0% 4848k About 5-10 minutes later the machine panicked. I'll try updating to a newer -CURRENT. Kris From owner-freebsd-current@FreeBSD.ORG Mon Jun 15 21:03:07 2009 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 E238A106564A for ; Mon, 15 Jun 2009 21:03:07 +0000 (UTC) (envelope-from thomas+freebsd@lotterer.net) Received: from angel.hellmouth.lotterer.net (angel.hellmouth.lotterer.net [88.198.53.82]) by mx1.freebsd.org (Postfix) with ESMTP id 99CED8FC36 for ; Mon, 15 Jun 2009 21:03:07 +0000 (UTC) (envelope-from thomas+freebsd@lotterer.net) Received: from buffy.sunnydale.lotterer.net (ppp-93-104-163-93.dynamic.mnet-online.de [93.104.163.93]) by angel.hellmouth.lotterer.net (Postfix) with ESMTPS id 3CACE1EC21B; Mon, 15 Jun 2009 23:03:06 +0200 (CEST) Received: from [172.17.16.141] (faith.sunnydale.lotterer.net [172.17.16.141]) by buffy.sunnydale.lotterer.net (Postfix) with ESMTPSA id D0193107420; Mon, 15 Jun 2009 21:02:54 +0000 (UTC) Message-ID: <4A36B70F.1020107@lotterer.net> Date: Mon, 15 Jun 2009 23:03:11 +0200 From: Thomas Lotterer User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: pyunyh@gmail.com References: <4A2DA8D9.2030300@lotterer.net> <20090610024959.GD63941@michelle.cdnetworks.co.kr> <4A2FF8E3.4060501@lotterer.net> <20090611002923.GA68519@michelle.cdnetworks.co.kr> <4A30FD94.4030409@lotterer.net> <20090611130557.GB68519@michelle.cdnetworks.co.kr> <4A312517.9030206@lotterer.net> <20090612055032.GD72855@michelle.cdnetworks.co.kr> <4A32BAE7.40605@lotterer.net> <20090615015505.GB78415@michelle.cdnetworks.co.kr> In-Reply-To: <20090615015505.GB78415@michelle.cdnetworks.co.kr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=3.0 tests=UNPARSEABLE_RELAY autolearn=failed version=3.2.5-openpkg X-Spam-Checker-Version: SpamAssassin 3.2.5-openpkg (2008-06-10) on angel.hellmouth.lotterer.net Cc: freebsd-current@freebsd.org Subject: Re: suspect bug in vge(4) 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, 15 Jun 2009 21:03:09 -0000 From: Pyun YongHyeon Date: 2009-06-15 3:55:05 +0200 > On Fri, Jun 12, 2009 at 10:30:31PM +0200, Thomas Lotterer wrote: >> panic: Assertion mtx_unowned(m) failed at /usr/src/sys/kern/kern_mutex.c:827 > > This looks locking bug in driver. Show me backtrace info. > I'd like to, but I've no idea how to do it. First, this is NanoBSD with no space to dump core. Well, there is ZFS but I mind this is a good place to use. Second, this is ARTiGO with no serial and no PS/2 keyboard - only USB. There are certain times where FreeBSD lacks USB keyboard support. The MBR boot loader seems to leverage BIOS USB Keyboard support and works. Thereafter, boot block (override boot.config), loader (override loader.conf), the "beastie menue" (disable ACPI, safe mode, ...) and kernel debugger have BIOS USB keyboard dropped but do not support vanilla USB keyboard so I end up with not being able to type any key! Now realize how hard it was to get there :-| Cheers -- http://thomas.lotterer.net From owner-freebsd-current@FreeBSD.ORG Mon Jun 15 21:08:25 2009 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 7FE3F1065880; Mon, 15 Jun 2009 21:08:25 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.246]) by mx1.freebsd.org (Postfix) with ESMTP id 3291E8FC33; Mon, 15 Jun 2009 21:08:23 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: by an-out-0708.google.com with SMTP id c3so2108654ana.13 for ; Mon, 15 Jun 2009 14:08:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=VQtiIPqP+dPBbEYTiFeJ7B3zhDepy+8YLRCBJqDKfl0=; b=fFPWvREa+N5os4vxbCdbgUM2N3NhdwcQVsslAvB+3UxR7/+2DcyG92/Q/GMsc+ik4E 2ZuDzKoLfU6G8tcpfobHkS+Ea/fj9o+UNq8169uYrD7conrTOBqVOjZd4uzbv2ZzOLWR wbtSZg32trZmcw6xIuj9oVtyluiyJ0USkep3Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=OQusRW2OSQ2RYlEapqaJU77kOYLuRsTx/45cn99aqR/nnlE3p36CfyjFTL9IEMO2Af qrm5lwZ3rZaQSzYQ28l1Mp4iAWhOtwe2p/IgLT3Mr1yHGSf7xCgbZ9kgB7/kZIC8LZn4 csf5rkA/0OkMtSkRVDwRu+plw70Dq3F8uS1LI= MIME-Version: 1.0 Sender: mat.macy@gmail.com Received: by 10.100.208.9 with SMTP id f9mr9525873ang.55.1245100100677; Mon, 15 Jun 2009 14:08:20 -0700 (PDT) In-Reply-To: <4A36B6D8.8000701@FreeBSD.org> References: <1242075474.72992.118.camel@hood.oook.cz> <4A36B6D8.8000701@FreeBSD.org> Date: Mon, 15 Jun 2009 14:08:17 -0700 X-Google-Sender-Auth: b4dac494355ed748 Message-ID: <3c1674c90906151408n6febec56m140b089b694f6e13@mail.gmail.com> From: Kip Macy To: Doug Rabson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: pav@freebsd.org, current@freebsd.org Subject: Re: pointyhat 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: Mon, 15 Jun 2009 21:08:31 -0000 This is from the RPC re-work. I had thought that this was fixed. You shouldn't see this on the latest -CURRENT, but Doug will have more details. Cheers, Kip On Mon, Jun 15, 2009 at 2:02 PM, Kris Kennaway wrote: > Pav Lucistnik wrote: >> >> panic: mtx_lock() of destroyed mutex @ /usr/src/sys/rpc/clnt_vc.c:953 >> cpuid =3D 2 >> KDB: enter: panic >> [thread pid 0 tid 100029 ] >> Stopped at =A0 =A0 =A0kdb_enter+0x3d: movq =A0 =A0$0,0x3f5fb8(%rip) >> db> bt >> Tracing pid 0 tid 100029 td 0xffffff00018e1000 >> kdb_enter() at kdb_enter+0x3d >> panic() at panic+0x17b >> _mtx_lock_flags() at _mtx_lock_flags+0xc5 >> clnt_vc_soupcall() at clnt_vc_soupcall+0x273 >> sowakeup() at sowakeup+0xf8 >> tcp_do_segment() at tcp_do_segment+0x23c9 >> tcp_input() at tcp_input+0x9ec >> ip_input() at ip_input+0xbc >> ether_demux() at ether_demux+0x1ed >> ether_input() at ether_input+0x171 >> em_rxeof() at em_rxeof+0x201 >> em_handle_rxtx() at em_handle_rxtx+0x4b >> taskqueue_run() at taskqueue_run+0x96 >> taskqueue_thread_loop() at taskqueue_thread_loop+0x3f >> fork_exit() at fork_exit+0x12a >> fork_trampoline() at fork_trampoline+0xe >> --- trap 0, rip =3D 0, rsp =3D 0xffffffff240a6d40, rbp =3D 0 --- >> >> The box is in kdb on serial console for now. May 9 -CURRENT, I think. >> > > This happened again. =A0The trigger was this (^C of a find on a busy neta= pp > volume with a lot of other concurrent nfs traffic to the same mountpoint)= : > > pointyhat# find . -name \*.bz2 -mmin -10 > ^Cnfs server dumpster:/vol/vol4/pointyhat: not responding > nfs server dumpster:/vol/vol4/pointyhat: not responding > nfs server dumpster:/vol/vol4/pointyhat: not responding > nfs server dumpster:/vol/vol4/pointyhat: not responding > nfs server dumpster:/vol/vol4/pointyhat: not responding > nfs server dumpster:/vol/vol4/pointyhat: not responding > nfs server dumpster:/vol/vol4/pointyhat: not responding > nfs server dumpster:/vol/vol4/pointyhat: not responding > nfs server dumpster:/vol/vol4/pointyhat: not responding > nfs server dumpster:/vol/vol4/pointyhat: not responding > nfs server dumpster:/vol/vol4/pointyhat: not responding > nfs server dumpster:/vol/vol4/pointyhat: not responding > load: 4.54 =A0cmd: find 93357 [rpccon] 11.19u 111.62s 0% 4848k > > About 5-10 minutes later the machine panicked. =A0I'll try updating to a = newer > -CURRENT. > > Kris > --=20 When bad men combine, the good must associate; else they will fall one by one, an unpitied sacrifice in a contemptible struggle. Edmund Burke From owner-freebsd-current@FreeBSD.ORG Mon Jun 15 21:11:30 2009 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 8F9B31065877 for ; Mon, 15 Jun 2009 21:11:30 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from vlakno.cz (77-93-215-190.static.masterinter.net [77.93.215.190]) by mx1.freebsd.org (Postfix) with ESMTP id 469B68FC08 for ; Mon, 15 Jun 2009 21:11:29 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from localhost (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 620F09CB0F4 for ; Mon, 15 Jun 2009 23:11:25 +0200 (CEST) X-Virus-Scanned: amavisd-new at vlakno.cz Received: from vlakno.cz ([127.0.0.1]) by localhost (lev.vlakno.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RSYbJXYF07fz for ; Mon, 15 Jun 2009 23:11:23 +0200 (CEST) Received: from vlk.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 392629CB19F for ; Mon, 15 Jun 2009 23:11:23 +0200 (CEST) Received: (from rdivacky@localhost) by vlk.vlakno.cz (8.14.3/8.14.3/Submit) id n5FLBNlg088921 for current@freebsd.org; Mon, 15 Jun 2009 23:11:23 +0200 (CEST) (envelope-from rdivacky) Date: Mon, 15 Jun 2009 23:11:23 +0200 From: Roman Divacky To: current@freebsd.org Message-ID: <20090615211123.GA88422@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PEIAKu/WMn1b1Hv9" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: [PATCH]: typo in contrib/ipf 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, 15 Jun 2009 21:11:32 -0000 --PEIAKu/WMn1b1Hv9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable hi I found this typo: Index: tools/ipfcomp.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 RCS file: /home/ncvs/src/contrib/ipfilter/tools/ipfcomp.c,v retrieving revision 1.5 diff -u -r1.5 ipfcomp.c --- tools/ipfcomp.c 4 Jun 2007 02:54:34 -0000 1.5 +++ tools/ipfcomp.c 15 Jun 2009 21:10:14 -0000 @@ -382,7 +382,7 @@ extern frentry_t *ipf_rules_out_%s[%d];\n", grp->fg_name, grp->fg_name, outcount); =20 - for (g =3D groups; g !=3D g; g =3D g->fg_next) + for (g =3D groups; g !=3D grp; g =3D g->fg_next) if ((strncmp(g->fg_name, grp->fg_name, FR_GROUPLEN) =3D=3D 0) && g->fg_flags =3D=3D grp->fg_flags) can someone review it? darren reed ignored my mail. is it ok to commit to contrib/ipf ? thnx for the answers :) roman --PEIAKu/WMn1b1Hv9 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAko2uPoACgkQLVEj6D3CBEwRzQCfUO78NiULbNdsU+ERcsno+uAX xOAAn2RKoS+J61r9er1I+65bjLfEqzNH =qSNu -----END PGP SIGNATURE----- --PEIAKu/WMn1b1Hv9-- From owner-freebsd-current@FreeBSD.ORG Mon Jun 15 22:08:05 2009 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 647B1106564A for ; Mon, 15 Jun 2009 22:08:05 +0000 (UTC) (envelope-from nakal@web.de) Received: from fmmailgate03.web.de (fmmailgate03.web.de [217.72.192.234]) by mx1.freebsd.org (Postfix) with ESMTP id D8F6B8FC17 for ; Mon, 15 Jun 2009 22:08:04 +0000 (UTC) (envelope-from nakal@web.de) Received: from smtp07.web.de (fmsmtp07.dlan.cinetic.de [172.20.5.215]) by fmmailgate03.web.de (Postfix) with ESMTP id A5FA71001BD81; Tue, 16 Jun 2009 00:08:01 +0200 (CEST) Received: from [217.236.11.4] (helo=zelda.local) by smtp07.web.de with asmtp (TLSv1:AES128-SHA:128) (WEB.DE 4.110 #277) id 1MGKLQ-0006v2-00; Tue, 16 Jun 2009 00:08:00 +0200 Date: Tue, 16 Jun 2009 00:07:58 +0200 From: Martin To: Rick Macklem Message-ID: <20090616000758.714912e6@zelda.local> In-Reply-To: References: <4A2504AA.1020406@zedat.fu-berlin.de> <20090603235227.GB15659@hades.panopticon> <20090615173315.1cdb39e1@zelda.local> X-Mailer: Claws Mail 3.7.1 (GTK+ 2.16.2; amd64-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: nakal@web.de X-Sender: nakal@web.de X-Provags-ID: V01U2FsdGVkX18/mqoh7sKvbGMIrq6S1CE3mUEAUaJw2PUNK3fS VzkTXcQFrqZM9CEBr7mtwc1vLxxDMzw237OsgYR+KaAsaYQBcE 5CVnkuVtk= Cc: freebsd-current@FreeBSD.org, Dmitry Marakasov , Hartmann , Arnar Mar Sig , O. Subject: Re: RPCPROG_MNT: RPC: Timed out / receiving NFS error when trying to mount NFS file system after make world 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, 15 Jun 2009 22:08:05 -0000 Am Mon, 15 Jun 2009 16:20:59 -0400 (EDT) schrieb Rick Macklem : > Are you using a recently built userland? I ask because there have been > some recent changes to the rpc routines in libc related to routing > replies. > > One of them used a uint32_t argument to _setsockopt() until it > was changed to "int" on May 28. > > The changes I put in nfsd.c had nothing to do with the "-h" option > or use of rpcbind(), so I don't think my changes would be the culprit. > > rick Hi Rick, I've rebuilt the userland, of course. # ls -l /lib/libc.so* -r--r--r-- 1 root wheel 1234432 Jun 15 01:04 /lib/libc.so.7 # ls -l /boot/kernel/kernel -r-xr-xr-x 1 root wheel 12010608 Jun 15 01:38 /boot/kernel/kernel Further info to diagnose the problem: I've got 3 NICs on 35, 135 and 235 (different subnets). Netmasks are: - xx.xx.xx.35/25 - xx.xx.xx.135/26 - xx.xx.xx.235/26 Client is xx.xx.xx.150/26. But you can try it with a single server. A mount on 127.0.0.1 won't work either. Here relevant part of rc.conf: nfs_server_flags="-t -n 4 -h xx.xx.xx.35 -h xx.xx.xx.135" mountd_flags="-l -r -h xx.xx.xx.35 -h xx.xx.xx.135" /etc/exports: /usr/export/src -maproot=root -ro -network xx.xx.xx.128 -mask 255.255.255.192 And here what I changed (rpcbind_flags) and the effects. Notice, I executed rpcinfo each time before restarting nfsd and mountd. Maybe I don't understand the rpcinfo output, because it differs from sockstat. ------------------------------ rpcbind_flags="-h xx.xx.xx.35 -h xx.xx.xx.135" # rpcinfo program version netid address service owner 100000 4 tcp xx.xx.xx.35.0.111 rpcbind superuser 100000 3 tcp xx.xx.xx.35.0.111 rpcbind superuser 100000 2 tcp xx.xx.xx.35.0.111 rpcbind superuser 100000 4 udp xx.xx.xx.35.0.111 rpcbind superuser 100000 3 udp xx.xx.xx.35.0.111 rpcbind superuser 100000 2 udp xx.xx.xx.35.0.111 rpcbind superuser 100000 4 tcp6 ::1.0.111 rpcbind superuser 100000 3 tcp6 ::1.0.111 rpcbind superuser 100000 4 udp6 ::1.0.111 rpcbind superuser 100000 3 udp6 ::1.0.111 rpcbind superuser 100000 4 local /var/run/rpcbind.sock rpcbind superuser 100000 3 local /var/run/rpcbind.sock rpcbind superuser 100000 2 local /var/run/rpcbind.sock rpcbind superuser # sockstat | grep rpcbind root rpcbind 28763 4 udp6 *:* *:* root rpcbind 28763 5 stream /var/run/rpcbind.sock root rpcbind 28763 6 udp6 ::1:111 *:* root rpcbind 28763 7 udp6 *:1008 *:* root rpcbind 28763 8 tcp6 ::1:111 *:* root rpcbind 28763 9 udp4 127.0.0.1:111 *:* root rpcbind 28763 10 udp4 xx.xx.xx.135:111 *:* root rpcbind 28763 11 udp4 xx.xx.xx.35:111 *:* root rpcbind 28763 12 udp4 *:842 *:* root rpcbind 28763 13 tcp4 127.0.0.1:111 *:* root rpcbind 28763 14 tcp4 xx.xx.xx.135:111 *:* root rpcbind 28763 15 tcp4 xx.xx.xx.35:111 *:* client# mount_nfs -o ro,tcp,intr,soft,bg,nfsv3 xx.xx.xx.35:/usr/export/src /usr/src [tcp] xx.xx.xx.35:/usr/export/src: RPCPROG_NFS: RPC: Port mapper failure - RPC: Timed out mount_nfs: Cannot immediately mount xx.xx.xx.35:/usr/export/src, backgrounding -------------------------------------- rpcbind_flags="-h xx.xx.xx.135 -h xx.xx.xx.35" # rpcinfo program version netid address service owner 100000 4 tcp xx.xx.xx.135.0.111 rpcbind superuser 100000 3 tcp xx.xx.xx.135.0.111 rpcbind superuser 100000 2 tcp xx.xx.xx.135.0.111 rpcbind superuser 100000 4 udp xx.xx.xx.135.0.111 rpcbind superuser 100000 3 udp xx.xx.xx.135.0.111 rpcbind superuser 100000 2 udp xx.xx.xx.135.0.111 rpcbind superuser 100000 4 tcp6 ::1.0.111 rpcbind superuser 100000 3 tcp6 ::1.0.111 rpcbind superuser 100000 4 udp6 ::1.0.111 rpcbind superuser 100000 3 udp6 ::1.0.111 rpcbind superuser 100000 4 local /var/run/rpcbind.sock rpcbind superuser 100000 3 local /var/run/rpcbind.sock rpcbind superuser 100000 2 local /var/run/rpcbind.sock rpcbind superuser # sockstat | grep rpcbind root rpcbind 28591 4 udp6 *:* *:* root rpcbind 28591 5 stream /var/run/rpcbind.sock root rpcbind 28591 6 udp6 ::1:111 *:* root rpcbind 28591 7 udp6 *:825 *:* root rpcbind 28591 8 tcp6 ::1:111 *:* root rpcbind 28591 9 udp4 127.0.0.1:111 *:* root rpcbind 28591 10 udp4 xx.xx.xx.35:111 *:* root rpcbind 28591 11 udp4 xx.xx.xx.135:111 *:* root rpcbind 28591 12 udp4 *:1009 *:* root rpcbind 28591 13 tcp4 127.0.0.1:111 *:* root rpcbind 28591 14 tcp4 xx.xx.xx.35:111 *:* root rpcbind 28591 15 tcp4 xx.xx.xx.135:111 *:* client# mount_nfs -o ro,tcp,intr,soft,bg,nfsv3 xx.xx.xx.35:/usr/export/src /usr/src [tcp] xx.xx.xx.35:/usr/export/src: RPCPROG_NFS: RPC: Port mapper failure - RPC: Timed out mount_nfs: Cannot immediately mount xx.xx.xx.35:/usr/export/src, backgrounding -------------------------------------- rpcbind_flags="-h xx.xx.xx.135 -h xx.xx.xx.35 -h xx.xx.xx.235" # rpcinfo program version netid address service owner 100000 4 tcp xx.xx.xx.135.0.111 rpcbind superuser 100000 3 tcp xx.xx.xx.135.0.111 rpcbind superuser 100000 2 tcp xx.xx.xx.135.0.111 rpcbind superuser 100000 4 udp xx.xx.xx.135.0.111 rpcbind superuser 100000 3 udp xx.xx.xx.135.0.111 rpcbind superuser 100000 2 udp xx.xx.xx.135.0.111 rpcbind superuser 100000 4 tcp6 ::1.0.111 rpcbind superuser 100000 3 tcp6 ::1.0.111 rpcbind superuser 100000 4 udp6 ::1.0.111 rpcbind superuser 100000 3 udp6 ::1.0.111 rpcbind superuser 100000 4 local /var/run/rpcbind.sock rpcbind superuser 100000 3 local /var/run/rpcbind.sock rpcbind superuser 100000 2 local /var/run/rpcbind.sock rpcbind superuser # sockstat |grep rpcbind root rpcbind 28564 4 udp6 *:* *:* root rpcbind 28564 5 stream /var/run/rpcbind.sock root rpcbind 28564 6 udp6 ::1:111 *:* root rpcbind 28564 7 udp6 *:892 *:* root rpcbind 28564 8 tcp6 ::1:111 *:* root rpcbind 28564 9 udp4 127.0.0.1:111 *:* root rpcbind 28564 10 udp4 xx.xx.xx.235:111 *:* root rpcbind 28564 11 udp4 xx.xx.xx.35:111 *:* root rpcbind 28564 12 udp4 xx.xx.xx.135:111 *:* root rpcbind 28564 13 udp4 *:630 *:* root rpcbind 28564 14 tcp4 127.0.0.1:111 *:* root rpcbind 28564 15 tcp4 xx.xx.xx.235:111 *:* root rpcbind 28564 16 tcp4 xx.xx.xx.35:111 *:* root rpcbind 28564 17 tcp4 xx.xx.xx.135:111 *:* client# mount_nfs -o ro,tcp,intr,soft,bg,nfsv3 xx.xx.xx.35:/usr/export/src /usr/src [tcp] xx.xx.xx.35:/usr/export/src: RPCPROG_NFS: RPC: Port mapper failure - RPC: Timed out mount_nfs: Cannot immediately mount xx.xx.xx.35:/usr/export/src, backgrounding -------------------------------------- rpcbind_flags="" # rpcinfo program version netid address service owner 100000 4 tcp 0.0.0.0.0.111 rpcbind superuser 100000 3 tcp 0.0.0.0.0.111 rpcbind superuser 100000 2 tcp 0.0.0.0.0.111 rpcbind superuser 100000 4 udp 0.0.0.0.0.111 rpcbind superuser 100000 3 udp 0.0.0.0.0.111 rpcbind superuser 100000 2 udp 0.0.0.0.0.111 rpcbind superuser 100000 4 tcp6 ::.0.111 rpcbind superuser 100000 3 tcp6 ::.0.111 rpcbind superuser 100000 4 udp6 ::.0.111 rpcbind superuser 100000 3 udp6 ::.0.111 rpcbind superuser 100000 4 local /var/run/rpcbind.sock rpcbind superuser 100000 3 local /var/run/rpcbind.sock rpcbind superuser 100000 2 local /var/run/rpcbind.sock rpcbind superuser # sockstat | grep rpcbind root rpcbind 28735 4 udp6 *:* *:* root rpcbind 28735 5 stream /var/run/rpcbind.sock root rpcbind 28735 6 udp6 *:111 *:* root rpcbind 28735 7 udp6 *:718 *:* root rpcbind 28735 8 tcp6 *:111 *:* root rpcbind 28735 9 udp4 *:111 *:* root rpcbind 28735 10 udp4 *:870 *:* root rpcbind 28735 11 tcp4 *:111 *:* client# mount_nfs -o ro,tcp,intr,soft,bg,nfsv3 xx.xx.xx.35:/usr/export/src /usr/src client# umount /usr/src umount: xx.xx.xx.35: RPCMNT_UMOUNT: RPC: Timed out --------------------------------- Hmm... the mount has been successful, but I wonder why umount still gets a time out... Need more info? -- Martin From owner-freebsd-current@FreeBSD.ORG Mon Jun 15 22:09:52 2009 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 CEAF510656DD; Mon, 15 Jun 2009 22:09:52 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.freebsd.org (Postfix) with ESMTP id 8D33A8FC1E; Mon, 15 Jun 2009 22:09:52 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.14.2/8.14.1) with ESMTP id n5FM9pDN007071; Mon, 15 Jun 2009 15:09:51 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.14.2/8.13.4/Submit) id n5FM9psY007070; Mon, 15 Jun 2009 15:09:51 -0700 (PDT) Date: Mon, 15 Jun 2009 15:09:51 -0700 (PDT) From: Matthew Dillon Message-Id: <200906152209.n5FM9psY007070@apollo.backplane.com> To: Daan Vreeken References: <4A254B45.8050800@mavhome.dp.ua> <4A294DC3.5010008@mavhome.dp.ua> <200906051728.n55HSFf0076644@apollo.backplane.com> <200906152352.48231.Daan@vehosting.nl> Cc: Alexander Motin , FreeBSD-Current , freebsd-arch@freebsd.org Subject: Re: WIP: ATA to CAM integration 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, 15 Jun 2009 22:09:53 -0000 :Hi, : :According to the following link : : http://www.siliconimage.com/products/product.aspx?pid=32 : :the SiI3132 supports FIS based switching. We use them in a storage server :prototype. : :Regards, :-- :Daan Vreeken :VEHosting Yah, I have a bunch of those. They aren't AHCI parts though (as far as I know) so it doesn't help with the AHCI driver. They have their own custom driver. But thanks for mentioning it :-) (Someone tell me if I'm wrong there, I'm pretty sure all the Sili stuff uses a Sili-specific device driver). -Matt From owner-freebsd-current@FreeBSD.ORG Mon Jun 15 21:53:21 2009 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 1C92C10656BA; Mon, 15 Jun 2009 21:53:21 +0000 (UTC) (envelope-from Daan@vehosting.nl) Received: from VM01.VEHosting.nl (unknown [IPv6:2001:470:1f14:32d::1:140]) by mx1.freebsd.org (Postfix) with ESMTP id D08CF8FC1B; Mon, 15 Jun 2009 21:53:20 +0000 (UTC) (envelope-from Daan@vehosting.nl) Received: from [192.168.72.10] (124-54.bbned.dsl.internl.net [92.254.54.124]) (authenticated bits=0) by VM01.VEHosting.nl (8.14.3/8.13.8) with ESMTP id n5FLrHDI055760; Mon, 15 Jun 2009 23:53:17 +0200 (CEST) (envelope-from Daan@vehosting.nl) From: Daan Vreeken Organization: VEHosting.nl - Vitsch Electronics Hosting To: freebsd-arch@freebsd.org Date: Mon, 15 Jun 2009 23:52:47 +0200 User-Agent: KMail/1.9.10 References: <4A254B45.8050800@mavhome.dp.ua> <4A294DC3.5010008@mavhome.dp.ua> <200906051728.n55HSFf0076644@apollo.backplane.com> In-Reply-To: <200906051728.n55HSFf0076644@apollo.backplane.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200906152352.48231.Daan@vehosting.nl> x-ve-auth-version: mi-1.0.3 2008-05-30 - Copyright (c) 2008 - Daan Vreeken - VEHosting x-ve-auth: authenticated as 'pa4dan' on VM01.VEHosting.nl X-Mailman-Approved-At: Mon, 15 Jun 2009 22:18:15 +0000 Cc: FreeBSD-Current , Alexander Motin Subject: Re: WIP: ATA to CAM integration 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, 15 Jun 2009 21:53:22 -0000 Hi, On Friday 05 June 2009 19:28:15 Matthew Dillon wrote: > :Latest AHCI specifications define feature named FIS Based Switching. It > :allows controller independently track state of every device beyond port > :multiplier. It should be quite easy to use it, but actually none of my > :controllers have that capability. > > Damn. The FBSS capability bit is not set on my (AMD) MCP77 based AHCI > SATA controller. That sucks. > > ahci0: ... > ahci0: AHCI 1.2 capabilities > 0xe3229f05, 6 port > > Do you know of any host controllers which support FBS ? Any of the > Intel parts or machines per-chance? ... According to the following link : http://www.siliconimage.com/products/product.aspx?pid=32 the SiI3132 supports FIS based switching. We use them in a storage server prototype. Regards, -- Daan Vreeken VEHosting http://VEHosting.nl tel: +31-(0)40-7113050 / +31-(0)6-46210825 KvK nr: 17174380 From owner-freebsd-current@FreeBSD.ORG Mon Jun 15 22:27:16 2009 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 0B69E106566C; Mon, 15 Jun 2009 22:27:16 +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 B96388FC0C; Mon, 15 Jun 2009 22:27:15 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id n5FMRCsO064820; Mon, 15 Jun 2009 18:27:12 -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.3/8.14.3) with ESMTP id n5FMRCpW017594; Mon, 15 Jun 2009 18:27:12 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 265957302F; Mon, 15 Jun 2009 18:27:12 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090615222712.265957302F@freebsd-current.sentex.ca> Date: Mon, 15 Jun 2009 18:27:12 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp1.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on mips/mips 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: Mon, 15 Jun 2009 22:27:16 -0000 TB --- 2009-06-15 22:10:50 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-06-15 22:10:50 - starting HEAD tinderbox run for mips/mips TB --- 2009-06-15 22:10:50 - cleaning the object tree TB --- 2009-06-15 22:11:07 - cvsupping the source tree TB --- 2009-06-15 22:11:07 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/mips/mips/supfile TB --- 2009-06-15 22:11:19 - building world TB --- 2009-06-15 22:11:19 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-15 22:11:19 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-15 22:11:19 - TARGET=mips TB --- 2009-06-15 22:11:19 - TARGET_ARCH=mips TB --- 2009-06-15 22:11:19 - TZ=UTC TB --- 2009-06-15 22:11:19 - __MAKE_CONF=/dev/null TB --- 2009-06-15 22:11:19 - cd /src TB --- 2009-06-15 22:11:19 - /usr/bin/make -B buildworld >>> World build started on Mon Jun 15 22:11:21 UTC 2009 >>> 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 [...] rm -f .depend mkdep -f .depend -a -I/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/src/kerberos5/lib/libasn1/../../include asn1_err.c /src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1/der_copy.c /src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1/der_cmp.c /src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1/der_free.c /src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1/der_format.c /src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1/der_get.c /src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1/der_length.c /src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1/der_put.c /src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1/extra.c /src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1/timegm.c asn1_Version.c asn1_id_pkcs_1.c asn1_id_pkcs1_rsaEncryption.c asn1_id_pkcs1_md2WithRSAEncryption.c asn1_id_pkcs1_md5WithRSAEncryption .c asn1_id_pkcs1_sha1WithRSAEncryption.c asn1_id_pkcs1_sha256WithRSAEncryption.c asn1_id_pkcs1_sha384WithRSAEncryption.c asn1_id_pkcs1_sha512WithRSAEncryption.c asn1_id_heim_rsa_pkcs1_x509.c asn1_id_pkcs_2.c asn1_id_pkcs2_md2.c asn1_id_pkcs2_md4.c asn1_id_pkcs2_md5.c asn1_id_rsa_digestAlgorithm.c asn1_id_rsa_digest_md2.c asn1_id_rsa_digest_md4.c asn1_id_rsa_digest_md5.c asn1_id_pkcs_3.c asn1_id_pkcs3_rc2_cbc.c asn1_id_pkcs3_rc4.c asn1_id_pkcs3_des_ede3_cbc.c asn1_id_rsadsi_encalg.c asn1_id_rsadsi_rc2_cbc.c asn1_id_rsadsi_des_ede3_cbc.c asn1_id_secsig_sha_1.c asn1_id_nistAlgorithm.c asn1_id_nist_aes_algs.c asn1_id_aes_128_cbc.c asn1_id_aes_192_cbc.c asn1_id_aes_256_cbc.c asn1_id_nist_sha_algs.c asn1_id_sha256.c asn1_id_sha224.c asn1_id_sha384.c asn1_id_sha512.c asn1_id_dhpublicnumber.c asn1_id_x9_57.c asn1_id_dsa.c asn1_id_dsa_with_sha1.c asn1_id_x520_at.c asn1_id_at_commonName.c asn1_id_at_surname.c asn1_id_at_serialNumber.c asn1_id_at_countryName.c asn1_id_at_localityName.c asn1_id_at_streetAddress.c asn1_id_at_stateOrProvinceName.c asn1_id_at_organizationName.c asn1_id_at_organizationalUnitName.c asn1_id_at_name.c asn1_id_at_givenName.c asn1_id_at_initials.c asn1_id_at_generationQualifier.c asn1_id_at_pseudonym.c asn1_id_Userid.c asn1_id_domainComponent.c asn1_id_x509_ce.c asn1_id_uspkicommon_card_id.c asn1_id_uspkicommon_piv_interim.c asn1_id_netscape.c asn1_id_netscape_cert_comment.c asn1_id_ms_cert_enroll_domaincontroller.c asn1_id_ms_client_authentication.c asn1_AlgorithmIdentifier.c asn1_AttributeType.c asn1_AttributeValue.c asn1_TeletexStringx.c asn1_DirectoryString.c asn1_Attribute.c asn1_AttributeTypeAndValue.c asn1_AuthorityInfoAccessSyntax.c asn1_AccessDescription.c asn1_RelativeDistinguishedName.c asn1_RDNSequence.c asn1_Name.c asn1_CertificateSerialNumber.c asn1_Time.c asn1_Validity.c asn1_UniqueIdentifier.c asn1_SubjectPublicKeyInfo.c asn1_Extension.c asn1_Extensions.c asn1_TBSCertificate.c asn1_Certificate.c asn1_Certificates.c asn1_ValidationParms.c asn1_DomainParameters.c asn1_DHPublicKey.c asn1_OtherName.c asn1_GeneralName.c asn1_GeneralNames.c asn1_id_x509_ce_keyUsage.c asn1_KeyUsage.c asn1_id_x509_ce_authorityKeyIdentifier.c asn1_KeyIdentifier.c asn1_AuthorityKeyIdentifier.c asn1_id_x509_ce_subjectKeyIdentifier.c asn1_SubjectKeyIdentifier.c asn1_id_x509_ce_basicConstraints.c asn1_BasicConstraints.c asn1_id_x509_ce_nameConstraints.c asn1_BaseDistance.c asn1_GeneralSubtree.c asn1_GeneralSubtrees.c asn1_NameConstraints.c asn1_id_x509_ce_privateKeyUsagePeriod.c asn1_id_x509_ce_certificatePolicies.c asn1_id_x509_ce_policyMappings.c asn1_id_x509_ce_subjectAltName.c asn1_id_x509_ce_issuerAltName.c asn1_id_x509_ce_subjectDirectoryAttributes.c asn1_id_x509_ce_policyConstraints.c asn1_id_x509_ce_extKeyUsage.c asn1_ExtKeyUsage.c asn1_id_x509_ce_cRLDistributionPoints.c asn1_id_x509_ce_deltaCRLIndicator.c asn1_id_x509_ce_issuingDistributionPoint.c asn1_id_x509_ce_holdInstructionCode.c asn1_id_x509_ce_inval idityDate.c asn1_id_x509_ce_certificateIssuer.c asn1_id_x509_ce_inhibitAnyPolicy.c asn1_DistributionPointReasonFlags.c asn1_DistributionPointName.c asn1_DistributionPoint.c asn1_CRLDistributionPoints.c asn1_DSASigValue.c asn1_DSAPublicKey.c asn1_DSAParams.c asn1_RSAPublicKey.c asn1_RSAPrivateKey.c asn1_DigestInfo.c asn1_TBSCRLCertList.c asn1_CRLCertificateList.c asn1_id_x509_ce_cRLNumber.c asn1_id_x509_ce_freshestCRL.c asn1_id_x509_ce_cRLReason.c asn1_CRLReason.c asn1_PKIXXmppAddr.c asn1_id_pkix.c asn1_id_pkix_on.c asn1_id_pkix_on_dnsSRV.c asn1_id_pkix_on_xmppAddr.c asn1_id_pkix_kp.c asn1_id_pkix_kp_serverAuth.c asn1_id_pkix_kp_clientAuth.c asn1_id_pkix_kp_emailProtection.c asn1_id_pkix_kp_timeStamping.c asn1_id_pkix_kp_OCSPSigning.c asn1_id_pkix_pe.c asn1_id_pkix_pe_authorityInfoAccess.c asn1_id_pkix_pe_proxyCertInfo.c asn1_id_pkix_ppl.c asn1_id_pkix_ppl_anyLanguage.c asn1_id_pkix_ppl_inheritAll.c asn1_id_pkix_ppl_independent.c asn1_ProxyPolicy.c asn1_ProxyCertInfo.c asn1_C MSAttributes.c asn1_CMSCBCParameter.c asn1_CMSEncryptedData.c asn1_CMSIdentifier.c asn1_CMSRC2CBCParameter.c asn1_CMSVersion.c asn1_CertificateList.c asn1_CertificateRevocationLists.c asn1_CertificateSet.c asn1_ContentEncryptionAlgorithmIdentifier.c asn1_ContentInfo.c asn1_ContentType.c asn1_DigestAlgorithmIdentifier.c asn1_DigestAlgorithmIdentifiers.c asn1_EncapsulatedContentInfo.c asn1_EncryptedContent.c asn1_EncryptedContentInfo.c asn1_EncryptedKey.c asn1_EnvelopedData.c asn1_IssuerAndSerialNumber.c asn1_KeyEncryptionAlgorithmIdentifier.c asn1_KeyTransRecipientInfo.c asn1_MessageDigest.c asn1_OriginatorInfo.c asn1_RecipientIdentifier.c asn1_RecipientInfo.c asn1_RecipientInfos.c asn1_SignatureAlgorithmIdentifier.c asn1_SignatureValue.c asn1_SignedData.c asn1_SignerIdentifier.c asn1_SignerInfo.c asn1_SignerInfos.c asn1_id_pkcs7.c asn1_id_pkcs7_data.c asn1_id_pkcs7_digestedData.c asn1_id_pkcs7_encryptedData.c asn1_id_pkcs7_envelopedData.c asn1_id_pkcs7_signedAndEnvelopedData .c asn1_id_pkcs7_signedData.c asn1_UnprotectedAttributes.c asn1_AD_AND_OR.c asn1_AD_IF_RELEVANT.c asn1_AD_KDCIssued.c asn1_AD_MANDATORY_FOR_KDC.c asn1_AD_LoginAlias.c asn1_APOptions.c asn1_AP_REP.c asn1_AP_REQ.c asn1_AS_REP.c asn1_AS_REQ.c asn1_AUTHDATA_TYPE.c asn1_Authenticator.c asn1_AuthorizationData.c asn1_AuthorizationDataElement.c asn1_CKSUMTYPE.c asn1_ChangePasswdDataMS.c asn1_Checksum.c asn1_ENCTYPE.c asn1_ETYPE_INFO.c asn1_ETYPE_INFO2.c asn1_ETYPE_INFO2_ENTRY.c asn1_ETYPE_INFO_ENTRY.c asn1_EncAPRepPart.c asn1_EncASRepPart.c asn1_EncKDCRepPart.c asn1_EncKrbCredPart.c asn1_EncKrbPrivPart.c asn1_EncTGSRepPart.c asn1_EncTicketPart.c asn1_EncryptedData.c asn1_EncryptionKey.c asn1_EtypeList.c asn1_HostAddress.c asn1_HostAddresses.c asn1_KDCOptions.c asn1_KDC_REP.c asn1_KDC_REQ.c asn1_KDC_REQ_BODY.c asn1_KRB_CRED.c asn1_KRB_ERROR.c asn1_KRB_PRIV.c asn1_KRB_SAFE.c asn1_KRB_SAFE_BODY.c asn1_KerberosString.c asn1_KerberosTime.c asn1_KrbCredInfo.c asn1_LR_TYPE.c asn1_LastReq.c asn1_MESSAGE_TYPE.c asn1_METHOD_DATA.c asn1_NAME_TYPE.c asn1_PADATA_TYPE.c asn1_PA_DATA.c asn1_PA_ENC_SAM_RESPONSE_ENC.c asn1_PA_ENC_TS_ENC.c asn1_PA_PAC_REQUEST.c asn1_PA_S4U2Self.c asn1_PA_SAM_CHALLENGE_2.c asn1_PA_SAM_CHALLENGE_2_BODY.c asn1_PA_SAM_REDIRECT.c asn1_PA_SAM_RESPONSE_2.c asn1_PA_SAM_TYPE.c asn1_PA_ClientCanonicalized.c asn1_PA_ClientCanonicalizedNames.c asn1_PA_SvrReferralData.c asn1_PROV_SRV_LOCATION.c asn1_Principal.c asn1_PrincipalName.c asn1_Realm.c asn1_SAMFlags.c asn1_TGS_REP.c asn1_TGS_REQ.c asn1_TYPED_DATA.c asn1_Ticket.c asn1_TicketFlags.c asn1_TransitedEncoding.c asn1_TypedData.c asn1_krb5int32.c asn1_krb5uint32.c asn1_KRB5SignedPathData.c asn1_KRB5SignedPathPrincipals.c asn1_KRB5SignedPath.c asn1_id_pkinit.c asn1_id_pkauthdata.c asn1_id_pkdhkeydata.c asn1_id_pkrkeydata.c asn1_id_pkekuoid.c asn1_id_pkkdcekuoid.c asn1_id_pkinit_san.c asn1_id_pkinit_ms_eku.c asn1_id_pkinit_ms_san.c asn1_MS_UPN_SAN.c asn1_DHNonce.c asn1_KDFAlgorithmId.c asn1_TrustedCA .c asn1_ExternalPrincipalIdentifier.c asn1_ExternalPrincipalIdentifiers.c asn1_PA_PK_AS_REQ.c asn1_PKAuthenticator.c asn1_AuthPack.c asn1_TD_TRUSTED_CERTIFIERS.c asn1_TD_INVALID_CERTIFICATES.c asn1_KRB5PrincipalName.c asn1_AD_INITIAL_VERIFIED_CAS.c asn1_DHRepInfo.c asn1_PA_PK_AS_REP.c asn1_KDCDHKeyInfo.c asn1_ReplyKeyPack.c asn1_TD_DH_PARAMETERS.c asn1_PKAuthenticator_Win2k.c asn1_AuthPack_Win2k.c asn1_TrustedCA_Win2k.c asn1_PA_PK_AS_REQ_Win2k.c asn1_PA_PK_AS_REP_Win2k.c asn1_KDCDHKeyInfo_Win2k.c asn1_ReplyKeyPack_Win2k.c asn1_PkinitSuppPubInfo.c asn1_PKCS8PrivateKeyAlgorithmIdentifier.c asn1_PKCS8PrivateKey.c asn1_PKCS8PrivateKeyInfo.c asn1_PKCS8Attributes.c asn1_PKCS8EncryptedPrivateKeyInfo.c asn1_PKCS8EncryptedData.c asn1_id_pkcs_9.c asn1_id_pkcs9_contentType.c asn1_id_pkcs9_emailAddress.c asn1_id_pkcs9_messageDigest.c asn1_id_pkcs9_signingTime.c asn1_id_pkcs9_countersignature.c asn1_id_pkcs_9_at_friendlyName.c asn1_id_pkcs_9_at_localKeyId.c asn1_id_pkcs_9_at_certTypes.c asn1_id_pkcs_9_at_certTypes_x509.c asn1_PKCS9_BMPString.c asn1_PKCS9_friendlyName.c asn1_id_pkcs_12.c asn1_id_pkcs_12PbeIds.c asn1_id_pbeWithSHAAnd128BitRC4.c asn1_id_pbeWithSHAAnd40BitRC4.c asn1_id_pbeWithSHAAnd3_KeyTripleDES_CBC.c asn1_id_pbeWithSHAAnd2_KeyTripleDES_CBC.c asn1_id_pbeWithSHAAnd128BitRC2_CBC.c asn1_id_pbewithSHAAnd40BitRC2_CBC.c asn1_id_pkcs12_bagtypes.c asn1_id_pkcs12_keyBag.c asn1_id_pkcs12_pkcs8ShroudedKeyBag.c asn1_id_pkcs12_certBag.c asn1_id_pkcs12_crlBag.c asn1_id_pkcs12_secretBag.c asn1_id_pkcs12_safeContentsBag.c asn1_PKCS12_MacData.c asn1_PKCS12_PFX.c asn1_PKCS12_AuthenticatedSafe.c asn1_PKCS12_CertBag.c asn1_PKCS12_Attribute.c asn1_PKCS12_Attributes.c asn1_PKCS12_SafeBag.c asn1_PKCS12_SafeContents.c asn1_PKCS12_OctetString.c asn1_PKCS12_PBEParams.c asn1_DigestError.c asn1_DigestInit.c asn1_DigestInitReply.c asn1_DigestREP.c asn1_DigestREQ.c asn1_DigestRepInner.c asn1_DigestReqInner.c asn1_DigestRequest.c asn1_DigestResponse.c asn1_DigestTypes.c asn 1_NTLMInit.c asn1_NTLMInitReply.c asn1_NTLMRequest.c asn1_NTLMResponse.c asn1_Kx509Response.c asn1_Kx509Request.c cc -O -pipe -EL -msoft-float -G0 -mno-dsp -mabicalls -I/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/src/kerberos5/lib/libasn1/../../include -std=gnu99 -c asn1_err.c cc -O -pipe -EL -msoft-float -G0 -mno-dsp -mabicalls -I/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/src/kerberos5/lib/libasn1/../../include -std=gnu99 -c /src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1/der_copy.c In file included from /src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1/der_locl.h:50, from /src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1/der_copy.c:34: /obj/mips/src/tmp/usr/include/roken.h:248: error: conflicting types for 'closefrom' /obj/mips/src/tmp/usr/include/unistd.h:329: error: previous declaration of 'closefrom' was here *** Error code 1 Stop in /src/kerberos5/lib/libasn1. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-15 22:27:11 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-15 22:27:11 - ERROR: failed to build world TB --- 2009-06-15 22:27:11 - 743.58 user 75.84 system 981.00 real http://tinderbox.des.no/tinderbox-head-HEAD-mips-mips.full From owner-freebsd-current@FreeBSD.ORG Mon Jun 15 22:45:49 2009 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 A42101065674; Mon, 15 Jun 2009 22:45:49 +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 6E1918FC1C; Mon, 15 Jun 2009 22:45:49 +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.3/8.14.3) with ESMTP id n5FMjlcd066287; Mon, 15 Jun 2009 18:45:47 -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 n5FMjkBu048197; Mon, 15 Jun 2009 18:45:46 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id C77BB7302F; Mon, 15 Jun 2009 18:45:46 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090615224546.C77BB7302F@freebsd-current.sentex.ca> Date: Mon, 15 Jun 2009 18:45:46 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp2.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 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: Mon, 15 Jun 2009 22:45:50 -0000 TB --- 2009-06-15 22:27:12 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-06-15 22:27:12 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2009-06-15 22:27:12 - cleaning the object tree TB --- 2009-06-15 22:27:55 - cvsupping the source tree TB --- 2009-06-15 22:27:55 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2009-06-15 22:28:04 - building world TB --- 2009-06-15 22:28:04 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-15 22:28:04 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-15 22:28:04 - TARGET=powerpc TB --- 2009-06-15 22:28:04 - TARGET_ARCH=powerpc TB --- 2009-06-15 22:28:04 - TZ=UTC TB --- 2009-06-15 22:28:04 - __MAKE_CONF=/dev/null TB --- 2009-06-15 22:28:04 - cd /src TB --- 2009-06-15 22:28:04 - /usr/bin/make -B buildworld >>> World build started on Mon Jun 15 22:28:06 UTC 2009 >>> 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 [...] rm -f .depend mkdep -f .depend -a -I/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/src/kerberos5/lib/libasn1/../../include asn1_err.c /src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1/der_copy.c /src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1/der_cmp.c /src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1/der_free.c /src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1/der_format.c /src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1/der_get.c /src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1/der_length.c /src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1/der_put.c /src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1/extra.c /src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1/timegm.c asn1_Version.c asn1_id_pkcs_1.c asn1_id_pkcs1_rsaEncryption.c asn1_id_pkcs1_md2WithRSAEncryption.c asn1_id_pkcs1_md5WithRSAEncryption .c asn1_id_pkcs1_sha1WithRSAEncryption.c asn1_id_pkcs1_sha256WithRSAEncryption.c asn1_id_pkcs1_sha384WithRSAEncryption.c asn1_id_pkcs1_sha512WithRSAEncryption.c asn1_id_heim_rsa_pkcs1_x509.c asn1_id_pkcs_2.c asn1_id_pkcs2_md2.c asn1_id_pkcs2_md4.c asn1_id_pkcs2_md5.c asn1_id_rsa_digestAlgorithm.c asn1_id_rsa_digest_md2.c asn1_id_rsa_digest_md4.c asn1_id_rsa_digest_md5.c asn1_id_pkcs_3.c asn1_id_pkcs3_rc2_cbc.c asn1_id_pkcs3_rc4.c asn1_id_pkcs3_des_ede3_cbc.c asn1_id_rsadsi_encalg.c asn1_id_rsadsi_rc2_cbc.c asn1_id_rsadsi_des_ede3_cbc.c asn1_id_secsig_sha_1.c asn1_id_nistAlgorithm.c asn1_id_nist_aes_algs.c asn1_id_aes_128_cbc.c asn1_id_aes_192_cbc.c asn1_id_aes_256_cbc.c asn1_id_nist_sha_algs.c asn1_id_sha256.c asn1_id_sha224.c asn1_id_sha384.c asn1_id_sha512.c asn1_id_dhpublicnumber.c asn1_id_x9_57.c asn1_id_dsa.c asn1_id_dsa_with_sha1.c asn1_id_x520_at.c asn1_id_at_commonName.c asn1_id_at_surname.c asn1_id_at_serialNumber.c asn1_id_at_countryName.c asn1_id_at_localityName.c asn1_id_at_streetAddress.c asn1_id_at_stateOrProvinceName.c asn1_id_at_organizationName.c asn1_id_at_organizationalUnitName.c asn1_id_at_name.c asn1_id_at_givenName.c asn1_id_at_initials.c asn1_id_at_generationQualifier.c asn1_id_at_pseudonym.c asn1_id_Userid.c asn1_id_domainComponent.c asn1_id_x509_ce.c asn1_id_uspkicommon_card_id.c asn1_id_uspkicommon_piv_interim.c asn1_id_netscape.c asn1_id_netscape_cert_comment.c asn1_id_ms_cert_enroll_domaincontroller.c asn1_id_ms_client_authentication.c asn1_AlgorithmIdentifier.c asn1_AttributeType.c asn1_AttributeValue.c asn1_TeletexStringx.c asn1_DirectoryString.c asn1_Attribute.c asn1_AttributeTypeAndValue.c asn1_AuthorityInfoAccessSyntax.c asn1_AccessDescription.c asn1_RelativeDistinguishedName.c asn1_RDNSequence.c asn1_Name.c asn1_CertificateSerialNumber.c asn1_Time.c asn1_Validity.c asn1_UniqueIdentifier.c asn1_SubjectPublicKeyInfo.c asn1_Extension.c asn1_Extensions.c asn1_TBSCertificate.c asn1_Certificate.c asn1_Certificates.c asn1_ValidationParms.c asn1_DomainParameters.c asn1_DHPublicKey.c asn1_OtherName.c asn1_GeneralName.c asn1_GeneralNames.c asn1_id_x509_ce_keyUsage.c asn1_KeyUsage.c asn1_id_x509_ce_authorityKeyIdentifier.c asn1_KeyIdentifier.c asn1_AuthorityKeyIdentifier.c asn1_id_x509_ce_subjectKeyIdentifier.c asn1_SubjectKeyIdentifier.c asn1_id_x509_ce_basicConstraints.c asn1_BasicConstraints.c asn1_id_x509_ce_nameConstraints.c asn1_BaseDistance.c asn1_GeneralSubtree.c asn1_GeneralSubtrees.c asn1_NameConstraints.c asn1_id_x509_ce_privateKeyUsagePeriod.c asn1_id_x509_ce_certificatePolicies.c asn1_id_x509_ce_policyMappings.c asn1_id_x509_ce_subjectAltName.c asn1_id_x509_ce_issuerAltName.c asn1_id_x509_ce_subjectDirectoryAttributes.c asn1_id_x509_ce_policyConstraints.c asn1_id_x509_ce_extKeyUsage.c asn1_ExtKeyUsage.c asn1_id_x509_ce_cRLDistributionPoints.c asn1_id_x509_ce_deltaCRLIndicator.c asn1_id_x509_ce_issuingDistributionPoint.c asn1_id_x509_ce_holdInstructionCode.c asn1_id_x509_ce_inval idityDate.c asn1_id_x509_ce_certificateIssuer.c asn1_id_x509_ce_inhibitAnyPolicy.c asn1_DistributionPointReasonFlags.c asn1_DistributionPointName.c asn1_DistributionPoint.c asn1_CRLDistributionPoints.c asn1_DSASigValue.c asn1_DSAPublicKey.c asn1_DSAParams.c asn1_RSAPublicKey.c asn1_RSAPrivateKey.c asn1_DigestInfo.c asn1_TBSCRLCertList.c asn1_CRLCertificateList.c asn1_id_x509_ce_cRLNumber.c asn1_id_x509_ce_freshestCRL.c asn1_id_x509_ce_cRLReason.c asn1_CRLReason.c asn1_PKIXXmppAddr.c asn1_id_pkix.c asn1_id_pkix_on.c asn1_id_pkix_on_dnsSRV.c asn1_id_pkix_on_xmppAddr.c asn1_id_pkix_kp.c asn1_id_pkix_kp_serverAuth.c asn1_id_pkix_kp_clientAuth.c asn1_id_pkix_kp_emailProtection.c asn1_id_pkix_kp_timeStamping.c asn1_id_pkix_kp_OCSPSigning.c asn1_id_pkix_pe.c asn1_id_pkix_pe_authorityInfoAccess.c asn1_id_pkix_pe_proxyCertInfo.c asn1_id_pkix_ppl.c asn1_id_pkix_ppl_anyLanguage.c asn1_id_pkix_ppl_inheritAll.c asn1_id_pkix_ppl_independent.c asn1_ProxyPolicy.c asn1_ProxyCertInfo.c asn1_C MSAttributes.c asn1_CMSCBCParameter.c asn1_CMSEncryptedData.c asn1_CMSIdentifier.c asn1_CMSRC2CBCParameter.c asn1_CMSVersion.c asn1_CertificateList.c asn1_CertificateRevocationLists.c asn1_CertificateSet.c asn1_ContentEncryptionAlgorithmIdentifier.c asn1_ContentInfo.c asn1_ContentType.c asn1_DigestAlgorithmIdentifier.c asn1_DigestAlgorithmIdentifiers.c asn1_EncapsulatedContentInfo.c asn1_EncryptedContent.c asn1_EncryptedContentInfo.c asn1_EncryptedKey.c asn1_EnvelopedData.c asn1_IssuerAndSerialNumber.c asn1_KeyEncryptionAlgorithmIdentifier.c asn1_KeyTransRecipientInfo.c asn1_MessageDigest.c asn1_OriginatorInfo.c asn1_RecipientIdentifier.c asn1_RecipientInfo.c asn1_RecipientInfos.c asn1_SignatureAlgorithmIdentifier.c asn1_SignatureValue.c asn1_SignedData.c asn1_SignerIdentifier.c asn1_SignerInfo.c asn1_SignerInfos.c asn1_id_pkcs7.c asn1_id_pkcs7_data.c asn1_id_pkcs7_digestedData.c asn1_id_pkcs7_encryptedData.c asn1_id_pkcs7_envelopedData.c asn1_id_pkcs7_signedAndEnvelopedData .c asn1_id_pkcs7_signedData.c asn1_UnprotectedAttributes.c asn1_AD_AND_OR.c asn1_AD_IF_RELEVANT.c asn1_AD_KDCIssued.c asn1_AD_MANDATORY_FOR_KDC.c asn1_AD_LoginAlias.c asn1_APOptions.c asn1_AP_REP.c asn1_AP_REQ.c asn1_AS_REP.c asn1_AS_REQ.c asn1_AUTHDATA_TYPE.c asn1_Authenticator.c asn1_AuthorizationData.c asn1_AuthorizationDataElement.c asn1_CKSUMTYPE.c asn1_ChangePasswdDataMS.c asn1_Checksum.c asn1_ENCTYPE.c asn1_ETYPE_INFO.c asn1_ETYPE_INFO2.c asn1_ETYPE_INFO2_ENTRY.c asn1_ETYPE_INFO_ENTRY.c asn1_EncAPRepPart.c asn1_EncASRepPart.c asn1_EncKDCRepPart.c asn1_EncKrbCredPart.c asn1_EncKrbPrivPart.c asn1_EncTGSRepPart.c asn1_EncTicketPart.c asn1_EncryptedData.c asn1_EncryptionKey.c asn1_EtypeList.c asn1_HostAddress.c asn1_HostAddresses.c asn1_KDCOptions.c asn1_KDC_REP.c asn1_KDC_REQ.c asn1_KDC_REQ_BODY.c asn1_KRB_CRED.c asn1_KRB_ERROR.c asn1_KRB_PRIV.c asn1_KRB_SAFE.c asn1_KRB_SAFE_BODY.c asn1_KerberosString.c asn1_KerberosTime.c asn1_KrbCredInfo.c asn1_LR_TYPE.c asn1_LastReq.c asn1_MESSAGE_TYPE.c asn1_METHOD_DATA.c asn1_NAME_TYPE.c asn1_PADATA_TYPE.c asn1_PA_DATA.c asn1_PA_ENC_SAM_RESPONSE_ENC.c asn1_PA_ENC_TS_ENC.c asn1_PA_PAC_REQUEST.c asn1_PA_S4U2Self.c asn1_PA_SAM_CHALLENGE_2.c asn1_PA_SAM_CHALLENGE_2_BODY.c asn1_PA_SAM_REDIRECT.c asn1_PA_SAM_RESPONSE_2.c asn1_PA_SAM_TYPE.c asn1_PA_ClientCanonicalized.c asn1_PA_ClientCanonicalizedNames.c asn1_PA_SvrReferralData.c asn1_PROV_SRV_LOCATION.c asn1_Principal.c asn1_PrincipalName.c asn1_Realm.c asn1_SAMFlags.c asn1_TGS_REP.c asn1_TGS_REQ.c asn1_TYPED_DATA.c asn1_Ticket.c asn1_TicketFlags.c asn1_TransitedEncoding.c asn1_TypedData.c asn1_krb5int32.c asn1_krb5uint32.c asn1_KRB5SignedPathData.c asn1_KRB5SignedPathPrincipals.c asn1_KRB5SignedPath.c asn1_id_pkinit.c asn1_id_pkauthdata.c asn1_id_pkdhkeydata.c asn1_id_pkrkeydata.c asn1_id_pkekuoid.c asn1_id_pkkdcekuoid.c asn1_id_pkinit_san.c asn1_id_pkinit_ms_eku.c asn1_id_pkinit_ms_san.c asn1_MS_UPN_SAN.c asn1_DHNonce.c asn1_KDFAlgorithmId.c asn1_TrustedCA .c asn1_ExternalPrincipalIdentifier.c asn1_ExternalPrincipalIdentifiers.c asn1_PA_PK_AS_REQ.c asn1_PKAuthenticator.c asn1_AuthPack.c asn1_TD_TRUSTED_CERTIFIERS.c asn1_TD_INVALID_CERTIFICATES.c asn1_KRB5PrincipalName.c asn1_AD_INITIAL_VERIFIED_CAS.c asn1_DHRepInfo.c asn1_PA_PK_AS_REP.c asn1_KDCDHKeyInfo.c asn1_ReplyKeyPack.c asn1_TD_DH_PARAMETERS.c asn1_PKAuthenticator_Win2k.c asn1_AuthPack_Win2k.c asn1_TrustedCA_Win2k.c asn1_PA_PK_AS_REQ_Win2k.c asn1_PA_PK_AS_REP_Win2k.c asn1_KDCDHKeyInfo_Win2k.c asn1_ReplyKeyPack_Win2k.c asn1_PkinitSuppPubInfo.c asn1_PKCS8PrivateKeyAlgorithmIdentifier.c asn1_PKCS8PrivateKey.c asn1_PKCS8PrivateKeyInfo.c asn1_PKCS8Attributes.c asn1_PKCS8EncryptedPrivateKeyInfo.c asn1_PKCS8EncryptedData.c asn1_id_pkcs_9.c asn1_id_pkcs9_contentType.c asn1_id_pkcs9_emailAddress.c asn1_id_pkcs9_messageDigest.c asn1_id_pkcs9_signingTime.c asn1_id_pkcs9_countersignature.c asn1_id_pkcs_9_at_friendlyName.c asn1_id_pkcs_9_at_localKeyId.c asn1_id_pkcs_9_at_certTypes.c asn1_id_pkcs_9_at_certTypes_x509.c asn1_PKCS9_BMPString.c asn1_PKCS9_friendlyName.c asn1_id_pkcs_12.c asn1_id_pkcs_12PbeIds.c asn1_id_pbeWithSHAAnd128BitRC4.c asn1_id_pbeWithSHAAnd40BitRC4.c asn1_id_pbeWithSHAAnd3_KeyTripleDES_CBC.c asn1_id_pbeWithSHAAnd2_KeyTripleDES_CBC.c asn1_id_pbeWithSHAAnd128BitRC2_CBC.c asn1_id_pbewithSHAAnd40BitRC2_CBC.c asn1_id_pkcs12_bagtypes.c asn1_id_pkcs12_keyBag.c asn1_id_pkcs12_pkcs8ShroudedKeyBag.c asn1_id_pkcs12_certBag.c asn1_id_pkcs12_crlBag.c asn1_id_pkcs12_secretBag.c asn1_id_pkcs12_safeContentsBag.c asn1_PKCS12_MacData.c asn1_PKCS12_PFX.c asn1_PKCS12_AuthenticatedSafe.c asn1_PKCS12_CertBag.c asn1_PKCS12_Attribute.c asn1_PKCS12_Attributes.c asn1_PKCS12_SafeBag.c asn1_PKCS12_SafeContents.c asn1_PKCS12_OctetString.c asn1_PKCS12_PBEParams.c asn1_DigestError.c asn1_DigestInit.c asn1_DigestInitReply.c asn1_DigestREP.c asn1_DigestREQ.c asn1_DigestRepInner.c asn1_DigestReqInner.c asn1_DigestRequest.c asn1_DigestResponse.c asn1_DigestTypes.c asn 1_NTLMInit.c asn1_NTLMInitReply.c asn1_NTLMRequest.c asn1_NTLMResponse.c asn1_Kx509Response.c asn1_Kx509Request.c cc -O2 -pipe -I/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/src/kerberos5/lib/libasn1/../../include -std=gnu99 -fstack-protector -c asn1_err.c cc -O2 -pipe -I/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/src/kerberos5/lib/libasn1/../../include -std=gnu99 -fstack-protector -c /src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1/der_copy.c In file included from /src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1/der_locl.h:50, from /src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1/der_copy.c:34: /obj/powerpc/src/tmp/usr/include/roken.h:248: error: conflicting types for 'closefrom' /obj/powerpc/src/tmp/usr/include/unistd.h:329: error: previous declaration of 'closefrom' was here *** Error code 1 Stop in /src/kerberos5/lib/libasn1. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-15 22:45:46 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-15 22:45:46 - ERROR: failed to build world TB --- 2009-06-15 22:45:46 - 820.34 user 80.86 system 1114.55 real http://tinderbox.des.no/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Mon Jun 15 22:57:48 2009 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 7A8461065674; Mon, 15 Jun 2009 22:57:48 +0000 (UTC) (envelope-from oz@nixil.net) Received: from nixil.net (nixil.net [161.58.222.1]) by mx1.freebsd.org (Postfix) with ESMTP id 3C1DF8FC1D; Mon, 15 Jun 2009 22:57:47 +0000 (UTC) (envelope-from oz@nixil.net) Received: from demigorgon.corp.verio.net (fw.oremut02.us.wh.verio.net [198.65.168.24]) (authenticated bits=0) by nixil.net (8.13.6.20060614/8.13.6) with ESMTP id n5FMivUW070044 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 15 Jun 2009 16:45:10 -0600 (MDT) Message-ID: <4A36CEE9.9040101@nixil.net> Date: Mon, 15 Jun 2009 16:44:57 -0600 From: Phil Oleson User-Agent: Thunderbird 2.0.0.14 (X11/20080623) MIME-Version: 1.0 To: Matthew Dillon References: <4A254B45.8050800@mavhome.dp.ua> <4A294DC3.5010008@mavhome.dp.ua> <200906051728.n55HSFf0076644@apollo.backplane.com> <200906152352.48231.Daan@vehosting.nl> <200906152209.n5FM9psY007070@apollo.backplane.com> In-Reply-To: <200906152209.n5FM9psY007070@apollo.backplane.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (nixil.net [161.58.222.1]); Mon, 15 Jun 2009 16:45:11 -0600 (MDT) X-Virus-Scanned: ClamAV 0.94.2/9467/Mon Jun 15 02:11:58 2009 on nixil.net X-Virus-Status: Clean Cc: Daan Vreeken , Alexander Motin , FreeBSD-Current , freebsd-arch@freebsd.org Subject: Re: WIP: ATA to CAM integration 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, 15 Jun 2009 22:57:49 -0000 Matthew Dillon wrote: > :Hi, > : > :According to the following link : > : http://www.siliconimage.com/products/product.aspx?pid=32 > : > :the SiI3132 supports FIS based switching. We use them in a storage server > :prototype. > : > :Regards, > :-- > :Daan Vreeken > :VEHosting > > Yah, I have a bunch of those. They aren't AHCI parts though (as far > as I know) so it doesn't help with the AHCI driver. They have their > own custom driver. But thanks for mentioning it :-) > > (Someone tell me if I'm wrong there, I'm pretty sure all the Sili stuff > uses a Sili-specific device driver). meh.. found this via google: http://www.tomshardware.com/reviews/storage-accessories,1787-2.html The article claims it's AHCI compliant.. though the addonics web page doesn't specifically says so from a cursory glance here: http://www.addonics.com/products/host_controller/extpm.asp and the other form factors. http://www.addonics.com/products/pm/ -Phil. From owner-freebsd-current@FreeBSD.ORG Mon Jun 15 23:02:41 2009 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 CAF40106566C; Mon, 15 Jun 2009 23:02:41 +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 84A378FC16; Mon, 15 Jun 2009 23:02:41 +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.3/8.14.3) with ESMTP id n5FN2cfd067601; Mon, 15 Jun 2009 19:02:38 -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 n5FN2cf3082421; Mon, 15 Jun 2009 19:02:38 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 80B107302F; Mon, 15 Jun 2009 19:02:38 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090615230238.80B107302F@freebsd-current.sentex.ca> Date: Mon, 15 Jun 2009 19:02:38 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp2.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on sparc64/sparc64 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: Mon, 15 Jun 2009 23:02:42 -0000 TB --- 2009-06-15 22:45:46 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-06-15 22:45:46 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2009-06-15 22:45:46 - cleaning the object tree TB --- 2009-06-15 22:46:17 - cvsupping the source tree TB --- 2009-06-15 22:46:17 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2009-06-15 22:46:28 - building world TB --- 2009-06-15 22:46:28 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-15 22:46:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-15 22:46:28 - TARGET=sparc64 TB --- 2009-06-15 22:46:28 - TARGET_ARCH=sparc64 TB --- 2009-06-15 22:46:28 - TZ=UTC TB --- 2009-06-15 22:46:28 - __MAKE_CONF=/dev/null TB --- 2009-06-15 22:46:28 - cd /src TB --- 2009-06-15 22:46:28 - /usr/bin/make -B buildworld >>> World build started on Mon Jun 15 22:46:29 UTC 2009 >>> 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 [...] rm -f .depend mkdep -f .depend -a -I/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/src/kerberos5/lib/libasn1/../../include asn1_err.c /src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1/der_copy.c /src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1/der_cmp.c /src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1/der_free.c /src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1/der_format.c /src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1/der_get.c /src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1/der_length.c /src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1/der_put.c /src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1/extra.c /src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1/timegm.c asn1_Version.c asn1_id_pkcs_1.c asn1_id_pkcs1_rsaEncryption.c asn1_id_pkcs1_md2WithRSAEncryption.c asn1_id_pkcs1_md5WithRSAEncryption .c asn1_id_pkcs1_sha1WithRSAEncryption.c asn1_id_pkcs1_sha256WithRSAEncryption.c asn1_id_pkcs1_sha384WithRSAEncryption.c asn1_id_pkcs1_sha512WithRSAEncryption.c asn1_id_heim_rsa_pkcs1_x509.c asn1_id_pkcs_2.c asn1_id_pkcs2_md2.c asn1_id_pkcs2_md4.c asn1_id_pkcs2_md5.c asn1_id_rsa_digestAlgorithm.c asn1_id_rsa_digest_md2.c asn1_id_rsa_digest_md4.c asn1_id_rsa_digest_md5.c asn1_id_pkcs_3.c asn1_id_pkcs3_rc2_cbc.c asn1_id_pkcs3_rc4.c asn1_id_pkcs3_des_ede3_cbc.c asn1_id_rsadsi_encalg.c asn1_id_rsadsi_rc2_cbc.c asn1_id_rsadsi_des_ede3_cbc.c asn1_id_secsig_sha_1.c asn1_id_nistAlgorithm.c asn1_id_nist_aes_algs.c asn1_id_aes_128_cbc.c asn1_id_aes_192_cbc.c asn1_id_aes_256_cbc.c asn1_id_nist_sha_algs.c asn1_id_sha256.c asn1_id_sha224.c asn1_id_sha384.c asn1_id_sha512.c asn1_id_dhpublicnumber.c asn1_id_x9_57.c asn1_id_dsa.c asn1_id_dsa_with_sha1.c asn1_id_x520_at.c asn1_id_at_commonName.c asn1_id_at_surname.c asn1_id_at_serialNumber.c asn1_id_at_countryName.c asn1_id_at_localityName.c asn1_id_at_streetAddress.c asn1_id_at_stateOrProvinceName.c asn1_id_at_organizationName.c asn1_id_at_organizationalUnitName.c asn1_id_at_name.c asn1_id_at_givenName.c asn1_id_at_initials.c asn1_id_at_generationQualifier.c asn1_id_at_pseudonym.c asn1_id_Userid.c asn1_id_domainComponent.c asn1_id_x509_ce.c asn1_id_uspkicommon_card_id.c asn1_id_uspkicommon_piv_interim.c asn1_id_netscape.c asn1_id_netscape_cert_comment.c asn1_id_ms_cert_enroll_domaincontroller.c asn1_id_ms_client_authentication.c asn1_AlgorithmIdentifier.c asn1_AttributeType.c asn1_AttributeValue.c asn1_TeletexStringx.c asn1_DirectoryString.c asn1_Attribute.c asn1_AttributeTypeAndValue.c asn1_AuthorityInfoAccessSyntax.c asn1_AccessDescription.c asn1_RelativeDistinguishedName.c asn1_RDNSequence.c asn1_Name.c asn1_CertificateSerialNumber.c asn1_Time.c asn1_Validity.c asn1_UniqueIdentifier.c asn1_SubjectPublicKeyInfo.c asn1_Extension.c asn1_Extensions.c asn1_TBSCertificate.c asn1_Certificate.c asn1_Certificates.c asn1_ValidationParms.c asn1_DomainParameters.c asn1_DHPublicKey.c asn1_OtherName.c asn1_GeneralName.c asn1_GeneralNames.c asn1_id_x509_ce_keyUsage.c asn1_KeyUsage.c asn1_id_x509_ce_authorityKeyIdentifier.c asn1_KeyIdentifier.c asn1_AuthorityKeyIdentifier.c asn1_id_x509_ce_subjectKeyIdentifier.c asn1_SubjectKeyIdentifier.c asn1_id_x509_ce_basicConstraints.c asn1_BasicConstraints.c asn1_id_x509_ce_nameConstraints.c asn1_BaseDistance.c asn1_GeneralSubtree.c asn1_GeneralSubtrees.c asn1_NameConstraints.c asn1_id_x509_ce_privateKeyUsagePeriod.c asn1_id_x509_ce_certificatePolicies.c asn1_id_x509_ce_policyMappings.c asn1_id_x509_ce_subjectAltName.c asn1_id_x509_ce_issuerAltName.c asn1_id_x509_ce_subjectDirectoryAttributes.c asn1_id_x509_ce_policyConstraints.c asn1_id_x509_ce_extKeyUsage.c asn1_ExtKeyUsage.c asn1_id_x509_ce_cRLDistributionPoints.c asn1_id_x509_ce_deltaCRLIndicator.c asn1_id_x509_ce_issuingDistributionPoint.c asn1_id_x509_ce_holdInstructionCode.c asn1_id_x509_ce_inval idityDate.c asn1_id_x509_ce_certificateIssuer.c asn1_id_x509_ce_inhibitAnyPolicy.c asn1_DistributionPointReasonFlags.c asn1_DistributionPointName.c asn1_DistributionPoint.c asn1_CRLDistributionPoints.c asn1_DSASigValue.c asn1_DSAPublicKey.c asn1_DSAParams.c asn1_RSAPublicKey.c asn1_RSAPrivateKey.c asn1_DigestInfo.c asn1_TBSCRLCertList.c asn1_CRLCertificateList.c asn1_id_x509_ce_cRLNumber.c asn1_id_x509_ce_freshestCRL.c asn1_id_x509_ce_cRLReason.c asn1_CRLReason.c asn1_PKIXXmppAddr.c asn1_id_pkix.c asn1_id_pkix_on.c asn1_id_pkix_on_dnsSRV.c asn1_id_pkix_on_xmppAddr.c asn1_id_pkix_kp.c asn1_id_pkix_kp_serverAuth.c asn1_id_pkix_kp_clientAuth.c asn1_id_pkix_kp_emailProtection.c asn1_id_pkix_kp_timeStamping.c asn1_id_pkix_kp_OCSPSigning.c asn1_id_pkix_pe.c asn1_id_pkix_pe_authorityInfoAccess.c asn1_id_pkix_pe_proxyCertInfo.c asn1_id_pkix_ppl.c asn1_id_pkix_ppl_anyLanguage.c asn1_id_pkix_ppl_inheritAll.c asn1_id_pkix_ppl_independent.c asn1_ProxyPolicy.c asn1_ProxyCertInfo.c asn1_C MSAttributes.c asn1_CMSCBCParameter.c asn1_CMSEncryptedData.c asn1_CMSIdentifier.c asn1_CMSRC2CBCParameter.c asn1_CMSVersion.c asn1_CertificateList.c asn1_CertificateRevocationLists.c asn1_CertificateSet.c asn1_ContentEncryptionAlgorithmIdentifier.c asn1_ContentInfo.c asn1_ContentType.c asn1_DigestAlgorithmIdentifier.c asn1_DigestAlgorithmIdentifiers.c asn1_EncapsulatedContentInfo.c asn1_EncryptedContent.c asn1_EncryptedContentInfo.c asn1_EncryptedKey.c asn1_EnvelopedData.c asn1_IssuerAndSerialNumber.c asn1_KeyEncryptionAlgorithmIdentifier.c asn1_KeyTransRecipientInfo.c asn1_MessageDigest.c asn1_OriginatorInfo.c asn1_RecipientIdentifier.c asn1_RecipientInfo.c asn1_RecipientInfos.c asn1_SignatureAlgorithmIdentifier.c asn1_SignatureValue.c asn1_SignedData.c asn1_SignerIdentifier.c asn1_SignerInfo.c asn1_SignerInfos.c asn1_id_pkcs7.c asn1_id_pkcs7_data.c asn1_id_pkcs7_digestedData.c asn1_id_pkcs7_encryptedData.c asn1_id_pkcs7_envelopedData.c asn1_id_pkcs7_signedAndEnvelopedData .c asn1_id_pkcs7_signedData.c asn1_UnprotectedAttributes.c asn1_AD_AND_OR.c asn1_AD_IF_RELEVANT.c asn1_AD_KDCIssued.c asn1_AD_MANDATORY_FOR_KDC.c asn1_AD_LoginAlias.c asn1_APOptions.c asn1_AP_REP.c asn1_AP_REQ.c asn1_AS_REP.c asn1_AS_REQ.c asn1_AUTHDATA_TYPE.c asn1_Authenticator.c asn1_AuthorizationData.c asn1_AuthorizationDataElement.c asn1_CKSUMTYPE.c asn1_ChangePasswdDataMS.c asn1_Checksum.c asn1_ENCTYPE.c asn1_ETYPE_INFO.c asn1_ETYPE_INFO2.c asn1_ETYPE_INFO2_ENTRY.c asn1_ETYPE_INFO_ENTRY.c asn1_EncAPRepPart.c asn1_EncASRepPart.c asn1_EncKDCRepPart.c asn1_EncKrbCredPart.c asn1_EncKrbPrivPart.c asn1_EncTGSRepPart.c asn1_EncTicketPart.c asn1_EncryptedData.c asn1_EncryptionKey.c asn1_EtypeList.c asn1_HostAddress.c asn1_HostAddresses.c asn1_KDCOptions.c asn1_KDC_REP.c asn1_KDC_REQ.c asn1_KDC_REQ_BODY.c asn1_KRB_CRED.c asn1_KRB_ERROR.c asn1_KRB_PRIV.c asn1_KRB_SAFE.c asn1_KRB_SAFE_BODY.c asn1_KerberosString.c asn1_KerberosTime.c asn1_KrbCredInfo.c asn1_LR_TYPE.c asn1_LastReq.c asn1_MESSAGE_TYPE.c asn1_METHOD_DATA.c asn1_NAME_TYPE.c asn1_PADATA_TYPE.c asn1_PA_DATA.c asn1_PA_ENC_SAM_RESPONSE_ENC.c asn1_PA_ENC_TS_ENC.c asn1_PA_PAC_REQUEST.c asn1_PA_S4U2Self.c asn1_PA_SAM_CHALLENGE_2.c asn1_PA_SAM_CHALLENGE_2_BODY.c asn1_PA_SAM_REDIRECT.c asn1_PA_SAM_RESPONSE_2.c asn1_PA_SAM_TYPE.c asn1_PA_ClientCanonicalized.c asn1_PA_ClientCanonicalizedNames.c asn1_PA_SvrReferralData.c asn1_PROV_SRV_LOCATION.c asn1_Principal.c asn1_PrincipalName.c asn1_Realm.c asn1_SAMFlags.c asn1_TGS_REP.c asn1_TGS_REQ.c asn1_TYPED_DATA.c asn1_Ticket.c asn1_TicketFlags.c asn1_TransitedEncoding.c asn1_TypedData.c asn1_krb5int32.c asn1_krb5uint32.c asn1_KRB5SignedPathData.c asn1_KRB5SignedPathPrincipals.c asn1_KRB5SignedPath.c asn1_id_pkinit.c asn1_id_pkauthdata.c asn1_id_pkdhkeydata.c asn1_id_pkrkeydata.c asn1_id_pkekuoid.c asn1_id_pkkdcekuoid.c asn1_id_pkinit_san.c asn1_id_pkinit_ms_eku.c asn1_id_pkinit_ms_san.c asn1_MS_UPN_SAN.c asn1_DHNonce.c asn1_KDFAlgorithmId.c asn1_TrustedCA .c asn1_ExternalPrincipalIdentifier.c asn1_ExternalPrincipalIdentifiers.c asn1_PA_PK_AS_REQ.c asn1_PKAuthenticator.c asn1_AuthPack.c asn1_TD_TRUSTED_CERTIFIERS.c asn1_TD_INVALID_CERTIFICATES.c asn1_KRB5PrincipalName.c asn1_AD_INITIAL_VERIFIED_CAS.c asn1_DHRepInfo.c asn1_PA_PK_AS_REP.c asn1_KDCDHKeyInfo.c asn1_ReplyKeyPack.c asn1_TD_DH_PARAMETERS.c asn1_PKAuthenticator_Win2k.c asn1_AuthPack_Win2k.c asn1_TrustedCA_Win2k.c asn1_PA_PK_AS_REQ_Win2k.c asn1_PA_PK_AS_REP_Win2k.c asn1_KDCDHKeyInfo_Win2k.c asn1_ReplyKeyPack_Win2k.c asn1_PkinitSuppPubInfo.c asn1_PKCS8PrivateKeyAlgorithmIdentifier.c asn1_PKCS8PrivateKey.c asn1_PKCS8PrivateKeyInfo.c asn1_PKCS8Attributes.c asn1_PKCS8EncryptedPrivateKeyInfo.c asn1_PKCS8EncryptedData.c asn1_id_pkcs_9.c asn1_id_pkcs9_contentType.c asn1_id_pkcs9_emailAddress.c asn1_id_pkcs9_messageDigest.c asn1_id_pkcs9_signingTime.c asn1_id_pkcs9_countersignature.c asn1_id_pkcs_9_at_friendlyName.c asn1_id_pkcs_9_at_localKeyId.c asn1_id_pkcs_9_at_certTypes.c asn1_id_pkcs_9_at_certTypes_x509.c asn1_PKCS9_BMPString.c asn1_PKCS9_friendlyName.c asn1_id_pkcs_12.c asn1_id_pkcs_12PbeIds.c asn1_id_pbeWithSHAAnd128BitRC4.c asn1_id_pbeWithSHAAnd40BitRC4.c asn1_id_pbeWithSHAAnd3_KeyTripleDES_CBC.c asn1_id_pbeWithSHAAnd2_KeyTripleDES_CBC.c asn1_id_pbeWithSHAAnd128BitRC2_CBC.c asn1_id_pbewithSHAAnd40BitRC2_CBC.c asn1_id_pkcs12_bagtypes.c asn1_id_pkcs12_keyBag.c asn1_id_pkcs12_pkcs8ShroudedKeyBag.c asn1_id_pkcs12_certBag.c asn1_id_pkcs12_crlBag.c asn1_id_pkcs12_secretBag.c asn1_id_pkcs12_safeContentsBag.c asn1_PKCS12_MacData.c asn1_PKCS12_PFX.c asn1_PKCS12_AuthenticatedSafe.c asn1_PKCS12_CertBag.c asn1_PKCS12_Attribute.c asn1_PKCS12_Attributes.c asn1_PKCS12_SafeBag.c asn1_PKCS12_SafeContents.c asn1_PKCS12_OctetString.c asn1_PKCS12_PBEParams.c asn1_DigestError.c asn1_DigestInit.c asn1_DigestInitReply.c asn1_DigestREP.c asn1_DigestREQ.c asn1_DigestRepInner.c asn1_DigestReqInner.c asn1_DigestRequest.c asn1_DigestResponse.c asn1_DigestTypes.c asn 1_NTLMInit.c asn1_NTLMInitReply.c asn1_NTLMRequest.c asn1_NTLMResponse.c asn1_Kx509Response.c asn1_Kx509Request.c cc -O2 -pipe -I/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/src/kerberos5/lib/libasn1/../../include -std=gnu99 -fstack-protector -c asn1_err.c cc -O2 -pipe -I/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/src/kerberos5/lib/libasn1/../../include -std=gnu99 -fstack-protector -c /src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1/der_copy.c In file included from /src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1/der_locl.h:50, from /src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1/der_copy.c:34: /obj/sparc64/src/tmp/usr/include/roken.h:248: error: conflicting types for 'closefrom' /obj/sparc64/src/tmp/usr/include/unistd.h:329: error: previous declaration of 'closefrom' was here *** Error code 1 Stop in /src/kerberos5/lib/libasn1. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-15 23:02:38 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-15 23:02:38 - ERROR: failed to build world TB --- 2009-06-15 23:02:38 - 725.38 user 77.88 system 1011.53 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Mon Jun 15 23:10:40 2009 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 3B464106566B; Mon, 15 Jun 2009 23:10:40 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id D69848FC17; Mon, 15 Jun 2009 23:10:39 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id n5FN7V5c077571; Mon, 15 Jun 2009 17:07:31 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 15 Jun 2009 17:07:54 -0600 (MDT) Message-Id: <20090615.170754.1399854812.imp@bsdimp.com> To: mav@freebsd.org From: "M. Warner Losh" In-Reply-To: <4A2AF876.1030103@FreeBSD.org> References: <6657.1244328220@critter.freebsd.dk> <4A2AF876.1030103@FreeBSD.org> 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 Cc: phk@phk.freebsd.dk, freebsd-current@freebsd.org, freebsd-arch@freebsd.org Subject: Re: WIP: ATA to CAM integration 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, 15 Jun 2009 23:10:40 -0000 In message: <4A2AF876.1030103@FreeBSD.org> Alexander Motin writes: : Poul-Henning Kamp wrote: : > In message <4A294DC3.5010008@mavhome.dp.ua>, Alexander Motin writes: : >> I think ATAPI disk device is theoretically possible, but I believe it : >> does not exist in practice, as industry do not need it. : > : > Maxtor ZIP ? : : May be, never had an ATA version. But it is more FDD, then HDD. Also it : existed in Parallel Port and SCSI versions, so it could be done in ATAPI : way just for unification. There was a ata/atapi version too. It attaches to afd. Warner From owner-freebsd-current@FreeBSD.ORG Mon Jun 15 23:19:12 2009 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 CBB3B1065672; Mon, 15 Jun 2009 23:19:12 +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 A10B88FC13; Mon, 15 Jun 2009 23:19:12 +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.3/8.14.3) with ESMTP id n5FNJAsb068627; Mon, 15 Jun 2009 19:19:10 -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 n5FNJAoD020770; Mon, 15 Jun 2009 19:19:10 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 0BD577302F; Mon, 15 Jun 2009 19:19:10 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090615231910.0BD577302F@freebsd-current.sentex.ca> Date: Mon, 15 Jun 2009 19:19:10 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp2.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on sparc64/sun4v 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: Mon, 15 Jun 2009 23:19:13 -0000 TB --- 2009-06-15 23:02:38 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-06-15 23:02:38 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2009-06-15 23:02:38 - cleaning the object tree TB --- 2009-06-15 23:03:03 - cvsupping the source tree TB --- 2009-06-15 23:03:03 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2009-06-15 23:03:12 - building world TB --- 2009-06-15 23:03:12 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-15 23:03:12 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-15 23:03:12 - TARGET=sun4v TB --- 2009-06-15 23:03:12 - TARGET_ARCH=sparc64 TB --- 2009-06-15 23:03:12 - TZ=UTC TB --- 2009-06-15 23:03:12 - __MAKE_CONF=/dev/null TB --- 2009-06-15 23:03:12 - cd /src TB --- 2009-06-15 23:03:12 - /usr/bin/make -B buildworld >>> World build started on Mon Jun 15 23:03:13 UTC 2009 >>> 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 [...] rm -f .depend mkdep -f .depend -a -I/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/src/kerberos5/lib/libasn1/../../include asn1_err.c /src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1/der_copy.c /src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1/der_cmp.c /src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1/der_free.c /src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1/der_format.c /src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1/der_get.c /src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1/der_length.c /src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1/der_put.c /src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1/extra.c /src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1/timegm.c asn1_Version.c asn1_id_pkcs_1.c asn1_id_pkcs1_rsaEncryption.c asn1_id_pkcs1_md2WithRSAEncryption.c asn1_id_pkcs1_md5WithRSAEncryption .c asn1_id_pkcs1_sha1WithRSAEncryption.c asn1_id_pkcs1_sha256WithRSAEncryption.c asn1_id_pkcs1_sha384WithRSAEncryption.c asn1_id_pkcs1_sha512WithRSAEncryption.c asn1_id_heim_rsa_pkcs1_x509.c asn1_id_pkcs_2.c asn1_id_pkcs2_md2.c asn1_id_pkcs2_md4.c asn1_id_pkcs2_md5.c asn1_id_rsa_digestAlgorithm.c asn1_id_rsa_digest_md2.c asn1_id_rsa_digest_md4.c asn1_id_rsa_digest_md5.c asn1_id_pkcs_3.c asn1_id_pkcs3_rc2_cbc.c asn1_id_pkcs3_rc4.c asn1_id_pkcs3_des_ede3_cbc.c asn1_id_rsadsi_encalg.c asn1_id_rsadsi_rc2_cbc.c asn1_id_rsadsi_des_ede3_cbc.c asn1_id_secsig_sha_1.c asn1_id_nistAlgorithm.c asn1_id_nist_aes_algs.c asn1_id_aes_128_cbc.c asn1_id_aes_192_cbc.c asn1_id_aes_256_cbc.c asn1_id_nist_sha_algs.c asn1_id_sha256.c asn1_id_sha224.c asn1_id_sha384.c asn1_id_sha512.c asn1_id_dhpublicnumber.c asn1_id_x9_57.c asn1_id_dsa.c asn1_id_dsa_with_sha1.c asn1_id_x520_at.c asn1_id_at_commonName.c asn1_id_at_surname.c asn1_id_at_serialNumber.c asn1_id_at_countryName.c asn1_id_at_localityName.c asn1_id_at_streetAddress.c asn1_id_at_stateOrProvinceName.c asn1_id_at_organizationName.c asn1_id_at_organizationalUnitName.c asn1_id_at_name.c asn1_id_at_givenName.c asn1_id_at_initials.c asn1_id_at_generationQualifier.c asn1_id_at_pseudonym.c asn1_id_Userid.c asn1_id_domainComponent.c asn1_id_x509_ce.c asn1_id_uspkicommon_card_id.c asn1_id_uspkicommon_piv_interim.c asn1_id_netscape.c asn1_id_netscape_cert_comment.c asn1_id_ms_cert_enroll_domaincontroller.c asn1_id_ms_client_authentication.c asn1_AlgorithmIdentifier.c asn1_AttributeType.c asn1_AttributeValue.c asn1_TeletexStringx.c asn1_DirectoryString.c asn1_Attribute.c asn1_AttributeTypeAndValue.c asn1_AuthorityInfoAccessSyntax.c asn1_AccessDescription.c asn1_RelativeDistinguishedName.c asn1_RDNSequence.c asn1_Name.c asn1_CertificateSerialNumber.c asn1_Time.c asn1_Validity.c asn1_UniqueIdentifier.c asn1_SubjectPublicKeyInfo.c asn1_Extension.c asn1_Extensions.c asn1_TBSCertificate.c asn1_Certificate.c asn1_Certificates.c asn1_ValidationParms.c asn1_DomainParameters.c asn1_DHPublicKey.c asn1_OtherName.c asn1_GeneralName.c asn1_GeneralNames.c asn1_id_x509_ce_keyUsage.c asn1_KeyUsage.c asn1_id_x509_ce_authorityKeyIdentifier.c asn1_KeyIdentifier.c asn1_AuthorityKeyIdentifier.c asn1_id_x509_ce_subjectKeyIdentifier.c asn1_SubjectKeyIdentifier.c asn1_id_x509_ce_basicConstraints.c asn1_BasicConstraints.c asn1_id_x509_ce_nameConstraints.c asn1_BaseDistance.c asn1_GeneralSubtree.c asn1_GeneralSubtrees.c asn1_NameConstraints.c asn1_id_x509_ce_privateKeyUsagePeriod.c asn1_id_x509_ce_certificatePolicies.c asn1_id_x509_ce_policyMappings.c asn1_id_x509_ce_subjectAltName.c asn1_id_x509_ce_issuerAltName.c asn1_id_x509_ce_subjectDirectoryAttributes.c asn1_id_x509_ce_policyConstraints.c asn1_id_x509_ce_extKeyUsage.c asn1_ExtKeyUsage.c asn1_id_x509_ce_cRLDistributionPoints.c asn1_id_x509_ce_deltaCRLIndicator.c asn1_id_x509_ce_issuingDistributionPoint.c asn1_id_x509_ce_holdInstructionCode.c asn1_id_x509_ce_inval idityDate.c asn1_id_x509_ce_certificateIssuer.c asn1_id_x509_ce_inhibitAnyPolicy.c asn1_DistributionPointReasonFlags.c asn1_DistributionPointName.c asn1_DistributionPoint.c asn1_CRLDistributionPoints.c asn1_DSASigValue.c asn1_DSAPublicKey.c asn1_DSAParams.c asn1_RSAPublicKey.c asn1_RSAPrivateKey.c asn1_DigestInfo.c asn1_TBSCRLCertList.c asn1_CRLCertificateList.c asn1_id_x509_ce_cRLNumber.c asn1_id_x509_ce_freshestCRL.c asn1_id_x509_ce_cRLReason.c asn1_CRLReason.c asn1_PKIXXmppAddr.c asn1_id_pkix.c asn1_id_pkix_on.c asn1_id_pkix_on_dnsSRV.c asn1_id_pkix_on_xmppAddr.c asn1_id_pkix_kp.c asn1_id_pkix_kp_serverAuth.c asn1_id_pkix_kp_clientAuth.c asn1_id_pkix_kp_emailProtection.c asn1_id_pkix_kp_timeStamping.c asn1_id_pkix_kp_OCSPSigning.c asn1_id_pkix_pe.c asn1_id_pkix_pe_authorityInfoAccess.c asn1_id_pkix_pe_proxyCertInfo.c asn1_id_pkix_ppl.c asn1_id_pkix_ppl_anyLanguage.c asn1_id_pkix_ppl_inheritAll.c asn1_id_pkix_ppl_independent.c asn1_ProxyPolicy.c asn1_ProxyCertInfo.c asn1_C MSAttributes.c asn1_CMSCBCParameter.c asn1_CMSEncryptedData.c asn1_CMSIdentifier.c asn1_CMSRC2CBCParameter.c asn1_CMSVersion.c asn1_CertificateList.c asn1_CertificateRevocationLists.c asn1_CertificateSet.c asn1_ContentEncryptionAlgorithmIdentifier.c asn1_ContentInfo.c asn1_ContentType.c asn1_DigestAlgorithmIdentifier.c asn1_DigestAlgorithmIdentifiers.c asn1_EncapsulatedContentInfo.c asn1_EncryptedContent.c asn1_EncryptedContentInfo.c asn1_EncryptedKey.c asn1_EnvelopedData.c asn1_IssuerAndSerialNumber.c asn1_KeyEncryptionAlgorithmIdentifier.c asn1_KeyTransRecipientInfo.c asn1_MessageDigest.c asn1_OriginatorInfo.c asn1_RecipientIdentifier.c asn1_RecipientInfo.c asn1_RecipientInfos.c asn1_SignatureAlgorithmIdentifier.c asn1_SignatureValue.c asn1_SignedData.c asn1_SignerIdentifier.c asn1_SignerInfo.c asn1_SignerInfos.c asn1_id_pkcs7.c asn1_id_pkcs7_data.c asn1_id_pkcs7_digestedData.c asn1_id_pkcs7_encryptedData.c asn1_id_pkcs7_envelopedData.c asn1_id_pkcs7_signedAndEnvelopedData .c asn1_id_pkcs7_signedData.c asn1_UnprotectedAttributes.c asn1_AD_AND_OR.c asn1_AD_IF_RELEVANT.c asn1_AD_KDCIssued.c asn1_AD_MANDATORY_FOR_KDC.c asn1_AD_LoginAlias.c asn1_APOptions.c asn1_AP_REP.c asn1_AP_REQ.c asn1_AS_REP.c asn1_AS_REQ.c asn1_AUTHDATA_TYPE.c asn1_Authenticator.c asn1_AuthorizationData.c asn1_AuthorizationDataElement.c asn1_CKSUMTYPE.c asn1_ChangePasswdDataMS.c asn1_Checksum.c asn1_ENCTYPE.c asn1_ETYPE_INFO.c asn1_ETYPE_INFO2.c asn1_ETYPE_INFO2_ENTRY.c asn1_ETYPE_INFO_ENTRY.c asn1_EncAPRepPart.c asn1_EncASRepPart.c asn1_EncKDCRepPart.c asn1_EncKrbCredPart.c asn1_EncKrbPrivPart.c asn1_EncTGSRepPart.c asn1_EncTicketPart.c asn1_EncryptedData.c asn1_EncryptionKey.c asn1_EtypeList.c asn1_HostAddress.c asn1_HostAddresses.c asn1_KDCOptions.c asn1_KDC_REP.c asn1_KDC_REQ.c asn1_KDC_REQ_BODY.c asn1_KRB_CRED.c asn1_KRB_ERROR.c asn1_KRB_PRIV.c asn1_KRB_SAFE.c asn1_KRB_SAFE_BODY.c asn1_KerberosString.c asn1_KerberosTime.c asn1_KrbCredInfo.c asn1_LR_TYPE.c asn1_LastReq.c asn1_MESSAGE_TYPE.c asn1_METHOD_DATA.c asn1_NAME_TYPE.c asn1_PADATA_TYPE.c asn1_PA_DATA.c asn1_PA_ENC_SAM_RESPONSE_ENC.c asn1_PA_ENC_TS_ENC.c asn1_PA_PAC_REQUEST.c asn1_PA_S4U2Self.c asn1_PA_SAM_CHALLENGE_2.c asn1_PA_SAM_CHALLENGE_2_BODY.c asn1_PA_SAM_REDIRECT.c asn1_PA_SAM_RESPONSE_2.c asn1_PA_SAM_TYPE.c asn1_PA_ClientCanonicalized.c asn1_PA_ClientCanonicalizedNames.c asn1_PA_SvrReferralData.c asn1_PROV_SRV_LOCATION.c asn1_Principal.c asn1_PrincipalName.c asn1_Realm.c asn1_SAMFlags.c asn1_TGS_REP.c asn1_TGS_REQ.c asn1_TYPED_DATA.c asn1_Ticket.c asn1_TicketFlags.c asn1_TransitedEncoding.c asn1_TypedData.c asn1_krb5int32.c asn1_krb5uint32.c asn1_KRB5SignedPathData.c asn1_KRB5SignedPathPrincipals.c asn1_KRB5SignedPath.c asn1_id_pkinit.c asn1_id_pkauthdata.c asn1_id_pkdhkeydata.c asn1_id_pkrkeydata.c asn1_id_pkekuoid.c asn1_id_pkkdcekuoid.c asn1_id_pkinit_san.c asn1_id_pkinit_ms_eku.c asn1_id_pkinit_ms_san.c asn1_MS_UPN_SAN.c asn1_DHNonce.c asn1_KDFAlgorithmId.c asn1_TrustedCA .c asn1_ExternalPrincipalIdentifier.c asn1_ExternalPrincipalIdentifiers.c asn1_PA_PK_AS_REQ.c asn1_PKAuthenticator.c asn1_AuthPack.c asn1_TD_TRUSTED_CERTIFIERS.c asn1_TD_INVALID_CERTIFICATES.c asn1_KRB5PrincipalName.c asn1_AD_INITIAL_VERIFIED_CAS.c asn1_DHRepInfo.c asn1_PA_PK_AS_REP.c asn1_KDCDHKeyInfo.c asn1_ReplyKeyPack.c asn1_TD_DH_PARAMETERS.c asn1_PKAuthenticator_Win2k.c asn1_AuthPack_Win2k.c asn1_TrustedCA_Win2k.c asn1_PA_PK_AS_REQ_Win2k.c asn1_PA_PK_AS_REP_Win2k.c asn1_KDCDHKeyInfo_Win2k.c asn1_ReplyKeyPack_Win2k.c asn1_PkinitSuppPubInfo.c asn1_PKCS8PrivateKeyAlgorithmIdentifier.c asn1_PKCS8PrivateKey.c asn1_PKCS8PrivateKeyInfo.c asn1_PKCS8Attributes.c asn1_PKCS8EncryptedPrivateKeyInfo.c asn1_PKCS8EncryptedData.c asn1_id_pkcs_9.c asn1_id_pkcs9_contentType.c asn1_id_pkcs9_emailAddress.c asn1_id_pkcs9_messageDigest.c asn1_id_pkcs9_signingTime.c asn1_id_pkcs9_countersignature.c asn1_id_pkcs_9_at_friendlyName.c asn1_id_pkcs_9_at_localKeyId.c asn1_id_pkcs_9_at_certTypes.c asn1_id_pkcs_9_at_certTypes_x509.c asn1_PKCS9_BMPString.c asn1_PKCS9_friendlyName.c asn1_id_pkcs_12.c asn1_id_pkcs_12PbeIds.c asn1_id_pbeWithSHAAnd128BitRC4.c asn1_id_pbeWithSHAAnd40BitRC4.c asn1_id_pbeWithSHAAnd3_KeyTripleDES_CBC.c asn1_id_pbeWithSHAAnd2_KeyTripleDES_CBC.c asn1_id_pbeWithSHAAnd128BitRC2_CBC.c asn1_id_pbewithSHAAnd40BitRC2_CBC.c asn1_id_pkcs12_bagtypes.c asn1_id_pkcs12_keyBag.c asn1_id_pkcs12_pkcs8ShroudedKeyBag.c asn1_id_pkcs12_certBag.c asn1_id_pkcs12_crlBag.c asn1_id_pkcs12_secretBag.c asn1_id_pkcs12_safeContentsBag.c asn1_PKCS12_MacData.c asn1_PKCS12_PFX.c asn1_PKCS12_AuthenticatedSafe.c asn1_PKCS12_CertBag.c asn1_PKCS12_Attribute.c asn1_PKCS12_Attributes.c asn1_PKCS12_SafeBag.c asn1_PKCS12_SafeContents.c asn1_PKCS12_OctetString.c asn1_PKCS12_PBEParams.c asn1_DigestError.c asn1_DigestInit.c asn1_DigestInitReply.c asn1_DigestREP.c asn1_DigestREQ.c asn1_DigestRepInner.c asn1_DigestReqInner.c asn1_DigestRequest.c asn1_DigestResponse.c asn1_DigestTypes.c asn 1_NTLMInit.c asn1_NTLMInitReply.c asn1_NTLMRequest.c asn1_NTLMResponse.c asn1_Kx509Response.c asn1_Kx509Request.c cc -O2 -pipe -I/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/src/kerberos5/lib/libasn1/../../include -std=gnu99 -fstack-protector -c asn1_err.c cc -O2 -pipe -I/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/src/kerberos5/lib/libasn1/../../include -std=gnu99 -fstack-protector -c /src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1/der_copy.c In file included from /src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1/der_locl.h:50, from /src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1/der_copy.c:34: /obj/sun4v/src/tmp/usr/include/roken.h:248: error: conflicting types for 'closefrom' /obj/sun4v/src/tmp/usr/include/unistd.h:329: error: previous declaration of 'closefrom' was here *** Error code 1 Stop in /src/kerberos5/lib/libasn1. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-15 23:19:09 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-15 23:19:09 - ERROR: failed to build world TB --- 2009-06-15 23:19:09 - 725.54 user 79.32 system 991.35 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Mon Jun 15 23:27:51 2009 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 8F5671065670 for ; Mon, 15 Jun 2009 23:27:51 +0000 (UTC) (envelope-from james-freebsd-current@jrv.org) Received: from mail.jrv.org (rrcs-24-73-246-106.sw.biz.rr.com [24.73.246.106]) by mx1.freebsd.org (Postfix) with ESMTP id 50F588FC15 for ; Mon, 15 Jun 2009 23:27:51 +0000 (UTC) (envelope-from james-freebsd-current@jrv.org) Received: from kremvax.housenet.jrv (kremvax.housenet.jrv [192.168.3.124]) by mail.jrv.org (8.14.3/8.14.3) with ESMTP id n5FNRg3E004454; Mon, 15 Jun 2009 18:27:42 -0500 (CDT) (envelope-from james-freebsd-current@jrv.org) Authentication-Results: mail.jrv.org; domainkeys=pass (testing) header.from=james-freebsd-current@jrv.org DomainKey-Signature: a=rsa-sha1; s=enigma; d=jrv.org; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=HBAFMsZwBQ1N6/h/9XsgAY/v8idJZ7w+xFY/gBm6DJfAqKXTxmhYV534xUCrMStZX UTH57puE0dI5aV5bCQ+bNJMkc4sAcZO03GJLWO0Hz0on90AKTiOZ01oAINGcE4Ui0IR iBk14pa6/y1Y8xkv4EAcvZMrlYaTSKkG/cYrIPM= Message-ID: <4A36D8D9.7080104@jrv.org> Date: Mon, 15 Jun 2009 18:27:21 -0500 From: "James R. Van Artsdalen" User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Matthew Dillon References: <4A254B45.8050800@mavhome.dp.ua> <4A294DC3.5010008@mavhome.dp.ua> <200906051728.n55HSFf0076644@apollo.backplane.com> <200906152352.48231.Daan@vehosting.nl> <200906152209.n5FM9psY007070@apollo.backplane.com> In-Reply-To: <200906152209.n5FM9psY007070@apollo.backplane.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Daan Vreeken , Alexander Motin , FreeBSD-Current , freebsd-arch@freebsd.org Subject: Re: WIP: ATA to CAM integration 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, 15 Jun 2009 23:27:51 -0000 Matthew Dillon wrote: > (Someone tell me if I'm wrong there, I'm pretty sure all the Sili stuff > uses a Sili-specific device driver). > Silicon Image publishes the 3132 datasheet. http://www.siimage.com/docs/SiI-DS-0138-D.pdf This chip is probably the one most commonly used in add-on cards due to low cost. From owner-freebsd-current@FreeBSD.ORG Mon Jun 15 23:37:27 2009 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 3B47110656CC; Mon, 15 Jun 2009 23:37:27 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.freebsd.org (Postfix) with ESMTP id 0FE788FC0A; Mon, 15 Jun 2009 23:37:26 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.14.2/8.14.1) with ESMTP id n5FNbQrk008015; Mon, 15 Jun 2009 16:37:26 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.14.2/8.13.4/Submit) id n5FNbQrI008014; Mon, 15 Jun 2009 16:37:26 -0700 (PDT) Date: Mon, 15 Jun 2009 16:37:26 -0700 (PDT) From: Matthew Dillon Message-Id: <200906152337.n5FNbQrI008014@apollo.backplane.com> To: Phil Oleson References: <4A254B45.8050800@mavhome.dp.ua> <4A294DC3.5010008@mavhome.dp.ua> <200906051728.n55HSFf0076644@apollo.backplane.com> <200906152352.48231.Daan@vehosting.nl> <200906152209.n5FM9psY007070@apollo.backplane.com> <4A36CEE9.9040101@nixil.net> Cc: Daan Vreeken , Alexander Motin , FreeBSD-Current , freebsd-arch@freebsd.org Subject: Re: WIP: ATA to CAM integration 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, 15 Jun 2009 23:37:27 -0000 :meh.. found this via google: : :http://www.tomshardware.com/reviews/storage-accessories,1787-2.html : :The article claims it's AHCI compliant.. though the addonics web page :doesn't specifically says so from a cursory glance here: : :http://www.addonics.com/products/host_controller/extpm.asp : :and the other form factors. :http://www.addonics.com/products/pm/ : : -Phil. I think they mis-spoke. They are SATA-compliant and Port Multiplier compliant, and they use FIS-based packets, so they pretty much do away with all the ATA baggage, but they don't use the AHCI device interface so they won't probe as an AHCI driver. I can see why they do it that way, though. It looks like they hide most of the complexity behind the chipset, which is nice. AHCI exposes a lot of that complexity. It looks like a reasonable chipset. -Matt Matthew Dillon From owner-freebsd-current@FreeBSD.ORG Mon Jun 15 23:59:18 2009 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 A6A18106564A; Mon, 15 Jun 2009 23:59:18 +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 7253A8FC0C; Mon, 15 Jun 2009 23:59:18 +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.3/8.14.3) with ESMTP id n5FNxGff012933; Mon, 15 Jun 2009 19:59:16 -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.3/8.14.3) with ESMTP id n5FNxGrS067038; Mon, 15 Jun 2009 19:59:16 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 277527302F; Mon, 15 Jun 2009 19:59:16 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090615235916.277527302F@freebsd-current.sentex.ca> Date: Mon, 15 Jun 2009 19:59:16 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp1.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 205.211.164.50 Cc: Subject: [head tinderbox] failure on arm/arm 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: Mon, 15 Jun 2009 23:59:19 -0000 TB --- 2009-06-15 23:40:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-06-15 23:40:00 - starting HEAD tinderbox run for arm/arm TB --- 2009-06-15 23:40:00 - cleaning the object tree TB --- 2009-06-15 23:40:42 - cvsupping the source tree TB --- 2009-06-15 23:40:42 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/arm/arm/supfile TB --- 2009-06-15 23:40:53 - building world TB --- 2009-06-15 23:40:53 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-15 23:40:53 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-15 23:40:53 - TARGET=arm TB --- 2009-06-15 23:40:53 - TARGET_ARCH=arm TB --- 2009-06-15 23:40:53 - TZ=UTC TB --- 2009-06-15 23:40:53 - __MAKE_CONF=/dev/null TB --- 2009-06-15 23:40:53 - cd /src TB --- 2009-06-15 23:40:53 - /usr/bin/make -B buildworld >>> World build started on Mon Jun 15 23:40:55 UTC 2009 >>> 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 [...] ===> kerberos5/lib/libroken (obj,depend,all,install) rm -f .depend mkdep -f .depend -a -I/src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/src/kerberos5/lib/libroken/../../include /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/base64.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/bswap.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/closefrom.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/concat.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/copyhostent.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/dumpdata.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/ecalloc.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/emalloc.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/environment.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/eread.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/erealloc.c /src/kerberos5/lib/libroken/../../../cryp to/heimdal/lib/roken/esetenv.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/estrdup.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/ewrite.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/get_default_username.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/get_window_size.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/getaddrinfo_hostspec.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/getarg.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/getnameinfo_verified.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/hex.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/hostent_find_fqdn.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/issuid.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/k_getpwnam.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/k_getpwuid.c /src/kerberos5/lib/libroken/../../../c rypto/heimdal/lib/roken/mini_inetd.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/ndbm_wrap.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/net_read.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/net_write.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/parse_bytes.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/parse_time.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/parse_units.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/resolve.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/roken_gethostby.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/rtbl.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/simple_exec.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/snprintf.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/socket.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/s trcollect.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/strlwr.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/strndup.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/strnlen.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/strpool.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/strsep_copy.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/strupr.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/timeval.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/tm2time.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/unvis.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/verify.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/vis.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/warnerr.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/write_pid.c cc -O -pipe -I/src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/src/kerberos5/lib/libroken/../../include -std=gnu99 -c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/base64.c cc -O -pipe -I/src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/src/kerberos5/lib/libroken/../../include -std=gnu99 -c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/bswap.c cc -O -pipe -I/src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/src/kerberos5/lib/libroken/../../include -std=gnu99 -c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/closefrom.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/closefrom.c:50: error: conflicting types for 'closefrom' /obj/arm/src/tmp/usr/include/unistd.h:329: error: previous declaration of 'closefrom' was here *** Error code 1 Stop in /src/kerberos5/lib/libroken. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-15 23:59:16 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-15 23:59:16 - ERROR: failed to build world TB --- 2009-06-15 23:59:16 - 831.69 user 98.77 system 1155.47 real http://tinderbox.des.no/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Tue Jun 16 00:03:13 2009 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 0F3A3106564A; Tue, 16 Jun 2009 00:03:13 +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 CDFD88FC15; Tue, 16 Jun 2009 00:03:12 +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.3/8.14.3) with ESMTP id n5G03BVt013286; Mon, 15 Jun 2009 20:03:11 -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.3/8.14.3) with ESMTP id n5G03Bkk069192; Mon, 15 Jun 2009 20:03:11 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 022A37302F; Mon, 15 Jun 2009 20:03:11 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090616000311.022A37302F@freebsd-current.sentex.ca> Date: Mon, 15 Jun 2009 20:03:11 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp1.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 205.211.164.50 Cc: Subject: [head tinderbox] failure on amd64/amd64 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: Tue, 16 Jun 2009 00:03:13 -0000 TB --- 2009-06-15 23:40:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-06-15 23:40:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2009-06-15 23:40:00 - cleaning the object tree TB --- 2009-06-15 23:41:01 - cvsupping the source tree TB --- 2009-06-15 23:41:01 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/amd64/amd64/supfile TB --- 2009-06-15 23:41:11 - building world TB --- 2009-06-15 23:41:11 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-15 23:41:11 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-15 23:41:11 - TARGET=amd64 TB --- 2009-06-15 23:41:11 - TARGET_ARCH=amd64 TB --- 2009-06-15 23:41:11 - TZ=UTC TB --- 2009-06-15 23:41:11 - __MAKE_CONF=/dev/null TB --- 2009-06-15 23:41:11 - cd /src TB --- 2009-06-15 23:41:11 - /usr/bin/make -B buildworld >>> World build started on Mon Jun 15 23:41:14 UTC 2009 >>> 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 [...] ===> kerberos5/lib/libroken (obj,depend,all,install) rm -f .depend mkdep -f .depend -a -I/src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/src/kerberos5/lib/libroken/../../include /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/base64.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/bswap.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/closefrom.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/concat.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/copyhostent.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/dumpdata.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/ecalloc.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/emalloc.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/environment.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/eread.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/erealloc.c /src/kerberos5/lib/libroken/../../../cryp to/heimdal/lib/roken/esetenv.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/estrdup.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/ewrite.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/get_default_username.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/get_window_size.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/getaddrinfo_hostspec.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/getarg.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/getnameinfo_verified.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/hex.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/hostent_find_fqdn.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/issuid.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/k_getpwnam.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/k_getpwuid.c /src/kerberos5/lib/libroken/../../../c rypto/heimdal/lib/roken/mini_inetd.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/ndbm_wrap.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/net_read.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/net_write.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/parse_bytes.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/parse_time.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/parse_units.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/resolve.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/roken_gethostby.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/rtbl.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/simple_exec.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/snprintf.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/socket.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/s trcollect.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/strlwr.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/strndup.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/strnlen.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/strpool.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/strsep_copy.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/strupr.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/timeval.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/tm2time.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/unvis.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/verify.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/vis.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/warnerr.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/write_pid.c cc -O2 -pipe -I/src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/src/kerberos5/lib/libroken/../../include -std=gnu99 -fstack-protector -c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/base64.c cc -O2 -pipe -I/src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/src/kerberos5/lib/libroken/../../include -std=gnu99 -fstack-protector -c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/bswap.c cc -O2 -pipe -I/src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/src/kerberos5/lib/libroken/../../include -std=gnu99 -fstack-protector -c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/closefrom.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/closefrom.c:50: error: conflicting types for 'closefrom' /obj/amd64/src/tmp/usr/include/unistd.h:329: error: previous declaration of 'closefrom' was here *** Error code 1 Stop in /src/kerberos5/lib/libroken. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-16 00:03:10 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-16 00:03:10 - ERROR: failed to build world TB --- 2009-06-16 00:03:10 - 1012.09 user 110.15 system 1390.32 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Tue Jun 16 00:20:02 2009 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 8F761106566C; Tue, 16 Jun 2009 00:20:02 +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 655058FC08; Tue, 16 Jun 2009 00:20:02 +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.3/8.14.3) with ESMTP id n5G0JxkQ072947; Mon, 15 Jun 2009 20:19:59 -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 n5G0JxaV048923; Mon, 15 Jun 2009 20:19:59 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 9CCE17302F; Mon, 15 Jun 2009 20:19:59 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090616001959.9CCE17302F@freebsd-current.sentex.ca> Date: Mon, 15 Jun 2009 20:19:59 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp2.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on i386/i386 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: Tue, 16 Jun 2009 00:20:03 -0000 TB --- 2009-06-15 23:59:16 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-06-15 23:59:16 - starting HEAD tinderbox run for i386/i386 TB --- 2009-06-15 23:59:16 - cleaning the object tree TB --- 2009-06-15 23:59:54 - cvsupping the source tree TB --- 2009-06-15 23:59:54 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/i386/supfile TB --- 2009-06-16 00:00:02 - building world TB --- 2009-06-16 00:00:02 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-16 00:00:02 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-16 00:00:02 - TARGET=i386 TB --- 2009-06-16 00:00:02 - TARGET_ARCH=i386 TB --- 2009-06-16 00:00:02 - TZ=UTC TB --- 2009-06-16 00:00:02 - __MAKE_CONF=/dev/null TB --- 2009-06-16 00:00:02 - cd /src TB --- 2009-06-16 00:00:02 - /usr/bin/make -B buildworld >>> World build started on Tue Jun 16 00:00:03 UTC 2009 >>> 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 [...] ===> kerberos5/lib/libroken (obj,depend,all,install) rm -f .depend mkdep -f .depend -a -I/src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/src/kerberos5/lib/libroken/../../include /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/base64.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/bswap.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/closefrom.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/concat.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/copyhostent.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/dumpdata.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/ecalloc.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/emalloc.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/environment.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/eread.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/erealloc.c /src/kerberos5/lib/libroken/../../../cryp to/heimdal/lib/roken/esetenv.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/estrdup.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/ewrite.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/get_default_username.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/get_window_size.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/getaddrinfo_hostspec.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/getarg.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/getnameinfo_verified.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/hex.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/hostent_find_fqdn.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/issuid.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/k_getpwnam.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/k_getpwuid.c /src/kerberos5/lib/libroken/../../../c rypto/heimdal/lib/roken/mini_inetd.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/ndbm_wrap.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/net_read.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/net_write.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/parse_bytes.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/parse_time.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/parse_units.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/resolve.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/roken_gethostby.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/rtbl.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/simple_exec.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/snprintf.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/socket.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/s trcollect.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/strlwr.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/strndup.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/strnlen.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/strpool.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/strsep_copy.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/strupr.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/timeval.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/tm2time.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/unvis.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/verify.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/vis.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/warnerr.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/write_pid.c cc -O2 -pipe -I/src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/src/kerberos5/lib/libroken/../../include -std=gnu99 -fstack-protector -c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/base64.c cc -O2 -pipe -I/src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/src/kerberos5/lib/libroken/../../include -std=gnu99 -fstack-protector -c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/bswap.c cc -O2 -pipe -I/src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/src/kerberos5/lib/libroken/../../include -std=gnu99 -fstack-protector -c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/closefrom.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/closefrom.c:50: error: conflicting types for 'closefrom' /obj/src/tmp/usr/include/unistd.h:329: error: previous declaration of 'closefrom' was here *** Error code 1 Stop in /src/kerberos5/lib/libroken. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-16 00:19:59 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-16 00:19:59 - ERROR: failed to build world TB --- 2009-06-16 00:19:59 - 947.23 user 97.48 system 1243.32 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Tue Jun 16 00:24:09 2009 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 C176A1065672; Tue, 16 Jun 2009 00:24:09 +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 812478FC1B; Tue, 16 Jun 2009 00:24:09 +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.3/8.14.3) with ESMTP id n5G0O7BJ073254; Mon, 15 Jun 2009 20:24:07 -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 n5G0O7fe057537; Mon, 15 Jun 2009 20:24:07 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 495277302F; Mon, 15 Jun 2009 20:24:07 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090616002407.495277302F@freebsd-current.sentex.ca> Date: Mon, 15 Jun 2009 20:24:07 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp2.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on i386/pc98 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: Tue, 16 Jun 2009 00:24:10 -0000 TB --- 2009-06-16 00:03:11 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-06-16 00:03:11 - starting HEAD tinderbox run for i386/pc98 TB --- 2009-06-16 00:03:11 - cleaning the object tree TB --- 2009-06-16 00:03:48 - cvsupping the source tree TB --- 2009-06-16 00:03:48 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/pc98/supfile TB --- 2009-06-16 00:03:55 - building world TB --- 2009-06-16 00:03:55 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-16 00:03:55 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-16 00:03:55 - TARGET=pc98 TB --- 2009-06-16 00:03:55 - TARGET_ARCH=i386 TB --- 2009-06-16 00:03:55 - TZ=UTC TB --- 2009-06-16 00:03:55 - __MAKE_CONF=/dev/null TB --- 2009-06-16 00:03:55 - cd /src TB --- 2009-06-16 00:03:55 - /usr/bin/make -B buildworld >>> World build started on Tue Jun 16 00:03:57 UTC 2009 >>> 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 [...] ===> kerberos5/lib/libroken (obj,depend,all,install) rm -f .depend mkdep -f .depend -a -I/src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/src/kerberos5/lib/libroken/../../include /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/base64.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/bswap.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/closefrom.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/concat.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/copyhostent.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/dumpdata.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/ecalloc.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/emalloc.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/environment.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/eread.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/erealloc.c /src/kerberos5/lib/libroken/../../../cryp to/heimdal/lib/roken/esetenv.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/estrdup.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/ewrite.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/get_default_username.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/get_window_size.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/getaddrinfo_hostspec.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/getarg.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/getnameinfo_verified.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/hex.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/hostent_find_fqdn.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/issuid.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/k_getpwnam.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/k_getpwuid.c /src/kerberos5/lib/libroken/../../../c rypto/heimdal/lib/roken/mini_inetd.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/ndbm_wrap.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/net_read.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/net_write.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/parse_bytes.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/parse_time.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/parse_units.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/resolve.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/roken_gethostby.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/rtbl.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/simple_exec.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/snprintf.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/socket.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/s trcollect.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/strlwr.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/strndup.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/strnlen.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/strpool.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/strsep_copy.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/strupr.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/timeval.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/tm2time.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/unvis.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/verify.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/vis.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/warnerr.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/write_pid.c cc -O2 -pipe -I/src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/src/kerberos5/lib/libroken/../../include -std=gnu99 -fstack-protector -c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/base64.c cc -O2 -pipe -I/src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/src/kerberos5/lib/libroken/../../include -std=gnu99 -fstack-protector -c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/bswap.c cc -O2 -pipe -I/src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/src/kerberos5/lib/libroken/../../include -std=gnu99 -fstack-protector -c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/closefrom.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/closefrom.c:50: error: conflicting types for 'closefrom' /obj/pc98/src/tmp/usr/include/unistd.h:329: error: previous declaration of 'closefrom' was here *** Error code 1 Stop in /src/kerberos5/lib/libroken. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-16 00:24:07 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-16 00:24:07 - ERROR: failed to build world TB --- 2009-06-16 00:24:07 - 947.63 user 99.80 system 1256.11 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Tue Jun 16 00:58:12 2009 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 88BB01065673 for ; Tue, 16 Jun 2009 00:58:12 +0000 (UTC) (envelope-from mcdouga9@egr.msu.edu) Received: from mx.egr.msu.edu (surfnturf.egr.msu.edu [35.9.37.164]) by mx1.freebsd.org (Postfix) with ESMTP id 393968FC18 for ; Tue, 16 Jun 2009 00:58:12 +0000 (UTC) (envelope-from mcdouga9@egr.msu.edu) Received: from localhost (localhost [127.0.0.1]) by mx.egr.msu.edu (Postfix) with ESMTP id 84C0971F11D; Mon, 15 Jun 2009 20:58:11 -0400 (EDT) X-Virus-Scanned: amavisd-new at egr.msu.edu Received: from mx.egr.msu.edu ([127.0.0.1]) by localhost (surfnturf.egr.msu.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ofbA9gVbTLMe; Mon, 15 Jun 2009 20:58:11 -0400 (EDT) Received: from localhost (daemon.egr.msu.edu [35.9.44.65]) by mx.egr.msu.edu (Postfix) with ESMTP id 5F68F71F11B; Mon, 15 Jun 2009 20:58:11 -0400 (EDT) Received: by localhost (Postfix, from userid 21281) id 4A7A5AE; Mon, 15 Jun 2009 20:58:11 -0400 (EDT) Date: Mon, 15 Jun 2009 20:58:11 -0400 From: Adam McDougall To: Kris Kennaway Message-ID: <20090616005810.GE1111@egr.msu.edu> References: <1242075474.72992.118.camel@hood.oook.cz> <4A36B6D8.8000701@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A36B6D8.8000701@FreeBSD.org> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: current@FreeBSD.org Subject: Re: pointyhat 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: Tue, 16 Jun 2009 00:58:12 -0000 On Mon, Jun 15, 2009 at 10:02:16PM +0100, Kris Kennaway wrote: Pav Lucistnik wrote: > panic: mtx_lock() of destroyed mutex @ /usr/src/sys/rpc/clnt_vc.c:953 > cpuid = 2 > KDB: enter: panic > [thread pid 0 tid 100029 ] > Stopped at kdb_enter+0x3d: movq $0,0x3f5fb8(%rip) > db> bt > Tracing pid 0 tid 100029 td 0xffffff00018e1000 > kdb_enter() at kdb_enter+0x3d > panic() at panic+0x17b > _mtx_lock_flags() at _mtx_lock_flags+0xc5 > clnt_vc_soupcall() at clnt_vc_soupcall+0x273 > sowakeup() at sowakeup+0xf8 > tcp_do_segment() at tcp_do_segment+0x23c9 > tcp_input() at tcp_input+0x9ec > ip_input() at ip_input+0xbc > ether_demux() at ether_demux+0x1ed > ether_input() at ether_input+0x171 > em_rxeof() at em_rxeof+0x201 > em_handle_rxtx() at em_handle_rxtx+0x4b > taskqueue_run() at taskqueue_run+0x96 > taskqueue_thread_loop() at taskqueue_thread_loop+0x3f > fork_exit() at fork_exit+0x12a > fork_trampoline() at fork_trampoline+0xe > --- trap 0, rip = 0, rsp = 0xffffffff240a6d40, rbp = 0 --- > > The box is in kdb on serial console for now. May 9 -CURRENT, I think. > This happened again. The trigger was this (^C of a find on a busy netapp volume with a lot of other concurrent nfs traffic to the same mountpoint): pointyhat# find . -name \*.bz2 -mmin -10 ^Cnfs server dumpster:/vol/vol4/pointyhat: not responding nfs server dumpster:/vol/vol4/pointyhat: not responding nfs server dumpster:/vol/vol4/pointyhat: not responding nfs server dumpster:/vol/vol4/pointyhat: not responding nfs server dumpster:/vol/vol4/pointyhat: not responding nfs server dumpster:/vol/vol4/pointyhat: not responding nfs server dumpster:/vol/vol4/pointyhat: not responding nfs server dumpster:/vol/vol4/pointyhat: not responding nfs server dumpster:/vol/vol4/pointyhat: not responding nfs server dumpster:/vol/vol4/pointyhat: not responding nfs server dumpster:/vol/vol4/pointyhat: not responding nfs server dumpster:/vol/vol4/pointyhat: not responding load: 4.54 cmd: find 93357 [rpccon] 11.19u 111.62s 0% 4848k About 5-10 minutes later the machine panicked. I'll try updating to a newer -CURRENT. Kris This sounds like nearly exactly the same symptoms I noticed on a -current machine a few months ago, I was doing a du on a nfs mount, decided to ctrl-c it, got the not responding for a while and a few minutes after the system paniced. I hadn't had a chance to report it yet but I did find a workaround, it is stable if I remove "intr" from the NFS mount options. Hope this helps a little. From owner-freebsd-current@FreeBSD.ORG Tue Jun 16 03:12:59 2009 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 69E2A106564A for ; Tue, 16 Jun 2009 03:12:59 +0000 (UTC) (envelope-from ben@wanderview.com) Received: from mail.wanderview.com (mail.wanderview.com [66.92.166.102]) by mx1.freebsd.org (Postfix) with ESMTP id 0EC3D8FC0C for ; Tue, 16 Jun 2009 03:12:58 +0000 (UTC) (envelope-from ben@wanderview.com) Received: from [10.76.10.146] ([10.76.10.146]) (authenticated bits=0) by mail.wanderview.com (8.14.3/8.14.3) with ESMTP id n5G3Co1m058549 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Jun 2009 03:12:56 GMT (envelope-from ben@wanderview.com) Message-ID: <4A370DB2.8070403@wanderview.com> Date: Mon, 15 Jun 2009 23:12:50 -0400 From: Ben Kelly User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: Ivan Voras References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: -1.44 () ALL_TRUSTED,AWL X-Scanned-By: MIMEDefang 2.64 on 10.76.20.1 Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: tmpfs experimental? 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, 16 Jun 2009 03:12:59 -0000 Ivan Voras wrote: > Hi, > > Are there still known problems with tmpfs? > > I've been using it for a while in 7-STABLE and 8-CURRENT without > noticeable problems - not that there was ever serious load involved > (normal /tmp activity). I've just tried it and it survived a couple of > rounds of blogbench, even with virtual memory swapping. > > In other words, is there still reason for the "highly experimental > feature" warning? I get some slightly unexpected behavior when mount is run multiple times: ianto# mount | grep ' /tmp' tmpfs on /tmp (tmpfs, local) ianto# mount /tmp ianto# mount | grep ' /tmp' tmpfs on /tmp (tmpfs, local) tmpfs on /tmp (tmpfs, local) ianto# umount /tmp ianto# mount | grep ' /tmp' tmpfs on /tmp (tmpfs, local) ianto# It also occurred to me once that perhaps all tmpfs mounts should share the same UMA zones instead of a new zone for each mount, but thats a pretty minor issue: ianto# vmstat -z | grep TMPFS TMPFS dirent: 20, 0, 4, 165, 385, 0 TMPFS node: 136, 0, 5, 53, 386, 0 TMPFS dirent: 20, 0, 4, 165, 5541, 0 TMPFS node: 136, 0, 5, 53, 5542, 0 TMPFS dirent: 20, 0, 6, 163, 51031, 0 TMPFS node: 136, 0, 7, 80, 46927, 0 TMPFS dirent: 20, 0, 4, 165, 7542, 0 TMPFS node: 136, 0, 5, 53, 7543, 0 TMPFS dirent: 20, 0, 6, 163, 81644, 0 TMPFS node: 136, 0, 8, 79, 77463, 0 Overall tmpfs has been very stable for me as a mimedefang spool directory. Hope that helps. - Ben From owner-freebsd-current@FreeBSD.ORG Tue Jun 16 03:44:00 2009 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 7578C106564A; Tue, 16 Jun 2009 03:44:00 +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 32F468FC16; Tue, 16 Jun 2009 03:43:59 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: (from root@localhost) by kientzle.com (8.14.3/8.14.3) id n5G3hxkE094910; Mon, 15 Jun 2009 20:43:59 -0700 (PDT) (envelope-from kientzle@freebsd.org) Received: from dark.x.kientzle.com (fw2.kientzle.com [10.123.1.2]) by kientzle.com with SMTP id 6d7jahdj6gnqqz3tyct2whxm42; Mon, 15 Jun 2009 20:43:59 -0700 (PDT) (envelope-from kientzle@freebsd.org) Message-ID: <4A3714FF.7050608@freebsd.org> Date: Mon, 15 Jun 2009 20:43:59 -0700 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.1.21) Gecko/20090601 SeaMonkey/1.1.16 MIME-Version: 1.0 To: Sam Leffler References: <20090615181555.GA52009@freebsd.org> <4A369529.5090004@freebsd.org> In-Reply-To: <4A369529.5090004@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Roman Divacky , current@freebsd.org Subject: Re: [RFC]: (void)0 instead of empty defines 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, 16 Jun 2009 03:44:00 -0000 > Are you saying that: > > if (cond) > ; > > is considered worthy of a warning by the compiler? Yes, especially when it's written as: if (rare_condition); do_something_dangerous(); Tim From owner-freebsd-current@FreeBSD.ORG Tue Jun 16 05:52:48 2009 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 DB440106564A; Tue, 16 Jun 2009 05:52:48 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 1E4948FC28; Tue, 16 Jun 2009 05:52:47 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from [212.86.226.226] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPSA id 245817994; Tue, 16 Jun 2009 08:52:44 +0300 Message-ID: <4A373318.9000603@FreeBSD.org> Date: Tue, 16 Jun 2009 08:52:24 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.21 (X11/20090405) MIME-Version: 1.0 To: Matthew Dillon References: <4A254B45.8050800@mavhome.dp.ua> <4A294DC3.5010008@mavhome.dp.ua> <200906051728.n55HSFf0076644@apollo.backplane.com> <200906152352.48231.Daan@vehosting.nl> <200906152209.n5FM9psY007070@apollo.backplane.com> <4A36CEE9.9040101@nixil.net> <200906152337.n5FNbQrI008014@apollo.backplane.com> In-Reply-To: <200906152337.n5FNbQrI008014@apollo.backplane.com> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: Daan Vreeken , FreeBSD-Current , Phil Oleson , freebsd-arch@freebsd.org Subject: Re: WIP: ATA to CAM integration 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, 16 Jun 2009 05:52:49 -0000 Matthew Dillon wrote: > I think they mis-spoke. They are SATA-compliant and Port Multiplier > compliant, and they use FIS-based packets, so they pretty much do away > with all the ATA baggage, but they don't use the AHCI device interface > so they won't probe as an AHCI driver. > > I can see why they do it that way, though. It looks like they hide > most of the complexity behind the chipset, which is nice. AHCI > exposes a lot of that complexity. > > It looks like a reasonable chipset. Agree. It's functionally comparable to the latest AHCI specs, but looks more user-friendly. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Tue Jun 16 07:33:58 2009 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 339911065672; Tue, 16 Jun 2009 07:33:58 +0000 (UTC) (envelope-from erwin@mail.droso.net) Received: from mail.droso.net (koala.ipv6.droso.net [IPv6:2001:6c8:6:c:20d:56ff:fe6f:f935]) by mx1.freebsd.org (Postfix) with ESMTP id B68938FC1B; Tue, 16 Jun 2009 07:33:57 +0000 (UTC) (envelope-from erwin@mail.droso.net) Received: by mail.droso.net (Postfix, from userid 1001) id B89781CD3A; Tue, 16 Jun 2009 09:33:55 +0200 (CEST) Date: Tue, 16 Jun 2009 09:33:55 +0200 From: Erwin Lansing To: Kip Macy Message-ID: <20090616073353.GZ33280@droso.net> References: <1242075474.72992.118.camel@hood.oook.cz> <4A36B6D8.8000701@FreeBSD.org> <3c1674c90906151408n6febec56m140b089b694f6e13@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ibq+fG+Ci5ONsaof" Content-Disposition: inline In-Reply-To: <3c1674c90906151408n6febec56m140b089b694f6e13@mail.gmail.com> X-Operating-System: FreeBSD/i386 7.2-STABLE User-Agent: Mutt/1.5.19 (2009-01-05) Cc: Doug Rabson , pav@freebsd.org, current@freebsd.org Subject: Re: pointyhat 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: Tue, 16 Jun 2009 07:33:58 -0000 --ibq+fG+Ci5ONsaof Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jun 15, 2009 at 02:08:17PM -0700, Kip Macy wrote: > This is from the RPC re-work. I had thought that this was fixed. You > shouldn't see this on the latest -CURRENT, but Doug will have more > details. Any datepoint when these fixes went in? I upgraded pointyhat last month exactly to get the latest fixes in, but could be there were more since then. Thanks, -erwin >=20 > Cheers, > Kip >=20 >=20 > On Mon, Jun 15, 2009 at 2:02 PM, Kris Kennaway wrote: > > Pav Lucistnik wrote: > >> > >> panic: mtx_lock() of destroyed mutex @ /usr/src/sys/rpc/clnt_vc.c:953 > >> cpuid =3D 2 > >> KDB: enter: panic > >> [thread pid 0 tid 100029 ] > >> Stopped at =A0 =A0 =A0kdb_enter+0x3d: movq =A0 =A0$0,0x3f5fb8(%rip) > >> db> bt > >> Tracing pid 0 tid 100029 td 0xffffff00018e1000 > >> kdb_enter() at kdb_enter+0x3d > >> panic() at panic+0x17b > >> _mtx_lock_flags() at _mtx_lock_flags+0xc5 > >> clnt_vc_soupcall() at clnt_vc_soupcall+0x273 > >> sowakeup() at sowakeup+0xf8 > >> tcp_do_segment() at tcp_do_segment+0x23c9 > >> tcp_input() at tcp_input+0x9ec > >> ip_input() at ip_input+0xbc > >> ether_demux() at ether_demux+0x1ed > >> ether_input() at ether_input+0x171 > >> em_rxeof() at em_rxeof+0x201 > >> em_handle_rxtx() at em_handle_rxtx+0x4b > >> taskqueue_run() at taskqueue_run+0x96 > >> taskqueue_thread_loop() at taskqueue_thread_loop+0x3f > >> fork_exit() at fork_exit+0x12a > >> fork_trampoline() at fork_trampoline+0xe > >> --- trap 0, rip =3D 0, rsp =3D 0xffffffff240a6d40, rbp =3D 0 --- > >> > >> The box is in kdb on serial console for now. May 9 -CURRENT, I think. > >> > > > > This happened again. =A0The trigger was this (^C of a find on a busy ne= tapp > > volume with a lot of other concurrent nfs traffic to the same mountpoin= t): > > > > pointyhat# find . -name \*.bz2 -mmin -10 > > ^Cnfs server dumpster:/vol/vol4/pointyhat: not responding > > nfs server dumpster:/vol/vol4/pointyhat: not responding > > nfs server dumpster:/vol/vol4/pointyhat: not responding > > nfs server dumpster:/vol/vol4/pointyhat: not responding > > nfs server dumpster:/vol/vol4/pointyhat: not responding > > nfs server dumpster:/vol/vol4/pointyhat: not responding > > nfs server dumpster:/vol/vol4/pointyhat: not responding > > nfs server dumpster:/vol/vol4/pointyhat: not responding > > nfs server dumpster:/vol/vol4/pointyhat: not responding > > nfs server dumpster:/vol/vol4/pointyhat: not responding > > nfs server dumpster:/vol/vol4/pointyhat: not responding > > nfs server dumpster:/vol/vol4/pointyhat: not responding > > load: 4.54 =A0cmd: find 93357 [rpccon] 11.19u 111.62s 0% 4848k > > > > About 5-10 minutes later the machine panicked. =A0I'll try updating to = a newer > > -CURRENT. > > > > Kris > > >=20 >=20 >=20 > --=20 > When bad men combine, the good must associate; else they will fall one > by one, an unpitied sacrifice in a contemptible struggle. >=20 > Edmund Burke > _______________________________________________ > 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" --=20 Erwin Lansing http://droso.org Prediction is very difficult especially about the future erwin@FreeBSD.org --ibq+fG+Ci5ONsaof Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iD8DBQFKN0rhqy9aWxUlaZARArrjAJ0Qeqq72+QaYFhQtAj4TlyHfxhEsgCfUgPL gpEUkZDcANcxTHJFir1s/C4= =Woyp -----END PGP SIGNATURE----- --ibq+fG+Ci5ONsaof-- From owner-freebsd-current@FreeBSD.ORG Tue Jun 16 09:33:36 2009 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 7282E10656B1 for ; Tue, 16 Jun 2009 09:33:36 +0000 (UTC) (envelope-from uqs@spoerlein.net) Received: from acme.spoerlein.net (cl-43.dus-01.de.sixxs.net [IPv6:2a01:198:200:2a::2]) by mx1.freebsd.org (Postfix) with ESMTP id E4C0D8FC1A for ; Tue, 16 Jun 2009 09:33:35 +0000 (UTC) (envelope-from uqs@spoerlein.net) Received: from acme.spoerlein.net (localhost.spoerlein.net [127.0.0.1]) by acme.spoerlein.net (8.14.3/8.14.3) with ESMTP id n5G9XYow045936 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Jun 2009 11:33:34 +0200 (CEST) (envelope-from uqs@spoerlein.net) Received: (from uqs@localhost) by acme.spoerlein.net (8.14.3/8.14.3/Submit) id n5G9XYXX045935; Tue, 16 Jun 2009 11:33:34 +0200 (CEST) (envelope-from uqs@spoerlein.net) Date: Tue, 16 Jun 2009 11:33:34 +0200 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: Pyun YongHyeon Message-ID: <20090616093334.GB31709@acme.spoerlein.net> Mail-Followup-To: Pyun YongHyeon , current@freebsd.org References: <20090615121623.GA1479@roadrunner.spoerlein.net> <20090615125154.GG78415@michelle.cdnetworks.co.kr> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20090615125154.GG78415@michelle.cdnetworks.co.kr> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: current@freebsd.org Subject: Re: ale(4): Problems with tso, rxcsum and/or txcsum 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, 16 Jun 2009 09:33:37 -0000 On Mon, 15.06.2009 at 21:51:54 +0900, Pyun YongHyeon wrote: > On Mon, Jun 15, 2009 at 02:16:23PM +0200, Ulrich Sp??rlein wrote: > > Hello Pyun, > > > > I have connection problems with the onboard GigE of an Asus P5Q board, using a recent 8-CURRENT > > > > ale0: port 0xdc00-0xdc7f mem 0xfe9c0000-0xfe9fffff irq 17 at device 0.0 on pci2 > > ale0: 960 Tx FIFO, 1024 Rx FIFO > > ale0: Using 1 MSI messages. > > ale0: 4GB boundary crossed, switching to 32bit DMA addressing mode. > > miibus0: on ale0 > > ale0: Ethernet address: 00:24:8c:36:3e:10 > > ale0: [FILTER] > > ale0: link state changed to UP > > > > ale0@pci0:2:0:0: class=0x020000 card=0x82261043 chip=0x10261969 rev=0xb0 hdr=0x00 > > vendor = 'Attansic (Now owned by Atheros)' > > device = 'PCI-E ETHERNET CONTROLLER (AR8121/AR8113 )' > > class = network > > subclass = ethernet > > > > ale0: flags=8843 metric 0 mtu 1500 > > options=311b > > ether 00:24:8c:36:3e:10 > > inet 192.168.0.146 netmask 0xffffff00 broadcast 192.168.0.255 > > media: Ethernet autoselect (100baseTX ) > > status: active > > > > > > When transferring data to the machine at ~10MB/s (100Mbit network only) the ssh > > connection will die after a couple of minutes with > > > > Disconnecting: Bad packet length 1592360521. > > > > After disabling tso, txcsum and rxcsum the connection seems to be > > stable, though. I fail to figure out a pattern, though. Do I need to > > Hmm, I think this is the second report that could be related with > Rx checksum offloading. If disabling Rx checksum fix the issue, I > have to disable it by default until I understand what's going on. I really need to disable tso, rxcsum *and* txcsum to make this card work stable. :/ There is one other weirdness, though, regarding tso. I have been using a netcat-blast test, where I "upload" /dev/zero to another machine, and "download" it from the same machine. When tso is enabled, upload is seriously impacted, download is fine though, observe systat output: ale0 in 10.805 MB/s 11.101 MB/s 7.739 GB out 2.574 MB/s 8.740 MB/s 5.891 GB When disabling tso, while that test is running, it will immediately become this: ale0 in 7.498 MB/s 11.101 MB/s 8.270 GB out 7.560 MB/s 8.740 MB/s 6.209 GB Which looks more normal. Re-activating tso now has no further consequences to the stream (it only works for new TCP sessions, right?) Cheers, Ulrich Spörlein -- http://www.dubistterrorist.de/ From owner-freebsd-current@FreeBSD.ORG Tue Jun 16 09:47:01 2009 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 282E81065674 for ; Tue, 16 Jun 2009 09:47:01 +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 D6B678FC18 for ; Tue, 16 Jun 2009 09:47:00 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1MGVFr-0000q3-RA for freebsd-current@freebsd.org; Tue, 16 Jun 2009 09:46:59 +0000 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 16 Jun 2009 09:46:59 +0000 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 16 Jun 2009 09:46:59 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Tue, 16 Jun 2009 11:46:49 +0200 Lines: 30 Message-ID: References: <4A370DB2.8070403@wanderview.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 2.0.0.21 (X11/20090615) In-Reply-To: <4A370DB2.8070403@wanderview.com> Sender: news Cc: freebsd-hackers@freebsd.org Subject: Re: tmpfs experimental? 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, 16 Jun 2009 09:47:01 -0000 Ben Kelly wrote: > Ivan Voras wrote: >> Hi, >> >> Are there still known problems with tmpfs? >> >> I've been using it for a while in 7-STABLE and 8-CURRENT without >> noticeable problems - not that there was ever serious load involved >> (normal /tmp activity). I've just tried it and it survived a couple of >> rounds of blogbench, even with virtual memory swapping. >> >> In other words, is there still reason for the "highly experimental >> feature" warning? > > I get some slightly unexpected behavior when mount is run > multiple times: > > ianto# mount | grep ' /tmp' > tmpfs on /tmp (tmpfs, local) > ianto# mount /tmp > ianto# mount | grep ' /tmp' > tmpfs on /tmp (tmpfs, local) > tmpfs on /tmp (tmpfs, local) > ianto# umount /tmp > ianto# mount | grep ' /tmp' > tmpfs on /tmp (tmpfs, local) Sorry, maybe I'm missing the point, but what is wrong with the above behaviour? AFAIK you are allowed to mount multiple file systems on the same directory, though it isn't very useful. From owner-freebsd-current@FreeBSD.ORG Tue Jun 16 10:14:03 2009 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 756DE106566B for ; Tue, 16 Jun 2009 10:14:03 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.177]) by mx1.freebsd.org (Postfix) with ESMTP id 42D3D8FC1E for ; Tue, 16 Jun 2009 10:14:03 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by wa-out-1112.google.com with SMTP id m38so1419238waf.27 for ; Tue, 16 Jun 2009 03:14:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:subject :message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=xo3MXb6D/AytLsdDckULtZMIQplnFA5Wdjtpck2PLkg=; b=AkL8acWw2pldOg6JLH6QY8Gl35DtTsaO6/q2G1jSdyk7njVkLgVaY1w9Tu8hWYuM4g yU1vko3j5Sn0hP3InFgDRnOzEjLIDPHLoHybm4hxNUPzICIdrCuUVKsVoX5GWYV/GHnQ w2UMiByN9t7hYD98ADDeqaKCbNz/HniROvZjk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=lYjMw/QdH7pZhlpRxEXJ5smmeCfd2TYnm0b2be3tfbyuO0+OaniLImSW0vpoiSrn2+ ueUUn9Jd8lqrbWwzGtbf6Rwayg6gcFhLUTkBb5ub84U8Reu7Ugiy/qX1dpJItagZYWBZ oFUSeXUq/r5G1TuQ6d2GooCqy487Q45RrrjRw= Received: by 10.115.60.2 with SMTP id n2mr13401678wak.36.1245147242835; Tue, 16 Jun 2009 03:14:02 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ([114.111.62.249]) by mx.google.com with ESMTPS id g25sm2522167wag.43.2009.06.16.03.14.01 (version=SSLv3 cipher=RC4-MD5); Tue, 16 Jun 2009 03:14:01 -0700 (PDT) Received: by michelle.cdnetworks.co.kr (sSMTP sendmail emulation); Tue, 16 Jun 2009 19:17:40 +0900 From: Pyun YongHyeon Date: Tue, 16 Jun 2009 19:17:40 +0900 To: current@freebsd.org Message-ID: <20090616101740.GI78415@michelle.cdnetworks.co.kr> References: <20090615121623.GA1479@roadrunner.spoerlein.net> <20090615125154.GG78415@michelle.cdnetworks.co.kr> <20090616093334.GB31709@acme.spoerlein.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090616093334.GB31709@acme.spoerlein.net> User-Agent: Mutt/1.4.2.3i Cc: Subject: Re: ale(4): Problems with tso, rxcsum and/or txcsum 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, 16 Jun 2009 10:14:03 -0000 On Tue, Jun 16, 2009 at 11:33:34AM +0200, Ulrich Sp??rlein wrote: > On Mon, 15.06.2009 at 21:51:54 +0900, Pyun YongHyeon wrote: > > On Mon, Jun 15, 2009 at 02:16:23PM +0200, Ulrich Sp??rlein wrote: > > > Hello Pyun, > > > > > > I have connection problems with the onboard GigE of an Asus P5Q board, using a recent 8-CURRENT > > > > > > ale0: port 0xdc00-0xdc7f mem 0xfe9c0000-0xfe9fffff irq 17 at device 0.0 on pci2 > > > ale0: 960 Tx FIFO, 1024 Rx FIFO > > > ale0: Using 1 MSI messages. > > > ale0: 4GB boundary crossed, switching to 32bit DMA addressing mode. > > > miibus0: on ale0 > > > ale0: Ethernet address: 00:24:8c:36:3e:10 > > > ale0: [FILTER] > > > ale0: link state changed to UP > > > > > > ale0@pci0:2:0:0: class=0x020000 card=0x82261043 chip=0x10261969 rev=0xb0 hdr=0x00 > > > vendor = 'Attansic (Now owned by Atheros)' > > > device = 'PCI-E ETHERNET CONTROLLER (AR8121/AR8113 )' > > > class = network > > > subclass = ethernet > > > > > > ale0: flags=8843 metric 0 mtu 1500 > > > options=311b > > > ether 00:24:8c:36:3e:10 > > > inet 192.168.0.146 netmask 0xffffff00 broadcast 192.168.0.255 > > > media: Ethernet autoselect (100baseTX ) > > > status: active > > > > > > > > > When transferring data to the machine at ~10MB/s (100Mbit network only) the ssh > > > connection will die after a couple of minutes with > > > > > > Disconnecting: Bad packet length 1592360521. > > > > > > After disabling tso, txcsum and rxcsum the connection seems to be > > > stable, though. I fail to figure out a pattern, though. Do I need to > > > > Hmm, I think this is the second report that could be related with > > Rx checksum offloading. If disabling Rx checksum fix the issue, I > > have to disable it by default until I understand what's going on. > > I really need to disable tso, rxcsum *and* txcsum to make this card work > stable. :/ > Hmm, let's see which offload was broken. Disabling all offloads make it hard to find broken one. > There is one other weirdness, though, regarding tso. I have been using a > netcat-blast test, where I "upload" /dev/zero to another machine, and > "download" it from the same machine. > > When tso is enabled, upload is seriously impacted, download is fine > though, observe systat output: > > ale0 in 10.805 MB/s 11.101 MB/s 7.739 GB > out 2.574 MB/s 8.740 MB/s 5.891 GB > > When disabling tso, while that test is running, it will immediately become this: > > ale0 in 7.498 MB/s 11.101 MB/s 8.270 GB > out 7.560 MB/s 8.740 MB/s 6.209 GB > > Which looks more normal. Re-activating tso now has no further consequences to > the stream (it only works for new TCP sessions, right?) > I was able to saturate gigabit link with AR8121. Tx performance is about 930Mbps or higher. Since ale(4) does not support ethernet flow-control it could be caused by dropped frames. Check hardware MAC counters, you can get it via "sysctl dev.ale.0.stats". Receiver also should be fast enough to get frames without loss. The above does not explain OpenSSH's output of "Bad packet length". It really means incoming packets were corrupted. So I'd like to know if you disable Rx checksum offloading you can still see the horrible message from OpenSSH. It does not necessarily mean TSO/ Tx checksum offloading works without problems but I'd like to narrow down issues instead of blindly disabling all offloads. From owner-freebsd-current@FreeBSD.ORG Tue Jun 16 10:40:32 2009 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 A48D4106566B for ; Tue, 16 Jun 2009 10:40:32 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id E701A8FC0A for ; Tue, 16 Jun 2009 10:40:31 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id NAA04020; Tue, 16 Jun 2009 13:20:44 +0300 (EEST) (envelope-from avg@freebsd.org) Message-ID: <4A3771FC.7030301@freebsd.org> Date: Tue, 16 Jun 2009 13:20:44 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.21 (X11/20090406) MIME-Version: 1.0 To: Marcel Moolenaar References: <20090615181555.GA52009@freebsd.org> <4A369529.5090004@freebsd.org> <20090615185812.GA67104@freebsd.org> <53E03A0A-8846-4EED-AE95-A15960FC6724@mac.com> In-Reply-To: <53E03A0A-8846-4EED-AE95-A15960FC6724@mac.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Roman Divacky , Sam Leffler , current@freebsd.org Subject: Re: [RFC]: (void)0 instead of empty defines 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, 16 Jun 2009 10:40:32 -0000 on 15/06/2009 22:38 Marcel Moolenaar said the following: > If the patch is all we need to compile the kernel with the warning > enabled and knowing that the warning has already found real bugs, > then it's a no-brainer to me: commit. I agree - if FOO is a function-like or complete-statement-like macro than it is more consistent to expand it to no-op statement than to nothing. (I am not sure if the same is true for other type of macros, e.g. expression-like ones). BTW, I think that this is a very typical practice, many C projects that I worked on used this convention. Our assert.h also does this. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Tue Jun 16 10:01:46 2009 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 EF490106566B; Tue, 16 Jun 2009 10:01:46 +0000 (UTC) (envelope-from venkiece2005@gmail.com) Received: from mail-gx0-f207.google.com (mail-gx0-f207.google.com [209.85.217.207]) by mx1.freebsd.org (Postfix) with ESMTP id 9A5708FC20; Tue, 16 Jun 2009 10:01:46 +0000 (UTC) (envelope-from venkiece2005@gmail.com) Received: by gxk3 with SMTP id 3so6816387gxk.19 for ; Tue, 16 Jun 2009 03:01:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=scLu95xR/Q1lhFNSxU3JsroV2l2GkFg510kiws1Bw0M=; b=Hek50uJ4Cq8VGvsyl7sMI8MfkBBoxIhhw2qm+jYXuYiY4Mnx9Sb7C5fELtSmwn9MvL NujpkGyOlJbljrtHyq3up+h/yzCmo1kzTfVwJcca39Ak7Ms7HSX+YXeM7aczUjxq96Bp 8yZb5sUkYJ3FZEVR9tL9vB7x3pYZ/BcPw1QKk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=ceV/FN4SyEwn0YZw9xg6AauB2A0Zk/9ic3IFFRzuZ+yxL9tbfjfdgnC03A6bRdpCxI ObO2pJrv8Y7+bbe1vcLKUTjLGoyQjsMwxkFWbLvUpaG3Rji5bqKG5igcMoGdlWyO/Mm1 Qbj9JNnbRdofmDt1LLGw08r/N+XwHZTqPHRL8= MIME-Version: 1.0 Received: by 10.151.119.3 with SMTP id w3mr15306939ybm.149.1245144576692; Tue, 16 Jun 2009 02:29:36 -0700 (PDT) Date: Tue, 16 Jun 2009 14:59:36 +0530 Message-ID: <6d53329e0906160229j2fdba518h84b13652153a32f6@mail.gmail.com> From: venki kaps To: freebsd-arm@freebsd.org, netbsd-users@netbsd.org, freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 16 Jun 2009 13:05:18 +0000 Cc: Subject: [libc] dlclose gives "invalid shared object handle" without pthread combination. 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, 16 Jun 2009 10:01:47 -0000 Hi, I am using the NetBSD implementation of rtld(src/libexec/ld.elf_so/) for ARM/MIPS. I have C++ static constructor/destructor issue with my rtld. Problem Report: "ld.elf_so does not execute .init/.fini functions in order" and [libc] dlclose gives "invalid shared object handle" when called through the fini function of another module. The similar NetBSD/freeBSD issues are found from the following References: [1] http://gnats.netbsd.org/37347 [2] http://updraft3.jp.freebsd.org/cgi/query-pr.cgi?pr=kern/42956 The above issues are already commited in NetBSD-5-0-RELEASE. I have ported NetBSD-5-0-RELEASE rtld and tested Ref[1] provided static constructor/destructor test and did not find any issues with shared pthread combination but noticed [libc] dlclose gives "invalid shared object handle" without pthread combination. The static constructor/destructor test results: It should be : -------------- $ ./foobar foo_ctor bar_ctor tar_ctor main_ctor dep1_ctor dep2_ctor dll_ctor dll_dtor dep2_dtor dep1_dtor main_dtor tar_dtor bar_dtor foo_dtor While currently I get: ---------------------- with pthreads: $ ./foobar foo_ctor bar_ctor tar_ctor main_ctor dep1_ctor dep2_ctor dll_ctor dll_dtor dep2_dtor dep1_dtor main_dtor tar_dtor bar_dtor foo_dtor without pthreads: $ ./foobar foo_ctor bar_ctor tar_ctor main_ctor dep1_ctor dep2_ctor dll_ctor dll_dtor dep2_dtor dep1_dtor main_dtor tar_dtor bar_dtor foo_dtor Invalid shared object handle 0xbdbed400 This gives a "invalid shared object handle" message because the refcount field (obj->dl_refcount) for the handle is zero. I have little bit confused about dlclose destructor with/without pthreads. I have some queries: 1) Is it required any changes apart from the NetBSD-5-0-RELEASE/{Ref[1],[2]}? 2) Are any changes required in thread-stub? Could anyone provide any inputs to the my issue? Thanks in advance. Thanks & Regards, Venkappa From owner-freebsd-current@FreeBSD.ORG Tue Jun 16 11:30:56 2009 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 C1A2B106564A; Tue, 16 Jun 2009 11:30:56 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [IPv6:2001:4070:101:2::1]) by mx1.freebsd.org (Postfix) with ESMTP id AAF718FC0A; Tue, 16 Jun 2009 11:30:55 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (localhost [IPv6:::1]) by wojtek.tensor.gdynia.pl (8.14.3/8.14.3) with ESMTP id n5GBUTTJ027602; Tue, 16 Jun 2009 13:30:29 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.3/8.14.3/Submit) with ESMTP id n5GBUQm0027599; Tue, 16 Jun 2009 13:30:29 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Tue, 16 Jun 2009 13:30:25 +0200 (CEST) From: Wojciech Puchar To: d@delphij.net In-Reply-To: <4A36930F.2000302@delphij.net> Message-ID: References: <4A36930F.2000302@delphij.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Tue, 16 Jun 2009 13:05:35 +0000 Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, Ivan Voras Subject: Re: tmpfs experimental? 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, 16 Jun 2009 11:30:57 -0000 >> In other words, is there still reason for the "highly experimental >> feature" warning? > > Last time when I added the warning, it was because some data corruption > issue that can be identified by fsx which I didn't got a chance to > investigate further. I think tmpfs is Ok for some usual work but maybe > not ready for production at that moment. alc@ and kib@ has made a lot > of changes on it recently so perhaps we need to re-visit the problems, > tmpfs would be a great feature for us. as an ordinary user not programmer of tmpfs i can say that: 1) runs fine for months in production environments, including case with over 40 mountpoints (jails) 2) runs really fast when memory is available. 3) performance is bad in case that swapping actually is used. It reads from swap with too small chunks. it's a place for improvement here. Its great thing as it does it properly - memory is immediately freed on delete, and no caching of memory disk like with md(4). From owner-freebsd-current@FreeBSD.ORG Tue Jun 16 11:31:49 2009 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 A08A11065689; Tue, 16 Jun 2009 11:31:49 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [IPv6:2001:4070:101:2::1]) by mx1.freebsd.org (Postfix) with ESMTP id 989368FC24; Tue, 16 Jun 2009 11:31:48 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (localhost [IPv6:::1]) by wojtek.tensor.gdynia.pl (8.14.3/8.14.3) with ESMTP id n5GBVhSG027634; Tue, 16 Jun 2009 13:31:43 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.3/8.14.3/Submit) with ESMTP id n5GBVgcp027631; Tue, 16 Jun 2009 13:31:43 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Tue, 16 Jun 2009 13:31:42 +0200 (CEST) From: Wojciech Puchar To: Ben Kelly In-Reply-To: <4A370DB2.8070403@wanderview.com> Message-ID: References: <4A370DB2.8070403@wanderview.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Tue, 16 Jun 2009 13:06:08 +0000 Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, Ivan Voras Subject: Re: tmpfs experimental? 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, 16 Jun 2009 11:31:50 -0000 > multiple times: > > ianto# mount | grep ' /tmp' > tmpfs on /tmp (tmpfs, local) > ianto# mount /tmp > ianto# mount | grep ' /tmp' > tmpfs on /tmp (tmpfs, local) > tmpfs on /tmp (tmpfs, local) > ianto# umount /tmp > ianto# mount | grep ' /tmp' > tmpfs on /tmp (tmpfs, local) > ianto# it's not only tmpfs. you may mount ufs readonly, or nfs multiple times on the same place. It's not tmpfs specific problem IMHO. There is no checking in mount for that case. From owner-freebsd-current@FreeBSD.ORG Tue Jun 16 13:35:00 2009 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 99F13106566B for ; Tue, 16 Jun 2009 13:35:00 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-out3.uni-muenster.de (ZIVM-OUT3.UNI-MUENSTER.DE [128.176.192.18]) by mx1.freebsd.org (Postfix) with ESMTP id 2EE3B8FC17 for ; Tue, 16 Jun 2009 13:34:59 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) X-IronPort-AV: E=Sophos;i="4.42,228,1243807200"; d="scan'208";a="6058498" Received: from zivmaildisp2.uni-muenster.de (HELO ZIVMAILUSER01.UNI-MUENSTER.DE) ([128.176.188.143]) by zivm-relay3.uni-muenster.de with ESMTP; 16 Jun 2009 15:34:42 +0200 Received: by ZIVMAILUSER01.UNI-MUENSTER.DE (Postfix, from userid 149459) id CAF521B0763; Tue, 16 Jun 2009 15:34:42 +0200 (CEST) Date: Tue, 16 Jun 2009 15:34:42 +0200 (CEST) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Subject: WITHOUT_GAMES=true and /usr/games 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, 16 Jun 2009 13:35:01 -0000 hi there, any reason installworld creates the games dir in /usr even though /etc/src.conf states WITHOUT_GAMES=true. if nothing get's installed into the dir buildworld might just as well not create it. or am i wrong? cheers. From owner-freebsd-current@FreeBSD.ORG Tue Jun 16 13:36:44 2009 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 A9C801065672 for ; Tue, 16 Jun 2009 13:36:44 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from vlakno.cz (77-93-215-190.static.masterinter.net [77.93.215.190]) by mx1.freebsd.org (Postfix) with ESMTP id 6489B8FC14 for ; Tue, 16 Jun 2009 13:36:43 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from localhost (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id E18EF9CB053 for ; Tue, 16 Jun 2009 15:36:38 +0200 (CEST) X-Virus-Scanned: amavisd-new at vlakno.cz Received: from vlakno.cz ([127.0.0.1]) by localhost (lev.vlakno.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 73OZ4KclqWUy for ; Tue, 16 Jun 2009 15:36:36 +0200 (CEST) Received: from vlk.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id AFA549CB118 for ; Tue, 16 Jun 2009 15:36:36 +0200 (CEST) Received: (from rdivacky@localhost) by vlk.vlakno.cz (8.14.3/8.14.3/Submit) id n5GDaaRo059615 for current@freebsd.org; Tue, 16 Jun 2009 15:36:36 +0200 (CEST) (envelope-from rdivacky) Date: Tue, 16 Jun 2009 15:36:36 +0200 From: Roman Divacky To: current@freebsd.org Message-ID: <20090616133636.GA59523@freebsd.org> References: <20090615211123.GA88422@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090615211123.GA88422@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: Subject: Re: [PATCH]: typo in contrib/ipf 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, 16 Jun 2009 13:36:45 -0000 I just commited the fix. it is worth to note that this bug was found by clang. The wider warnings seems to be quite useful to me.... On Mon, Jun 15, 2009 at 11:11:23PM +0200, Roman Divacky wrote: > hi > > I found this typo: > > > Index: tools/ipfcomp.c > =================================================================== > RCS file: /home/ncvs/src/contrib/ipfilter/tools/ipfcomp.c,v > retrieving revision 1.5 > diff -u -r1.5 ipfcomp.c > --- tools/ipfcomp.c 4 Jun 2007 02:54:34 -0000 1.5 > +++ tools/ipfcomp.c 15 Jun 2009 21:10:14 -0000 > @@ -382,7 +382,7 @@ > extern frentry_t *ipf_rules_out_%s[%d];\n", > grp->fg_name, grp->fg_name, outcount); > > - for (g = groups; g != g; g = g->fg_next) > + for (g = groups; g != grp; g = g->fg_next) > if ((strncmp(g->fg_name, grp->fg_name, > FR_GROUPLEN) == 0) && > g->fg_flags == grp->fg_flags) > > can someone review it? darren reed ignored my mail. is it ok > to commit to contrib/ipf ? > > thnx for the answers :) > > roman > From owner-freebsd-current@FreeBSD.ORG Tue Jun 16 13:40:38 2009 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 6D78A1065670; Tue, 16 Jun 2009 13:40:38 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 3DAB78FC1B; Tue, 16 Jun 2009 13:40:38 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id E520C46B7F; Tue, 16 Jun 2009 09:40:37 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id D2D808A072; Tue, 16 Jun 2009 09:40:36 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Tue, 16 Jun 2009 08:12:03 -0400 User-Agent: KMail/1.9.7 References: <1242075474.72992.118.camel@hood.oook.cz> <3c1674c90906151408n6febec56m140b089b694f6e13@mail.gmail.com> <20090616073353.GZ33280@droso.net> In-Reply-To: <20090616073353.GZ33280@droso.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200906160812.04284.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Tue, 16 Jun 2009 09:40:36 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: current@freebsd.org, Doug Rabson , pav@freebsd.org, Kip Macy Subject: Re: pointyhat 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: Tue, 16 Jun 2009 13:40:39 -0000 On Tuesday 16 June 2009 3:33:55 am Erwin Lansing wrote: > On Mon, Jun 15, 2009 at 02:08:17PM -0700, Kip Macy wrote: > > This is from the RPC re-work. I had thought that this was fixed. You > > shouldn't see this on the latest -CURRENT, but Doug will have more > > details. > > Any datepoint when these fixes went in? I upgraded pointyhat last month > exactly to get the latest fixes in, but could be there were more since > then. You want the socket upcall locking changes in 193272 (committed June 1). You will also want subsequent commits to the RPC and NFS code by Rick Macklem to close a few more races. I think Rick still has one other patch that pho@ is stress testing as well. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Jun 16 13:40:38 2009 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 6D78A1065670; Tue, 16 Jun 2009 13:40:38 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 3DAB78FC1B; Tue, 16 Jun 2009 13:40:38 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id E520C46B7F; Tue, 16 Jun 2009 09:40:37 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id D2D808A072; Tue, 16 Jun 2009 09:40:36 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Tue, 16 Jun 2009 08:12:03 -0400 User-Agent: KMail/1.9.7 References: <1242075474.72992.118.camel@hood.oook.cz> <3c1674c90906151408n6febec56m140b089b694f6e13@mail.gmail.com> <20090616073353.GZ33280@droso.net> In-Reply-To: <20090616073353.GZ33280@droso.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200906160812.04284.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Tue, 16 Jun 2009 09:40:36 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: current@freebsd.org, Doug Rabson , pav@freebsd.org, Kip Macy Subject: Re: pointyhat 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: Tue, 16 Jun 2009 13:40:39 -0000 On Tuesday 16 June 2009 3:33:55 am Erwin Lansing wrote: > On Mon, Jun 15, 2009 at 02:08:17PM -0700, Kip Macy wrote: > > This is from the RPC re-work. I had thought that this was fixed. You > > shouldn't see this on the latest -CURRENT, but Doug will have more > > details. > > Any datepoint when these fixes went in? I upgraded pointyhat last month > exactly to get the latest fixes in, but could be there were more since > then. You want the socket upcall locking changes in 193272 (committed June 1). You will also want subsequent commits to the RPC and NFS code by Rick Macklem to close a few more races. I think Rick still has one other patch that pho@ is stress testing as well. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Jun 16 13:40:40 2009 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 59407106564A; Tue, 16 Jun 2009 13:40:40 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 190868FC08; Tue, 16 Jun 2009 13:40:40 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id A5C0446B8A; Tue, 16 Jun 2009 09:40:39 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 93B388A073; Tue, 16 Jun 2009 09:40:38 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Tue, 16 Jun 2009 08:12:48 -0400 User-Agent: KMail/1.9.7 References: <1242075474.72992.118.camel@hood.oook.cz> <4A36B6D8.8000701@FreeBSD.org> <20090616005810.GE1111@egr.msu.edu> In-Reply-To: <20090616005810.GE1111@egr.msu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200906160812.49039.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Tue, 16 Jun 2009 09:40:38 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Adam McDougall Subject: Re: pointyhat 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: Tue, 16 Jun 2009 13:40:40 -0000 On Monday 15 June 2009 8:58:11 pm Adam McDougall wrote: > On Mon, Jun 15, 2009 at 10:02:16PM +0100, Kris Kennaway wrote: > > Pav Lucistnik wrote: > > panic: mtx_lock() of destroyed mutex @ /usr/src/sys/rpc/clnt_vc.c:953 > > cpuid = 2 > > KDB: enter: panic > > [thread pid 0 tid 100029 ] > > Stopped at kdb_enter+0x3d: movq $0,0x3f5fb8(%rip) > > db> bt > > Tracing pid 0 tid 100029 td 0xffffff00018e1000 > > kdb_enter() at kdb_enter+0x3d > > panic() at panic+0x17b > > _mtx_lock_flags() at _mtx_lock_flags+0xc5 > > clnt_vc_soupcall() at clnt_vc_soupcall+0x273 > > sowakeup() at sowakeup+0xf8 > > tcp_do_segment() at tcp_do_segment+0x23c9 > > tcp_input() at tcp_input+0x9ec > > ip_input() at ip_input+0xbc > > ether_demux() at ether_demux+0x1ed > > ether_input() at ether_input+0x171 > > em_rxeof() at em_rxeof+0x201 > > em_handle_rxtx() at em_handle_rxtx+0x4b > > taskqueue_run() at taskqueue_run+0x96 > > taskqueue_thread_loop() at taskqueue_thread_loop+0x3f > > fork_exit() at fork_exit+0x12a > > fork_trampoline() at fork_trampoline+0xe > > --- trap 0, rip = 0, rsp = 0xffffffff240a6d40, rbp = 0 --- > > > > The box is in kdb on serial console for now. May 9 -CURRENT, I think. > > > > This happened again. The trigger was this (^C of a find on a busy > netapp volume with a lot of other concurrent nfs traffic to the same > mountpoint): > > pointyhat# find . -name \*.bz2 -mmin -10 > ^Cnfs server dumpster:/vol/vol4/pointyhat: not responding > nfs server dumpster:/vol/vol4/pointyhat: not responding > nfs server dumpster:/vol/vol4/pointyhat: not responding > nfs server dumpster:/vol/vol4/pointyhat: not responding > nfs server dumpster:/vol/vol4/pointyhat: not responding > nfs server dumpster:/vol/vol4/pointyhat: not responding > nfs server dumpster:/vol/vol4/pointyhat: not responding > nfs server dumpster:/vol/vol4/pointyhat: not responding > nfs server dumpster:/vol/vol4/pointyhat: not responding > nfs server dumpster:/vol/vol4/pointyhat: not responding > nfs server dumpster:/vol/vol4/pointyhat: not responding > nfs server dumpster:/vol/vol4/pointyhat: not responding > load: 4.54 cmd: find 93357 [rpccon] 11.19u 111.62s 0% 4848k > > About 5-10 minutes later the machine panicked. I'll try updating to a > newer -CURRENT. > > Kris > > This sounds like nearly exactly the same symptoms I noticed on > a -current machine a few months ago, I was doing a du on a > nfs mount, decided to ctrl-c it, got the not responding for a > while and a few minutes after the system paniced. I hadn't > had a chance to report it yet but I did find a workaround, > it is stable if I remove "intr" from the NFS mount options. > Hope this helps a little. These should be fixed in the latest HEAD. It would be good to re-enable "intr" and test it before 8.0 is released. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Jun 16 13:44:00 2009 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 30030106564A for ; Tue, 16 Jun 2009 13:44:00 +0000 (UTC) (envelope-from snb@freebsd.org) Received: from smtp-2.sys.kth.se (smtp-2.sys.kth.se [130.237.32.160]) by mx1.freebsd.org (Postfix) with ESMTP id B66C38FC19 for ; Tue, 16 Jun 2009 13:43:59 +0000 (UTC) (envelope-from snb@freebsd.org) Received: from localhost (localhost [127.0.0.1]) by smtp-2.sys.kth.se (Postfix) with ESMTP id 9ADE214C144; Tue, 16 Jun 2009 15:16:15 +0200 (CEST) X-Virus-Scanned: by amavisd-new at kth.se Received: from smtp-2.sys.kth.se ([127.0.0.1]) by localhost (smtp-2.sys.kth.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id d0fWc00VVSnd; Tue, 16 Jun 2009 15:16:10 +0200 (CEST) Received: from pogo4.particle.kth.se (pogo4.particle.kth.se [130.237.34.136]) by smtp-2.sys.kth.se (Postfix) with ESMTP id AB1E714D847; Tue, 16 Jun 2009 15:16:08 +0200 (CEST) Message-ID: <4A379AEE.7080101@freebsd.org> Date: Tue, 16 Jun 2009 15:15:26 +0200 From: Nick Barkas User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: Ivailo Bonev References: <549859.9626.qm@web25007.mail.ukl.yahoo.com> In-Reply-To: <549859.9626.qm@web25007.mail.ukl.yahoo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-current@freebsd.org" Subject: Re: LOR:vfs_bio.c and ufs_dirhash.c 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, 16 Jun 2009 13:44:01 -0000 Ivailo Bonev wrote: > I've installed 8-CURRENT on my HP laptop, snapshot from pub.allbsd.org with HEAD sources from yesterday, but on first startup I see LOR. Everything works ok, though... > Here is log from messages: > Jun 15 17:46:53 ibb kernel: lock order reversal: > Jun 15 17:46:53 ibb kernel: 1st 0xd9537bb0 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2558 > Jun 15 17:46:53 ibb kernel: 2nd 0xc5efd000 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:285 > Jun 15 17:46:53 ibb kernel: KDB: stack backtrace: > Jun 15 17:46:53 ibb kernel: db_trace_self_wrapper(c0c5e1c8,e813a87c,c08b15d5,c08a250b,c0c6100b,...) at db_trace_self_wrapper+0x26 > Jun 15 17:46:53 ibb kernel: kdb_backtrace(c08a250b,c0c6100b,c552acf0,c5530c00,e813a8d8,...) at kdb_backtrace+0x29 > Jun 15 17:46:53 ibb kernel: _witness_debugger(c0c6100b,c5efd000,c0c810bd,c5530c00,c0c80d56,...) at _witness_debugger+0x25 > Jun 15 17:46:53 ibb kernel: witness_checkorder(c5efd000,9,c0c80d56,11d,0,...) at witness_checkorder+0x839 > Jun 15 17:46:53 ibb kernel: _sx_xlock(c5efd000,0,c0c80d56,11d,c6015c3c,...) at _sx_xlock+0x85 > Jun 15 17:46:53 ibb kernel: ufsdirhash_acquire(d9537b50,da6db800,200,da6db81c,e813a9a8,...) at ufsdirhash_acquire+0x35 > Jun 15 17:46:53 ibb kernel: ufsdirhash_add(c6015c3c,e813aa20,81c,e813a994,e813a998,...) at ufsdirhash_add+0x13 > Jun 15 17:46:53 ibb kernel: ufs_direnter(c5ff596c,c6139218,e813aa20,e813ac04,d956c200,...) at ufs_direnter+0x729 > Jun 15 17:46:53 ibb kernel: ufs_mkdir(e813ac28,ead,0,0,e813ab70,...) at ufs_mkdir+0x897 > Jun 15 17:46:53 ibb kernel: VOP_MKDIR_APV(c0d5eec0,e813ac28,e813ac04,e813ab70,0,...) at VOP_MKDIR_APV+0xa5 > Jun 15 17:46:53 ibb kernel: kern_mkdirat(c5cda480,ffffff9c,28528f80,0,1ed,...) at kern_mkdirat+0x268 > Jun 15 17:46:53 ibb kernel: kern_mkdir(c5cda480,28528f80,0,1ed,e813ad2c,...) at kern_mkdir+0x2e > Jun 15 17:46:53 ibb kernel: mkdir(c5cda480,e813acf8,8,c0c5e284,c0d3f240,...) at mkdir+0x29 > Jun 15 17:46:53 ibb kernel: syscall(e813ad38) at syscall+0x2a3 > Jun 15 17:46:53 ibb kernel: Xint0x80_syscall() at Xint0x80_syscall+0x20 > Jun 15 17:46:53 ibb kernel: --- syscall (136, FreeBSD ELF32, mkdir), eip = 0x283063c3, esp = 0xbf4f9d1c, ebp = 0xbf4f9d48 --- > > Mail me, if I can help with anything else... This is known, and shouldn't be anything to worry about because it will not result in a deadlock. See the comment added in r187474: + * WITNESS reports a lock order reversal between the "bufwait" lock + * and the "dirhash" lock. However, this specific reversal will not + * cause a deadlock. To get a deadlock, one would have to lock a + * buffer followed by the dirhash while a second thread locked a + * buffer while holding the dirhash lock. The second order can happen + * under a shared or exclusive vnode lock for the associated directory + * in lookup(). The first order, however, can only happen under an + * exclusive vnode lock (e.g. unlink(), rename(), etc.). Thus, for + * a thread to be doing a "bufwait" -> "dirhash" order, it has to hold + * an exclusive vnode lock. That exclusive vnode lock will prevent + * any other threads from doing a "dirhash" -> "bufwait" order. See also http://sources.zabbadoz.net/freebsd/lor/261.html but note that you are seeing different line numbers in vfs_bio.c and ufs_dirhash.c because those files have been changed since this page was first created back in September. Nick From owner-freebsd-current@FreeBSD.ORG Tue Jun 16 13:46:44 2009 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 DDAFB10656AB for ; Tue, 16 Jun 2009 13:46:44 +0000 (UTC) (envelope-from gabor@FreeBSD.org) Received: from server.mypc.hu (server.mypc.hu [87.229.73.95]) by mx1.freebsd.org (Postfix) with ESMTP id 94D2C8FC0A for ; Tue, 16 Jun 2009 13:46:44 +0000 (UTC) (envelope-from gabor@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) by server.mypc.hu (Postfix) with ESMTP id BA13F14D88E7; Tue, 16 Jun 2009 15:46:42 +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 4z3RpN84OJyJ; Tue, 16 Jun 2009 15:46:41 +0200 (CEST) Received: from [192.168.1.105] (catv-80-98-231-64.catv.broadband.hu [80.98.231.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by server.mypc.hu (Postfix) with ESMTPSA id A420314D79BF; Tue, 16 Jun 2009 15:46:41 +0200 (CEST) Message-ID: <4A37A23C.3050305@FreeBSD.org> Date: Tue, 16 Jun 2009 15:46:36 +0200 From: Gabor Kovesdan User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Alexander Best References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-current@FreeBSD.org Subject: Re: WITHOUT_GAMES=true and /usr/games 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, 16 Jun 2009 13:46:46 -0000 Alexander Best escribió: > hi there, > > any reason installworld creates the games dir in /usr even though > /etc/src.conf states WITHOUT_GAMES=true. if nothing get's installed into the > dir buildworld might just as well not create it. or am i wrong? > My assumption is that the games directory is created by mtree just like the majority of directories we create during installworld. I think there aren't any customizations for mtree calls, it would be complicated and each make variable would be checked in a lot of places while there's no good reason for this, those empty directories make no harm. -- Gabor Kovesdan FreeBSD Volunteer EMAIL: gabor@FreeBSD.org .:|:. gabor@kovesdan.org WEB: http://people.FreeBSD.org/~gabor .:|:. http://kovesdan.org From owner-freebsd-current@FreeBSD.ORG Tue Jun 16 14:10:44 2009 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 72F62106564A; Tue, 16 Jun 2009 14:10:44 +0000 (UTC) (envelope-from ben@wanderview.com) Received: from mail.wanderview.com (mail.wanderview.com [66.92.166.102]) by mx1.freebsd.org (Postfix) with ESMTP id 1925E8FC1C; Tue, 16 Jun 2009 14:10:43 +0000 (UTC) (envelope-from ben@wanderview.com) Received: from [10.76.10.146] ([10.76.10.146]) (authenticated bits=0) by mail.wanderview.com (8.14.3/8.14.3) with ESMTP id n5GEAfis067391 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Jun 2009 14:10:42 GMT (envelope-from ben@wanderview.com) Message-ID: <4A37A7E1.6060905@wanderview.com> Date: Tue, 16 Jun 2009 10:10:41 -0400 From: Ben Kelly User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: Ivan Voras References: <4A370DB2.8070403@wanderview.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: -1.44 () ALL_TRUSTED X-Scanned-By: MIMEDefang 2.64 on 10.76.20.1 Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: tmpfs experimental? 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, 16 Jun 2009 14:10:44 -0000 Ivan Voras wrote: > Ben Kelly wrote: >> I get some slightly unexpected behavior when mount is run >> multiple times: >> >> ianto# mount | grep ' /tmp' >> tmpfs on /tmp (tmpfs, local) >> ianto# mount /tmp >> ianto# mount | grep ' /tmp' >> tmpfs on /tmp (tmpfs, local) >> tmpfs on /tmp (tmpfs, local) >> ianto# umount /tmp >> ianto# mount | grep ' /tmp' >> tmpfs on /tmp (tmpfs, local) > > Sorry, maybe I'm missing the point, but what is wrong with the above > behaviour? AFAIK you are allowed to mount multiple file systems on the > same directory, though it isn't very useful. I guess I just found it confusing because it effectively made files disappear from my file system. This was a surprise to me since I was interpreting fstab as saying "mount a single tmpfs file system here". The only other file system I really had to compare it to was a writable UFS partition which does not exhibit this behavior. Anyway, I have no problem if this is expected behavior. Just mentioning what I thought was an oddity. Overall its been very stable for me. - Ben From owner-freebsd-current@FreeBSD.ORG Tue Jun 16 16:00:42 2009 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 B91E51065675 for ; Tue, 16 Jun 2009 16:00:42 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from host.omnilan.net (host.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id 3BA748FC18 for ; Tue, 16 Jun 2009 16:00:42 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from titan.flintsbach.schmalzbauer.de (titan.flintsbach.schmalzbauer.de [172.21.1.150]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id n5GG0ekR013575 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Jun 2009 18:00:40 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <4A37C1A7.1070801@omnilan.de> Date: Tue, 16 Jun 2009 18:00:39 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Thunderbird 2.0.0.21 (X11/20090425) MIME-Version: 1.0 To: Marcel Moolenaar References: <4A344A9F.5020708@jrv.org> <4A344C67.8000101@jrv.org> In-Reply-To: X-Enigmail-Version: 0.95.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig9DB6B45A8E3C96AAC29C65D2" Cc: Alexander Best , FreeBSD Current , "James R. Van Artsdalen" Subject: Re: `gpart show` and secondary GPT header 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, 16 Jun 2009 16:00:43 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig9DB6B45A8E3C96AAC29C65D2 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Marcel Moolenaar schrieb am 2009-06-14 07:23 (localtime): =2E.. >>>> Jun 13 06:31:42 bigback kernel: GEOM: ad12: the secondary GPT table = is >>>> corrupt or invalid. >>>> Jun 13 06:31:42 bigback kernel: GEOM: ad12: using the primary only -= - >>>> recovery suggested. I'm curious what the correct way to recover is. I also tried dd, but without success. `gpt` had a recover functionality if I remember corretcly. Thanks, -Harry --------------enig9DB6B45A8E3C96AAC29C65D2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAko3wagACgkQLDqVQ9VXb8i7NgCg0RlhIGjAIzwerFEzkyJSRxhV /zwAn1Wo8nq+SqdnjrduUCfjEP3RISFB =nGzJ -----END PGP SIGNATURE----- --------------enig9DB6B45A8E3C96AAC29C65D2-- From owner-freebsd-current@FreeBSD.ORG Tue Jun 16 16:15:30 2009 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 233F81065677; Tue, 16 Jun 2009 16:15:30 +0000 (UTC) (envelope-from erwin@mail.droso.net) Received: from mail.droso.net (koala.ipv6.droso.net [IPv6:2001:6c8:6:c:20d:56ff:fe6f:f935]) by mx1.freebsd.org (Postfix) with ESMTP id 9FC028FC1D; Tue, 16 Jun 2009 16:15:29 +0000 (UTC) (envelope-from erwin@mail.droso.net) Received: by mail.droso.net (Postfix, from userid 1001) id B357B1CC2E; Tue, 16 Jun 2009 18:15:27 +0200 (CEST) Date: Tue, 16 Jun 2009 18:15:27 +0200 From: Erwin Lansing To: John Baldwin Message-ID: <20090616161526.GA33280@droso.net> References: <1242075474.72992.118.camel@hood.oook.cz> <3c1674c90906151408n6febec56m140b089b694f6e13@mail.gmail.com> <20090616073353.GZ33280@droso.net> <200906160812.04284.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ucfHZChuBC0NsER/" Content-Disposition: inline In-Reply-To: <200906160812.04284.jhb@freebsd.org> X-Operating-System: FreeBSD/i386 7.2-STABLE User-Agent: Mutt/1.5.19 (2009-01-05) Cc: Doug Rabson , freebsd-current@freebsd.org, pav@freebsd.org, Kip Macy , current@freebsd.org Subject: Re: pointyhat 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: Tue, 16 Jun 2009 16:15:30 -0000 --ucfHZChuBC0NsER/ Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 16, 2009 at 08:12:03AM -0400, John Baldwin wrote: > On Tuesday 16 June 2009 3:33:55 am Erwin Lansing wrote: > > On Mon, Jun 15, 2009 at 02:08:17PM -0700, Kip Macy wrote: > > > This is from the RPC re-work. I had thought that this was fixed. You > > > shouldn't see this on the latest -CURRENT, but Doug will have more > > > details. > >=20 > > Any datepoint when these fixes went in? I upgraded pointyhat last month > > exactly to get the latest fixes in, but could be there were more since > > then. >=20 > You want the socket upcall locking changes in 193272 (committed June 1). = You=20 > will also want subsequent commits to the RPC and NFS code by Rick Macklem= to=20 > close a few more races. I think Rick still has one other patch that pho@= is=20 > stress testing as well. >=20 OK, in that case we definately need to upgrade, my upgrade was before those. Thanks for the info. Best, -erwin --=20 Erwin Lansing (o_ _o) http://droso.org \\\_\ /_/// The rest is silence <____) (____> erwin@lansing.dk --ucfHZChuBC0NsER/ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iD8DBQFKN8Ueqy9aWxUlaZARAttxAJ4u0XHIcKO6gCNXZF0S/T98RGwsWgCfTJa3 CpAgkjEJwJL2lE+NKfYW4jc= =O1Tm -----END PGP SIGNATURE----- --ucfHZChuBC0NsER/-- From owner-freebsd-current@FreeBSD.ORG Tue Jun 16 16:15:30 2009 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 233F81065677; Tue, 16 Jun 2009 16:15:30 +0000 (UTC) (envelope-from erwin@mail.droso.net) Received: from mail.droso.net (koala.ipv6.droso.net [IPv6:2001:6c8:6:c:20d:56ff:fe6f:f935]) by mx1.freebsd.org (Postfix) with ESMTP id 9FC028FC1D; Tue, 16 Jun 2009 16:15:29 +0000 (UTC) (envelope-from erwin@mail.droso.net) Received: by mail.droso.net (Postfix, from userid 1001) id B357B1CC2E; Tue, 16 Jun 2009 18:15:27 +0200 (CEST) Date: Tue, 16 Jun 2009 18:15:27 +0200 From: Erwin Lansing To: John Baldwin Message-ID: <20090616161526.GA33280@droso.net> References: <1242075474.72992.118.camel@hood.oook.cz> <3c1674c90906151408n6febec56m140b089b694f6e13@mail.gmail.com> <20090616073353.GZ33280@droso.net> <200906160812.04284.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ucfHZChuBC0NsER/" Content-Disposition: inline In-Reply-To: <200906160812.04284.jhb@freebsd.org> X-Operating-System: FreeBSD/i386 7.2-STABLE User-Agent: Mutt/1.5.19 (2009-01-05) Cc: Doug Rabson , freebsd-current@freebsd.org, pav@freebsd.org, Kip Macy , current@freebsd.org Subject: Re: pointyhat 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: Tue, 16 Jun 2009 16:15:30 -0000 --ucfHZChuBC0NsER/ Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 16, 2009 at 08:12:03AM -0400, John Baldwin wrote: > On Tuesday 16 June 2009 3:33:55 am Erwin Lansing wrote: > > On Mon, Jun 15, 2009 at 02:08:17PM -0700, Kip Macy wrote: > > > This is from the RPC re-work. I had thought that this was fixed. You > > > shouldn't see this on the latest -CURRENT, but Doug will have more > > > details. > >=20 > > Any datepoint when these fixes went in? I upgraded pointyhat last month > > exactly to get the latest fixes in, but could be there were more since > > then. >=20 > You want the socket upcall locking changes in 193272 (committed June 1). = You=20 > will also want subsequent commits to the RPC and NFS code by Rick Macklem= to=20 > close a few more races. I think Rick still has one other patch that pho@= is=20 > stress testing as well. >=20 OK, in that case we definately need to upgrade, my upgrade was before those. Thanks for the info. Best, -erwin --=20 Erwin Lansing (o_ _o) http://droso.org \\\_\ /_/// The rest is silence <____) (____> erwin@lansing.dk --ucfHZChuBC0NsER/ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iD8DBQFKN8Ueqy9aWxUlaZARAttxAJ4u0XHIcKO6gCNXZF0S/T98RGwsWgCfTJa3 CpAgkjEJwJL2lE+NKfYW4jc= =O1Tm -----END PGP SIGNATURE----- --ucfHZChuBC0NsER/-- From owner-freebsd-current@FreeBSD.ORG Tue Jun 16 16:16:53 2009 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 D7F9B10656AA; Tue, 16 Jun 2009 16:16:53 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 732028FC30; Tue, 16 Jun 2009 16:16:53 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAMpbN0qDaFvI/2dsb2JhbADVUIQNBQ X-IronPort-AV: E=Sophos;i="4.42,229,1243828800"; d="scan'208";a="36533570" Received: from darling.cs.uoguelph.ca ([131.104.91.200]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 16 Jun 2009 11:47:56 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by darling.cs.uoguelph.ca (Postfix) with ESMTP id 232D9940073; Tue, 16 Jun 2009 11:47:56 -0400 (EDT) X-Virus-Scanned: amavisd-new at darling.cs.uoguelph.ca Received: from darling.cs.uoguelph.ca ([127.0.0.1]) by localhost (darling.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Oew6g4voXVe; Tue, 16 Jun 2009 11:47:55 -0400 (EDT) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by darling.cs.uoguelph.ca (Postfix) with ESMTP id 1E6C8940065; Tue, 16 Jun 2009 11:47:55 -0400 (EDT) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id n5GFndL24355; Tue, 16 Jun 2009 11:49:39 -0400 (EDT) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Tue, 16 Jun 2009 11:49:39 -0400 (EDT) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: Kris Kennaway In-Reply-To: <4A36B6D8.8000701@FreeBSD.org> Message-ID: References: <1242075474.72992.118.camel@hood.oook.cz> <4A36B6D8.8000701@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dfr@FreeBSD.org, pav@FreeBSD.org, kmacy@FreeBSD.org, current@FreeBSD.org Subject: Re: pointyhat 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: Tue, 16 Jun 2009 16:16:54 -0000 On Mon, 15 Jun 2009, Kris Kennaway wrote: > Pav Lucistnik wrote: >> panic: mtx_lock() of destroyed mutex @ /usr/src/sys/rpc/clnt_vc.c:953 >> cpuid = 2 >> KDB: enter: panic >> [thread pid 0 tid 100029 ] >> Stopped at kdb_enter+0x3d: movq $0,0x3f5fb8(%rip) >> db> bt >> Tracing pid 0 tid 100029 td 0xffffff00018e1000 >> kdb_enter() at kdb_enter+0x3d >> panic() at panic+0x17b >> _mtx_lock_flags() at _mtx_lock_flags+0xc5 >> clnt_vc_soupcall() at clnt_vc_soupcall+0x273 >> sowakeup() at sowakeup+0xf8 [stuff snipped] >> The box is in kdb on serial console for now. May 9 -CURRENT, I think. >> > > This happened again. The trigger was this (^C of a find on a busy netapp > volume with a lot of other concurrent nfs traffic to the same mountpoint): > > About 5-10 minutes later the machine panicked. I'll try updating to a newer > -CURRENT. > Although there are a couple of krpc fixes still in the pipe and not yet committed, I think the above panic was fixed by r193437. (June 4, 2009.) If your crash was because it slept while rc_lock was held, that patch isn't committed yet. The other known issue for which a patch isn't committed yet is a reference to a bad pointer in strdup() when called from svc_reg(). Hopefully these will be patched soon, rick From owner-freebsd-current@FreeBSD.ORG Tue Jun 16 16:28:41 2009 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 02A001065670 for ; Tue, 16 Jun 2009 16:28:41 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout022.mac.com (asmtpout022.mac.com [17.148.16.97]) by mx1.freebsd.org (Postfix) with ESMTP id E07D18FC13 for ; Tue, 16 Jun 2009 16:28:40 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from macbook-pro.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp022.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KLC00CARB3SLN20@asmtp022.mac.com> for freebsd-current@freebsd.org; Tue, 16 Jun 2009 09:28:40 -0700 (PDT) Message-id: <19563E0A-3A5A-4B0C-BB89-934A44CF4A82@mac.com> From: Marcel Moolenaar To: Harald Schmalzbauer In-reply-to: <4A37C1A7.1070801@omnilan.de> Date: Tue, 16 Jun 2009 09:28:39 -0700 References: <4A344A9F.5020708@jrv.org> <4A344C67.8000101@jrv.org> <4A37C1A7.1070801@omnilan.de> X-Mailer: Apple Mail (2.935.3) Cc: Alexander Best , FreeBSD Current , "James R. Van Artsdalen" Subject: Re: `gpart show` and secondary GPT header 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, 16 Jun 2009 16:28:41 -0000 On Jun 16, 2009, at 9:00 AM, Harald Schmalzbauer wrote: > Marcel Moolenaar schrieb am 2009-06-14 07:23 (localtime): > ... >>>>> Jun 13 06:31:42 bigback kernel: GEOM: ad12: the secondary GPT >>>>> table is >>>>> corrupt or invalid. >>>>> Jun 13 06:31:42 bigback kernel: GEOM: ad12: using the primary >>>>> only -- >>>>> recovery suggested. > > I'm curious what the correct way to recover is. > I also tried dd, but without success. > `gpt` had a recover functionality if I remember corretcly. Recovery is not yet implemented in gpart. That would be the correct way to recover. And yes, gpt(8) has recovery. Thus, gpt(8) is the right way to recover on -STABLE. FYI, -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Tue Jun 16 19:53:14 2009 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 D8AF9106564A for ; Tue, 16 Jun 2009 19:53:14 +0000 (UTC) (envelope-from studentslava@mail.ru) Received: from mx45.mail.ru (mx45.mail.ru [94.100.176.59]) by mx1.freebsd.org (Postfix) with ESMTP id 8FAD58FC1B for ; Tue, 16 Jun 2009 19:53:14 +0000 (UTC) (envelope-from studentslava@mail.ru) Received: from f31.mail.ru (f31.mail.ru [194.67.57.70]) by mx45.mail.ru (mPOP.Fallback_MX) with ESMTP id B8838E003393 for ; Tue, 16 Jun 2009 22:41:14 +0400 (MSD) Received: from mail by f31.mail.ru with local id 1MGdan-00072G-00 for freebsd-current@freebsd.org; Tue, 16 Jun 2009 22:41:09 +0400 Received: from [89.169.10.109] by win.mail.ru with HTTP; Tue, 16 Jun 2009 22:41:09 +0400 From: =?koi8-r?Q?=F7=D1=DE=C5=D3=CC=C1=D7_=E7=D2=C5=C2=C5=CE=C0=CB=CF=D7?= To: freebsd-current@freebsd.org Mime-Version: 1.0 X-Mailer: mPOP Web-Mail 2.19 X-Originating-IP: [89.169.10.109] Date: Tue, 16 Jun 2009 22:41:09 +0400 X-Mru-Data: 3199:1:1:70:70:0 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit Message-Id: X-Spam: Not detected X-Mras: Ok Subject: ATI X1950Pro behaves oddly with radeon driver and DRI enabled X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: =?koi8-r?Q?=F7=D1=DE=C5=D3=CC=C1=D7_=E7=D2=C5=C2=C5=CE=C0=CB=CF=D7?= List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 19:53:15 -0000 Hello. I'm trying to get working my Sapphire X1950 Pro (512 mb) in xorg. With DRI disabled everything works just fine, except that there's no acceleration. With DRI enabled all I can see is the screen full of garbage - usually it's the picture that was on the screen right before reboot or xorg shutdown with some repetitions of ttys images. But those parts that drawn without help of graphics acceleration - xterm screens for example - are in good condition. Mostly. Their TWM frames are not drawn, along with the headers. If I switch to the console and then back, the screen becomes clean (i.e. pure black background and correctly drawn xterm windows), but is still static - it doesn't change it's content whenewer an accelerated action is performed (i.e. window mowements). Accelerated mouse cursor works just fine though. Logs show no errors. I can even launch glxgears in xterm and it outputs FPS without complains - got somewhat around 6600 FPS, which is much higher than when launched wtith DRI disabled (about 600). I tried several options from the radeon driver man page but without any success (EXA/XAA for example). I also tried the radeonhd driver, but it only makes my display flicker. My system is about one week old, and everything was built from the scratch. Latest snapshots of drm module and radeon driver also didn't help. Hardware: C2D E4500, M/B Gigabyte GA-G33M DS2R (Intel G33 chipset), 2 GB RAM, Dell WFP 3007 (2560x1600 max res - tried 1280x800 without any luck). xorg.conf is the one which generated by "Xorg -configure". Any ideas how to fix it? Regards. Slava. From owner-freebsd-current@FreeBSD.ORG Tue Jun 16 19:58:08 2009 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 113DF106566C for ; Tue, 16 Jun 2009 19:58:08 +0000 (UTC) (envelope-from nakal@web.de) Received: from fmmailgate03.web.de (fmmailgate03.web.de [217.72.192.234]) by mx1.freebsd.org (Postfix) with ESMTP id 958008FC12 for ; Tue, 16 Jun 2009 19:58:07 +0000 (UTC) (envelope-from nakal@web.de) Received: from smtp06.web.de (fmsmtp06.dlan.cinetic.de [172.20.5.172]) by fmmailgate03.web.de (Postfix) with ESMTP id 3E4E810033242; Tue, 16 Jun 2009 21:58:06 +0200 (CEST) Received: from [217.236.10.57] (helo=zelda.local) by smtp06.web.de with asmtp (TLSv1:AES128-SHA:128) (WEB.DE 4.110 #277) id 1MGenF-0006y4-00; Tue, 16 Jun 2009 21:58:05 +0200 Date: Tue, 16 Jun 2009 21:58:03 +0200 From: Martin To: Rick Macklem Message-ID: <20090616215803.4a3aa748@zelda.local> In-Reply-To: References: <4A2504AA.1020406@zedat.fu-berlin.de> <20090603235227.GB15659@hades.panopticon> <20090615173315.1cdb39e1@zelda.local> <20090616000758.714912e6@zelda.local> X-Mailer: Claws Mail 3.7.1 (GTK+ 2.16.2; amd64-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: nakal@web.de X-Sender: nakal@web.de X-Provags-ID: V01U2FsdGVkX18aJL2m/N6CDq4Tsl3GQb9ab3OFfQ6icg56g93E TkXGCriMIK5qGt+lczlyY/O6rZ/yJf7cHNtsFdmWWLvdbhpQ0M I8EOkdhf0= Cc: freebsd-current@freebsd.org Subject: Re: RPCPROG_MNT: RPC: Timed out / receiving NFS error when trying to mount NFS file system after make world 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, 16 Jun 2009 19:58:08 -0000 Am Tue, 16 Jun 2009 15:24:19 -0400 (EDT) schrieb Rick Macklem : > I suspect it's a recent rpc libc and/or networking change. If you know > when your configuration last worked (rNNNNNN or date you took the code > off of head), that might help people figure out what broke it. (nb: > Note that I said "people" and not me. Hi Rick, I'm talking to you, because you seem to try to resolve the problem in this discussion. Of course I know that you are not responsible for everything. I never expect anyone to solve my personal problems with FreeBSD, I just want to at least mention them. I hope, it's still helpful for developers here. > I don't know diddly about rpc > libc or networking stack changes. I just went to: > http://svn.freebsd.org/viewvc/base/ > and then looked at when stuff had changed. > > If you could post to -current again with the last version that worked > vs doesn't work now, hopefully someone will spot the problem, rick I've looked up the date that is encoded in my kernel.old build. FreeBSD 8.0-CURRENT #0: Fri May 15 10:57:37 CEST 2009 I'm sure it worked at this point. Also nfs filesystems that have been already mounted survived the change, but when I started to remount them, the problems have begun to appear, so I suppose that nfsd itself is functioning well, but mountd or rpcbind are somehow affected. The version I'm using now, that shows the issue, is of Jun 14 19:50 CET. I usually update shortly before I compile. It could have been one day earlier that I csup'ed, but I don't think it's more than that. Fortunatelly there are not many changes in libc/rpc in this time interval. -- Martin From owner-freebsd-current@FreeBSD.ORG Tue Jun 16 21:30:11 2009 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 648761065670 for ; Tue, 16 Jun 2009 21:30:11 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-out2.uni-muenster.de (ZIVM-OUT2.UNI-MUENSTER.DE [128.176.192.9]) by mx1.freebsd.org (Postfix) with ESMTP id C01D18FC0A for ; Tue, 16 Jun 2009 21:30:10 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) X-IronPort-AV: E=Sophos;i="4.42,232,1243807200"; d="scan'208";a="216340194" Received: from zivmaildisp2.uni-muenster.de (HELO ZIVMAILUSER04.UNI-MUENSTER.DE) ([128.176.188.143]) by zivm-relay2.uni-muenster.de with ESMTP; 16 Jun 2009 23:30:09 +0200 Received: by ZIVMAILUSER04.UNI-MUENSTER.DE (Postfix, from userid 149459) id 0D72A1B07BA; Tue, 16 Jun 2009 23:30:09 +0200 (CEST) Date: Tue, 16 Jun 2009 23:30:08 +0200 (CEST) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: Gabor Kovesdan Message-ID: In-Reply-To: <4A37A23C.3050305@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@FreeBSD.org Subject: Re: WITHOUT_GAMES=true and /usr/games 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, 16 Jun 2009 21:30:11 -0000 oh. alright. it's ok then i guess. thanks for the hint. alex Gabor Kovesdan schrieb am 2009-06-16: > Alexander Best escribi=F3: > >hi there, > >any reason installworld creates the games dir in /usr even though > >/etc/src.conf states WITHOUT_GAMES=3Dtrue. if nothing get's installed > >into the > >dir buildworld might just as well not create it. or am i wrong? > My assumption is that the games directory is created by mtree just > like the majority of directories we create during installworld. I > think there aren't any customizations for mtree calls, it would be > complicated and each make variable would be checked in a lot of > places while there's no good reason for this, those empty > directories make no harm. > -- > Gabor Kovesdan > FreeBSD Volunteer > EMAIL: gabor@FreeBSD.org .:|:. gabor@kovesdan.org > WEB: http://people.FreeBSD.org/~gabor .:|:. http://kovesdan.org From owner-freebsd-current@FreeBSD.ORG Tue Jun 16 22:10:27 2009 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 B625E106566B for ; Tue, 16 Jun 2009 22:10:27 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.31]) by mx1.freebsd.org (Postfix) with ESMTP id 70B628FC17 for ; Tue, 16 Jun 2009 22:10:27 +0000 (UTC) (envelope-from artemb@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so2473906ywe.13 for ; Tue, 16 Jun 2009 15:10:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=nK0KCXbUjIzNcx6veAniuVvTqUMtxKcJ7L6mBHHx/C8=; b=Hj64q0hjOxqqJ5AUsbTeIiAA8Y7ChDnOUF8To0TnU5Xm/zdZ7QDckJ5K79WOOQOBtK NiaQ8PD7EVwELXnUMk0vUTrotHU/YKEa9bOtKuSN6cX5rFrGjEyuD1jAhuaoTrMkQGBX OjT8YQZO1R6WSNDvrBUvbLsrSQuKHgDQHOEB4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type:content-transfer-encoding; b=GOeBC/kbfMWoyZnz2Nc9ZcuTYC+VO1X4ZBYMu6vzEHkJ0AHdxQynUIRvSUINNx212M pQTHhZdohIJq4Xo/8L4YJJbMGTkNXqJ0aPApkq44kxUc5m8CVklR+URw0fJjiBtYRRrS O73hVqSid7EOMUX3UssEGoXvZuwRuL2Y9ej4s= MIME-Version: 1.0 Sender: artemb@gmail.com Received: by 10.90.33.15 with SMTP id g15mr2986098agg.115.1245190226674; Tue, 16 Jun 2009 15:10:26 -0700 (PDT) Date: Tue, 16 Jun 2009 15:10:26 -0700 X-Google-Sender-Auth: bd0b6012bac4c95c Message-ID: From: Artem Belevich To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Crash in ZFS during vnode sync 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, 16 Jun 2009 22:10:27 -0000 Got a new crash on fresh (as of yesterday) -current/amd64 while the box was pretty much idle. Haven't seen this one before. Fatal trap 12: page fault while in kernel mode cpuid = 3; apic id = 03 fault virtual address = 0xd8 fault code = supervisor write data, page not present instruction pointer = 0x20:0xffffffff80360a35 stack pointer = 0x28:0xffffff842cfc8900 frame pointer = 0x28:0xffffff842cfc8910 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 48 (syncer) [thread pid 48 tid 100076 ] Stopped at _mtx_lock_flags+0x15: lock cmpxchgq %rsi,0x18(%rdi) db> where Tracing pid 48 tid 100076 td 0xffffff0007b0a390 _mtx_lock_flags() at _mtx_lock_flags+0x15 vn_rele_async() at vn_rele_async+0x31 zfs_get_data() at zfs_get_data+0xd0 zil_commit() at zil_commit+0x532 zfs_sync() at zfs_sync+0xa6 sync_fsync() at sync_fsync+0x184 VOP_FSYNC_APV() at VOP_FSYNC_APV+0x4a sync_vnode() at sync_vnode+0x16b sched_sync() at sched_sync+0x1c9 fork_exit() at fork_exit+0x118 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff842cfc8d40, rbp = 0 --- db> show lockedbufs buf at 0xffffff83c11d8550 b_flags = 0xa00200a0 b_error = 0, b_bufsize = 4096, b_bcount = 4096, b_resid = 0 b_bufobj = (0xffffff0012c7a2f0), b_data = 0xffffff83da5fa000, b_blkno = 19214240, b_dep = 0 b_npages = 1, pages(OBJ, IDX, PA): (0xffffff003d5b47d0, 0x0, 0x3c082000) lock type bufwait: EXCL by thread 0xffffff0010e85720 (pid 886) db> show lockedvnods Locked vnodes 0xffffff0012c7a1d8: tag ufs, type VREG usecount 1, writecount 1, refcount 3 mountedhere 0 flags () v_object 0xffffff003d5b47d0 ref 0 pages 1 lock type ufs: EXCL by thread 0xffffff0010e85720 (pid 886) ino 1201240, on dev ad4s1a 0xffffff0007db9ce8: tag syncer, type VNON usecount 1, writecount 0, refcount 2 mountedhere 0 flags () lock type syncer: EXCL by thread 0xffffff0007b0a390 (pid 48) db> show vnodebufs usage: show vnodebufs db> show vnodebufs 0xffffff0007db9ce8 Clean buffers: Dirty buffers: db> show vnodebufs 0xffffff0012c7a1d8 Clean buffers: Dirty buffers: buf at 0xffffff83c11d8550 b_flags = 0xa00200a0 b_error = 0, b_bufsize = 4096, b_bcount = 4096, b_resid = 0 b_bufobj = (0xffffff0012c7a2f0), b_data = 0xffffff83da5fa000, b_blkno = 19214240, b_dep = 0 b_npages = 1, pages(OBJ, IDX, PA): (0xffffff003d5b47d0, 0x0, 0x3c082000) lock type bufwait: EXCL by thread 0xffffff0010e85720 (pid 886) db> bt 886 Tracing pid 886 tid 100183 td 0xffffff0010e85720 cpustop_handler() at cpustop_handler+0x3b ipi_nmi_handler() at ipi_nmi_handler+0x30 trap() at trap+0x195 nmi_calltrap() at nmi_calltrap+0x8 --- trap 0x13, rip = 0xffffffff803605ca, rsp = 0xffffff800001bfe0, rbp = 0xffffff842f52b7f0 --- _mtx_lock_sleep() at _mtx_lock_sleep+0x11a bdwrite() at bdwrite+0x313 ffs_write() at ffs_write+0x634 VOP_WRITE_APV() at VOP_WRITE_APV+0xc6 vn_write() at vn_write+0x188 dofilewrite() at dofilewrite+0x85 kern_writev() at kern_writev+0x60 writev() at writev+0x41 syscall() at syscall+0x28f Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (121, FreeBSD ELF64, writev), rip = 0x80083501c, rsp = 0x7fffffffcaf8, rbp = 0 --- db> bt 48 Tracing pid 48 tid 100076 td 0xffffff0007b0a390 _mtx_lock_flags() at _mtx_lock_flags+0x15 vn_rele_async() at vn_rele_async+0x31 zfs_get_data() at zfs_get_data+0xd0 zil_commit() at zil_commit+0x532 zfs_sync() at zfs_sync+0xa6 sync_fsync() at sync_fsync+0x184 VOP_FSYNC_APV() at VOP_FSYNC_APV+0x4a sync_vnode() at sync_vnode+0x16b sched_sync() at sched_sync+0x1c9 fork_exit() at fork_exit+0x118 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff842cfc8d40, rbp = 0 --- --Artem From owner-freebsd-current@FreeBSD.ORG Wed Jun 17 00:15:33 2009 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 9D183106566B for ; Wed, 17 Jun 2009 00:15:33 +0000 (UTC) (envelope-from shuvaev@physik.uni-wuerzburg.de) Received: from mailrelay.rz.uni-wuerzburg.de (mailrelay.rz.uni-wuerzburg.de [132.187.3.28]) by mx1.freebsd.org (Postfix) with ESMTP id E14138FC19 for ; Wed, 17 Jun 2009 00:15:32 +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 5856DA0790; Wed, 17 Jun 2009 02:15:28 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 4C3A5A078E; Wed, 17 Jun 2009 02:15:28 +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 28D52A078B; Wed, 17 Jun 2009 02:15:28 +0200 (CEST) Received: from wep4035 ([132.187.37.35]) by mail.physik.uni-wuerzburg.de (Lotus Domino Release 8.0.2FP1HF244) with ESMTP id 2009061702152747-10102 ; Wed, 17 Jun 2009 02:15:27 +0200 Received: by wep4035 (sSMTP sendmail emulation); Wed, 17 Jun 2009 02:15:27 +0200 Date: Wed, 17 Jun 2009 02:15:27 +0200 From: Alexey Shuvaev To: Pyun YongHyeon Message-ID: <20090617001527.GB4146@wep4035.physik.uni-wuerzburg.de> References: <20090615044106.GC78415@michelle.cdnetworks.co.kr> <4A36018E.2050301@incunabulum.net> <20090615084850.GD78415@michelle.cdnetworks.co.kr> MIME-Version: 1.0 In-Reply-To: <20090615084850.GD78415@michelle.cdnetworks.co.kr> Organization: Universitaet Wuerzburg User-Agent: Mutt/1.5.19 (2009-01-05) X-MIMETrack: Itemize by SMTP Server on domino1/uni-wuerzburg(Release 8.0.2FP1HF244 | April 7, 2009) at 06/17/2009 02:15:27 AM, Serialize by Router on domino1/uni-wuerzburg(Release 8.0.2FP1HF244 | April 7, 2009) at 06/17/2009 02:15:27 AM, Serialize complete at 06/17/2009 02:15:27 AM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: Bruce Simpson , freebsd-current@freebsd.org Subject: Re: CFT: fxp(4) 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, 17 Jun 2009 00:15:33 -0000 On Mon, Jun 15, 2009 at 05:48:50PM +0900, Pyun YongHyeon wrote: > On Mon, Jun 15, 2009 at 09:08:46AM +0100, Bruce Simpson wrote: > > Pyun YongHyeon wrote: > > >Please test the patch in the following URL if you have fxp(4) > > >hardwares. The patch contains various accumulated fixes for > > >multicast handling, bus_dma fixes, more sane initialization > > >and enhanced lockup detection for buggy controllers. > > > > This is just a note to say that I *have* observed problems with > > multicast setup in fxp(4) -- it seems to need setting up of the > > link-layer hash filter for a group to transmit as well as receive. > > > > I couldn't see this limitation in datasheet. So it could be a > bug in stock fxp(4). > > > This isn't OK, NICs should be able to transmit w/o receive setup, and > > may break normal use-cases (esp. IPv6), I posted to freebsd-net@ about > > this over the past 12 months, but did not have time to reproduce or > > isolate the issue. So a fix is very, very welcome. Thanks for working on > > this. > > So does that patch fixed the issue? I'm not familiar with > multicasting but I did my best to make fxp(4) work on multicasting > environments. fxp(4) hardwares do not allow multicast hash filter > programming when device is not in idle state. So stock fxp(4) > used to rely on Tx completion interrupt to program multicast > filters. I think that is error-prone/complex and fxp(4) can drop > multicat frames until its filter is fully reprogrammed. > My setup on one side: mskc0@pci0:1:0:0: class=0x020000 card=0x81f81043 chip=0x436411ab rev=0x12 hdr=0x00 vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)' device = 'Yukon PCI-E Gigabit Ethernet Controller (88E8056)' class = network subclass = ethernet msk0: flags=8843 metric 0 mtu 1500 options=11a ... media: Ethernet autoselect (100baseTX ) status: active The other side is: fxp0@pci0:2:8:0: class=0x020000 card=0x00011179 chip=0x10318086 rev=0x42 hdr=0x00 vendor = 'Intel Corporation' device = '82801CAM (ICH3) PRO/100 VE (LOM) Network Connection' class = network subclass = ethernet fxp0: flags=8843 metric 0 mtu 1500 options=2009 ... media: Ethernet autoselect (100baseTX ) status: active Both sides: ~> uname -a FreeBSD wep4035 8.0-CURRENT FreeBSD 8.0-CURRENT #1 r194030M: Thu Jun 11 21:12:19 CEST 2009 root@wep4035:/usr/obj/usr/src/sys/GENERIC amd64 The command used to receive packets (thanks to gnn): ./mctest -i msk0/fxp0 -m 0 -s 1024 -n 10000 -r to transmit: ./mctest -i fxp0/msk0 -M 1 -s 1024 -n 10000 -t 1 The switch is CentreCOM FS709FC which was disconnected from the uplink during the tests. That means that the network was still idle other than test packets. Looks like everything is working both with and without the patch. However it seems I understand too little about multicasting to perform sensible tests. Do I need any route add 224.0.0.0/4 -interface fxp0/msk0 commands? How long should I wait before exchanging multicast transmitter with receiver? ... ftp upload/download are working also good with/without the patch. Alexey. From owner-freebsd-current@FreeBSD.ORG Wed Jun 17 00:34:26 2009 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 57CDD106564A; Wed, 17 Jun 2009 00:34:26 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: from mail-qy0-f173.google.com (mail-qy0-f173.google.com [209.85.221.173]) by mx1.freebsd.org (Postfix) with ESMTP id E1F928FC24; Wed, 17 Jun 2009 00:34:25 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: by qyk3 with SMTP id 3so6284815qyk.3 for ; Tue, 16 Jun 2009 17:34:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:in-reply-to:references:x-mailer:mime-version :content-type; bh=kitMmyazbIZU3ynb3GuP2oKdxmgt1Meodyd1OFCnX1M=; b=COyxB9ct+Ze7Gj+WAhrDhPuidFJqfCrL1kU54ZCfW779EhjRF6UvT+CEXPPjeBtpWF 0D40YpQhTWmnpe4HtqorCTIyNaobnu1mq9FXkmzBTlhsJPeLlFBCYx98Lx0M9GDwJnI6 nrXuRVzQPZPEHdJDkvv8EOr/F6cJqYCM8ou+8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type; b=Giis/5KOrpqBo8wsamv8AWmGRHxJbC6tLSXEcQ6eG4E5ru+BSMVdbOCZDQgZZN20sX 32DNqEGOScmWCVaJL9UMbUxc7QyEzXIq2MZVtKekhRLeSiDaQlfBpNx9PyJczvdsiDOW kGrH+3DMEWsdHMCq9GJxqu39gadqOIkQIYeZg= Received: by 10.224.29.2 with SMTP id o2mr9087890qac.102.1245197286024; Tue, 16 Jun 2009 17:08:06 -0700 (PDT) Received: from kan.dnsalias.net (c-98-217-224-113.hsd1.ma.comcast.net [98.217.224.113]) by mx.google.com with ESMTPS id 6sm223875qwd.32.2009.06.16.17.08.04 (version=SSLv3 cipher=RC4-MD5); Tue, 16 Jun 2009 17:08:05 -0700 (PDT) Date: Tue, 16 Jun 2009 20:07:56 -0400 From: Alexander Kabaev To: venki kaps Message-ID: <20090616200756.70206fda@kan.dnsalias.net> In-Reply-To: <6d53329e0906160229j2fdba518h84b13652153a32f6@mail.gmail.com> References: <6d53329e0906160229j2fdba518h84b13652153a32f6@mail.gmail.com> X-Mailer: Claws Mail 3.7.1 (GTK+ 2.16.2; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/rwovTwY3y=_ftDqWww523R9"; protocol="application/pgp-signature" Cc: freebsd-arm@freebsd.org, freebsd-current@freebsd.org, netbsd-users@netbsd.org Subject: Re: [libc] dlclose gives "invalid shared object handle" without pthread combination. 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, 17 Jun 2009 00:34:26 -0000 --Sig_/rwovTwY3y=_ftDqWww523R9 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi, I do not think we on FreeBSD support NetBSD rtld with our pthread libraries, unless you already implemented all the necessary glue. The interface between threading library and rtld is rather intimate and tricky to get right. You provide no code to look at nor explicitly mention what OS and what version you are running your test on (FreeBSD?), I think you are on your own. Furthermore, your claim on 'correct' constructor/destructor is wrong given the sample code provided by NetBSD PR. Some more comments are inline. On Tue, 16 Jun 2009 14:59:36 +0530 venki kaps wrote: > Hi, >=20 > I am using the NetBSD implementation of rtld(src/libexec/ld.elf_so/) > for ARM/MIPS. >=20 > I have C++ static constructor/destructor issue with my rtld. >=20 > Problem Report: > "ld.elf_so does not execute .init/.fini functions in order" and [libc] > dlclose gives > "invalid shared object handle" when called through the fini function > of another module. >=20 > The similar NetBSD/freeBSD issues are found from the following > References: [1] http://gnats.netbsd.org/37347 > [2] http://updraft3.jp.freebsd.org/cgi/query-pr.cgi?pr=3Dkern/42956 >=20 > The above issues are already commited in NetBSD-5-0-RELEASE. >=20 > I have ported NetBSD-5-0-RELEASE rtld and tested Ref[1] provided > static constructor/destructor test and did not find any issues > with shared pthread combination but noticed [libc] dlclose gives > "invalid shared object handle" without pthread combination. >=20 > The static constructor/destructor test results: >=20 > It should be : > -------------- >=20 > $ ./foobar > foo_ctor > bar_ctor > tar_ctor > main_ctor > dep1_ctor > dep2_ctor > dll_ctor > dll_dtor > dep2_dtor > dep1_dtor > main_dtor > tar_dtor > bar_dtor > foo_dtor Given the test in Ref[1], both constructor and destructor orders are wrong above. libdep1 depends on libdep2, so dep2_ctor should be invoked before dep1_ctor and consequently dep2_dtor should be invoked after dep1_dtor. =20 > While currently I get: > ---------------------- >=20 > with pthreads: >=20 > $ ./foobar > foo_ctor > bar_ctor > tar_ctor > main_ctor > dep1_ctor > dep2_ctor > dll_ctor > dll_dtor > dep2_dtor > dep1_dtor > main_dtor > tar_dtor > bar_dtor > foo_dtor >=20 > without pthreads: >=20 > $ ./foobar > foo_ctor > bar_ctor > tar_ctor > main_ctor > dep1_ctor > dep2_ctor > dll_ctor > dll_dtor > dep2_dtor > dep1_dtor > main_dtor > tar_dtor > bar_dtor > foo_dtor > Invalid shared object handle 0xbdbed400 Again, given the sample code from NetBSD PR cannot possibly print this message because it never even calls dlerr(). You must be looking at some other code and unless you provide it, understanding your problem and fixing it is next to impossible. Said that, thanks for pointing the FreeBSD PR to me. I will commit the fix for the problem described here shortly. =20 > This gives a "invalid shared object handle" message > because the refcount field (obj->dl_refcount) for the handle is zero. >=20 > I have little bit confused about dlclose destructor > with/without pthreads. >=20 > I have some queries: > 1) Is it required any changes apart from the > NetBSD-5-0-RELEASE/{Ref[1],[2]}? 2) Are any changes required in > thread-stub? >=20 > Could anyone provide any inputs to the my issue? >=20 > Thanks in advance. >=20 > Thanks & Regards, > Venkappa --=20 Alexander Kabaev --Sig_/rwovTwY3y=_ftDqWww523R9 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iD8DBQFKODPhQ6z1jMm+XZYRAuCjAKC94cJ7t9l68OMZoigdjbyLNp2t5QCg4Xzh gpe/B6QrwPZFZU9lEKejMtg= =vhtp -----END PGP SIGNATURE----- --Sig_/rwovTwY3y=_ftDqWww523R9-- From owner-freebsd-current@FreeBSD.ORG Wed Jun 17 04:24:49 2009 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 278DB1065674; Wed, 17 Jun 2009 04:24:49 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id C854F8FC19; Wed, 17 Jun 2009 04:24:48 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Subject:Message-ID:Reply-To:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender; b=dSYd6N+3cP+bV2i0yCsDOBrxqcI/XOACtGZvEpIx0DCyVA+S9s+4P96hDxFsFJRGgAMl/JhbpKv/ViZfnesJkGIuh0t3wwyZkMVwjGC0/CpmpCgsQJ5vpS5Wk2s1u/b/hDKmA7EvirmQ2WauIzMQyQNIYsJJ1UQIOSL+APQRnfU=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1MGmhb-000643-If; Wed, 17 Jun 2009 08:24:47 +0400 Date: Wed, 17 Jun 2009 08:24:44 +0400 From: Eygene Ryabinkin To: Marius Strobl Message-ID: References: <20090602222445.2F6017302F@freebsd-current.sentex.ca> <20090603200013.GB43137@alchemy.franken.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090603200013.GB43137@alchemy.franken.de> Sender: rea-fbsd@codelabs.ru Cc: current@freebsd.org, rwatson@freebsd.org, FreeBSD Tinderbox , sparc64@freebsd.org, kmacy@freebsd.org Subject: Re: [head tinderbox] failure on sparc64/sun4v X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rea-fbsd@codelabs.ru List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 04:24:50 -0000 Marius, *, good day. Wed, Jun 03, 2009 at 10:00:13PM +0200, Marius Strobl wrote: > On Wed, Jun 03, 2009 at 02:15:55PM +0400, Eygene Ryabinkin wrote: > > And while I am here: definition for PCPU_NAME_LEN seems to be wrong. > > It is intended to fit ("CPU %d", cpuid) where cpuid <= MAXCPU. If this > > is correct, then (sys/sys/pcpu.h, line 57) > > > > 1. sizeof(__XSTRING(MAXCPU) + 1) is a typo: typeof(__XSTRING(...) + 1) > > is 'char *', so sizeof() will return the size of the pointer, not > > the size of the string contents. The proper expression should be > > 'sizeof(__XSTRING(MAXCPU)) + 1'. > > > > 2. one should not add one, but substract it: sizeof() accounts for the > > trailing '\0' and we have two sizeof's, so the size of one '\0' > > should be substracted -- this will give the maximal string buffer > > length for CPU with its number, no less, no more. > > > > Does the attached patch looks sane? > > diff --git a/sys/sys/pcpu.h b/sys/sys/pcpu.h > > index 63c3fa3..98705eb 100644 > > --- a/sys/sys/pcpu.h > > +++ b/sys/sys/pcpu.h > > @@ -54,7 +54,7 @@ struct rm_queue { > > struct rm_queue* volatile rmq_prev; > > }; > > > > -#define PCPU_NAME_LEN (sizeof("CPU ") + sizeof(__XSTRING(MAXCPU) + 1)) > > +#define PCPU_NAME_LEN (sizeof("CPU ") + sizeof(__XSTRING(MAXCPU)) - 1) > > > > > > /* > > This looks correct to me. Jeff? Any updates on this matter? May be someone else will be able to review the patch? Kip, Robert? -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # From owner-freebsd-current@FreeBSD.ORG Wed Jun 17 04:26:31 2009 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 9A9DD1065698; Wed, 17 Jun 2009 04:26:31 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id 4A85E8FC21; Wed, 17 Jun 2009 04:26:31 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Subject:Message-ID:Reply-To:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender; b=DCdZronzZtGaZIYDuIjbs3Qg+6BnUtcf7ygBpKGBTDddB2XIo/CrCMB4zhHULKFUDJc64SNB8xllqlsLm7JQZUNYme4d7K1/G8PHlehOTIAnLbkWXTXnDoMUUJZlXUZQketPuAE/i83G+G9cewX3y55XmSVfulstLeMXSwuM9RQ=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1MGmjG-0006Eq-Dg; Wed, 17 Jun 2009 08:26:30 +0400 Date: Wed, 17 Jun 2009 08:26:27 +0400 From: Eygene Ryabinkin To: John Baldwin Message-ID: References: <20090602222445.2F6017302F@freebsd-current.sentex.ca> <20090603194453.GA43137@alchemy.franken.de> <200906040802.27057.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: rea-fbsd@codelabs.ru Cc: freebsd-current@freebsd.org, rwatson@freebsd.org, kmacy@freebsd.org, Marius Strobl Subject: Re: [head tinderbox] failure on sparc64/sun4v X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rea-fbsd@codelabs.ru List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 04:26:31 -0000 John, good day. Fri, Jun 05, 2009 at 10:29:56AM +0400, Eygene Ryabinkin wrote: > Thu, Jun 04, 2009 at 08:02:25AM -0400, John Baldwin wrote: > > On Wednesday 03 June 2009 11:26:17 pm Eygene Ryabinkin wrote: > > > Yes, seems like so. John, may be we can eliminate the only reference to > > > KTR_PERCPU from sys/sys/pcpu.h? Both 'struct pcpu' fields seem to be > > > unused (grep'ped -CURRENT sources). > > > > Yes. > > Fine. Then the attached patch should remove the stuff. Could the mentioned KTR_PERCPU stuff be removed or you think that it is better to leave it "as is"? Thanks! -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # From owner-freebsd-current@FreeBSD.ORG Wed Jun 17 05:04:45 2009 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 D63171065670; Wed, 17 Jun 2009 05:04:45 +0000 (UTC) (envelope-from taguchi@iij.ad.jp) Received: from omgo.iij.ad.jp (mo30.iij.ad.jp [202.232.30.71]) by mx1.freebsd.org (Postfix) with ESMTP id 844838FC24; Wed, 17 Jun 2009 05:04:45 +0000 (UTC) (envelope-from taguchi@iij.ad.jp) DKIM-Signature: v=1;a=rsa-sha256;c=relaxed/simple;d=iij.ad.jp;h=Message-ID: Date:From:To:Cc:Subject:References:In-Reply-To:MIME-Version:Content-Type: Content-Transfer-Encoding;i=taguchi@iij.ad.jp;s=omgo1;t=1245214196;x= 1246423796; bh=qamxixBj19NBADf+gTtYACEbsVRH5iJ2fZJhVILANKI=; b=e5BUdXvORiAIij1f CuQMpT6LG3IU0iEr2tLxzo7CSw24OGn/ezEHmo+z80HbH86omEmT8e4a+unEKU1v1X+zIBYTFYBLO ufIgri4XfA0Lx5nHLFFUoyo0dLeRxH0ZQdKWctk+oL/dl6IjzV4FWDne5fPDFBIY1jl9gXlvGEVeT E=; Received: by omgo.iij.ad.jp (mo30) id n5H4nuNo005690; Wed, 17 Jun 2009 13:49:56 +0900 Received: by taguchi-d.tohoku.iiji.jp (Postfix, from userid 80) id EDBA41173C22; Wed, 17 Jun 2009 13:49:54 +0900 (JST) Received: from taguchi-d (taguchi-d [192.168.145.42]) by taguchi-d.tohoku.iiji.jp (Horde Framework) with HTTP; Wed, 17 Jun 2009 13:49:54 +0900 Message-ID: <20090617134954.131956w1zmh4czci@taguchi-d.tohoku.iiji.jp> X-Priority: 3 (Normal) Date: Wed, 17 Jun 2009 13:49:54 +0900 From: =?ISO-2022-JP?B?GyRCRUQ4fRsoQg==?= =?ISO-2022-JP?B?GyRCNSMbKEI=?= To: Martin Wilke References: <20090611194557.GC98175@bsdcrew.de> In-Reply-To: <20090611194557.GC98175@bsdcrew.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) 4.3.3 / FreeBSD-7.2 X-Mailman-Approved-At: Wed, 17 Jun 2009 05:31:44 +0000 Cc: ports@FreeBSD.org, freebsd-emulation@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: [Call For Testing] VirtualBox for FreeBSD! take 6 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, 17 Jun 2009 05:04:46 -0000 Hi, I've test it on my FreeBSD-7.2p1 amd64 box. I got "2 VirtualBox processes"-probrem. but I'd kill 2nd process, then it works fine. So I'd tried to boot FreeBSD-7.2-RELEASE-amd64 installer DVD. loader work fine. but try to launch /stand/sysinstall, it does not work. it stopped ;-( installer's dialogue does not displaied. i386 version was work fine. Thanks. ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From owner-freebsd-current@FreeBSD.ORG Wed Jun 17 05:04:46 2009 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 D99441065673; Wed, 17 Jun 2009 05:04:45 +0000 (UTC) (envelope-from taguchi@iij.ad.jp) Received: from omgo.iij.ad.jp (mo30.iij.ad.jp [202.232.30.71]) by mx1.freebsd.org (Postfix) with ESMTP id 8A6138FC25; Wed, 17 Jun 2009 05:04:45 +0000 (UTC) (envelope-from taguchi@iij.ad.jp) DKIM-Signature: v=1;a=rsa-sha256;c=relaxed/simple;d=iij.ad.jp;h=Message-ID: Date:From:To:Cc:Subject:References:In-Reply-To:MIME-Version:Content-Type: Content-Transfer-Encoding;i=taguchi@iij.ad.jp;s=omgo1;t=1245214211;x= 1246423811; bh=gWOsgvqhndlG8BjASBontxtlVDc15ORPUqsxdmN2UuY=; b=Jy15lYA1vnoeJXDC B6cKTVlglxnPyc1i17gFedo0KOvjSay3J6clvDc5616T9TSKAaFwTr6may/8m9sseCpV6AYjtbDoa KaryUaIo1NH5W7057gW4iHtALCJMtu3h5HBpJmjRA9H1yMVoTSJyKg6+hN4uRJW2dQuEMLAyBoQnd M=; Received: by omgo.iij.ad.jp (mo30) id n5H4oBKP005727; Wed, 17 Jun 2009 13:50:11 +0900 Received: by taguchi-d.tohoku.iiji.jp (Postfix, from userid 80) id 14BD41173C22; Wed, 17 Jun 2009 13:50:11 +0900 (JST) Received: from taguchi-d (taguchi-d [192.168.145.42]) by taguchi-d.tohoku.iiji.jp (Horde Framework) with HTTP; Wed, 17 Jun 2009 13:50:11 +0900 Message-ID: <20090617135011.996334oa95kwtpfn@taguchi-d.tohoku.iiji.jp> X-Priority: 3 (Normal) Date: Wed, 17 Jun 2009 13:50:11 +0900 From: =?ISO-2022-JP?B?GyRCRUQ4fRsoQg==?= =?ISO-2022-JP?B?GyRCNSMbKEI=?= To: Martin Wilke References: <20090611194557.GC98175@bsdcrew.de> In-Reply-To: <20090611194557.GC98175@bsdcrew.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) 4.3.3 / FreeBSD-7.2 X-Mailman-Approved-At: Wed, 17 Jun 2009 05:31:58 +0000 Cc: ports@FreeBSD.org, freebsd-emulation@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: [Call For Testing] VirtualBox for FreeBSD! take 6 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, 17 Jun 2009 05:04:47 -0000 Martin Wilke $B$5$s$O8@$o$l$^$7$?!'(B > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Huhu, > > Yes we life and that's good :-). > Changes: > > - Fix build error when compiling in debug mode on FreeBSD HEAD > - SemEvent?-r0drv/FreeBSD: Don't use tvtohz for an infinite timeout. > - Some FreeBSD relate typos > - Enable shared OpenGL service. Completely untested due to lack of > appropriate hardware but it compiles at least > - Add support for shared clipboards. Requires libXt > - FreeBSD: Implement preemption API for guest SMP and enable > it (slightly tested). Add neccessary RTMP* methods in userspace > for the frontends to detect the number of CPUs > - Runtime/semevent-r0drv-freebsd: Use a sleeping mutex > instead of a spinlock to fix the problems users are seeing > (assertions with debugging enabled) while still being able > to run on 100Hz hosts. No problems detected so far and Solaris > doesn't use a spin mutex in this code too so it shouldn't do > any harm (keeping fingers crossed)space for the frontends to > detect the number of CPUs > - Add support for curl > - Add VBoxSharedClipboard > > Ports Changes; > - Force guestadditions version to 2.2.4 > - Removed Qt3 include replacements (already upstream) > - Removed cosmetic X11 include path patch > > Please make SURE, your world and kernel is in sync and you've read > the pkg-messages. Also please unload the kernel module before > you update the port ;-). > > Many thx to all Vbox Devs, All supporters, my nice team! :-) > > http://people.freebsd.org/~miwi/vbox/virtualbox_6.tgz > > Happy Testing! > > - - Martin > > - -- > > +-----------------------+-------------------------------+ > | PGP : 0xB1E6FCE9 | Jabber : miwi(at)BSDCrew.de | > | Skype : splash_111 | Mail : miwi(at)FreeBSD.org | > +-----------------------+-------------------------------+ > | Mess with the Best, Die like the Rest! | > +-----------------------+-------------------------------+ > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.11 (FreeBSD) > > iEYEARECAAYFAkoxXvUACgkQdLJIhLHm/OmHHQCcCvJ6EKNehym1siBuQICX+7+l > i2sAn0InwBQW7jf+l/PqjIM/BR/g3qhi > =hDW+ > -----END PGP SIGNATURE----- > _______________________________________________ > freebsd-ports@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org" > ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From owner-freebsd-current@FreeBSD.ORG Wed Jun 17 10:45:04 2009 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 A2BD31065674; Wed, 17 Jun 2009 10:45:04 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from dhcp-172-16-23-160.lon.corp.google.com (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id CD6E28FC1D; Wed, 17 Jun 2009 10:45:03 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <4A38C92F.7050809@FreeBSD.org> Date: Wed, 17 Jun 2009 11:45:03 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Pawel Jakub Dawidek , Kip Macy , FreeBSD Current , Rick Macklem Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: destroyed NFS exported filesystems not removed from /etc/zfs/exports 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, 17 Jun 2009 10:45:04 -0000 mountd was failing to start after an upgrade, with lots of log entries like: Jun 17 10:19:22 pointyhat mountd[855]: bad exports list line /a/portbuild/i386/20090421213917 Jun 17 10:19:22 pointyhat mountd[855]: bad exports list line /a/portbuild/i386/7-exp/builds/20090422073914/src Jun 17 10:19:22 pointyhat mountd[855]: bad exports list line /a/portbuild/i386/8-exp/builds/20080814181849/ports These came from /etc/zfs/exports, and refer to filesystems that used to exist & were exported, but which have been destroyed. These were not cleaned up at destroy time. zfs unshare -a didn't clean this file up either, I had to remove it and recreate. Also, mountd was treating these as fatal errors at runtime and failing to start. I think this is a recent change in mountd, since this used to work even with the stale entries (the 200808 filesystem was destroyed in 2008, and mountd has started correctly after numerous reboots until the upgrade I just did from a May 9 world+kernel). Kris From owner-freebsd-current@FreeBSD.ORG Wed Jun 17 12:29:40 2009 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 CD1A61065673; Wed, 17 Jun 2009 12:29:40 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 9E0248FC14; Wed, 17 Jun 2009 12:29:40 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 52A9846B8E; Wed, 17 Jun 2009 08:29:40 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 6477E8A072; Wed, 17 Jun 2009 08:29:39 -0400 (EDT) From: John Baldwin To: rea-fbsd@codelabs.ru Date: Wed, 17 Jun 2009 08:13:34 -0400 User-Agent: KMail/1.9.7 References: <20090602222445.2F6017302F@freebsd-current.sentex.ca> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200906170813.34660.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Wed, 17 Jun 2009 08:29:39 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: freebsd-current@freebsd.org, rwatson@freebsd.org, kmacy@freebsd.org, Marius Strobl Subject: Re: [head tinderbox] failure on sparc64/sun4v 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, 17 Jun 2009 12:29:41 -0000 On Wednesday 17 June 2009 12:26:27 am Eygene Ryabinkin wrote: > John, good day. > > Fri, Jun 05, 2009 at 10:29:56AM +0400, Eygene Ryabinkin wrote: > > Thu, Jun 04, 2009 at 08:02:25AM -0400, John Baldwin wrote: > > > On Wednesday 03 June 2009 11:26:17 pm Eygene Ryabinkin wrote: > > > > Yes, seems like so. John, may be we can eliminate the only reference to > > > > KTR_PERCPU from sys/sys/pcpu.h? Both 'struct pcpu' fields seem to be > > > > unused (grep'ped -CURRENT sources). > > > > > > Yes. > > > > Fine. Then the attached patch should remove the stuff. > > Could the mentioned KTR_PERCPU stuff be removed or you think that > it is better to leave it "as is"? I removed it from HEAD already after your previous e-mail (at least from ). Was there something else you had in mind? -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Jun 17 14:58:13 2009 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 2F54C106564A; Wed, 17 Jun 2009 14:58:13 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id CE71B8FC1B; Wed, 17 Jun 2009 14:58:12 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Subject:Message-ID:Reply-To:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender; b=WD3p3V5+m7tcy+Yl0ujl/AJ46LsZ1wS/HPMTnoYRNKYdskzx431XoRhjJuff2weodB7CuY8ORozphkl3gM5o6/WUmN9tC3We/FIuFGtiuyLajO2OdGghg0glu9GqnG0uBD9dpQT0aOhfbFHnMK0uxyF01pWSYrIN5PnGuyfBkRw=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1MGwaZ-0004h6-It; Wed, 17 Jun 2009 18:58:11 +0400 Date: Wed, 17 Jun 2009 18:58:09 +0400 From: Eygene Ryabinkin To: John Baldwin Message-ID: References: <20090602222445.2F6017302F@freebsd-current.sentex.ca> <200906170813.34660.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200906170813.34660.jhb@freebsd.org> Sender: rea-fbsd@codelabs.ru Cc: freebsd-current@freebsd.org, rwatson@freebsd.org, kmacy@freebsd.org, Marius Strobl Subject: Re: [head tinderbox] failure on sparc64/sun4v X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rea-fbsd@codelabs.ru List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 14:58:13 -0000 Wed, Jun 17, 2009 at 08:13:34AM -0400, John Baldwin wrote: > I removed it from HEAD already after your previous e-mail (at least > from ). Was there something else you had in mind? Uhm, I'm terribly sorry -- this will teach me to look at the commits before writing reminders. Once again, sorry. -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # From owner-freebsd-current@FreeBSD.ORG Wed Jun 17 15:21:00 2009 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 B24B01065670; Wed, 17 Jun 2009 15:21:00 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 22F348FC12; Wed, 17 Jun 2009 15:20:59 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAEimOEqDaFvI/2dsb2JhbADVY4QIBQ X-IronPort-AV: E=Sophos;i="4.42,236,1243828800"; d="scan'208";a="36650170" Received: from darling.cs.uoguelph.ca ([131.104.91.200]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 17 Jun 2009 11:20:59 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by darling.cs.uoguelph.ca (Postfix) with ESMTP id 2F823940065; Wed, 17 Jun 2009 11:20:59 -0400 (EDT) X-Virus-Scanned: amavisd-new at darling.cs.uoguelph.ca Received: from darling.cs.uoguelph.ca ([127.0.0.1]) by localhost (darling.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fX6mRx212yYe; Wed, 17 Jun 2009 11:20:58 -0400 (EDT) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by darling.cs.uoguelph.ca (Postfix) with ESMTP id 2E247940063; Wed, 17 Jun 2009 11:20:58 -0400 (EDT) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id n5HFMkp11991; Wed, 17 Jun 2009 11:22:46 -0400 (EDT) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Wed, 17 Jun 2009 11:22:46 -0400 (EDT) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: Kris Kennaway In-Reply-To: <4A38C92F.7050809@FreeBSD.org> Message-ID: References: <4A38C92F.7050809@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD Current , Pawel Jakub Dawidek , Kip Macy Subject: Re: destroyed NFS exported filesystems not removed from /etc/zfs/exports 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, 17 Jun 2009 15:21:01 -0000 On Wed, 17 Jun 2009, Kris Kennaway wrote: > mountd was failing to start after an upgrade, with lots of log entries like: > > Jun 17 10:19:22 pointyhat mountd[855]: bad exports list line > /a/portbuild/i386/20090421213917 > Jun 17 10:19:22 pointyhat mountd[855]: bad exports list line > /a/portbuild/i386/7-exp/builds/20090422073914/src > Jun 17 10:19:22 pointyhat mountd[855]: bad exports list line > /a/portbuild/i386/8-exp/builds/20080814181849/ports > > These came from /etc/zfs/exports, and refer to filesystems that used to exist > & were exported, but which have been destroyed. These were not cleaned up at > destroy time. > > zfs unshare -a didn't clean this file up either, I had to remove it and > recreate. > > Also, mountd was treating these as fatal errors at runtime and failing to > start. I think this is a recent change in mountd, since this used to work > even with the stale entries (the 200808 filesystem was destroyed in 2008, and > mountd has started correctly after numerous reboots until the upgrade I just > did from a May 9 world+kernel). > Well, the most recent change pre-May 9 done to mountd.c was on Nov. 3. It involved adding security flavors to the exports. (http://svn.freebsd.org/viewc/base/ is your friend:-) I can't think of how that might have broken things, but I don't know diddly about zfs. rick From owner-freebsd-current@FreeBSD.ORG Wed Jun 17 15:33:35 2009 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 3AA5E106566C for ; Wed, 17 Jun 2009 15:33:35 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id BF35C8FC1A for ; Wed, 17 Jun 2009 15:33:34 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAMepOEqDaFvI/2dsb2JhbADVc4QIBQ X-IronPort-AV: E=Sophos;i="4.42,236,1243828800"; d="scan'208";a="38648054" Received: from darling.cs.uoguelph.ca ([131.104.91.200]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 17 Jun 2009 11:33:33 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by darling.cs.uoguelph.ca (Postfix) with ESMTP id A38AE94006C; Wed, 17 Jun 2009 11:33:33 -0400 (EDT) X-Virus-Scanned: amavisd-new at darling.cs.uoguelph.ca Received: from darling.cs.uoguelph.ca ([127.0.0.1]) by localhost (darling.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zwDmV65xW-Ym; Wed, 17 Jun 2009 11:33:32 -0400 (EDT) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by darling.cs.uoguelph.ca (Postfix) with ESMTP id 725CD940062; Wed, 17 Jun 2009 11:33:31 -0400 (EDT) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id n5HFZJS14076; Wed, 17 Jun 2009 11:35:19 -0400 (EDT) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Wed, 17 Jun 2009 11:35:19 -0400 (EDT) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: Martin In-Reply-To: <20090616215803.4a3aa748@zelda.local> Message-ID: References: <4A2504AA.1020406@zedat.fu-berlin.de> <20090603235227.GB15659@hades.panopticon> <20090615173315.1cdb39e1@zelda.local> <20090616000758.714912e6@zelda.local> <20090616215803.4a3aa748@zelda.local> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: RPCPROG_MNT: RPC: Timed out / receiving NFS error when trying to mount NFS file system after make world 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, 17 Jun 2009 15:33:35 -0000 On Tue, 16 Jun 2009, Martin wrote: [assorted bits deleted for brevity] >> If you could post to -current again with the last version that worked >> vs doesn't work now, hopefully someone will spot the problem, rick > > I've looked up the date that is encoded in my kernel.old build. > FreeBSD 8.0-CURRENT #0: Fri May 15 10:57:37 CEST 2009 > > I'm sure it worked at this point. Also nfs filesystems that have > been already mounted survived the change, but when I started to > remount them, the problems have begun to appear, so I suppose that nfsd > itself is functioning well, but mountd or rpcbind are somehow affected. > Yep, mountd only gets involved at mount time. (It does suggest that the /etc/exports stuff is ok, since mountd does push that down into the kernel and it gets used by nfsd.) > The version I'm using now, that shows the issue, is of Jun 14 19:50 > CET. > > > Fortunatelly there are not many changes in libc/rpc in this > time interval. > One that might be worth trying is a pre-r192913 svc_dg.c. I'll email you a copy of that, in case you don't have an easy way to get one. rick ps: This is related to Martin's problem posted recently, as follows: # ls -l /lib/libc.so* -r--r--r-- 1 root wheel 1234432 Jun 15 01:04 /lib/libc.so.7 # ls -l /boot/kernel/kernel -r-xr-xr-x 1 root wheel 12010608 Jun 15 01:38 /boot/kernel/kernel Further info to diagnose the problem: I've got 3 NICs on 35, 135 and 235 (different subnets). Netmasks are: - xx.xx.xx.35/25 - xx.xx.xx.135/26 - xx.xx.xx.235/26 Client is xx.xx.xx.150/26. But you can try it with a single server. A mount on 127.0.0.1 won't work either. Here relevant part of rc.conf: nfs_server_flags="-t -n 4 -h xx.xx.xx.35 -h xx.xx.xx.135" mountd_flags="-l -r -h xx.xx.xx.35 -h xx.xx.xx.135" /etc/exports: /usr/export/src -maproot=root -ro -network xx.xx.xx.128 -mask 255.255.255.192 And here what I changed (rpcbind_flags) and the effects. Notice, I executed rpcinfo each time before restarting nfsd and mountd. Maybe I don't understand the rpcinfo output, because it differs from sockstat. ------------------------------ rpcbind_flags="-h xx.xx.xx.35 -h xx.xx.xx.135" # rpcinfo program version netid address service owner 100000 4 tcp xx.xx.xx.35.0.111 rpcbind superuser 100000 3 tcp xx.xx.xx.35.0.111 rpcbind superuser 100000 2 tcp xx.xx.xx.35.0.111 rpcbind superuser 100000 4 udp xx.xx.xx.35.0.111 rpcbind superuser 100000 3 udp xx.xx.xx.35.0.111 rpcbind superuser 100000 2 udp xx.xx.xx.35.0.111 rpcbind superuser 100000 4 tcp6 ::1.0.111 rpcbind superuser 100000 3 tcp6 ::1.0.111 rpcbind superuser 100000 4 udp6 ::1.0.111 rpcbind superuser 100000 3 udp6 ::1.0.111 rpcbind superuser 100000 4 local /var/run/rpcbind.sock rpcbind superuser 100000 3 local /var/run/rpcbind.sock rpcbind superuser 100000 2 local /var/run/rpcbind.sock rpcbind superuser # sockstat | grep rpcbind root rpcbind 28763 4 udp6 *:* *:* root rpcbind 28763 5 stream /var/run/rpcbind.sock root rpcbind 28763 6 udp6 ::1:111 *:* root rpcbind 28763 7 udp6 *:1008 *:* root rpcbind 28763 8 tcp6 ::1:111 *:* root rpcbind 28763 9 udp4 127.0.0.1:111 *:* root rpcbind 28763 10 udp4 xx.xx.xx.135:111 *:* root rpcbind 28763 11 udp4 xx.xx.xx.35:111 *:* root rpcbind 28763 12 udp4 *:842 *:* root rpcbind 28763 13 tcp4 127.0.0.1:111 *:* root rpcbind 28763 14 tcp4 xx.xx.xx.135:111 *:* root rpcbind 28763 15 tcp4 xx.xx.xx.35:111 *:* client# mount_nfs -o ro,tcp,intr,soft,bg,nfsv3 xx.xx.xx.35:/usr/export/src /usr/src [tcp] xx.xx.xx.35:/usr/export/src: RPCPROG_NFS: RPC: Port mapper failure - RPC: Timed out mount_nfs: Cannot immediately mount xx.xx.xx.35:/usr/export/src, backgrounding -------------------------------------- rpcbind_flags="-h xx.xx.xx.135 -h xx.xx.xx.35" # rpcinfo program version netid address service owner 100000 4 tcp xx.xx.xx.135.0.111 rpcbind superuser 100000 3 tcp xx.xx.xx.135.0.111 rpcbind superuser 100000 2 tcp xx.xx.xx.135.0.111 rpcbind superuser 100000 4 udp xx.xx.xx.135.0.111 rpcbind superuser 100000 3 udp xx.xx.xx.135.0.111 rpcbind superuser 100000 2 udp xx.xx.xx.135.0.111 rpcbind superuser 100000 4 tcp6 ::1.0.111 rpcbind superuser 100000 3 tcp6 ::1.0.111 rpcbind superuser 100000 4 udp6 ::1.0.111 rpcbind superuser 100000 3 udp6 ::1.0.111 rpcbind superuser 100000 4 local /var/run/rpcbind.sock rpcbind superuser 100000 3 local /var/run/rpcbind.sock rpcbind superuser 100000 2 local /var/run/rpcbind.sock rpcbind superuser # sockstat | grep rpcbind root rpcbind 28591 4 udp6 *:* *:* root rpcbind 28591 5 stream /var/run/rpcbind.sock root rpcbind 28591 6 udp6 ::1:111 *:* root rpcbind 28591 7 udp6 *:825 *:* root rpcbind 28591 8 tcp6 ::1:111 *:* root rpcbind 28591 9 udp4 127.0.0.1:111 *:* root rpcbind 28591 10 udp4 xx.xx.xx.35:111 *:* root rpcbind 28591 11 udp4 xx.xx.xx.135:111 *:* root rpcbind 28591 12 udp4 *:1009 *:* root rpcbind 28591 13 tcp4 127.0.0.1:111 *:* root rpcbind 28591 14 tcp4 xx.xx.xx.35:111 *:* root rpcbind 28591 15 tcp4 xx.xx.xx.135:111 *:* client# mount_nfs -o ro,tcp,intr,soft,bg,nfsv3 xx.xx.xx.35:/usr/export/src /usr/src [tcp] xx.xx.xx.35:/usr/export/src: RPCPROG_NFS: RPC: Port mapper failure - RPC: Timed out mount_nfs: Cannot immediately mount xx.xx.xx.35:/usr/export/src, backgrounding -------------------------------------- rpcbind_flags="-h xx.xx.xx.135 -h xx.xx.xx.35 -h xx.xx.xx.235" # rpcinfo program version netid address service owner 100000 4 tcp xx.xx.xx.135.0.111 rpcbind superuser 100000 3 tcp xx.xx.xx.135.0.111 rpcbind superuser 100000 2 tcp xx.xx.xx.135.0.111 rpcbind superuser 100000 4 udp xx.xx.xx.135.0.111 rpcbind superuser 100000 3 udp xx.xx.xx.135.0.111 rpcbind superuser 100000 2 udp xx.xx.xx.135.0.111 rpcbind superuser 100000 4 tcp6 ::1.0.111 rpcbind superuser 100000 3 tcp6 ::1.0.111 rpcbind superuser 100000 4 udp6 ::1.0.111 rpcbind superuser 100000 3 udp6 ::1.0.111 rpcbind superuser 100000 4 local /var/run/rpcbind.sock rpcbind superuser 100000 3 local /var/run/rpcbind.sock rpcbind superuser 100000 2 local /var/run/rpcbind.sock rpcbind superuser # sockstat |grep rpcbind root rpcbind 28564 4 udp6 *:* *:* root rpcbind 28564 5 stream /var/run/rpcbind.sock root rpcbind 28564 6 udp6 ::1:111 *:* root rpcbind 28564 7 udp6 *:892 *:* root rpcbind 28564 8 tcp6 ::1:111 *:* root rpcbind 28564 9 udp4 127.0.0.1:111 *:* root rpcbind 28564 10 udp4 xx.xx.xx.235:111 *:* root rpcbind 28564 11 udp4 xx.xx.xx.35:111 *:* root rpcbind 28564 12 udp4 xx.xx.xx.135:111 *:* root rpcbind 28564 13 udp4 *:630 *:* root rpcbind 28564 14 tcp4 127.0.0.1:111 *:* root rpcbind 28564 15 tcp4 xx.xx.xx.235:111 *:* root rpcbind 28564 16 tcp4 xx.xx.xx.35:111 *:* root rpcbind 28564 17 tcp4 xx.xx.xx.135:111 *:* client# mount_nfs -o ro,tcp,intr,soft,bg,nfsv3 xx.xx.xx.35:/usr/export/src /usr/src [tcp] xx.xx.xx.35:/usr/export/src: RPCPROG_NFS: RPC: Port mapper failure - RPC: Timed out mount_nfs: Cannot immediately mount xx.xx.xx.35:/usr/export/src, backgrounding -------------------------------------- rpcbind_flags="" # rpcinfo program version netid address service owner 100000 4 tcp 0.0.0.0.0.111 rpcbind superuser 100000 3 tcp 0.0.0.0.0.111 rpcbind superuser 100000 2 tcp 0.0.0.0.0.111 rpcbind superuser 100000 4 udp 0.0.0.0.0.111 rpcbind superuser 100000 3 udp 0.0.0.0.0.111 rpcbind superuser 100000 2 udp 0.0.0.0.0.111 rpcbind superuser 100000 4 tcp6 ::.0.111 rpcbind superuser 100000 3 tcp6 ::.0.111 rpcbind superuser 100000 4 udp6 ::.0.111 rpcbind superuser 100000 3 udp6 ::.0.111 rpcbind superuser 100000 4 local /var/run/rpcbind.sock rpcbind superuser 100000 3 local /var/run/rpcbind.sock rpcbind superuser 100000 2 local /var/run/rpcbind.sock rpcbind superuser # sockstat | grep rpcbind root rpcbind 28735 4 udp6 *:* *:* root rpcbind 28735 5 stream /var/run/rpcbind.sock root rpcbind 28735 6 udp6 *:111 *:* root rpcbind 28735 7 udp6 *:718 *:* root rpcbind 28735 8 tcp6 *:111 *:* root rpcbind 28735 9 udp4 *:111 *:* root rpcbind 28735 10 udp4 *:870 *:* root rpcbind 28735 11 tcp4 *:111 *:* client# mount_nfs -o ro,tcp,intr,soft,bg,nfsv3 xx.xx.xx.35:/usr/export/src /usr/src client# umount /usr/src umount: xx.xx.xx.35: RPCMNT_UMOUNT: RPC: Timed out --------------------------------- Hmm... the mount has been successful, but I wonder why umount still gets a time out... Need more info? From owner-freebsd-current@FreeBSD.ORG Wed Jun 17 15:46:24 2009 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 B5DDF1065679; Wed, 17 Jun 2009 15:46:24 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.freebsd.org (Postfix) with ESMTP id 39C3C8FC23; Wed, 17 Jun 2009 15:46:23 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.3/8.14.3) with ESMTP id n5HFi7cJ015096; Wed, 17 Jun 2009 19:44:08 +0400 (MSD) (envelope-from marck@rinet.ru) Date: Wed, 17 Jun 2009 19:44:07 +0400 (MSD) From: Dmitry Morozovsky To: Wojciech Puchar In-Reply-To: Message-ID: References: <4A36930F.2000302@delphij.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (woozle.rinet.ru [0.0.0.0]); Wed, 17 Jun 2009 19:44:08 +0400 (MSD) Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, d@delphij.net, Ivan Voras Subject: Re: tmpfs experimental? 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, 17 Jun 2009 15:46:25 -0000 On Tue, 16 Jun 2009, Wojciech Puchar wrote: WP> > > In other words, is there still reason for the "highly experimental WP> > > feature" warning? WP> > WP> > Last time when I added the warning, it was because some data corruption WP> > issue that can be identified by fsx which I didn't got a chance to WP> > investigate further. I think tmpfs is Ok for some usual work but maybe WP> > not ready for production at that moment. alc@ and kib@ has made a lot WP> > of changes on it recently so perhaps we need to re-visit the problems, WP> > tmpfs would be a great feature for us. WP> WP> as an ordinary user not programmer of tmpfs i can say that: WP> WP> 1) runs fine for months in production environments, including case with over WP> 40 mountpoints (jails) WP> 2) runs really fast when memory is available. WP> 3) performance is bad in case that swapping actually is used. It reads from WP> swap with too small chunks. it's a place for improvement here. WP> WP> Its great thing as it does it properly - memory is immediately freed on WP> delete, and no caching of memory disk like with md(4). Actually, buffer cache is used, so excessive memory usage are still in place; also, on rather heavy tmpfs usage (building large ports, for example) I still can panic and/or hang the machione with exhausted maxswzone, so there definitely is a place to improve things ;) -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Wed Jun 17 16:38:31 2009 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 0050E1065670 for ; Wed, 17 Jun 2009 16:38:30 +0000 (UTC) (envelope-from zml@FreeBSD.org) Received: from seaxch10.isilon.com (seaxch10.isilon.com [74.85.160.26]) by mx1.freebsd.org (Postfix) with ESMTP id CB7F78FC0A for ; Wed, 17 Jun 2009 16:38:30 +0000 (UTC) (envelope-from zml@FreeBSD.org) Received: from famine.isilon.com ([10.54.190.95]) by seaxch10.isilon.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 Jun 2009 09:25:59 -0700 Received: from zloafman by famine.isilon.com with local (Exim 4.69) (envelope-from ) id 1MGxxW-0004Ed-TH; Wed, 17 Jun 2009 09:25:58 -0700 Date: Wed, 17 Jun 2009 09:25:57 -0700 From: Zachary Loafman To: Martin Message-ID: <20090617162557.GA16254@isilon.com> References: <4A2504AA.1020406@zedat.fu-berlin.de> <20090603235227.GB15659@hades.panopticon> <20090615173315.1cdb39e1@zelda.local> <20090616000758.714912e6@zelda.local> <20090616215803.4a3aa748@zelda.local> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="DocE+STaALJfprDB" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) X-OriginalArrivalTime: 17 Jun 2009 16:26:00.0018 (UTC) FILETIME=[4CC1DB20:01C9EF68] Cc: freebsd-current@freebsd.org Subject: Re: RPCPROG_MNT: RPC: Timed out / receiving NFS error when trying to mount NFS file system after make world 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, 17 Jun 2009 16:38:31 -0000 --DocE+STaALJfprDB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Jun 17, 2009 at 11:35:19AM -0400, Rick Macklem wrote: > One that might be worth trying is a pre-r192913 svc_dg.c. I'll email > you a copy of that, in case you don't have an easy way to get one. This was my rev, and may have some subtle issues on 8.0 (it was originally a 6.x based patch). I've attached a lib/libc/rpc/svc_dg.c patch from Rachel Hestilow that may fix your issue. Martin, can you test it in your environment? I'll get it approved / checked in soon. -- Zach Loafman | Staff Engineer | Isilon Systems --DocE+STaALJfprDB Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="20090616-bug-55392.diff" Index: svc_dg.c =================================================================== --- svc_dg.c (revision 120171) +++ svc_dg.c (working copy) @@ -222,20 +222,25 @@ svc_dg_recvfrom(int fd, char *buf, int b if (!have_lin) return rlen; lin->sin_family = AF_INET; lin->sin_port = 0; *laddrlen = sizeof(struct sockaddr_in); return rlen; } +/* + * Wrapper that acts like recvfrom. Captures the local address for + * incoming packets so that it can be sent out later using + * IP_SENDSRCADDR. + */ static bool_t svc_dg_recv(xprt, msg) SVCXPRT *xprt; struct rpc_msg *msg; { struct svc_dg_data *su = su_data(xprt); XDR *xdrs = &(su->su_xdrs); char *reply; struct sockaddr_storage ss; socklen_t alen; @@ -273,41 +278,45 @@ again: if (su->su_cache != NULL) { if (cache_get(xprt, msg, &reply, &replylen)) { (void)_sendto(xprt->xp_fd, reply, replylen, 0, (struct sockaddr *)(void *)&ss, alen); return (FALSE); } } return (TRUE); } +/* + * Wrapper for sendto. If laddr is set to a specific address, + * it will be sent out as a source address using IP_SENDSRCADDR. + */ static int svc_dg_sendto(int fd, char *buf, int buflen, const struct sockaddr *raddr, socklen_t raddrlen, const struct sockaddr *laddr, socklen_t laddrlen) { struct msghdr msg; struct iovec msg_iov[1]; struct sockaddr_in *laddr_in = (struct sockaddr_in *)laddr; struct in_addr *lin = &laddr_in->sin_addr; char tmp[CMSG_SPACE(sizeof(*lin))]; struct cmsghdr *cmsg; memset((char *)&msg, 0, sizeof(msg)); msg_iov[0].iov_base = buf; msg_iov[0].iov_len = buflen; msg.msg_iov = msg_iov; msg.msg_iovlen = 1; msg.msg_namelen = raddrlen; msg.msg_name = (char *)raddr; - if (laddr->sa_family == AF_INET) { + if (laddr->sa_family == AF_INET && lin->s_addr != INADDR_ANY) { msg.msg_control = (caddr_t)tmp; msg.msg_controllen = CMSG_LEN(sizeof(*lin)); cmsg = CMSG_FIRSTHDR(&msg); cmsg->cmsg_len = CMSG_LEN(sizeof(*lin)); cmsg->cmsg_level = IPPROTO_IP; cmsg->cmsg_type = IP_SENDSRCADDR; memcpy(CMSG_DATA(cmsg), lin, sizeof(*lin)); } return _sendmsg(fd, &msg, 0); --DocE+STaALJfprDB-- From owner-freebsd-current@FreeBSD.ORG Wed Jun 17 17:00:38 2009 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 20FDB1065678 for ; Wed, 17 Jun 2009 17:00:38 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from mail-gw1.york.ac.uk (mail-gw1.york.ac.uk [144.32.128.246]) by mx1.freebsd.org (Postfix) with ESMTP id B04788FC20 for ; Wed, 17 Jun 2009 17:00:37 +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-gw1.york.ac.uk (8.13.6/8.13.6) with ESMTP id n5HH0NJJ018869 for ; Wed, 17 Jun 2009 18:00:23 +0100 (BST) Received: from buffy-128.york.ac.uk ([144.32.128.160] helo=buffy.york.ac.uk) by mail-gw7.york.ac.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1MGyUo-0001es-U8 for freebsd-current@FreeBSD.org; Wed, 17 Jun 2009 18:00:22 +0100 Received: from buffy.york.ac.uk (localhost [127.0.0.1]) by buffy.york.ac.uk (8.14.3/8.14.3) with ESMTP id n5HH0MM0043477 for ; Wed, 17 Jun 2009 18:00:22 +0100 (BST) (envelope-from gavin@FreeBSD.org) Received: (from ga9@localhost) by buffy.york.ac.uk (8.14.3/8.14.3/Submit) id n5HH0M8A043476 for freebsd-current@freebsd.org; Wed, 17 Jun 2009 18:00:22 +0100 (BST) (envelope-from gavin@FreeBSD.org) X-Authentication-Warning: buffy.york.ac.uk: ga9 set sender to gavin@FreeBSD.org using -f From: Gavin Atkinson To: freebsd-current@FreeBSD.org Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Wed, 17 Jun 2009 18:00:22 +0100 Message-Id: <1245258022.40309.49.camel@buffy.york.ac.uk> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 FreeBSD GNOME Team Port X-York-MailScanner: Found to be clean X-York-MailScanner-From: gavin@freebsd.org Cc: Subject: BTX halted when booting from CD: Toshiba M10-10i laptop 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, 17 Jun 2009 17:00:38 -0000 Hi all, I've got a new laptop (a Toshiba M10-10i, for the archives) but FreeBSD won't boot on it. I've tested with the May 2009 amd64 snapshot ISO, and about 20% of the time, it hangs before even displaying "CD loader". The rest of the time, I get the following BTX register dump: CD Loader 1.2 Building the boot loader arguments Looking up /BOOT/LOADER... Found Relocating the loader and the BTX Starting the BTX loader BTX loader 1.00 BTX version is 1.02 int=0000000d err=00003d58 efl=00010246 eip=3583d321 eax=8b16d000 ebx=00000000 ecx=ffff0000 edx=00002170 esi=00000000 edi=0003b7c0 ebp=00090bf8 esp=00090bc8 cs=002b ds=0033 es=0033 fs=0033 gs=0033 ss=0033 cs:eip=07 00 00 00 00 00 00 00-33 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00-03 00 00 00 20 00 00 00 ss:esp=5b 3d 03 00 33 00 00 00-48 01 00 00 a0 b0 03 00 38 00 00 00 6f 01 20 00-1a 00 20 00 01 94 00 00 BTX halted (at which point the laptop immediately reboots. This is transcribed from a photo.) A second crash (some registers are different, but I guess it's the same cause due to the same odd eip): int=0000000d err=00003d58 efl=00010202 eip=3583d321 eax=79f7b814 ebx=00000000 ecx=02000000 edx=000000ec esi=00000000 edi=0003b7c0 ebp=00090bf8 esp=00090bcc cs=002b ds=0033 es=0033 fs=0033 gs=0033 ss=0033 cs:eip=07 00 00 00 00 00 00 00-33 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00-03 00 00 00 20 00 00 00 ss:esp=5b 3d 03 00 48 01 00 00-a0 b0 03 00 38 00 00 00 6f 01 20 00 1a 00 20 00-01 94 00 00 00 00 00 00 BTX halted Now, I can tell that eip is off into the weeds, but I'm not really sure how to debug this past that. The first address on the stack is presumably a return address, but that doesn't seem to be within the address space where any of the bootstrap code is loaded to, so maybe I'm wrong. So, how do I continue tracking down the problem from here? I don't know if it helps at all, but even a 4.x CD dies in BTX (although I haven't managed to successfully take a picture of that to confirm if it is the same problem, but can try if it would be useful) As an aside, from what I understand from the source, once we've got to this stage of the boot the environment should be the same whether we're booting from hard drive, CD or PXE? Is that correct? Thanks, Gavin From owner-freebsd-current@FreeBSD.ORG Wed Jun 17 18:29:27 2009 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 CBC9810656E9 for ; Wed, 17 Jun 2009 18:29:27 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-out2.uni-muenster.de (ZIVM-OUT2.UNI-MUENSTER.DE [128.176.192.9]) by mx1.freebsd.org (Postfix) with ESMTP id 60DC78FC23 for ; Wed, 17 Jun 2009 18:29:26 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) X-IronPort-AV: E=Sophos;i="4.42,239,1243807200"; d="scan'208";a="216418979" Received: from zivmaildisp2.uni-muenster.de (HELO ZIVMAILUSER01.UNI-MUENSTER.DE) ([128.176.188.143]) by zivm-relay2.uni-muenster.de with ESMTP; 17 Jun 2009 20:29:25 +0200 Received: by ZIVMAILUSER01.UNI-MUENSTER.DE (Postfix, from userid 149459) id 823C31B0763; Wed, 17 Jun 2009 20:29:25 +0200 (CEST) Date: Wed, 17 Jun 2009 20:29:25 +0200 (CEST) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Subject: estX still not attaching properly 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, 17 Jun 2009 18:29:28 -0000 hi there, although i'm running a very recent current which has "ACPICA 20090521", estX still isn't attaching properly on my machine: est0: on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 925092506000925 device_attach: est0 attach returned 6 est1: on cpu1 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 925092506000925 device_attach: est1 attach returned 6 here's the output of `sysctl -a|grep freq`: kern.acct_chkfreq: 15 kern.timecounter.tc.i8254.frequency: 1193182 kern.timecounter.tc.ACPI-fast.frequency: 3579545 kern.timecounter.tc.HPET.frequency: 14318180 kern.timecounter.tc.TSC.frequency: 1800009864 debug.cpufreq.verbose: 0 debug.cpufreq.lowest: 0 "cpufreq lock","system map" "cpufreq lock","UMA zone" machdep.tsc_freq: 1800009864 machdep.i8254_freq: 1193182 machdep.acpi_timer_freq: 3579545 dev.cpu.0.freq: 1350 dev.cpu.0.freq_levels: 1800/-1 1575/-1 1350/-1 1125/-1 900/-1 675/-1 450/-1 225/-1 dev.p4tcc.0.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1 2500/-1 1250/-1 dev.p4tcc.1.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1 2500/-1 1250/-1 dev.cpufreq.0.%driver: cpufreq dev.cpufreq.0.%parent: cpu0 dev.cpufreq.1.%driver: cpufreq dev.cpufreq.1.%parent: cpu1 this is my cpu: CPU: Intel(R) Pentium(R) Dual CPU E2160 @ 1.80GHz (1800.01-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6fd Stepping = 13 Features=0xbfebfbff Features2=0xe39d AMD Features=0x20100000 AMD Features2=0x1 TSC: P-state invariant real memory = 2147483648 (2048 MB) avail memory = 2082861056 (1986 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 right now i'm running r194284. cheers. From owner-freebsd-current@FreeBSD.ORG Wed Jun 17 21:07:53 2009 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 C43A010656D2 for ; Wed, 17 Jun 2009 21:07:53 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-out2.uni-muenster.de (ZIVM-OUT2.UNI-MUENSTER.DE [128.176.192.9]) by mx1.freebsd.org (Postfix) with ESMTP id 58A4F8FC13 for ; Wed, 17 Jun 2009 21:07:52 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) X-IronPort-AV: E=Sophos;i="4.42,239,1243807200"; d="scan'208";a="216427744" Received: from zivmaildisp2.uni-muenster.de (HELO ZIVMAILUSER03.UNI-MUENSTER.DE) ([128.176.188.143]) by zivm-relay2.uni-muenster.de with ESMTP; 17 Jun 2009 23:07:51 +0200 Received: by ZIVMAILUSER03.UNI-MUENSTER.DE (Postfix, from userid 149459) id 7321D1B075E; Wed, 17 Jun 2009 23:07:51 +0200 (CEST) Date: Wed, 17 Jun 2009 23:07:50 +0200 (CEST) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Subject: debug.debugger_on_panic = 0 yet still entering db 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, 17 Jun 2009 21:07:54 -0000 i'd like to get a bt from a panic which occurs after doing `acpiconf -s 3`. since i'm using a usb keyboard (which doesn't work in db) i've set debug.debugger_on_panic = 0 ("options KDB_UNATTENDED" in kernel). yet when the panic occurs freebsd still enters the debugger! i also get another panic which is virtualbox related, but when the virtualbox related panic occurs the core gets dumped and freebsd reboots as it should do. since i cannot use my usb keyboard when the acpi panic occurs i don't know what kind of panic this is, but i think it saw the term "spinlock". i'm running r194284. this is the output of `sysctl -a|grep panic`: kern.sync_on_panic: 0 debug.ddb.textdump.do_panic: 1 debug.trace_on_panic: 1 debug.debugger_on_panic: 0 debug.kdb.panic: 0 machdep.enable_panic_key: 0 machdep.panic_on_nmi: 1 cheers. From owner-freebsd-current@FreeBSD.ORG Wed Jun 17 21:37:08 2009 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 7DDD71065673; Wed, 17 Jun 2009 21:37:08 +0000 (UTC) (envelope-from nakal@web.de) Received: from fmmailgate02.web.de (fmmailgate02.web.de [217.72.192.227]) by mx1.freebsd.org (Postfix) with ESMTP id 3620F8FC12; Wed, 17 Jun 2009 21:37:08 +0000 (UTC) (envelope-from nakal@web.de) Received: from smtp07.web.de (fmsmtp07.dlan.cinetic.de [172.20.5.215]) by fmmailgate02.web.de (Postfix) with ESMTP id 028E1103C6949; Wed, 17 Jun 2009 23:37:07 +0200 (CEST) Received: from [217.236.12.202] (helo=zelda.local) by smtp07.web.de with asmtp (TLSv1:AES128-SHA:128) (WEB.DE 4.110 #277) id 1MH2oc-0003vH-00; Wed, 17 Jun 2009 23:37:06 +0200 Date: Wed, 17 Jun 2009 23:37:04 +0200 From: Martin To: Zachary Loafman Message-ID: <20090617233704.3e92540a@zelda.local> In-Reply-To: <20090617162557.GA16254@isilon.com> References: <4A2504AA.1020406@zedat.fu-berlin.de> <20090603235227.GB15659@hades.panopticon> <20090615173315.1cdb39e1@zelda.local> <20090616000758.714912e6@zelda.local> <20090616215803.4a3aa748@zelda.local> <20090617162557.GA16254@isilon.com> X-Mailer: Claws Mail 3.7.1 (GTK+ 2.16.2; amd64-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: nakal@web.de X-Sender: nakal@web.de X-Provags-ID: V01U2FsdGVkX18CdDPBXtn1x8Gm+gsoKxcoClMCBGGUhj7uEiNZ Q1xk+fxN5+3E1bGXLkw2UBerO8faquN/BZ3cTFxvCP5A4883GI 9S1RFoqqA= Cc: freebsd-current@freebsd.org Subject: Re: RPCPROG_MNT: RPC: Timed out / receiving NFS error when trying to mount NFS file system after make world 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, 17 Jun 2009 21:37:08 -0000 Am Wed, 17 Jun 2009 09:25:57 -0700 schrieb Zachary Loafman : > On Wed, Jun 17, 2009 at 11:35:19AM -0400, Rick Macklem wrote: > > One that might be worth trying is a pre-r192913 svc_dg.c. I'll email > > you a copy of that, in case you don't have an easy way to get one. > > This was my rev, and may have some subtle issues on 8.0 (it was > originally a 6.x based patch). I've attached a lib/libc/rpc/svc_dg.c > patch from Rachel Hestilow that may fix your issue. Martin, can you > test it in your environment? I'll get it approved / checked in soon. > Hi Zachary, I doubt anything will change, because your patch only inserted a comment in svc_dg.c. I've got this patch already in my svc_dg.c: - if (laddr->sa_family == AF_INET) { + if (laddr->sa_family == AF_INET && lin->s_addr != INADDR_ANY) { -- Martin From owner-freebsd-current@FreeBSD.ORG Wed Jun 17 22:58:50 2009 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 6AE2E106566C for ; Wed, 17 Jun 2009 22:58:50 +0000 (UTC) (envelope-from wxs@atarininja.org) Received: from syn.atarininja.org (syn.csh.rit.edu [129.21.60.158]) by mx1.freebsd.org (Postfix) with ESMTP id 42C2E8FC08 for ; Wed, 17 Jun 2009 22:58:50 +0000 (UTC) (envelope-from wxs@atarininja.org) Received: by syn.atarininja.org (Postfix, from userid 1001) id A21295C2E; Wed, 17 Jun 2009 18:58:49 -0400 (EDT) Date: Wed, 17 Jun 2009 18:58:49 -0400 From: Wesley Shields To: Thomas Backman Message-ID: <20090617225849.GB28509@atarininja.org> References: <949B5884-5303-4EFF-AC7D-293640FFA012@exscape.org> <0C235698-3ED2-4AE9-A7D1-5DC56D8324A4@exscape.org> <200905212129.47892.mel.flynn+fbsd.current@mailing.thruhere.net> <44F486FA-E798-448D-BE31-F7A51EF1F612@exscape.org> <60173AF0-7E54-4BDD-8927-0DADA9DAD1B4@exscape.org> <20090522200306.GE2630@atarininja.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090522200306.GE2630@atarininja.org> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: freebsd-current@freebsd.org Subject: Re: DTrace panic while probing syscall::open (and possibly many others) 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, 17 Jun 2009 22:58:50 -0000 On Fri, May 22, 2009 at 04:03:06PM -0400, Wesley Shields wrote: > On Fri, May 22, 2009 at 10:00:56AM +0200, Thomas Backman wrote: > > On May 22, 2009, at 09:31 AM, Thomas Backman wrote: > > > > > > ... > > > dtrace: error on enabled probe ID 1 (ID 38977: syscall::open:entry): > > > invalid address (0xffffff803e9afae0) in action #1 at DIF offset 28 > > > dtrace: error on enabled probe ID 1 (ID 38977: syscall::open:entry): > > > invalid address (0xffffff803e9afae0) in action #1 at DIF offset 28 > > > dtrace: error on enabled probe ID 1 (ID 38977: syscall::open:entry): > > > invalid address (0xffffff803e9afae0) in action #1 at DIF offset 28 > > > > > > > Actually, I still get these. Bummer. > > > > [root@chaos /usr/local/sbin]# execsnoop > > UID PID PPID ARGS > > 0 1931 1924 /bin/sh > > 0 1931 1924 /bin/sh > > 0 1932 1931 /bin/mkdir > > 0 1932 1931 /bin/mkdir > > dtrace: error on enabled probe ID 2 (ID 39086: > > syscall::execve:return): invalid address (0xffffff803e8cfae0) in > > action #8 > > dtrace: error on enabled probe ID 3 (ID 39086: > > syscall::execve:return): invalid address (0xffffff803e8cfae0) in > > action #8 > > 0 1944 1933 mktemp > > 0 1944 1933 mktemp > > dtrace: error on enabled probe ID 2 (ID 39086: > > syscall::execve:return): invalid address (0xffffff803ea58ae0) in > > action #8 > > dtrace: error on enabled probe ID 3 (ID 39086: > > syscall::execve:return): invalid address (0xffffff803ea58ae0) in > > action #8 > > dtrace: error on enabled probe ID 2 (ID 39086: > > syscall::execve:return): invalid address (0xffffff803ea9eae0) in > > action #8 > > dtrace: error on enabled probe ID 3 (ID 39086: > > syscall::execve:return): invalid address (0xffffff803ea9eae0) in > > action #8 > > 0 1948 1947 /bin/sh > > 0 1948 1947 /bin/sh > > 0 1949 1948 vnstat > > 0 1949 1948 vnstat > > 0 1950 1933 /bin/rm > > 0 1950 1933 /bin/rm > > 0 1951 1907 /bin/sh > > 0 1951 1907 /bin/sh > > 0 1952 1951 make > > 0 1952 1951 make > > > > (No idea why everything is printed twice either.) > > Also, the DTrace variable "walltimestamp" seems to return "1970 Jan 1 > > 01:00:00" (I'm in GMT+2 right now, btw) every time. > > This leads me to believe it's a race somewhere. > > Another datapoint: whatever was changed also made it into 7.2 as that is > broken in the same fashion. I just installed a 7.1 VM and tried it there > and it works. I just updated a -current machine to r194361 and the race condition is still there but not triggered as often, and it no longer leads to a panic. I still get occasional output like what is listed above but no panic. -- WXS From owner-freebsd-current@FreeBSD.ORG Thu Jun 18 00:03:57 2009 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 799B7106566B; Thu, 18 Jun 2009 00:03:57 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (cl-162.ewr-01.us.sixxs.net [IPv6:2001:4830:1200:a1::2]) by mx1.freebsd.org (Postfix) with ESMTP id 189248FC12; Thu, 18 Jun 2009 00:03:56 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.3/8.14.3) with ESMTP id n5I048JR046030; Wed, 17 Jun 2009 19:04:08 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.3/8.14.3/Submit) id n5I048KI046029; Wed, 17 Jun 2009 19:04:08 -0500 (CDT) (envelope-from brooks) Date: Wed, 17 Jun 2009 19:04:08 -0500 From: Brooks Davis To: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Message-ID: <20090618000407.GA43514@lor.one-eyed-alien.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vkogqOf2sHV7VnPd" Content-Disposition: inline User-Agent: Mutt/1.5.17 (2007-11-01) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (lor.one-eyed-alien.net [127.0.0.1]); Wed, 17 Jun 2009 19:04:08 -0500 (CDT) Cc: Subject: CFT: final patches for NGROUPS>>16 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, 18 Jun 2009 00:03:57 -0000 --vkogqOf2sHV7VnPd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Please find attached three patches which result in raising NGROUPS to 1024, making programs in the base system immune to changing values of NGROUPS, and pave the way for NGROUPS to be boot time configurable. The first two patches (ngroups-catman.diff and ngroups-posix.diff) are userland cleanups. The third (ngroups-main.diff) is the core of the change and primairly in the kernel. It is strongly based on work contributed by Isilon Systems. The proposed commit messages appear to the bottom of this message. I've been running the basic code on my FreeBSD laptop for a while and I've tested basic NFS mounts, but more areas need testing before this hits a release. Key things to hit include: - NFS mount and export - IPFW uid, gid, and jail rules - portalfs (ideally portalfs should be extended to not truncate groups) In practice, expect appliations to not care about this change unless they are run with more than 16 groups. If that happens, calls to getgroups() will fail if they use statically sized buffers recompilation should fix them. Please test, review, etc. I'd like to get this in before code freeze if at all possible. -- Brooks ngroups-catman.diff: When checking if we can write to a file, use access() instead of a manual permission check based on stat output. Also, get rid of the executability check since it is not used. MFC after: 2 weeks ngroups-posix.diff In preparation for raising NGROUPS and NGROUPS_MAX, change base system callers of getgroups(), getgrouplist(), and setgroups() to allocate buffers dynamically. Specifically, allocate a buffer of size sysconf(_SC_NGROUPS_MAX)+1 (+2 in a few cases to allow for overflow). This (or similar gymnastics) is required for the code to actually follow the POSIX.1-2008 specification where {NGROUPS_MAX} may differ at runtime and where getgroups may return {NGROUPS_MAX}+1 results on systems like FreeBSD which include the primary group. In id(1), don't pointlessly add the primary group to the list of all groups, it is always the first result from getgroups(). In principle the old code was more portable, but this was only done in one of the two places where getgroups() was called to the overall effect was pointless. Document the actual POSIX requirements in the getgroups(2) and setgroups(2) manpages. We do not yet support a dynamic NGROUPS, but we may in the future. MFC after: 2 weeks ngroups-main.diff: Rework the credential code to support larger values of NGROUPS and NGROUPS_MAX, eliminate ABI dependencies on them, and raise the to 1024 and 1023 respectively. (Previously they were equal, but under a close reading of POSIX, NGROUPS_MAX was defined to be too large by 1 since it is the number of supplemental groups, not total number of groups.) The bulk of the change consists of converting the struct ucred member cr_groups from a static array to a pointer. Do the equivalent in kinfo_proc. Introduce new interfaces crcopysafe() and crsetgroups() for duplicating a process credential before modifying it and for setting group lists respectively. Both interfaces take care for the details of allocating groups array. crsetgroups() takes care of truncating the group list to the current maximum (NGROUPS) if necessary. In the future, crsetgroups() may be responsible for insuring invariants such as sorting the supplemental groups to allow groupmember() to be implemented as a binary search. Because we can not change struct xucred without breaking application ABIs, we leave it alone and introduce a new XU_NGROUPS value which is always 16 and is to be used or NGRPS as appropriate for things such as NFS which need to use no more than 16 groups. When feasible, truncate the group list rather than generating an error. Minor changes: - Reduce the number of hand rolled versions of groupmember(). - Do not assign to both cr_gid and cr_groups[0]. - Modify ipfw to cache ucreds instead of part of their contents since they are immutable once referenced by more than one entity. Submitted by: Isilon Systems X-MFC after: never --vkogqOf2sHV7VnPd Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iD8DBQFKOYR3XY6L6fI4GtQRAlOkAJwKRcS2PcUsUAyGurwQZMgAyM5npQCgkGR8 u6SdpLhMZAQgQ7+RXhyJ5FU= =TZms -----END PGP SIGNATURE----- --vkogqOf2sHV7VnPd-- From owner-freebsd-current@FreeBSD.ORG Thu Jun 18 00:05:21 2009 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 38425106564A; Thu, 18 Jun 2009 00:05:21 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (cl-162.ewr-01.us.sixxs.net [IPv6:2001:4830:1200:a1::2]) by mx1.freebsd.org (Postfix) with ESMTP id BDD9B8FC1C; Thu, 18 Jun 2009 00:05:19 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.3/8.14.3) with ESMTP id n5I05VUI046057; Wed, 17 Jun 2009 19:05:31 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.3/8.14.3/Submit) id n5I05VQW046056; Wed, 17 Jun 2009 19:05:31 -0500 (CDT) (envelope-from brooks) Date: Wed, 17 Jun 2009 19:05:31 -0500 From: Brooks Davis To: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Message-ID: <20090618000531.GA46033@lor.one-eyed-alien.net> References: <20090618000407.GA43514@lor.one-eyed-alien.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="O5XBE6gyVG5Rl6Rj" Content-Disposition: inline In-Reply-To: <20090618000407.GA43514@lor.one-eyed-alien.net> User-Agent: Mutt/1.5.17 (2007-11-01) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (lor.one-eyed-alien.net [127.0.0.1]); Wed, 17 Jun 2009 19:05:31 -0500 (CDT) Cc: Subject: Re: CFT: final patches for NGROUPS>>16 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, 18 Jun 2009 00:05:21 -0000 --O5XBE6gyVG5Rl6Rj Content-Type: multipart/mixed; boundary="YZ5djTAD1cGYuMQK" Content-Disposition: inline --YZ5djTAD1cGYuMQK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable As usual, I forgot the attachments. Here they are. -- Brooks On Wed, Jun 17, 2009 at 07:04:07PM -0500, Brooks Davis wrote: > Please find attached three patches which result in raising NGROUPS to > 1024, making programs in the base system immune to changing values of > NGROUPS, and pave the way for NGROUPS to be boot time configurable. >=20 > The first two patches (ngroups-catman.diff and ngroups-posix.diff) > are userland cleanups. The third (ngroups-main.diff) is the core of > the change and primairly in the kernel. It is strongly based on work > contributed by Isilon Systems. The proposed commit messages appear to > the bottom of this message. >=20 > I've been running the basic code on my FreeBSD laptop for a while and > I've tested basic NFS mounts, but more areas need testing before this > hits a release. Key things to hit include: > - NFS mount and export > - IPFW uid, gid, and jail rules > - portalfs (ideally portalfs should be extended to not truncate groups) >=20 > In practice, expect appliations to not care about this change unless > they are run with more than 16 groups. If that happens, calls to > getgroups() will fail if they use statically sized buffers recompilation > should fix them. >=20 > Please test, review, etc. I'd like to get this in before code freeze if > at all possible. >=20 > -- Brooks >=20 > ngroups-catman.diff: >=20 > When checking if we can write to a file, use access() instead of a > manual permission check based on stat output. Also, get rid of the > executability check since it is not used. >=20 > MFC after: 2 weeks >=20 > ngroups-posix.diff >=20 > In preparation for raising NGROUPS and NGROUPS_MAX, change base > system callers of getgroups(), getgrouplist(), and setgroups() to > allocate buffers dynamically. Specifically, allocate a buffer of size > sysconf(_SC_NGROUPS_MAX)+1 (+2 in a few cases to allow for overflow). >=20 > This (or similar gymnastics) is required for the code to actually follow > the POSIX.1-2008 specification where {NGROUPS_MAX} may differ at runtime > and where getgroups may return {NGROUPS_MAX}+1 results on systems like > FreeBSD which include the primary group. >=20 > In id(1), don't pointlessly add the primary group to the list of all > groups, it is always the first result from getgroups(). In principle > the old code was more portable, but this was only done in one of the two > places where getgroups() was called to the overall effect was pointless. >=20 > Document the actual POSIX requirements in the getgroups(2) and > setgroups(2) manpages. We do not yet support a dynamic NGROUPS, but we > may in the future. >=20 > MFC after: 2 weeks >=20 > ngroups-main.diff: >=20 > Rework the credential code to support larger values of NGROUPS and > NGROUPS_MAX, eliminate ABI dependencies on them, and raise the to 1024 > and 1023 respectively. (Previously they were equal, but under a close > reading of POSIX, NGROUPS_MAX was defined to be too large by 1 since it > is the number of supplemental groups, not total number of groups.) >=20 > The bulk of the change consists of converting the struct ucred member > cr_groups from a static array to a pointer. Do the equivalent in > kinfo_proc. >=20 > Introduce new interfaces crcopysafe() and crsetgroups() for duplicating > a process credential before modifying it and for setting group lists > respectively. Both interfaces take care for the details of allocating > groups array. crsetgroups() takes care of truncating the group list > to the current maximum (NGROUPS) if necessary. In the future, > crsetgroups() may be responsible for insuring invariants such as sorting > the supplemental groups to allow groupmember() to be implemented as a > binary search. >=20 > Because we can not change struct xucred without breaking application > ABIs, we leave it alone and introduce a new XU_NGROUPS value which is > always 16 and is to be used or NGRPS as appropriate for things such as > NFS which need to use no more than 16 groups. When feasible, truncate > the group list rather than generating an error. >=20 > Minor changes: > - Reduce the number of hand rolled versions of groupmember(). > - Do not assign to both cr_gid and cr_groups[0]. > - Modify ipfw to cache ucreds instead of part of their contents since > they are immutable once referenced by more than one entity. >=20 > Submitted by: Isilon Systems > X-MFC after: never --YZ5djTAD1cGYuMQK Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="ngroups-catman.diff" Content-Transfer-Encoding: quoted-printable diff -ru --exclude=3D.svn --exclude=3Dcompile --exclude=3Dcardbus.c --ignor= e-matching=3D'$FreeBSD:' /usr/fsvn/head/usr.bin/catman/catman.c ./usr.bin/c= atman/catman.c --- /usr/fsvn/head/usr.bin/catman/catman.c 2009-01-22 10:04:12.000000000 -0= 600 +++ ./usr.bin/catman/catman.c 2009-05-08 15:47:47.000000000 -0500 @@ -57,7 +57,6 @@ #define TEST_FILE 0x04 #define TEST_READABLE 0x08 #define TEST_WRITABLE 0x10 -#define TEST_EXECUTABLE 0x20 =20 static int verbose; /* -v flag: be verbose with warnings */ static int pretend; /* -n, -p flags: print out what would be done @@ -92,9 +91,6 @@ #define GZCAT_CMD "z" enum Ziptype {NONE, BZIP, GZIP}; =20 -static uid_t uid; -static gid_t gids[NGROUPS_MAX]; -static int ngids; static int starting_dir; static char tmp_file[MAXPATHLEN]; struct stat test_st; @@ -320,23 +316,10 @@ result |=3D TEST_DIR; else if (S_ISREG(test_st.st_mode)) result |=3D TEST_FILE; - if (test_st.st_uid =3D=3D uid) { - test_st.st_mode >>=3D 6; - } else { - int i; - for (i =3D 0; i < ngids; i++) { - if (test_st.st_gid =3D=3D gids[i]) { - test_st.st_mode >>=3D 3; - break; - } - } - } - if (test_st.st_mode & S_IROTH) + if (access(name, R_OK)) result |=3D TEST_READABLE; - if (test_st.st_mode & S_IWOTH) + if (access(name, W_OK)) result |=3D TEST_WRITABLE; - if (test_st.st_mode & S_IXOTH) - result |=3D TEST_EXECUTABLE; return result; } =20 @@ -759,14 +742,6 @@ { int opt; =20 - if ((uid =3D getuid()) =3D=3D 0) { - fprintf(stderr, "don't run %s as root, use:\n echo", argv[0]); - for (optind =3D 0; optind < argc; optind++) { - fprintf(stderr, " %s", argv[optind]); - } - fprintf(stderr, " | nice -5 su -m man\n"); - exit(1); - } while ((opt =3D getopt(argc, argv, "vnfLrh")) !=3D -1) { switch (opt) { case 'f': @@ -789,7 +764,6 @@ /* NOTREACHED */ } } - ngids =3D getgroups(NGROUPS_MAX, gids); if ((starting_dir =3D open(".", 0)) < 0) { err(1, "."); } --YZ5djTAD1cGYuMQK Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="ngroups-posix.diff" Content-Transfer-Encoding: quoted-printable diff -ru --exclude=3D.svn --exclude=3Dcompile --exclude=3Dcardbus.c --ignor= e-matching=3D'$FreeBSD:' /usr/fsvn/head/lib/libc/gen/initgroups.3 ./lib/lib= c/gen/initgroups.3 --- /usr/fsvn/head/lib/libc/gen/initgroups.3 2009-01-22 10:05:45.000000000 = -0600 +++ ./lib/libc/gen/initgroups.3 2009-06-09 09:17:36.000000000 -0500 @@ -65,6 +65,13 @@ .Va errno for any of the errors specified for the library function .Xr setgroups 2 . +It may also return: +.Bl -tag -width Er +.It Bq Er ENOMEM +The +.Fn initgroups +function was unable to allocate temporary storage. +.El .Sh SEE ALSO .Xr setgroups 2 , .Xr getgrouplist 3 diff -ru --exclude=3D.svn --exclude=3Dcompile --exclude=3Dcardbus.c --ignor= e-matching=3D'$FreeBSD:' /usr/fsvn/head/lib/libc/gen/initgroups.c ./lib/lib= c/gen/initgroups.c --- /usr/fsvn/head/lib/libc/gen/initgroups.c 2009-01-22 10:05:45.000000000 = -0600 +++ ./lib/libc/gen/initgroups.c 2009-06-17 14:00:59.000000000 -0500 @@ -35,10 +35,12 @@ =20 #include =20 -#include #include "namespace.h" #include #include "un-namespace.h" +#include +#include +#include #include =20 int @@ -46,14 +48,21 @@ const char *uname; gid_t agroup; { - int ngroups; + int ngroups, ret; + long ngroups_max; + gid_t *groups; + /* - * Provide space for one group more than NGROUPS to allow + * Provide space for one group more than possible to allow * setgroups to fail and set errno. */ - gid_t groups[NGROUPS + 1]; + ngroups_max =3D sysconf(_SC_NGROUPS_MAX) + 2; + if ((groups =3D malloc(sizeof(*groups) * ngroups_max)) =3D=3D NULL) + return (ENOMEM); =20 - ngroups =3D NGROUPS + 1; + ngroups =3D (int)ngroups_max; getgrouplist(uname, agroup, groups, &ngroups); - return (setgroups(ngroups, groups)); + ret =3D setgroups(ngroups, groups); + free(groups); + return (ret); } diff -ru --exclude=3D.svn --exclude=3Dcompile --exclude=3Dcardbus.c --ignor= e-matching=3D'$FreeBSD:' /usr/fsvn/head/lib/libc/rpc/auth_unix.c ./lib/libc= /rpc/auth_unix.c --- /usr/fsvn/head/lib/libc/rpc/auth_unix.c 2009-01-22 10:05:43.000000000 -= 0600 +++ ./lib/libc/rpc/auth_unix.c 2009-06-17 14:00:59.000000000 -0500 @@ -185,23 +185,29 @@ AUTH * authunix_create_default() { - int len; + int ngids; + long ngids_max; char machname[MAXHOSTNAMELEN + 1]; uid_t uid; gid_t gid; - gid_t gids[NGROUPS_MAX]; + gid_t *gids; + + ngids_max =3D sysconf(_SC_NGROUPS_MAX) + 1; + gids =3D malloc(sizeof(gid_t) * ngids_max); + if (gids =3D=3D NULL) + return (NULL); =20 if (gethostname(machname, sizeof machname) =3D=3D -1) abort(); machname[sizeof(machname) - 1] =3D 0; uid =3D geteuid(); gid =3D getegid(); - if ((len =3D getgroups(NGROUPS_MAX, gids)) < 0) + if ((ngids =3D getgroups(ngids_max, gids)) < 0) abort(); - if (len > NGRPS) - len =3D NGRPS; + if (ngids > NGRPS) + ngids =3D NGRPS; /* XXX: interface problem; those should all have been unsigned */ - return (authunix_create(machname, (int)uid, (int)gid, len, + return (authunix_create(machname, (int)uid, (int)gid, ngids, (int *)gids)); } =20 diff -ru --exclude=3D.svn --exclude=3Dcompile --exclude=3Dcardbus.c --ignor= e-matching=3D'$FreeBSD:' /usr/fsvn/head/lib/libc/sys/getgroups.2 ./lib/libc= /sys/getgroups.2 --- /usr/fsvn/head/lib/libc/sys/getgroups.2 2009-01-22 10:05:48.000000000 -= 0600 +++ ./lib/libc/sys/getgroups.2 2009-06-16 13:56:17.000000000 -0500 @@ -58,10 +58,7 @@ system call returns the actual number of groups returned in .Fa gidset . -No more than -.Dv NGROUPS_MAX -will ever -be returned. +At least one and as many as {NGROUPS_MAX}+1 values may be returned. If .Fa gidsetlen is zero, @@ -92,6 +89,11 @@ .Sh SEE ALSO .Xr setgroups 2 , .Xr initgroups 3 +.Sh STANDARDS +The +.Fn getgroups +system call conforms to +.St -p1003.1-2008 . .Sh HISTORY The .Fn getgroups diff -ru --exclude=3D.svn --exclude=3Dcompile --exclude=3Dcardbus.c --ignor= e-matching=3D'$FreeBSD:' /usr/fsvn/head/lib/libc/sys/setgroups.2 ./lib/libc= /sys/setgroups.2 --- /usr/fsvn/head/lib/libc/sys/setgroups.2 2009-01-22 10:05:48.000000000 -= 0600 +++ ./lib/libc/sys/setgroups.2 2009-06-16 13:56:17.000000000 -0500 @@ -53,9 +53,7 @@ argument indicates the number of entries in the array and must be no more than -.Dv NGROUPS , -as defined in -.In sys/param.h . +.Dv {NGROUPS_MAX}+1 . .Pp Only the super-user may set a new group list. .Sh RETURN VALUES @@ -71,7 +69,7 @@ The number specified in the .Fa ngroups argument is larger than the -.Dv NGROUPS +.Dv {NGROUPS_MAX}+1 limit. .It Bq Er EFAULT The address specified for diff -ru --exclude=3D.svn --exclude=3Dcompile --exclude=3Dcardbus.c --ignor= e-matching=3D'$FreeBSD:' /usr/fsvn/head/usr.bin/id/id.c ./usr.bin/id/id.c --- /usr/fsvn/head/usr.bin/id/id.c 2009-01-22 10:04:13.000000000 -0600 +++ ./usr.bin/id/id.c 2009-06-17 14:00:59.000000000 -0500 @@ -258,7 +258,8 @@ gid_t gid, egid, lastgid; uid_t uid, euid; int cnt, ngroups; - gid_t groups[NGROUPS + 1]; + long ngroups_max; + gid_t *groups; const char *fmt; =20 if (pw !=3D NULL) { @@ -270,12 +271,16 @@ gid =3D getgid(); } =20 + ngroups_max =3D sysconf(_SC_NGROUPS_MAX) + 1; + if ((groups =3D malloc(sizeof(gid_t) * ngroups_max)) =3D=3D NULL) + err(1, "malloc"); + if (use_ggl && pw !=3D NULL) { - ngroups =3D NGROUPS + 1; + ngroups =3D ngroups_max; getgrouplist(pw->pw_name, gid, groups, &ngroups); } else { - ngroups =3D getgroups(NGROUPS + 1, groups); + ngroups =3D getgroups(ngroups_max, groups); } =20 if (pw !=3D NULL) @@ -306,6 +311,7 @@ lastgid =3D gid; } printf("\n"); + free(groups); } =20 #ifdef USE_BSM_AUDIT @@ -361,15 +367,19 @@ { struct group *gr; int cnt, id, lastid, ngroups; - gid_t groups[NGROUPS + 1]; + long ngroups_max; + gid_t *groups; const char *fmt; =20 + ngroups_max =3D sysconf(_SC_NGROUPS_MAX) + 1; + if ((groups =3D malloc(sizeof(gid_t) * (ngroups_max))) =3D=3D NULL) + err(1, "malloc"); + if (pw) { - ngroups =3D NGROUPS + 1; + ngroups =3D ngroups_max; (void) getgrouplist(pw->pw_name, pw->pw_gid, groups, &ngroups); } else { - groups[0] =3D getgid(); - ngroups =3D getgroups(NGROUPS, groups + 1) + 1; + ngroups =3D getgroups(ngroups_max, groups); } fmt =3D nflag ? "%s" : "%u"; for (lastid =3D -1, cnt =3D 0; cnt < ngroups; ++cnt) { @@ -389,6 +399,7 @@ lastid =3D id; } (void)printf("\n"); + free(groups); } =20 void diff -ru --exclude=3D.svn --exclude=3Dcompile --exclude=3Dcardbus.c --ignor= e-matching=3D'$FreeBSD:' /usr/fsvn/head/usr.bin/newgrp/newgrp.c ./usr.bin/n= ewgrp/newgrp.c --- /usr/fsvn/head/usr.bin/newgrp/newgrp.c 2009-01-22 10:04:11.000000000 -0= 600 +++ ./usr.bin/newgrp/newgrp.c 2009-06-17 14:00:59.000000000 -0500 @@ -146,8 +146,8 @@ static void addgroup(const char *grpname) { - gid_t grps[NGROUPS_MAX]; - long lgid; + gid_t *grps; + long lgid, ngrps_max; int dbmember, i, ngrps; gid_t egid; struct group *grp; @@ -185,7 +185,10 @@ } } =20 - if ((ngrps =3D getgroups(NGROUPS_MAX, (gid_t *)grps)) < 0) { + ngrps_max =3D sysconf(_SC_NGROUPS_MAX) + 1; + if ((grps =3D malloc(sizeof(gid_t) * ngrps_max)) =3D=3D NULL) + err(1, "malloc"); + if ((ngrps =3D getgroups(ngrps_max, (gid_t *)grps)) < 0) { warn("getgroups"); return; } @@ -217,7 +220,7 @@ =20 /* Add old effective gid to supp. list if it does not exist. */ if (egid !=3D grp->gr_gid && !inarray(egid, grps, ngrps)) { - if (ngrps =3D=3D NGROUPS_MAX) + if (ngrps =3D=3D ngrps_max) warnx("too many groups"); else { grps[ngrps++] =3D egid; @@ -231,6 +234,7 @@ } } =20 + free(grps); } =20 static int diff -ru --exclude=3D.svn --exclude=3Dcompile --exclude=3Dcardbus.c --ignor= e-matching=3D'$FreeBSD:' /usr/fsvn/head/usr.bin/quota/quota.c ./usr.bin/quo= ta/quota.c --- /usr/fsvn/head/usr.bin/quota/quota.c 2009-01-22 10:04:12.000000000 -0600 +++ ./usr.bin/quota/quota.c 2009-06-17 14:00:59.000000000 -0500 @@ -117,7 +117,8 @@ main(int argc, char *argv[]) { int ngroups;=20 - gid_t mygid, gidset[NGROUPS]; + long ngroups_max; + gid_t mygid, *gidset; int i, ch, gflag =3D 0, uflag =3D 0, errflag =3D 0; =20 while ((ch =3D getopt(argc, argv, "f:ghlrquv")) !=3D -1) { @@ -159,13 +160,18 @@ errflag +=3D showuid(getuid()); if (gflag) { mygid =3D getgid(); - ngroups =3D getgroups(NGROUPS, gidset); + ngroups_max =3D sysconf(_SC_NGROUPS_MAX) + 1; + if ((gidset =3D malloc(sizeof(gid_t) * ngroups_max)) + =3D=3D NULL) + err(1, "malloc"); + ngroups =3D getgroups(ngroups_max, gidset); if (ngroups < 0) err(1, "getgroups"); errflag +=3D showgid(mygid); for (i =3D 0; i < ngroups; i++) if (gidset[i] !=3D mygid) errflag +=3D showgid(gidset[i]); + free(gidset); } return(errflag); } diff -ru --exclude=3D.svn --exclude=3Dcompile --exclude=3Dcardbus.c --ignor= e-matching=3D'$FreeBSD:' /usr/fsvn/head/usr.sbin/chown/chown.c ./usr.sbin/c= hown/chown.c --- /usr/fsvn/head/usr.sbin/chown/chown.c 2009-01-22 10:05:31.000000000 -06= 00 +++ ./usr.sbin/chown/chown.c 2009-06-17 14:00:59.000000000 -0500 @@ -269,7 +269,8 @@ { static uid_t euid =3D -1; static int ngroups =3D -1; - gid_t groups[NGROUPS_MAX]; + static long ngroups_max; + gid_t *groups; =20 /* Check for chown without being root. */ if (errno !=3D EPERM || (uid !=3D (uid_t)-1 && @@ -281,7 +282,10 @@ /* Check group membership; kernel just returns EPERM. */ if (gid !=3D (gid_t)-1 && ngroups =3D=3D -1 && euid =3D=3D (uid_t)-1 && (euid =3D geteuid()) !=3D 0) { - ngroups =3D getgroups(NGROUPS_MAX, groups); + ngroups_max =3D sysconf(_SC_NGROUPS_MAX) + 1; + if ((groups =3D malloc(sizeof(gid_t) * ngroups_max)) =3D=3D NULL) + err(1, "malloc"); + ngroups =3D getgroups(ngroups_max, groups); while (--ngroups >=3D 0 && gid !=3D groups[ngroups]); if (ngroups < 0) { warnx("you are not a member of group %s", gname); diff -ru --exclude=3D.svn --exclude=3Dcompile --exclude=3Dcardbus.c --ignor= e-matching=3D'$FreeBSD:' /usr/fsvn/head/usr.sbin/chroot/chroot.c ./usr.sbin= /chroot/chroot.c --- /usr/fsvn/head/usr.sbin/chroot/chroot.c 2009-01-22 10:05:34.000000000 -= 0600 +++ ./usr.sbin/chroot/chroot.c 2009-06-17 14:00:59.000000000 -0500 @@ -69,9 +69,10 @@ struct passwd *pw; char *endp, *p; const char *shell; - gid_t gid, gidlist[NGROUPS_MAX]; + gid_t gid, *gidlist; uid_t uid; int ch, gids; + long ngroups_max; =20 gid =3D 0; uid =3D 0; @@ -117,8 +118,11 @@ } } =20 + ngroups_max =3D sysconf(_SC_NGROUPS_MAX) + 1; + if ((gidlist =3D malloc(sizeof(gid_t) * ngroups_max)) =3D=3D NULL) + err(1, "malloc"); for (gids =3D 0; - (p =3D strsep(&grouplist, ",")) !=3D NULL && gids < NGROUPS_MAX; ) { + (p =3D strsep(&grouplist, ",")) !=3D NULL && gids < ngroups_max; ) { if (*p =3D=3D '\0') continue; =20 @@ -135,7 +139,7 @@ } gids++; } - if (p !=3D NULL && gids =3D=3D NGROUPS_MAX) + if (p !=3D NULL && gids =3D=3D ngroups_max) errx(1, "too many supplementary groups provided"); =20 if (user !=3D NULL) { diff -ru --exclude=3D.svn --exclude=3Dcompile --exclude=3Dcardbus.c --ignor= e-matching=3D'$FreeBSD:' /usr/fsvn/head/usr.sbin/jail/jail.c ./usr.sbin/jai= l/jail.c --- /usr/fsvn/head/usr.sbin/jail/jail.c 2009-06-12 00:52:16.000000000 -0500 +++ ./usr.sbin/jail/jail.c 2009-06-17 14:00:59.000000000 -0500 @@ -104,7 +104,7 @@ lcap =3D login_getpwclass(pwd); \ if (lcap =3D=3D NULL) \ err(1, "getpwclass: %s", username); \ - ngroups =3D NGROUPS; \ + ngroups =3D ngroups_max; \ if (getgrouplist(username, pwd->pw_gid, groups, &ngroups) !=3D 0) \ err(1, "getgrouplist: %s", username); \ } while (0) @@ -115,10 +115,11 @@ login_cap_t *lcap =3D NULL; struct iovec rparams[2]; struct passwd *pwd =3D NULL; - gid_t groups[NGROUPS]; + gid_t *groups; size_t sysvallen; int ch, cmdarg, i, jail_set_flags, jid, ngroups, sysval; int hflag, iflag, Jflag, lflag, rflag, uflag, Uflag; + long ngroups_max; unsigned pi; char *ep, *jailname, *securelevel, *username, *JidFile; char errmsg[ERRMSG_SIZE], enforce_statfs[4]; @@ -132,6 +133,10 @@ jailname =3D securelevel =3D username =3D JidFile =3D cleanenv =3D NULL; fp =3D NULL; =20 + ngroups_max =3D sysconf(_SC_NGROUPS_MAX) + 1;=09 + if ((groups =3D malloc(sizeof(gid_t) * ngroups_max)) =3D=3D NULL) + err(1, "malloc"); + while ((ch =3D getopt(argc, argv, "cdhilmn:r:s:u:U:J:")) !=3D -1) { switch (ch) { case 'd': diff -ru --exclude=3D.svn --exclude=3Dcompile --exclude=3Dcardbus.c --ignor= e-matching=3D'$FreeBSD:' /usr/fsvn/head/usr.sbin/jexec/jexec.c ./usr.sbin/j= exec/jexec.c --- /usr/fsvn/head/usr.sbin/jexec/jexec.c 2009-05-29 12:48:00.000000000 -05= 00 +++ ./usr.sbin/jexec/jexec.c 2009-06-17 14:00:59.000000000 -0500 @@ -59,7 +59,7 @@ lcap =3D login_getpwclass(pwd); \ if (lcap =3D=3D NULL) \ err(1, "getpwclass: %s", username); \ - ngroups =3D NGROUPS; \ + ngroups =3D ngroups_max; \ if (getgrouplist(username, pwd->pw_gid, groups, &ngroups) !=3D 0) \ err(1, "getgrouplist: %s", username); \ } while (0) @@ -71,12 +71,17 @@ int jid; login_cap_t *lcap =3D NULL; struct passwd *pwd =3D NULL; - gid_t groups[NGROUPS]; + gid_t *groups =3D NULL; int ch, ngroups, uflag, Uflag; + long ngroups_max; char *ep, *username; ch =3D uflag =3D Uflag =3D 0; username =3D NULL; =20 + ngroups_max =3D sysconf(_SC_NGROUPS_MAX) + 1; + if ((groups =3D malloc(sizeof(gid_t) * ngroups_max)) =3D=3D NULL) + err(1, "malloc"); + while ((ch =3D getopt(argc, argv, "nu:U:")) !=3D -1) { switch (ch) { case 'n': diff -ru --exclude=3D.svn --exclude=3Dcompile --exclude=3Dcardbus.c --ignor= e-matching=3D'$FreeBSD:' /usr/fsvn/head/usr.sbin/lpr/lpc/lpc.c ./usr.sbin/l= pr/lpc/lpc.c --- /usr/fsvn/head/usr.sbin/lpr/lpc/lpc.c 2009-01-22 10:05:32.000000000 -06= 00 +++ ./usr.sbin/lpr/lpc/lpc.c 2009-06-17 14:00:59.000000000 -0500 @@ -356,7 +356,8 @@ { static struct group *gptr=3DNULL; static int ngroups =3D 0; - static gid_t groups[NGROUPS]; + static long ngroups_max; + static gid_t *groups; register gid_t gid; register int i; =20 @@ -365,7 +366,10 @@ warnx("warning: unknown group '%s'", grname); return(0); } - ngroups =3D getgroups(NGROUPS, groups); + ngroups_max =3D sysconf(_SC_NGROUPS_MAX); + if ((groups =3D malloc(sizeof(gid_t) * ngroups_max)) =3D=3D NULL) + err(1, "malloc"); + ngroups =3D getgroups(ngroups_max, groups); if (ngroups < 0) err(1, "getgroups"); } --YZ5djTAD1cGYuMQK Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="ngroups-main.diff" Content-Transfer-Encoding: quoted-printable diff -ru --exclude=3D.svn --exclude=3Dcompile --exclude=3Dcardbus.c --ignor= e-matching=3D'$FreeBSD:' /usr/fsvn/head/lib/libc/rpc/netname.c ./lib/libc/r= pc/netname.c --- /usr/fsvn/head/lib/libc/rpc/netname.c 2009-01-22 10:05:44.000000000 -06= 00 +++ ./lib/libc/rpc/netname.c 2009-05-14 01:48:22.000000000 -0500 @@ -61,9 +61,6 @@ #ifndef MAXHOSTNAMELEN #define MAXHOSTNAMELEN 256 #endif -#ifndef NGROUPS -#define NGROUPS 16 -#endif =20 #define TYPE_BIT(type) (sizeof (type) * CHAR_BIT) =20 diff -ru --exclude=3D.svn --exclude=3Dcompile --exclude=3Dcardbus.c --ignor= e-matching=3D'$FreeBSD:' /usr/fsvn/head/lib/libc/rpc/netnamer.c ./lib/libc/= rpc/netnamer.c --- /usr/fsvn/head/lib/libc/rpc/netnamer.c 2009-01-22 10:05:44.000000000 -0= 600 +++ ./lib/libc/rpc/netnamer.c 2009-05-13 22:51:38.000000000 -0500 @@ -66,10 +66,6 @@ static int getnetid( char *, char * ); static int _getgroups( char *, gid_t * ); =20 -#ifndef NGROUPS -#define NGROUPS 16 -#endif - /* * Convert network-name into unix credential */ @@ -104,7 +100,7 @@ return (0); } *gidp =3D (gid_t) atol(p); - for (gidlen =3D 0; gidlen < NGROUPS; gidlen++) { + for (gidlen =3D 0; gidlen < NGRPS; gidlen++) { p =3D strsep(&res, "\n,"); if (p =3D=3D NULL) break; @@ -157,7 +153,7 @@ static int _getgroups(uname, groups) char *uname; - gid_t groups[NGROUPS]; + gid_t groups[NGRPS]; { gid_t ngroups =3D 0; struct group *grp; @@ -169,7 +165,7 @@ while ((grp =3D getgrent())) { for (i =3D 0; grp->gr_mem[i]; i++) if (!strcmp(grp->gr_mem[i], uname)) { - if (ngroups =3D=3D NGROUPS) { + if (ngroups =3D=3D NGRPS) { #ifdef DEBUG fprintf(stderr, "initgroups: %s is in too many groups\n", uname); diff -ru --exclude=3D.svn --exclude=3Dcompile --exclude=3Dcardbus.c --ignor= e-matching=3D'$FreeBSD:' /usr/fsvn/head/lib/libkvm/kvm_proc.c ./lib/libkvm/= kvm_proc.c --- /usr/fsvn/head/lib/libkvm/kvm_proc.c 2009-06-16 15:54:14.000000000 -0500 +++ ./lib/libkvm/kvm_proc.c 2009-05-28 16:40:33.000000000 -0500 @@ -146,8 +146,7 @@ kp->ki_rgid =3D ucred.cr_rgid; kp->ki_svgid =3D ucred.cr_svgid; kp->ki_ngroups =3D ucred.cr_ngroups; - bcopy(ucred.cr_groups, kp->ki_groups, - NGROUPS * sizeof(gid_t)); + kp->ki_groups =3D ucred.cr_groups; kp->ki_uid =3D ucred.cr_uid; if (ucred.cr_prison !=3D NULL) { if (KREAD(kd, (u_long)ucred.cr_prison, &pr)) { Files /usr/fsvn/head/share/examples/kld/firmware/fwimage/firmware.img and .= /share/examples/kld/firmware/fwimage/firmware.img differ Only in /usr/fsvn/head/sys: .glimpse_exclude Only in /usr/fsvn/head/sys: .glimpse_filenames Only in /usr/fsvn/head/sys: .glimpse_filenames_index Only in /usr/fsvn/head/sys: .glimpse_filetimes Only in /usr/fsvn/head/sys: .glimpse_index Only in /usr/fsvn/head/sys: .glimpse_messages Only in /usr/fsvn/head/sys: .glimpse_partitions Only in /usr/fsvn/head/sys: .glimpse_statistics Only in /usr/fsvn/head/sys: .glimpse_turbo diff -ru --exclude=3D.svn --exclude=3Dcompile --exclude=3Dcardbus.c --ignor= e-matching=3D'$FreeBSD:' /usr/fsvn/head/sys/compat/linux/linux_misc.c ./sys= /compat/linux/linux_misc.c --- /usr/fsvn/head/sys/compat/linux/linux_misc.c 2009-06-16 15:54:53.000000= 000 -0500 +++ ./sys/compat/linux/linux_misc.c 2009-06-16 13:56:19.000000000 -0500 @@ -1132,7 +1132,7 @@ linux_setgroups(struct thread *td, struct linux_setgroups_args *args) { struct ucred *newcred, *oldcred; - l_gid_t linux_gidset[NGROUPS]; + l_gid_t *linux_gidset; gid_t *bsd_gidset; int ngrp, error; struct proc *p; @@ -1140,13 +1140,14 @@ ngrp =3D args->gidsetsize; if (ngrp < 0 || ngrp >=3D NGROUPS) return (EINVAL); + linux_gidset =3D malloc(ngrp * sizeof(*linux_gidset), M_TEMP, M_WAITOK); error =3D copyin(args->grouplist, linux_gidset, ngrp * sizeof(l_gid_t)); if (error) - return (error); + goto out; newcred =3D crget(); p =3D td->td_proc; PROC_LOCK(p); - oldcred =3D p->p_ucred; + oldcred =3D crcopysafe(p, newcred); =20 /* * cr_groups[0] holds egid. Setting the whole set from @@ -1157,10 +1158,9 @@ if ((error =3D priv_check_cred(oldcred, PRIV_CRED_SETGROUPS, 0)) !=3D 0) { PROC_UNLOCK(p); crfree(newcred); - return (error); + goto out; } =20 - crcopy(newcred, oldcred); if (ngrp > 0) { newcred->cr_ngroups =3D ngrp + 1; =20 @@ -1177,14 +1177,17 @@ p->p_ucred =3D newcred; PROC_UNLOCK(p); crfree(oldcred); - return (0); + error =3D 0; +out: + free(linux_gidset, M_TEMP); + return (error); } =20 int linux_getgroups(struct thread *td, struct linux_getgroups_args *args) { struct ucred *cred; - l_gid_t linux_gidset[NGROUPS]; + l_gid_t *linux_gidset; gid_t *bsd_gidset; int bsd_gidsetsz, ngrp, error; =20 @@ -1207,13 +1210,16 @@ return (EINVAL); =20 ngrp =3D 0; + linux_gidset =3D malloc(bsd_gidsetsz * sizeof(*linux_gidset), + M_TEMP, M_WAITOK); while (ngrp < bsd_gidsetsz) { linux_gidset[ngrp] =3D bsd_gidset[ngrp + 1]; ngrp++; } =20 - if ((error =3D copyout(linux_gidset, args->grouplist, - ngrp * sizeof(l_gid_t)))) + error =3D copyout(linux_gidset, args->grouplist, ngrp * sizeof(l_gid_t)); + free(linux_gidset, M_TEMP); + if (error) return (error); =20 td->td_retval[0] =3D ngrp; diff -ru --exclude=3D.svn --exclude=3Dcompile --exclude=3Dcardbus.c --ignor= e-matching=3D'$FreeBSD:' /usr/fsvn/head/sys/compat/linux/linux_uid16.c ./sy= s/compat/linux/linux_uid16.c --- /usr/fsvn/head/sys/compat/linux/linux_uid16.c 2009-06-16 15:54:53.00000= 0000 -0500 +++ ./sys/compat/linux/linux_uid16.c 2009-05-28 16:40:33.000000000 -0500 @@ -98,7 +98,7 @@ linux_setgroups16(struct thread *td, struct linux_setgroups16_args *args) { struct ucred *newcred, *oldcred; - l_gid16_t linux_gidset[NGROUPS]; + l_gid16_t *linux_gidset; gid_t *bsd_gidset; int ngrp, error; struct proc *p; @@ -111,13 +111,14 @@ ngrp =3D args->gidsetsize; if (ngrp < 0 || ngrp >=3D NGROUPS) return (EINVAL); + linux_gidset =3D malloc(ngrp * sizeof(*linux_gidset), M_TEMP, M_WAITOK); error =3D copyin(args->gidset, linux_gidset, ngrp * sizeof(l_gid16_t)); if (error) return (error); newcred =3D crget(); p =3D td->td_proc; PROC_LOCK(p); - oldcred =3D p->p_ucred; + oldcred =3D crcopysafe(p, newcred); =20 /* * cr_groups[0] holds egid. Setting the whole set from @@ -128,10 +129,9 @@ if ((error =3D priv_check_cred(oldcred, PRIV_CRED_SETGROUPS, 0)) !=3D 0) { PROC_UNLOCK(p); crfree(newcred); - return (error); + goto out; } =20 - crcopy(newcred, oldcred); if (ngrp > 0) { newcred->cr_ngroups =3D ngrp + 1; =20 @@ -149,14 +149,17 @@ p->p_ucred =3D newcred; PROC_UNLOCK(p); crfree(oldcred); - return (0); + error =3D 0; +out: + free(linux_gidset, M_TEMP); + return (error); } =20 int linux_getgroups16(struct thread *td, struct linux_getgroups16_args *args) { struct ucred *cred; - l_gid16_t linux_gidset[NGROUPS]; + l_gid16_t *linux_gidset; gid_t *bsd_gidset; int bsd_gidsetsz, ngrp, error; =20 @@ -184,12 +187,15 @@ return (EINVAL); =20 ngrp =3D 0; + linux_gidset =3D malloc(bsd_gidsetsz * sizeof(*linux_gidset), + M_TEMP, M_WAITOK); while (ngrp < bsd_gidsetsz) { linux_gidset[ngrp] =3D bsd_gidset[ngrp + 1]; ngrp++; } =20 error =3D copyout(linux_gidset, args->gidset, ngrp * sizeof(l_gid16_t)); + free(linux_gidset, M_TEMP); if (error) return (error); =20 diff -ru --exclude=3D.svn --exclude=3Dcompile --exclude=3Dcardbus.c --ignor= e-matching=3D'$FreeBSD:' /usr/fsvn/head/sys/fs/nfs/nfs_commonport.c ./sys/f= s/nfs/nfs_commonport.c --- /usr/fsvn/head/sys/fs/nfs/nfs_commonport.c 2009-05-29 12:48:03.00000000= 0 -0500 +++ ./sys/fs/nfs/nfs_commonport.c 2009-06-09 08:49:37.000000000 -0500 @@ -220,14 +220,9 @@ void newnfs_copycred(struct nfscred *nfscr, struct ucred *cr) { - int ngroups, i; =20 cr->cr_uid =3D nfscr->nfsc_uid; - ngroups =3D (nfscr->nfsc_ngroups < NGROUPS) ? - nfscr->nfsc_ngroups : NGROUPS; - for (i =3D 0; i < ngroups; i++) - cr->cr_groups[i] =3D nfscr->nfsc_groups[i]; - cr->cr_ngroups =3D ngroups; + crsetgroups(cr, nfscr->nfsc_ngroups, nfscr->nfsc_groups); } =20 /* diff -ru --exclude=3D.svn --exclude=3Dcompile --exclude=3Dcardbus.c --ignor= e-matching=3D'$FreeBSD:' /usr/fsvn/head/sys/fs/nfsclient/nfs_clport.c ./sys= /fs/nfsclient/nfs_clport.c --- /usr/fsvn/head/sys/fs/nfsclient/nfs_clport.c 2009-05-29 12:48:03.000000= 000 -0500 +++ ./sys/fs/nfsclient/nfs_clport.c 2009-06-05 15:33:54.000000000 -0500 @@ -976,14 +976,12 @@ void newnfs_copyincred(struct ucred *cr, struct nfscred *nfscr) { - int ngroups, i; + int i; =20 nfscr->nfsc_uid =3D cr->cr_uid; - ngroups =3D (cr->cr_ngroups > NGROUPS) ? NGROUPS : - cr->cr_ngroups; - for (i =3D 0; i < ngroups; i++) + nfscr->nfsc_ngroups =3D MIN(cr->cr_ngroups, XU_NGROUPS); + for (i =3D 0; i < nfscr->nfsc_ngroups; i++) nfscr->nfsc_groups[i] =3D cr->cr_groups[i]; - nfscr->nfsc_ngroups =3D ngroups; } =20 =20 diff -ru --exclude=3D.svn --exclude=3Dcompile --exclude=3Dcardbus.c --ignor= e-matching=3D'$FreeBSD:' /usr/fsvn/head/sys/fs/nfsserver/nfs_nfsdport.c ./s= ys/fs/nfsserver/nfs_nfsdport.c --- /usr/fsvn/head/sys/fs/nfsserver/nfs_nfsdport.c 2009-06-05 15:33:50.0000= 00000 -0500 +++ ./sys/fs/nfsserver/nfs_nfsdport.c 2009-06-05 16:02:29.000000000 -0500 @@ -2360,7 +2360,6 @@ nfsd_excred(struct nfsrv_descript *nd, struct nfsexstuff *exp, struct ucred *credanon) { - int i; int error =3D 0; =20 /* @@ -2403,9 +2402,8 @@ (nd->nd_flag & ND_AUTHNONE))) { nd->nd_cred->cr_uid =3D credanon->cr_uid; nd->nd_cred->cr_gid =3D credanon->cr_gid; - for (i =3D 0; i < credanon->cr_ngroups && i < NGROUPS; i++) - nd->nd_cred->cr_groups[i] =3D credanon->cr_groups[i]; - nd->nd_cred->cr_ngroups =3D i; + crsetgroups(nd->nd_cred, credanon->cr_ngroups, + credanon->cr_groups); } return (0); } diff -ru --exclude=3D.svn --exclude=3Dcompile --exclude=3Dcardbus.c --ignor= e-matching=3D'$FreeBSD:' /usr/fsvn/head/sys/fs/nfsserver/nfs_nfsdstate.c ./= sys/fs/nfsserver/nfs_nfsdstate.c --- /usr/fsvn/head/sys/fs/nfsserver/nfs_nfsdstate.c 2009-06-16 13:55:57.000= 000000 -0500 +++ ./sys/fs/nfsserver/nfs_nfsdstate.c 2009-06-16 13:56:18.000000000 -0500 @@ -3577,7 +3577,6 @@ nd->nd_repstat =3D 0; cred->cr_uid =3D clp->lc_uid; cred->cr_gid =3D clp->lc_gid; - cred->cr_groups[0] =3D clp->lc_gid; callback =3D clp->lc_callback; NFSUNLOCKSTATE(); cred->cr_ngroups =3D 1; diff -ru --exclude=3D.svn --exclude=3Dcompile --exclude=3Dcardbus.c --ignor= e-matching=3D'$FreeBSD:' /usr/fsvn/head/sys/fs/portalfs/portal.h ./sys/fs/p= ortalfs/portal.h --- /usr/fsvn/head/sys/fs/portalfs/portal.h 2009-01-22 10:06:01.000000000 -= 0600 +++ ./sys/fs/portalfs/portal.h 2009-06-05 15:33:54.000000000 -0500 @@ -43,7 +43,7 @@ int pcr_flag; /* File open mode */ uid_t pcr_uid; /* From ucred */ short pcr_ngroups; /* From ucred */ - gid_t pcr_groups[NGROUPS]; /* From ucred */ + gid_t pcr_groups[XU_NGROUPS]; /* From ucred */ }; =20 #ifdef _KERNEL diff -ru --exclude=3D.svn --exclude=3Dcompile --exclude=3Dcardbus.c --ignor= e-matching=3D'$FreeBSD:' /usr/fsvn/head/sys/fs/portalfs/portal_vnops.c ./sy= s/fs/portalfs/portal_vnops.c --- /usr/fsvn/head/sys/fs/portalfs/portal_vnops.c 2009-01-22 10:06:01.00000= 0000 -0600 +++ ./sys/fs/portalfs/portal_vnops.c 2009-06-05 15:33:54.000000000 -0500 @@ -311,8 +311,9 @@ =20 pcred.pcr_flag =3D ap->a_mode; pcred.pcr_uid =3D ap->a_cred->cr_uid; - pcred.pcr_ngroups =3D ap->a_cred->cr_ngroups; - bcopy(ap->a_cred->cr_groups, pcred.pcr_groups, NGROUPS * sizeof(gid_t)); + pcred.pcr_ngroups =3D MIN(ap->a_cred->cr_ngroups, XU_NGROUPS); + bcopy(ap->a_cred->cr_groups, pcred.pcr_groups, + pcred.pcr_ngroups * sizeof(gid_t)); aiov[0].iov_base =3D (caddr_t) &pcred; aiov[0].iov_len =3D sizeof(pcred); aiov[1].iov_base =3D pt->pt_arg; diff -ru --exclude=3D.svn --exclude=3Dcompile --exclude=3Dcardbus.c --ignor= e-matching=3D'$FreeBSD:' /usr/fsvn/head/sys/fs/unionfs/union_vnops.c ./sys/= fs/unionfs/union_vnops.c --- /usr/fsvn/head/sys/fs/unionfs/union_vnops.c 2009-04-12 15:26:52.0000000= 00 -0500 +++ ./sys/fs/unionfs/union_vnops.c 2009-06-05 15:33:54.000000000 -0500 @@ -638,7 +638,6 @@ uid_t uid; /* upper side vnode's uid */ gid_t gid; /* upper side vnode's gid */ u_short vmode; /* upper side vnode's mode */ - gid_t *gp; u_short mask; =20 mask =3D 0; @@ -659,17 +658,14 @@ =20 /* check group */ count =3D 0; - gp =3D cred->cr_groups; - for (; count < cred->cr_ngroups; count++, gp++) { - if (gid =3D=3D *gp) { - if (accmode & VEXEC) - mask |=3D S_IXGRP; - if (accmode & VREAD) - mask |=3D S_IRGRP; - if (accmode & VWRITE) - mask |=3D S_IWGRP; - return ((vmode & mask) =3D=3D mask ? 0 : EACCES); - } + if (groupmember(gid, cred)) { + if (accmode & VEXEC) + mask |=3D S_IXGRP; + if (accmode & VREAD) + mask |=3D S_IRGRP; + if (accmode & VWRITE) + mask |=3D S_IWGRP; + return ((vmode & mask) =3D=3D mask ? 0 : EACCES); } =20 /* check other */ diff -ru --exclude=3D.svn --exclude=3Dcompile --exclude=3Dcardbus.c --ignor= e-matching=3D'$FreeBSD:' /usr/fsvn/head/sys/i386/ibcs2/ibcs2_misc.c ./sys/i= 386/ibcs2/ibcs2_misc.c --- /usr/fsvn/head/sys/i386/ibcs2/ibcs2_misc.c 2009-06-16 15:54:53.00000000= 0 -0500 +++ ./sys/i386/ibcs2/ibcs2_misc.c 2009-06-05 16:02:31.000000000 -0500 @@ -657,24 +657,29 @@ struct thread *td; struct ibcs2_getgroups_args *uap; { - ibcs2_gid_t iset[NGROUPS_MAX]; - gid_t gp[NGROUPS_MAX]; + ibcs2_gid_t *iset; + gid_t *gp; u_int i, ngrp; int error; =20 if (uap->gidsetsize < 0) return (EINVAL); ngrp =3D MIN(uap->gidsetsize, NGROUPS_MAX); + gp =3D malloc(ngrp * sizeof(*gp), M_TEMP, M_WAITOK); error =3D kern_getgroups(td, &ngrp, gp); if (error) - return (error); + goto out; if (uap->gidsetsize > 0) { + iset =3D malloc(ngrp * sizeof(*iset), M_TEMP, M_WAITOK); for (i =3D 0; i < ngrp; i++) iset[i] =3D (ibcs2_gid_t)gp[i]; error =3D copyout(iset, uap->gidset, ngrp * sizeof(ibcs2_gid_t)); + free(iset, M_TEMP); } if (error =3D=3D 0) td->td_retval[0] =3D ngrp; +out: + free(gp, M_TEMP); return (error); } =20 @@ -683,21 +688,31 @@ struct thread *td; struct ibcs2_setgroups_args *uap; { - ibcs2_gid_t iset[NGROUPS_MAX]; - gid_t gp[NGROUPS_MAX]; + ibcs2_gid_t *iset; + gid_t *gp; int error, i; =20 if (uap->gidsetsize < 0 || uap->gidsetsize > NGROUPS_MAX) return (EINVAL); - if (uap->gidsetsize && uap->gidset) { + if (uap->gidsetsize && uap->gidset =3D=3D NULL) + return (EINVAL); + gp =3D malloc(uap->gidsetsize * sizeof(*gp), M_TEMP, M_WAITOK); + if (uap->gidsetsize) { + iset =3D malloc(uap->gidsetsize * sizeof(*iset), M_TEMP, M_WAITOK); error =3D copyin(uap->gidset, iset, sizeof(ibcs2_gid_t) * uap->gidsetsize); - if (error) - return (error); + if (error) { + free(iset, M_TEMP); + goto out; + } for (i =3D 0; i < uap->gidsetsize; i++) gp[i] =3D (gid_t)iset[i]; } - return (kern_setgroups(td, uap->gidsetsize, gp)); + + error =3D kern_setgroups(td, uap->gidsetsize, gp); +out: + free(gp, M_TEMP); + return (error); } =20 int diff -ru --exclude=3D.svn --exclude=3Dcompile --exclude=3Dcardbus.c --ignor= e-matching=3D'$FreeBSD:' /usr/fsvn/head/sys/kern/kern_exec.c ./sys/kern/ker= n_exec.c --- /usr/fsvn/head/sys/kern/kern_exec.c 2009-06-16 15:54:34.000000000 -0500 +++ ./sys/kern/kern_exec.c 2009-06-12 01:13:11.000000000 -0500 @@ -579,6 +579,7 @@ * reset. */ PROC_LOCK(p); + oldcred =3D crcopysafe(p, newcred); if (sigacts_shared(p->p_sigacts)) { oldsigacts =3D p->p_sigacts; PROC_UNLOCK(p); @@ -629,7 +630,6 @@ * XXXMAC: For the time being, use NOSUID to also prohibit * transitions on the file system. */ - oldcred =3D p->p_ucred; credential_changing =3D 0; credential_changing |=3D (attr.va_mode & S_ISUID) && oldcred->cr_uid !=3D attr.va_uid; @@ -683,7 +683,6 @@ /* * Set the new credentials. */ - crcopy(newcred, oldcred); if (attr.va_mode & S_ISUID) change_euid(newcred, euip); if (attr.va_mode & S_ISGID) @@ -723,7 +722,6 @@ */ if (oldcred->cr_svuid !=3D oldcred->cr_uid || oldcred->cr_svgid !=3D oldcred->cr_gid) { - crcopy(newcred, oldcred); change_svuid(newcred, newcred->cr_uid); change_svgid(newcred, newcred->cr_gid); p->p_ucred =3D newcred; diff -ru --exclude=3D.svn --exclude=3Dcompile --exclude=3Dcardbus.c --ignor= e-matching=3D'$FreeBSD:' /usr/fsvn/head/sys/kern/kern_proc.c ./sys/kern/ker= n_proc.c --- /usr/fsvn/head/sys/kern/kern_proc.c 2009-06-16 15:54:34.000000000 -0500 +++ ./sys/kern/kern_proc.c 2009-06-05 16:02:28.000000000 -0500 @@ -730,10 +730,8 @@ kp->ki_uid =3D cred->cr_uid; kp->ki_ruid =3D cred->cr_ruid; kp->ki_svuid =3D cred->cr_svuid; - /* XXX bde doesn't like KI_NGROUPS */ - kp->ki_ngroups =3D min(cred->cr_ngroups, KI_NGROUPS); - bcopy(cred->cr_groups, kp->ki_groups, - kp->ki_ngroups * sizeof(gid_t)); + kp->ki_ngroups =3D cred->cr_ngroups; + kp->ki_groups =3D cred->cr_groups; kp->ki_rgid =3D cred->cr_rgid; kp->ki_svgid =3D cred->cr_svgid; kp->ki_cr_flags =3D cred->cr_flags; --- /usr/fsvn/head/sys/kern/kern_prot.c 2009-06-16 15:54:34.000000000 -0500 +++ ./sys/kern/kern_prot.c 2009-06-17 18:24:56.000000000 -0500 @@ -82,6 +82,10 @@ =20 SYSCTL_NODE(_security, OID_AUTO, bsd, CTLFLAG_RW, 0, "BSD security policy"= ); =20 +static void crextend(struct ucred *cr, int n); +static void crsetgroups_locked(struct ucred *cr, int ngrp, + gid_t *groups); + #ifndef _SYS_SYSPROTO_H_ struct getpid_args { int dummy; @@ -276,18 +280,21 @@ int getgroups(struct thread *td, register struct getgroups_args *uap) { - gid_t groups[NGROUPS]; + gid_t *groups; u_int ngrp; int error; =20 ngrp =3D MIN(uap->gidsetsize, NGROUPS); + groups =3D malloc(ngrp * sizeof(*groups), M_TEMP, M_WAITOK); error =3D kern_getgroups(td, &ngrp, groups); if (error) - return (error); + goto out; if (uap->gidsetsize > 0) error =3D copyout(groups, uap->gidset, ngrp * sizeof(gid_t)); if (error =3D=3D 0) td->td_retval[0] =3D ngrp; +out: + free(groups, M_TEMP); return (error); } =20 @@ -486,7 +493,10 @@ newcred =3D crget(); uip =3D uifind(uid); PROC_LOCK(p); - oldcred =3D p->p_ucred; + /* + * Copy credentials so other references do not see our changes. + */ + oldcred =3D crcopysafe(p, newcred); =20 #ifdef MAC error =3D mac_cred_check_setuid(oldcred, uid); @@ -521,10 +531,6 @@ (error =3D priv_check_cred(oldcred, PRIV_CRED_SETUID, 0)) !=3D 0) goto fail; =20 - /* - * Copy credentials so other references do not see our changes. - */ - crcopy(newcred, oldcred); #ifdef _POSIX_SAVED_IDS /* * Do we have "appropriate privileges" (are we root or uid =3D=3D euid) @@ -598,7 +604,10 @@ newcred =3D crget(); euip =3D uifind(euid); PROC_LOCK(p); - oldcred =3D p->p_ucred; + /* + * Copy credentials so other references do not see our changes. + */ + oldcred =3D crcopysafe(p, newcred); =20 #ifdef MAC error =3D mac_cred_check_seteuid(oldcred, euid); @@ -612,8 +621,7 @@ goto fail; =20 /* - * Everything's okay, do it. Copy credentials so other references do - * not see our changes. + * Everything's okay, do it. */ crcopy(newcred, oldcred); if (oldcred->cr_uid !=3D euid) { @@ -651,7 +659,7 @@ AUDIT_ARG(gid, gid); newcred =3D crget(); PROC_LOCK(p); - oldcred =3D p->p_ucred; + oldcred =3D crcopysafe(p, newcred); =20 #ifdef MAC error =3D mac_cred_check_setgid(oldcred, gid); @@ -680,7 +688,6 @@ (error =3D priv_check_cred(oldcred, PRIV_CRED_SETGID, 0)) !=3D 0) goto fail; =20 - crcopy(newcred, oldcred); #ifdef _POSIX_SAVED_IDS /* * Do we have "appropriate privileges" (are we root or gid =3D=3D egid) @@ -750,7 +757,7 @@ AUDIT_ARG(egid, egid); newcred =3D crget(); PROC_LOCK(p); - oldcred =3D p->p_ucred; + oldcred =3D crcopysafe(p, newcred); =20 #ifdef MAC error =3D mac_cred_check_setegid(oldcred, egid); @@ -763,7 +770,6 @@ (error =3D priv_check_cred(oldcred, PRIV_CRED_SETEGID, 0)) !=3D 0) goto fail; =20 - crcopy(newcred, oldcred); if (oldcred->cr_groups[0] !=3D egid) { change_egid(newcred, egid); setsugid(p); @@ -789,15 +795,19 @@ int setgroups(struct thread *td, struct setgroups_args *uap) { - gid_t groups[NGROUPS]; + gid_t *groups =3D NULL; int error; =20 if (uap->gidsetsize > NGROUPS) return (EINVAL); + groups =3D malloc(uap->gidsetsize * sizeof(gid_t), M_TEMP, M_WAITOK); error =3D copyin(uap->gidset, groups, uap->gidsetsize * sizeof(gid_t)); if (error) - return (error); - return (kern_setgroups(td, uap->gidsetsize, groups)); + goto out; + error =3D kern_setgroups(td, uap->gidsetsize, groups); +out: + free(groups, M_TEMP); + return (error); } =20 int @@ -811,8 +821,9 @@ return (EINVAL); AUDIT_ARG(groupset, groups, ngrp); newcred =3D crget(); + crextend(newcred, ngrp); PROC_LOCK(p); - oldcred =3D p->p_ucred; + oldcred =3D crcopysafe(p, newcred); =20 #ifdef MAC error =3D mac_cred_check_setgroups(oldcred, ngrp, groups); @@ -824,11 +835,6 @@ if (error) goto fail; =20 - /* - * XXX A little bit lazy here. We could test if anything has - * changed before crcopy() and setting P_SUGID. - */ - crcopy(newcred, oldcred); if (ngrp < 1) { /* * setgroups(0, NULL) is a legitimate way of clearing the @@ -838,8 +844,7 @@ */ newcred->cr_ngroups =3D 1; } else { - bcopy(groups, newcred->cr_groups, ngrp * sizeof(gid_t)); - newcred->cr_ngroups =3D ngrp; + crsetgroups_locked(newcred, ngrp, groups); } setsugid(p); p->p_ucred =3D newcred; @@ -877,7 +882,7 @@ euip =3D uifind(euid); ruip =3D uifind(ruid); PROC_LOCK(p); - oldcred =3D p->p_ucred; + oldcred =3D crcopysafe(p, newcred); =20 #ifdef MAC error =3D mac_cred_check_setreuid(oldcred, ruid, euid); @@ -892,7 +897,6 @@ (error =3D priv_check_cred(oldcred, PRIV_CRED_SETREUID, 0)) !=3D 0) goto fail; =20 - crcopy(newcred, oldcred); if (euid !=3D (uid_t)-1 && oldcred->cr_uid !=3D euid) { change_euid(newcred, euip); setsugid(p); @@ -942,7 +946,7 @@ AUDIT_ARG(rgid, rgid); newcred =3D crget(); PROC_LOCK(p); - oldcred =3D p->p_ucred; + oldcred =3D crcopysafe(p, newcred); =20 #ifdef MAC error =3D mac_cred_check_setregid(oldcred, rgid, egid); @@ -957,7 +961,6 @@ (error =3D priv_check_cred(oldcred, PRIV_CRED_SETREGID, 0)) !=3D 0) goto fail; =20 - crcopy(newcred, oldcred); if (egid !=3D (gid_t)-1 && oldcred->cr_groups[0] !=3D egid) { change_egid(newcred, egid); setsugid(p); @@ -1013,7 +1016,7 @@ euip =3D uifind(euid); ruip =3D uifind(ruid); PROC_LOCK(p); - oldcred =3D p->p_ucred; + oldcred =3D crcopysafe(p, newcred); =20 #ifdef MAC error =3D mac_cred_check_setresuid(oldcred, ruid, euid, suid); @@ -1033,7 +1036,6 @@ (error =3D priv_check_cred(oldcred, PRIV_CRED_SETRESUID, 0)) !=3D 0) goto fail; =20 - crcopy(newcred, oldcred); if (euid !=3D (uid_t)-1 && oldcred->cr_uid !=3D euid) { change_euid(newcred, euip); setsugid(p); @@ -1090,7 +1092,7 @@ AUDIT_ARG(sgid, sgid); newcred =3D crget(); PROC_LOCK(p); - oldcred =3D p->p_ucred; + oldcred =3D crcopysafe(p, newcred); =20 #ifdef MAC error =3D mac_cred_check_setresgid(oldcred, rgid, egid, sgid); @@ -1110,7 +1112,6 @@ (error =3D priv_check_cred(oldcred, PRIV_CRED_SETRESGID, 0)) !=3D 0) goto fail; =20 - crcopy(newcred, oldcred); if (egid !=3D (gid_t)-1 && oldcred->cr_groups[0] !=3D egid) { change_egid(newcred, egid); setsugid(p); @@ -1780,6 +1781,7 @@ #ifdef MAC mac_cred_init(cr); #endif + crextend(cr, XU_NGROUPS); return (cr); } =20 @@ -1829,6 +1831,7 @@ #ifdef MAC mac_cred_destroy(cr); #endif + free(cr->cr_groups, M_CRED); free(cr, M_CRED); } } @@ -1854,6 +1857,7 @@ bcopy(&src->cr_startcopy, &dest->cr_startcopy, (unsigned)((caddr_t)&src->cr_endcopy - (caddr_t)&src->cr_startcopy)); + crsetgroups(dest, src->cr_ngroups, src->cr_groups); uihold(dest->cr_uidinfo); uihold(dest->cr_ruidinfo); prison_hold(dest->cr_prison); @@ -1888,12 +1892,16 @@ void cru2x(struct ucred *cr, struct xucred *xcr) { + int ngroups; =20 bzero(xcr, sizeof(*xcr)); xcr->cr_version =3D XUCRED_VERSION; xcr->cr_uid =3D cr->cr_uid; - xcr->cr_ngroups =3D cr->cr_ngroups; - bcopy(cr->cr_groups, xcr->cr_groups, sizeof(cr->cr_groups)); + + ngroups =3D MIN(cr->cr_ngroups, XU_NGROUPS); + xcr->cr_ngroups =3D ngroups; + bcopy(cr->cr_groups, xcr->cr_groups, + ngroups * sizeof(*cr->cr_groups)); } =20 /* @@ -1915,6 +1923,97 @@ crfree(cred); } =20 +struct ucred * +crcopysafe(struct proc *p, struct ucred *cr) +{ + struct ucred *oldcred; + int groups; + + PROC_LOCK_ASSERT(p, MA_OWNED); + + oldcred =3D p->p_ucred; + while (cr->cr_agroups < oldcred->cr_agroups) { + groups =3D oldcred->cr_agroups; + PROC_UNLOCK(p); + crextend(cr, groups); + PROC_LOCK(p); + oldcred =3D p->p_ucred; + } + crcopy(cr, oldcred); + + return (oldcred); +} + +/* + * Extend the passed in credential to hold n items. + */ +static void +crextend(struct ucred *cr, int n) +{ + int cnt; + + /* Truncate? */ + if (n <=3D cr->cr_agroups) + return; + + /* + * We extend by 2 each time since we're using a power of two + * allocator until we need enough groups to fill a page. + * Once we're allocating multiple pages, only allocate as many + * as we actually need. The case of processes needing a + * non-power of two number of pages seems more likely than + * a real world process that adds thousands of groups one at a + * time. + */ + if ( n < PAGE_SIZE / sizeof(gid_t) ) { + if (cr->cr_agroups =3D=3D 0) + cnt =3D MINALLOCSIZE / sizeof(gid_t); + else + cnt =3D cr->cr_agroups * 2; + + while (cnt < n) + cnt *=3D 2; + } else + cnt =3D roundup2(n, PAGE_SIZE / sizeof(gid_t)); + + /* Free the old array. */ + if (cr->cr_groups) + free(cr->cr_groups, M_CRED); + + cr->cr_groups =3D malloc(cnt * sizeof(gid_t), M_CRED, M_WAITOK | M_ZERO); + cr->cr_agroups =3D cnt; +} + +/* + * Copy groups in to a credential, preserving any necessicary invariants + * (i.e. sorting in the future). crextend() must have been called + * before hand to ensure sufficient space is available. If=20 + */ +static void +crsetgroups_locked(struct ucred *cr, int ngrp, gid_t *groups) +{ +=09 + KASSERT(cr->cr_agroups >=3D ngrp, ("cr_ngroups is too small")); + + bcopy(groups, cr->cr_groups, ngrp * sizeof(gid_t)); + cr->cr_ngroups =3D ngrp; +} + +/* + * Copy groups in to a credential after expanding it if required. + * Truncate the list to NGROUPS if it is too large. + */ +void +crsetgroups(struct ucred *cr, int ngrp, gid_t *groups) +{ + + if (ngrp > NGROUPS) + ngrp =3D NGROUPS; + + crextend(cr, ngrp); + crsetgroups_locked(cr, ngrp, groups); +} + /* * Get login name, if available. */ diff -ru --exclude=3D.svn --exclude=3Dcompile --exclude=3Dcardbus.c --ignor= e-matching=3D'$FreeBSD:' /usr/fsvn/head/sys/kern/vfs_export.c ./sys/kern/vf= s_export.c --- /usr/fsvn/head/sys/kern/vfs_export.c 2009-05-29 12:48:02.000000000 -0500 +++ ./sys/kern/vfs_export.c 2009-06-05 15:33:54.000000000 -0500 @@ -120,9 +120,8 @@ np->netc_exflags =3D argp->ex_flags; np->netc_anon =3D crget(); np->netc_anon->cr_uid =3D argp->ex_anon.cr_uid; - np->netc_anon->cr_ngroups =3D argp->ex_anon.cr_ngroups; - bcopy(argp->ex_anon.cr_groups, np->netc_anon->cr_groups, - sizeof(np->netc_anon->cr_groups)); + crsetgroups(np->netc_anon, argp->ex_anon.cr_ngroups, + argp->ex_anon.cr_groups); np->netc_numsecflavors =3D argp->ex_numsecflavors; bcopy(argp->ex_secflavors, np->netc_secflavors, sizeof(np->netc_secflavors)); @@ -205,9 +204,8 @@ np->netc_exflags =3D argp->ex_flags; np->netc_anon =3D crget(); np->netc_anon->cr_uid =3D argp->ex_anon.cr_uid; - np->netc_anon->cr_ngroups =3D argp->ex_anon.cr_ngroups; - bcopy(argp->ex_anon.cr_groups, np->netc_anon->cr_groups, - sizeof(np->netc_anon->cr_groups)); + crsetgroups(np->netc_anon, argp->ex_anon.cr_ngroups, + np->netc_anon->cr_groups); np->netc_numsecflavors =3D argp->ex_numsecflavors; bcopy(argp->ex_secflavors, np->netc_secflavors, sizeof(np->netc_secflavors)); diff -ru --exclude=3D.svn --exclude=3Dcompile --exclude=3Dcardbus.c --ignor= e-matching=3D'$FreeBSD:' /usr/fsvn/head/sys/netinet/ipfw/ip_fw2.c ./sys/net= inet/ipfw/ip_fw2.c --- /usr/fsvn/head/sys/netinet/ipfw/ip_fw2.c 2009-06-12 00:52:26.000000000 = -0500 +++ ./sys/netinet/ipfw/ip_fw2.c 2009-06-17 13:42:23.000000000 -0500 @@ -135,19 +135,6 @@ struct ip_fw *ip_fw_default_rule; =20 /* - * Data structure to cache our ucred related - * information. This structure only gets used if - * the user specified UID/GID based constraints in - * a firewall rule. - */ -struct ip_fw_ugid { - gid_t fw_groups[NGROUPS]; - int fw_ngroups; - uid_t fw_uid; - int fw_prid; -}; - -/* * list of rules for layer 3 */ #ifdef VIMAGE_GLOBALS @@ -2009,22 +1996,10 @@ return (0); } =20 -static void -fill_ugid_cache(struct inpcb *inp, struct ip_fw_ugid *ugp) -{ - struct ucred *cr; - - cr =3D inp->inp_cred; - ugp->fw_prid =3D jailed(cr) ? cr->cr_prison->pr_id : -1; - ugp->fw_uid =3D cr->cr_uid; - ugp->fw_ngroups =3D cr->cr_ngroups; - bcopy(cr->cr_groups, ugp->fw_groups, sizeof(ugp->fw_groups)); -} - static int check_uidgid(ipfw_insn_u32 *insn, int proto, struct ifnet *oif, struct in_addr dst_ip, u_int16_t dst_port, struct in_addr src_ip, - u_int16_t src_port, struct ip_fw_ugid *ugp, int *ugid_lookupp, + u_int16_t src_port, struct ucred **uc, int *ugid_lookupp, struct inpcb *inp) { INIT_VNET_INET(curvnet); @@ -2032,7 +2007,6 @@ int wildcard; struct inpcb *pcb; int match; - gid_t *gp; =20 /* * Check to see if the UDP or TCP stack supplied us with @@ -2042,7 +2016,7 @@ if (inp && *ugid_lookupp =3D=3D 0) { INP_LOCK_ASSERT(inp); if (inp->inp_socket !=3D NULL) { - fill_ugid_cache(inp, ugp); + *uc =3D crhold(inp->inp_cred); *ugid_lookupp =3D 1; } else *ugid_lookupp =3D -1; @@ -2075,7 +2049,7 @@ dst_ip, htons(dst_port), wildcard, NULL); if (pcb !=3D NULL) { - fill_ugid_cache(pcb, ugp); + *uc =3D crhold(inp->inp_cred); *ugid_lookupp =3D 1; } INP_INFO_RUNLOCK(pi); @@ -2091,16 +2065,11 @@ } }=20 if (insn->o.opcode =3D=3D O_UID) - match =3D (ugp->fw_uid =3D=3D (uid_t)insn->d[0]); - else if (insn->o.opcode =3D=3D O_GID) { - for (gp =3D ugp->fw_groups; - gp < &ugp->fw_groups[ugp->fw_ngroups]; gp++) - if (*gp =3D=3D (gid_t)insn->d[0]) { - match =3D 1; - break; - } - } else if (insn->o.opcode =3D=3D O_JAIL) - match =3D (ugp->fw_prid =3D=3D (int)insn->d[0]); + match =3D ((*uc)->cr_uid =3D=3D (uid_t)insn->d[0]); + else if (insn->o.opcode =3D=3D O_GID) + match =3D groupmember((gid_t)insn->d[0], *uc); + else if (insn->o.opcode =3D=3D O_JAIL) + match =3D ((*uc)->cr_prison->pr_id =3D=3D (int)insn->d[0]); return match; } =20 @@ -2178,8 +2147,8 @@ * these types of constraints, as well as decrease contention * on pcb related locks. */ - struct ip_fw_ugid fw_ugid_cache; - int ugid_lookup =3D 0; + struct ucred *ucred_cache =3D NULL; + int ucred_lookup =3D 0; =20 /* * divinput_flags If non-zero, set to the IP_FW_DIVERT_*_FLAG @@ -2641,8 +2610,8 @@ (ipfw_insn_u32 *)cmd, proto, oif, dst_ip, dst_port, - src_ip, src_port, &fw_ugid_cache, - &ugid_lookup, args->inp); + src_ip, src_port, &ucred_cache, + &ucred_lookup, args->inp); break; =20 case O_RECV: @@ -3270,6 +3239,8 @@ /* XXX statistic */ /* drop packet */ IPFW_RUNLOCK(chain); + if (ucred_cache !=3D NULL) + crfree(ucred_cache); return (IP_FW_DENY); } dt =3D (struct divert_tag *)(mtag+1); @@ -3475,6 +3446,8 @@ } /* end of outer for, scan rules */ printf("ipfw: ouch!, skip past end of rules, denying packet\n"); IPFW_RUNLOCK(chain); + if (ucred_cache !=3D NULL) + crfree(ucred_cache); return (IP_FW_DENY); =20 done: @@ -3483,6 +3456,8 @@ f->bcnt +=3D pktlen; f->timestamp =3D time_uptime; IPFW_RUNLOCK(chain); + if (ucred_cache !=3D NULL) + crfree(ucred_cache); return (retval); =20 pullup_failed: diff -ru --exclude=3D.svn --exclude=3Dcompile --exclude=3Dcardbus.c --ignor= e-matching=3D'$FreeBSD:' /usr/fsvn/head/sys/nfsserver/nfs_srvsock.c ./sys/n= fsserver/nfs_srvsock.c --- /usr/fsvn/head/sys/nfsserver/nfs_srvsock.c 2009-06-16 15:54:40.00000000= 0 -0500 +++ ./sys/nfsserver/nfs_srvsock.c 2009-06-09 08:49:37.000000000 -0500 @@ -370,11 +370,11 @@ } tl =3D nfsm_dissect_nonblock(u_int32_t *, (len + 2) * NFSX_UNSIGNED); for (i =3D 1; i <=3D len; i++) - if (i < NGROUPS) + if (i < XU_NGROUPS) nd->nd_cr->cr_groups[i] =3D fxdr_unsigned(gid_t, *tl++); else tl++; - nd->nd_cr->cr_ngroups =3D (len >=3D NGROUPS) ? NGROUPS : (len + 1); + nd->nd_cr->cr_ngroups =3D MIN(XU_NGROUPS, len + 1); if (nd->nd_cr->cr_ngroups > 1) nfsrvw_sort(nd->nd_cr->cr_groups, nd->nd_cr->cr_ngroups); len =3D fxdr_unsigned(int, *++tl); diff -ru --exclude=3D.svn --exclude=3Dcompile --exclude=3Dcardbus.c --ignor= e-matching=3D'$FreeBSD:' /usr/fsvn/head/sys/nfsserver/nfs_srvsubs.c ./sys/n= fsserver/nfs_srvsubs.c --- /usr/fsvn/head/sys/nfsserver/nfs_srvsubs.c 2009-05-29 12:48:04.00000000= 0 -0500 +++ ./sys/nfsserver/nfs_srvsubs.c 2009-06-05 15:33:54.000000000 -0500 @@ -1181,9 +1181,7 @@ cred =3D nfsd->nd_cr; if (cred->cr_uid =3D=3D 0 || (exflags & MNT_EXPORTANON)) { cred->cr_uid =3D credanon->cr_uid; - for (i =3D 0; i < credanon->cr_ngroups && i < NGROUPS; i++) - cred->cr_groups[i] =3D credanon->cr_groups[i]; - cred->cr_ngroups =3D i; + crsetgroups(cred, credanon->cr_ngroups, credanon->cr_groups); } if (exflags & MNT_EXRDONLY) *rdonlyp =3D 1; diff -ru --exclude=3D.svn --exclude=3Dcompile --exclude=3Dcardbus.c --ignor= e-matching=3D'$FreeBSD:' /usr/fsvn/head/sys/rpc/rpcsec_gss/svc_rpcsec_gss.c= ./sys/rpc/rpcsec_gss/svc_rpcsec_gss.c --- /usr/fsvn/head/sys/rpc/rpcsec_gss/svc_rpcsec_gss.c 2009-06-16 13:55:57.= 000000000 -0500 +++ ./sys/rpc/rpcsec_gss/svc_rpcsec_gss.c 2009-06-16 13:56:18.000000000 -05= 00 @@ -449,11 +449,7 @@ cr =3D client->cl_cred =3D crget(); cr->cr_uid =3D cr->cr_ruid =3D cr->cr_svuid =3D uc->uid; cr->cr_rgid =3D cr->cr_svgid =3D uc->gid; - cr->cr_ngroups =3D uc->gidlen; - if (cr->cr_ngroups > NGROUPS) - cr->cr_ngroups =3D NGROUPS; - for (i =3D 0; i < cr->cr_ngroups; i++) - cr->cr_groups[i] =3D uc->gidlist[i]; + crsetgroups(cr, uc->gidlen, uc->gidlist); *crp =3D crhold(cr); =20 return (TRUE); diff -ru --exclude=3D.svn --exclude=3Dcompile --exclude=3Dcardbus.c --ignor= e-matching=3D'$FreeBSD:' /usr/fsvn/head/sys/rpc/svc_auth.c ./sys/rpc/svc_au= th.c --- /usr/fsvn/head/sys/rpc/svc_auth.c 2009-06-12 00:52:17.000000000 -0500 +++ ./sys/rpc/svc_auth.c 2009-06-12 01:13:12.000000000 -0500 @@ -166,7 +166,7 @@ svc_getcred(struct svc_req *rqst, struct ucred **crp, int *flavorp) { struct ucred *cr =3D NULL; - int flavor, i; + int flavor; struct xucred *xcr; =20 flavor =3D rqst->rq_cred.oa_flavor; @@ -178,9 +178,7 @@ xcr =3D (struct xucred *) rqst->rq_clntcred; cr =3D crget(); cr->cr_uid =3D cr->cr_ruid =3D cr->cr_svuid =3D xcr->cr_uid; - cr->cr_ngroups =3D xcr->cr_ngroups; - for (i =3D 0; i < xcr->cr_ngroups; i++) - cr->cr_groups[i] =3D xcr->cr_groups[i]; + crsetgroups(cr, xcr->cr_ngroups, xcr->cr_groups); cr->cr_rgid =3D cr->cr_svgid =3D cr->cr_groups[0]; cr->cr_prison =3D &prison0; prison_hold(cr->cr_prison); diff -ru --exclude=3D.svn --exclude=3Dcompile --exclude=3Dcardbus.c --ignor= e-matching=3D'$FreeBSD:' /usr/fsvn/head/sys/rpc/svc_auth_unix.c ./sys/rpc/s= vc_auth_unix.c --- /usr/fsvn/head/sys/rpc/svc_auth_unix.c 2009-01-22 10:05:57.000000000 -0= 600 +++ ./sys/rpc/svc_auth_unix.c 2009-06-09 08:49:37.000000000 -0500 @@ -95,13 +95,13 @@ goto done; } for (i =3D 0; i < gid_len; i++) { - if (i + 1 < NGROUPS) + if (i + 1 < XU_NGROUPS) xcr->cr_groups[i + 1] =3D IXDR_GET_INT32(buf); else buf++; } - if (gid_len + 1 > NGROUPS) - xcr->cr_ngroups =3D NGROUPS; + if (gid_len + 1 > XU_NGROUPS) + xcr->cr_ngroups =3D XU_NGROUPS; else xcr->cr_ngroups =3D gid_len + 1; =20 diff -ru --exclude=3D.svn --exclude=3Dcompile --exclude=3Dcardbus.c --ignor= e-matching=3D'$FreeBSD:' /usr/fsvn/head/sys/sys/param.h ./sys/sys/param.h --- /usr/fsvn/head/sys/sys/param.h 2009-06-16 13:55:59.000000000 -0500 +++ ./sys/sys/param.h 2009-06-16 13:56:20.000000000 -0500 @@ -77,7 +77,7 @@ #define MAXLOGNAME 17 /* max login name length (incl. NUL) */ #define MAXUPRC CHILD_MAX /* max simultaneous processes */ #define NCARGS ARG_MAX /* max bytes for an exec function */ -#define NGROUPS NGROUPS_MAX /* max number groups */ +#define NGROUPS NGROUPS_MAX+1 /* max number groups */ #define NOFILE OPEN_MAX /* max open files per process */ #define NOGROUP 65535 /* marker for empty group set member */ #define MAXHOSTNAMELEN 256 /* max hostname size */ diff -ru --exclude=3D.svn --exclude=3Dcompile --exclude=3Dcardbus.c --ignor= e-matching=3D'$FreeBSD:' /usr/fsvn/head/sys/sys/syslimits.h ./sys/sys/sysli= mits.h --- /usr/fsvn/head/sys/sys/syslimits.h 2009-01-22 10:06:22.000000000 -0600 +++ ./sys/sys/syslimits.h 2009-06-08 23:57:36.000000000 -0500 @@ -54,7 +54,9 @@ #define MAX_CANON 255 /* max bytes in term canon input line */ #define MAX_INPUT 255 /* max bytes in terminal input */ #define NAME_MAX 255 /* max bytes in a file name */ -#define NGROUPS_MAX 16 /* max supplemental group id's */ +#ifndef NGROUPS_MAX +#define NGROUPS_MAX 1023 /* max supplemental group id's */ +#endif #ifndef OPEN_MAX #define OPEN_MAX 64 /* max open files per process */ #endif --- /usr/fsvn/head/sys/sys/ucred.h 2009-06-16 15:54:53.000000000 -0500 +++ ./sys/sys/ucred.h 2009-06-17 18:23:49.000000000 -0500 @@ -48,8 +48,7 @@ uid_t cr_uid; /* effective user id */ uid_t cr_ruid; /* real user id */ uid_t cr_svuid; /* saved user id */ - short cr_ngroups; /* number of groups */ - gid_t cr_groups[NGROUPS]; /* groups */ + int cr_ngroups; /* number of groups */ gid_t cr_rgid; /* real group id */ gid_t cr_svgid; /* saved group id */ struct uidinfo *cr_uidinfo; /* per euid resource consumption */ @@ -61,11 +60,15 @@ #define cr_endcopy cr_label struct label *cr_label; /* MAC label */ struct auditinfo_addr cr_audit; /* Audit properties. */ + gid_t *cr_groups; /* groups */ + int cr_agroups; /* Available groups */ }; #define NOCRED ((struct ucred *)0) /* no credential available */ #define FSCRED ((struct ucred *)-1) /* filesystem credential */ #endif /* _KERNEL || _WANT_UCRED */ =20 +#define XU_NGROUPS 16 + /* * This is the external representation of struct ucred. */ @@ -73,7 +76,7 @@ u_int cr_version; /* structure layout version */ uid_t cr_uid; /* effective user id */ short cr_ngroups; /* number of groups */ - gid_t cr_groups[NGROUPS]; /* groups */ + gid_t cr_groups[XU_NGROUPS]; /* groups */ void *_cr_unused1; /* compatibility with old ucred */ }; #define XUCRED_VERSION 0 @@ -82,6 +85,7 @@ #define cr_gid cr_groups[0] =20 #ifdef _KERNEL +struct proc; struct thread; =20 void change_egid(struct ucred *newcred, gid_t egid); @@ -91,6 +95,7 @@ void change_svgid(struct ucred *newcred, gid_t svgid); void change_svuid(struct ucred *newcred, uid_t svuid); void crcopy(struct ucred *dest, struct ucred *src); +struct ucred *crcopysafe(struct proc *p, struct ucred *cr); struct ucred *crdup(struct ucred *cr); void cred_update_thread(struct thread *td); void crfree(struct ucred *cr); @@ -98,6 +103,7 @@ struct ucred *crhold(struct ucred *cr); int crshared(struct ucred *cr); void cru2x(struct ucred *cr, struct xucred *xcr); +void crsetgroups(struct ucred *cr, int n, gid_t *groups); int groupmember(gid_t gid, struct ucred *cred); #endif /* _KERNEL */ =20 diff -ru --exclude=3D.svn --exclude=3Dcompile --exclude=3Dcardbus.c --ignor= e-matching=3D'$FreeBSD:' /usr/fsvn/head/sys/sys/user.h ./sys/sys/user.h --- /usr/fsvn/head/sys/sys/user.h 2009-06-16 15:54:53.000000000 -0500 +++ ./sys/sys/user.h 2009-06-05 16:02:34.000000000 -0500 @@ -85,7 +85,7 @@ */ #define KI_NSPARE_INT 9 #define KI_NSPARE_LONG 12 -#define KI_NSPARE_PTR 7 +#define KI_NSPARE_PTR 6 =20 #ifdef __amd64__ #define KINFO_PROC_SIZE 1088 @@ -117,7 +117,6 @@ #define OCOMMLEN 16 /* size of returned thread name */ #define COMMLEN 19 /* size of returned ki_comm name */ #define KI_EMULNAMELEN 16 /* size of returned ki_emul */ -#define KI_NGROUPS 16 /* number of groups in ki_groups */ #define LOGNAMELEN 17 /* size of returned ki_login */ =20 struct kinfo_proc { @@ -151,7 +150,7 @@ gid_t ki_svgid; /* Saved effective group id */ short ki_ngroups; /* number of groups */ short ki_spare_short2; /* unused (just here for alignment) */ - gid_t ki_groups[KI_NGROUPS]; /* groups */ + uint32_t __was_ki_groups[16]; /* unused; left for bin compat */ vm_size_t ki_size; /* virtual size */ segsz_t ki_rssize; /* current resident set size in pages */ segsz_t ki_swrss; /* resident set size before last swap */ @@ -201,6 +200,7 @@ struct pcb *ki_pcb; /* kernel virtual addr of pcb */ void *ki_kstack; /* kernel virtual addr of stack */ void *ki_udata; /* User convenience pointer */ + gid_t *ki_groups; /* groups */ /* * When adding new variables, take space for pointers from the * front of ki_spareptrs, and longs from the end of ki_sparelongs. diff -ru --exclude=3D.svn --exclude=3Dcompile --exclude=3Dcardbus.c --ignor= e-matching=3D'$FreeBSD:' /usr/fsvn/head/sys/ufs/ufs/ufs_vnops.c ./sys/ufs/u= fs/ufs_vnops.c --- /usr/fsvn/head/sys/ufs/ufs/ufs_vnops.c 2009-06-16 13:55:57.000000000 -0= 500 +++ ./sys/ufs/ufs/ufs_vnops.c 2009-06-16 13:56:20.000000000 -0500 @@ -2266,6 +2266,7 @@ { #ifdef QUOTA struct ucred ucred, *ucp; + gid_t ucred_group; ucp =3D cnp->cn_cred; #endif /* @@ -2292,6 +2293,7 @@ refcount_init(&ucred.cr_ref, 1); ucred.cr_uid =3D ip->i_uid; ucred.cr_ngroups =3D 1; + ucred.cr_groups =3D &ucred_group; ucred.cr_groups[0] =3D pdir->i_gid; ucp =3D &ucred; #endif diff -ru --exclude=3D.svn --exclude=3Dcompile --exclude=3Dcardbus.c --ignor= e-matching=3D'$FreeBSD:' /usr/fsvn/head/usr.sbin/mount_portalfs/portald.h .= /usr.sbin/mount_portalfs/portald.h --- /usr/fsvn/head/usr.sbin/mount_portalfs/portald.h 2009-01-22 10:05:31.00= 0000000 -0600 +++ ./usr.sbin/mount_portalfs/portald.h 2009-06-17 13:41:26.000000000 -0500 @@ -36,6 +36,7 @@ */ =20 #include +#include #include =20 /* diff -ru --exclude=3D.svn --exclude=3Dcompile --exclude=3Dcardbus.c --ignor= e-matching=3D'$FreeBSD:' /usr/fsvn/head/usr.sbin/mountd/mountd.c ./usr.sbin= /mountd/mountd.c --- /usr/fsvn/head/usr.sbin/mountd/mountd.c 2009-06-16 15:54:05.000000000 -= 0500 +++ ./usr.sbin/mountd/mountd.c 2009-06-17 15:25:33.000000000 -0500 @@ -2644,7 +2644,7 @@ char *names; struct passwd *pw; struct group *gr; - gid_t groups[NGROUPS + 1]; + gid_t groups[XU_NGROUPS + 1]; int ngroups; =20 cr->cr_version =3D XUCRED_VERSION; @@ -2672,7 +2672,7 @@ return; } cr->cr_uid =3D pw->pw_uid; - ngroups =3D NGROUPS + 1; + ngroups =3D XU_NGROUPS + 1; if (getgrouplist(pw->pw_name, pw->pw_gid, groups, &ngroups)) syslog(LOG_ERR, "too many groups"); /* @@ -2697,7 +2697,7 @@ return; } cr->cr_ngroups =3D 0; - while (names !=3D NULL && *names !=3D '\0' && cr->cr_ngroups < NGROUPS) { + while (names !=3D NULL && *names !=3D '\0' && cr->cr_ngroups < XU_NGROUPS= ) { name =3D strsep(&names, ":"); if (isdigit(*name) || *name =3D=3D '-') { cr->cr_groups[cr->cr_ngroups++] =3D atoi(name); @@ -2709,7 +2709,7 @@ cr->cr_groups[cr->cr_ngroups++] =3D gr->gr_gid; } } - if (names !=3D NULL && *names !=3D '\0' && cr->cr_ngroups =3D=3D NGROUPS) + if (names !=3D NULL && *names !=3D '\0' && cr->cr_ngroups =3D=3D XU_NGROU= PS) syslog(LOG_ERR, "too many groups"); } =20 --YZ5djTAD1cGYuMQK-- --O5XBE6gyVG5Rl6Rj Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iD8DBQFKOYTKXY6L6fI4GtQRAoiYAJ9BzCBNbP/75Un8IE0lnANi+vLzcACgvb3y Qn1aK6Ca1A8ZeOXWFkULVJo= =wA9V -----END PGP SIGNATURE----- --O5XBE6gyVG5Rl6Rj-- From owner-freebsd-current@FreeBSD.ORG Thu Jun 18 07:43:27 2009 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 5E7681065678 for ; Thu, 18 Jun 2009 07:43:27 +0000 (UTC) (envelope-from fergus@cobbled.net) Received: from mail1.slb.deg.dub.stisp.net (mail1.slb.deg.dub.stisp.net [84.203.253.98]) by mx1.freebsd.org (Postfix) with SMTP id AE08E8FC1B for ; Thu, 18 Jun 2009 07:43:26 +0000 (UTC) (envelope-from fergus@cobbled.net) Received: (qmail 68305 invoked from network); 18 Jun 2009 07:16:44 -0000 Received: from unknown (HELO holyman.cobbled.net) (84.203.180.117) by mail1.slb.deg.dub.stisp.net with SMTP; 18 Jun 2009 07:16:44 -0000 Received: by holyman.cobbled.net (Postfix, from userid 16385) id 6A8A91031D; Thu, 18 Jun 2009 07:16:43 +0000 (UTC) Date: Thu, 18 Jun 2009 07:16:43 +0000 From: ttw+bsd@cobbled.net To: Brooks Davis Message-ID: <20090618071643.GA27928@holyman.cobbled.net> Mail-Followup-To: Brooks Davis , freebsd-hackers@freebsd.org, freebsd-current@freebsd.org References: <20090618000407.GA43514@lor.one-eyed-alien.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090618000407.GA43514@lor.one-eyed-alien.net> Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: CFT: final patches for NGROUPS>>16 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, 18 Jun 2009 07:43:27 -0000 posted patches to this effect some months ago. they needed some clean-up and validation but the also mapped correctly into an RPC_NGROUPS_MAX and IPC_NGROUPS_MAX for consistent (and possibly dynamic) mapping to those problem areas. they build and run but are untested beyond that. i do not expect to have time to re-visit the problem in reasonable order. they also included some other userland changes that may be of interest. From owner-freebsd-current@FreeBSD.ORG Thu Jun 18 09:43:23 2009 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 D7EB21065670; Thu, 18 Jun 2009 09:43:23 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from ch-smtp01.sth.basefarm.net (ch-smtp01.sth.basefarm.net [80.76.149.212]) by mx1.freebsd.org (Postfix) with ESMTP id 634DA8FC14; Thu, 18 Jun 2009 09:43:23 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from c83-253-252-234.bredband.comhem.se ([83.253.252.234]:50390 helo=mx.exscape.org) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.69) (envelope-from ) id 1MHE9E-0001ev-3E; Thu, 18 Jun 2009 11:43:10 +0200 Received: from [192.168.1.5] (macbookpro [192.168.1.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx.exscape.org (Postfix) with ESMTPSA id 243326AD73; Thu, 18 Jun 2009 11:43:04 +0200 (CEST) Message-Id: From: Thomas Backman To: Wesley Shields In-Reply-To: <20090617225849.GB28509@atarininja.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 18 Jun 2009 11:43:03 +0200 References: <949B5884-5303-4EFF-AC7D-293640FFA012@exscape.org> <0C235698-3ED2-4AE9-A7D1-5DC56D8324A4@exscape.org> <200905212129.47892.mel.flynn+fbsd.current@mailing.thruhere.net> <44F486FA-E798-448D-BE31-F7A51EF1F612@exscape.org> <60173AF0-7E54-4BDD-8927-0DADA9DAD1B4@exscape.org> <20090522200306.GE2630@atarininja.org> <20090617225849.GB28509@atarininja.org> X-Mailer: Apple Mail (2.935.3) X-Originating-IP: 83.253.252.234 X-Scan-Result: No virus found in message 1MHE9E-0001ev-3E. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1MHE9E-0001ev-3E 5cdb634c05b145d39d3ab2a49d867da8 Cc: freebsd-current@freebsd.org Subject: Re: DTrace panic while probing syscall::open (and possibly many others) 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, 18 Jun 2009 09:43:24 -0000 On Jun 18, 2009, at 12:58 AM, Wesley Shields wrote: > On Fri, May 22, 2009 at 04:03:06PM -0400, Wesley Shields wrote: >> On Fri, May 22, 2009 at 10:00:56AM +0200, Thomas Backman wrote: >>> On May 22, 2009, at 09:31 AM, Thomas Backman wrote: >>>> >>>> ... >>>> dtrace: error on enabled probe ID 1 (ID 38977: =20 >>>> syscall::open:entry): >>>> invalid address (0xffffff803e9afae0) in action #1 at DIF offset 28 >>>> dtrace: error on enabled probe ID 1 (ID 38977: =20 >>>> syscall::open:entry): >>>> invalid address (0xffffff803e9afae0) in action #1 at DIF offset 28 >>>> dtrace: error on enabled probe ID 1 (ID 38977: =20 >>>> syscall::open:entry): >>>> invalid address (0xffffff803e9afae0) in action #1 at DIF offset 28 >>>> >>> >>> Actually, I still get these. Bummer. >>> >>> [root@chaos /usr/local/sbin]# execsnoop >>> UID PID PPID ARGS >>> 0 1931 1924 /bin/sh >>> 0 1931 1924 /bin/sh >>> 0 1932 1931 /bin/mkdir >>> 0 1932 1931 /bin/mkdir >>> dtrace: error on enabled probe ID 2 (ID 39086: >>> syscall::execve:return): invalid address (0xffffff803e8cfae0) in >>> action #8 >>> dtrace: error on enabled probe ID 3 (ID 39086: >>> syscall::execve:return): invalid address (0xffffff803e8cfae0) in >>> action #8 >>> 0 1944 1933 mktemp >>> 0 1944 1933 mktemp >>> dtrace: error on enabled probe ID 2 (ID 39086: >>> syscall::execve:return): invalid address (0xffffff803ea58ae0) in >>> action #8 >>> dtrace: error on enabled probe ID 3 (ID 39086: >>> syscall::execve:return): invalid address (0xffffff803ea58ae0) in >>> action #8 >>> dtrace: error on enabled probe ID 2 (ID 39086: >>> syscall::execve:return): invalid address (0xffffff803ea9eae0) in >>> action #8 >>> dtrace: error on enabled probe ID 3 (ID 39086: >>> syscall::execve:return): invalid address (0xffffff803ea9eae0) in >>> action #8 >>> 0 1948 1947 /bin/sh >>> 0 1948 1947 /bin/sh >>> 0 1949 1948 vnstat >>> 0 1949 1948 vnstat >>> 0 1950 1933 /bin/rm >>> 0 1950 1933 /bin/rm >>> 0 1951 1907 /bin/sh >>> 0 1951 1907 /bin/sh >>> 0 1952 1951 make >>> 0 1952 1951 make >>> >>> (No idea why everything is printed twice either.) >>> Also, the DTrace variable "walltimestamp" seems to return "1970 =20 >>> Jan 1 >>> 01:00:00" (I'm in GMT+2 right now, btw) every time. >> >> This leads me to believe it's a race somewhere. >> >> Another datapoint: whatever was changed also made it into 7.2 as =20 >> that is >> broken in the same fashion. I just installed a 7.1 VM and tried it =20= >> there >> and it works. > > I just updated a -current machine to r194361 and the race condition is > still there but not triggered as often, and it no longer leads to a > panic. I still get occasional output like what is listed above but no > panic. > > -- WXS No luck here. :( FreeBSD chaos.exscape.org 8.0-CURRENT FreeBSD 8.0-CURRENT #8 r194428: =20= Thu Jun 18 10:44:21 CEST 2009 root@chaos.exscape.org:/usr/obj/usr/=20= src/sys/DTRACE amd64 I removed my funny printf-before-ASSERT hack, updated to the latest =20 revision and built it, then ran: dtrace -n 'syscall::open:entry { self->path =3D arg0; } =20 syscall::open:return { printf("%s\n", copyinstr(self->path)); }' again, same crash. dtrace_copycheck() seeems to be the culprit yet again, as expected. I guess I'll have to add back the printf hack, heh. #10 0xffffffff816c9140 in vpanic_common () from /boot/kernel/dtrace.ko #11 0xffffffff816b3067 in dtrace_panic (format=3DVariable "format" is =20= not available. ) at /usr/src/sys/modules/dtrace/dtrace/../../../cddl/contrib/=20 opensolaris/uts/common/dtrace/dtrace.c:600 #12 0xffffffff816b309d in dtrace_assfail ( a=3D0xffffffff816d4b88 "kaddr >=3D kernelbase && kaddr + size >=3D =20= kaddr", f=3D0xffffff803e770370 "=C0=E0F\201=FF=FF=FF=FF=C0=E0F\201=FF=FF=FF=FF= 0\005w>\200=FF=FF=FF=C7=E0=20 \206\200=FF=FF=FF=FFWD\210\200=FF=FF=FF=FF`&t~", l=3DVariable "l" is not = available. ) at /usr/src/sys/modules/dtrace/dtrace/../../../cddl/contrib/=20 opensolaris/uts/common/dtrace/dtrace.c:607 #13 0xffffffff816b3140 in dtrace_copycheck (uaddr=3D34365163021, =20 kaddr=3DVariable "kaddr" is not available. ) at dtrace_isa.c:527 #14 0xffffffff816b31fc in dtrace_copyinstr (uaddr=3D34365163021, kaddr=3D18446743524025463312, size=3D256, flags=3D0xffffffff8146e0c0)= at dtrace_isa.c:558 #15 0xffffffff816c10f1 in dtrace_dif_emulate (difo=3D0xffffffff80884457, mstate=3D0xffffff803e770a10, vstate=3D0xffffff0002930c38, state=3D0xffffff0002930c00) at /usr/src/sys/modules/dtrace/dtrace/../../../cddl/contrib/=20 opensolaris/uts/common/dtrace/dtrace.c:3452 #16 0xffffffff816c233a in dtrace_probe (id=3DVariable "id" is not =20 available. ) at /usr/src/sys/modules/dtrace/dtrace/../../../cddl/contrib/=20 opensolaris/uts/common/dtrace/dtrace.c:6226 #17 0xffffffff817f2145 in systrace_probe () from /boot/kernel/=20 systrace.ko #18 0xffffffff80887c7d in syscall (frame=3D0xffffff803e770c90) at /usr/src/sys/amd64/amd64/trap.c:997 #19 0xffffffff8086e350 in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:364 #20 0x000000080050c3ac in ?? () Previous frame inner to this frame (corrupt stack?) Regards, Thomas= From owner-freebsd-current@FreeBSD.ORG Thu Jun 18 10:55:41 2009 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 8E4F6106566B for ; Thu, 18 Jun 2009 10:55:41 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 96B5F8FC21 for ; Thu, 18 Jun 2009 10:55:40 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id NAA15303; Thu, 18 Jun 2009 13:55:35 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4A3A1D27.4010802@icyb.net.ua> Date: Thu, 18 Jun 2009 13:55:35 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.21 (X11/20090406) MIME-Version: 1.0 To: Thomas Backman References: <949B5884-5303-4EFF-AC7D-293640FFA012@exscape.org> <0C235698-3ED2-4AE9-A7D1-5DC56D8324A4@exscape.org> <200905212129.47892.mel.flynn+fbsd.current@mailing.thruhere.net> <44F486FA-E798-448D-BE31-F7A51EF1F612@exscape.org> <60173AF0-7E54-4BDD-8927-0DADA9DAD1B4@exscape.org> <20090522200306.GE2630@atarininja.org> <20090617225849.GB28509@atarininja.org> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: Wesley Shields , freebsd-current@FreeBSD.org Subject: Re: DTrace panic while probing syscall::open (and possibly many others) 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, 18 Jun 2009 10:55:41 -0000 on 18/06/2009 12:43 Thomas Backman said the following: > #10 0xffffffff816c9140 in vpanic_common () from /boot/kernel/dtrace.ko > #11 0xffffffff816b3067 in dtrace_panic (format=Variable "format" is not > available. > ) > at > /usr/src/sys/modules/dtrace/dtrace/../../../cddl/contrib/opensolaris/uts/common/dtrace/dtrace.c:600 > > #12 0xffffffff816b309d in dtrace_assfail ( > a=0xffffffff816d4b88 "kaddr >= kernelbase && kaddr + size >= kaddr", > f=0xffffff803e770370 > "ÀàF\201ÿÿÿÿÀàF\201ÿÿÿÿ0\005w>\200ÿÿÿÇà\206\200ÿÿÿÿWD\210\200ÿÿÿÿ`&t~", > l=Variable "l" is not available. > ) > at > /usr/src/sys/modules/dtrace/dtrace/../../../cddl/contrib/opensolaris/uts/common/dtrace/dtrace.c:607 > > #13 0xffffffff816b3140 in dtrace_copycheck (uaddr=34365163021, > kaddr=Variable "kaddr" is not available. > ) > at dtrace_isa.c:527 > #14 0xffffffff816b31fc in dtrace_copyinstr (uaddr=34365163021, > kaddr=18446743524025463312, size=256, flags=0xffffffff8146e0c0) > at dtrace_isa.c:558 kaddr=18446743524025463312 == FFFFFF8004467210 I think kernelbase on amd64 is 0xFFFFFFFF80000000. FFFFFF8004467210 kaddr is smaller than FFFFFFFF80000000 kernelbase The numbers do look suspiciously similar, so I am not sure if you are seeing a race or a real bug somewhere. > #15 0xffffffff816c10f1 in dtrace_dif_emulate (difo=0xffffffff80884457, > mstate=0xffffff803e770a10, vstate=0xffffff0002930c38, > state=0xffffff0002930c00) > at > /usr/src/sys/modules/dtrace/dtrace/../../../cddl/contrib/opensolaris/uts/common/dtrace/dtrace.c:3452 > > #16 0xffffffff816c233a in dtrace_probe (id=Variable "id" is not available. > ) > at > /usr/src/sys/modules/dtrace/dtrace/../../../cddl/contrib/opensolaris/uts/common/dtrace/dtrace.c:6226 > > #17 0xffffffff817f2145 in systrace_probe () from /boot/kernel/systrace.ko > #18 0xffffffff80887c7d in syscall (frame=0xffffff803e770c90) > at /usr/src/sys/amd64/amd64/trap.c:997 > #19 0xffffffff8086e350 in Xfast_syscall () > at /usr/src/sys/amd64/amd64/exception.S:364 > #20 0x000000080050c3ac in ?? () -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Thu Jun 18 11:43:11 2009 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 123D6106568A; Thu, 18 Jun 2009 11:43:11 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from ch-smtp01.sth.basefarm.net (ch-smtp01.sth.basefarm.net [80.76.149.212]) by mx1.freebsd.org (Postfix) with ESMTP id 8FA738FC16; Thu, 18 Jun 2009 11:43:10 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from c83-253-252-234.bredband.comhem.se ([83.253.252.234]:57231 helo=mx.exscape.org) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.69) (envelope-from ) id 1MHG1E-0007vM-65; Thu, 18 Jun 2009 13:43:02 +0200 Received: from [192.168.1.5] (macbookpro [192.168.1.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx.exscape.org (Postfix) with ESMTPSA id 790466B162; Thu, 18 Jun 2009 13:42:56 +0200 (CEST) Message-Id: From: Thomas Backman To: Andriy Gapon In-Reply-To: <4A3A1D27.4010802@icyb.net.ua> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 18 Jun 2009 13:42:55 +0200 References: <949B5884-5303-4EFF-AC7D-293640FFA012@exscape.org> <0C235698-3ED2-4AE9-A7D1-5DC56D8324A4@exscape.org> <200905212129.47892.mel.flynn+fbsd.current@mailing.thruhere.net> <44F486FA-E798-448D-BE31-F7A51EF1F612@exscape.org> <60173AF0-7E54-4BDD-8927-0DADA9DAD1B4@exscape.org> <20090522200306.GE2630@atarininja.org> <20090617225849.GB28509@atarininja.org> <4A3A1D27.4010802@icyb.net.ua> X-Mailer: Apple Mail (2.935.3) X-Originating-IP: 83.253.252.234 X-Scan-Result: No virus found in message 1MHG1E-0007vM-65. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1MHG1E-0007vM-65 5c90402651a87bf0de3a7dc1e9d4d6bc Cc: Wesley Shields , freebsd-current@FreeBSD.org Subject: Re: DTrace panic while probing syscall::open (and possibly many others) 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, 18 Jun 2009 11:43:11 -0000 On Jun 18, 2009, at 12:55 PM, Andriy Gapon wrote: > on 18/06/2009 12:43 Thomas Backman said the following: >> >> at dtrace_isa.c:527 >> #14 0xffffffff816b31fc in dtrace_copyinstr (uaddr=34365163021, >> kaddr=18446743524025463312, size=256, flags=0xffffffff8146e0c0) >> at dtrace_isa.c:558 > > kaddr=18446743524025463312 == FFFFFF8004467210 > I think kernelbase on amd64 is 0xFFFFFFFF80000000. > FFFFFF8004467210 kaddr > is smaller than > FFFFFFFF80000000 kernelbase > > The numbers do look suspiciously similar, so I am not sure if you > are seeing a > race or a real bug somewhere. > -- > Andriy Gapon Hmmm... Looking around a bit for these numbers, I found, in /sys/amd64/include/ vmparam.h: /* * Virtual addresses of things. Derived from the page directory and * page table indexes from pmap.h for precision. * * 0x0000000000000000 - 0x00007fffffffffff user map * 0x0000800000000000 - 0xffff7fffffffffff does not exist (hole) * 0xffff800000000000 - 0xffff804020100fff recursive page table (512GB slot) * 0xffff804020101000 - 0xfffffeffffffffff unused * 0xffffff0000000000 - 0xffffff7fffffffff 512GB direct map mappings * 0xffffff8000000000 - 0xffffffffffffffff 512GB kernel map * * Within the kernel map: * * 0xffffffff80000000 KERNBASE */ So, kaddr is inside the "kernel map", but not KERNBASE. What this means, I have no clue whatsoever. (I'm not a kernel developer and I don't know too much about (virtual) memory either!) Regards, Thomas From owner-freebsd-current@FreeBSD.ORG Thu Jun 18 11:50:08 2009 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 8E962106564A for ; Thu, 18 Jun 2009 11:50:08 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from ch-smtp01.sth.basefarm.net (ch-smtp01.sth.basefarm.net [80.76.149.212]) by mx1.freebsd.org (Postfix) with ESMTP id 202598FC13 for ; Thu, 18 Jun 2009 11:50:07 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from c83-253-252-234.bredband.comhem.se ([83.253.252.234]:37948 helo=mx.exscape.org) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.69) (envelope-from ) id 1MHG7p-0008Rb-3S; Thu, 18 Jun 2009 13:49:51 +0200 Received: from [192.168.1.5] (macbookpro [192.168.1.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx.exscape.org (Postfix) with ESMTPSA id 6DFDC6B161; Thu, 18 Jun 2009 13:49:47 +0200 (CEST) Message-Id: <993B7B5B-1B6B-48A5-8425-6A1D071335A9@exscape.org> From: Thomas Backman To: Artem Belevich 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 v935.3) Date: Thu, 18 Jun 2009 13:49:46 +0200 References: X-Mailer: Apple Mail (2.935.3) X-Originating-IP: 83.253.252.234 X-Scan-Result: No virus found in message 1MHG7p-0008Rb-3S. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1MHG7p-0008Rb-3S 4704e28427d1bfb6cd99c4517d6480e2 Cc: freebsd-current@freebsd.org Subject: Re: ZFS : panic("sleeping thread") 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, 18 Jun 2009 11:50:08 -0000 On May 27, 2009, at 07:58 PM, Artem Belevich wrote: > Hi, > > While recent ZFS improvements got rid of random hangs I used to see, > there's still one problem that I keep running into -- panic in ZFS > under heavy load. I can reproduce it by doing a build with -j16 in a > jail running i386 binaries on -CURRENT/amd64 running on a box with > quad-core CPU. It takes a while to reproduce, but it usually shows up > within couple of hours. > > Sleeping thread (tid 100606, pid 32147) owns a non-sleepable lock > sched_switch() at sched_switch+0xed > mi_switch() at mi_switch+0x16f > sleepq_wait() at sleepq_wait+0x42 > _sx_xlock_hard() at _sx_xlock_hard+0x1f0 > _sx_xlock() at _sx_xlock+0x4e > rrw_exit() at rrw_exit+0x1d > zfs_freebsd_getattr() at zfs_freebsd_getattr+0x2be > VOP_GETATTR_APV() at VOP_GETATTR_APV+0x44 > filt_vfsread() at filt_vfsread+0x51 > knote() at knote+0xc2 > VOP_WRITE_APV() at VOP_WRITE_APV+0x11f > vn_write() at vn_write+0x279 > dofilewrite() at dofilewrite+0x85 > kern_writev() at kern_writev+0x60 > write() at write+0x54 > ia32_syscall() at ia32_syscall+0x236 > Xint0x80_syscall() at Xint0x80_syscall+0x85 > --- syscall (4, FreeBSD ELF32, write), rip = 0x78162153, rsp = > 0xffff945c, rbp = 0xffff9478 --- > > It appears that locking within ZFS conflicts with vnode locking. The > back-trace is always the same. > > For now, I've applied following patch to disable the panic, but it > would be good if someone familiar with VFS locking in FreeBSD could > take a look. > If you need any additional info, let me know. > > Thanks, > --Artem > > diff -r 930d975c8103 src/sys/kern/subr_turnstile.c > --- a/sys/kern/subr_turnstile.c Fri Dec 05 16:12:43 2008 -0800 > +++ b/sys/kern/subr_turnstile.c Fri Dec 12 14:31:16 2008 -0800 > @@ -219,7 +219,10 @@ > #ifdef DDB > db_trace_thread(td, -1); > #endif > - panic("sleeping thread"); > + /* Don't propagate priority to a sleeping > thread. */ > + thread_unlock(td); > + return; > + // panic("sleeping thread"); > } > > /* Anyone have any updates on this? I just got a "sleeping thread" panic in ZFS after doing a zfs rollback. Unfortunately, "panic" in the debugger resulted in "dump device too small" (despite being RAM-sized) so I don't have a BT... However the BT I got in the debugger was *not* the same as yours. There was no _sx_xlock in it, but that's pretty much all I know about it. :( Regards, Thomas From owner-freebsd-current@FreeBSD.ORG Thu Jun 18 13:37:35 2009 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 D3DA11065673; Thu, 18 Jun 2009 13:37:35 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id A742E8FC0C; Thu, 18 Jun 2009 13:37:35 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 5B5B746B51; Thu, 18 Jun 2009 09:37:35 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 3B6CA8A074; Thu, 18 Jun 2009 09:37:34 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Thu, 18 Jun 2009 09:08:05 -0400 User-Agent: KMail/1.9.7 References: <1245258022.40309.49.camel@buffy.york.ac.uk> In-Reply-To: <1245258022.40309.49.camel@buffy.york.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200906180908.05274.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Thu, 18 Jun 2009 09:37:34 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Gavin Atkinson Subject: Re: BTX halted when booting from CD: Toshiba M10-10i laptop 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, 18 Jun 2009 13:37:36 -0000 On Wednesday 17 June 2009 1:00:22 pm Gavin Atkinson wrote: > Hi all, > > I've got a new laptop (a Toshiba M10-10i, for the archives) but FreeBSD > won't boot on it. I've tested with the May 2009 amd64 snapshot ISO, and > about 20% of the time, it hangs before even displaying "CD loader". The > rest of the time, I get the following BTX register dump: > > CD Loader 1.2 > > Building the boot loader arguments > Looking up /BOOT/LOADER... Found > Relocating the loader and the BTX > Starting the BTX loader > > BTX loader 1.00 BTX version is 1.02 > > int=0000000d err=00003d58 efl=00010246 eip=3583d321 > eax=8b16d000 ebx=00000000 ecx=ffff0000 edx=00002170 > esi=00000000 edi=0003b7c0 ebp=00090bf8 esp=00090bc8 > cs=002b ds=0033 es=0033 fs=0033 gs=0033 ss=0033 > cs:eip=07 00 00 00 00 00 00 00-33 00 02 00 00 00 00 00 > 00 00 00 00 00 00 00 00-03 00 00 00 20 00 00 00 > ss:esp=5b 3d 03 00 33 00 00 00-48 01 00 00 a0 b0 03 00 > 38 00 00 00 6f 01 20 00-1a 00 20 00 01 94 00 00 > BTX halted > > (at which point the laptop immediately reboots. This is transcribed > from a photo.) > > A second crash (some registers are different, but I guess it's the same > cause due to the same odd eip): > > int=0000000d err=00003d58 efl=00010202 eip=3583d321 > eax=79f7b814 ebx=00000000 ecx=02000000 edx=000000ec > esi=00000000 edi=0003b7c0 ebp=00090bf8 esp=00090bcc > cs=002b ds=0033 es=0033 fs=0033 gs=0033 ss=0033 > cs:eip=07 00 00 00 00 00 00 00-33 00 02 00 00 00 00 00 > 00 00 00 00 00 00 00 00-03 00 00 00 20 00 00 00 > ss:esp=5b 3d 03 00 48 01 00 00-a0 b0 03 00 38 00 00 00 > 6f 01 20 00 1a 00 20 00-01 94 00 00 00 00 00 00 > BTX halted > > Now, I can tell that eip is off into the weeds, but I'm not really sure > how to debug this past that. The first address on the stack is > presumably a return address, but that doesn't seem to be within the > address space where any of the bootstrap code is loaded to, so maybe I'm > wrong. > > So, how do I continue tracking down the problem from here? > > I don't know if it helps at all, but even a 4.x CD dies in BTX (although > I haven't managed to successfully take a picture of that to confirm if > it is the same problem, but can try if it would be useful) > > As an aside, from what I understand from the source, once we've got to > this stage of the boot the environment should be the same whether we're > booting from hard drive, CD or PXE? Is that correct? My guess is that the data being read from the CD is corrupted somehow. If a 4.x CD fails too then that the breakage is solely in the BIOS as 4.x uses the old floppy emulation mode. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Jun 18 13:37:37 2009 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 743AB106564A for ; Thu, 18 Jun 2009 13:37:37 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 471EB8FC21 for ; Thu, 18 Jun 2009 13:37:37 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id F317C46BC0; Thu, 18 Jun 2009 09:37:36 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id EFF738A075; Thu, 18 Jun 2009 09:37:35 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Thu, 18 Jun 2009 09:09:33 -0400 User-Agent: KMail/1.9.7 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200906180909.33511.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Thu, 18 Jun 2009 09:37:36 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Alexander Best Subject: Re: estX still not attaching properly 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, 18 Jun 2009 13:37:37 -0000 On Wednesday 17 June 2009 2:29:25 pm Alexander Best wrote: > hi there, > > although i'm running a very recent current which has "ACPICA 20090521", estX > still isn't attaching properly on my machine: > > est0: on cpu0 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 925092506000925 > device_attach: est0 attach returned 6 > est1: on cpu1 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 925092506000925 > device_attach: est1 attach returned 6 That just means ACPI isn't providing info about the speed steppings your CPU provides. It is odd that cpu0 has freq_levels but cpu1 does not. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Jun 18 13:56:12 2009 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 38ECC1065670 for ; Thu, 18 Jun 2009 13:56:12 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from ch-smtp01.sth.basefarm.net (ch-smtp01.sth.basefarm.net [80.76.149.212]) by mx1.freebsd.org (Postfix) with ESMTP id E16818FC12 for ; Thu, 18 Jun 2009 13:56:11 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from c83-253-252-234.bredband.comhem.se ([83.253.252.234]:45224 helo=mx.exscape.org) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.69) (envelope-from ) id 1MHI5j-0000qF-4X; Thu, 18 Jun 2009 15:55:49 +0200 Received: from [192.168.1.5] (macbookpro [192.168.1.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx.exscape.org (Postfix) with ESMTPSA id F21DE6B161; Thu, 18 Jun 2009 15:55:46 +0200 (CEST) Message-Id: From: Thomas Backman To: Andriy Gapon In-Reply-To: <4A3A2B88.60009@icyb.net.ua> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 18 Jun 2009 15:55:45 +0200 References: <949B5884-5303-4EFF-AC7D-293640FFA012@exscape.org> <0C235698-3ED2-4AE9-A7D1-5DC56D8324A4@exscape.org> <200905212129.47892.mel.flynn+fbsd.current@mailing.thruhere.net> <44F486FA-E798-448D-BE31-F7A51EF1F612@exscape.org> <60173AF0-7E54-4BDD-8927-0DADA9DAD1B4@exscape.org> <20090522200306.GE2630@atarininja.org> <20090617225849.GB28509@atarininja.org> <4A3A1D27.4010802@icyb.net.ua> <4A3A2B88.60009@icyb.net.ua> X-Mailer: Apple Mail (2.935.3) X-Originating-IP: 83.253.252.234 X-Scan-Result: No virus found in message 1MHI5j-0000qF-4X. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1MHI5j-0000qF-4X 934a4c68a4d38eabd3a2b31b1a918702 Cc: FreeBSD current Subject: Re: DTrace panic while probing syscall::open (and possibly many others) 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, 18 Jun 2009 13:56:12 -0000 On Jun 18, 2009, at 01:56 PM, Andriy Gapon wrote: > on 18/06/2009 14:42 Thomas Backman said the following: >> >> So, kaddr is inside the "kernel map", but not KERNBASE. What this >> means, >> I have no clue whatsoever. (I'm not a kernel developer and I don't >> know >> too much about (virtual) memory either!) > > Me neither :( > BTW, could you please go to fr 18 and examine 'code', 'callp' and > 'args' local > variables? No. :/ The kernel.debug was gone, and so I deleted the core as well, since I had changed the kernel code since the recompile (that *would* break debugging it, yes? I can't just recompile a new, changed one hoping it will still debug properly, right?). Maybe at a later time. Regards, Thomas From owner-freebsd-current@FreeBSD.ORG Thu Jun 18 06:08:44 2009 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 F1C7F106564A; Thu, 18 Jun 2009 06:08:44 +0000 (UTC) (envelope-from venkiece2005@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.31]) by mx1.freebsd.org (Postfix) with ESMTP id 9A27D8FC17; Thu, 18 Jun 2009 06:08:44 +0000 (UTC) (envelope-from venkiece2005@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so378296ywe.13 for ; Wed, 17 Jun 2009 23:08:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=s8zhDn8rrvCuPHM2e9iqSeXA7gDNAOa1dh+EIT/uHJw=; b=FSa3K6PyTFfrRSTr0ZIHx3Rkh0AMfCQKPUf+SGRmL/Sqb7L8fHW5wxRaxZ6j8l/lMR 8pqTRa7xTTWzNlZJktI4qgmudSQ43LTYhe0r4klMUZghJD6wHrR9oPbLIzkkL5j2ieqz DHabx7XivIZViPEwABCUnHR5m5mWqrOkEMhpQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=svxN2eU5ANiiqmgp8g/vLFtYMlsRP2ZkobBVl4czWPu/H+YGJ7aFnKpGx7Vnr2ejCK /wqyljps/meM+wh/p3XOrwcy/ynVTtMENRfQB3TJu0M4Kn0PqEiTc7gQGcSd6CGtugx2 NCGl37dTMqwEhAKrKy6FUZQnjGGTb/WD4AKRA= MIME-Version: 1.0 Received: by 10.151.119.2 with SMTP id w2mr2803496ybm.200.1245305323438; Wed, 17 Jun 2009 23:08:43 -0700 (PDT) In-Reply-To: <20090616200756.70206fda@kan.dnsalias.net> References: <6d53329e0906160229j2fdba518h84b13652153a32f6@mail.gmail.com> <20090616200756.70206fda@kan.dnsalias.net> Date: Thu, 18 Jun 2009 11:38:43 +0530 Message-ID: <6d53329e0906172308j28c7f404y49f759fea4842a29@mail.gmail.com> From: venki kaps To: Alexander Kabaev Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 18 Jun 2009 13:59:42 +0000 Cc: freebsd-arm@freebsd.org, freebsd-current@freebsd.org, netbsd-users@netbsd.org Subject: Re: [libc] dlclose gives "invalid shared object handle" without pthread combination. 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, 18 Jun 2009 06:08:45 -0000 Hi, I have been porting NetBSD source in the Linux environment with our own pthread library. system environment: Compiler: arm-linux-gcc-4.3.3 OS: Linux Kernel: 2.6.29 Yes, it never even calls dlerr() in dlcose but NetBSD __dlclose(void *handle) source sequence, int dlclose(void *handle) { Obj_Entry *root = _rtld_dlcheck(handle); if (root == NULL) return -1; _rtld_debug.r_state = RT_DELETE; _rtld_debug_state(); --root->dl_refcount; _rtld_unload_object(root, true); _rtld_debug.r_state = RT_CONSISTENT; _rtld_debug_state(); return 0; } static Obj_Entry * _rtld_dlcheck(void *handle) { Obj_Entry *obj; for (obj = _rtld_objlist; obj != NULL; obj = obj->next) if (obj == (Obj_Entry *) handle) break; xprintf("obj->dl_refcount is %d\n",obj->dl_refcount); if (obj == NULL || obj->dl_refcount == 0) { xwarnx("Invalid shared object handle %p", handle); return NULL; } return obj; } I have printed xprintf("obj->dl_refcount is %d\n",obj->dl_refcount); obj->dl_refcount is getting zero(0). So due to "obj->dl_refcount == 0" the error "invalid shared object handle" is showing. i do not know why this error is coming even though all the constructor/destructor sequences are completed. is it rtld_exit->fini->static C++ destructor->dlcose sequence problem? Thanks & Regards, Venkappa On Wed, Jun 17, 2009 at 5:37 AM, Alexander Kabaev wrote: > Hi, > > I do not think we on FreeBSD support NetBSD rtld with our pthread > libraries, unless you already implemented all the necessary glue. > The interface between threading library and rtld is rather intimate and > tricky to get right. > > You provide no code to look at nor explicitly mention what OS and > what version you are running your test on (FreeBSD?), I think you are > on your own. Furthermore, your claim on 'correct' > constructor/destructor is wrong given the sample code provided by > NetBSD PR. > > Some more comments are inline. > > On Tue, 16 Jun 2009 14:59:36 +0530 > venki kaps wrote: > >> Hi, >> >> I am using the NetBSD implementation of rtld(src/libexec/ld.elf_so/) >> for ARM/MIPS. >> >> I have C++ static constructor/destructor issue with my rtld. >> >> Problem Report: >> "ld.elf_so does not execute .init/.fini functions in order" and [libc] >> dlclose gives >> "invalid shared object handle" when called through the fini function >> of another module. >> >> The similar NetBSD/freeBSD issues are found from the following >> References: [1] http://gnats.netbsd.org/37347 >> [2] http://updraft3.jp.freebsd.org/cgi/query-pr.cgi?pr=kern/42956 >> >> The above issues are already commited in NetBSD-5-0-RELEASE. >> >> I have ported NetBSD-5-0-RELEASE rtld and tested Ref[1] provided >> static constructor/destructor test and did not find any issues >> with shared pthread combination but noticed [libc] dlclose gives >> "invalid shared object handle" without pthread combination. >> >> The static constructor/destructor test results: >> >> It should be : >> -------------- >> >> $ ./foobar >> foo_ctor >> bar_ctor >> tar_ctor >> main_ctor >> dep1_ctor >> dep2_ctor >> dll_ctor >> dll_dtor >> dep2_dtor >> dep1_dtor >> main_dtor >> tar_dtor >> bar_dtor >> foo_dtor > > Given the test in Ref[1], both constructor and destructor orders are > wrong above. libdep1 depends on libdep2, so dep2_ctor should be invoked > before dep1_ctor and consequently dep2_dtor should be invoked after > dep1_dtor. > >> While currently I get: >> ---------------------- >> >> with pthreads: >> >> $ ./foobar >> foo_ctor >> bar_ctor >> tar_ctor >> main_ctor >> dep1_ctor >> dep2_ctor >> dll_ctor >> dll_dtor >> dep2_dtor >> dep1_dtor >> main_dtor >> tar_dtor >> bar_dtor >> foo_dtor >> >> without pthreads: >> >> $ ./foobar >> foo_ctor >> bar_ctor >> tar_ctor >> main_ctor >> dep1_ctor >> dep2_ctor >> dll_ctor >> dll_dtor >> dep2_dtor >> dep1_dtor >> main_dtor >> tar_dtor >> bar_dtor >> foo_dtor >> Invalid shared object handle 0xbdbed400 > > Again, given the sample code from NetBSD PR cannot possibly print this > message because it never even calls dlerr(). You must be looking at > some other code and unless you provide it, understanding your problem > and fixing it is next to impossible. > > Said that, thanks for pointing the FreeBSD PR to me. I will commit the > fix for the problem described here shortly. > >> This gives a "invalid shared object handle" message >> because the refcount field (obj->dl_refcount) for the handle is zero. >> >> I have little bit confused about dlclose destructor >> with/without pthreads. >> >> I have some queries: >> 1) Is it required any changes apart from the >> NetBSD-5-0-RELEASE/{Ref[1],[2]}? 2) Are any changes required in >> thread-stub? >> >> Could anyone provide any inputs to the my issue? >> >> Thanks in advance. >> >> Thanks & Regards, >> Venkappa > > -- > Alexander Kabaev > From owner-freebsd-current@FreeBSD.ORG Thu Jun 18 12:45:49 2009 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 3BEED1065672 for ; Thu, 18 Jun 2009 12:45:49 +0000 (UTC) (envelope-from ibb27@yahoo.co.uk) Received: from web25001.mail.ukl.yahoo.com (web25001.mail.ukl.yahoo.com [217.146.183.104]) by mx1.freebsd.org (Postfix) with SMTP id A3DB58FC14 for ; Thu, 18 Jun 2009 12:45:48 +0000 (UTC) (envelope-from ibb27@yahoo.co.uk) Received: (qmail 48263 invoked by uid 60001); 18 Jun 2009 12:45:47 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.uk; s=s1024; t=1245329147; bh=x69T6UegrAM0fyxu4+f8wuT6B8lqxTFe0aJpz+bEPao=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=4KRpkGzDyUCXAllrfLPDO3Wv9W4vg5ZJPjLJh3++DxFsHvX/EZKmk3spcnujtf6mg2WZD7pVE1ki8hZiz3POF07O7WvURANUSWO6FbSuPbCyRyy9lMSAOOq9gETALtH35DwwI5csdIK9hHmMaEFmZW/GoucdDB0cm6fHTPNeRWc= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.uk; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=MeT8tgN6n7mJY+hFjayVCndRlT8fR/1+4YdZGtije1HA+5bxGKUyY6oZO5jxEdj20NbEux96POi1TJrZ+AZ2laqpmtb9LJziwxBF3oSh0DuCHnArtrs8NjEpH+gNF+V4NzefXQ9Wfw+GVdPGOyLUSmj4wC+GCsKY934yFwqnL58=; Message-ID: <538522.48180.qm@web25001.mail.ukl.yahoo.com> X-YMail-OSG: U0vR.DgVM1lVqYPba1lpPOyGu3d41xbIS28.Y64lft3Ta2cqulPmbzroQho8uRuSzgnkk1yqOapJ.R_K.zlDlHDjSI5la0QPTngExRBzeWul4gYCSw8JVHjGbLyyIyBSdT6MGpvcLgmlEgj3hXONFKHCS3D8rRI4WjJ9kbQK2rmKw.kGLoNtiydNL6SX6Y0_iE34UD37g9BHlt5Aui1HsOPW7kRV8H5WjO3DxZ.j_oe7T9aOkvPX3Q._d9M2Ond2pT58OHrJxG4pPj42e50IgVCDB7KNyq1IPumiPSZaZKGuYa.z0rulZFAlrJ.Az1RwcKzMQhgVi79.9QsWt9tUJBTv.rcQGuks5PXC.4gqW4WH Received: from [87.126.120.179] by web25001.mail.ukl.yahoo.com via HTTP; Thu, 18 Jun 2009 12:45:47 GMT X-Mailer: YahooMailClassic/5.4.17 YahooMailWebService/0.7.289.15 Date: Thu, 18 Jun 2009 12:45:47 +0000 (GMT) From: Ivailo Bonev To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 18 Jun 2009 14:06:12 +0000 Subject: kernel with ndis 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: Thu, 18 Jun 2009 12:45:49 -0000 I want to compile kernel with ndis support to use it for wireless. I've ins= erted only these 2 lines in GENERIC: options NDISAPI device ndis but I see this error: :> hack.c cc -shared -nostdlib hack.c -o hack.So rm -f hack.c MAKE=3Dmake sh ../../../conf/newvers.sh GENERIC cc -c -O -pipe -std=3Dc99 -g -Wall -Wredundant-decls -Wnested-externs -Wst= rict-pr ototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wunde= f -Wn o-pointer-sign -fformat-extensions -nostdinc -I. -I../../.. -I../../../con= trib/ altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-comm= on -f inline-limit=3D8000 --param inline-unit-growth=3D100 --param large-function= -growth=3D1 000 -mno-align-long-strings -mpreferred-stack-boundary=3D2 -mno-mmx -mno-= 3dnow - mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror vers.= c linking kernel.debug if_ndis.o(.text+0x179f): In function `ndis_detach': ../../../dev/if_ndis/if_ndis.c:1080: undefined reference to `ndis_free_amem= ' if_ndis.o(.text+0x196c): In function `ndis_attach': ../../../dev/if_ndis/if_ndis.c:565: undefined reference to `ndis_alloc_amem= ' *** Error code 1 ibb# uname -a FreeBSD ibb.bsdsys-bg.com 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Tue Jun 16 04= :54:1 8 EEST 2009 root@ibb.bsdsys-bg.com:/usr/obj/usr/src/sys/GENERIC i386= =0A=0A=0A From owner-freebsd-current@FreeBSD.ORG Thu Jun 18 14:17:21 2009 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 094D3106564A; Thu, 18 Jun 2009 14:17:21 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-bw0-f227.google.com (mail-bw0-f227.google.com [209.85.218.227]) by mx1.freebsd.org (Postfix) with ESMTP id 4A9758FC0C; Thu, 18 Jun 2009 14:17:19 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: by bwz27 with SMTP id 27so305026bwz.43 for ; Thu, 18 Jun 2009 07:17:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ST5gpClkQPcoYSdvoyHbTNmFfd/gL+2dyMdASUVYiug=; b=jk9QsTzYkOhu735jzj8qBoGAX3/9EVEl03ShoXQdUFg9pIgEqSHKCXK7Dkvy9BwZi7 oLGb6nRKi5n4Otrce8BXQFfBVUNtzpBh6dIJfwbhq8OoWhrdvCON9BCgYOw8JatwBZzr vBSGQvN3XfHrgkURacCdQRMmvTTRvDN/Up2Hc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=xPbbHmtTU0y5RMgquwX6cMkRnJ654SNGAXf9gtfTz2pkdcHuZvszJOVFC1Mydgdr5/ K4Qo69oYq0hYVjIoY7cNSD/p55ELMB1U7C9sNxbLZHs00+ZVFR2Nwo8eHP+EU0gZfgrG LXqwP81rKjCAfb7BpNs7+xtuXQIDXS+HR9Cu8= MIME-Version: 1.0 Received: by 10.103.168.12 with SMTP id v12mr1076813muo.45.1245334639064; Thu, 18 Jun 2009 07:17:19 -0700 (PDT) In-Reply-To: <200906180909.33511.jhb@freebsd.org> References: <200906180909.33511.jhb@freebsd.org> Date: Thu, 18 Jun 2009 18:17:19 +0400 Message-ID: From: pluknet To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: estX still not attaching properly 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, 18 Jun 2009 14:17:21 -0000 2009/6/18 John Baldwin : > On Wednesday 17 June 2009 2:29:25 pm Alexander Best wrote: >> hi there, >> >> although i'm running a very recent current which has "ACPICA 20090521", = estX >> still isn't attaching properly on my machine: >> >> est0: on cpu0 >> est: CPU supports Enhanced Speedstep, but is not recognized. >> est: cpu_vendor GenuineIntel, msr 925092506000925 >> device_attach: est0 attach returned 6 >> est1: on cpu1 >> est: CPU supports Enhanced Speedstep, but is not recognized. >> est: cpu_vendor GenuineIntel, msr 925092506000925 >> device_attach: est1 attach returned 6 > > That just means ACPI isn't providing info about the speed steppings your = CPU > provides. =A0It is odd that cpu0 has freq_levels but cpu1 does not. > While here let me also please share my own acpi/est data. I hope it would not bother you too much. est attaches to all cpu:s, but again freq_levels is only on cpu0. >From 7.2-S. cpu0: on acpi0 est0: on cpu0 p4tcc0: on cpu0 cpu1: on acpi0 est1: on cpu1 p4tcc1: on cpu1 cpu2: on acpi0 est2: on cpu2 p4tcc2: on cpu2 cpu3: on acpi0 est3: on cpu3 p4tcc3: on cpu3 cpu4: on acpi0 est4: on cpu4 p4tcc4: on cpu4 cpu5: on acpi0 est5: on cpu5 p4tcc5: on cpu5 cpu6: on acpi0 est6: on cpu6 p4tcc6: on cpu6 cpu7: on acpi0 est7: on cpu7 p4tcc7: on cpu7 dev.cpu.0.%desc: ACPI CPU dev.cpu.0.%driver: cpu dev.cpu.0.%location: handle=3D\_PR_.CPU0 dev.cpu.0.%pnpinfo: _HID=3Dnone _UID=3D0 dev.cpu.0.%parent: acpi0 dev.cpu.0.freq: 2822 dev.cpu.0.freq_levels: 2822/80900 2469/70787 2116/60675 1763/50562 1411/40450 1058/30337 705/20225 352/10112 dev.cpu.0.cx_supported: C1/0 dev.cpu.0.cx_lowest: C1 dev.cpu.0.cx_usage: 100.00% dev.cpu.1.%desc: ACPI CPU dev.cpu.1.%driver: cpu dev.cpu.1.%location: handle=3D\_PR_.CPU1 dev.cpu.1.%pnpinfo: _HID=3Dnone _UID=3D0 dev.cpu.1.%parent: acpi0 dev.cpu.1.cx_supported: C1/0 dev.cpu.1.cx_lowest: C1 dev.cpu.1.cx_usage: 100.00% dev.cpu.2.%desc: ACPI CPU dev.cpu.2.%driver: cpu dev.cpu.2.%location: handle=3D\_PR_.CPU2 dev.cpu.2.%pnpinfo: _HID=3Dnone _UID=3D0 dev.cpu.2.%parent: acpi0 dev.cpu.2.cx_supported: C1/0 dev.cpu.2.cx_lowest: C1 dev.cpu.2.cx_usage: 100.00% dev.cpu.3.%desc: ACPI CPU dev.cpu.3.%driver: cpu dev.cpu.3.%location: handle=3D\_PR_.CPU3 dev.cpu.3.%pnpinfo: _HID=3Dnone _UID=3D0 dev.cpu.3.%parent: acpi0 dev.cpu.3.cx_supported: C1/0 dev.cpu.3.cx_lowest: C1 dev.cpu.3.cx_usage: 100.00% dev.cpu.4.%desc: ACPI CPU dev.cpu.4.%driver: cpu dev.cpu.4.%location: handle=3D\_PR_.CPU4 dev.cpu.4.%pnpinfo: _HID=3Dnone _UID=3D0 dev.cpu.4.%parent: acpi0 dev.cpu.4.cx_supported: C1/0 dev.cpu.4.cx_lowest: C1 dev.cpu.4.cx_usage: 100.00% dev.cpu.5.%desc: ACPI CPU dev.cpu.5.%driver: cpu dev.cpu.5.%location: handle=3D\_PR_.CPU5 dev.cpu.5.%pnpinfo: _HID=3Dnone _UID=3D0 dev.cpu.5.%parent: acpi0 dev.cpu.5.cx_supported: C1/0 dev.cpu.5.cx_lowest: C1 dev.cpu.5.cx_usage: 100.00% dev.cpu.6.%desc: ACPI CPU dev.cpu.6.%driver: cpu dev.cpu.6.%location: handle=3D\_PR_.CPU6 dev.cpu.6.%pnpinfo: _HID=3Dnone _UID=3D0 dev.cpu.6.%parent: acpi0 dev.cpu.6.cx_supported: C1/0 dev.cpu.6.cx_lowest: C1 dev.cpu.6.cx_usage: 100.00% dev.cpu.7.%desc: ACPI CPU dev.cpu.7.%driver: cpu dev.cpu.7.%location: handle=3D\_PR_.CPU7 dev.cpu.7.%pnpinfo: _HID=3Dnone _UID=3D0 dev.cpu.7.%parent: acpi0 dev.cpu.7.cx_supported: C1/0 dev.cpu.7.cx_lowest: C1 dev.cpu.7.cx_usage: 100.00% dev.p4tcc.0.%desc: CPU Frequency Thermal Control dev.p4tcc.0.%driver: p4tcc dev.p4tcc.0.%parent: cpu0 dev.p4tcc.0.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1 2500/-1 1250/-1 dev.p4tcc.1.%desc: CPU Frequency Thermal Control dev.p4tcc.1.%driver: p4tcc dev.p4tcc.1.%parent: cpu1 dev.p4tcc.1.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1 2500/-1 1250/-1 dev.p4tcc.2.%desc: CPU Frequency Thermal Control dev.p4tcc.2.%driver: p4tcc dev.p4tcc.2.%parent: cpu2 dev.p4tcc.2.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1 2500/-1 1250/-1 dev.p4tcc.3.%desc: CPU Frequency Thermal Control dev.p4tcc.3.%driver: p4tcc dev.p4tcc.3.%parent: cpu3 dev.p4tcc.3.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1 2500/-1 1250/-1 dev.p4tcc.4.%desc: CPU Frequency Thermal Control dev.p4tcc.4.%driver: p4tcc dev.p4tcc.4.%parent: cpu4 dev.p4tcc.4.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1 2500/-1 1250/-1 dev.p4tcc.5.%desc: CPU Frequency Thermal Control dev.p4tcc.5.%driver: p4tcc dev.p4tcc.5.%parent: cpu5 dev.p4tcc.5.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1 2500/-1 1250/-1 dev.p4tcc.6.%desc: CPU Frequency Thermal Control dev.p4tcc.6.%driver: p4tcc dev.p4tcc.6.%parent: cpu6 dev.p4tcc.6.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1 2500/-1 1250/-1 dev.p4tcc.7.%desc: CPU Frequency Thermal Control dev.p4tcc.7.%driver: p4tcc dev.p4tcc.7.%parent: cpu7 dev.p4tcc.7.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1 2500/-1 1250/-1 hth --=20 wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Thu Jun 18 14:29:09 2009 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 8088B106566C for ; Thu, 18 Jun 2009 14:29:09 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-fx0-f206.google.com (mail-fx0-f206.google.com [209.85.220.206]) by mx1.freebsd.org (Postfix) with ESMTP id 142738FC13 for ; Thu, 18 Jun 2009 14:29:08 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: by fxm2 with SMTP id 2so136406fxm.43 for ; Thu, 18 Jun 2009 07:29:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=/46c3x9xVK4v6tavJUsA4An00VsuOsVcXCP9VjBQ+eI=; b=E02meEP/hi6yzS5tFeQ++Jw5HZCxx6MUspKoetVbGsAeEhvGdmArM+0mwxH+Lrp4sT //vgEl6/W5aHDOGQF/zmyhUTJjLgeSPHwNe1oGEl10dCoGqyvIfSi9h9RzzX6tffHV8O 67eISi4e5IavadmtNvri2yGIYmLDULfyVgVdA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=tNSfXCukI5YG40Ork2DKZk9LsUWtZcXgc4I6Pw5OI+QmEE/DDYIuL1tOCTXDRu8yJf 48vtj69hgLUhdKBH6bO9PJ5Bci/ZmZWV5qDytQJBxAab8PwSwbFGlP7H8h6CHQu2zjI8 7AdMUnphcM+NB/meDPozF2WyIeMO8ehq1oyiM= MIME-Version: 1.0 Received: by 10.102.228.10 with SMTP id a10mr1087499muh.26.1245335347445; Thu, 18 Jun 2009 07:29:07 -0700 (PDT) In-Reply-To: <538522.48180.qm@web25001.mail.ukl.yahoo.com> References: <538522.48180.qm@web25001.mail.ukl.yahoo.com> Date: Thu, 18 Jun 2009 18:29:07 +0400 Message-ID: From: pluknet To: Ivailo Bonev Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: kernel with ndis 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: Thu, 18 Jun 2009 14:29:09 -0000 2009/6/18 Ivailo Bonev : > > I want to compile kernel with ndis support to use it for wireless. I've i= nserted only these 2 lines in GENERIC: > options =A0 =A0 =A0 =A0 NDISAPI > device =A0 =A0 =A0 =A0 =A0ndis > I guess you have to add device pccard to your kernel config. > but I see this error: > > :> hack.c > cc -shared -nostdlib hack.c -o hack.So > rm -f hack.c > MAKE=3Dmake sh ../../../conf/newvers.sh GENERIC > cc -c -O -pipe =A0-std=3Dc99 -g -Wall -Wredundant-decls -Wnested-externs = -Wstrict-pr > ototypes =A0-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual =A0= -Wundef -Wn > o-pointer-sign -fformat-extensions -nostdinc =A0-I. -I../../.. -I../../..= /contrib/ > altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-co= mmon -f > inline-limit=3D8000 --param inline-unit-growth=3D100 --param large-functi= on-growth=3D1 > 000 =A0-mno-align-long-strings -mpreferred-stack-boundary=3D2 =A0-mno-mmx= -mno-3dnow - > mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror =A0v= ers.c > linking kernel.debug > if_ndis.o(.text+0x179f): In function `ndis_detach': > ../../../dev/if_ndis/if_ndis.c:1080: undefined reference to `ndis_free_am= em' > if_ndis.o(.text+0x196c): In function `ndis_attach': > ../../../dev/if_ndis/if_ndis.c:565: undefined reference to `ndis_alloc_am= em' > *** Error code 1 > > ibb# uname -a > FreeBSD ibb.bsdsys-bg.com 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Tue Jun 16 = 04:54:1 > 8 EEST 2009 =A0 =A0 root@ibb.bsdsys-bg.com:/usr/obj/usr/src/sys/GENERIC = =A0i386 > --=20 wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Thu Jun 18 14:55:08 2009 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 C4D10106566B for ; Thu, 18 Jun 2009 14:55:08 +0000 (UTC) (envelope-from adamk@voicenet.com) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [76.96.59.211]) by mx1.freebsd.org (Postfix) with ESMTP id 74CB18FC15 for ; Thu, 18 Jun 2009 14:55:08 +0000 (UTC) (envelope-from adamk@voicenet.com) Received: from OMTA03.westchester.pa.mail.comcast.net ([76.96.62.27]) by QMTA11.westchester.pa.mail.comcast.net with comcast id 5NNL1c0060bG4ec5BShtT5; Thu, 18 Jun 2009 14:41:53 +0000 Received: from scroll.ashke.com ([67.103.204.242]) by OMTA03.westchester.pa.mail.comcast.net with comcast id 5Shj1c0025EJinX3PShlk4; Thu, 18 Jun 2009 14:41:51 +0000 Message-ID: <4A3A5225.2090905@voicenet.com> Date: Thu, 18 Jun 2009 10:41:41 -0400 From: Adam K Kirchhoff User-Agent: Thunderbird 2.0.0.21 (X11/20090515) MIME-Version: 1.0 To: Ivailo Bonev References: <538522.48180.qm@web25001.mail.ukl.yahoo.com> In-Reply-To: <538522.48180.qm@web25001.mail.ukl.yahoo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: kernel with ndis 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: Thu, 18 Jun 2009 14:55:09 -0000 Ivailo Bonev wrote: > I want to compile kernel with ndis support to use it for wireless. I've inserted only these 2 lines in GENERIC: > options NDISAPI > device ndis > > but I see this error: > > :> hack.c > cc -shared -nostdlib hack.c -o hack.So > rm -f hack.c > MAKE=make sh ../../../conf/newvers.sh GENERIC > cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-pr > ototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wn > o-pointer-sign -fformat-extensions -nostdinc -I. -I../../.. -I../../../contrib/ > altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -f > inline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1 > 000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow - > mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror vers.c > linking kernel.debug > if_ndis.o(.text+0x179f): In function `ndis_detach': > ../../../dev/if_ndis/if_ndis.c:1080: undefined reference to `ndis_free_amem' > if_ndis.o(.text+0x196c): In function `ndis_attach': > ../../../dev/if_ndis/if_ndis.c:565: undefined reference to `ndis_alloc_amem' > *** Error code 1 > > ibb# uname -a > FreeBSD ibb.bsdsys-bg.com 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Tue Jun 16 04:54:1 > 8 EEST 2009 root@ibb.bsdsys-bg.com:/usr/obj/usr/src/sys/GENERIC i386 > > Is there some reason you aren't using is as a module? It's comes built that way on GENERIC and should work just fine. Adam From owner-freebsd-current@FreeBSD.ORG Thu Jun 18 16:48:29 2009 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 26F5E1065700 for ; Thu, 18 Jun 2009 16:48:29 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from ch-smtp01.sth.basefarm.net (ch-smtp01.sth.basefarm.net [80.76.149.212]) by mx1.freebsd.org (Postfix) with ESMTP id AE5B58FC20 for ; Thu, 18 Jun 2009 16:48:28 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from c83-253-252-234.bredband.comhem.se ([83.253.252.234]:58122 helo=mx.exscape.org) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.69) (envelope-from ) id 1MHKmc-0000A2-3i for freebsd-current@freebsd.org; Thu, 18 Jun 2009 18:48:16 +0200 Received: from [192.168.1.5] (macbookpro [192.168.1.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx.exscape.org (Postfix) with ESMTPSA id BBD5E6B3E0 for ; Thu, 18 Jun 2009 18:48:12 +0200 (CEST) Message-Id: <6AE25B6A-A985-4182-98CD-AD0C230274BE@exscape.org> From: Thomas Backman To: FreeBSD current Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 18 Jun 2009 18:48:11 +0200 X-Mailer: Apple Mail (2.935.3) X-Originating-IP: 83.253.252.234 X-Scan-Result: No virus found in message 1MHKmc-0000A2-3i. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1MHKmc-0000A2-3i 434d8f6cbef3b0f155df7d0af0aa9de2 Subject: smbfs.ko regression? 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, 18 Jun 2009 16:48:29 -0000 Has anyone else had trouble with smbfs.ko/samba mounting recently? I upgraded to r194428 today, and on reboot noticed that the computer had hanged (i.e. took way too long to boot), so I plugged a monitor in and noticed that it had hanged on loading the smbfs module/mounting a smbfs share, and then the same thing happened on "mounting late filesystems" (dmesg -a | grep late returns nothing now that it works, BTW). IIRC it dropped to single-user due to "/etc/rc returing an error" or something to that matter. I commented the line out in fstab and did an "exit" and it came up from single user beautifully. The error appears to be a bit random and I haven't been able to reproduce it, but it happened two or three times so it wasn't just a one-off. It did print some kind of error, but I guess there's no way of getting at that now? On a similar note, I can't kldunload it, either. The computer just freezes - it responds to ping, but not SSH input, and not keyboard input either (not even drop to debugger). I can't find a way out except to reset it. I don't really care too much about this part, but freezes are bad. Needless to say I can't provide a backtrace or similar - is there anything I can do to help? Still, the main issue, and question, is regarding the *loading*. [root@chaos ~]# mount|grep smbfs //SERENITY@EXSCAPE/FBSDBACKUP on /mnt/backup (smbfs) [root@chaos ~]# umount /mnt/backup [root@chaos ~]# mount|grep smbfs [root@chaos ~]# kldstat Id Refs Address Size Name 1 21 0xffffffff80100000 e61c98 kernel 2 1 0xffffffff80f62000 50ae98 zfs.ko 3 2 0xffffffff8146d000 7988 opensolaris.ko 4 1 0xffffffff81475000 3378 accf_http.ko 5 1 0xffffffff81479000 4278 amdtemp.ko 6 1 0xffffffff81622000 722e1 smbfs.ko 7 2 0xffffffff81695000 6694 libiconv.ko 8 2 0xffffffff8169c000 1740 libmchain.ko [root@chaos ~]# kldunload smbfs After quite a while: Read from remote host 192.168.1.10: Connection reset by peer "kldunload amdtemp" succeeds, by the way. Regards, Thomas From owner-freebsd-current@FreeBSD.ORG Thu Jun 18 18:13:13 2009 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 3E43F106568D for ; Thu, 18 Jun 2009 18:13:13 +0000 (UTC) (envelope-from ibb_orac@mbox.contact.bg) Received: from sd97.btc-net.bg (SD97.btc-net.bg [212.39.90.97]) by mx1.freebsd.org (Postfix) with SMTP id 86DB38FC12 for ; Thu, 18 Jun 2009 18:13:12 +0000 (UTC) (envelope-from ibb_orac@mbox.contact.bg) Received: (qmail 9576 invoked by uid 605); 18 Jun 2009 18:06:33 -0000 Received: from unknown (HELO chameleon) (83.228.34.40) by 0 with SMTP; 18 Jun 2009 18:06:33 -0000 Message-ID: From: "Ivailo Bonev" To: "Adam K Kirchhoff" References: <538522.48180.qm@web25001.mail.ukl.yahoo.com> <4A3A5225.2090905@voicenet.com> Date: Thu, 18 Jun 2009 21:06:16 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Cc: freebsd-current@freebsd.org Subject: Re: kernel with ndis 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: Thu, 18 Jun 2009 18:13:13 -0000 ----- Original Message ----- From: "Adam K Kirchhoff" To: "Ivailo Bonev" Cc: Sent: Thursday, June 18, 2009 5:41 PM Subject: Re: kernel with ndis support > Ivailo Bonev wrote: >> I want to compile kernel with ndis support to use it for wireless. I've >> inserted only these 2 lines in GENERIC: >> options NDISAPI >> device ndis >> >> but I see this error: >> >> :> hack.c >> cc -shared -nostdlib hack.c -o hack.So >> rm -f hack.c >> MAKE=make sh ../../../conf/newvers.sh GENERIC >> cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-pr >> >> totypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef >> -Wn >> o-pointer-sign -fformat-extensions -nostdinc -I. -I../../.. -I../../../contrib/ >> altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include >> opt_global.h -fno-common -f >> inline-limit=8000 --param inline-unit-growth=100 --param >> large-function-growth=1 >> 000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow >> - >> mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror >> vers.c >> linking kernel.debug >> if_ndis.o(.text+0x179f): In function `ndis_detach': >> ../../../dev/if_ndis/if_ndis.c:1080: undefined reference to >> `ndis_free_amem' >> if_ndis.o(.text+0x196c): In function `ndis_attach': >> ../../../dev/if_ndis/if_ndis.c:565: undefined reference to >> `ndis_alloc_amem' >> *** Error code 1 >> >> ibb# uname -a >> FreeBSD ibb.bsdsys-bg.com 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Tue Jun 16 >> 04:54:1 >> 8 EEST 2009 root@ibb.bsdsys-bg.com:/usr/obj/usr/src/sys/GENERIC i386 >> >> > > Is there some reason you aren't using is as a module? It's comes built > that way on GENERIC and should work just fine. > > Adam > > _______________________________________________ > 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" > No, I'm just an old style user, and want every driver that PC use, to be in kernel :) From owner-freebsd-current@FreeBSD.ORG Thu Jun 18 18:26:38 2009 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 E71281065672 for ; Thu, 18 Jun 2009 18:26:38 +0000 (UTC) (envelope-from ibb_orac@mbox.contact.bg) Received: from sd97.btc-net.bg (SD97.btc-net.bg [212.39.90.97]) by mx1.freebsd.org (Postfix) with SMTP id 756D88FC12 for ; Thu, 18 Jun 2009 18:26:38 +0000 (UTC) (envelope-from ibb_orac@mbox.contact.bg) Received: (qmail 4096 invoked by uid 605); 18 Jun 2009 18:00:00 -0000 Received: from unknown (HELO chameleon) (83.228.34.40) by 0 with SMTP; 18 Jun 2009 17:59:59 -0000 Message-ID: From: "Ivailo Bonev" To: Date: Thu, 18 Jun 2009 20:59:43 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="windows-1251"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Subject: How to grab a dump from panic on boot in FreeBSD 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: Thu, 18 Jun 2009 18:26:39 -0000 I want to send a panic that is reproducible when boot my laptop with ndis module for Broadcom wireless card, but don't know how to send screen output to a file? Can anyone help me? From owner-freebsd-current@FreeBSD.ORG Thu Jun 18 21:39:49 2009 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 66B6110656F5 for ; Thu, 18 Jun 2009 21:39:49 +0000 (UTC) (envelope-from thierry.herbelot@free.fr) Received: from smtp4-g21.free.fr (smtp4-g21.free.fr [212.27.42.4]) by mx1.freebsd.org (Postfix) with ESMTP id C283B8FC0A for ; Thu, 18 Jun 2009 21:39:47 +0000 (UTC) (envelope-from thierry.herbelot@free.fr) Received: from smtp4-g21.free.fr (localhost [127.0.0.1]) by smtp4-g21.free.fr (Postfix) with ESMTP id BC1174C8164 for ; Thu, 18 Jun 2009 23:39:43 +0200 (CEST) Received: from mail.herbelot.nom (bne75-4-82-227-159-103.fbx.proxad.net [82.227.159.103]) by smtp4-g21.free.fr (Postfix) with ESMTP id 831634C813F for ; Thu, 18 Jun 2009 23:39:40 +0200 (CEST) Received: from tulipe.herbelot.nom (tulipe.herbelot.nom [192.168.2.5]) by mail.herbelot.nom (8.14.1/8.14.1) with ESMTP id n5ILdYa2027886; Thu, 18 Jun 2009 23:39:36 +0200 (CEST) From: Thierry Herbelot To: freebsd-current@freebsd.org Date: Thu, 18 Jun 2009 23:39:29 +0200 User-Agent: KMail/1.9.10 References: In-Reply-To: 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="iso-8859-15" Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200906182339.29530.thierry.herbelot@free.fr> Cc: Ivailo Bonev Subject: Re: How to grab a dump from panic on boot in FreeBSD 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: Thu, 18 Jun 2009 21:39:50 -0000 Le Thursday 18 June 2009, Ivailo Bonev a écrit : > I want to send a panic that is reproducible when boot my laptop with ndis > module for Broadcom wireless card, but don't know how to send screen output > to a file? Can anyone help me? you may want to use a serial console (if your notebook is old enough to still have a serial port ...), by adding the following line to /boot/loader.conf : -%------------------------ console="comconsole" -%------------------------ TfH PS : if there is no serial port, you may want to use a firewire port (or else, use a camera to take a picture of the screen, when you have the panic message) > > > _______________________________________________ > 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 Thu Jun 18 21:53:55 2009 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 32286106568E for ; Thu, 18 Jun 2009 21:53:55 +0000 (UTC) (envelope-from ibb_orac@mbox.contact.bg) Received: from sd97.btc-net.bg (SD97.btc-net.bg [212.39.90.97]) by mx1.freebsd.org (Postfix) with SMTP id 652858FC1D for ; Thu, 18 Jun 2009 21:53:54 +0000 (UTC) (envelope-from ibb_orac@mbox.contact.bg) Received: (qmail 30652 invoked by uid 605); 18 Jun 2009 21:53:56 -0000 Received: from unknown (HELO chameleon) (83.228.34.40) by 0 with SMTP; 18 Jun 2009 21:53:56 -0000 Message-ID: <60A35D1E3B604ED8B6949A8EEA68C8E5@chameleon> From: "Ivailo Bonev" To: "Thierry Herbelot" References: <200906182339.29530.thierry.herbelot@free.fr> Date: Fri, 19 Jun 2009 00:53:38 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="ISO-8859-15"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Cc: freebsd-current@freebsd.org Subject: Re: How to grab a dump from panic on boot in FreeBSD 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: Thu, 18 Jun 2009 21:53:57 -0000 ----- Original Message ----- From: "Thierry Herbelot" To: Cc: "Ivailo Bonev" Sent: Friday, June 19, 2009 12:39 AM Subject: Re: How to grab a dump from panic on boot in FreeBSD Current? > Le Thursday 18 June 2009, Ivailo Bonev a écrit : >> I want to send a panic that is reproducible when boot my laptop with ndis >> module for Broadcom wireless card, but don't know how to send screen >> output >> to a file? Can anyone help me? > > you may want to use a serial console (if your notebook is old enough to > still > have a serial port ...), by adding the following line to /boot/loader.conf > : > -%------------------------ > console="comconsole" > -%------------------------ > > TfH > > PS : if there is no serial port, you may want to use a firewire port (or > else, > use a camera to take a picture of the screen, when you have the panic > message) >> >> >> _______________________________________________ >> 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" > I don't have a serial port, ant don't have firewire. I had impression that it is possible with newest "textdump"? From owner-freebsd-current@FreeBSD.ORG Thu Jun 18 21:54:56 2009 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 A0D23106567E; Thu, 18 Jun 2009 21:54:56 +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 610118FC16; Thu, 18 Jun 2009 21:54:56 +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.3/8.14.3) with ESMTP id n5ILssuN025989; Thu, 18 Jun 2009 17:54:54 -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 n5ILssFf029680; Thu, 18 Jun 2009 17:54:54 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id C807B73030; Thu, 18 Jun 2009 17:54:53 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090618215453.C807B73030@freebsd-current.sentex.ca> Date: Thu, 18 Jun 2009 17:54:53 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp2.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on amd64/amd64 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, 18 Jun 2009 21:54:58 -0000 TB --- 2009-06-18 19:40:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-06-18 19:40:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2009-06-18 19:40:00 - cleaning the object tree TB --- 2009-06-18 19:41:07 - cvsupping the source tree TB --- 2009-06-18 19:41:08 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/amd64/amd64/supfile TB --- 2009-06-18 19:41:15 - building world TB --- 2009-06-18 19:41:15 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-18 19:41:15 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-18 19:41:15 - TARGET=amd64 TB --- 2009-06-18 19:41:15 - TARGET_ARCH=amd64 TB --- 2009-06-18 19:41:15 - TZ=UTC TB --- 2009-06-18 19:41:15 - __MAKE_CONF=/dev/null TB --- 2009-06-18 19:41:15 - cd /src TB --- 2009-06-18 19:41:15 - /usr/bin/make -B buildworld >>> World build started on Thu Jun 18 19:41:17 UTC 2009 >>> 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 >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Thu Jun 18 21:41:09 UTC 2009 TB --- 2009-06-18 21:41:09 - generating LINT kernel config TB --- 2009-06-18 21:41:09 - cd /src/sys/amd64/conf TB --- 2009-06-18 21:41:09 - /usr/bin/make -B LINT TB --- 2009-06-18 21:41:09 - building LINT kernel TB --- 2009-06-18 21:41:09 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-18 21:41:09 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-18 21:41:09 - TARGET=amd64 TB --- 2009-06-18 21:41:09 - TARGET_ARCH=amd64 TB --- 2009-06-18 21:41:09 - TZ=UTC TB --- 2009-06-18 21:41:09 - __MAKE_CONF=/dev/null TB --- 2009-06-18 21:41:09 - cd /src TB --- 2009-06-18 21:41:09 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Jun 18 21:41:10 UTC 2009 >>> 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 [...] cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/kern/kern_lockstat.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/kern/kern_malloc.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/kern/kern_mbuf.c cc1: warnings being treated as errors /src/sys/kern/kern_mbuf.c: In function 'mbuf_jumbo_alloc': /src/sys/kern/kern_mbuf.c:358: warning: implicit declaration of function 'kmem_alloc_contig' /src/sys/kern/kern_mbuf.c:358: warning: nested extern declaration of 'kmem_alloc_contig' /src/sys/kern/kern_mbuf.c:359: warning: cast to pointer from integer of different size *** Error code 1 Stop in /obj/amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-18 21:54:53 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-18 21:54:53 - ERROR: failed to build lint kernel TB --- 2009-06-18 21:54:53 - 6279.68 user 642.88 system 8092.80 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Thu Jun 18 22:25:19 2009 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 B65E2106568C; Thu, 18 Jun 2009 22:25:19 +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 3F5338FC08; Thu, 18 Jun 2009 22:25:18 +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.3/8.14.3) with ESMTP id n5IMPGg7028364; Thu, 18 Jun 2009 18:25:16 -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 n5IMPGuu095826; Thu, 18 Jun 2009 18:25:16 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 8571973030; Thu, 18 Jun 2009 18:25:16 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090618222516.8571973030@freebsd-current.sentex.ca> Date: Thu, 18 Jun 2009 18:25:16 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp2.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on i386/i386 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, 18 Jun 2009 22:25:20 -0000 TB --- 2009-06-18 20:48:01 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-06-18 20:48:01 - starting HEAD tinderbox run for i386/i386 TB --- 2009-06-18 20:48:01 - cleaning the object tree TB --- 2009-06-18 20:48:44 - cvsupping the source tree TB --- 2009-06-18 20:48:44 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/i386/supfile TB --- 2009-06-18 20:48:51 - building world TB --- 2009-06-18 20:48:51 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-18 20:48:51 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-18 20:48:51 - TARGET=i386 TB --- 2009-06-18 20:48:51 - TARGET_ARCH=i386 TB --- 2009-06-18 20:48:51 - TZ=UTC TB --- 2009-06-18 20:48:51 - __MAKE_CONF=/dev/null TB --- 2009-06-18 20:48:51 - cd /src TB --- 2009-06-18 20:48:51 - /usr/bin/make -B buildworld >>> World build started on Thu Jun 18 20:48:53 UTC 2009 >>> 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 Jun 18 22:11:28 UTC 2009 TB --- 2009-06-18 22:11:28 - generating LINT kernel config TB --- 2009-06-18 22:11:28 - cd /src/sys/i386/conf TB --- 2009-06-18 22:11:28 - /usr/bin/make -B LINT TB --- 2009-06-18 22:11:28 - building LINT kernel TB --- 2009-06-18 22:11:28 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-18 22:11:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-18 22:11:28 - TARGET=i386 TB --- 2009-06-18 22:11:28 - TARGET_ARCH=i386 TB --- 2009-06-18 22:11:28 - TZ=UTC TB --- 2009-06-18 22:11:28 - __MAKE_CONF=/dev/null TB --- 2009-06-18 22:11:28 - cd /src TB --- 2009-06-18 22:11:28 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Jun 18 22:11:28 UTC 2009 >>> 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 [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/kern/kern_lockf.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/kern/kern_lockstat.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/kern/kern_malloc.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/kern/kern_mbuf.c cc1: warnings being treated as errors /src/sys/kern/kern_mbuf.c: In function 'mbuf_jumbo_alloc': /src/sys/kern/kern_mbuf.c:358: warning: implicit declaration of function 'kmem_alloc_contig' /src/sys/kern/kern_mbuf.c:358: warning: nested extern declaration of 'kmem_alloc_contig' *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-18 22:25:16 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-18 22:25:16 - ERROR: failed to build lint kernel TB --- 2009-06-18 22:25:16 - 4606.34 user 441.03 system 5835.42 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Thu Jun 18 23:29:04 2009 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 C2E631065690; Thu, 18 Jun 2009 23:29: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 98AC18FC08; Thu, 18 Jun 2009 23:29: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.3/8.14.3) with ESMTP id n5INT2Kx032710; Thu, 18 Jun 2009 19:29:02 -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 n5INT2HB027204; Thu, 18 Jun 2009 19:29:02 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id D1C7173030; Thu, 18 Jun 2009 19:29:01 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090618232901.D1C7173030@freebsd-current.sentex.ca> Date: Thu, 18 Jun 2009 19:29:01 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp2.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on i386/pc98 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, 18 Jun 2009 23:29:05 -0000 TB --- 2009-06-18 21:54:53 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-06-18 21:54:53 - starting HEAD tinderbox run for i386/pc98 TB --- 2009-06-18 21:54:53 - cleaning the object tree TB --- 2009-06-18 21:55:29 - cvsupping the source tree TB --- 2009-06-18 21:55:29 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/pc98/supfile TB --- 2009-06-18 21:55:37 - building world TB --- 2009-06-18 21:55:37 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-18 21:55:37 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-18 21:55:37 - TARGET=pc98 TB --- 2009-06-18 21:55:37 - TARGET_ARCH=i386 TB --- 2009-06-18 21:55:37 - TZ=UTC TB --- 2009-06-18 21:55:37 - __MAKE_CONF=/dev/null TB --- 2009-06-18 21:55:37 - cd /src TB --- 2009-06-18 21:55:37 - /usr/bin/make -B buildworld >>> World build started on Thu Jun 18 21:55:38 UTC 2009 >>> 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 Jun 18 23:17:02 UTC 2009 TB --- 2009-06-18 23:17:02 - generating LINT kernel config TB --- 2009-06-18 23:17:02 - cd /src/sys/pc98/conf TB --- 2009-06-18 23:17:02 - /usr/bin/make -B LINT TB --- 2009-06-18 23:17:02 - building LINT kernel TB --- 2009-06-18 23:17:02 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-18 23:17:02 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-18 23:17:02 - TARGET=pc98 TB --- 2009-06-18 23:17:02 - TARGET_ARCH=i386 TB --- 2009-06-18 23:17:02 - TZ=UTC TB --- 2009-06-18 23:17:02 - __MAKE_CONF=/dev/null TB --- 2009-06-18 23:17:02 - cd /src TB --- 2009-06-18 23:17:02 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Jun 18 23:17:02 UTC 2009 >>> 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 [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/kern/kern_lockf.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/kern/kern_lockstat.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/kern/kern_malloc.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/kern/kern_mbuf.c cc1: warnings being treated as errors /src/sys/kern/kern_mbuf.c: In function 'mbuf_jumbo_alloc': /src/sys/kern/kern_mbuf.c:358: warning: implicit declaration of function 'kmem_alloc_contig' /src/sys/kern/kern_mbuf.c:358: warning: nested extern declaration of 'kmem_alloc_contig' *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-18 23:29:01 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-18 23:29:01 - ERROR: failed to build lint kernel TB --- 2009-06-18 23:29:01 - 4456.66 user 444.34 system 5647.73 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Fri Jun 19 02:59:35 2009 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 36639106566C for ; Fri, 19 Jun 2009 02:59:35 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.245]) by mx1.freebsd.org (Postfix) with ESMTP id E1B278FC15 for ; Fri, 19 Jun 2009 02:59:34 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: by an-out-0708.google.com with SMTP id c3so658339ana.13 for ; Thu, 18 Jun 2009 19:59:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=zVdtfsrCqUmWWGjuf61R7XMiONPpbcfYTILvYnzAyGs=; b=b3e2kVfLt8e1Gl+rzMWhiiPGZGys1tTbyTYYku40mhpPtXG6x7yNQ1f2yo7Zh1r4Q7 N6pOyeJaJsujr+CBxk71nHF+lK9H14ZtA5kxzQLIOS8vwjLKm9l5Kncu9HVBw1GlEe7H 9FfBLTRpqt5kLqNLUFY28dT/MJRFEMibSWKXM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=UWDwiLoy8o1pB35RC3URRGOfUhPEw+qV2nQIIwHD5AaCUzQIuagVwZZGLHJTAPKq6J 8iwgcuGJK+568ivrUsMNxuLgZC0FQydE0pQiiHJdS1RHQBoUNHHEyrbkAa9vW0So8g1X Bqj+2x8yJ5/g+h44DNbY0Eb95dW8IGfKn80y8= MIME-Version: 1.0 Sender: mat.macy@gmail.com Received: by 10.100.45.13 with SMTP id s13mr3087142ans.193.1245380374194; Thu, 18 Jun 2009 19:59:34 -0700 (PDT) In-Reply-To: References: Date: Thu, 18 Jun 2009 19:59:34 -0700 X-Google-Sender-Auth: c7d3124011518ca8 Message-ID: <3c1674c90906181959m7cf149ccpabb78fa7c0c8247b@mail.gmail.com> From: Kip Macy To: Artem Belevich Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: Crash in ZFS during vnode sync 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, 19 Jun 2009 02:59:35 -0000 It looks like you tried to lock a destroyed vnode. Did you get a core? Cheers, Kip On Tue, Jun 16, 2009 at 3:10 PM, Artem Belevich wrote: > Got a new crash on fresh (as of yesterday) -current/amd64 while the > box was pretty much idle. Haven't seen this one before. > > Fatal trap 12: page fault while in kernel mode > cpuid =3D 3; apic id =3D 03 > fault virtual address =A0 =3D 0xd8 > fault code =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D supervisor write data, page not= present > instruction pointer =A0 =A0 =3D 0x20:0xffffffff80360a35 > stack pointer =A0 =A0 =A0 =A0 =A0 =3D 0x28:0xffffff842cfc8900 > frame pointer =A0 =A0 =A0 =A0 =A0 =3D 0x28:0xffffff842cfc8910 > code segment =A0 =A0 =A0 =A0 =A0 =A0=3D base 0x0, limit 0xfffff, type 0x1= b > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D DPL 0, pres 1, long 1,= def32 0, gran 1 > processor eflags =A0 =A0 =A0 =A0=3D interrupt enabled, resume, IOPL =3D 0 > current process =A0 =A0 =A0 =A0 =3D 48 (syncer) > [thread pid 48 tid 100076 ] > Stopped at =A0 =A0 =A0_mtx_lock_flags+0x15: =A0 lock cmpxchgq =A0 %rsi,0x= 18(%rdi) > db> where > Tracing pid 48 tid 100076 td 0xffffff0007b0a390 > _mtx_lock_flags() at _mtx_lock_flags+0x15 > vn_rele_async() at vn_rele_async+0x31 > zfs_get_data() at zfs_get_data+0xd0 > zil_commit() at zil_commit+0x532 > zfs_sync() at zfs_sync+0xa6 > sync_fsync() at sync_fsync+0x184 > VOP_FSYNC_APV() at VOP_FSYNC_APV+0x4a > sync_vnode() at sync_vnode+0x16b > sched_sync() at sched_sync+0x1c9 > fork_exit() at fork_exit+0x118 > fork_trampoline() at fork_trampoline+0xe > --- trap 0, rip =3D 0, rsp =3D 0xffffff842cfc8d40, rbp =3D 0 --- > > db> show lockedbufs > buf at 0xffffff83c11d8550 > b_flags =3D 0xa00200a0 > b_error =3D 0, b_bufsize =3D 4096, b_bcount =3D 4096, b_resid =3D 0 > b_bufobj =3D (0xffffff0012c7a2f0), b_data =3D 0xffffff83da5fa000, b_blkno > =3D 19214240, b_dep =3D 0 > b_npages =3D 1, pages(OBJ, IDX, PA): (0xffffff003d5b47d0, 0x0, 0x3c082000= ) > lock type bufwait: EXCL by thread 0xffffff0010e85720 (pid 886) > > db> show lockedvnods > Locked vnodes > > 0xffffff0012c7a1d8: tag ufs, type VREG > =A0 =A0usecount 1, writecount 1, refcount 3 mountedhere 0 > =A0 =A0flags () > =A0 =A0v_object 0xffffff003d5b47d0 ref 0 pages 1 > =A0 =A0lock type ufs: EXCL by thread 0xffffff0010e85720 (pid 886) > =A0 =A0 =A0 =A0ino 1201240, on dev ad4s1a > > 0xffffff0007db9ce8: tag syncer, type VNON > =A0 =A0usecount 1, writecount 0, refcount 2 mountedhere 0 > =A0 =A0flags () > =A0 =A0lock type syncer: EXCL by thread 0xffffff0007b0a390 (pid 48) > db> show vnodebufs > usage: show vnodebufs > db> show vnodebufs 0xffffff0007db9ce8 > Clean buffers: > Dirty buffers: > db> show vnodebufs 0xffffff0012c7a1d8 > Clean buffers: > Dirty buffers: > buf at 0xffffff83c11d8550 > b_flags =3D 0xa00200a0 > b_error =3D 0, b_bufsize =3D 4096, b_bcount =3D 4096, b_resid =3D 0 > b_bufobj =3D (0xffffff0012c7a2f0), b_data =3D 0xffffff83da5fa000, b_blkno > =3D 19214240, b_dep =3D 0 > b_npages =3D 1, pages(OBJ, IDX, PA): (0xffffff003d5b47d0, 0x0, 0x3c082000= ) > lock type bufwait: EXCL by thread 0xffffff0010e85720 (pid 886) > > db> bt 886 > Tracing pid 886 tid 100183 td 0xffffff0010e85720 > cpustop_handler() at cpustop_handler+0x3b > ipi_nmi_handler() at ipi_nmi_handler+0x30 > trap() at trap+0x195 > nmi_calltrap() at nmi_calltrap+0x8 > --- trap 0x13, rip =3D 0xffffffff803605ca, rsp =3D 0xffffff800001bfe0, rb= p > =3D 0xffffff842f52b7f0 --- > _mtx_lock_sleep() at _mtx_lock_sleep+0x11a > bdwrite() at bdwrite+0x313 > ffs_write() at ffs_write+0x634 > VOP_WRITE_APV() at VOP_WRITE_APV+0xc6 > vn_write() at vn_write+0x188 > dofilewrite() at dofilewrite+0x85 > kern_writev() at kern_writev+0x60 > writev() at writev+0x41 > syscall() at syscall+0x28f > Xfast_syscall() at Xfast_syscall+0xd0 > --- syscall (121, FreeBSD ELF64, writev), rip =3D 0x80083501c, rsp =3D > 0x7fffffffcaf8, rbp =3D 0 --- > db> bt 48 > Tracing pid 48 tid 100076 td 0xffffff0007b0a390 > _mtx_lock_flags() at _mtx_lock_flags+0x15 > vn_rele_async() at vn_rele_async+0x31 > zfs_get_data() at zfs_get_data+0xd0 > zil_commit() at zil_commit+0x532 > zfs_sync() at zfs_sync+0xa6 > sync_fsync() at sync_fsync+0x184 > VOP_FSYNC_APV() at VOP_FSYNC_APV+0x4a > sync_vnode() at sync_vnode+0x16b > sched_sync() at sched_sync+0x1c9 > fork_exit() at fork_exit+0x118 > fork_trampoline() at fork_trampoline+0xe > --- trap 0, rip =3D 0, rsp =3D 0xffffff842cfc8d40, rbp =3D 0 --- > > > > --Artem > _______________________________________________ > 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= " > --=20 When bad men combine, the good must associate; else they will fall one by one, an unpitied sacrifice in a contemptible struggle. Edmund Burke From owner-freebsd-current@FreeBSD.ORG Fri Jun 19 08:05:40 2009 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 25ED21065670 for ; Fri, 19 Jun 2009 08:05:40 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from ch-smtp01.sth.basefarm.net (ch-smtp01.sth.basefarm.net [80.76.149.212]) by mx1.freebsd.org (Postfix) with ESMTP id D4D4E8FC15 for ; Fri, 19 Jun 2009 08:05:39 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from c83-253-252-234.bredband.comhem.se ([83.253.252.234]:42209 helo=mx.exscape.org) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.69) (envelope-from ) id 1MHZ6M-0001G5-5F for freebsd-current@freebsd.org; Fri, 19 Jun 2009 10:05:36 +0200 Received: from [192.168.1.5] (macbookpro [192.168.1.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx.exscape.org (Postfix) with ESMTPSA id 7079E1674; Fri, 19 Jun 2009 10:05:33 +0200 (CEST) Message-Id: <889F64DF-7323-4C43-A6ED-3F952EE8EF10@exscape.org> From: Thomas Backman To: Thomas Backman In-Reply-To: <6AE25B6A-A985-4182-98CD-AD0C230274BE@exscape.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 19 Jun 2009 10:05:31 +0200 References: <6AE25B6A-A985-4182-98CD-AD0C230274BE@exscape.org> X-Mailer: Apple Mail (2.935.3) X-Originating-IP: 83.253.252.234 X-Scan-Result: No virus found in message 1MHZ6M-0001G5-5F. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1MHZ6M-0001G5-5F 7248519499d31310681b63a0ddd0c082 Cc: FreeBSD current Subject: Re: smbfs.ko regression? 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, 19 Jun 2009 08:05:40 -0000 On Jun 18, 2009, at 06:48 PM, Thomas Backman wrote: > Has anyone else had trouble with smbfs.ko/samba mounting recently? > > I upgraded to r194428 today, and on reboot noticed that the computer > had hanged (i.e. took way too long to boot), so I plugged a monitor > in and noticed that it had hanged on loading the smbfs module/ > mounting a smbfs share, and then the same thing happened on > "mounting late filesystems" (dmesg -a | grep late returns nothing > now that it works, BTW). IIRC it dropped to single-user due to "/etc/ > rc returing an error" or something to that matter. I commented the > line out in fstab and did an "exit" and it came up from single user > beautifully. > The error appears to be a bit random and I haven't been able to > reproduce it, but it happened two or three times so it wasn't just a > one-off. It did print some kind of error, but I guess there's no way > of getting at that now? > ... > > Regards, > Thomas OK, ignore this. Totally silly error on my side and it has nothing to do with smbfs or even FreeBSD, it was... ahem, hardware related. As in a cable being half-plugged in, half not. Damn 8P8C/RJ45 connectors breaking... ;) Regards, Thomas PS. I haven't tried unloading it, though - that's got to be a real issue. Currently compiling world+kernel so I'm not very willing to try it right now. From owner-freebsd-current@FreeBSD.ORG Fri Jun 19 08:35:45 2009 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 8637C1065670; Fri, 19 Jun 2009 08:35:45 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id 15BE68FC0C; Fri, 19 Jun 2009 08:35:45 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Subject:Message-ID:Reply-To:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender; b=oPNrfb8M5IHQA7GiIgFSg+v3BpIVsNWWFUkwURomE8rYu4AAm03IP8nPaRaDmOJMyMNlM66KCxDeQTyncxuebA2OAHU+GxLgDPAJ/4iQaBtuRyeEV32XsZC1pJofBdi1iwXX9MrpCYxhAEc8oFULXpvtuuac4DgW6Hah28gDqvU=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1MHZZX-0000I1-6h; Fri, 19 Jun 2009 12:35:43 +0400 Date: Fri, 19 Jun 2009 12:35:41 +0400 From: Eygene Ryabinkin To: pluknet Message-ID: References: <200906180909.33511.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: rea-fbsd@codelabs.ru Cc: freebsd-current@freebsd.org Subject: Re: estX still not attaching properly X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rea-fbsd@codelabs.ru List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2009 08:35:45 -0000 Good day. Thu, Jun 18, 2009 at 06:17:19PM +0400, pluknet wrote: > 2009/6/18 John Baldwin : > > On Wednesday 17 June 2009 2:29:25 pm Alexander Best wrote: > >> hi there, > >> > >> although i'm running a very recent current which has "ACPICA 20090521", estX > >> still isn't attaching properly on my machine: > >> > >> est0: on cpu0 > >> est: CPU supports Enhanced Speedstep, but is not recognized. > >> est: cpu_vendor GenuineIntel, msr 925092506000925 > >> device_attach: est0 attach returned 6 > >> est1: on cpu1 > >> est: CPU supports Enhanced Speedstep, but is not recognized. > >> est: cpu_vendor GenuineIntel, msr 925092506000925 > >> device_attach: est1 attach returned 6 > > > > That just means ACPI isn't providing info about the speed steppings your CPU > > provides. True. Probably update to the latest BIOS will help, but may be it won't: some vendors aren't putting the stuff to the ACPI tables. > > It is odd that cpu0 has freq_levels but cpu1 does not. > > While here let me also please share my own acpi/est data. > I hope it would not bother you too much. > est attaches to all cpu:s, but again freq_levels is only on cpu0. It is the proper behaviour of the ACPI's cpufreq driver: frequency levels for all CPUs are meant to be the same. See sys/kern/kern_cpu.c (cpufreq_attach(), line 172 or something like this), ----- /* * Only initialize one set of sysctls for all CPUs. In the future, * if multiple CPUs can have different settings, we can move these * sysctls to be under every CPU instead of just the first one. */ numdevs = devclass_get_count(cpufreq_dc); if (numdevs > 1) return (0); CF_DEBUG("initializing one-time data for %s\n", device_get_nameunit(dev)); SYSCTL_ADD_PROC(&sc->sysctl_ctx, SYSCTL_CHILDREN(device_get_sysctl_tree(parent)), OID_AUTO, "freq", CTLTYPE_INT | CTLFLAG_RW, sc, 0, cpufreq_curr_sysctl, "I", "Current CPU frequency"); SYSCTL_ADD_PROC(&sc->sysctl_ctx, SYSCTL_CHILDREN(device_get_sysctl_tree(parent)), OID_AUTO, "freq_levels", CTLTYPE_STRING | CTLFLAG_RD, sc, 0, cpufreq_levels_sysctl, "A", "CPU frequency levels"); ----- -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # From owner-freebsd-current@FreeBSD.ORG Fri Jun 19 09:43:36 2009 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 A22A01065672; Fri, 19 Jun 2009 09:43:36 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: from mail-px0-f203.google.com (mail-px0-f203.google.com [209.85.216.203]) by mx1.freebsd.org (Postfix) with ESMTP id 7C1158FC22; Fri, 19 Jun 2009 09:43:36 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: by mail-px0-f203.google.com with SMTP id 41so1059597pxi.3 for ; Fri, 19 Jun 2009 02:43:36 -0700 (PDT) Received: by 10.114.157.11 with SMTP id f11mr3715401wae.75.1245402761788; Fri, 19 Jun 2009 02:12:41 -0700 (PDT) Received: from ?10.0.1.198? (udp016664uds.hawaiiantel.net [72.235.41.117]) by mx.google.com with ESMTPS id v32sm5403380wah.13.2009.06.19.02.12.39 (version=SSLv3 cipher=RC4-MD5); Fri, 19 Jun 2009 02:12:40 -0700 (PDT) Date: Thu, 18 Jun 2009 23:12:45 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: net@freebsd.org, current@freebsd.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: Subject: mbuf layout optimizations 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, 19 Jun 2009 09:43:37 -0000 http://people.freebsd.org/~jeff/mbuf2.diff Hello, This is a call for testers and feedback on my mbuf layout improvements. I'm trying to decide whether I will push to have these included in 8.0. After reducing the scope slightly from my last patch, I have not encountered any problems. Kip Macy has also been using it for the past few weeks without issue. You should not expect any functional changes from this patch. The goal is mostly to pave the way fors more sensible mbuf handling in the future, although it does offer a few performance benefits. The only issue is that cxgb support requires another set of patches from Kip. If anyone needs those I will prod him to reply with that diff. Thanks, Jeff From owner-freebsd-current@FreeBSD.ORG Fri Jun 19 10:26:42 2009 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 657AF1065670 for ; Fri, 19 Jun 2009 10:26:42 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id A37308FC12 for ; Fri, 19 Jun 2009 10:26:41 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id NAA03518; Fri, 19 Jun 2009 13:26:39 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4A3B67DE.6080200@icyb.net.ua> Date: Fri, 19 Jun 2009 13:26:38 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.21 (X11/20090406) MIME-Version: 1.0 To: Thomas Backman References: <949B5884-5303-4EFF-AC7D-293640FFA012@exscape.org> <0C235698-3ED2-4AE9-A7D1-5DC56D8324A4@exscape.org> <200905212129.47892.mel.flynn+fbsd.current@mailing.thruhere.net> <44F486FA-E798-448D-BE31-F7A51EF1F612@exscape.org> <60173AF0-7E54-4BDD-8927-0DADA9DAD1B4@exscape.org> <20090522200306.GE2630@atarininja.org> <20090617225849.GB28509@atarininja.org> <4A3A1D27.4010802@icyb.net.ua> <4A3A2B88.60009@icyb.net.ua> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD current Subject: Re: DTrace panic while probing syscall::open (and possibly many others) 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, 19 Jun 2009 10:26:42 -0000 on 18/06/2009 16:55 Thomas Backman said the following: > No. :/ > The kernel.debug was gone, and so I deleted the core as well, since I > had changed the kernel code since the recompile (that *would* break > debugging it, yes? I can't just recompile a new, changed one hoping it > will still debug properly, right?). Maybe at a later time. Ok. In general I have a feeling that there might be some bug in management of "scratch buffer" that is used to hold temporary results (like target of copyinstr). -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Fri Jun 19 11:10:06 2009 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 371BB106564A; Fri, 19 Jun 2009 11:10:06 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 8B8758FC1F; Fri, 19 Jun 2009 11:10:04 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA04190; Fri, 19 Jun 2009 14:10:02 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4A3B720A.8040601@icyb.net.ua> Date: Fri, 19 Jun 2009 14:10:02 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.21 (X11/20090406) MIME-Version: 1.0 To: John Baldwin References: <200906180909.33511.jhb@freebsd.org> In-Reply-To: <200906180909.33511.jhb@freebsd.org> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Alexander Best , freebsd-current@freebsd.org, freebsd-acpi@freebsd.org Subject: Re: estX still not attaching properly 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, 19 Jun 2009 11:10:06 -0000 on 18/06/2009 16:09 John Baldwin said the following: > On Wednesday 17 June 2009 2:29:25 pm Alexander Best wrote: >> hi there, >> >> although i'm running a very recent current which has "ACPICA 20090521", estX >> still isn't attaching properly on my machine: >> >> est0: on cpu0 >> est: CPU supports Enhanced Speedstep, but is not recognized. >> est: cpu_vendor GenuineIntel, msr 925092506000925 >> device_attach: est0 attach returned 6 >> est1: on cpu1 >> est: CPU supports Enhanced Speedstep, but is not recognized. >> est: cpu_vendor GenuineIntel, msr 925092506000925 >> device_attach: est1 attach returned 6 > > That just means ACPI isn't providing info about the speed steppings your CPU > provides. It is odd that cpu0 has freq_levels but cpu1 does not. > This is most probably not related to the issue at hand. But I have some (probably unfounded) suspicions about OS features that we advertise via _PDC. Also, I find the following interesting in acpi_cpu.c. First we call _PDC, then we call _OSC and then there is the following comment between the two calls: /* * On some systems we need to evaluate _OSC so that the ASL * loads the _PSS and/or _PDC methods at runtime. ... -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Fri Jun 19 13:56:00 2009 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 E01751065674 for ; Fri, 19 Jun 2009 13:56:00 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from ch-smtp01.sth.basefarm.net (ch-smtp01.sth.basefarm.net [80.76.149.212]) by mx1.freebsd.org (Postfix) with ESMTP id 935BF8FC0C for ; Fri, 19 Jun 2009 13:56:00 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from c83-253-252-234.bredband.comhem.se ([83.253.252.234]:42731 helo=mx.exscape.org) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.69) (envelope-from ) id 1MHeZG-00063N-5T; Fri, 19 Jun 2009 15:55:48 +0200 Received: from [192.168.1.5] (macbookpro [192.168.1.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx.exscape.org (Postfix) with ESMTPSA id 0BF536AC05; Fri, 19 Jun 2009 15:55:43 +0200 (CEST) Message-Id: <127EFC29-D6D4-497E-B623-594E6E485EA9@exscape.org> From: Thomas Backman To: Andriy Gapon In-Reply-To: <4A3A2B88.60009@icyb.net.ua> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 19 Jun 2009 15:55:40 +0200 References: <949B5884-5303-4EFF-AC7D-293640FFA012@exscape.org> <0C235698-3ED2-4AE9-A7D1-5DC56D8324A4@exscape.org> <200905212129.47892.mel.flynn+fbsd.current@mailing.thruhere.net> <44F486FA-E798-448D-BE31-F7A51EF1F612@exscape.org> <60173AF0-7E54-4BDD-8927-0DADA9DAD1B4@exscape.org> <20090522200306.GE2630@atarininja.org> <20090617225849.GB28509@atarininja.org> <4A3A1D27.4010802@icyb.net.ua> <4A3A2B88.60009@icyb.net.ua> X-Mailer: Apple Mail (2.935.3) X-Originating-IP: 83.253.252.234 X-Scan-Result: No virus found in message 1MHeZG-00063N-5T. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1MHeZG-00063N-5T fa59e8721f6d0e1799f1b2cd4beff3bf Cc: FreeBSD current Subject: Re: DTrace panic while probing syscall::open (and possibly many others) 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, 19 Jun 2009 13:56:01 -0000 On Jun 18, 2009, at 01:56 PM, Andriy Gapon wrote: > on 18/06/2009 14:42 Thomas Backman said the following: >> >> So, kaddr is inside the "kernel map", but not KERNBASE. What this >> means, >> I have no clue whatsoever. (I'm not a kernel developer and I don't >> know >> too much about (virtual) memory either!) > > Me neither :( > BTW, could you please go to fr 18 and examine 'code', 'callp' and > 'args' local > variables? Like this? (kgdb) fr 18 #18 0xffffffff80887bbd in syscall (frame=0xffffff803e761c90) at /usr/ src/sys/amd64/amd64/trap.c:997 997 (*systrace_probe_func)(callp- >sy_return, code, callp, ... 998 args); (kgdb) p/x code $4 = 0x5 (kgdb) p/x callp $5 = 0x9b42 (kgdb) p/x args $6 = {0x80053160d, 0x0, 0x2f, 0x2, 0x80, 0x0, 0xffffff803e761c80, 0xffffffff80570a52} Regards, Thomas From owner-freebsd-current@FreeBSD.ORG Fri Jun 19 14:59:55 2009 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 74BE8106564A for ; Fri, 19 Jun 2009 14:59:55 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from web63906.mail.re1.yahoo.com (web63906.mail.re1.yahoo.com [69.147.97.121]) by mx1.freebsd.org (Postfix) with SMTP id 1F2038FC0C for ; Fri, 19 Jun 2009 14:59:54 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: (qmail 84540 invoked by uid 60001); 19 Jun 2009 14:59:54 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1245423594; bh=CxOF3vcW3kxmgYBIbavgSS9b0MHsYF4Zr1RlCUlYWZM=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=T6+UiEUzZdHaRvX8p6HiFnbzsFQAS9rnq0xxpHbjLy4TeeIdNVDFARzb8tPOLLNY+cpHmDQFlZOcvA+L7BuB/ogybVbQFvmZT7fz5gzbdah7ZsbjWIj+0vros2vBISysfUq4IjNMQZKoEzMCPxTjTzDID7SwJRkPGYvmiXl+hns= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=P9pdzkuGEPeIs+ZvUi1YW67GHxvvZI5Z+ORSeXlhu3WBx5zTwZchd9mfKCTTEtG3XJTen78foMHBsmiij5p3DR3SNhx7c/l2R4m/tSk7LKH9aH3MLMdXySQNMcmCpNo8YR87yE/5PDD84rvVXPKGs59XvM/KerhMtvo6r+1whts=; Message-ID: <603332.84337.qm@web63906.mail.re1.yahoo.com> X-YMail-OSG: E5Ef2Z0VM1kotkb2_aL3Vi5ji_aiH3RppHd9Cw6HcMRlA6gdZuINN6wia6af_Euk6.ZK4kM6KyF6FdT.uXcKH9ldMoMzrinygJixfRmsWYKJ6P6c4Zlp8U5_Wa1._SmUfyE2D3b_eAaEp7vcGYZxLrTIqAfOmHO5vI5Oirkq6Y3HMGVIR8DzRqG5f9qXwICIx6HPrhhUKthiBA_WQTlYk0rp3hlGsWRl_V4paFcZIihkqIYCPn7hxUxdLD8r9_sl6biA_4qwgczy4Htt2BQqTOyP30PHTmcgQmVg.W59CnWSFVMx2kwFWGU- Received: from [66.176.162.245] by web63906.mail.re1.yahoo.com via HTTP; Fri, 19 Jun 2009 07:59:54 PDT X-Mailer: YahooMailClassic/5.4.17 YahooMailWebService/0.7.289.15 Date: Fri, 19 Jun 2009 07:59:54 -0700 (PDT) From: Barney Cordoba To: net@freebsd.org, current@freebsd.org, Jeff Roberson MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: mbuf layout optimizations 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, 19 Jun 2009 14:59:55 -0000 =0A=0A--- On Fri, 6/19/09, Jeff Roberson wrote:= =0A=0A> From: Jeff Roberson =0A> Subject: mbuf lay= out optimizations=0A> To: net@freebsd.org, current@freebsd.org=0A> Date: Fr= iday, June 19, 2009, 5:12 AM=0A> http://people.freebsd.org/~jeff/mbuf2.diff= =0A> =0A> Hello,=0A> =0A> This is a call for testers and feedback on my mbu= f layout=0A> improvements. I'm trying to decide whether I will push to=0A> = have these included in 8.0. After reducing the scope=0A> slightly from my l= ast patch, I have not encountered any=0A> problems.=A0 Kip Macy has also be= en using it for the past=0A> few weeks without issue.=0A> =0A> You should n= ot expect any functional changes from this=0A> patch.=A0 The goal is mostly= to pave the way fors more=0A> sensible mbuf handling in the future, althou= gh it does offer=0A> a few performance benefits.=0A> =0A> The only issue is= that cxgb support requires another set of=0A> patches from Kip.=A0 If anyo= ne needs those I will prod=0A> him to reply with that diff.=0A> =0A> Thanks= ,=0A> Jeff=0A=0AI thought that the purpose of m_tags was to keep individual= applications from having to "patch" mbufs. Has that idea proven to be too= =0Aperformance-challenged?=0A=0ABarney=0A=0A=0A From owner-freebsd-current@FreeBSD.ORG Fri Jun 19 16:39:58 2009 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 E9254106566C; Fri, 19 Jun 2009 16:39:58 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id EE5878FC0A; Fri, 19 Jun 2009 16:39:57 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id TAA07936; Fri, 19 Jun 2009 19:39:54 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4A3BBF5A.6060702@icyb.net.ua> Date: Fri, 19 Jun 2009 19:39:54 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.21 (X11/20090406) MIME-Version: 1.0 To: Thomas Backman References: <949B5884-5303-4EFF-AC7D-293640FFA012@exscape.org> <0C235698-3ED2-4AE9-A7D1-5DC56D8324A4@exscape.org> <200905212129.47892.mel.flynn+fbsd.current@mailing.thruhere.net> <44F486FA-E798-448D-BE31-F7A51EF1F612@exscape.org> <60173AF0-7E54-4BDD-8927-0DADA9DAD1B4@exscape.org> <20090522200306.GE2630@atarininja.org> <20090617225849.GB28509@atarininja.org> <4A3A1D27.4010802@icyb.net.ua> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Alan Cox , freebsd-current@FreeBSD.org, John Birrell , John Baldwin Subject: Re: DTrace panic while probing syscall::open (and possibly many others) 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, 19 Jun 2009 16:39:59 -0000 on 18/06/2009 14:42 Thomas Backman said the following: > > On Jun 18, 2009, at 12:55 PM, Andriy Gapon wrote: > >> on 18/06/2009 12:43 Thomas Backman said the following: >>> >>> at dtrace_isa.c:527 >>> #14 0xffffffff816b31fc in dtrace_copyinstr (uaddr=34365163021, >>> kaddr=18446743524025463312, size=256, flags=0xffffffff8146e0c0) >>> at dtrace_isa.c:558 >> >> kaddr=18446743524025463312 == FFFFFF8004467210 >> I think kernelbase on amd64 is 0xFFFFFFFF80000000. >> FFFFFF8004467210 kaddr >> is smaller than >> FFFFFFFF80000000 kernelbase >> >> The numbers do look suspiciously similar, so I am not sure if you are >> seeing a >> race or a real bug somewhere. >> -- >> Andriy Gapon > Hmmm... > Looking around a bit for these numbers, I found, in > /sys/amd64/include/vmparam.h: > > /* > * Virtual addresses of things. Derived from the page directory and > * page table indexes from pmap.h for precision. > * > * 0x0000000000000000 - 0x00007fffffffffff user map > * 0x0000800000000000 - 0xffff7fffffffffff does not exist (hole) > * 0xffff800000000000 - 0xffff804020100fff recursive page table (512GB > slot) > * 0xffff804020101000 - 0xfffffeffffffffff unused > * 0xffffff0000000000 - 0xffffff7fffffffff 512GB direct map mappings > * 0xffffff8000000000 - 0xffffffffffffffff 512GB kernel map > * > * Within the kernel map: > * > * 0xffffffff80000000 KERNBASE > */ > > So, kaddr is inside the "kernel map", but not KERNBASE. What this means, > I have no clue whatsoever. (I'm not a kernel developer and I don't know > too much about (virtual) memory either!) Thomas, I think that you were correct that one needs to be somewhat of a VM expert here. It seems that amd64 is the only[?] platform where KERNBASE != VM_MIN_KERNEL_ADDRESS (0xffffffff80000000 and 0xffffff8000000000 correspondingly). That makes the assert in sys/cddl/dev/dtrace/amd64/dtrace_isa.c bogus in my opinion: static int dtrace_copycheck(uintptr_t uaddr, uintptr_t kaddr, size_t size) { ASSERT(kaddr >= kernelbase && kaddr + size >= kaddr); If the purpose of the assert is to ensure that [kaddr:kaddr+size) is within kernel memory, then it should use VM_MIN_KERNEL_ADDRESS instead of KERNBASE. Or maybe even use something like the macro in sys/amd64/include/stack.h: #define INKERNEL(va) (((va) >= DMAP_MIN_ADDRESS && (va) < DMAP_MAX_ADDRESS) \ || ((va) >= VM_MIN_KERNEL_ADDRESS && (va) < VM_MAX_KERNEL_ADDRESS)) The above is just my understanding, not a fact, so I am CC-ing people that are really knowledgeable of our VM and the porter/author of our DTrace code too. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Fri Jun 19 17:23:34 2009 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 5B6351065673; Fri, 19 Jun 2009 17:23:34 +0000 (UTC) (envelope-from alc@cs.rice.edu) Received: from mail.cs.rice.edu (mail.cs.rice.edu [128.42.1.31]) by mx1.freebsd.org (Postfix) with ESMTP id 1EF1A8FC15; Fri, 19 Jun 2009 17:23:34 +0000 (UTC) (envelope-from alc@cs.rice.edu) Received: from mail.cs.rice.edu (localhost.localdomain [127.0.0.1]) by mail.cs.rice.edu (Postfix) with ESMTP id 181432C2A81; Fri, 19 Jun 2009 12:02:02 -0500 (CDT) X-Virus-Scanned: by amavis-2.4.0 at mail.cs.rice.edu Received: from mail.cs.rice.edu ([127.0.0.1]) by mail.cs.rice.edu (mail.cs.rice.edu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id NhDYNKWf7e3b; Fri, 19 Jun 2009 12:01:54 -0500 (CDT) Received: from adsl-216-63-78-18.dsl.hstntx.swbell.net (adsl-216-63-78-18.dsl.hstntx.swbell.net [216.63.78.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.cs.rice.edu (Postfix) with ESMTP id 2564A2C2A7E; Fri, 19 Jun 2009 12:01:54 -0500 (CDT) Message-ID: <4A3BC481.1010600@cs.rice.edu> Date: Fri, 19 Jun 2009 12:01:53 -0500 From: Alan Cox User-Agent: Thunderbird 2.0.0.21 (X11/20090404) MIME-Version: 1.0 To: Andriy Gapon References: <949B5884-5303-4EFF-AC7D-293640FFA012@exscape.org> <0C235698-3ED2-4AE9-A7D1-5DC56D8324A4@exscape.org> <200905212129.47892.mel.flynn+fbsd.current@mailing.thruhere.net> <44F486FA-E798-448D-BE31-F7A51EF1F612@exscape.org> <60173AF0-7E54-4BDD-8927-0DADA9DAD1B4@exscape.org> <20090522200306.GE2630@atarininja.org> <20090617225849.GB28509@atarininja.org> <4A3A1D27.4010802@icyb.net.ua> <4A3BBF5A.6060702@icyb.net.ua> In-Reply-To: <4A3BBF5A.6060702@icyb.net.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Alan Cox , John Birrell , freebsd-current@freebsd.org, Thomas Backman Subject: Re: DTrace panic while probing syscall::open (and possibly many others) 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, 19 Jun 2009 17:23:34 -0000 Andriy Gapon wrote: > on 18/06/2009 14:42 Thomas Backman said the following: > >> On Jun 18, 2009, at 12:55 PM, Andriy Gapon wrote: >> >> >>> on 18/06/2009 12:43 Thomas Backman said the following: >>> >>>> at dtrace_isa.c:527 >>>> #14 0xffffffff816b31fc in dtrace_copyinstr (uaddr=34365163021, >>>> kaddr=18446743524025463312, size=256, flags=0xffffffff8146e0c0) >>>> at dtrace_isa.c:558 >>>> >>> kaddr=18446743524025463312 == FFFFFF8004467210 >>> I think kernelbase on amd64 is 0xFFFFFFFF80000000. >>> FFFFFF8004467210 kaddr >>> is smaller than >>> FFFFFFFF80000000 kernelbase >>> >>> The numbers do look suspiciously similar, so I am not sure if you are >>> seeing a >>> race or a real bug somewhere. >>> -- >>> Andriy Gapon >>> >> Hmmm... >> Looking around a bit for these numbers, I found, in >> /sys/amd64/include/vmparam.h: >> >> /* >> * Virtual addresses of things. Derived from the page directory and >> * page table indexes from pmap.h for precision. >> * >> * 0x0000000000000000 - 0x00007fffffffffff user map >> * 0x0000800000000000 - 0xffff7fffffffffff does not exist (hole) >> * 0xffff800000000000 - 0xffff804020100fff recursive page table (512GB >> slot) >> * 0xffff804020101000 - 0xfffffeffffffffff unused >> * 0xffffff0000000000 - 0xffffff7fffffffff 512GB direct map mappings >> * 0xffffff8000000000 - 0xffffffffffffffff 512GB kernel map >> * >> * Within the kernel map: >> * >> * 0xffffffff80000000 KERNBASE >> */ >> >> So, kaddr is inside the "kernel map", but not KERNBASE. What this means, >> I have no clue whatsoever. (I'm not a kernel developer and I don't know >> too much about (virtual) memory either!) >> > > Thomas, > > I think that you were correct that one needs to be somewhat of a VM expert here. > It seems that amd64 is the only[?] platform where KERNBASE != > VM_MIN_KERNEL_ADDRESS (0xffffffff80000000 and 0xffffff8000000000 correspondingly). > That makes the assert in sys/cddl/dev/dtrace/amd64/dtrace_isa.c bogus in my opinion: > static int > dtrace_copycheck(uintptr_t uaddr, uintptr_t kaddr, size_t size) > { > ASSERT(kaddr >= kernelbase && kaddr + size >= kaddr); > > If the purpose of the assert is to ensure that [kaddr:kaddr+size) is within kernel > memory, then it should use VM_MIN_KERNEL_ADDRESS instead of KERNBASE. Or maybe > even use something like the macro in sys/amd64/include/stack.h: > #define INKERNEL(va) (((va) >= DMAP_MIN_ADDRESS && (va) < DMAP_MAX_ADDRESS) \ > || ((va) >= VM_MIN_KERNEL_ADDRESS && (va) < VM_MAX_KERNEL_ADDRESS)) > > Yes. Your analysis is correct. Alan From owner-freebsd-current@FreeBSD.ORG Fri Jun 19 17:33:09 2009 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 3DAC01065672; Fri, 19 Jun 2009 17:33:09 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from ch-smtp01.sth.basefarm.net (ch-smtp01.sth.basefarm.net [80.76.149.212]) by mx1.freebsd.org (Postfix) with ESMTP id B7B1B8FC0C; Fri, 19 Jun 2009 17:33:08 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from c83-253-252-234.bredband.comhem.se ([83.253.252.234]:49924 helo=mx.exscape.org) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.69) (envelope-from ) id 1MHhxM-00028U-42; Fri, 19 Jun 2009 19:32:54 +0200 Received: from [192.168.1.5] (macbookpro [192.168.1.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx.exscape.org (Postfix) with ESMTPSA id 2F8E06AC12; Fri, 19 Jun 2009 19:32:43 +0200 (CEST) Message-Id: From: Thomas Backman To: Alan Cox In-Reply-To: <4A3BC481.1010600@cs.rice.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 19 Jun 2009 19:32:40 +0200 References: <949B5884-5303-4EFF-AC7D-293640FFA012@exscape.org> <0C235698-3ED2-4AE9-A7D1-5DC56D8324A4@exscape.org> <200905212129.47892.mel.flynn+fbsd.current@mailing.thruhere.net> <44F486FA-E798-448D-BE31-F7A51EF1F612@exscape.org> <60173AF0-7E54-4BDD-8927-0DADA9DAD1B4@exscape.org> <20090522200306.GE2630@atarininja.org> <20090617225849.GB28509@atarininja.org> <4A3A1D27.4010802@icyb.net.ua> <4A3BBF5A.6060702@icyb.net.ua> <4A3BC481.1010600@cs.rice.edu> X-Mailer: Apple Mail (2.935.3) X-Originating-IP: 83.253.252.234 X-Scan-Result: No virus found in message 1MHhxM-00028U-42. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1MHhxM-00028U-42 c30f1dab438dfba62ec65e2893c2ca09 Cc: Alan Cox , John Birrell , freebsd-current@freebsd.org, Andriy Gapon Subject: Re: DTrace panic while probing syscall::open (and possibly many others) 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, 19 Jun 2009 17:33:09 -0000 On Jun 19, 2009, at 07:01 PM, Alan Cox wrote: > Andriy Gapon wrote: >> on 18/06/2009 14:42 Thomas Backman said the following: >> >>> On Jun 18, 2009, at 12:55 PM, Andriy Gapon wrote: >>> >>> >>>> on 18/06/2009 12:43 Thomas Backman said the following: >>>> >>>>> at dtrace_isa.c:527 >>>>> #14 0xffffffff816b31fc in dtrace_copyinstr (uaddr=34365163021, >>>>> kaddr=18446743524025463312, size=256, flags=0xffffffff8146e0c0) >>>>> at dtrace_isa.c:558 >>>>> >>>> kaddr=18446743524025463312 == FFFFFF8004467210 >>>> I think kernelbase on amd64 is 0xFFFFFFFF80000000. >>>> FFFFFF8004467210 kaddr >>>> is smaller than >>>> FFFFFFFF80000000 kernelbase >>>> >>>> The numbers do look suspiciously similar, so I am not sure if you >>>> are >>>> seeing a >>>> race or a real bug somewhere. >>>> -- >>>> Andriy Gapon >>>> >>> Hmmm... >>> Looking around a bit for these numbers, I found, in >>> /sys/amd64/include/vmparam.h: >>> >>> /* >>> * Virtual addresses of things. Derived from the page directory and >>> * page table indexes from pmap.h for precision. >>> * >>> * 0x0000000000000000 - 0x00007fffffffffff user map >>> * 0x0000800000000000 - 0xffff7fffffffffff does not exist (hole) >>> * 0xffff800000000000 - 0xffff804020100fff recursive page table >>> (512GB >>> slot) >>> * 0xffff804020101000 - 0xfffffeffffffffff unused >>> * 0xffffff0000000000 - 0xffffff7fffffffff 512GB direct map >>> mappings >>> * 0xffffff8000000000 - 0xffffffffffffffff 512GB kernel map >>> * >>> * Within the kernel map: >>> * >>> * 0xffffffff80000000 KERNBASE >>> */ >>> >>> So, kaddr is inside the "kernel map", but not KERNBASE. What this >>> means, >>> I have no clue whatsoever. (I'm not a kernel developer and I don't >>> know >>> too much about (virtual) memory either!) >>> >> >> Thomas, >> >> I think that you were correct that one needs to be somewhat of a VM >> expert here. >> It seems that amd64 is the only[?] platform where KERNBASE != >> VM_MIN_KERNEL_ADDRESS (0xffffffff80000000 and 0xffffff8000000000 >> correspondingly). >> That makes the assert in sys/cddl/dev/dtrace/amd64/dtrace_isa.c >> bogus in my opinion: >> static int >> dtrace_copycheck(uintptr_t uaddr, uintptr_t kaddr, size_t size) >> { >> ASSERT(kaddr >= kernelbase && kaddr + size >= kaddr); >> >> If the purpose of the assert is to ensure that [kaddr:kaddr+size) >> is within kernel >> memory, then it should use VM_MIN_KERNEL_ADDRESS instead of >> KERNBASE. Or maybe >> even use something like the macro in sys/amd64/include/stack.h: >> #define INKERNEL(va) (((va) >= DMAP_MIN_ADDRESS && (va) < >> DMAP_MAX_ADDRESS) \ >> || ((va) >= VM_MIN_KERNEL_ADDRESS && (va) < >> VM_MAX_KERNEL_ADDRESS)) >> >> > > Yes. Your analysis is correct. > > Alan Very interesting. I replaced the ASSERT line temporarily: --- ../src_r194478-UNTOUCHED/sys/cddl/dev/dtrace/amd64/ dtrace_isa.c 2009-06-19 13:10:05.661079736 +0200 +++ sys/cddl/dev/dtrace/amd64/dtrace_isa.c 2009-06-19 19:24:42.362125129 +0200 @@ -524,7 +524,7 @@ static int dtrace_copycheck(uintptr_t uaddr, uintptr_t kaddr, size_t size) { - ASSERT(kaddr >= kernelbase && kaddr + size >= kaddr); + ASSERT(kaddr >= 0xffffff8000000000 && kaddr + size >= kaddr); if (uaddr + size >= kernelbase || uaddr + size < uaddr) { DTRACE_CPUFLAG_SET(CPU_DTRACE_BADADDR); ... and it works! I obviously haven't tried it for extended periods or anything, but at least it's working so far. Should the ASSERT simply use this (as a #define somewhere) or the INKERNEL macro, though? Regards, Thomas From owner-freebsd-current@FreeBSD.ORG Fri Jun 19 17:41:52 2009 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 862AD106566C; Fri, 19 Jun 2009 17:41:52 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from ch-smtp01.sth.basefarm.net (ch-smtp01.sth.basefarm.net [80.76.149.212]) by mx1.freebsd.org (Postfix) with ESMTP id 0BB2D8FC0C; Fri, 19 Jun 2009 17:41:52 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from c83-253-252-234.bredband.comhem.se ([83.253.252.234]:42331 helo=mx.exscape.org) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.69) (envelope-from ) id 1MHi5l-0003tE-5b; Fri, 19 Jun 2009 19:41:35 +0200 Received: from [192.168.1.5] (macbookpro [192.168.1.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx.exscape.org (Postfix) with ESMTPSA id 3CB2B6AD67; Fri, 19 Jun 2009 19:41:32 +0200 (CEST) Message-Id: From: Thomas Backman To: FreeBSD current 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 v935.3) Date: Fri, 19 Jun 2009 19:41:29 +0200 References: <949B5884-5303-4EFF-AC7D-293640FFA012@exscape.org> <0C235698-3ED2-4AE9-A7D1-5DC56D8324A4@exscape.org> <200905212129.47892.mel.flynn+fbsd.current@mailing.thruhere.net> <44F486FA-E798-448D-BE31-F7A51EF1F612@exscape.org> <60173AF0-7E54-4BDD-8927-0DADA9DAD1B4@exscape.org> <20090522200306.GE2630@atarininja.org> <20090617225849.GB28509@atarininja.org> <4A3A1D27.4010802@icyb.net.ua> <4A3BBF5A.6060702@icyb.net.ua> <4A3BC481.1010600@cs.rice.edu> X-Mailer: Apple Mail (2.935.3) X-Originating-IP: 83.253.252.234 X-Scan-Result: No virus found in message 1MHi5l-0003tE-5b. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1MHi5l-0003tE-5b 1df895e374f1b4af289ce37002d95280 Cc: Alan Cox , John Birrell , Alan Cox , Andriy Gapon Subject: Re: DTrace panic while probing syscall::open (and possibly many others) 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, 19 Jun 2009 17:41:52 -0000 On Jun 19, 2009, at 07:32 PM, Thomas Backman wrote: > > On Jun 19, 2009, at 07:01 PM, Alan Cox wrote: > >> Andriy Gapon wrote: >>> on 18/06/2009 14:42 Thomas Backman said the following: >>> >>>> On Jun 18, 2009, at 12:55 PM, Andriy Gapon wrote: >>>> >>>> >>>>> on 18/06/2009 12:43 Thomas Backman said the following: >>>>> >>>>>> at dtrace_isa.c:527 >>>>>> #14 0xffffffff816b31fc in dtrace_copyinstr (uaddr=34365163021, >>>>>> kaddr=18446743524025463312, size=256, flags=0xffffffff8146e0c0) >>>>>> at dtrace_isa.c:558 >>>>>> >>>>> kaddr=18446743524025463312 == FFFFFF8004467210 >>>>> I think kernelbase on amd64 is 0xFFFFFFFF80000000. >>>>> FFFFFF8004467210 kaddr >>>>> is smaller than >>>>> FFFFFFFF80000000 kernelbase >>>>> >>>>> The numbers do look suspiciously similar, so I am not sure if >>>>> you are >>>>> seeing a >>>>> race or a real bug somewhere. >>>>> -- >>>>> Andriy Gapon >>>>> >>>> Hmmm... >>>> Looking around a bit for these numbers, I found, in >>>> /sys/amd64/include/vmparam.h: >>>> >>>> /* >>>> * Virtual addresses of things. Derived from the page directory and >>>> * page table indexes from pmap.h for precision. >>>> * >>>> * 0x0000000000000000 - 0x00007fffffffffff user map >>>> * 0x0000800000000000 - 0xffff7fffffffffff does not exist (hole) >>>> * 0xffff800000000000 - 0xffff804020100fff recursive page table >>>> (512GB >>>> slot) >>>> * 0xffff804020101000 - 0xfffffeffffffffff unused >>>> * 0xffffff0000000000 - 0xffffff7fffffffff 512GB direct map >>>> mappings >>>> * 0xffffff8000000000 - 0xffffffffffffffff 512GB kernel map >>>> * >>>> * Within the kernel map: >>>> * >>>> * 0xffffffff80000000 KERNBASE >>>> */ >>>> >>>> So, kaddr is inside the "kernel map", but not KERNBASE. What this >>>> means, >>>> I have no clue whatsoever. (I'm not a kernel developer and I >>>> don't know >>>> too much about (virtual) memory either!) >>>> >>> >>> Thomas, >>> >>> I think that you were correct that one needs to be somewhat of a >>> VM expert here. >>> It seems that amd64 is the only[?] platform where KERNBASE != >>> VM_MIN_KERNEL_ADDRESS (0xffffffff80000000 and 0xffffff8000000000 >>> correspondingly). >>> That makes the assert in sys/cddl/dev/dtrace/amd64/dtrace_isa.c >>> bogus in my opinion: >>> static int >>> dtrace_copycheck(uintptr_t uaddr, uintptr_t kaddr, size_t size) >>> { >>> ASSERT(kaddr >= kernelbase && kaddr + size >= kaddr); >>> >>> If the purpose of the assert is to ensure that [kaddr:kaddr+size) >>> is within kernel >>> memory, then it should use VM_MIN_KERNEL_ADDRESS instead of >>> KERNBASE. Or maybe >>> even use something like the macro in sys/amd64/include/stack.h: >>> #define INKERNEL(va) (((va) >= DMAP_MIN_ADDRESS && (va) < >>> DMAP_MAX_ADDRESS) \ >>> || ((va) >= VM_MIN_KERNEL_ADDRESS && (va) < >>> VM_MAX_KERNEL_ADDRESS)) >>> >>> >> >> Yes. Your analysis is correct. >> >> Alan > Very interesting. > I replaced the ASSERT line temporarily: > > --- ../src_r194478-UNTOUCHED/sys/cddl/dev/dtrace/amd64/ > dtrace_isa.c 2009-06-19 13:10:05.661079736 +0200 > +++ sys/cddl/dev/dtrace/amd64/dtrace_isa.c 2009-06-19 > 19:24:42.362125129 +0200 > @@ -524,7 +524,7 @@ > static int > dtrace_copycheck(uintptr_t uaddr, uintptr_t kaddr, size_t size) > { > - ASSERT(kaddr >= kernelbase && kaddr + size >= kaddr); > + ASSERT(kaddr >= 0xffffff8000000000 && kaddr + size >= kaddr); > > if (uaddr + size >= kernelbase || uaddr + size < uaddr) { > DTRACE_CPUFLAG_SET(CPU_DTRACE_BADADDR); > > ... and it works! I obviously haven't tried it for extended periods > or anything, but at least it's working so far. > Should the ASSERT simply use this (as a #define somewhere) or the > INKERNEL macro, though? BTW... Should "kernelbase" in the line following the ASSERT also be replaced, or not? As far as I can understand (not too far in these contexts ;) it (should) check/s to see whether the userspace data, to be copied, is inside the kernel *map*(?)... which at the moment, I guess it doesn't. Correct? Regards, Thomas From owner-freebsd-current@FreeBSD.ORG Fri Jun 19 17:43:15 2009 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 180BF106567B; Fri, 19 Jun 2009 17:43:15 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.181]) by mx1.freebsd.org (Postfix) with ESMTP id E05488FC1D; Fri, 19 Jun 2009 17:43:14 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: by wa-out-1112.google.com with SMTP id m38so538894waf.27 for ; Fri, 19 Jun 2009 10:43:14 -0700 (PDT) Received: by 10.114.122.9 with SMTP id u9mr4332110wac.206.1245433394547; Fri, 19 Jun 2009 10:43:14 -0700 (PDT) Received: from ?10.0.1.198? (udp016664uds.hawaiiantel.net [72.235.41.117]) by mx.google.com with ESMTPS id j15sm6132110waf.16.2009.06.19.10.43.12 (version=SSLv3 cipher=RC4-MD5); Fri, 19 Jun 2009 10:43:13 -0700 (PDT) Date: Fri, 19 Jun 2009 07:43:19 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: Barney Cordoba In-Reply-To: <603332.84337.qm@web63906.mail.re1.yahoo.com> Message-ID: References: <603332.84337.qm@web63906.mail.re1.yahoo.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="2547152148-1022206537-1245433402=:1025" Cc: current@freebsd.org, net@freebsd.org Subject: Re: mbuf layout optimizations 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, 19 Jun 2009 17:43:15 -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. --2547152148-1022206537-1245433402=:1025 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8BIT On Fri, 19 Jun 2009, Barney Cordoba wrote: > > > > --- On Fri, 6/19/09, Jeff Roberson wrote: > >> From: Jeff Roberson >> Subject: mbuf layout optimizations >> To: net@freebsd.org, current@freebsd.org >> Date: Friday, June 19, 2009, 5:12 AM >> http://people.freebsd.org/~jeff/mbuf2.diff >> >> Hello, >> >> This is a call for testers and feedback on my mbuf layout >> improvements. I'm trying to decide whether I will push to >> have these included in 8.0. After reducing the scope >> slightly from my last patch, I have not encountered any >> problems.  Kip Macy has also been using it for the past >> few weeks without issue. >> >> You should not expect any functional changes from this >> patch.  The goal is mostly to pave the way fors more >> sensible mbuf handling in the future, although it does offer >> a few performance benefits. >> >> The only issue is that cxgb support requires another set of >> patches from Kip.  If anyone needs those I will prod >> him to reply with that diff. >> >> Thanks, >> Jeff > > I thought that the purpose of m_tags was to keep individual applications from having to "patch" mbufs. Has that idea proven to be too > performance-challenged? m_tags are unrelated to this diff. This addresses the fundamental memory allocation mechanisms and layout of the mbuf. It reduces the amount of book keeping necessary and makes reference counts more pervasive. Thanks, Jeff > > Barney > --2547152148-1022206537-1245433402=:1025-- From owner-freebsd-current@FreeBSD.ORG Sat Jun 20 02:25:40 2009 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 501341065670; Sat, 20 Jun 2009 02:25:40 +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 F02718FC12; Sat, 20 Jun 2009 02:25:39 +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.3/8.14.3) with ESMTP id n5K2PbL2016492; Fri, 19 Jun 2009 22:25:37 -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 n5K2PbEB028998; Fri, 19 Jun 2009 22:25:37 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id ED32F7302F; Fri, 19 Jun 2009 22:25:36 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090620022536.ED32F7302F@freebsd-current.sentex.ca> Date: Fri, 19 Jun 2009 22:25:36 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp2.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on arm/arm 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: Sat, 20 Jun 2009 02:25:40 -0000 TB --- 2009-06-20 01:20:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-06-20 01:20:00 - starting HEAD tinderbox run for arm/arm TB --- 2009-06-20 01:20:00 - cleaning the object tree TB --- 2009-06-20 01:20:34 - cvsupping the source tree TB --- 2009-06-20 01:20:34 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/arm/arm/supfile TB --- 2009-06-20 01:20:42 - building world TB --- 2009-06-20 01:20:42 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-20 01:20:42 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-20 01:20:42 - TARGET=arm TB --- 2009-06-20 01:20:42 - TARGET_ARCH=arm TB --- 2009-06-20 01:20:42 - TZ=UTC TB --- 2009-06-20 01:20:42 - __MAKE_CONF=/dev/null TB --- 2009-06-20 01:20:42 - cd /src TB --- 2009-06-20 01:20:42 - /usr/bin/make -B buildworld >>> World build started on Sat Jun 20 01:20:45 UTC 2009 >>> 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 [...] cc -O -pipe -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/newsyslog/ptimes.c cc -O -pipe -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -o newsyslog newsyslog.o ptimes.o gzip -cn /src/usr.sbin/newsyslog/newsyslog.8 > newsyslog.8.gz gzip -cn /src/usr.sbin/newsyslog/newsyslog.conf.5 > newsyslog.conf.5.gz ===> usr.sbin/nfscbd (all) cc -O -pipe -std=gnu99 -c /src/usr.sbin/nfscbd/nfscbd.c In file included from /src/usr.sbin/nfscbd/nfscbd.c:50: /obj/arm/src/tmp/usr/include/fs/nfs/nfs.h:413: error: 'RPCAUTH_UNIXGIDS' undeclared here (not in a function) *** Error code 1 Stop in /src/usr.sbin/nfscbd. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-20 02:25:36 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-20 02:25:36 - ERROR: failed to build world TB --- 2009-06-20 02:25:36 - 3025.02 user 368.67 system 3936.20 real http://tinderbox.des.no/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Sat Jun 20 02:43:22 2009 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 C29DF1065670; Sat, 20 Jun 2009 02:43:22 +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 6E73A8FC13; Sat, 20 Jun 2009 02:43:22 +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.3/8.14.3) with ESMTP id n5K2hKZu017528; Fri, 19 Jun 2009 22:43:20 -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 n5K2hK4J067381; Fri, 19 Jun 2009 22:43:20 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id EF4D07302F; Fri, 19 Jun 2009 22:43:19 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090620024319.EF4D07302F@freebsd-current.sentex.ca> Date: Fri, 19 Jun 2009 22:43:19 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp2.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on amd64/amd64 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: Sat, 20 Jun 2009 02:43:23 -0000 TB --- 2009-06-20 01:20:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-06-20 01:20:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2009-06-20 01:20:00 - cleaning the object tree TB --- 2009-06-20 01:21:06 - cvsupping the source tree TB --- 2009-06-20 01:21:06 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/amd64/amd64/supfile TB --- 2009-06-20 01:21:16 - building world TB --- 2009-06-20 01:21:16 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-20 01:21:16 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-20 01:21:16 - TARGET=amd64 TB --- 2009-06-20 01:21:16 - TARGET_ARCH=amd64 TB --- 2009-06-20 01:21:16 - TZ=UTC TB --- 2009-06-20 01:21:16 - __MAKE_CONF=/dev/null TB --- 2009-06-20 01:21:16 - cd /src TB --- 2009-06-20 01:21:16 - /usr/bin/make -B buildworld >>> World build started on Sat Jun 20 01:21:17 UTC 2009 >>> 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 [...] cc -O2 -pipe -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/newsyslog/ptimes.c cc -O2 -pipe -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -o newsyslog newsyslog.o ptimes.o gzip -cn /src/usr.sbin/newsyslog/newsyslog.8 > newsyslog.8.gz gzip -cn /src/usr.sbin/newsyslog/newsyslog.conf.5 > newsyslog.conf.5.gz ===> usr.sbin/nfscbd (all) cc -O2 -pipe -std=gnu99 -fstack-protector -c /src/usr.sbin/nfscbd/nfscbd.c In file included from /src/usr.sbin/nfscbd/nfscbd.c:50: /obj/amd64/src/tmp/usr/include/fs/nfs/nfs.h:413: error: 'RPCAUTH_UNIXGIDS' undeclared here (not in a function) *** Error code 1 Stop in /src/usr.sbin/nfscbd. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-20 02:43:19 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-20 02:43:19 - ERROR: failed to build world TB --- 2009-06-20 02:43:19 - 3845.47 user 388.22 system 4999.41 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Sat Jun 20 03:45:41 2009 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 86E311065672; Sat, 20 Jun 2009 03:45:41 +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 333F58FC14; Sat, 20 Jun 2009 03:45:40 +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.3/8.14.3) with ESMTP id n5K3jcSj020627; Fri, 19 Jun 2009 23:45:38 -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 n5K3jcZk088634; Fri, 19 Jun 2009 23:45:38 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 767557302F; Fri, 19 Jun 2009 23:45:38 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090620034538.767557302F@freebsd-current.sentex.ca> Date: Fri, 19 Jun 2009 23:45:38 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp2.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on i386/i386 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: Sat, 20 Jun 2009 03:45:42 -0000 TB --- 2009-06-20 02:25:37 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-06-20 02:25:37 - starting HEAD tinderbox run for i386/i386 TB --- 2009-06-20 02:25:37 - cleaning the object tree TB --- 2009-06-20 02:26:21 - cvsupping the source tree TB --- 2009-06-20 02:26:21 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/i386/supfile TB --- 2009-06-20 02:26:34 - building world TB --- 2009-06-20 02:26:34 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-20 02:26:34 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-20 02:26:34 - TARGET=i386 TB --- 2009-06-20 02:26:34 - TARGET_ARCH=i386 TB --- 2009-06-20 02:26:34 - TZ=UTC TB --- 2009-06-20 02:26:34 - __MAKE_CONF=/dev/null TB --- 2009-06-20 02:26:34 - cd /src TB --- 2009-06-20 02:26:34 - /usr/bin/make -B buildworld >>> World build started on Sat Jun 20 02:26:36 UTC 2009 >>> 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 [...] cc -O2 -pipe -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/newsyslog/ptimes.c cc -O2 -pipe -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -o newsyslog newsyslog.o ptimes.o gzip -cn /src/usr.sbin/newsyslog/newsyslog.8 > newsyslog.8.gz gzip -cn /src/usr.sbin/newsyslog/newsyslog.conf.5 > newsyslog.conf.5.gz ===> usr.sbin/nfscbd (all) cc -O2 -pipe -std=gnu99 -fstack-protector -c /src/usr.sbin/nfscbd/nfscbd.c In file included from /src/usr.sbin/nfscbd/nfscbd.c:50: /obj/src/tmp/usr/include/fs/nfs/nfs.h:413: error: 'RPCAUTH_UNIXGIDS' undeclared here (not in a function) *** Error code 1 Stop in /src/usr.sbin/nfscbd. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-20 03:45:38 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-20 03:45:38 - ERROR: failed to build world TB --- 2009-06-20 03:45:38 - 3787.32 user 369.96 system 4801.27 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Sat Jun 20 04:02:30 2009 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 E4480106564A; Sat, 20 Jun 2009 04:02:30 +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 908498FC0C; Sat, 20 Jun 2009 04:02:30 +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.3/8.14.3) with ESMTP id n5K42Sa8021135; Sat, 20 Jun 2009 00:02:28 -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 n5K42SIT023690; Sat, 20 Jun 2009 00:02:28 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 7D8CA7302F; Sat, 20 Jun 2009 00:02:28 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090620040228.7D8CA7302F@freebsd-current.sentex.ca> Date: Sat, 20 Jun 2009 00:02:28 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp2.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on i386/pc98 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: Sat, 20 Jun 2009 04:02:31 -0000 TB --- 2009-06-20 02:43:20 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-06-20 02:43:20 - starting HEAD tinderbox run for i386/pc98 TB --- 2009-06-20 02:43:20 - cleaning the object tree TB --- 2009-06-20 02:43:59 - cvsupping the source tree TB --- 2009-06-20 02:43:59 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/pc98/supfile TB --- 2009-06-20 02:44:08 - building world TB --- 2009-06-20 02:44:08 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-20 02:44:08 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-20 02:44:08 - TARGET=pc98 TB --- 2009-06-20 02:44:08 - TARGET_ARCH=i386 TB --- 2009-06-20 02:44:08 - TZ=UTC TB --- 2009-06-20 02:44:08 - __MAKE_CONF=/dev/null TB --- 2009-06-20 02:44:08 - cd /src TB --- 2009-06-20 02:44:08 - /usr/bin/make -B buildworld >>> World build started on Sat Jun 20 02:44:10 UTC 2009 >>> 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 [...] cc -O2 -pipe -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/newsyslog/ptimes.c cc -O2 -pipe -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -o newsyslog newsyslog.o ptimes.o gzip -cn /src/usr.sbin/newsyslog/newsyslog.8 > newsyslog.8.gz gzip -cn /src/usr.sbin/newsyslog/newsyslog.conf.5 > newsyslog.conf.5.gz ===> usr.sbin/nfscbd (all) cc -O2 -pipe -std=gnu99 -fstack-protector -c /src/usr.sbin/nfscbd/nfscbd.c In file included from /src/usr.sbin/nfscbd/nfscbd.c:50: /obj/pc98/src/tmp/usr/include/fs/nfs/nfs.h:413: error: 'RPCAUTH_UNIXGIDS' undeclared here (not in a function) *** Error code 1 Stop in /src/usr.sbin/nfscbd. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-20 04:02:28 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-20 04:02:28 - ERROR: failed to build world TB --- 2009-06-20 04:02:28 - 3748.54 user 381.20 system 4748.37 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Sat Jun 20 04:04:54 2009 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 7F049106567A for ; Sat, 20 Jun 2009 04:04:54 +0000 (UTC) (envelope-from freebsd.work@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.28]) by mx1.freebsd.org (Postfix) with ESMTP id 3D6A78FC28 for ; Sat, 20 Jun 2009 04:04:53 +0000 (UTC) (envelope-from freebsd.work@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so962972ywe.13 for ; Fri, 19 Jun 2009 21:04:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=OS19nk4FgFHcn01Mpb04S/bClq5Nms+NPolVcfnN5Kg=; b=Qn59W7sEVv2HSMIWHCPK2aClGd5XEfeYdfAeUw/2nJodwjqWl+0q+WAtHIkYWbFaFZ UXl65nhIhrwT7lnmuS1Tm1QAzGopmIrBbgSrNGnP5O8pXxMLO0bbmMSocRh0k0xLrKk6 ZO0/dDAnwc/5fC7mct1Ie6Jx7swp4o7Wvan3o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=XfrPOiRlJDcLlCJQM7+NS1XGYRbFHBO83XFLHBI32AoRYE8+DqcH7z750se9+/4tF/ fhqWSfEz6eRUMcOS1gD9pY7ciJCfb0/qR76JlDOUcJoClqPep0F9N/pTYupf5U/wntte U11iaxeOtjIUQh2zfWrctX2RuTnLxb0VFGQH0= MIME-Version: 1.0 Received: by 10.231.39.4 with SMTP id d4mr1175091ibe.10.1245470693181; Fri, 19 Jun 2009 21:04:53 -0700 (PDT) Date: Fri, 19 Jun 2009 21:04:53 -0700 Message-ID: <45d874490906192104w1a11271am97f6d9705b7fa49c@mail.gmail.com> From: "Sean P. Dew" To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: building device drivers for FreeBSD 7.2+ /AMD64 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, 20 Jun 2009 04:04:54 -0000 Is there any tutorial/book on building device drivers for Free BSD? Thanks From owner-freebsd-current@FreeBSD.ORG Sat Jun 20 04:23:36 2009 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 6A34F106566C for ; Sat, 20 Jun 2009 04:23:36 +0000 (UTC) (envelope-from oberman@es.net) Received: from mailgw.es.net (mail1.es.net [IPv6:2001:400:201:1::2]) by mx1.freebsd.org (Postfix) with ESMTP id 5292D8FC0C for ; Sat, 20 Jun 2009 04:23:36 +0000 (UTC) (envelope-from oberman@es.net) Received: from ptavv.es.net (ptavv.es.net [IPv6:2001:400:910::29]) by mailgw.es.net (8.14.3/8.14.3) with ESMTP id n5K4NXKo017477 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 19 Jun 2009 21:23:35 -0700 Received: from ptavv.es.net (ptavv.es.net [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 520971CC09; Fri, 19 Jun 2009 21:23:33 -0700 (PDT) To: "Sean P. Dew" In-reply-to: Your message of "Fri, 19 Jun 2009 21:04:53 PDT." <45d874490906192104w1a11271am97f6d9705b7fa49c@mail.gmail.com> Date: Fri, 19 Jun 2009 21:23:33 -0700 From: "Kevin Oberman" Message-Id: <20090620042333.520971CC09@ptavv.es.net> X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2009-06-19_02:2009-06-01, 2009-06-19, 2009-06-18 signatures=0 Cc: freebsd-current@freebsd.org Subject: Re: building device drivers for FreeBSD 7.2+ /AMD64 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, 20 Jun 2009 04:23:36 -0000 > Date: Fri, 19 Jun 2009 21:04:53 -0700 > From: "Sean P. Dew" > Sender: owner-freebsd-current@freebsd.org > > Is there any tutorial/book on building device drivers for Free BSD? The canonical one is "The FreeBSD Developers' Handbook" (http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/index.html) Also, see the FreeBSD Documentation pages for information on paper books. http://www.freebsd.org/publish.html While a bit out of date, Kirk McKusick and George Neville-Neil's "The Design and Implementation of the FreeBSD Operating System", ISBN 4-7561-4679-1 is still probably the most detailed presentation on the OS internals. Based on FreeBSD 5.2, it is the modern kernel and driver design, but it is still nearly 5 years old. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From owner-freebsd-current@FreeBSD.ORG Sat Jun 20 04:43:27 2009 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 3F947106564A for ; Sat, 20 Jun 2009 04:43:27 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by mx1.freebsd.org (Postfix) with ESMTP id C80118FC0A for ; Sat, 20 Jun 2009 04:43:26 +0000 (UTC) (envelope-from max@love2party.net) Received: from vampire.homelinux.org (dslb-088-064-178-032.pools.arcor-ip.net [88.64.178.32]) by mrelayeu.kundenserver.de (node=mrbap0) with ESMTP (Nemesis) id 0MKsym-1MHsQH1aku-000dgf; Sat, 20 Jun 2009 06:43:25 +0200 Received: (qmail 58417 invoked from network); 20 Jun 2009 04:43:25 -0000 Received: from kvm.laiers.local (HELO kvm.localnet) (192.168.4.187) by laiers.local with SMTP; 20 Jun 2009 04:43:25 -0000 From: Max Laier Organization: FreeBSD To: freebsd-current@freebsd.org Date: Sat, 20 Jun 2009 06:43:24 +0200 User-Agent: KMail/1.11.3 (Linux/2.6.30-rc5-ARCH; KDE/4.2.3; x86_64; ; ) References: <20090620042333.520971CC09@ptavv.es.net> In-Reply-To: <20090620042333.520971CC09@ptavv.es.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200906200643.24654.max@love2party.net> X-Provags-ID: V01U2FsdGVkX18iRniNnL4NwAoDrRe0PWOVNnfgyU9Tl0zPbtt /CANDnwVQ2p/acvcnw/87cLGn1EW9RXnfw+Ip/hj3Klkpj3q/M amv48xwW9PSIEAqqmIk7A== Cc: "Sean P. Dew" Subject: Re: building device drivers for FreeBSD 7.2+ /AMD64 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, 20 Jun 2009 04:43:27 -0000 On Saturday 20 June 2009 06:23:33 Kevin Oberman wrote: > > Date: Fri, 19 Jun 2009 21:04:53 -0700 > > From: "Sean P. Dew" > > Sender: owner-freebsd-current@freebsd.org > > > > Is there any tutorial/book on building device drivers for Free BSD? > > The canonical one is "The FreeBSD Developers' Handbook" > (http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/i >ndex.html) > > Also, see the FreeBSD Documentation pages for information on paper > books. http://www.freebsd.org/publish.html > > While a bit out of date, Kirk McKusick and George Neville-Neil's "The > Design and Implementation of the FreeBSD Operating System", ISBN > 4-7561-4679-1 is still probably the most detailed presentation on the > OS internals. Based on FreeBSD 5.2, it is the modern kernel and driver > design, but it is still nearly 5 years old. You might also want to look at the driver(9) man page and those linked from there. In addition check out jmg's 2006 BSDCan Presentation: http://www.bsdcan.org/2006/papers/freebsd.device.driver.slides.pdf http://www.bsdcan.org/2006/papers/freebsd.driver.pdf -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From owner-freebsd-current@FreeBSD.ORG Sat Jun 20 05:06:22 2009 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 ACB7A106566C; Sat, 20 Jun 2009 05:06:22 +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 587428FC16; Sat, 20 Jun 2009 05:06:22 +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.3/8.14.3) with ESMTP id n5K56JN4023679; Sat, 20 Jun 2009 01:06:19 -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 n5K56Jei046789; Sat, 20 Jun 2009 01:06:19 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 3D1567302F; Sat, 20 Jun 2009 01:06:19 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090620050619.3D1567302F@freebsd-current.sentex.ca> Date: Sat, 20 Jun 2009 01:06:19 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp2.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on mips/mips 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: Sat, 20 Jun 2009 05:06:23 -0000 TB --- 2009-06-20 04:02:28 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-06-20 04:02:28 - starting HEAD tinderbox run for mips/mips TB --- 2009-06-20 04:02:28 - cleaning the object tree TB --- 2009-06-20 04:02:46 - cvsupping the source tree TB --- 2009-06-20 04:02:46 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/mips/mips/supfile TB --- 2009-06-20 04:02:53 - building world TB --- 2009-06-20 04:02:53 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-20 04:02:53 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-20 04:02:53 - TARGET=mips TB --- 2009-06-20 04:02:53 - TARGET_ARCH=mips TB --- 2009-06-20 04:02:53 - TZ=UTC TB --- 2009-06-20 04:02:53 - __MAKE_CONF=/dev/null TB --- 2009-06-20 04:02:53 - cd /src TB --- 2009-06-20 04:02:53 - /usr/bin/make -B buildworld >>> World build started on Sat Jun 20 04:02:55 UTC 2009 >>> 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 [...] cc -O -pipe -EL -msoft-float -G0 -mno-dsp -mabicalls -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/newsyslog/ptimes.c cc -O -pipe -EL -msoft-float -G0 -mno-dsp -mabicalls -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wl,-EL -o newsyslog newsyslog.o ptimes.o gzip -cn /src/usr.sbin/newsyslog/newsyslog.8 > newsyslog.8.gz gzip -cn /src/usr.sbin/newsyslog/newsyslog.conf.5 > newsyslog.conf.5.gz ===> usr.sbin/nfscbd (all) cc -O -pipe -EL -msoft-float -G0 -mno-dsp -mabicalls -std=gnu99 -c /src/usr.sbin/nfscbd/nfscbd.c In file included from /src/usr.sbin/nfscbd/nfscbd.c:50: /obj/mips/src/tmp/usr/include/fs/nfs/nfs.h:413: error: 'RPCAUTH_UNIXGIDS' undeclared here (not in a function) *** Error code 1 Stop in /src/usr.sbin/nfscbd. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-20 05:06:18 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-20 05:06:18 - ERROR: failed to build world TB --- 2009-06-20 05:06:18 - 2962.75 user 341.17 system 3830.40 real http://tinderbox.des.no/tinderbox-head-HEAD-mips-mips.full From owner-freebsd-current@FreeBSD.ORG Sat Jun 20 05:29:59 2009 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 B9B48106564A; Sat, 20 Jun 2009 05:29:59 +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 6619A8FC0A; Sat, 20 Jun 2009 05:29:59 +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.3/8.14.3) with ESMTP id n5K5TvAF024770; Sat, 20 Jun 2009 01:29:57 -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 n5K5TuLd094767; Sat, 20 Jun 2009 01:29:56 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id D52EF7302F; Sat, 20 Jun 2009 01:29:56 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090620052956.D52EF7302F@freebsd-current.sentex.ca> Date: Sat, 20 Jun 2009 01:29:56 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp2.sentex.ca 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: Sat, 20 Jun 2009 05:30:00 -0000 TB --- 2009-06-20 03:45:38 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-06-20 03:45:38 - starting HEAD tinderbox run for ia64/ia64 TB --- 2009-06-20 03:45:38 - cleaning the object tree TB --- 2009-06-20 03:46:13 - cvsupping the source tree TB --- 2009-06-20 03:46:13 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/ia64/ia64/supfile TB --- 2009-06-20 03:46:22 - building world TB --- 2009-06-20 03:46:22 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-20 03:46:22 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-20 03:46:22 - TARGET=ia64 TB --- 2009-06-20 03:46:22 - TARGET_ARCH=ia64 TB --- 2009-06-20 03:46:22 - TZ=UTC TB --- 2009-06-20 03:46:22 - __MAKE_CONF=/dev/null TB --- 2009-06-20 03:46:22 - cd /src TB --- 2009-06-20 03:46:22 - /usr/bin/make -B buildworld >>> World build started on Sat Jun 20 03:46:24 UTC 2009 >>> 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 [...] cc -O2 -pipe -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/newsyslog/ptimes.c cc -O2 -pipe -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -o newsyslog newsyslog.o ptimes.o gzip -cn /src/usr.sbin/newsyslog/newsyslog.8 > newsyslog.8.gz gzip -cn /src/usr.sbin/newsyslog/newsyslog.conf.5 > newsyslog.conf.5.gz ===> usr.sbin/nfscbd (all) cc -O2 -pipe -std=gnu99 -c /src/usr.sbin/nfscbd/nfscbd.c In file included from /src/usr.sbin/nfscbd/nfscbd.c:50: /obj/ia64/src/tmp/usr/include/fs/nfs/nfs.h:413: error: 'RPCAUTH_UNIXGIDS' undeclared here (not in a function) *** Error code 1 Stop in /src/usr.sbin/nfscbd. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-20 05:29:56 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-20 05:29:56 - ERROR: failed to build world TB --- 2009-06-20 05:29:56 - 5137.30 user 383.63 system 6258.17 real http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Sat Jun 20 06:28:07 2009 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 DFD3C106566C; Sat, 20 Jun 2009 06:28:07 +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 8B7B98FC15; Sat, 20 Jun 2009 06:28:07 +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.3/8.14.3) with ESMTP id n5K6S5LW028359; Sat, 20 Jun 2009 02:28:05 -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 n5K6S54N008396; Sat, 20 Jun 2009 02:28:05 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id CEC2C7302F; Sat, 20 Jun 2009 02:28:04 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090620062804.CEC2C7302F@freebsd-current.sentex.ca> Date: Sat, 20 Jun 2009 02:28:04 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp2.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 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: Sat, 20 Jun 2009 06:28:08 -0000 TB --- 2009-06-20 05:06:19 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-06-20 05:06:19 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2009-06-20 05:06:19 - cleaning the object tree TB --- 2009-06-20 05:06:49 - cvsupping the source tree TB --- 2009-06-20 05:06:49 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2009-06-20 05:06:58 - building world TB --- 2009-06-20 05:06:58 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-20 05:06:58 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-20 05:06:58 - TARGET=powerpc TB --- 2009-06-20 05:06:58 - TARGET_ARCH=powerpc TB --- 2009-06-20 05:06:58 - TZ=UTC TB --- 2009-06-20 05:06:58 - __MAKE_CONF=/dev/null TB --- 2009-06-20 05:06:58 - cd /src TB --- 2009-06-20 05:06:58 - /usr/bin/make -B buildworld >>> World build started on Sat Jun 20 05:07:00 UTC 2009 >>> 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 [...] cc -O2 -pipe -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/newsyslog/ptimes.c cc -O2 -pipe -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -o newsyslog newsyslog.o ptimes.o gzip -cn /src/usr.sbin/newsyslog/newsyslog.8 > newsyslog.8.gz gzip -cn /src/usr.sbin/newsyslog/newsyslog.conf.5 > newsyslog.conf.5.gz ===> usr.sbin/nfscbd (all) cc -O2 -pipe -std=gnu99 -fstack-protector -c /src/usr.sbin/nfscbd/nfscbd.c In file included from /src/usr.sbin/nfscbd/nfscbd.c:50: /obj/powerpc/src/tmp/usr/include/fs/nfs/nfs.h:413: error: 'RPCAUTH_UNIXGIDS' undeclared here (not in a function) *** Error code 1 Stop in /src/usr.sbin/nfscbd. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-20 06:28:04 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-20 06:28:04 - ERROR: failed to build world TB --- 2009-06-20 06:28:04 - 3922.36 user 370.19 system 4905.33 real http://tinderbox.des.no/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sat Jun 20 06:48:19 2009 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 68F271065670; Sat, 20 Jun 2009 06:48:19 +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 16AE78FC08; Sat, 20 Jun 2009 06:48:18 +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.3/8.14.3) with ESMTP id n5K6mHQd083953; Sat, 20 Jun 2009 02:48:17 -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.3/8.14.3) with ESMTP id n5K6mHBL049445; Sat, 20 Jun 2009 02:48:17 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id E3A347302F; Sat, 20 Jun 2009 02:48:16 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090620064816.E3A347302F@freebsd-current.sentex.ca> Date: Sat, 20 Jun 2009 02:48:16 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp1.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 205.211.164.50 Cc: Subject: [head tinderbox] failure on sparc64/sparc64 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: Sat, 20 Jun 2009 06:48:20 -0000 TB --- 2009-06-20 05:29:56 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-06-20 05:29:56 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2009-06-20 05:29:56 - cleaning the object tree TB --- 2009-06-20 05:30:37 - cvsupping the source tree TB --- 2009-06-20 05:30:37 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2009-06-20 05:30:45 - building world TB --- 2009-06-20 05:30:45 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-20 05:30:45 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-20 05:30:45 - TARGET=sparc64 TB --- 2009-06-20 05:30:45 - TARGET_ARCH=sparc64 TB --- 2009-06-20 05:30:45 - TZ=UTC TB --- 2009-06-20 05:30:45 - __MAKE_CONF=/dev/null TB --- 2009-06-20 05:30:45 - cd /src TB --- 2009-06-20 05:30:45 - /usr/bin/make -B buildworld >>> World build started on Sat Jun 20 05:30:47 UTC 2009 >>> 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 [...] cc -O2 -pipe -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/newsyslog/ptimes.c cc -O2 -pipe -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -o newsyslog newsyslog.o ptimes.o gzip -cn /src/usr.sbin/newsyslog/newsyslog.8 > newsyslog.8.gz gzip -cn /src/usr.sbin/newsyslog/newsyslog.conf.5 > newsyslog.conf.5.gz ===> usr.sbin/nfscbd (all) cc -O2 -pipe -std=gnu99 -fstack-protector -c /src/usr.sbin/nfscbd/nfscbd.c In file included from /src/usr.sbin/nfscbd/nfscbd.c:50: /obj/sparc64/src/tmp/usr/include/fs/nfs/nfs.h:413: error: 'RPCAUTH_UNIXGIDS' undeclared here (not in a function) *** Error code 1 Stop in /src/usr.sbin/nfscbd. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-20 06:48:16 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-20 06:48:16 - ERROR: failed to build world TB --- 2009-06-20 06:48:16 - 3674.11 user 365.71 system 4699.92 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Sat Jun 20 07:11:49 2009 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 980B81065670 for ; Sat, 20 Jun 2009 07:11:49 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from ch-smtp01.sth.basefarm.net (ch-smtp01.sth.basefarm.net [80.76.149.212]) by mx1.freebsd.org (Postfix) with ESMTP id 2AB568FC0C for ; Sat, 20 Jun 2009 07:11:48 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from c83-253-252-234.bredband.comhem.se ([83.253.252.234]:44889 helo=mx.exscape.org) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.69) (envelope-from ) id 1MHujg-0006XO-5a for freebsd-current@freebsd.org; Sat, 20 Jun 2009 09:11:38 +0200 Received: from [192.168.1.5] (macbookpro [192.168.1.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx.exscape.org (Postfix) with ESMTPSA id 495896A98E for ; Sat, 20 Jun 2009 09:11:36 +0200 (CEST) Message-Id: <72163521-40BF-4764-8B74-5446A88DFBF8@exscape.org> From: Thomas Backman To: FreeBSD current Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sat, 20 Jun 2009 09:11:34 +0200 X-Mailer: Apple Mail (2.935.3) X-Originating-IP: 83.253.252.234 X-Scan-Result: No virus found in message 1MHujg-0006XO-5a. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1MHujg-0006XO-5a 6a313ac0145f1ada6e227df48fcaf444 Subject: "New" ZFS crash on FS (pool?) unmount/export 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, 20 Jun 2009 07:11:49 -0000 I just ran into this tonight. Not sure exactly what triggered it - the box stopped responding to pings at 02:07AM and it has a cron backup job using zfs send/recv at 02:00, so I'm guessing it's related, even though the backup probably should have finished before then... Hmm. Anyway. r194478. kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x288 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff805a4989 stack pointer = 0x28:0xffffff803e8b57e0 frame pointer = 0x28:0xffffff803e8b5840 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 = 57514 (zpool) panic: from debugger cpuid = 0 Uptime: 10h22m13s Physical memory: 2027 MB (kgdb) bt #0 doadump () at pcpu.h:223 #1 0xffffffff8059c409 in boot (howto=260) at /usr/src/sys/kern/ kern_shutdown.c:419 #2 0xffffffff8059c85c in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:575 #3 0xffffffff801f1377 in db_panic (addr=Variable "addr" is not available. ) at /usr/src/sys/ddb/db_command.c:478 #4 0xffffffff801f1781 in db_command (last_cmdp=0xffffffff80c38620, cmd_table=Variable "cmd_table" is not available. ) at /usr/src/sys/ddb/db_command.c:445 #5 0xffffffff801f19d0 in db_command_loop () at /usr/src/sys/ddb/ db_command.c:498 #6 0xffffffff801f3969 in db_trap (type=Variable "type" is not available. ) at /usr/src/sys/ddb/db_main.c:229 #7 0xffffffff805ce465 in kdb_trap (type=12, code=0, tf=0xffffff803e8b5730) at /usr/src/sys/kern/subr_kdb.c:534 #8 0xffffffff8088715d in trap_fatal (frame=0xffffff803e8b5730, eva=Variable "eva" is not available. ) at /usr/src/sys/amd64/amd64/trap.c:847 #9 0xffffffff80887fb2 in trap (frame=0xffffff803e8b5730) at /usr/src/ sys/amd64/amd64/trap.c:345 #10 0xffffffff8086e007 in calltrap () at /usr/src/sys/amd64/amd64/ exception.S:223 #11 0xffffffff805a4989 in _sx_xlock_hard (sx=0xffffff0043557d50, tid=18446742975830720512, opts=Variable "opts" is not available. ) at /usr/src/sys/kern/kern_sx.c:575 #12 0xffffffff805a52fe in _sx_xlock (sx=Variable "sx" is not available. ) at sx.h:155 #13 0xffffffff80fe2995 in zfs_freebsd_reclaim () from /boot/kernel/ zfs.ko #14 0xffffffff808cefca in VOP_RECLAIM_APV (vop=0xffffff0043557d38, a=0xffffff0043557d50) at vnode_if.c:1926 #15 0xffffffff80626f6e in vgonel (vp=0xffffff00437a7938) at vnode_if.h: 830 #16 0xffffffff8062b528 in vflush (mp=0xffffff0060f2a000, rootrefs=0, flags=0, td=0xffffff0061528000) at /usr/src/sys/kern/vfs_subr.c:2450 #17 0xffffffff80fdd3a8 in zfs_umount () from /boot/kernel/zfs.ko #18 0xffffffff8062420a in dounmount (mp=0xffffff0060f2a000, flags=1626513408, td=Variable "td" is not available. ) at /usr/src/sys/kern/vfs_mount.c:1287 #19 0xffffffff80624975 in unmount (td=0xffffff0061528000, uap=0xffffff803e8b5c00) at /usr/src/sys/kern/vfs_mount.c:1172 #20 0xffffffff8088783f in syscall (frame=0xffffff803e8b5c90) at /usr/ src/sys/amd64/amd64/trap.c:984 #21 0xffffffff8086e290 in Xfast_syscall () at /usr/src/sys/amd64/amd64/ exception.S:364 #22 0x000000080104e49c in ?? () Previous frame inner to this frame (corrupt stack?) BTW, I got a (one) "force unmount is experimental" on the console. On regular shutdown I usually get one per filesystem, it seems (at least 10) and this pool should contain exactly as many filesystems as the root pool since it's a copy of it. On running the backup script manually post-crash, though, I didn't get any. Also worth noting is that I was running DTrace all night to test its stability. I'm pretty sure the script was dtrace -n 'syscall::open:entry { @a[copyinstr(arg0)] = count(); }' 0 swap was used and 277700 pages (~1084 MB or 50%) RAM was free, according to the core.txt. Regards, Thomas From owner-freebsd-current@FreeBSD.ORG Sat Jun 20 07:46:48 2009 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 968651065673; Sat, 20 Jun 2009 07:46:48 +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 43DA68FC13; Sat, 20 Jun 2009 07:46:47 +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.3/8.14.3) with ESMTP id n5K7kkDU091346; Sat, 20 Jun 2009 03:46:46 -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.3/8.14.3) with ESMTP id n5K7kjtn073741; Sat, 20 Jun 2009 03:46:45 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id D1C847302F; Sat, 20 Jun 2009 03:46:45 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090620074645.D1C847302F@freebsd-current.sentex.ca> Date: Sat, 20 Jun 2009 03:46:45 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp1.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 205.211.164.50 Cc: Subject: [head tinderbox] failure on sparc64/sun4v 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: Sat, 20 Jun 2009 07:46:49 -0000 TB --- 2009-06-20 06:28:04 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-06-20 06:28:04 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2009-06-20 06:28:04 - cleaning the object tree TB --- 2009-06-20 06:28:37 - cvsupping the source tree TB --- 2009-06-20 06:28:37 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2009-06-20 06:28:45 - building world TB --- 2009-06-20 06:28:45 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-20 06:28:45 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-20 06:28:45 - TARGET=sun4v TB --- 2009-06-20 06:28:45 - TARGET_ARCH=sparc64 TB --- 2009-06-20 06:28:45 - TZ=UTC TB --- 2009-06-20 06:28:45 - __MAKE_CONF=/dev/null TB --- 2009-06-20 06:28:45 - cd /src TB --- 2009-06-20 06:28:45 - /usr/bin/make -B buildworld >>> World build started on Sat Jun 20 06:28:48 UTC 2009 >>> 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 [...] cc -O2 -pipe -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/newsyslog/ptimes.c cc -O2 -pipe -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -o newsyslog newsyslog.o ptimes.o gzip -cn /src/usr.sbin/newsyslog/newsyslog.8 > newsyslog.8.gz gzip -cn /src/usr.sbin/newsyslog/newsyslog.conf.5 > newsyslog.conf.5.gz ===> usr.sbin/nfscbd (all) cc -O2 -pipe -std=gnu99 -fstack-protector -c /src/usr.sbin/nfscbd/nfscbd.c In file included from /src/usr.sbin/nfscbd/nfscbd.c:50: /obj/sun4v/src/tmp/usr/include/fs/nfs/nfs.h:413: error: 'RPCAUTH_UNIXGIDS' undeclared here (not in a function) *** Error code 1 Stop in /src/usr.sbin/nfscbd. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-20 07:46:45 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-20 07:46:45 - ERROR: failed to build world TB --- 2009-06-20 07:46:45 - 3680.04 user 363.68 system 4720.91 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Sat Jun 20 08:13:35 2009 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 5C6311065673; Sat, 20 Jun 2009 08:13:35 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id E8E3A8FC0A; Sat, 20 Jun 2009 08:13:33 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id LAA15090; Sat, 20 Jun 2009 11:13:27 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1] helo=edge.pp.kiev.ua) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1MHvhW-000OVj-Mx; Sat, 20 Jun 2009 11:13:26 +0300 Message-ID: <4A3C9A25.8050305@icyb.net.ua> Date: Sat, 20 Jun 2009 11:13:25 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.21 (X11/20090406) MIME-Version: 1.0 To: Thomas Backman References: <949B5884-5303-4EFF-AC7D-293640FFA012@exscape.org> <0C235698-3ED2-4AE9-A7D1-5DC56D8324A4@exscape.org> <200905212129.47892.mel.flynn+fbsd.current@mailing.thruhere.net> <44F486FA-E798-448D-BE31-F7A51EF1F612@exscape.org> <60173AF0-7E54-4BDD-8927-0DADA9DAD1B4@exscape.org> <20090522200306.GE2630@atarininja.org> <20090617225849.GB28509@atarininja.org> <4A3A1D27.4010802@icyb.net.ua> <4A3BBF5A.6060702@icyb.net.ua> <4A3BC481.1010600@cs.rice.edu> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Alan Cox , John Birrell , FreeBSD current , Alan Cox Subject: Re: DTrace panic while probing syscall::open (and possibly many others) 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, 20 Jun 2009 08:13:35 -0000 on 19/06/2009 20:41 Thomas Backman said the following: > On Jun 19, 2009, at 07:32 PM, Thomas Backman wrote: >> Very interesting. >> I replaced the ASSERT line temporarily: >> >> --- >> ../src_r194478-UNTOUCHED/sys/cddl/dev/dtrace/amd64/dtrace_isa.c >> 2009-06-19 13:10:05.661079736 +0200 >> +++ sys/cddl/dev/dtrace/amd64/dtrace_isa.c 2009-06-19 >> 19:24:42.362125129 +0200 >> @@ -524,7 +524,7 @@ >> static int >> dtrace_copycheck(uintptr_t uaddr, uintptr_t kaddr, size_t size) >> { >> - ASSERT(kaddr >= kernelbase && kaddr + size >= kaddr); >> + ASSERT(kaddr >= 0xffffff8000000000 && kaddr + size >= kaddr); >> >> if (uaddr + size >= kernelbase || uaddr + size < uaddr) { >> DTRACE_CPUFLAG_SET(CPU_DTRACE_BADADDR); >> >> ... and it works! I obviously haven't tried it for extended periods or >> anything, but at least it's working so far. >> Should the ASSERT simply use this (as a #define somewhere) or the >> INKERNEL macro, though? I think that this should be sufficient, because I don't think that 'kaddr' of dtrace scratch buffer could be in direct map. > BTW... Should "kernelbase" in the line following the ASSERT also be > replaced, or not? As far as I can understand (not too far in these > contexts ;) it (should) check/s to see whether the userspace data, to be > copied, is inside the kernel *map*(?)... which at the moment, I guess it > doesn't. Correct? Yes, I think so too. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Sat Jun 20 08:23:03 2009 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 5F3041065672 for ; Sat, 20 Jun 2009 08:23:03 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.249]) by mx1.freebsd.org (Postfix) with ESMTP id 146548FC0C for ; Sat, 20 Jun 2009 08:23:02 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: by an-out-0708.google.com with SMTP id c3so978994ana.13 for ; Sat, 20 Jun 2009 01:23:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=V3EHx5EgJcY4my/J9xbMQzpsOl4sBRfwqWU5KoxKKCw=; b=f+W/bIF+heGytqcr+g1vovucXhjgzI12DgLWDeg2+1/LB3W1aB9OcX5v/GODAyl8qC KbiQ0WATwgmMdZNPBMjakmmbnzZOV40Zk3w8A5HQxGjD8QVfNPDnoCf9qGDy7Z3BmFd3 v2XoYPUAyLSeCgHga7BJLKIWqD+OnF2ycyIq8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=JHEGKVI8+MOnHWJz+iJeEuXsaa2wBJFhSdAsYDb6fUZtZJRhq0tXrlcYGtGYv5QDhM kUydQB1w+N82OIuXqtLCQ62vjkWZzIH8KWs0DLeHeNt+L2KIYwlte6yo5eMeR/hxFwJc NbNY+PwkyLDnZ3awjbi5BT0Rx9OW+GqDIGPVU= MIME-Version: 1.0 Sender: mat.macy@gmail.com Received: by 10.100.108.8 with SMTP id g8mr5071406anc.66.1245486182198; Sat, 20 Jun 2009 01:23:02 -0700 (PDT) In-Reply-To: <72163521-40BF-4764-8B74-5446A88DFBF8@exscape.org> References: <72163521-40BF-4764-8B74-5446A88DFBF8@exscape.org> Date: Sat, 20 Jun 2009 01:23:02 -0700 X-Google-Sender-Auth: 34eaf1e1e0b091e9 Message-ID: <3c1674c90906200123l75b4eb29y57d5b48f89c19a5b@mail.gmail.com> From: Kip Macy To: Thomas Backman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD current Subject: Re: "New" ZFS crash on FS (pool?) unmount/export 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, 20 Jun 2009 08:23:03 -0000 A force unmount causes all vnodes dirty data to be flushed and then the vnodes to be released. A regular unmount will not complete if there are open files referencing it (hence the use of force unmount on shutdown). Pawel had previously disabled forced unmount because of known "issues". I chose to enable it because it guarantees that dirty data is flushed to disk before shutdown. It looks like we may be reclaiming a vnode that has already been freed. I haven't seen this issue myself, so if you can identify more specifics on how to reproduce it would greatly increase the likelihood of my being able to fix it in the near future. Thanks, Kip On Sat, Jun 20, 2009 at 12:11 AM, Thomas Backman wrot= e: > I just ran into this tonight. Not sure exactly what triggered it - the bo= x > stopped responding to pings at 02:07AM and it has a cron backup job using > zfs send/recv at 02:00, so I'm guessing it's related, even though the bac= kup > probably should have finished before then... Hmm. Anyway. > > r194478. > > kernel trap 12 with interrupts disabled > > Fatal trap 12: page fault while in kernel mode > cpuid =3D 0; apic id =3D 00 > fault virtual address =A0 =3D 0x288 > fault code =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D supervisor read data, page not = present > instruction pointer =A0 =A0 =3D 0x20:0xffffffff805a4989 > stack pointer =A0 =A0 =A0 =A0 =A0 =3D 0x28:0xffffff803e8b57e0 > frame pointer =A0 =A0 =A0 =A0 =A0 =3D 0x28:0xffffff803e8b5840 > code segment =A0 =A0 =A0 =A0 =A0 =A0=3D base 0x0, limit 0xfffff, type 0x1= b > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D DPL 0, pres 1, long 1,= def32 0, gran 1 > processor eflags =A0 =A0 =A0 =A0=3D resume, IOPL =3D 0 > current process =A0 =A0 =A0 =A0 =3D 57514 (zpool) > panic: from debugger > cpuid =3D 0 > Uptime: 10h22m13s > Physical memory: 2027 MB > > (kgdb) bt > #0 =A0doadump () at pcpu.h:223 > #1 =A00xffffffff8059c409 in boot (howto=3D260) at > /usr/src/sys/kern/kern_shutdown.c:419 > #2 =A00xffffffff8059c85c in panic (fmt=3DVariable "fmt" is not available. > ) at /usr/src/sys/kern/kern_shutdown.c:575 > #3 =A00xffffffff801f1377 in db_panic (addr=3DVariable "addr" is not avail= able. > ) at /usr/src/sys/ddb/db_command.c:478 > #4 =A00xffffffff801f1781 in db_command (last_cmdp=3D0xffffffff80c38620, > cmd_table=3DVariable "cmd_table" is not available. > ) at /usr/src/sys/ddb/db_command.c:445 > #5 =A00xffffffff801f19d0 in db_command_loop () at > /usr/src/sys/ddb/db_command.c:498 > #6 =A00xffffffff801f3969 in db_trap (type=3DVariable "type" is not availa= ble. > ) at /usr/src/sys/ddb/db_main.c:229 > #7 =A00xffffffff805ce465 in kdb_trap (type=3D12, code=3D0, tf=3D0xffffff8= 03e8b5730) > at /usr/src/sys/kern/subr_kdb.c:534 > #8 =A00xffffffff8088715d in trap_fatal (frame=3D0xffffff803e8b5730, eva= =3DVariable > "eva" is not available. > ) at /usr/src/sys/amd64/amd64/trap.c:847 > #9 =A00xffffffff80887fb2 in trap (frame=3D0xffffff803e8b5730) at > /usr/src/sys/amd64/amd64/trap.c:345 > #10 0xffffffff8086e007 in calltrap () at > /usr/src/sys/amd64/amd64/exception.S:223 > #11 0xffffffff805a4989 in _sx_xlock_hard (sx=3D0xffffff0043557d50, > tid=3D18446742975830720512, opts=3DVariable "opts" is not available. > ) > =A0 =A0at /usr/src/sys/kern/kern_sx.c:575 > #12 0xffffffff805a52fe in _sx_xlock (sx=3DVariable "sx" is not available. > ) at sx.h:155 > #13 0xffffffff80fe2995 in zfs_freebsd_reclaim () from /boot/kernel/zfs.ko > #14 0xffffffff808cefca in VOP_RECLAIM_APV (vop=3D0xffffff0043557d38, > a=3D0xffffff0043557d50) at vnode_if.c:1926 > #15 0xffffffff80626f6e in vgonel (vp=3D0xffffff00437a7938) at vnode_if.h:= 830 > #16 0xffffffff8062b528 in vflush (mp=3D0xffffff0060f2a000, rootrefs=3D0, > flags=3D0, td=3D0xffffff0061528000) > =A0 =A0at /usr/src/sys/kern/vfs_subr.c:2450 > #17 0xffffffff80fdd3a8 in zfs_umount () from /boot/kernel/zfs.ko > #18 0xffffffff8062420a in dounmount (mp=3D0xffffff0060f2a000, > flags=3D1626513408, td=3DVariable "td" is not available. > ) > =A0 =A0at /usr/src/sys/kern/vfs_mount.c:1287 > #19 0xffffffff80624975 in unmount (td=3D0xffffff0061528000, > uap=3D0xffffff803e8b5c00) > =A0 =A0at /usr/src/sys/kern/vfs_mount.c:1172 > #20 0xffffffff8088783f in syscall (frame=3D0xffffff803e8b5c90) at > /usr/src/sys/amd64/amd64/trap.c:984 > #21 0xffffffff8086e290 in Xfast_syscall () at > /usr/src/sys/amd64/amd64/exception.S:364 > #22 0x000000080104e49c in ?? () > Previous frame inner to this frame (corrupt stack?) > > BTW, I got a (one) "force unmount is experimental" on the console. On > regular shutdown I usually get one per filesystem, it seems (at least 10) > and this pool should contain exactly as many filesystems as the root pool > since it's a copy of it. On running the backup script manually post-crash= , > though, I didn't get any. > > Also worth noting is that I was running DTrace all night to test its > stability. I'm pretty sure the script was > dtrace -n 'syscall::open:entry { @a[copyinstr(arg0)] =3D count(); }' > > 0 swap was used and 277700 pages (~1084 MB or 50%) RAM was free, accordin= g > to the core.txt. > > Regards, > Thomas > _______________________________________________ > 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= " > --=20 When bad men combine, the good must associate; else they will fall one by one, an unpitied sacrifice in a contemptible struggle. Edmund Burke From owner-freebsd-current@FreeBSD.ORG Sat Jun 20 09:12:51 2009 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 17B121065675; Sat, 20 Jun 2009 09:12:51 +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 B92D18FC2A; Sat, 20 Jun 2009 09:12:50 +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.3/8.14.3) with ESMTP id n5K9CmD0003419; Sat, 20 Jun 2009 05:12:48 -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.3/8.14.3) with ESMTP id n5K9CmxW015886; Sat, 20 Jun 2009 05:12:48 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 58CBD7302F; Sat, 20 Jun 2009 05:12:48 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090620091248.58CBD7302F@freebsd-current.sentex.ca> Date: Sat, 20 Jun 2009 05:12:48 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp1.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 205.211.164.50 Cc: Subject: [head tinderbox] failure on arm/arm 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: Sat, 20 Jun 2009 09:12:51 -0000 TB --- 2009-06-20 08:00:01 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-06-20 08:00:01 - starting HEAD tinderbox run for arm/arm TB --- 2009-06-20 08:00:01 - cleaning the object tree TB --- 2009-06-20 08:00:34 - cvsupping the source tree TB --- 2009-06-20 08:00:34 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/arm/arm/supfile TB --- 2009-06-20 08:00:44 - building world TB --- 2009-06-20 08:00:44 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-20 08:00:44 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-20 08:00:44 - TARGET=arm TB --- 2009-06-20 08:00:44 - TARGET_ARCH=arm TB --- 2009-06-20 08:00:44 - TZ=UTC TB --- 2009-06-20 08:00:44 - __MAKE_CONF=/dev/null TB --- 2009-06-20 08:00:44 - cd /src TB --- 2009-06-20 08:00:44 - /usr/bin/make -B buildworld >>> World build started on Sat Jun 20 08:00:46 UTC 2009 >>> 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 [...] cc -O -pipe -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/newsyslog/ptimes.c cc -O -pipe -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -o newsyslog newsyslog.o ptimes.o gzip -cn /src/usr.sbin/newsyslog/newsyslog.8 > newsyslog.8.gz gzip -cn /src/usr.sbin/newsyslog/newsyslog.conf.5 > newsyslog.conf.5.gz ===> usr.sbin/nfscbd (all) cc -O -pipe -std=gnu99 -c /src/usr.sbin/nfscbd/nfscbd.c In file included from /src/usr.sbin/nfscbd/nfscbd.c:50: /obj/arm/src/tmp/usr/include/fs/nfs/nfs.h:413: error: 'RPCAUTH_UNIXGIDS' undeclared here (not in a function) *** Error code 1 Stop in /src/usr.sbin/nfscbd. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-20 09:12:48 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-20 09:12:48 - ERROR: failed to build world TB --- 2009-06-20 09:12:48 - 3030.41 user 373.41 system 4367.23 real http://tinderbox.des.no/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Sat Jun 20 09:27:32 2009 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 BB534106564A for ; Sat, 20 Jun 2009 09:27:32 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from ch-smtp01.sth.basefarm.net (ch-smtp01.sth.basefarm.net [80.76.149.212]) by mx1.freebsd.org (Postfix) with ESMTP id 7834E8FC12 for ; Sat, 20 Jun 2009 09:27:32 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from c83-253-252-234.bredband.comhem.se ([83.253.252.234]:43476 helo=mx.exscape.org) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.69) (envelope-from ) id 1MHwrB-0005g6-4O for freebsd-current@freebsd.org; Sat, 20 Jun 2009 11:27:31 +0200 Received: from [192.168.1.5] (macbookpro [192.168.1.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx.exscape.org (Postfix) with ESMTPSA id A0A4838768 for ; Sat, 20 Jun 2009 11:27:29 +0200 (CEST) Message-Id: <462E2000-6856-46A7-B89C-03F9CE398F5E@exscape.org> From: Thomas Backman To: FreeBSD current Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sat, 20 Jun 2009 11:27:27 +0200 X-Mailer: Apple Mail (2.935.3) X-Originating-IP: 83.253.252.234 X-Scan-Result: No virus found in message 1MHwrB-0005g6-4O. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1MHwrB-0005g6-4O 98b2b60736522adf2bb278314d59d54f Subject: smartmontools/smartctl regression - CAMGETPASSTHRU ioctl failed 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, 20 Jun 2009 09:27:33 -0000 I know there have been some recent changes in the area (although TBH I don't know what CAM is, so...). It used to work a few weeks ago when I last checked, but now I get this: # smartctl -A /dev/da0 smartctl version 5.38 [amd64-portbld-freebsd8.0] Copyright (C) 2002-8 Bruce Allen Home page is http://smartmontools.sourceforge.net/ smartctl: cam_lookup_pass: CAMGETPASSTHRU ioctl failed cam_lookup_pass: No such file or directory cam_lookup_pass: either the pass driver isn't in your kernel cam_lookup_pass: or da0 doesn't exist Standard Inquiry (36 bytes) failed [Operation not permitted] Retrying with a 64 byte Standard Inquiry smartctl: cam_lookup_pass: CAMGETPASSTHRU ioctl failed cam_lookup_pass: No such file or directory cam_lookup_pass: either the pass driver isn't in your kernel cam_lookup_pass: or da0 doesn't exist Standard Inquiry (64 bytes) failed [Operation not permitted] A mandatory SMART command failed: exiting. To continue, add one or more '-T permissive' options. --------------- A rebuild of smartmontools did nothing. Am I missing a kernel option or something? I'm running GENERIC plus DTRACE minus WITNESS/ INVARIANTS, no other changes. Regards, Thomas From owner-freebsd-current@FreeBSD.ORG Sat Jun 20 09:28:02 2009 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 DA65B106568F; Sat, 20 Jun 2009 09:28:02 +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 884688FC17; Sat, 20 Jun 2009 09:28:02 +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.3/8.14.3) with ESMTP id n5K9S02C005502; Sat, 20 Jun 2009 05:28:00 -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.3/8.14.3) with ESMTP id n5K9S0hN024617; Sat, 20 Jun 2009 05:28:00 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 285737302F; Sat, 20 Jun 2009 05:28:00 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090620092800.285737302F@freebsd-current.sentex.ca> Date: Sat, 20 Jun 2009 05:28:00 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp1.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 205.211.164.50 Cc: Subject: [head tinderbox] failure on amd64/amd64 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: Sat, 20 Jun 2009 09:28:03 -0000 TB --- 2009-06-20 08:00:01 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-06-20 08:00:01 - starting HEAD tinderbox run for amd64/amd64 TB --- 2009-06-20 08:00:01 - cleaning the object tree TB --- 2009-06-20 08:00:33 - cvsupping the source tree TB --- 2009-06-20 08:00:33 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/amd64/amd64/supfile TB --- 2009-06-20 08:00:42 - building world TB --- 2009-06-20 08:00:42 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-20 08:00:42 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-20 08:00:42 - TARGET=amd64 TB --- 2009-06-20 08:00:42 - TARGET_ARCH=amd64 TB --- 2009-06-20 08:00:42 - TZ=UTC TB --- 2009-06-20 08:00:42 - __MAKE_CONF=/dev/null TB --- 2009-06-20 08:00:42 - cd /src TB --- 2009-06-20 08:00:42 - /usr/bin/make -B buildworld >>> World build started on Sat Jun 20 08:00:45 UTC 2009 >>> 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 [...] cc -O2 -pipe -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/newsyslog/ptimes.c cc -O2 -pipe -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -o newsyslog newsyslog.o ptimes.o gzip -cn /src/usr.sbin/newsyslog/newsyslog.8 > newsyslog.8.gz gzip -cn /src/usr.sbin/newsyslog/newsyslog.conf.5 > newsyslog.conf.5.gz ===> usr.sbin/nfscbd (all) cc -O2 -pipe -std=gnu99 -fstack-protector -c /src/usr.sbin/nfscbd/nfscbd.c In file included from /src/usr.sbin/nfscbd/nfscbd.c:50: /obj/amd64/src/tmp/usr/include/fs/nfs/nfs.h:413: error: 'RPCAUTH_UNIXGIDS' undeclared here (not in a function) *** Error code 1 Stop in /src/usr.sbin/nfscbd. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-20 09:27:59 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-20 09:27:59 - ERROR: failed to build world TB --- 2009-06-20 09:27:59 - 3851.89 user 387.56 system 5278.89 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Sat Jun 20 10:32:07 2009 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 9AF2E106566C; Sat, 20 Jun 2009 10:32:07 +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 45E888FC16; Sat, 20 Jun 2009 10:32:07 +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.3/8.14.3) with ESMTP id n5KAW4Wo050114; Sat, 20 Jun 2009 06:32:05 -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 n5KAW4k6017108; Sat, 20 Jun 2009 06:32:04 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 9929E7302F; Sat, 20 Jun 2009 06:32:04 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090620103204.9929E7302F@freebsd-current.sentex.ca> Date: Sat, 20 Jun 2009 06:32:04 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp2.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on i386/i386 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: Sat, 20 Jun 2009 10:32:08 -0000 TB --- 2009-06-20 09:12:48 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-06-20 09:12:48 - starting HEAD tinderbox run for i386/i386 TB --- 2009-06-20 09:12:48 - cleaning the object tree TB --- 2009-06-20 09:13:17 - cvsupping the source tree TB --- 2009-06-20 09:13:17 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/i386/supfile TB --- 2009-06-20 09:13:24 - building world TB --- 2009-06-20 09:13:24 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-20 09:13:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-20 09:13:24 - TARGET=i386 TB --- 2009-06-20 09:13:24 - TARGET_ARCH=i386 TB --- 2009-06-20 09:13:24 - TZ=UTC TB --- 2009-06-20 09:13:24 - __MAKE_CONF=/dev/null TB --- 2009-06-20 09:13:24 - cd /src TB --- 2009-06-20 09:13:24 - /usr/bin/make -B buildworld >>> World build started on Sat Jun 20 09:13:26 UTC 2009 >>> 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 [...] cc -O2 -pipe -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/newsyslog/ptimes.c cc -O2 -pipe -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -o newsyslog newsyslog.o ptimes.o gzip -cn /src/usr.sbin/newsyslog/newsyslog.8 > newsyslog.8.gz gzip -cn /src/usr.sbin/newsyslog/newsyslog.conf.5 > newsyslog.conf.5.gz ===> usr.sbin/nfscbd (all) cc -O2 -pipe -std=gnu99 -fstack-protector -c /src/usr.sbin/nfscbd/nfscbd.c In file included from /src/usr.sbin/nfscbd/nfscbd.c:50: /obj/src/tmp/usr/include/fs/nfs/nfs.h:413: error: 'RPCAUTH_UNIXGIDS' undeclared here (not in a function) *** Error code 1 Stop in /src/usr.sbin/nfscbd. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-20 10:32:04 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-20 10:32:04 - ERROR: failed to build world TB --- 2009-06-20 10:32:04 - 3788.11 user 366.92 system 4755.87 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Sat Jun 20 10:52:53 2009 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 1537C106566C; Sat, 20 Jun 2009 10:52:53 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.27]) by mx1.freebsd.org (Postfix) with ESMTP id C8D798FC1B; Sat, 20 Jun 2009 10:52:52 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from [62.143.132.243] (helo=localhost) by smtprelay04.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1MHxvq-00085n-OJ; Sat, 20 Jun 2009 12:36:24 +0200 Date: Sat, 20 Jun 2009 12:36:57 +0200 From: Fabian Keil To: Jeff Roberson Message-ID: <20090620123657.21728020@fabiankeil.de> In-Reply-To: References: X-Mailer: Claws Mail 3.7.1 (GTK+ 2.16.2; i386-portbld-freebsd8.0) X-PGP-KEY-URL: http://www.fabiankeil.de/gpg-keys/freebsd-listen-2008-08-18.asc Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Df-Sender: 775067 Cc: current@freebsd.org, net@freebsd.org Subject: Re: mbuf layout optimizations 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, 20 Jun 2009 10:52:53 -0000 Jeff Roberson wrote: > http://people.freebsd.org/~jeff/mbuf2.diff > This is a call for testers and feedback on my mbuf layout improvements. > I'm trying to decide whether I will push to have these included in 8.0. > After reducing the scope slightly from my last patch, I have not > encountered any problems. Kip Macy has also been using it for the past > few weeks without issue. > > You should not expect any functional changes from this patch. The goal > is mostly to pave the way fors more sensible mbuf handling in the > future, although it does offer a few performance benefits. So far I haven't been able to reproduce the em-related panic I reported with an earlier version of the patch. I'm not sure if it was reproducible back then, though. Fabian From owner-freebsd-current@FreeBSD.ORG Sat Jun 20 12:29:11 2009 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 58B691065676; Sat, 20 Jun 2009 12:29:11 +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 187358FC1C; Sat, 20 Jun 2009 12:29:10 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id n5KCT8Yj061080; Sat, 20 Jun 2009 08:29:08 -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.3/8.14.3) with ESMTP id n5KCT8po026437; Sat, 20 Jun 2009 08:29:08 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 665257302F; Sat, 20 Jun 2009 08:29:08 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090620122908.665257302F@freebsd-current.sentex.ca> Date: Sat, 20 Jun 2009 08:29:08 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp1.sentex.ca 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: Sat, 20 Jun 2009 12:29:12 -0000 TB --- 2009-06-20 10:32:04 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-06-20 10:32:04 - starting HEAD tinderbox run for ia64/ia64 TB --- 2009-06-20 10:32:04 - cleaning the object tree TB --- 2009-06-20 10:32:28 - cvsupping the source tree TB --- 2009-06-20 10:32:28 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/ia64/ia64/supfile TB --- 2009-06-20 10:32:35 - building world TB --- 2009-06-20 10:32:35 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-20 10:32:35 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-20 10:32:35 - TARGET=ia64 TB --- 2009-06-20 10:32:35 - TARGET_ARCH=ia64 TB --- 2009-06-20 10:32:35 - TZ=UTC TB --- 2009-06-20 10:32:35 - __MAKE_CONF=/dev/null TB --- 2009-06-20 10:32:35 - cd /src TB --- 2009-06-20 10:32:35 - /usr/bin/make -B buildworld >>> World build started on Sat Jun 20 10:32:38 UTC 2009 >>> 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 Sat Jun 20 12:21:39 UTC 2009 TB --- 2009-06-20 12:21:39 - generating LINT kernel config TB --- 2009-06-20 12:21:39 - cd /src/sys/ia64/conf TB --- 2009-06-20 12:21:39 - /usr/bin/make -B LINT TB --- 2009-06-20 12:21:39 - building LINT kernel TB --- 2009-06-20 12:21:39 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-20 12:21:39 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-20 12:21:39 - TARGET=ia64 TB --- 2009-06-20 12:21:39 - TARGET_ARCH=ia64 TB --- 2009-06-20 12:21:39 - TZ=UTC TB --- 2009-06-20 12:21:39 - __MAKE_CONF=/dev/null TB --- 2009-06-20 12:21:39 - cd /src TB --- 2009-06-20 12:21:39 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Jun 20 12:21:39 UTC 2009 >>> 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 [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/cxgb/cxgb_offload.c -I/src/sys/dev/cxgb cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/cxgb/cxgb_sge.c -I/src/sys/dev/cxgb In file included from /src/sys/dev/cxgb/cxgb_sge.c:68: /src/sys/dev/cxgb/sys/mvec.h: In function 'busdma_map_mbuf_fast': /src/sys/dev/cxgb/sys/mvec.h:55: error: dereferencing pointer to incomplete type cc1: warnings being treated as errors /src/sys/dev/cxgb/cxgb_sge.c: In function 'refill_fl': /src/sys/dev/cxgb/cxgb_sge.c:714: warning: suggest parentheses around assignment used as truth value *** Error code 1 Stop in /obj/ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-20 12:29:08 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-20 12:29:08 - ERROR: failed to build lint kernel TB --- 2009-06-20 12:29:08 - 5720.57 user 431.62 system 7023.45 real http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Sat Jun 20 13:03:50 2009 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 9B1E51065672 for ; Sat, 20 Jun 2009 13:03:50 +0000 (UTC) (envelope-from spambox@haruhiism.net) Received: from fujibayashi.jp (karas.fujibayashi.jp [77.221.159.4]) by mx1.freebsd.org (Postfix) with ESMTP id 56E1D8FC08 for ; Sat, 20 Jun 2009 13:03:50 +0000 (UTC) (envelope-from spambox@haruhiism.net) Received: from [192.168.0.10] (datacenter.telecombusinessconsulting.net [77.221.137.211]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by fujibayashi.jp (Postfix) with ESMTPSA id 0738E78F86 for ; Fri, 19 Jun 2009 11:46:32 +0400 (MSD) Message-ID: <4A3B4260.6070200@haruhiism.net> Date: Fri, 19 Jun 2009 11:46:40 +0400 From: Kamigishi Rei User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 20 Jun 2009 13:15:32 +0000 Subject: Following vm_lowmem event handler for dirhash 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, 20 Jun 2009 13:03:50 -0000 Hello, hope you're having a nice day, Following http://lists.freebsd.org/pipermail/freebsd-current/2009-May/007367.html > It adds a vm_lowmem event handler to the dirhash code in UFS2 > so that dirhashes will be deleted when the system is low on memory. From what I gather, this patch is in -CURRENT now; I've updated to -CURRENT 3 days ago (after using a snapshot from May) and my previously stable system threw a kernel panic yesterday. Panic happened during a benchmark on my ZFS pool (bonnie++ -s 32768) supposedly because of that exact patch (because ZFS is known to eat a lot of kmem and vm_lowmem was probably triggered). Alas, I don't have a dump available (because my system boots from a geom mirror and the swap space is there as well), so I only have the panic message: "dirhash: NULL hash on list". My system is a Core2 Duo on a Q35 motherboard, using 2GB RAM and 4x 500GB drives, of which 2 are in a GEOM_MIRROR and the other 2 are in a zpool. fujibayashi@ameagari ~ % uname -a FreeBSD ameagari.fujibayashi.jp 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Tue Jun 16 21:50:53 JST 2009 root@ameagari.fujibayashi.jp:/usr/obj/usr/src/sys/Ameagari amd64 (Last line in /usr/src/UPDATING states "20090613".) -- Kamigishi Rei Systems Administrator WIDE From owner-freebsd-current@FreeBSD.ORG Sat Jun 20 14:01:06 2009 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 90D3A106567A; Sat, 20 Jun 2009 14:01:06 +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 669128FC29; Sat, 20 Jun 2009 14:01:06 +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.3/8.14.3) with ESMTP id n5KE13qu071260; Sat, 20 Jun 2009 10:01:03 -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 n5KE13l3075992; Sat, 20 Jun 2009 10:01:03 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 091467302F; Sat, 20 Jun 2009 10:01:02 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090620140103.091467302F@freebsd-current.sentex.ca> Date: Sat, 20 Jun 2009 10:01:02 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp2.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 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: Sat, 20 Jun 2009 14:01:07 -0000 TB --- 2009-06-20 12:29:08 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-06-20 12:29:08 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2009-06-20 12:29:08 - cleaning the object tree TB --- 2009-06-20 12:29:29 - cvsupping the source tree TB --- 2009-06-20 12:29:29 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2009-06-20 12:29:39 - building world TB --- 2009-06-20 12:29:39 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-20 12:29:39 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-20 12:29:39 - TARGET=powerpc TB --- 2009-06-20 12:29:39 - TARGET_ARCH=powerpc TB --- 2009-06-20 12:29:39 - TZ=UTC TB --- 2009-06-20 12:29:39 - __MAKE_CONF=/dev/null TB --- 2009-06-20 12:29:39 - cd /src TB --- 2009-06-20 12:29:39 - /usr/bin/make -B buildworld >>> World build started on Sat Jun 20 12:29:43 UTC 2009 >>> 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 Sat Jun 20 13:55:17 UTC 2009 TB --- 2009-06-20 13:55:17 - generating LINT kernel config TB --- 2009-06-20 13:55:17 - cd /src/sys/powerpc/conf TB --- 2009-06-20 13:55:17 - /usr/bin/make -B LINT TB --- 2009-06-20 13:55:17 - building LINT kernel TB --- 2009-06-20 13:55:17 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-20 13:55:17 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-20 13:55:17 - TARGET=powerpc TB --- 2009-06-20 13:55:17 - TARGET_ARCH=powerpc TB --- 2009-06-20 13:55:17 - TZ=UTC TB --- 2009-06-20 13:55:17 - __MAKE_CONF=/dev/null TB --- 2009-06-20 13:55:17 - cd /src TB --- 2009-06-20 13:55:17 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Jun 20 13:55:17 UTC 2009 >>> 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 [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/cxgb/cxgb_offload.c -I/src/sys/dev/cxgb cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/cxgb/cxgb_sge.c -I/src/sys/dev/cxgb In file included from /src/sys/dev/cxgb/cxgb_sge.c:68: /src/sys/dev/cxgb/sys/mvec.h: In function 'busdma_map_mbuf_fast': /src/sys/dev/cxgb/sys/mvec.h:55: error: dereferencing pointer to incomplete type cc1: warnings being treated as errors /src/sys/dev/cxgb/cxgb_sge.c: In function 'refill_fl': /src/sys/dev/cxgb/cxgb_sge.c:714: warning: suggest parentheses around assignment used as truth value *** Error code 1 Stop in /obj/powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-20 14:01:02 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-20 14:01:02 - ERROR: failed to build lint kernel TB --- 2009-06-20 14:01:02 - 4334.57 user 413.45 system 5514.22 real http://tinderbox.des.no/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sat Jun 20 14:13:45 2009 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 354F21065672; Sat, 20 Jun 2009 14:13:45 +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 0B2AF8FC0A; Sat, 20 Jun 2009 14:13:44 +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.3/8.14.3) with ESMTP id n5KEDhsm072466; Sat, 20 Jun 2009 10:13:43 -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 n5KEDgMZ005102; Sat, 20 Jun 2009 10:13:42 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id D2FBF7302F; Sat, 20 Jun 2009 10:13:42 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090620141342.D2FBF7302F@freebsd-current.sentex.ca> Date: Sat, 20 Jun 2009 10:13:42 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp2.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on sparc64/sparc64 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: Sat, 20 Jun 2009 14:13:45 -0000 TB --- 2009-06-20 12:46:12 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-06-20 12:46:12 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2009-06-20 12:46:12 - cleaning the object tree TB --- 2009-06-20 12:46:40 - cvsupping the source tree TB --- 2009-06-20 12:46:40 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2009-06-20 12:46:47 - building world TB --- 2009-06-20 12:46:47 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-20 12:46:47 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-20 12:46:47 - TARGET=sparc64 TB --- 2009-06-20 12:46:47 - TARGET_ARCH=sparc64 TB --- 2009-06-20 12:46:47 - TZ=UTC TB --- 2009-06-20 12:46:47 - __MAKE_CONF=/dev/null TB --- 2009-06-20 12:46:47 - cd /src TB --- 2009-06-20 12:46:47 - /usr/bin/make -B buildworld >>> World build started on Sat Jun 20 12:46:48 UTC 2009 >>> 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 Sat Jun 20 14:07:55 UTC 2009 TB --- 2009-06-20 14:07:55 - generating LINT kernel config TB --- 2009-06-20 14:07:55 - cd /src/sys/sparc64/conf TB --- 2009-06-20 14:07:55 - /usr/bin/make -B LINT TB --- 2009-06-20 14:07:55 - building LINT kernel TB --- 2009-06-20 14:07:55 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-20 14:07:55 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-20 14:07:55 - TARGET=sparc64 TB --- 2009-06-20 14:07:55 - TARGET_ARCH=sparc64 TB --- 2009-06-20 14:07:55 - TZ=UTC TB --- 2009-06-20 14:07:55 - __MAKE_CONF=/dev/null TB --- 2009-06-20 14:07:55 - cd /src TB --- 2009-06-20 14:07:55 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Jun 20 14:07:55 UTC 2009 >>> 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 [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/cxgb/cxgb_offload.c -I/src/sys/dev/cxgb cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/cxgb/cxgb_sge.c -I/src/sys/dev/cxgb In file included from /src/sys/dev/cxgb/cxgb_sge.c:68: /src/sys/dev/cxgb/sys/mvec.h: In function 'busdma_map_mbuf_fast': /src/sys/dev/cxgb/sys/mvec.h:55: error: dereferencing pointer to incomplete type cc1: warnings being treated as errors /src/sys/dev/cxgb/cxgb_sge.c: In function 'refill_fl': /src/sys/dev/cxgb/cxgb_sge.c:714: warning: suggest parentheses around assignment used as truth value *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-20 14:13:42 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-20 14:13:42 - ERROR: failed to build lint kernel TB --- 2009-06-20 14:13:42 - 4095.05 user 404.23 system 5250.18 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Sat Jun 20 15:06:08 2009 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 C75031065674 for ; Sat, 20 Jun 2009 15:06:08 +0000 (UTC) (envelope-from matheusber@gmail.com) Received: from mail-gx0-f207.google.com (mail-gx0-f207.google.com [209.85.217.207]) by mx1.freebsd.org (Postfix) with ESMTP id 791FC8FC14 for ; Sat, 20 Jun 2009 15:06:08 +0000 (UTC) (envelope-from matheusber@gmail.com) Received: by gxk3 with SMTP id 3so3413522gxk.19 for ; Sat, 20 Jun 2009 08:06:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:received:received :message-id:date:subject:from:to:user-agent:mime-version :content-type:content-transfer-encoding:x-priority:importance; bh=P/gpCErN+FrhM9YViruT64C/P9qUkfXV4oRyrLrZKVg=; b=MMerI6NXxeUaAjWJ0LghfpVDfMM7uKRxZi0n7uS1to617ixDNBvqDmjrZVk4Sbjo0I oX60RUZRtxd/5LOuiMTVPr4UcqOmtfv4rCHiIIUDEp63WrM6sC5L6yq3R/mk+60UnbOR VcYDpl81wsOikA/JmNQBNOn65i7fMBffWZjkk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:subject:from:to:user-agent:mime-version :content-type:content-transfer-encoding:x-priority:importance; b=whP+w5EbAkHEeO5QlQKXZYggbtbQbdvNZ+YsbzYDCHm9vMTWpUPW+A89OuE2Osj/4g CbgU52Uh0K8mwkiEwKOP2974LnP5dA9C32h8ebRG6iS8nLuoDCxDbUPO/aYoOKBeLJVR DqVBDmwoyrbX5gEMDoKryIV0/iQTyOcTQPClk= Received: by 10.151.69.9 with SMTP id w9mr7816620ybk.29.1245510366420; Sat, 20 Jun 2009 08:06:06 -0700 (PDT) Received: from cygnus.homeunix.com ([189.71.105.194]) by mx.google.com with ESMTPS id 7sm147486ywo.36.2009.06.20.08.06.04 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 20 Jun 2009 08:06:05 -0700 (PDT) Sender: Nenhum_de_Nos Received: by cygnus.homeunix.com (Postfix, from userid 80) id E57DDB8083; Sat, 20 Jun 2009 12:06:00 -0300 (BRT) Received: from 189.93.32.75 (SquirrelMail authenticated user matheus) by cygnus.homeunix.com with HTTP; Sat, 20 Jun 2009 12:06:00 -0300 (BRT) Message-ID: <9ccd6cc4824b70cd9316ad9490dfd932.squirrel@cygnus.homeunix.com> Date: Sat, 20 Jun 2009 12:06:00 -0300 (BRT) From: "Nenhum_de_Nos" To: freebsd-current@freebsd.org User-Agent: SquirrelMail/1.4.15 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: tinybsd can't compile custom kernel 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, 20 Jun 2009 15:06:09 -0000 hail, I'm trying to compile tinybsd for a firewall. I copied firewall dir under conf to cygnus. edited and tried to compile. It was ok till kernel compilation: ===> Chrooted make in /usr/obj/tinybsdbuild succeeded ===> Cleaning up... ===> Cleaning for autoconf-2.62 ===> Cleaning for expat-2.0.1 ===> Cleaning for pcre-7.9 ===> Cleaning for libiconv-1.13 ===> Cleaning for m4-1.4.13,1 ===> Cleaning for help2man-1.36.4_3 ===> Cleaning for gmake-3.81_3 ===> Cleaning for autoconf-wrapper-20071109 ===> Cleaning for p5-gettext-1.05_2 ===> Cleaning for gettext-0.17_1 ===> Cleaning for apache-2.2.11_7 =====> Building customized tiny beastie kernel... ERROR: Missing kernel configuration file(s) (TINYBSD). *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. in conf/cygnus there is TINYBSD file and cygnus file. the tinybsd command line ask for kernel conf file. there I type cygnus. [root@darkside /usr/src/tools/tools/tinybsd/conf]# ls -l cygnus/ total 24 -rw-r--r-- 1 root wheel 6361 Jun 19 22:32 TINYBSD -rw-r--r-- 1 root wheel 6361 Jun 20 01:15 cygnus drwxr-xr-x 3 root wheel 512 Feb 13 13:10 etc -rw-r--r-- 1 root wheel 3799 Jun 25 2007 tinybsd.basefiles -rw-r--r-- 1 root wheel 473 Jun 19 22:42 tinybsd.ports [root@darkside /usr/src/tools/tools/tinybsd/conf]# I followed http://www.tinybsd.org/tinybsd/Documentation. also, is there a way to save all choices from ports build ? and the curses menu don't work ok for choosing. is this the way was supposed to be ? thanks, matheus -- We will call you cygnus, The God of balance you shall be A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? http://en.wikipedia.org/wiki/Posting_style From owner-freebsd-current@FreeBSD.ORG Sat Jun 20 15:20:13 2009 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 37C031065670; Sat, 20 Jun 2009 15:20:13 +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 0E81C8FC19; Sat, 20 Jun 2009 15:20:12 +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.3/8.14.3) with ESMTP id n5KFKAxM044268; Sat, 20 Jun 2009 11:20:11 -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.3/8.14.3) with ESMTP id n5KFKARY033253; Sat, 20 Jun 2009 11:20:10 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id C14E17302F; Sat, 20 Jun 2009 11:20:10 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090620152010.C14E17302F@freebsd-current.sentex.ca> Date: Sat, 20 Jun 2009 11:20:10 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp1.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 205.211.164.50 Cc: Subject: [head tinderbox] failure on sparc64/sun4v 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: Sat, 20 Jun 2009 15:20:14 -0000 TB --- 2009-06-20 14:01:03 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-06-20 14:01:03 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2009-06-20 14:01:03 - cleaning the object tree TB --- 2009-06-20 14:01:27 - cvsupping the source tree TB --- 2009-06-20 14:01:27 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2009-06-20 14:01:34 - building world TB --- 2009-06-20 14:01:34 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-20 14:01:34 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-20 14:01:34 - TARGET=sun4v TB --- 2009-06-20 14:01:34 - TARGET_ARCH=sparc64 TB --- 2009-06-20 14:01:34 - TZ=UTC TB --- 2009-06-20 14:01:34 - __MAKE_CONF=/dev/null TB --- 2009-06-20 14:01:34 - cd /src TB --- 2009-06-20 14:01:34 - /usr/bin/make -B buildworld >>> World build started on Sat Jun 20 14:01:36 UTC 2009 >>> 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 Sat Jun 20 15:15:03 UTC 2009 TB --- 2009-06-20 15:15:03 - generating LINT kernel config TB --- 2009-06-20 15:15:03 - cd /src/sys/sun4v/conf TB --- 2009-06-20 15:15:03 - /usr/bin/make -B LINT TB --- 2009-06-20 15:15:03 - building LINT kernel TB --- 2009-06-20 15:15:03 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-20 15:15:03 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-20 15:15:03 - TARGET=sun4v TB --- 2009-06-20 15:15:03 - TARGET_ARCH=sparc64 TB --- 2009-06-20 15:15:03 - TZ=UTC TB --- 2009-06-20 15:15:03 - __MAKE_CONF=/dev/null TB --- 2009-06-20 15:15:03 - cd /src TB --- 2009-06-20 15:15:03 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Jun 20 15:15:03 UTC 2009 >>> 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 [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/cxgb/cxgb_offload.c -I/src/sys/dev/cxgb cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/cxgb/cxgb_sge.c -I/src/sys/dev/cxgb In file included from /src/sys/dev/cxgb/cxgb_sge.c:68: /src/sys/dev/cxgb/sys/mvec.h: In function 'busdma_map_mbuf_fast': /src/sys/dev/cxgb/sys/mvec.h:55: error: dereferencing pointer to incomplete type cc1: warnings being treated as errors /src/sys/dev/cxgb/cxgb_sge.c: In function 'refill_fl': /src/sys/dev/cxgb/cxgb_sge.c:714: warning: suggest parentheses around assignment used as truth value *** Error code 1 Stop in /obj/sun4v/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-20 15:20:10 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-20 15:20:10 - ERROR: failed to build lint kernel TB --- 2009-06-20 15:20:10 - 4093.47 user 405.45 system 4747.65 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Sat Jun 20 15:42:12 2009 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 A77CA106564A for ; Sat, 20 Jun 2009 15:42:12 +0000 (UTC) (envelope-from matheusber@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.31]) by mx1.freebsd.org (Postfix) with ESMTP id 576998FC1C for ; Sat, 20 Jun 2009 15:42:12 +0000 (UTC) (envelope-from matheusber@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so1044874ywe.13 for ; Sat, 20 Jun 2009 08:42:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:received:received :message-id:in-reply-to:references:date:subject:from:to:user-agent :mime-version:content-type:content-transfer-encoding:x-priority :importance; bh=qkqRIq3xk7JOcUqNkUy5fWJ42rAyhVOrDDydhogFV+4=; b=EHF9fetxMFTJ/OppoopX8PuBLxXpbvfWeqQpsvZi8R4bw41LkpnXV7U17QdOpQ/2kJ Gc+jdtq5fduT6+CoE/ZQoRADd06f/T2zQc2oSj4yBChjlxyVAwNf2efVjY7MSFEGLc3w uf4kvM5iNKY/6Yq68/vk7X1xDi21bSjB+5S+o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:in-reply-to:references:date:subject:from:to :user-agent:mime-version:content-type:content-transfer-encoding :x-priority:importance; b=Tsngmolx1y3QumM7wKnhoqWfVmMH5tH82VcvYiD9jarujJHY9w68LC0Rnb+Bl2+/eb R0G9tqooVAHtEGHFBjafGdRAmCWb+6dLwc/iehrfOn8ZAa7XoWfRtnAolNsmK1NXLY67 wPVsfpl8clzaUFqEwNuITrUq8HIbnn6+R7+24= Received: by 10.151.121.12 with SMTP id y12mr7885665ybm.123.1245512531836; Sat, 20 Jun 2009 08:42:11 -0700 (PDT) Received: from cygnus.homeunix.com ([189.71.105.194]) by mx.google.com with ESMTPS id 8sm351214ywg.35.2009.06.20.08.42.10 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 20 Jun 2009 08:42:10 -0700 (PDT) Sender: Nenhum_de_Nos Received: by cygnus.homeunix.com (Postfix, from userid 80) id 32437B8083; Sat, 20 Jun 2009 12:42:06 -0300 (BRT) Received: from 189.93.32.75 (SquirrelMail authenticated user matheus) by cygnus.homeunix.com with HTTP; Sat, 20 Jun 2009 12:42:06 -0300 (BRT) Message-ID: <9ca40c9e2ad6e868fcbe6692e248ee13.squirrel@cygnus.homeunix.com> In-Reply-To: <9ccd6cc4824b70cd9316ad9490dfd932.squirrel@cygnus.homeunix.com> References: <9ccd6cc4824b70cd9316ad9490dfd932.squirrel@cygnus.homeunix.com> Date: Sat, 20 Jun 2009 12:42:06 -0300 (BRT) From: "Nenhum_de_Nos" To: freebsd-current@freebsd.org User-Agent: SquirrelMail/1.4.15 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: Re: tinybsd can't compile custom kernel 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, 20 Jun 2009 15:42:13 -0000 On Sat, June 20, 2009 12:06, Nenhum_de_Nos wrote: > hail, > > I'm trying to compile tinybsd for a firewall. I copied firewall dir under > conf to cygnus. edited and tried to compile. > > It was ok till kernel compilation: > > ===> Chrooted make in /usr/obj/tinybsdbuild succeeded > ===> Cleaning up... > ===> Cleaning for autoconf-2.62 > ===> Cleaning for expat-2.0.1 > ===> Cleaning for pcre-7.9 > ===> Cleaning for libiconv-1.13 > ===> Cleaning for m4-1.4.13,1 > ===> Cleaning for help2man-1.36.4_3 > ===> Cleaning for gmake-3.81_3 > ===> Cleaning for autoconf-wrapper-20071109 > ===> Cleaning for p5-gettext-1.05_2 > ===> Cleaning for gettext-0.17_1 > ===> Cleaning for apache-2.2.11_7 > =====> Building customized tiny beastie kernel... > ERROR: Missing kernel configuration file(s) (TINYBSD). > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > > in conf/cygnus there is TINYBSD file and cygnus file. the tinybsd command > line ask for kernel conf file. there I type cygnus. > > [root@darkside /usr/src/tools/tools/tinybsd/conf]# ls -l cygnus/ > total 24 > -rw-r--r-- 1 root wheel 6361 Jun 19 22:32 TINYBSD > -rw-r--r-- 1 root wheel 6361 Jun 20 01:15 cygnus > drwxr-xr-x 3 root wheel 512 Feb 13 13:10 etc > -rw-r--r-- 1 root wheel 3799 Jun 25 2007 tinybsd.basefiles > -rw-r--r-- 1 root wheel 473 Jun 19 22:42 tinybsd.ports > [root@darkside /usr/src/tools/tools/tinybsd/conf]# > > I followed http://www.tinybsd.org/tinybsd/Documentation. > > also, is there a way to save all choices from ports build ? and the curses > menu don't work ok for choosing. is this the way was supposed to be ? > > thanks, > > matheus is possible to compile i386 tinybsd on amd64 install ? FreeBSD darkside.apartnet 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Sun Jun 14 01:59:21 BRT 2009 root@darkside.apartnet:/usr/obj/usr/src/sys/Darkside8 amd64 thanks, matheus -- We will call you cygnus, The God of balance you shall be A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? http://en.wikipedia.org/wiki/Posting_style From owner-freebsd-current@FreeBSD.ORG Sat Jun 20 16:13:30 2009 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 E73E51065672 for ; Sat, 20 Jun 2009 16:13:30 +0000 (UTC) (envelope-from snb@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id BB6F88FC18; Sat, 20 Jun 2009 16:13:30 +0000 (UTC) (envelope-from snb@freebsd.org) Received: from ebi.local (snb@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n5KGDT9w074536; Sat, 20 Jun 2009 16:13:29 GMT (envelope-from snb@freebsd.org) Date: Sat, 20 Jun 2009 18:13:28 +0200 From: Nick Barkas To: Kamigishi Rei Message-ID: <20090620161252.GA2885@ebi.local> References: <4A3B4260.6070200@haruhiism.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A3B4260.6070200@haruhiism.net> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: freebsd-current@freebsd.org Subject: Re: Following vm_lowmem event handler for dirhash 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, 20 Jun 2009 16:13:31 -0000 On Fri, Jun 19, 2009 at 09:46:40AM +0200, Kamigishi Rei wrote: > Hello, hope you're having a nice day, > > Following > http://lists.freebsd.org/pipermail/freebsd-current/2009-May/007367.html > > > It adds a vm_lowmem event handler to the dirhash code in UFS2 > > so that dirhashes will be deleted when the system is low on memory. > From what I gather, this patch is in -CURRENT now; I've updated to > -CURRENT 3 days ago (after using a snapshot from May) and my previously > stable system threw a kernel panic yesterday. Panic happened during a > benchmark on my ZFS pool (bonnie++ -s 32768) supposedly because of that > exact patch (because ZFS is known to eat a lot of kmem and vm_lowmem was > probably triggered). Alas, I don't have a dump available (because my > system boots from a geom mirror and the swap space is there as well), so > I only have the panic message: "dirhash: NULL hash on list". You probably don't have the latest changes made to dirhash, which I committed in r194387 on the 17th of June. That fixed some problems introduced in my first commit with the vm_lowmem handler for dirhash a couple of weeks ago. Until this latest commit, it is possible that ufsdirhash_destroy(), which is where your "dirhash: NULL hash on list" message comes from, might be trying to destroy an already deleted dirhash. Please try updating your sources and build a new kernel to see if this problem comes up again. Nick > My system is a Core2 Duo on a Q35 motherboard, using 2GB RAM and 4x > 500GB drives, of which 2 are in a GEOM_MIRROR and the other 2 are in a > zpool. > > fujibayashi@ameagari ~ % uname -a > FreeBSD ameagari.fujibayashi.jp 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Tue > Jun 16 21:50:53 JST 2009 > root@ameagari.fujibayashi.jp:/usr/obj/usr/src/sys/Ameagari amd64 > > (Last line in /usr/src/UPDATING states "20090613".) > > -- > Kamigishi Rei > Systems Administrator > WIDE > _______________________________________________ > 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 Sat Jun 20 16:30:18 2009 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 11814106564A for ; Sat, 20 Jun 2009 16:30:18 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from ch-smtp01.sth.basefarm.net (ch-smtp01.sth.basefarm.net [80.76.149.212]) by mx1.freebsd.org (Postfix) with ESMTP id 981328FC0C for ; Sat, 20 Jun 2009 16:30:17 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from c83-253-252-234.bredband.comhem.se ([83.253.252.234]:33438 helo=mx.exscape.org) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.69) (envelope-from ) id 1MI3S0-00058n-3W for freebsd-current@freebsd.org; Sat, 20 Jun 2009 18:29:58 +0200 Received: from [192.168.1.5] (macbookpro [192.168.1.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx.exscape.org (Postfix) with ESMTPSA id C5F4218AD for ; Sat, 20 Jun 2009 18:29:53 +0200 (CEST) Message-Id: <668B820A-AAA7-4A40-8CF5-7DDCFDCD95FC@exscape.org> From: Thomas Backman To: FreeBSD current Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sat, 20 Jun 2009 18:29:51 +0200 X-Mailer: Apple Mail (2.935.3) X-Originating-IP: 83.253.252.234 X-Scan-Result: No virus found in message 1MI3S0-00058n-3W. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1MI3S0-00058n-3W a2b1f9dd313bd6239f2a980302855a88 Subject: DTrace "timestamp" wraps at about 2^33 (64-bit value)? 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, 20 Jun 2009 16:30:18 -0000 It appears the DTrace "timestamp" variable is wrapping around way, way too quickly - it only goes to somewhere slightly above 2^33 (in practice, at least), and since it's in nanoseconds, that's not a lot. (2^33 ns is less than 10 seconds, actually. 2^64 is 584.55 years, however!) # dtrace -n 'tick-500ms { trace(timestamp); }' dtrace: description 'tick-500ms ' matched 1 probe CPU ID FUNCTION:NAME 0 40770 :tick-500ms 8217926898 0 40770 :tick-500ms 8717920699 0 40770 :tick-500ms 37092920 0 40770 :tick-500ms 537090983 0 40770 :tick-500ms 1037086239 0 40770 :tick-500ms 1537081743 0 40770 :tick-500ms 2037075002 0 40770 :tick-500ms 2537073505 0 40770 :tick-500ms 3037066771 0 40770 :tick-500ms 3536065278 0 40770 :tick-500ms 4036058122 0 40770 :tick-500ms 4536056423 0 40770 :tick-500ms 5036049344 0 40770 :tick-500ms 5536047746 0 40770 :tick-500ms 6036041477 0 40770 :tick-500ms 6536039244 0 40770 :tick-500ms 7036033423 0 40770 :tick-500ms 7536030678 0 40770 :tick-500ms 8036025843 0 40770 :tick-500ms 8536020127 0 40770 :tick-500ms 9036012808 0 40770 :tick-500ms 355189205 0 40770 :tick-500ms 855182280 0 40770 :tick-500ms 1355180867 0 40770 :tick-500ms 1855173430 0 40770 :tick-500ms 2355172744 (From /usr/src/sys/cddl/dev/dtrace/amd64/dtrace_subr.c) /* * DTrace needs a high resolution time function which can * be called from a probe context and guaranteed not to have * instrumented with probes itself. * * Returns nanoseconds since boot. */ uint64_t dtrace_gethrtime() { return ((rdtsc() + tsc_skew[curcpu]) * (int64_t) 1000000000 / tsc_freq); } Is the function above really working as it should? (I'm assuming it's the function used to return the timestamp variable, here.) I ran into this in a more real-world example than tick, too: [root@chaos /]# dtrace -n 'syscall:::entry { self->pf = probefunc; self->ts = timestamp; } syscall:::return /self->ts/ { @a[self->pf] = quantize(timestamp - self->ts); }' dtrace: description 'syscall:::entry ' matched 1002 probes ^C select value ------------- Distribution ------------- count -8589934592 | 0 -4294967296 |@@ 4 -2147483648 | 0 -1073741824 | 0 -536870912 | 0 -268435456 | 0 ....... 1 | 0 2 | 0 4 | 0 8 | 0 16 | 0 32 | 0 64 | 0 128 | 0 256 | 0 512 | 0 1024 | 0 2048 |@@@@@@@ 15 4096 |@@@@@@@@@@@@@@ 29 8192 |@ 3 16384 | 0 32768 | 0 65536 |@@@ 7 131072 |@ 3 .... Also: [root@chaos /]# dtrace -n 'syscall:::entry { self->pf = probefunc; self->ts = timestamp; } syscall:::return /self->ts/ { @a[self->pf] = min(timestamp - self->ts); }' dtrace: description 'syscall:::entry ' matched 1002 probes ^C _umtx_op -8181214691 select -8179150768 sigprocmask 1470 fcntl 1567 lseek 1619 ... I doubt that select executes in -8.17 seconds. ;) Regards, Thomas From owner-freebsd-current@FreeBSD.ORG Sat Jun 20 15:26:51 2009 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 370801065673 for ; Sat, 20 Jun 2009 15:26:51 +0000 (UTC) (envelope-from craig001@lerwick.hopto.org) Received: from lerwick.hopto.org (81-178-20-70.dsl.pipex.com [81.178.20.70]) by mx1.freebsd.org (Postfix) with ESMTP id 70B208FC16 for ; Sat, 20 Jun 2009 15:26:50 +0000 (UTC) (envelope-from craig001@lerwick.hopto.org) Received: (qmail 47771 invoked by uid 98); 20 Jun 2009 16:30:16 +0100 Received: from 192.168.0.2 by polaris.lerwick.hopto.org (envelope-from , uid 82) with qmail-scanner-2.01 (clamdscan: 0.88.4/1789. hbedv: 7.1.1.11/6.35.1.178. f-prot: 4.6.6/3.16.14. spamassassin: 3.1.4. Clear:RC:1(192.168.0.2):. Processed in 3.713734 secs); 20 Jun 2009 15:30:16 -0000 Received: from unknown (HELO ?192.168.0.2?) (192.168.0.2) by lerwick.hopto.org with SMTP; 20 Jun 2009 16:30:12 +0100 From: Craig Butler To: Martin Wilke In-Reply-To: <20090611194557.GC98175@bsdcrew.de> References: <20090611194557.GC98175@bsdcrew.de> Content-Type: text/plain Date: Sat, 20 Jun 2009 16:25:53 +0100 Message-Id: <1245511553.10165.7.camel@main.lerwick.hopto.org> Mime-Version: 1.0 X-Mailer: Evolution 2.24.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 20 Jun 2009 16:34:56 +0000 Cc: ports@FreeBSD.org, freebsd-emulation@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: [Call For Testing] VirtualBox for FreeBSD! take 6 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, 20 Jun 2009 15:26:51 -0000 Hi All Is anyone else having difficulties running this as a normal user ? * running 7.2-RELEASE i386 * have added user to the vboxusers group. * confirmed by issuing groups command as user When I go to run VirtualBox it just hangs, if I run it within a truss session I get a warning saying; VirtualBox - Error in SUPR3HardenedMain Effective UID is not root I then tried to setuid the link and the binary, still getting the same result. Works ok if I su upto root tho... Although sometimes only when running with truss. Cheers Craig B On Thu, 2009-06-11 at 21:45 +0200, Martin Wilke wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Huhu, > > Yes we life and that's good :-). > Changes: > > - Fix build error when compiling in debug mode on FreeBSD HEAD > - SemEvent?-r0drv/FreeBSD: Don't use tvtohz for an infinite timeout. > - Some FreeBSD relate typos > - Enable shared OpenGL service. Completely untested due to lack of > appropriate hardware but it compiles at least > - Add support for shared clipboards. Requires libXt > - FreeBSD: Implement preemption API for guest SMP and enable > it (slightly tested). Add neccessary RTMP* methods in userspace > for the frontends to detect the number of CPUs > - Runtime/semevent-r0drv-freebsd: Use a sleeping mutex > instead of a spinlock to fix the problems users are seeing > (assertions with debugging enabled) while still being able > to run on 100Hz hosts. No problems detected so far and Solaris > doesn't use a spin mutex in this code too so it shouldn't do > any harm (keeping fingers crossed)space for the frontends to > detect the number of CPUs > - Add support for curl > - Add VBoxSharedClipboard > > Ports Changes; > - Force guestadditions version to 2.2.4 > - Removed Qt3 include replacements (already upstream) > - Removed cosmetic X11 include path patch > > Please make SURE, your world and kernel is in sync and you've read > the pkg-messages. Also please unload the kernel module before > you update the port ;-). > > Many thx to all Vbox Devs, All supporters, my nice team! :-) > > http://people.freebsd.org/~miwi/vbox/virtualbox_6.tgz > > Happy Testing! > > - - Martin > > - -- > > +-----------------------+-------------------------------+ > | PGP : 0xB1E6FCE9 | Jabber : miwi(at)BSDCrew.de | > | Skype : splash_111 | Mail : miwi(at)FreeBSD.org | > +-----------------------+-------------------------------+ > | Mess with the Best, Die like the Rest! | > +-----------------------+-------------------------------+ > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.11 (FreeBSD) > > iEYEARECAAYFAkoxXvUACgkQdLJIhLHm/OmHHQCcCvJ6EKNehym1siBuQICX+7+l > i2sAn0InwBQW7jf+l/PqjIM/BR/g3qhi > =hDW+ > -----END PGP SIGNATURE----- > _______________________________________________ > freebsd-ports@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Sat Jun 20 16:42:20 2009 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 1E6D31065673 for ; Sat, 20 Jun 2009 16:42:20 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outN.internet-mail-service.net (outn.internet-mail-service.net [216.240.47.237]) by mx1.freebsd.org (Postfix) with ESMTP id 018678FC14 for ; Sat, 20 Jun 2009 16:42:19 +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 0A80EC03DF; Sat, 20 Jun 2009 09:42:26 -0700 (PDT) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 41B262D6013; Sat, 20 Jun 2009 09:42:19 -0700 (PDT) Message-ID: <4A3D116B.7080308@elischer.org> Date: Sat, 20 Jun 2009 09:42:19 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Nenhum_de_Nos References: <9ccd6cc4824b70cd9316ad9490dfd932.squirrel@cygnus.homeunix.com> <9ca40c9e2ad6e868fcbe6692e248ee13.squirrel@cygnus.homeunix.com> In-Reply-To: <9ca40c9e2ad6e868fcbe6692e248ee13.squirrel@cygnus.homeunix.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: tinybsd can't compile custom kernel 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, 20 Jun 2009 16:42:20 -0000 Nenhum_de_Nos wrote: > On Sat, June 20, 2009 12:06, Nenhum_de_Nos wrote: >> hail, >> >> I'm trying to compile tinybsd for a firewall. I copied firewall dir under >> conf to cygnus. edited and tried to compile. >> >> It was ok till kernel compilation: >> >> ===> Chrooted make in /usr/obj/tinybsdbuild succeeded >> ===> Cleaning up... >> ===> Cleaning for autoconf-2.62 >> ===> Cleaning for expat-2.0.1 >> ===> Cleaning for pcre-7.9 >> ===> Cleaning for libiconv-1.13 >> ===> Cleaning for m4-1.4.13,1 >> ===> Cleaning for help2man-1.36.4_3 >> ===> Cleaning for gmake-3.81_3 >> ===> Cleaning for autoconf-wrapper-20071109 >> ===> Cleaning for p5-gettext-1.05_2 >> ===> Cleaning for gettext-0.17_1 >> ===> Cleaning for apache-2.2.11_7 >> =====> Building customized tiny beastie kernel... >> ERROR: Missing kernel configuration file(s) (TINYBSD). >> *** Error code 1 >> >> Stop in /usr/src. >> *** Error code 1 >> >> Stop in /usr/src. >> >> in conf/cygnus there is TINYBSD file and cygnus file. the tinybsd command >> line ask for kernel conf file. there I type cygnus. >> >> [root@darkside /usr/src/tools/tools/tinybsd/conf]# ls -l cygnus/ >> total 24 >> -rw-r--r-- 1 root wheel 6361 Jun 19 22:32 TINYBSD >> -rw-r--r-- 1 root wheel 6361 Jun 20 01:15 cygnus >> drwxr-xr-x 3 root wheel 512 Feb 13 13:10 etc >> -rw-r--r-- 1 root wheel 3799 Jun 25 2007 tinybsd.basefiles >> -rw-r--r-- 1 root wheel 473 Jun 19 22:42 tinybsd.ports >> [root@darkside /usr/src/tools/tools/tinybsd/conf]# >> >> I followed http://www.tinybsd.org/tinybsd/Documentation. >> >> also, is there a way to save all choices from ports build ? and the curses >> menu don't work ok for choosing. is this the way was supposed to be ? >> >> thanks, >> >> matheus > > is possible to compile i386 tinybsd on amd64 install ? > > FreeBSD darkside.apartnet 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Sun Jun 14 > 01:59:21 BRT 2009 > root@darkside.apartnet:/usr/obj/usr/src/sys/Darkside8 amd64 > > thanks, > > matheus > TinyBSD uses the systems binaries on teh host system by default.. I've been told it can do a cross build by using a cross-built directory instead of / but haven't done it.. tinybsd is a shell script so you may be able to understand what is going on by just reading it. From owner-freebsd-current@FreeBSD.ORG Sat Jun 20 17:16:32 2009 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 76AA8106566C; Sat, 20 Jun 2009 17:16:32 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.29]) by mx1.freebsd.org (Postfix) with ESMTP id E68D98FC0C; Sat, 20 Jun 2009 17:16:31 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so1060064ywe.13 for ; Sat, 20 Jun 2009 10:16:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=J26OozqCNlNdzenMYwO1jF54y5PByjRlJsLT+URSdeA=; b=ktN+dm56ZDRV+OGMmajMYUrA+Q0BYYOFGB4QMEa/8Ja/2sbXeGDQ+HzkykHZrMXZCY V7NnFE4KnABIbvUzF9UszmsAWUHUdP3f/wDRiqugFQcSbxVy1UMHX/fAcmF1ocDaQJx9 OFeITaNWm0x5qnJ2ueVIlOB9P4s5b0Gp1gKcA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=XfdTCPa/EVH2ZNuSwfGtbdZcH8jvM+W2CWIw9uPyPnJvVNj3iqgrShiaqOy8Wy3iEK Se3v9uYYD/M3QBeE0ltWMV2z2/iajPXyir2K+EjBgeiVWNzCUCefMBmdvBcr75hRwFK6 Z3b+xU6XZwpr6gVMmlTVtLWxLAGfFRmdy9gGU= MIME-Version: 1.0 Sender: chmeeedalf@gmail.com Received: by 10.100.213.13 with SMTP id l13mr5538552ang.110.1245516698475; Sat, 20 Jun 2009 09:51:38 -0700 (PDT) In-Reply-To: <1245511553.10165.7.camel@main.lerwick.hopto.org> References: <20090611194557.GC98175@bsdcrew.de> <1245511553.10165.7.camel@main.lerwick.hopto.org> Date: Sat, 20 Jun 2009 12:51:38 -0400 X-Google-Sender-Auth: 7c9c96956c9fa902 Message-ID: From: Justin Hibbits To: Craig Butler Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ports@freebsd.org, freebsd-emulation@freebsd.org, freebsd-current@freebsd.org, Martin Wilke Subject: Re: [Call For Testing] VirtualBox for FreeBSD! take 6 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, 20 Jun 2009 17:16:33 -0000 Hi Craig, Yes, I've had problems trying to run vbox, where it just hangs. I tried running it through ktrace, but it just stopped the trace after loading the libraries, nothing else. Haven't tried with truss, though, nor have I checked SUID or anything (wasn't motivated enough to look deep into it). This may be the same thing you're seeing. I'm also running 7.2-RELEASE i386. - Justin On Sat, Jun 20, 2009 at 11:25 AM, Craig Butler wrote: > Hi All > > Is anyone else having difficulties running this as a normal user ? > > * running 7.2-RELEASE i386 > * have added user to the vboxusers group. > * confirmed by issuing groups command as user > > When I go to run VirtualBox it just hangs, if I run it within a truss > session I get a warning saying; > > VirtualBox - Error in SUPR3HardenedMain > Effective UID is not root > > I then tried to setuid the link and the binary, still getting the same > result. > > Works ok if I su upto root tho... =A0Although sometimes only when running > with truss. > > Cheers > > Craig B > > > > On Thu, 2009-06-11 at 21:45 +0200, Martin Wilke wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Huhu, >> >> Yes we life and that's good :-). >> Changes: >> >> =A0 - Fix build error when compiling in debug mode on FreeBSD HEAD >> =A0 - SemEvent?-r0drv/FreeBSD: Don't use tvtohz for an infinite timeout. >> =A0 - Some FreeBSD relate typos >> =A0 - Enable shared OpenGL service. Completely untested due to lack of >> =A0 =A0 appropriate hardware but it compiles at least >> =A0 - Add support for shared clipboards. Requires libXt >> =A0 - FreeBSD: Implement preemption API for guest SMP and enable >> =A0 =A0 it (slightly tested). Add neccessary RTMP* methods in userspace >> =A0 =A0 for the frontends to detect the number of CPUs >> =A0 - Runtime/semevent-r0drv-freebsd: Use a sleeping mutex >> =A0 =A0 instead of a spinlock to fix the problems users are seeing >> =A0 =A0 (assertions with debugging enabled) while still being able >> =A0 =A0 to run on 100Hz hosts. No problems detected so far and Solaris >> =A0 =A0 doesn't use a spin mutex in this code too so it shouldn't do >> =A0 =A0 any harm (keeping fingers crossed)space for the frontends to >> =A0 =A0 detect the number of CPUs >> =A0 - Add support for curl >> =A0 - Add VBoxSharedClipboard >> >> Ports Changes; >> =A0 - Force guestadditions version to 2.2.4 >> =A0 - Removed Qt3 include replacements (already upstream) >> =A0 - Removed cosmetic X11 include path patch >> >> Please make SURE, your world and kernel is in sync and you've read >> the pkg-messages. Also please unload the kernel module before >> you update the port ;-). >> >> Many thx to all Vbox Devs, All supporters, my nice team! :-) >> >> =A0 =A0http://people.freebsd.org/~miwi/vbox/virtualbox_6.tgz >> >> =A0Happy Testing! >> >> - - Martin >> >> - -- >> >> +-----------------------+-------------------------------+ >> | =A0PGP =A0 =A0: 0xB1E6FCE9 =A0| =A0Jabber : miwi(at)BSDCrew.de =A0| >> | =A0Skype =A0: splash_111 =A0| =A0Mail =A0 : miwi(at)FreeBSD.org | >> +-----------------------+-------------------------------+ >> | =A0 =A0 Mess with the Best, Die like the Rest! =A0 =A0 =A0 =A0 =A0| >> +-----------------------+-------------------------------+ >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v2.0.11 (FreeBSD) >> >> iEYEARECAAYFAkoxXvUACgkQdLJIhLHm/OmHHQCcCvJ6EKNehym1siBuQICX+7+l >> i2sAn0InwBQW7jf+l/PqjIM/BR/g3qhi >> =3DhDW+ >> -----END PGP SIGNATURE----- >> _______________________________________________ >> freebsd-ports@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-ports >> To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org" > > _______________________________________________ > 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 Sat Jun 20 17:37:02 2009 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 E84CA106564A for ; Sat, 20 Jun 2009 17:37:02 +0000 (UTC) (envelope-from mister.olli@googlemail.com) Received: from mail-fx0-f206.google.com (mail-fx0-f206.google.com [209.85.220.206]) by mx1.freebsd.org (Postfix) with ESMTP id 6E5708FC08 for ; Sat, 20 Jun 2009 17:37:02 +0000 (UTC) (envelope-from mister.olli@googlemail.com) Received: by fxm2 with SMTP id 2so212191fxm.43 for ; Sat, 20 Jun 2009 10:37:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:subject:from:reply-to:to :content-type:date:message-id:mime-version:x-mailer :content-transfer-encoding; bh=KIxZscPOEKiUKX6UWCXxJpunq+Af3YUmcZcUQC3ZAC4=; b=ju258I9f+RDvuBJDZil5rgtua3lK/P1jxl7klAYPhzVEIrmkpkUnnm+OoUtH7Ir0hU FAjTgYly61J4cujO79iprFOnS8Nsma++91nVI1yUgBU+c241YGpT1pjW11rbgyiyS5OF vsNBfDG4H+5fALF9e1pkImMDg8C5g3FL1DesU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=subject:from:reply-to:to:content-type:date:message-id:mime-version :x-mailer:content-transfer-encoding; b=vfVzucCIeYqSw1WOZ3U+vOtbvf61alS5IM/tX6MCbZOMFYd1OL3kqiweVsej6dxyZO XINxijG9+NyRRrvwrxf6xPBiYdWoIMXU4yeAP+TqIjxspnyacw1GvTWZXE8ahwfX4Y/A VUC8Fazk5dhnY5fDAQw7fqJETZVw5F4TtW5cg= Received: by 10.204.117.65 with SMTP id p1mr3978384bkq.91.1245519421268; Sat, 20 Jun 2009 10:37:01 -0700 (PDT) Received: from ?88.128.7.206? ([88.128.7.206]) by mx.google.com with ESMTPS id e17sm8615090fke.18.2009.06.20.10.37.00 (version=SSLv3 cipher=RC4-MD5); Sat, 20 Jun 2009 10:37:00 -0700 (PDT) From: Mister Olli To: freebsd-current@freebsd.org Content-Type: text/plain Date: Sat, 20 Jun 2009 19:36:52 +0200 Message-Id: <1245519413.26909.60.camel@phoenix.blechhirn.net> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 Content-Transfer-Encoding: 7bit Subject: Unable to delete files on ZFS volume X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mister.olli@googlemail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jun 2009 17:37:03 -0000 Hi, after filling up a ZFS volume until the last byte, I'm unable to delete files, with error 'No space left on the device'. [root@template-8_CURRENT /test/data2]# df -h Filesystem Size Used Avail Capacity Mounted on /dev/ad0s1a 8.7G 5.2G 2.8G 65% / devfs 1.0K 1.0K 0B 100% /dev test 0B 0B 0B 100% /test test/data1 1.6G 1.6G 0B 100% /test/data1 test/data2 341M 341M 0B 100% /test/data2 [root@template-8_CURRENT /test/data2]# zfs list NAME USED AVAIL REFER MOUNTPOINT test 1.96G 0 26.6K /test test/data1 1.62G 0 1.62G /test/data1 test/data2 341M 0 341M /test/data2 [root@template-8_CURRENT /test/data2]# ls -l data1 |tail -n 20 <-- there are quite a lot of files, so I truncated ;-)) -rw-r--r-- 1 root wheel 3072 Jun 20 17:13 20090620165743 -rw-r--r-- 1 root wheel 9771008 Jun 20 17:11 20090620165803 -rw-r--r-- 1 root wheel 624640 Jun 20 17:12 20090620165809 -rw-r--r-- 1 root wheel 1777664 Jun 20 17:14 20090620165810 -rw-r--r-- 1 root wheel 4059136 Jun 20 17:15 20090620165817 -rw-r--r-- 1 root wheel 23778304 Jun 20 17:13 20090620165925 -rw-r--r-- 1 root wheel 20318208 Jun 20 17:13 20090620165952 -rw-r--r-- 1 root wheel 28394496 Jun 20 17:10 20090620170013 -rw-r--r-- 1 root wheel 23698432 Jun 20 17:12 20090620170021 -rw-r--r-- 1 root wheel 26476544 Jun 20 17:19 20090620170100 -rw-r--r-- 1 root wheel 19904512 Jun 20 17:15 20090620170132 -rw-r--r-- 1 root wheel 23815168 Jun 20 17:14 20090620170142 -rw-r--r-- 1 root wheel 6683648 Jun 20 17:11 20090620170225 -rw-r--r-- 1 root wheel 19619840 Jun 20 17:11 20090620170322 -rw-r--r-- 1 root wheel 13902848 Jun 20 17:13 20090620170331 -rw-r--r-- 1 root wheel 28981248 Jun 20 17:13 20090620170346 -rw-r--r-- 1 root wheel 18287616 Jun 20 17:11 20090620170355 -rw-r--r-- 1 root wheel 16762880 Jun 20 17:16 20090620170405 -rw-r--r-- 1 root wheel 26966016 Jun 20 17:10 20090620170429 -rw-r--r-- 1 root wheel 5252096 Jun 20 17:14 20090620170502 [root@template-8_CURRENT /test/data2]# rm -rf data1 rm: data1/20090620141524: No space left on device rm: data1/20090620025202: No space left on device rm: data1/20090620014926: No space left on device rm: data1/20090620075405: No space left on device rm: data1/20090620155124: No space left on device rm: data1/20090620105723: No space left on device rm: data1/20090620170100: No space left on device rm: data1/20090620040149: No space left on device rm: data1/20090620002512: No space left on device rm: data1/20090620052315: No space left on device rm: data1/20090620083750: No space left on device rm: data1/20090620063831: No space left on device rm: data1/20090620155029: No space left on device rm: data1/20090619234313: No space left on device rm: data1/20090620115346: No space left on device rm: data1/20090620075508: No space left on device rm: data1/20090620145541: No space left on device rm: data1/20090620093335: No space left on device rm: data1/20090620101846: No space left on device rm: data1/20090620132456: No space left on device rm: data1/20090620040044: No space left on device rm: data1/20090620091401: No space left on device rm: data1/20090620162251: No space left on device rm: data1/20090619220813: No space left on device rm: data1/20090620010643: No space left on device rm: data1/20090620052218: No space left on device Regards, --- Mr. Olli From owner-freebsd-current@FreeBSD.ORG Sat Jun 20 17:50:30 2009 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 4638C1065670 for ; Sat, 20 Jun 2009 17:50:30 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.242]) by mx1.freebsd.org (Postfix) with ESMTP id F275F8FC13 for ; Sat, 20 Jun 2009 17:50:29 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: by an-out-0708.google.com with SMTP id c3so1050499ana.13 for ; Sat, 20 Jun 2009 10:50:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=u/Lb5tCfzR2Xfrexxw3A/pDLyHP9YV1MmLFekKSN8Og=; b=sOPKrsmMyhNcpHD7c5OyGFhrnN5uigfcA1HSdpGrn27RXJHcRwO7qiEGlON10S2b/7 HPguR360lrEZt27csPQtrRauEahY42mycaKzYTFVLUhX3CwwexAe7LWosXCoKapTQ1GB Zg7SCnV+TC8yBd16xAoZ8ueqrQ0fkIFGF1xHQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=eGfM91ey994My+BygBeZBuipbgnDD/K5EiOhN4136l5hfXVIPHQhj6t/xZYBItVeJ+ E0cxlRL3Rja6hcvvHUhq1zUriOwlYcY0FYtrb2ulWV/XDLiofwbUiYvXAGuYTAvUSLZT eq3fe1Twr1oFlK9eYPOrtrjg5pbO/yyyJMDnY= MIME-Version: 1.0 Sender: mat.macy@gmail.com Received: by 10.100.47.12 with SMTP id u12mr5549355anu.169.1245520229348; Sat, 20 Jun 2009 10:50:29 -0700 (PDT) In-Reply-To: <1245519413.26909.60.camel@phoenix.blechhirn.net> References: <1245519413.26909.60.camel@phoenix.blechhirn.net> Date: Sat, 20 Jun 2009 10:50:29 -0700 X-Google-Sender-Auth: 4afdac79d1610369 Message-ID: <3c1674c90906201050w15e4cd5dpae76cd70d64b4e92@mail.gmail.com> From: Kip Macy To: mister.olli@googlemail.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: Unable to delete files on ZFS volume 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, 20 Jun 2009 17:50:30 -0000 Do you have snapshots or run ZFS v6? Confirm that you've deleted your snapshots and are running pool v13. Future ZFS mail should be directed to freebsd-fs@ On Sat, Jun 20, 2009 at 10:36 AM, Mister Olli w= rote: > Hi, > > after filling up a ZFS volume until the last byte, I'm unable to delete > files, with error 'No space left on the device'. > > > > [root@template-8_CURRENT /test/data2]# df -h > Filesystem =A0 =A0 Size =A0 =A0Used =A0 Avail Capacity =A0Mounted on > /dev/ad0s1a =A0 =A08.7G =A0 =A05.2G =A0 =A02.8G =A0 =A065% =A0 =A0/ > devfs =A0 =A0 =A0 =A0 =A01.0K =A0 =A01.0K =A0 =A0 =A00B =A0 100% =A0 =A0/= dev > test =A0 =A0 =A0 =A0 =A0 =A0 0B =A0 =A0 =A00B =A0 =A0 =A00B =A0 100% =A0 = =A0/test > test/data1 =A0 =A0 1.6G =A0 =A01.6G =A0 =A0 =A00B =A0 100% =A0 =A0/test/d= ata1 > test/data2 =A0 =A0 341M =A0 =A0341M =A0 =A0 =A00B =A0 100% =A0 =A0/test/d= ata2 > [root@template-8_CURRENT /test/data2]# zfs list > NAME =A0 =A0 =A0 =A0 USED =A0AVAIL =A0REFER =A0MOUNTPOINT > test =A0 =A0 =A0 =A01.96G =A0 =A0 =A00 =A026.6K =A0/test > test/data1 =A01.62G =A0 =A0 =A00 =A01.62G =A0/test/data1 > test/data2 =A0 341M =A0 =A0 =A00 =A0 341M =A0/test/data2 > [root@template-8_CURRENT /test/data2]# ls -l data1 |tail -n 20 =A0 =A0 = =A0 =A0 =A0<-- there are quite a lot of files, so I truncated ;-)) > -rw-r--r-- =A01 root =A0wheel =A0 =A0 =A03072 Jun 20 17:13 20090620165743 > -rw-r--r-- =A01 root =A0wheel =A0 9771008 Jun 20 17:11 20090620165803 > -rw-r--r-- =A01 root =A0wheel =A0 =A0624640 Jun 20 17:12 20090620165809 > -rw-r--r-- =A01 root =A0wheel =A0 1777664 Jun 20 17:14 20090620165810 > -rw-r--r-- =A01 root =A0wheel =A0 4059136 Jun 20 17:15 20090620165817 > -rw-r--r-- =A01 root =A0wheel =A023778304 Jun 20 17:13 20090620165925 > -rw-r--r-- =A01 root =A0wheel =A020318208 Jun 20 17:13 20090620165952 > -rw-r--r-- =A01 root =A0wheel =A028394496 Jun 20 17:10 20090620170013 > -rw-r--r-- =A01 root =A0wheel =A023698432 Jun 20 17:12 20090620170021 > -rw-r--r-- =A01 root =A0wheel =A026476544 Jun 20 17:19 20090620170100 > -rw-r--r-- =A01 root =A0wheel =A019904512 Jun 20 17:15 20090620170132 > -rw-r--r-- =A01 root =A0wheel =A023815168 Jun 20 17:14 20090620170142 > -rw-r--r-- =A01 root =A0wheel =A0 6683648 Jun 20 17:11 20090620170225 > -rw-r--r-- =A01 root =A0wheel =A019619840 Jun 20 17:11 20090620170322 > -rw-r--r-- =A01 root =A0wheel =A013902848 Jun 20 17:13 20090620170331 > -rw-r--r-- =A01 root =A0wheel =A028981248 Jun 20 17:13 20090620170346 > -rw-r--r-- =A01 root =A0wheel =A018287616 Jun 20 17:11 20090620170355 > -rw-r--r-- =A01 root =A0wheel =A016762880 Jun 20 17:16 20090620170405 > -rw-r--r-- =A01 root =A0wheel =A026966016 Jun 20 17:10 20090620170429 > -rw-r--r-- =A01 root =A0wheel =A0 5252096 Jun 20 17:14 20090620170502 > [root@template-8_CURRENT /test/data2]# =A0rm -rf data1 > rm: data1/20090620141524: No space left on device > rm: data1/20090620025202: No space left on device > rm: data1/20090620014926: No space left on device > rm: data1/20090620075405: No space left on device > rm: data1/20090620155124: No space left on device > rm: data1/20090620105723: No space left on device > rm: data1/20090620170100: No space left on device > rm: data1/20090620040149: No space left on device > rm: data1/20090620002512: No space left on device > rm: data1/20090620052315: No space left on device > rm: data1/20090620083750: No space left on device > rm: data1/20090620063831: No space left on device > rm: data1/20090620155029: No space left on device > rm: data1/20090619234313: No space left on device > rm: data1/20090620115346: No space left on device > rm: data1/20090620075508: No space left on device > rm: data1/20090620145541: No space left on device > rm: data1/20090620093335: No space left on device > rm: data1/20090620101846: No space left on device > rm: data1/20090620132456: No space left on device > rm: data1/20090620040044: No space left on device > rm: data1/20090620091401: No space left on device > rm: data1/20090620162251: No space left on device > rm: data1/20090619220813: No space left on device > rm: data1/20090620010643: No space left on device > rm: data1/20090620052218: No space left on device > > > > > > Regards, > --- > Mr. Olli > > _______________________________________________ > 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= " > --=20 When bad men combine, the good must associate; else they will fall one by one, an unpitied sacrifice in a contemptible struggle. Edmund Burke From owner-freebsd-current@FreeBSD.ORG Sat Jun 20 17:59:07 2009 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 9FF631065672; Sat, 20 Jun 2009 17:59:07 +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 5CF6E8FC13; Sat, 20 Jun 2009 17:59:07 +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.3/8.14.3) with ESMTP id n5KHx2UT089802; Sat, 20 Jun 2009 13:59:02 -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 n5KHx2AX093980; Sat, 20 Jun 2009 13:59:02 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id F0DDC7302F; Sat, 20 Jun 2009 13:59:01 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090620175901.F0DDC7302F@freebsd-current.sentex.ca> Date: Sat, 20 Jun 2009 13:59:01 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp2.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on amd64/amd64 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: Sat, 20 Jun 2009 17:59:08 -0000 TB --- 2009-06-20 15:40:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-06-20 15:40:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2009-06-20 15:40:00 - cleaning the object tree TB --- 2009-06-20 15:40:44 - cvsupping the source tree TB --- 2009-06-20 15:40:44 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/amd64/amd64/supfile TB --- 2009-06-20 15:40:53 - building world TB --- 2009-06-20 15:40:53 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-20 15:40:53 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-20 15:40:53 - TARGET=amd64 TB --- 2009-06-20 15:40:53 - TARGET_ARCH=amd64 TB --- 2009-06-20 15:40:53 - TZ=UTC TB --- 2009-06-20 15:40:53 - __MAKE_CONF=/dev/null TB --- 2009-06-20 15:40:53 - cd /src TB --- 2009-06-20 15:40:53 - /usr/bin/make -B buildworld >>> World build started on Sat Jun 20 15:40:57 UTC 2009 >>> 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 >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Sat Jun 20 17:41:33 UTC 2009 TB --- 2009-06-20 17:41:33 - generating LINT kernel config TB --- 2009-06-20 17:41:33 - cd /src/sys/amd64/conf TB --- 2009-06-20 17:41:33 - /usr/bin/make -B LINT TB --- 2009-06-20 17:41:34 - building LINT kernel TB --- 2009-06-20 17:41:34 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-20 17:41:34 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-20 17:41:34 - TARGET=amd64 TB --- 2009-06-20 17:41:34 - TARGET_ARCH=amd64 TB --- 2009-06-20 17:41:34 - TZ=UTC TB --- 2009-06-20 17:41:34 - __MAKE_CONF=/dev/null TB --- 2009-06-20 17:41:34 - cd /src TB --- 2009-06-20 17:41:34 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Jun 20 17:41:34 UTC 2009 >>> 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 [...] cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/security/mac/mac_sysv_sem.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/security/mac/mac_sysv_shm.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/security/mac/mac_vfs.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/security/mac_biba/mac_biba.c /src/sys/security/mac_biba/mac_biba.c: In function 'biba_priv_check': /src/sys/security/mac_biba/mac_biba.c:1792: error: 'PRIV_TTY_PRISON' undeclared (first use in this function) /src/sys/security/mac_biba/mac_biba.c:1792: error: (Each undeclared identifier is reported only once /src/sys/security/mac_biba/mac_biba.c:1792: error: for each function it appears in.) *** Error code 1 Stop in /obj/amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-20 17:59:01 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-20 17:59:01 - ERROR: failed to build lint kernel TB --- 2009-06-20 17:59:01 - 6478.07 user 649.66 system 8341.18 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Sat Jun 20 19:39:25 2009 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 8D2951065670 for ; Sat, 20 Jun 2009 19:39:25 +0000 (UTC) (envelope-from jason.harmening@gmail.com) Received: from mail-yx0-f200.google.com (mail-yx0-f200.google.com [209.85.210.200]) by mx1.freebsd.org (Postfix) with ESMTP id 32D168FC13 for ; Sat, 20 Jun 2009 19:39:25 +0000 (UTC) (envelope-from jason.harmening@gmail.com) Received: by yxe38 with SMTP id 38so834251yxe.3 for ; Sat, 20 Jun 2009 12:39:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:subject :message-id:x-mailer:mime-version:content-type :content-transfer-encoding; bh=7zC4hhWkJEmrdPZBn+na9bGtyVrp6Gxw5qo/cU49c+c=; b=EF42xQ25pCeygsUUktTxxYpkt9tGJderFGCGzW0AQnMMiYdY+DdRRUrtUpwSZhoXvm nEjnJNFAl9sXwv+oAgbk+ZIR/fBY1zE14c0UfxDL2YQjNoDe6/6Rj/b+4266N1e2/JXZ +VCO2uSpgm/c1ebFCb/yJcM3fxz8I/IxGVcpI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:subject:message-id:x-mailer:mime-version:content-type :content-transfer-encoding; b=Frdly9VTDuRGbMuhIPk2BfQe82M04aqSmevaPLLR0SctLScEQYWzOtEkjobrJwleyK R9Hj2/gRTrI1/rFuDEVyQLsZzbhLtY1nW9vPA/4JEBmRZwOWUCO5yZ66SLFnz3KbBriE rYkehqkZKsX3HhYesiWJzgaHsIod4PAiKFDuU= Received: by 10.90.56.16 with SMTP id e16mr2464646aga.57.1245525039744; Sat, 20 Jun 2009 12:10:39 -0700 (PDT) Received: from CORONA ([24.174.5.175]) by mx.google.com with ESMTPS id 10sm2598825agb.76.2009.06.20.12.10.38 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 20 Jun 2009 12:10:38 -0700 (PDT) Date: Sat, 20 Jun 2009 14:08:20 -0500 From: Jason Harmening To: freebsd-current@freebsd.org Message-ID: <20090620140820.14273115@CORONA> X-Mailer: Claws Mail 3.7.1 (GTK+ 2.16.1; amd64-portbld-freebsd7.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 20 Jun 2009 20:15:24 +0000 Subject: USB keyboard/mouse combo fails to attach 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, 20 Jun 2009 19:39:25 -0000 Hi all, I have a USB keyboard/mouse combo that sometimes fails to attach in -CURRENT, with the following error: uhub_reattach_port:416: could not allocate new device! This failure happens roughly every other time the device enumerates; generally it will attach and work fine if I just re-plug it. It looks like a stall while retrieving the device descriptor, though the device never had a problem attaching in 7-STABLE. I've included what (I think) are the relevant lines from my syslog w/ hw.usb.debug=15. Any help would be greatly appreciated. Thanks, Jason Jun 20 13:53:09 riviera kernel: usbd_do_request_flags:307: Handle Request function is set Jun 20 13:53:09 riviera kernel: usbd_do_request_flags:272: udev=0xffffff0005bb8000 bmRequestType=0x23 bRequest=0x01 wValue=0x0014 wIndex=0x0001 wLength=0x0000 Jun 20 13:53:09 riviera kernel: usbd_do_request_flags:307: Handle Request function is set Jun 20 13:53:09 riviera kernel: usbd_req_reset_port:659: port 1 reset returning error=USB_ERR_NORMAL_COMPLETION Jun 20 13:53:09 riviera kernel: usbd_do_request_flags:272: udev=0xffffff0005bb8000 bmRequestType=0xa3 bRequest=0x00 wValue=0x0000 wIndex=0x0001 wLength=0x0004 Jun 20 13:53:09 riviera kernel: usbd_do_request_flags:307: Handle Request function is set Jun 20 13:53:09 riviera kernel: usb_alloc_device:1432: parent_dev=0xffffff0005be1400, bus=0xffffff80005e8db0, parent_hub=0xffffff0005bb8000, depth=1, port_index=0, port_no=1, speed=1, usb_mode=0 Jun 20 13:53:09 riviera kernel: usb_set_device_state:2421: udev 0xffffff0016575800 state DETACHED -> POWERED Jun 20 13:53:09 riviera kernel: usbd_req_set_address:1160: setting device address=2 Jun 20 13:53:09 riviera kernel: usbd_do_request_flags:272: udev=0xffffff0016575800 bmRequestType=0x00 bRequest=0x05 wValue=0x0002 wIndex=0x0000 wLength=0x0000 Jun 20 13:53:09 riviera kernel: usbd_get_endpoint:184: udev=0xffffff0016575800 iface_index=0 address=0x0 type=0x0 dir=0xff index=0 Jun 20 13:53:09 riviera last message repeated 3 times Jun 20 13:53:09 riviera kernel: usb_command_wrapper:2541: cb 0xffffff8000aa0148 (enter) Jun 20 13:53:09 riviera kernel: usbd_callback_wrapper:1922: case 1-4 Jun 20 13:53:09 riviera kernel: usbd_do_request_callback:75: st=0 Jun 20 13:53:09 riviera kernel: usbd_transfer_submit:1381: xfer=0xffffff8000aa0148, endpoint=0xffffff00165758d8, nframes=1, dir=write Jun 20 13:53:09 riviera kernel: usb_dump_endpoint: endpoint=0xffffff00165758d8 edesc=0xffffff0016575de4 isoc_next=0 toggle_next=0 bEndpointAddress=0x00 Jun 20 13:53:09 riviera kernel: usb_dump_queue: endpoint=0xffffff00165758d8 xfer: Jun 20 13:53:09 riviera kernel: usbd_transfer_submit:1400: open Jun 20 13:53:09 riviera kernel: usb_command_wrapper:2541: cb 0xffffff8000aa0148 (enter) Jun 20 13:53:09 riviera kernel: usb_command_wrapper:2543: cb 0xffffff8000aa0148 (leave) Jun 20 13:53:09 riviera kernel: usb_command_wrapper:2541: cb 0xffffff8000aa0148 (enter) Jun 20 13:53:09 riviera kernel: usbd_pipe_enter:1568: enter Jun 20 13:53:09 riviera kernel: usb_command_wrapper:2541: cb 0xffffff8000aa0148 (enter) Jun 20 13:53:09 riviera kernel: usbd_pipe_start:2296: start Jun 20 13:53:09 riviera kernel: usb_command_wrapper:2543: cb 0xffffff8000aa0148 (leave) Jun 20 13:53:09 riviera kernel: usb_command_wrapper:2543: cb 0 (leave) Jun 20 13:53:09 riviera kernel: usb_command_wrapper:2543: cb 0 (leave) Jun 20 13:53:09 riviera kernel: usbd_transfer_done:2077: err=USB_ERR_NORMAL_COMPLETION Jun 20 13:53:09 riviera kernel: usb_command_wrapper:2541: cb 0xffffff8000aa0148 (enter) Jun 20 13:53:09 riviera kernel: usbd_callback_wrapper:1922: case 1-4 Jun 20 13:53:09 riviera kernel: usbd_callback_wrapper_sub:2430: xfer=0xffffff8000aa0148 endpoint=0xffffff00165758d8 sts=0 alen=8, slen=8, afrm=1, nfrm=1 Jun 20 13:53:09 riviera kernel: usbd_callback_wrapper_sub:2466: xfer=0xffffff8000aa0148: Control transfer active on endpoint=0xffffff00165758d8 Jun 20 13:53:09 riviera kernel: usbd_do_request_callback:75: st=1 Jun 20 13:53:09 riviera kernel: usb_command_wrapper:2543: cb 0 (leave) Jun 20 13:53:09 riviera kernel: usb_command_wrapper:2541: cb 0xffffff8000aa0148 (enter) Jun 20 13:53:09 riviera kernel: usbd_callback_wrapper:1922: case 1-4 Jun 20 13:53:09 riviera kernel: usbd_do_request_callback:75: st=0 Jun 20 13:53:09 riviera kernel: usbd_transfer_submit:1381: xfer=0xffffff8000aa0148, endpoint=0xffffff00165758d8, nframes=1, dir=write Jun 20 13:53:09 riviera kernel: usb_dump_endpoint: endpoint=0xffffff00165758d8 edesc=0xffffff0016575de4 isoc_next=0 toggle_next=1 bEndpointAddress=0x00 Jun 20 13:53:09 riviera kernel: usb_dump_queue: endpoint=0xffffff00165758d8 xfer: Jun 20 13:53:09 riviera kernel: usb_command_wrapper:2541: cb 0xffffff8000aa0148 (enter) Jun 20 13:53:09 riviera kernel: usb_command_wrapper:2543: cb 0xffffff8000aa0148 (leave) Jun 20 13:53:09 riviera kernel: usb_command_wrapper:2541: cb 0xffffff8000aa0148 (enter) Jun 20 13:53:09 riviera kernel: usbd_pipe_enter:1568: enter Jun 20 13:53:09 riviera kernel: usb_command_wrapper:2541: cb 0xffffff8000aa0148 (enter) Jun 20 13:53:09 riviera kernel: usbd_pipe_start:2296: start Jun 20 13:53:09 riviera kernel: usb_command_wrapper:2543: cb 0xffffff8000aa0148 (leave) Jun 20 13:53:09 riviera kernel: usb_command_wrapper:2543: cb 0 (leave) Jun 20 13:53:09 riviera kernel: usb_command_wrapper:2543: cb 0 (leave) Jun 20 13:53:09 riviera kernel: usbd_transfer_done:2077: err=USB_ERR_NORMAL_COMPLETION Jun 20 13:53:09 riviera kernel: usb_command_wrapper:2541: cb 0xffffff8000aa0148 (enter) Jun 20 13:53:09 riviera kernel: usbd_callback_wrapper:1922: case 1-4 Jun 20 13:53:09 riviera kernel: usbd_callback_wrapper_sub:2430: xfer=0xffffff8000aa0148 endpoint=0xffffff00165758d8 sts=0 alen=0, slen=0, afrm=1, nfrm=1 Jun 20 13:53:09 riviera kernel: usbd_do_request_callback:75: st=1 Jun 20 13:53:09 riviera kernel: usb_command_wrapper:2543: cb 0 (leave) Jun 20 13:53:09 riviera kernel: usb_set_device_state:2421: udev 0xffffff0016575800 state POWERED -> ADDRESSED Jun 20 13:53:09 riviera kernel: usbd_req_get_desc:699: id=0, type=1, index=0, max_len=8 Jun 20 13:53:09 riviera kernel: usbd_do_request_flags:272: udev=0xffffff0016575800 bmRequestType=0x80 bRequest=0x06 wValue=0x0100 wIndex=0x0000 wLength=0x0008 Jun 20 13:53:09 riviera kernel: usbd_transfer_stop:1675: close Jun 20 13:53:09 riviera kernel: usbd_transfer_done:2077: err=USB_ERR_CANCELLED Jun 20 13:53:09 riviera kernel: usbd_transfer_done:2084: not transferring Jun 20 13:53:09 riviera kernel: usbd_get_endpoint:184: udev=0xffffff0016575800 iface_index=0 address=0x0 type=0x0 dir=0xff index=0 Jun 20 13:53:09 riviera last message repeated 3 times Jun 20 13:53:09 riviera kernel: usb_command_wrapper:2541: cb 0xffffff8000aa0148 (enter) Jun 20 13:53:09 riviera kernel: usbd_callback_wrapper:1922: case 1-4 Jun 20 13:53:09 riviera kernel: usbd_do_request_callback:75: st=0 Jun 20 13:53:09 riviera kernel: usbd_transfer_submit:1381: xfer=0xffffff8000aa0148, endpoint=0xffffff00165758d8, nframes=2, dir=write Jun 20 13:53:09 riviera kernel: usb_dump_endpoint: endpoint=0xffffff00165758d8 edesc=0xffffff0016575de4 isoc_next=0 toggle_next=0 bEndpointAddress=0x00 Jun 20 13:53:09 riviera kernel: usb_dump_queue: endpoint=0xffffff00165758d8 xfer: Jun 20 13:53:09 riviera kernel: usbd_transfer_submit:1400: open Jun 20 13:53:09 riviera kernel: usb_command_wrapper:2541: cb 0xffffff8000aa0148 (enter) Jun 20 13:53:09 riviera kernel: usb_command_wrapper:2543: cb 0xffffff8000aa0148 (leave) Jun 20 13:53:09 riviera kernel: usb_command_wrapper:2541: cb 0xffffff8000aa0148 (enter) Jun 20 13:53:09 riviera kernel: usb_command_wrapper:2543: cb 0xffffff8000aa0148 (leave) Jun 20 13:53:09 riviera kernel: usb_command_wrapper:2541: cb 0xffffff8000aa0148 (enter) Jun 20 13:53:09 riviera kernel: usbd_pipe_enter:1568: enter Jun 20 13:53:09 riviera kernel: usb_command_wrapper:2541: cb 0xffffff8000aa0148 (enter) Jun 20 13:53:09 riviera kernel: usbd_pipe_start:2296: start Jun 20 13:53:09 riviera kernel: usb_command_wrapper:2543: cb 0xffffff8000aa0148 (leave) Jun 20 13:53:09 riviera kernel: usb_command_wrapper:2543: cb 0 (leave) Jun 20 13:53:09 riviera kernel: usb_command_wrapper:2543: cb 0 (leave) Jun 20 13:53:09 riviera kernel: usbd_transfer_done:2077: err=USB_ERR_NORMAL_COMPLETION Jun 20 13:53:09 riviera kernel: usb_command_wrapper:2541: cb 0xffffff8000aa0148 (enter) Jun 20 13:53:09 riviera kernel: usbd_callback_wrapper:1922: case 1-4 Jun 20 13:53:09 riviera kernel: usbd_callback_wrapper_sub:2430: xfer=0xffffff8000aa0148 endpoint=0xffffff00165758d8 sts=0 alen=16, slen=16, afrm=2, nfrm=2 Jun 20 13:53:09 riviera kernel: usbd_do_request_callback:75: st=1 Jun 20 13:53:09 riviera kernel: usb_command_wrapper:2543: cb 0 (leave) Jun 20 13:53:09 riviera kernel: usb_alloc_device:1622: adding unit addr=2, rev=110, class=0, subclass=0, protocol=0, maxpacket=8, len=8, speed=1 Jun 20 13:53:09 riviera kernel: usbd_req_get_device_desc:1023: Jun 20 13:53:09 riviera kernel: usbd_req_get_desc:699: id=0, type=1, index=0, max_len=18 Jun 20 13:53:09 riviera kernel: usbd_do_request_flags:272: udev=0xffffff0016575800 bmRequestType=0x80 bRequest=0x06 wValue=0x0100 wIndex=0x0000 wLength=0x0012 Jun 20 13:53:09 riviera kernel: usb_command_wrapper:2541: cb 0xffffff8000aa0148 (enter) Jun 20 13:53:09 riviera kernel: usbd_callback_wrapper:1922: case 1-4 Jun 20 13:53:09 riviera kernel: usbd_do_request_callback:75: st=0 Jun 20 13:53:09 riviera kernel: usbd_transfer_submit:1381: xfer=0xffffff8000aa0148, endpoint=0xffffff00165758d8, nframes=2, dir=read Jun 20 13:53:09 riviera kernel: usb_dump_endpoint: endpoint=0xffffff00165758d8 edesc=0xffffff0016575de4 isoc_next=0 toggle_next=0 bEndpointAddress=0x00 Jun 20 13:53:09 riviera kernel: usb_dump_queue: endpoint=0xffffff00165758d8 xfer: Jun 20 13:53:09 riviera kernel: usb_command_wrapper:2541: cb 0xffffff8000aa0148 (enter) Jun 20 13:53:09 riviera kernel: usb_command_wrapper:2543: cb 0xffffff8000aa0148 (leave) Jun 20 13:53:09 riviera kernel: usb_command_wrapper:2541: cb 0xffffff8000aa0148 (enter) Jun 20 13:53:09 riviera kernel: usb_command_wrapper:2543: cb 0xffffff8000aa0148 (leave) Jun 20 13:53:09 riviera kernel: usb_command_wrapper:2541: cb 0xffffff8000aa0148 (enter) Jun 20 13:53:09 riviera kernel: usbd_pipe_enter:1568: enter Jun 20 13:53:09 riviera kernel: usb_command_wrapper:2541: cb 0xffffff8000aa0148 (enter) Jun 20 13:53:09 riviera kernel: usbd_pipe_start:2296: start Jun 20 13:53:09 riviera kernel: usb_command_wrapper:2543: cb 0xffffff8000aa0148 (leave) Jun 20 13:53:09 riviera kernel: usb_command_wrapper:2543: cb 0 (leave) Jun 20 13:53:09 riviera kernel: usb_command_wrapper:2543: cb 0 (leave) Jun 20 13:53:09 riviera kernel: usbd_transfer_done:2077: err=USB_ERR_STALLED Jun 20 13:53:09 riviera kernel: usb_command_wrapper:2541: cb 0xffffff8000aa0148 (enter) Jun 20 13:53:09 riviera kernel: usbd_callback_wrapper:1922: case 1-4 Jun 20 13:53:09 riviera kernel: usbd_callback_wrapper_sub:2430: xfer=0xffffff8000aa0148 endpoint=0xffffff00165758d8 sts=22 alen=8, slen=26, afrm=1, nfrm=2 Jun 20 13:53:09 riviera kernel: usbd_do_request_callback:75: st=2 Jun 20 13:53:09 riviera kernel: usb_command_wrapper:2543: cb 0 (leave) Jun 20 13:53:09 riviera kernel: usbd_transfer_stop:1675: close Jun 20 13:53:09 riviera kernel: usbd_transfer_done:2077: err=USB_ERR_CANCELLED Jun 20 13:53:09 riviera kernel: usbd_transfer_done:2084: not transferring Jun 20 13:53:09 riviera kernel: usbd_do_request_flags:272: udev=0xffffff0005bb8800 bmRequestType=0xa3 bRequest=0x00 wValue=0x0000 wIndex=0x0001 wLength=0x0004 Jun 20 13:53:09 riviera kernel: usbd_do_request_flags:307: Handle Request function is set Jun 20 13:53:09 riviera kernel: usbd_do_request_flags:272: udev=0xffffff0005bb8800 bmRequestType=0xa3 bRequest=0x00 wValue=0x0000 wIndex=0x0002 wLength=0x0004 Jun 20 13:53:09 riviera kernel: usbd_do_request_flags:307: Handle Request function is set Jun 20 13:53:09 riviera kernel: usbd_do_request_flags:272: udev=0xffffff0005bb8800 bmRequestType=0xa3 bRequest=0x00 wValue=0x0000 wIndex=0x0003 wLength=0x0004 Jun 20 13:53:09 riviera kernel: usbd_do_request_flags:307: Handle Request function is set Jun 20 13:53:09 riviera kernel: usbd_do_request_flags:272: udev=0xffffff0005bb8800 bmRequestType=0xa3 bRequest=0x00 wValue=0x0000 wIndex=0x0004 wLength=0x0004 Jun 20 13:53:09 riviera kernel: usbd_do_request_flags:307: Handle Request function is set Jun 20 13:53:09 riviera kernel: usbd_do_request_flags:272: udev=0xffffff0005bb8800 bmRequestType=0xa3 bRequest=0x00 wValue=0x0000 wIndex=0x0005 wLength=0x0004 Jun 20 13:53:09 riviera kernel: usbd_do_request_flags:307: Handle Request function is set Jun 20 13:53:09 riviera kernel: usbd_do_request_flags:272: udev=0xffffff0005bb8800 bmRequestType=0xa3 bRequest=0x00 wValue=0x0000 wIndex=0x0006 wLength=0x0004 Jun 20 13:53:09 riviera kernel: usbd_do_request_flags:307: Handle Request function is set Jun 20 13:53:09 riviera kernel: usbd_do_request_flags:272: udev=0xffffff0005bb5800 bmRequestType=0xa3 bRequest=0x00 wValue=0x0000 wIndex=0x0001 wLength=0x0004 Jun 20 13:53:09 riviera kernel: usbd_do_request_flags:307: Handle Request function is set Jun 20 13:53:09 riviera kernel: usbd_do_request_flags:272: udev=0xffffff0005bb5800 bmRequestType=0xa3 bRequest=0x00 wValue=0x0000 wIndex=0x0002 wLength=0x0004 Jun 20 13:53:09 riviera kernel: usbd_do_request_flags:307: Handle Request function is set Jun 20 13:53:09 riviera kernel: usbd_do_request_flags:272: udev=0xffffff0005bb5800 bmRequestType=0xa3 bRequest=0x00 wValue=0x0000 wIndex=0x0003 wLength=0x0004 Jun 20 13:53:09 riviera kernel: usbd_do_request_flags:307: Handle Request function is set Jun 20 13:53:09 riviera kernel: usbd_do_request_flags:272: udev=0xffffff0005bb5800 bmRequestType=0xa3 bRequest=0x00 wValue=0x0000 wIndex=0x0004 wLength=0x0004 Jun 20 13:53:09 riviera kernel: usbd_do_request_flags:307: Handle Request function is set Jun 20 13:53:09 riviera kernel: usbd_do_request_flags:272: udev=0xffffff0005bb5800 bmRequestType=0xa3 bRequest=0x00 wValue=0x0000 wIndex=0x0005 wLength=0x0004 Jun 20 13:53:09 riviera kernel: usbd_do_request_flags:307: Handle Request function is set Jun 20 13:53:09 riviera kernel: usbd_do_request_flags:272: udev=0xffffff0005bb5800 bmRequestType=0xa3 bRequest=0x00 wValue=0x0000 wIndex=0x0006 wLength=0x0004 Jun 20 13:53:09 riviera kernel: usbd_do_request_flags:307: Handle Request function is set Jun 20 13:53:09 riviera kernel: usbd_do_request_flags:272: udev=0xffffff0016575800 bmRequestType=0x80 bRequest=0x06 wValue=0x0100 wIndex=0x0000 wLength=0x0012 Jun 20 13:53:09 riviera kernel: usb_command_wrapper:2541: cb 0xffffff8000aa0148 (enter) Jun 20 13:53:09 riviera kernel: usbd_callback_wrapper:1922: case 1-4 Jun 20 13:53:09 riviera kernel: usbd_do_request_callback:75: st=0 Jun 20 13:53:09 riviera kernel: usbd_transfer_submit:1381: xfer=0xffffff8000aa0148, endpoint=0xffffff00165758d8, nframes=2, dir=read Jun 20 13:53:09 riviera kernel: usb_dump_endpoint: endpoint=0xffffff00165758d8 edesc=0xffffff0016575de4 isoc_next=0 toggle_next=1 bEndpointAddress=0x00 Jun 20 13:53:09 riviera kernel: usb_dump_queue: endpoint=0xffffff00165758d8 xfer: Jun 20 13:53:09 riviera kernel: usbd_transfer_submit:1400: open Jun 20 13:53:09 riviera kernel: usb_command_wrapper:2541: cb 0xffffff8000aa0148 (enter) Jun 20 13:53:09 riviera kernel: usb_command_wrapper:2543: cb 0xffffff8000aa0148 (leave) Jun 20 13:53:09 riviera kernel: usb_command_wrapper:2541: cb 0xffffff8000aa0148 (enter) Jun 20 13:53:09 riviera kernel: usb_command_wrapper:2543: cb 0xffffff8000aa0148 (leave) Jun 20 13:53:09 riviera kernel: usb_command_wrapper:2541: cb 0xffffff8000aa0148 (enter) Jun 20 13:53:09 riviera kernel: usbd_pipe_enter:1568: enter Jun 20 13:53:09 riviera kernel: usb_command_wrapper:2541: cb 0xffffff8000aa0148 (enter) Jun 20 13:53:09 riviera kernel: usbd_pipe_start:2296: start Jun 20 13:53:09 riviera kernel: usb_command_wrapper:2543: cb 0xffffff8000aa0148 (leave) Jun 20 13:53:09 riviera kernel: usb_command_wrapper:2543: cb 0 (leave) Jun 20 13:53:09 riviera kernel: usb_command_wrapper:2543: cb 0 (leave) Jun 20 13:53:09 riviera kernel: usbd_transfer_done:2077: err=USB_ERR_STALLED Jun 20 13:53:09 riviera kernel: usb_command_wrapper:2541: cb 0xffffff8000aa0148 (enter) Jun 20 13:53:09 riviera kernel: usbd_callback_wrapper:1922: case 1-4 Jun 20 13:53:09 riviera kernel: usbd_callback_wrapper_sub:2430: xfer=0xffffff8000aa0148 endpoint=0xffffff00165758d8 sts=22 alen=8, slen=26, afrm=1, nfrm=2 Jun 20 13:53:09 riviera kernel: usbd_do_request_callback:75: st=2 Jun 20 13:53:09 riviera kernel: usb_command_wrapper:2543: cb 0 (leave) Jun 20 13:53:09 riviera kernel: usbd_transfer_stop:1675: close Jun 20 13:53:09 riviera kernel: usbd_transfer_done:2077: err=USB_ERR_CANCELLED Jun 20 13:53:09 riviera kernel: usbd_transfer_done:2084: not transferring Jun 20 13:53:09 riviera kernel: usbd_do_request_flags:272: udev=0xffffff0016575800 bmRequestType=0x80 bRequest=0x06 wValue=0x0100 wIndex=0x0000 wLength=0x0012 Jun 20 13:53:09 riviera kernel: usb_command_wrapper:2541: cb 0xffffff8000aa0148 (enter) Jun 20 13:53:09 riviera kernel: usbd_callback_wrapper:1922: case 1-4 Jun 20 13:53:09 riviera kernel: usbd_do_request_callback:75: st=0 Jun 20 13:53:09 riviera kernel: usbd_transfer_submit:1381: xfer=0xffffff8000aa0148, endpoint=0xffffff00165758d8, nframes=2, dir=read Jun 20 13:53:09 riviera kernel: usb_dump_endpoint: endpoint=0xffffff00165758d8 edesc=0xffffff0016575de4 isoc_next=0 toggle_next=1 bEndpointAddress=0x00 Jun 20 13:53:09 riviera kernel: usb_dump_queue: endpoint=0xffffff00165758d8 xfer: Jun 20 13:53:09 riviera kernel: usbd_transfer_submit:1400: open Jun 20 13:53:09 riviera kernel: usb_command_wrapper:2541: cb 0xffffff8000aa0148 (enter) Jun 20 13:53:09 riviera kernel: usb_command_wrapper:2543: cb 0xffffff8000aa0148 (leave) Jun 20 13:53:09 riviera kernel: usb_command_wrapper:2541: cb 0xffffff8000aa0148 (enter) Jun 20 13:53:09 riviera kernel: usb_command_wrapper:2543: cb 0xffffff8000aa0148 (leave) Jun 20 13:53:09 riviera kernel: usb_command_wrapper:2541: cb 0xffffff8000aa0148 (enter) Jun 20 13:53:09 riviera kernel: usbd_pipe_enter:1568: enter Jun 20 13:53:09 riviera kernel: usb_command_wrapper:2541: cb 0xffffff8000aa0148 (enter) Jun 20 13:53:09 riviera kernel: usbd_pipe_start:2296: start Jun 20 13:53:09 riviera kernel: usb_command_wrapper:2543: cb 0xffffff8000aa0148 (leave) Jun 20 13:53:09 riviera kernel: usb_command_wrapper:2543: cb 0 (leave) Jun 20 13:53:09 riviera kernel: usb_command_wrapper:2543: cb 0 (leave) Jun 20 13:53:09 riviera kernel: usbd_transfer_done:2077: err=USB_ERR_STALLED Jun 20 13:53:09 riviera kernel: usb_command_wrapper:2541: cb 0xffffff8000aa0148 (enter) Jun 20 13:53:09 riviera kernel: usbd_callback_wrapper:1922: case 1-4 Jun 20 13:53:09 riviera kernel: usbd_callback_wrapper_sub:2430: xfer=0xffffff8000aa0148 endpoint=0xffffff00165758d8 sts=22 alen=8, slen=26, afrm=1, nfrm=2 Jun 20 13:53:09 riviera kernel: usbd_do_request_callback:75: st=2 Jun 20 13:53:09 riviera kernel: usb_command_wrapper:2543: cb 0 (leave) Jun 20 13:53:09 riviera kernel: usbd_transfer_stop:1675: close Jun 20 13:53:09 riviera kernel: usbd_transfer_done:2077: err=USB_ERR_CANCELLED Jun 20 13:53:09 riviera kernel: usbd_transfer_done:2084: not transferring Jun 20 13:53:10 riviera kernel: usbd_do_request_flags:272: udev=0xffffff0016575800 bmRequestType=0x80 bRequest=0x06 wValue=0x0100 wIndex=0x0000 wLength=0x0012 Jun 20 13:53:10 riviera kernel: usb_command_wrapper:2541: cb 0xffffff8000aa0148 (enter) Jun 20 13:53:10 riviera kernel: usbd_callback_wrapper:1922: case 1-4 Jun 20 13:53:10 riviera kernel: usbd_do_request_callback:75: st=0 Jun 20 13:53:10 riviera kernel: usbd_transfer_submit:1381: xfer=0xffffff8000aa0148, endpoint=0xffffff00165758d8, nframes=2, dir=read Jun 20 13:53:10 riviera kernel: usb_dump_endpoint: endpoint=0xffffff00165758d8 edesc=0xffffff0016575de4 isoc_next=0 toggle_next=1 bEndpointAddress=0x00 Jun 20 13:53:10 riviera kernel: usb_dump_queue: endpoint=0xffffff00165758d8 xfer: Jun 20 13:53:10 riviera kernel: usbd_transfer_submit:1400: open Jun 20 13:53:10 riviera kernel: usb_command_wrapper:2541: cb 0xffffff8000aa0148 (enter) Jun 20 13:53:10 riviera kernel: usb_command_wrapper:2543: cb 0xffffff8000aa0148 (leave) Jun 20 13:53:10 riviera kernel: usb_command_wrapper:2541: cb 0xffffff8000aa0148 (enter) Jun 20 13:53:10 riviera kernel: usb_command_wrapper:2543: cb 0xffffff8000aa0148 (leave) Jun 20 13:53:10 riviera kernel: usb_command_wrapper:2541: cb 0xffffff8000aa0148 (enter) Jun 20 13:53:10 riviera kernel: usbd_pipe_enter:1568: enter Jun 20 13:53:10 riviera kernel: usb_command_wrapper:2541: cb 0xffffff8000aa0148 (enter) Jun 20 13:53:10 riviera kernel: usbd_pipe_start:2296: start Jun 20 13:53:10 riviera kernel: usb_command_wrapper:2543: cb 0xffffff8000aa0148 (leave) Jun 20 13:53:10 riviera kernel: usb_command_wrapper:2543: cb 0 (leave) Jun 20 13:53:10 riviera kernel: usb_command_wrapper:2543: cb 0 (leave) Jun 20 13:53:10 riviera kernel: usbd_transfer_done:2077: err=USB_ERR_STALLED Jun 20 13:53:10 riviera kernel: usb_command_wrapper:2541: cb 0xffffff8000aa0148 (enter) Jun 20 13:53:10 riviera kernel: usbd_callback_wrapper:1922: case 1-4 Jun 20 13:53:10 riviera kernel: usbd_callback_wrapper_sub:2430: xfer=0xffffff8000aa0148 endpoint=0xffffff00165758d8 sts=22 alen=8, slen=26, afrm=1, nfrm=2 Jun 20 13:53:10 riviera kernel: usbd_do_request_callback:75: st=2 Jun 20 13:53:10 riviera kernel: usb_command_wrapper:2543: cb 0 (leave) Jun 20 13:53:10 riviera kernel: usbd_transfer_stop:1675: close Jun 20 13:53:10 riviera kernel: usbd_transfer_done:2077: err=USB_ERR_CANCELLED Jun 20 13:53:10 riviera kernel: usbd_transfer_done:2084: not transferring Jun 20 13:53:10 riviera kernel: usb_alloc_device:1628: addr=2, getting full desc failed Jun 20 13:53:10 riviera kernel: usb_free_device:1920: udev=0xffffff0016575800 port=1 Jun 20 13:53:10 riviera kernel: usb_set_device_state:2421: udev 0xffffff0016575800 state ADDRESSED -> DETACHED Jun 20 13:53:10 riviera kernel: ugen4.2: <(null)> at usbus4 (disconnected) Jun 20 13:53:10 riviera kernel: usb_detach_device:1037: udev=0xffffff0016575800 Jun 20 13:53:10 riviera kernel: usb_cdev_free:1887: Freeing device nodes Jun 20 13:53:10 riviera kernel: usb_config_parse:618: iface_index=255 cmd=1 Jun 20 13:53:10 riviera kernel: uhub_reattach_port:416: could not allocate new device! From owner-freebsd-current@FreeBSD.ORG Sat Jun 20 21:14:59 2009 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 345791065670; Sat, 20 Jun 2009 21:14:59 +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 0B9408FC1A; Sat, 20 Jun 2009 21:14:58 +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.3/8.14.3) with ESMTP id n5KLEsL1073155; Sat, 20 Jun 2009 17:14:54 -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.3/8.14.3) with ESMTP id n5KLEsgD025375; Sat, 20 Jun 2009 17:14:54 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 386F07302F; Sat, 20 Jun 2009 17:14:54 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090620211454.386F07302F@freebsd-current.sentex.ca> Date: Sat, 20 Jun 2009 17:14:54 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp1.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 205.211.164.50 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: Sat, 20 Jun 2009 21:14:59 -0000 TB --- 2009-06-20 19:17:06 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-06-20 19:17:06 - starting HEAD tinderbox run for ia64/ia64 TB --- 2009-06-20 19:17:07 - cleaning the object tree TB --- 2009-06-20 19:17:42 - cvsupping the source tree TB --- 2009-06-20 19:17:42 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/ia64/ia64/supfile TB --- 2009-06-20 19:17:52 - building world TB --- 2009-06-20 19:17:52 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-20 19:17:52 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-20 19:17:52 - TARGET=ia64 TB --- 2009-06-20 19:17:52 - TARGET_ARCH=ia64 TB --- 2009-06-20 19:17:52 - TZ=UTC TB --- 2009-06-20 19:17:52 - __MAKE_CONF=/dev/null TB --- 2009-06-20 19:17:52 - cd /src TB --- 2009-06-20 19:17:52 - /usr/bin/make -B buildworld >>> World build started on Sat Jun 20 19:17:54 UTC 2009 >>> 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 Sat Jun 20 21:07:21 UTC 2009 TB --- 2009-06-20 21:07:21 - generating LINT kernel config TB --- 2009-06-20 21:07:21 - cd /src/sys/ia64/conf TB --- 2009-06-20 21:07:21 - /usr/bin/make -B LINT TB --- 2009-06-20 21:07:21 - building LINT kernel TB --- 2009-06-20 21:07:21 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-20 21:07:21 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-20 21:07:21 - TARGET=ia64 TB --- 2009-06-20 21:07:21 - TARGET_ARCH=ia64 TB --- 2009-06-20 21:07:21 - TZ=UTC TB --- 2009-06-20 21:07:21 - __MAKE_CONF=/dev/null TB --- 2009-06-20 21:07:21 - cd /src TB --- 2009-06-20 21:07:21 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Jun 20 21:07:21 UTC 2009 >>> 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 [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/cxgb/cxgb_offload.c -I/src/sys/dev/cxgb cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/cxgb/cxgb_sge.c -I/src/sys/dev/cxgb In file included from /src/sys/dev/cxgb/cxgb_sge.c:68: /src/sys/dev/cxgb/sys/mvec.h: In function 'busdma_map_mbuf_fast': /src/sys/dev/cxgb/sys/mvec.h:55: error: dereferencing pointer to incomplete type cc1: warnings being treated as errors /src/sys/dev/cxgb/cxgb_sge.c: In function 'refill_fl': /src/sys/dev/cxgb/cxgb_sge.c:714: warning: suggest parentheses around assignment used as truth value *** Error code 1 Stop in /obj/ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-20 21:14:53 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-20 21:14:53 - ERROR: failed to build lint kernel TB --- 2009-06-20 21:14:53 - 5719.59 user 431.16 system 7067.08 real http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Sat Jun 20 22:44:02 2009 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 307B4106566C for ; Sat, 20 Jun 2009 22:44:01 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from poseidon.ceid.upatras.gr (poseidon.ceid.upatras.gr [150.140.141.169]) by mx1.freebsd.org (Postfix) with ESMTP id 9AD048FC08 for ; Sat, 20 Jun 2009 22:44:00 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from mail.ceid.upatras.gr (unknown [10.1.0.143]) by poseidon.ceid.upatras.gr (Postfix) with ESMTP id 66417EB54AB; Sun, 21 Jun 2009 01:15:55 +0300 (EEST) Received: from localhost (europa.ceid.upatras.gr [127.0.0.1]) by mail.ceid.upatras.gr (Postfix) with ESMTP id 46FB44513E; Sun, 21 Jun 2009 01:15:55 +0300 (EEST) X-Virus-Scanned: amavisd-new at ceid.upatras.gr Received: from mail.ceid.upatras.gr ([127.0.0.1]) by localhost (europa.ceid.upatras.gr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HlHStKWjgRn5; Sun, 21 Jun 2009 01:15:55 +0300 (EEST) Received: from kobe.laptop (ppp-94-66-2-34.home.otenet.gr [94.66.2.34]) by mail.ceid.upatras.gr (Postfix) with ESMTP id 03A604512A; Sun, 21 Jun 2009 01:15:54 +0300 (EEST) Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.3/8.14.3) with ESMTP id n5KMFssp002621; Sun, 21 Jun 2009 01:15:54 +0300 (EEST) (envelope-from keramida@freebsd.org) Received: (from keramida@localhost) by kobe.laptop (8.14.3/8.14.3/Submit) id n5KMFsUr002620; Sun, 21 Jun 2009 01:15:54 +0300 (EEST) (envelope-from keramida@freebsd.org) From: Giorgos Keramidas To: Alexander Best References: Date: Sun, 21 Jun 2009 01:15:47 +0300 In-Reply-To: (Alexander Best's message of "Tue, 16 Jun 2009 15:34:42 +0200 (CEST)") Message-ID: <87r5xepn58.fsf@kobe.laptop> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.94 (berkeley-unix) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Cc: freebsd-current@freebsd.org Subject: Re: WITHOUT_GAMES=true and /usr/games 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, 20 Jun 2009 22:44:03 -0000 --=-=-= On Tue, 16 Jun 2009 15:34:42 +0200 (CEST), Alexander Best wrote: > hi there, > > any reason installworld creates the games dir in /usr even though > /etc/src.conf states WITHOUT_GAMES=true. if nothing get's installed into the > dir buildworld might just as well not create it. or am i wrong? I have a local patch for a few months, that splits /var/games and /usr/games in their own mtree spec file. If it looks ok, I can always ask for commit approval and push it to svn: %%% # HG changeset patch # User Giorgos Keramidas # Date 1219869421 -10800 # Branch head # Node ID 017ed6c13a5438d2bd077c0930591aa7d88f0649 # Parent 5255edc94f3b20de0b976ff13d1c65b0d6b799ed Fix `make installworld' with WITHOUT_GAMES=yes. * Split off the parts of BSD.usr.dist and BSD.var.dist that depend on the 'games' user and group to BSD.games.dist. * Update etc/Makefile to use BSD.games.dist, but hide the relevant parts behind .if ${MK_GAMES} != "no". This way when installworld runs and WITHOUT_GAMES=yes, we don't even try to create the directories that belong to the games:games user. The rest of the source tree is already set up to avoid installing anything in those directories, and installworld runs to completion without any visible issues. Inspired by: A thread in freebsd-questions, started by Redd Vinylene [reddvinylene at gmail.com] diff -r 5255edc94f3b -r 017ed6c13a54 etc/Makefile --- a/etc/Makefile Thu Aug 14 15:55:01 2008 +0300 +++ b/etc/Makefile Wed Aug 27 23:37:01 2008 +0300 @@ -100,6 +100,9 @@ .if ${MK_SENDMAIL} != "no" MTREE+= BSD.sendmail.dist .endif +.if ${MK_GAMES} != "no" +MTREE+= BSD.games.dist +.endif .if ${MK_BIND} != "no" MTREE+= BIND.chroot.dist .if ${MK_BIND_LIBS} != "no" @@ -260,6 +263,9 @@ .if ${MK_SENDMAIL} != "no" mtree -deU ${MTREE_FOLLOWS_SYMLINKS} -f ${.CURDIR}/mtree/BSD.sendmail.dist -p ${DESTDIR}/ .endif +.if ${MK_GAMES} != "no" + mtree -deU ${MTREE_FOLLOWS_SYMLINKS} -f ${.CURDIR}/mtree/BSD.games.dist -p ${DESTDIR}/ +.endif cd ${DESTDIR}/; rm -f ${DESTDIR}/sys; ln -s usr/src/sys sys cd ${DESTDIR}/usr/share/man/en.ISO8859-1; ln -sf ../man* . cd ${DESTDIR}/usr/share/man/en.UTF-8; ln -sf ../man* . diff -r 5255edc94f3b -r 017ed6c13a54 etc/mtree/BSD.games.dist --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/etc/mtree/BSD.games.dist Wed Aug 27 23:37:01 2008 +0300 @@ -0,0 +1,16 @@ +# $FreeBSD$ +# +# Please see the file src/etc/mtree/README before making changes to this file. +# + +/set type=dir uname=root gname=wheel mode=0755 +. + usr + games + .. + .. + var + games gname=games mode=0775 + .. + .. +.. diff -r 5255edc94f3b -r 017ed6c13a54 etc/mtree/BSD.usr.dist --- a/etc/mtree/BSD.usr.dist Thu Aug 14 15:55:01 2008 +0300 +++ b/etc/mtree/BSD.usr.dist Wed Aug 27 23:37:01 2008 +0300 @@ -7,8 +7,6 @@ . bin .. - games - .. include .. lib diff -r 5255edc94f3b -r 017ed6c13a54 etc/mtree/BSD.var.dist --- a/etc/mtree/BSD.var.dist Thu Aug 14 15:55:01 2008 +0300 +++ b/etc/mtree/BSD.var.dist Wed Aug 27 23:37:01 2008 +0300 @@ -45,8 +45,6 @@ .. empty mode=0555 flags=schg .. - games gname=games mode=0775 - .. heimdal mode=0700 .. log %%% --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAko9X5kACgkQ1g+UGjGGA7bgRQCeICi1pvB0L5aBv6d1w0VGYmdA 0mEAn0kjM1TnP/M/OQ4HsvIgWoEb+3SP =t4VX -----END PGP SIGNATURE----- --=-=-=-- From owner-freebsd-current@FreeBSD.ORG Sat Jun 20 22:46:28 2009 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 E2C8D1065672; Sat, 20 Jun 2009 22:46:28 +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 A4DE58FC0A; Sat, 20 Jun 2009 22:46:28 +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.3/8.14.3) with ESMTP id n5KMkOHu079011; Sat, 20 Jun 2009 18:46:24 -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.3/8.14.3) with ESMTP id n5KMkOIM067146; Sat, 20 Jun 2009 18:46:24 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 15DBD7302F; Sat, 20 Jun 2009 18:46:24 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090620224624.15DBD7302F@freebsd-current.sentex.ca> Date: Sat, 20 Jun 2009 18:46:24 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp1.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 205.211.164.50 Cc: Subject: [head tinderbox] failure on sparc64/sparc64 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: Sat, 20 Jun 2009 22:46:30 -0000 TB --- 2009-06-20 21:19:06 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-06-20 21:19:06 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2009-06-20 21:19:06 - cleaning the object tree TB --- 2009-06-20 21:19:29 - cvsupping the source tree TB --- 2009-06-20 21:19:29 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2009-06-20 21:19:37 - building world TB --- 2009-06-20 21:19:37 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-20 21:19:37 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-20 21:19:37 - TARGET=sparc64 TB --- 2009-06-20 21:19:37 - TARGET_ARCH=sparc64 TB --- 2009-06-20 21:19:37 - TZ=UTC TB --- 2009-06-20 21:19:37 - __MAKE_CONF=/dev/null TB --- 2009-06-20 21:19:37 - cd /src TB --- 2009-06-20 21:19:37 - /usr/bin/make -B buildworld >>> World build started on Sat Jun 20 21:19:39 UTC 2009 >>> 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 Sat Jun 20 22:40:07 UTC 2009 TB --- 2009-06-20 22:40:07 - generating LINT kernel config TB --- 2009-06-20 22:40:07 - cd /src/sys/sparc64/conf TB --- 2009-06-20 22:40:07 - /usr/bin/make -B LINT TB --- 2009-06-20 22:40:07 - building LINT kernel TB --- 2009-06-20 22:40:07 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-20 22:40:07 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-20 22:40:07 - TARGET=sparc64 TB --- 2009-06-20 22:40:07 - TARGET_ARCH=sparc64 TB --- 2009-06-20 22:40:07 - TZ=UTC TB --- 2009-06-20 22:40:07 - __MAKE_CONF=/dev/null TB --- 2009-06-20 22:40:07 - cd /src TB --- 2009-06-20 22:40:07 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Jun 20 22:40:07 UTC 2009 >>> 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 [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/cxgb/common/cxgb_mv88e1xxx.c -I/src/sys/dev/cxgb cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/cxgb/common/cxgb_xgmac.c -I/src/sys/dev/cxgb cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/cxgb/common/cxgb_t3_hw.c -I/src/sys/dev/cxgb cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/cxgb/common/cxgb_tn1010.c -I/src/sys/dev/cxgb cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/cxgb/sys/uipc_mvec.c -I/src/sys/dev/cxgb cc1: warnings being treated as errors /src/sys/dev/cxgb/sys/uipc_mvec.c: In function 'busdma_map_sg_collapse': /src/sys/dev/cxgb/sys/uipc_mvec.c:93: warning: passing argument 3 of 'txq->entry_tag->dt_mt->dm_dmamap_load_mbuf_sg' from incompatible pointer type *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-20 22:46:23 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-20 22:46:23 - ERROR: failed to build lint kernel TB --- 2009-06-20 22:46:23 - 4097.41 user 410.33 system 5237.10 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Sat Jun 20 22:47:13 2009 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 53B631065676; Sat, 20 Jun 2009 22:47:13 +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 1679F8FC27; Sat, 20 Jun 2009 22:47:12 +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.3/8.14.3) with ESMTP id n5KMl9du079099; Sat, 20 Jun 2009 18:47:09 -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.3/8.14.3) with ESMTP id n5KMl9u0067448; Sat, 20 Jun 2009 18:47:09 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id C4D2F7302F; Sat, 20 Jun 2009 18:47:08 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090620224708.C4D2F7302F@freebsd-current.sentex.ca> Date: Sat, 20 Jun 2009 18:47:08 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp1.sentex.ca 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: Sat, 20 Jun 2009 22:47:14 -0000 TB --- 2009-06-20 21:14:54 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-06-20 21:14:54 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2009-06-20 21:14:54 - cleaning the object tree TB --- 2009-06-20 21:15:28 - cvsupping the source tree TB --- 2009-06-20 21:15:28 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2009-06-20 21:15:36 - building world TB --- 2009-06-20 21:15:36 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-20 21:15:36 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-20 21:15:36 - TARGET=powerpc TB --- 2009-06-20 21:15:36 - TARGET_ARCH=powerpc TB --- 2009-06-20 21:15:36 - TZ=UTC TB --- 2009-06-20 21:15:36 - __MAKE_CONF=/dev/null TB --- 2009-06-20 21:15:36 - cd /src TB --- 2009-06-20 21:15:36 - /usr/bin/make -B buildworld >>> World build started on Sat Jun 20 21:15:38 UTC 2009 >>> 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 Sat Jun 20 22:40:57 UTC 2009 TB --- 2009-06-20 22:40:57 - generating LINT kernel config TB --- 2009-06-20 22:40:57 - cd /src/sys/powerpc/conf TB --- 2009-06-20 22:40:57 - /usr/bin/make -B LINT TB --- 2009-06-20 22:40:57 - building LINT kernel TB --- 2009-06-20 22:40:57 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-20 22:40:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-20 22:40:57 - TARGET=powerpc TB --- 2009-06-20 22:40:57 - TARGET_ARCH=powerpc TB --- 2009-06-20 22:40:57 - TZ=UTC TB --- 2009-06-20 22:40:57 - __MAKE_CONF=/dev/null TB --- 2009-06-20 22:40:57 - cd /src TB --- 2009-06-20 22:40:57 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Jun 20 22:40:58 UTC 2009 >>> 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 [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/cxgb/common/cxgb_mv88e1xxx.c -I/src/sys/dev/cxgb cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/cxgb/common/cxgb_xgmac.c -I/src/sys/dev/cxgb cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/cxgb/common/cxgb_t3_hw.c -I/src/sys/dev/cxgb cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/cxgb/common/cxgb_tn1010.c -I/src/sys/dev/cxgb cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/cxgb/sys/uipc_mvec.c -I/src/sys/dev/cxgb cc1: warnings being treated as errors /src/sys/dev/cxgb/sys/uipc_mvec.c: In function 'busdma_map_sg_collapse': /src/sys/dev/cxgb/sys/uipc_mvec.c:94: warning: passing argument 3 of 'bus_dmamap_load_mbuf_sg' from incompatible pointer type *** Error code 1 Stop in /obj/powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-20 22:47:08 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-20 22:47:08 - ERROR: failed to build lint kernel TB --- 2009-06-20 22:47:08 - 4338.12 user 417.45 system 5534.43 real http://tinderbox.des.no/tinderbox-head-HEAD-powerpc-powerpc.full