From owner-freebsd-hackers@FreeBSD.ORG Sun Aug 8 01:58:05 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AB34F1065677; Sun, 8 Aug 2010 01:58:05 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 304B58FC15; Sun, 8 Aug 2010 01:58:04 +0000 (UTC) Received: by qwg5 with SMTP id 5so5019913qwg.13 for ; Sat, 07 Aug 2010 18:58:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received:from:date :x-google-sender-auth:message-id:subject:to:content-type; bh=jBE+L73ix3z1Tos4QtHAuLwsi46t5VLZzSVwncCfqbU=; b=uUR5+2SSrAF7mZymGzJXeRG9wOXByPeiwqCINt+dHY9vFKZK7mN+vQJIseEXLGLieP //z3xp68VRG4iBEjkDlzjNq9KELtfQW9bR/ZOMgxUJ598UpL38/qwpACfOasL3brgLtF CA7OHoix5tWn5fwAq7LiEFwM3HopC6Vw4jIp0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:from:date:x-google-sender-auth:message-id :subject:to:content-type; b=t8fGv3B9iJNB8SAHgXrO0hVKOjxG0kL8KzvFjoh1rEWAXIDMp9HHN5iBbsL68LEj+n BkPJuAW9/OH50dY7qlts0i1ofE+k6xAMkmCrggxBeTLGmV3Vy6JANTzWhOuJqlkdRb5R zHCKdyXMGAjkjEgisigHlMtdj2h77xapVAa+k= Received: by 10.229.220.20 with SMTP id hw20mr6063242qcb.94.1281232684213; Sat, 07 Aug 2010 18:58:04 -0700 (PDT) MIME-Version: 1.0 Sender: ivoras@gmail.com Received: by 10.229.236.132 with HTTP; Sat, 7 Aug 2010 18:57:44 -0700 (PDT) From: Ivan Voras Date: Sun, 8 Aug 2010 03:57:44 +0200 X-Google-Sender-Auth: vwreAXHwgWrq2moCGdW1UbLKvlk Message-ID: To: Pawel Jakub Dawidek , freebsd-geom@freebsd.org, freebsd-hackers Content-Type: text/plain; charset=UTF-8 Cc: Subject: glabel "force sectorsize" patch X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Aug 2010 01:58:05 -0000 Hi, In order to help users having 4k sector drives which the system recognizes as 512 byte sector drives, I'm proposing a patch to glabel which enables it to use a forced sector size for its native-labeled providers. It is naturally only usable with glabel-native labels (those created by "glabel label") and not partition and file system labels because we cannot add arbitrary new fields to metadata of those types. The patch is here: http://people.freebsd.org/~ivoras/diffs/glabel_ssize.patch It's tested with UFS+SU and a forced 4k sector size - apparently there are no problems here. Here's how a dumpfs output looks like from the test file system with completely default newfs options (except SU): magic 19540119 (UFS2) time Sun Aug 8 03:40:47 2010 superblock location 65536 id [ 4c5e0ab3 41c7e8d9 ] ncg 7 size 524287 blocks 514774 bsize 16384 shift 14 mask 0xffffc000 fsize 4096 shift 12 mask 0xfffff000 frag 4 shift 2 fsbtodb 3 minfree 8% optim time symlinklen 120 maxbsize 16384 maxbpg 2048 maxcontig 8 contigsumsize 8 nbfree 128690 ndir 2 nifree 150972 nffree 12 bpg 21567 fpg 86268 ipg 21568 unrefs 0 nindir 2048 inopb 64 maxfilesize 140806241583103 sbsize 4096 cgsize 16384 csaddr 1376 cssize 4096 sblkno 20 cblkno 24 iblkno 28 dblkno 1376 cgrotor 0 fmod 0 ronly 0 clean 1 avgfpdir 64 avgfilesize 16384 flags soft-updates fsmnt /mt volname swuid 0 This is a pre-commit review request and also a call for testers :) This mechanism is a band-aid until there's a better way of dealing with 4k drives. From owner-freebsd-hackers@FreeBSD.ORG Sun Aug 8 09:31:46 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 55F0A1065670; Sun, 8 Aug 2010 09:31:46 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0368A8FC08; Sun, 8 Aug 2010 09:31:45 +0000 (UTC) Received: by iwn10 with SMTP id 10so3559613iwn.13 for ; Sun, 08 Aug 2010 02:31:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=Ylt6AJKNiVwM8tsGsK2Ti+TqgeamEbK5T8kPSooDH7A=; b=u45Zteh3N6I5vsau6bJDSb/+eLu4x3ctDV89SfMVeILnmwkiEF0WSEpCy04l7gJvrQ /W2+CKgXNffcf82BkBslzRrj+piXoewtPHfsgP5TO12EI/qznj5lKGRo5QyQXS8PeAWB ux5YMk1tgPxFdB3EjLn32Ca9N93wgTsabuXjc= 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=G3wdy4R+c/A6/ik2pN80imvY/5GVHTRaYAKx3ne24iS1bO80c8TcdWuW4PN1ft7Z9z 5Ew7x+C8JdB1lFyvGzQEkCK2NAOSah8ZbMqWh74oJuaTMwEhvswaWHmv5241SEpF7mM3 9nnDXULmXJR8axqeKLbVzXX4ZbSB3F823IIkQ= MIME-Version: 1.0 Received: by 10.231.17.1 with SMTP id q1mr5078154iba.17.1281259904995; Sun, 08 Aug 2010 02:31:44 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.231.173.133 with HTTP; Sun, 8 Aug 2010 02:31:44 -0700 (PDT) In-Reply-To: References: <86fwyq8rsc.fsf@ds4.des.no> <86d3tujh72.fsf@ds4.des.no> <864of680wv.fsf@ds4.des.no> Date: Sun, 8 Aug 2010 02:31:44 -0700 X-Google-Sender-Auth: hvrCItECn4QhssyutzzY9fx7_oY Message-ID: From: Garrett Cooper To: Ivan Voras Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: =?ISO-8859-1?Q?Dag=2DErling_Sm=F8rgrav?= , freebsd-hackers@freebsd.org Subject: Re: Why is TUNABLE_INT discouraged? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Aug 2010 09:31:46 -0000 2010/8/7 Ivan Voras : > 2010/8/8 Dag-Erling Sm=F8rgrav : >> Garrett Cooper writes: >>> Dag-Erling Sm=F8rgrav writes: >>> > Perhaps. =A0I don't remember all the details; I can't find a discussi= on in >>> > the list archives (other than me announcing the change in response to= a >>> > bug report), but there must have been one, either on IRC or in Karlsr= uhe. >>> > In any case, I never removed TUNABLE_INT(), so... >>> It does matter for integers on 64-bit vs 32-bit architectures though, >>> right >> >> Not sure what you mean. =A0The original issue was that someone had used >> TUNABLE_INT() for something that was actually a memory address. =A0I >> changed it to TUNABLE_ULONG(). =A0Of course, if your tunable is a boolea= n >> value or something like maxprocs, an int is fine - but so is a long. Why would someone express a tunable in a memory address (not being sarcastic... I just don't see why it makes sense right now, but if there's a valid reason I'm more than happy to be educated :)..)? > Semantically valid but using TUNABLE_INT to hold pointers is a > developer bug, not the fault of the API, and there's nothing wrong > with "int" as a data type in this context. > > Unless there is a real hidden danger in using TUNABLE_INT (and/or > adding TUNABLE_UINT etc.) in the expected way, I'd vote for either > removing the cautioning comment or rewriting it to say something like > "developers are hereby warned that ints cannot hold pointers on all > architectures", if it is indeed such a little known fact among kernel > developers :P *grins cheekily in agreement* :). Thanks, -Garrett From owner-freebsd-hackers@FreeBSD.ORG Sun Aug 8 10:52:21 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 69A631065673; Sun, 8 Aug 2010 10:52:21 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello089077043238.chello.pl [89.77.43.238]) by mx1.freebsd.org (Postfix) with ESMTP id ABD1E8FC1F; Sun, 8 Aug 2010 10:52:20 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id D1B4B45CA6; Sun, 8 Aug 2010 12:31:09 +0200 (CEST) Received: from localhost (chello089077043238.chello.pl [89.77.43.238]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 1DB5045684; Sun, 8 Aug 2010 12:31:04 +0200 (CEST) Date: Sun, 8 Aug 2010 12:30:55 +0200 From: Pawel Jakub Dawidek To: Ivan Voras Message-ID: <20100808103055.GA2037@garage.freebsd.pl> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jI8keyz6grp/JLjh" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 9.0-CURRENT amd64 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-hackers , freebsd-geom@freebsd.org Subject: Re: glabel "force sectorsize" patch X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Aug 2010 10:52:21 -0000 --jI8keyz6grp/JLjh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Aug 08, 2010 at 03:57:44AM +0200, Ivan Voras wrote: > Hi, >=20 > In order to help users having 4k sector drives which the system > recognizes as 512 byte sector drives, I'm proposing a patch to glabel > which enables it to use a forced sector size for its native-labeled > providers. It is naturally only usable with glabel-native labels > (those created by "glabel label") and not partition and file system > labels because we cannot add arbitrary new fields to metadata of those > types. >=20 > The patch is here: >=20 > http://people.freebsd.org/~ivoras/diffs/glabel_ssize.patch [...] > This mechanism is a band-aid until there's a better way of dealing > with 4k drives. So why do you want to obfuscate glabel with it? For people to start depend on it? Once we start supporting 4kB sectors what do we do with such a change? Remove it and decrease version number? What people will do with providers already labeled this way? If its temporary, just allow to list providers you want to increase sector size in /boot/loader.conf. Once we start supporting it properly people might simply remove it from loader.conf and it should just work. Glabel is not for that and I don't agree for such obfuscation. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --jI8keyz6grp/JLjh Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkxeh14ACgkQForvXbEpPzSL+wCguHzlZWPslLkwvdgXMEAXlhgl ztUAoJnJxtZhVFmO1NQuybFlFiyOkI77 =sttd -----END PGP SIGNATURE----- --jI8keyz6grp/JLjh-- From owner-freebsd-hackers@FreeBSD.ORG Sun Aug 8 12:37:10 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EA0F81065674; Sun, 8 Aug 2010 12:37:09 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello089077043238.chello.pl [89.77.43.238]) by mx1.freebsd.org (Postfix) with ESMTP id 3F7C98FC1F; Sun, 8 Aug 2010 12:37:08 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 5873B45D8D; Sun, 8 Aug 2010 14:37:07 +0200 (CEST) Received: from localhost (chello089077043238.chello.pl [89.77.43.238]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id D4C4A45C89; Sun, 8 Aug 2010 14:37:01 +0200 (CEST) Date: Sun, 8 Aug 2010 14:36:53 +0200 From: Pawel Jakub Dawidek To: Ivan Voras Message-ID: <20100808123653.GC2037@garage.freebsd.pl> References: <20100808103055.GA2037@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xo44VMWPx7vlQ2+2" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 9.0-CURRENT amd64 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-hackers@freebsd.org, freebsd-current@freebsd.org, freebsd-geom@freebsd.org Subject: Re: glabel "force sectorsize" patch X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Aug 2010 12:37:10 -0000 --xo44VMWPx7vlQ2+2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Aug 08, 2010 at 02:02:17PM +0200, Ivan Voras wrote: > On 8.8.2010 12:30, Pawel Jakub Dawidek wrote: > > So why do you want to obfuscate glabel with it? For people to start > > depend on it? Once we start supporting 4kB sectors what do we do with > > such a change? Remove it and decrease version number? What people will > > do with providers already labeled this way? > >=20 > > If its temporary, just allow to list providers you want to increase > > sector size in /boot/loader.conf. Once we start supporting it properly > > people might simply remove it from loader.conf and it should just work. > >=20 > > Glabel is not for that and I don't agree for such obfuscation. >=20 > Of course, there are good and bad sides to it. My take on it is that the > only bad side is that it really isn't glabel's primary function to > (optionally) fixup geometry, while the good sides are: It isn't its secondary function either. > * glabel is in GENERIC and judging by the mailing lists' traffic it is > one of the better used parts of the system so people are familiar with > it. It is also already used as a perfectly valid fixup for device > renaming, making both UFS and ZFS more stable for usage. That's an excellent argument. But you know what? The em(4) is also in GENERIC, why not to add it in there? > * You can't really "make people depend on glabel" both because it is in > GENERIC and because of it storing metadata in the last sector, making > the rest of the drive completely usable without it in the event native > 4k sector support is grown. I never said that. I do want people to depend on glabel, because it is free of such ugly hacks, so I know it won't bite them in the future. I don't want people to start depend on the fact that glabel supports changing sector sizes. Once we start supporting 4kB sectors properly people configuration will stop working, because glabel won't be able to read its metadata anymore. Your hack will break all configurations that started to depend on your hack. In what I proposed, GEOM provider will be presented to glabel (or any other GEOM class) as 4kB provider and everything will just work, also after adding proper support for 4kB sectors. > I'd like to hear comments from the wider audience. In respect with your > comment, I will compromise: as 4k sector drives have become available > over the counter more than 6 months ago and so far I think this is the > first effort to give some support for them, I will commit this patch > before 9.0 code freeze only if no other support gets developed. I'll repeat. You won't commit this patch, because it is totally wrong solution and can only do a lot of damage in the future. If you look forward, even temporary solutions can be done right. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --xo44VMWPx7vlQ2+2 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkxepOUACgkQForvXbEpPzTsugCgzpbR4hcr74ZwU9NFoiUibiyx eF0An1jqSoN7hiDyIAL0r80ZtVVei9GG =KZuE -----END PGP SIGNATURE----- --xo44VMWPx7vlQ2+2-- From owner-freebsd-hackers@FreeBSD.ORG Sun Aug 8 13:06:26 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6B2A81065675; Sun, 8 Aug 2010 13:06:26 +0000 (UTC) (envelope-from emaste@freebsd.org) Received: from mail1.sandvine.com (mail1.sandvine.com [64.7.137.162]) by mx1.freebsd.org (Postfix) with ESMTP id D96C08FC15; Sun, 8 Aug 2010 13:06:25 +0000 (UTC) Received: from labgw2.phaedrus.sandvine.com (192.168.222.22) by WTL-EXCH-1.sandvine.com (192.168.196.31) with Microsoft SMTP Server id 14.0.694.0; Sun, 8 Aug 2010 09:06:23 -0400 Received: by labgw2.phaedrus.sandvine.com (Postfix, from userid 10332) id 1514F33C00; Sun, 8 Aug 2010 09:06:25 -0400 (EDT) Date: Sun, 8 Aug 2010 09:06:25 -0400 From: Ed Maste To: Ivan Voras Message-ID: <20100808130624.GB40928@sandvine.com> References: <86fwyq8rsc.fsf@ds4.des.no> <86d3tujh72.fsf@ds4.des.no> <864of680wv.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: Dag-Erling Sm??rgrav , Garrett, Cooper , freebsd-hackers@freebsd.org Subject: Re: Why is TUNABLE_INT discouraged? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Aug 2010 13:06:26 -0000 On Sun, Aug 08, 2010 at 01:30:19AM +0200, Ivan Voras wrote: > 2010/8/8 Dag-Erling Sm??rgrav : > > Garrett Cooper writes: > >> Dag-Erling Sm??rgrav writes: > >> > Perhaps. ??I don't remember all the details; I can't find a discussion in > >> > the list archives (other than me announcing the change in response to a > >> > bug report), but there must have been one, either on IRC or in Karlsruhe. > >> > In any case, I never removed TUNABLE_INT(), so... > >> It does matter for integers on 64-bit vs 32-bit architectures though, > >> right > > > > Not sure what you mean. ??The original issue was that someone had used > > TUNABLE_INT() for something that was actually a memory address. ??I > > changed it to TUNABLE_ULONG(). ??Of course, if your tunable is a boolean > > value or something like maxprocs, an int is fine - but so is a long. > > Semantically valid but using TUNABLE_INT to hold pointers is a > developer bug, not the fault of the API, and there's nothing wrong > with "int" as a data type in this context. I agree with Ivan here. If we can't find an actual reason to universally prefer long I'd like to remove this comment. As a counterpoint to the preference for long I can offer a reason to prefer int: the same variable is often exposed by both a tunable and a sysctls, and a sysctl using long can have 32-bit compat issues. (That is, a 32-bit app using sysctlbyname will try to use 4 bytes for a long.) -Ed From owner-freebsd-hackers@FreeBSD.ORG Sun Aug 8 13:07:25 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C65B31065692; Sun, 8 Aug 2010 13:07:25 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello089077043238.chello.pl [89.77.43.238]) by mx1.freebsd.org (Postfix) with ESMTP id 113BB8FC21; Sun, 8 Aug 2010 13:07:24 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id BA9DA45E82; Sun, 8 Aug 2010 15:07:23 +0200 (CEST) Received: from localhost (chello089077043238.chello.pl [89.77.43.238]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 8A19845D8D; Sun, 8 Aug 2010 15:07:18 +0200 (CEST) Date: Sun, 8 Aug 2010 15:07:09 +0200 From: Pawel Jakub Dawidek To: Marius =?iso-8859-1?Q?N=FCnnerich?= Message-ID: <20100808130709.GD2037@garage.freebsd.pl> References: <20100808103055.GA2037@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wLAMOaPNJ0fu1fTG" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 9.0-CURRENT amd64 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-hackers@freebsd.org, freebsd-current@freebsd.org, Ivan Voras , freebsd-geom@freebsd.org Subject: Re: glabel "force sectorsize" patch X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Aug 2010 13:07:25 -0000 --wLAMOaPNJ0fu1fTG Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Aug 08, 2010 at 02:57:20PM +0200, Marius N=FCnnerich wrote: > On Sun, Aug 8, 2010 at 14:02, Ivan Voras wrote: > > I'd like to hear comments from the wider audience. In respect with your > > comment, I will compromise: as 4k sector drives have become available > > over the counter more than 6 months ago and so far I think this is the > > first effort to give some support for them, I will commit this patch > > before 9.0 code freeze only if no other support gets developed. >=20 > I do not like this at all. Even if it's just for the KISS and POLA > principles. A geom should do one thing and do it right imo. > Why not write a new geom class that does what you want? New GEOM class only for sectorsize conversion that can operate on metadata will be useful, not only to solve this particular problem. Although keep in mind that if at some point disks will be detected and presented as 4kB providers to the GEOM, this class won't be able to find its metadata anymore (as it was stored in the last 512 bytes, not in the last 4 kilobytes). --=20 Pawel Jakub Dawidek http://www.wheelsystems.com pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --wLAMOaPNJ0fu1fTG Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkxeq/0ACgkQForvXbEpPzSslACffbs/r5gFexV0pRgsaN76YDej ONEAoIpXoEgrLqpWXs7Vk4kryYTyvWUu =mN1A -----END PGP SIGNATURE----- --wLAMOaPNJ0fu1fTG-- From owner-freebsd-hackers@FreeBSD.ORG Sun Aug 8 13:27:40 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9EEF41065677; Sun, 8 Aug 2010 13:27:40 +0000 (UTC) (envelope-from marius@nuenneri.ch) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 45BBF8FC15; Sun, 8 Aug 2010 13:27:39 +0000 (UTC) Received: by qwg5 with SMTP id 5so5312639qwg.13 for ; Sun, 08 Aug 2010 06:27:39 -0700 (PDT) Received: by 10.224.69.17 with SMTP id x17mr7580311qai.283.1281272260167; Sun, 08 Aug 2010 05:57:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.219.17 with HTTP; Sun, 8 Aug 2010 05:57:20 -0700 (PDT) In-Reply-To: References: <20100808103055.GA2037@garage.freebsd.pl> From: =?UTF-8?Q?Marius_N=C3=BCnnerich?= Date: Sun, 8 Aug 2010 14:57:20 +0200 Message-ID: To: Ivan Voras Content-Type: text/plain; charset=UTF-8 Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, freebsd-geom@freebsd.org Subject: Re: glabel "force sectorsize" patch X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Aug 2010 13:27:40 -0000 On Sun, Aug 8, 2010 at 14:02, Ivan Voras wrote: > On 8.8.2010 12:30, Pawel Jakub Dawidek wrote: >> On Sun, Aug 08, 2010 at 03:57:44AM +0200, Ivan Voras wrote: >>> Hi, >>> >>> In order to help users having 4k sector drives which the system >>> recognizes as 512 byte sector drives, I'm proposing a patch to glabel >>> which enables it to use a forced sector size for its native-labeled >>> providers. It is naturally only usable with glabel-native labels >>> (those created by "glabel label") and not partition and file system >>> labels because we cannot add arbitrary new fields to metadata of those >>> types. >>> >>> The patch is here: >>> >>> http://people.freebsd.org/~ivoras/diffs/glabel_ssize.patch >> [...] >>> This mechanism is a band-aid until there's a better way of dealing >>> with 4k drives. >> >> So why do you want to obfuscate glabel with it? For people to start >> depend on it? Once we start supporting 4kB sectors what do we do with >> such a change? Remove it and decrease version number? What people will >> do with providers already labeled this way? >> >> If its temporary, just allow to list providers you want to increase >> sector size in /boot/loader.conf. Once we start supporting it properly >> people might simply remove it from loader.conf and it should just work. >> >> Glabel is not for that and I don't agree for such obfuscation. > > Of course, there are good and bad sides to it. My take on it is that the > only bad side is that it really isn't glabel's primary function to > (optionally) fixup geometry, while the good sides are: > > * glabel is in GENERIC and judging by the mailing lists' traffic it is > one of the better used parts of the system so people are familiar with > it. It is also already used as a perfectly valid fixup for device > renaming, making both UFS and ZFS more stable for usage. > > * You can't really "make people depend on glabel" both because it is in > GENERIC and because of it storing metadata in the last sector, making > the rest of the drive completely usable without it in the event native > 4k sector support is grown. > > I'd like to hear comments from the wider audience. In respect with your > comment, I will compromise: as 4k sector drives have become available > over the counter more than 6 months ago and so far I think this is the > first effort to give some support for them, I will commit this patch > before 9.0 code freeze only if no other support gets developed. I do not like this at all. Even if it's just for the KISS and POLA principles. A geom should do one thing and do it right imo. Why not write a new geom class that does what you want? From owner-freebsd-hackers@FreeBSD.ORG Sun Aug 8 14:43:53 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 85CAE1065674; Sun, 8 Aug 2010 14:43:53 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 1A2AD8FC1B; Sun, 8 Aug 2010 14:43:52 +0000 (UTC) Received: by qwg5 with SMTP id 5so5354712qwg.13 for ; Sun, 08 Aug 2010 07:43:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=lVdDu3IReGaMf3QYBVrAYULbBp2V990F+GoO4UvOtQU=; b=EF9zX7slE9R+LzMbg3vjGUWTcxvO+nfUYtG+zfZ0y1DzrolAAktUBe9enBAnC5LNet pv5cAihOHlnNSxBK3RBwzN4Ov91Sk5Z5Yu23Zt58AI5P3A8BRCQR7fgnT+OwPEXhDb45 SX2j6XmDJIYE0c4FraJjXCdr43zZYeEwpMz5g= 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=mNKg7KVUiehouEdBGnTQZO47ZokRoixoV9KfH2TAE0UR0WNhvArK7tHSPC6SkDRago 4+rp9hTolmTGVRLV4Uz1xFgaOMgRBxNpMaFnEeQ7R6xPGQL4F7LSMdws7kaiREkGLk4d 5MVlqODiTy1eHlxiFm3bsBM8xbNtDWw4MOcpI= MIME-Version: 1.0 Received: by 10.229.1.223 with SMTP id 31mr6252035qcg.298.1281278632201; Sun, 08 Aug 2010 07:43:52 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.229.251.6 with HTTP; Sun, 8 Aug 2010 07:43:52 -0700 (PDT) In-Reply-To: References: <201007301008.22501.jhb@freebsd.org> <201007301031.34266.jhb@freebsd.org> Date: Sun, 8 Aug 2010 16:43:52 +0200 X-Google-Sender-Auth: DpuFdPEWmjxRqByvtsmBF80WECQ Message-ID: From: Attilio Rao To: mdf@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: sched_pin() versus PCPU_GET X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Aug 2010 14:43:53 -0000 2010/8/4 : > On Fri, Jul 30, 2010 at 2:31 PM, John Baldwin wrote: >> On Friday, July 30, 2010 10:08:22 am John Baldwin wrote: >>> On Thursday, July 29, 2010 7:39:02 pm mdf@freebsd.org wrote: >>> > We've seen a few instances at work where witness_warn() in ast() >>> > indicates the sched lock is still held, but the place it claims it wa= s >>> > held by is in fact sometimes not possible to keep the lock, like: >>> > >>> > =C2=A0 =C2=A0 thread_lock(td); >>> > =C2=A0 =C2=A0 td->td_flags &=3D ~TDF_SELECT; >>> > =C2=A0 =C2=A0 thread_unlock(td); >>> > >>> > What I was wondering is, even though the assembly I see in objdump -S >>> > for witness_warn has the increment of td_pinned before the PCPU_GET: >>> > >>> > ffffffff802db210: =C2=A0 65 48 8b 1c 25 00 00 =C2=A0 =C2=A0mov =C2=A0= =C2=A0%gs:0x0,%rbx >>> > ffffffff802db217: =C2=A0 00 00 >>> > ffffffff802db219: =C2=A0 ff 83 04 01 00 00 =C2=A0 =C2=A0 =C2=A0 incl = =C2=A0 0x104(%rbx) >>> > =C2=A0 =C2=A0 =C2=A0* Pin the thread in order to avoid problems with = thread migration. >>> > =C2=A0 =C2=A0 =C2=A0* Once that all verifies are passed about spinloc= ks ownership, >>> > =C2=A0 =C2=A0 =C2=A0* the thread is in a safe path and it can be unpi= nned. >>> > =C2=A0 =C2=A0 =C2=A0*/ >>> > =C2=A0 =C2=A0 sched_pin(); >>> > =C2=A0 =C2=A0 lock_list =3D PCPU_GET(spinlocks); >>> > ffffffff802db21f: =C2=A0 65 48 8b 04 25 48 00 =C2=A0 =C2=A0mov =C2=A0= =C2=A0%gs:0x48,%rax >>> > ffffffff802db226: =C2=A0 00 00 >>> > =C2=A0 =C2=A0 if (lock_list !=3D NULL && lock_list->ll_count !=3D 0) = { >>> > ffffffff802db228: =C2=A0 48 85 c0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0test =C2=A0 %rax,%rax >>> > =C2=A0 =C2=A0 =C2=A0* Pin the thread in order to avoid problems with = thread migration. >>> > =C2=A0 =C2=A0 =C2=A0* Once that all verifies are passed about spinloc= ks ownership, >>> > =C2=A0 =C2=A0 =C2=A0* the thread is in a safe path and it can be unpi= nned. >>> > =C2=A0 =C2=A0 =C2=A0*/ >>> > =C2=A0 =C2=A0 sched_pin(); >>> > =C2=A0 =C2=A0 lock_list =3D PCPU_GET(spinlocks); >>> > ffffffff802db22b: =C2=A0 48 89 85 f0 fe ff ff =C2=A0 =C2=A0mov =C2=A0= =C2=A0%rax,-0x110(%rbp) >>> > ffffffff802db232: =C2=A0 48 89 85 f8 fe ff ff =C2=A0 =C2=A0mov =C2=A0= =C2=A0%rax,-0x108(%rbp) >>> > =C2=A0 =C2=A0 if (lock_list !=3D NULL && lock_list->ll_count !=3D 0) = { >>> > ffffffff802db239: =C2=A0 0f 84 ff 00 00 00 =C2=A0 =C2=A0 =C2=A0 je = =C2=A0 =C2=A0 ffffffff802db33e >>> > >>> > ffffffff802db23f: =C2=A0 44 8b 60 50 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 mov =C2=A0 =C2=A00x50(%rax),%r12d >>> > >>> > is it possible for the hardware to do any re-ordering here? >>> > >>> > The reason I'm suspicious is not just that the code doesn't have a >>> > lock leak at the indicated point, but in one instance I can see in th= e >>> > dump that the lock_list local from witness_warn is from the pcpu >>> > structure for CPU 0 (and I was warned about sched lock 0), but the >>> > thread id in panic_cpu is 2. =C2=A0So clearly the thread was being mi= grated >>> > right around panic time. >>> > >>> > This is the amd64 kernel on stable/7. =C2=A0I'm not sure exactly what= kind >>> > of hardware; it's a 4-way Intel chip from about 3 or 4 years ago IIRC= . >>> > >>> > So... do we need some kind of barrier in the code for sched_pin() for >>> > it to really do what it claims? =C2=A0Could the hardware have re-orde= red >>> > the "mov =C2=A0 =C2=A0%gs:0x48,%rax" PCPU_GET to before the sched_pin= () >>> > increment? >>> >>> Hmmm, I think it might be able to because they refer to different locat= ions. >>> >>> Note this rule in section 8.2.2 of Volume 3A: >>> >>> =C2=A0 =E2=80=A2 Reads may be reordered with older writes to different = locations but not >>> =C2=A0 =C2=A0 with older writes to the same location. >>> >>> It is certainly true that sparc64 could reorder with RMO. =C2=A0I belie= ve ia64 >>> could reorder as well. =C2=A0Since sched_pin/unpin are frequently used = to provide >>> this sort of synchronization, we could use memory barriers in pin/unpin >>> like so: >>> >>> sched_pin() >>> { >>> =C2=A0 =C2=A0 =C2=A0 td->td_pinned =3D atomic_load_acq_int(&td->td_pinn= ed) + 1; >>> } >>> >>> sched_unpin() >>> { >>> =C2=A0 =C2=A0 =C2=A0 atomic_store_rel_int(&td->td_pinned, td->td_pinned= - 1); >>> } >>> >>> We could also just use atomic_add_acq_int() and atomic_sub_rel_int(), b= ut they >>> are slightly more heavyweight, though it would be more clear what is ha= ppening >>> I think. >> >> However, to actually get a race you'd have to have an interrupt fire and >> migrate you so that the speculative read was from the other CPU. =C2=A0H= owever, I >> don't think the speculative read would be preserved in that case. =C2=A0= The CPU >> has to return to a specific PC when it returns from the interrupt and it= has >> no way of storing the state for what speculative reordering it might be >> doing, so presumably it is thrown away? =C2=A0I suppose it is possible t= hat it >> actually retires both instructions (but reordered) and then returns to t= he PC >> value after the read of listlocks after the interrupt. =C2=A0However, in= that case >> the scheduler would not migrate as it would see td_pinned !=3D 0. =C2=A0= To get the >> race you have to have the interrupt take effect prior to modifying td_pi= nned, >> so I think the processor would have to discard the reordered read of >> listlocks so it could safely resume execution at the 'incl' instruction. >> >> The other nit there on x86 at least is that the incl instruction is doin= g >> both a read and a write and another rule in the section 8.2.2 is this: >> >> =C2=A0=E2=80=A2 Reads are not reordered with other reads. >> >> That would seem to prevent the read of listlocks from passing the read o= f >> td_pinned in the incl instruction on x86. > > I wonder how that's interpreted in the microcode, though? =C2=A0I.e. if t= he > incr instruction decodes to load, add, store, does the h/w allow the > later reads to pass the final store? > > I added the following: > > =C2=A0 =C2=A0 =C2=A0 =C2=A0sched_pin(); > =C2=A0 =C2=A0 =C2=A0 =C2=A0lock_list =3D PCPU_GET(spinlocks); > =C2=A0 =C2=A0 =C2=A0 =C2=A0if (lock_list !=3D NULL && lock_list->ll_count= !=3D 0) { > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /* XXX debug for bug 6= 7957 */ > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mfence(); > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 lle =3D PCPU_GET(spinl= ocks); > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (lle !=3D lock_list= ) { > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 panic("Bug 67957: had lock list %p, now %p\n", > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 lock_list, lle); > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 } > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /* XXX end debug */ > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sched_unpin(); > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/* > > ... and the panic triggered. =C2=A0I think it's more likely that some > barrier is needed in sched_pin() than that %gs is getting corrupted > but can always be dereferenced. Are the 2 values just different or one of the 2 is NULL? Thanks, Attilio --=20 Peace can only be achieved by understanding - A. Einstein From owner-freebsd-hackers@FreeBSD.ORG Sun Aug 8 15:24:39 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3A6B81065673; Sun, 8 Aug 2010 15:24:39 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id E2D778FC13; Sun, 8 Aug 2010 15:24:38 +0000 (UTC) Received: by iwn10 with SMTP id 10so3791883iwn.13 for ; Sun, 08 Aug 2010 08:24:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=k1e/gT/VQjzHm52ozxtyP0vSLLrACCcOZfwuaBr7SC4=; b=m+8RwkMsAm6DozluQe3Opks6glAdEF64TiZOTizq5YA6G4wYP2fBDr7RKshQNUYrCo J3C+V0XOM3Tdzq8o8iOzPsl0ffAuCDra0qc4gRZZul8yGhzlWDIQxTWiGbC+YiL8oqj1 IaYvQ3OjGd9TDpX3Euuz7Urvv3/J6QF4RURbE= 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=YOuUs6IYI5STliEhAt/Bh67mPNzl4BgABMva1X6As2AcBxBL6yp1sX67nCezGkuFpk Erfgnb0O+2BceoI0Un22vBLIL6YV/Nt5eWAmplsDlnI3oRgWFcWpmmV/tGFn3w6Khpln WA5d+vjA1fNsUP/dTW2ztolonGRp16myxiyj4= MIME-Version: 1.0 Received: by 10.42.0.195 with SMTP id 3mr4672738icd.83.1281281078073; Sun, 08 Aug 2010 08:24:38 -0700 (PDT) Sender: mdf356@gmail.com Received: by 10.42.3.140 with HTTP; Sun, 8 Aug 2010 08:24:38 -0700 (PDT) In-Reply-To: References: <201007301008.22501.jhb@freebsd.org> <201007301031.34266.jhb@freebsd.org> Date: Sun, 8 Aug 2010 15:24:38 +0000 X-Google-Sender-Auth: 0oIbECYfW3kN6qjoZfH2W54G1n4 Message-ID: From: mdf@FreeBSD.org To: Attilio Rao Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: sched_pin() versus PCPU_GET X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Aug 2010 15:24:39 -0000 On Sun, Aug 8, 2010 at 2:43 PM, Attilio Rao wrote: > 2010/8/4 =A0: >> On Fri, Jul 30, 2010 at 2:31 PM, John Baldwin wrote: >>> On Friday, July 30, 2010 10:08:22 am John Baldwin wrote: >>>> On Thursday, July 29, 2010 7:39:02 pm mdf@freebsd.org wrote: >>>> > We've seen a few instances at work where witness_warn() in ast() >>>> > indicates the sched lock is still held, but the place it claims it w= as >>>> > held by is in fact sometimes not possible to keep the lock, like: >>>> > >>>> > =A0 =A0 thread_lock(td); >>>> > =A0 =A0 td->td_flags &=3D ~TDF_SELECT; >>>> > =A0 =A0 thread_unlock(td); >>>> > >>>> > What I was wondering is, even though the assembly I see in objdump -= S >>>> > for witness_warn has the increment of td_pinned before the PCPU_GET: >>>> > >>>> > ffffffff802db210: =A0 65 48 8b 1c 25 00 00 =A0 =A0mov =A0 =A0%gs:0x0= ,%rbx >>>> > ffffffff802db217: =A0 00 00 >>>> > ffffffff802db219: =A0 ff 83 04 01 00 00 =A0 =A0 =A0 incl =A0 0x104(%= rbx) >>>> > =A0 =A0 =A0* Pin the thread in order to avoid problems with thread m= igration. >>>> > =A0 =A0 =A0* Once that all verifies are passed about spinlocks owner= ship, >>>> > =A0 =A0 =A0* the thread is in a safe path and it can be unpinned. >>>> > =A0 =A0 =A0*/ >>>> > =A0 =A0 sched_pin(); >>>> > =A0 =A0 lock_list =3D PCPU_GET(spinlocks); >>>> > ffffffff802db21f: =A0 65 48 8b 04 25 48 00 =A0 =A0mov =A0 =A0%gs:0x4= 8,%rax >>>> > ffffffff802db226: =A0 00 00 >>>> > =A0 =A0 if (lock_list !=3D NULL && lock_list->ll_count !=3D 0) { >>>> > ffffffff802db228: =A0 48 85 c0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0test = =A0 %rax,%rax >>>> > =A0 =A0 =A0* Pin the thread in order to avoid problems with thread m= igration. >>>> > =A0 =A0 =A0* Once that all verifies are passed about spinlocks owner= ship, >>>> > =A0 =A0 =A0* the thread is in a safe path and it can be unpinned. >>>> > =A0 =A0 =A0*/ >>>> > =A0 =A0 sched_pin(); >>>> > =A0 =A0 lock_list =3D PCPU_GET(spinlocks); >>>> > ffffffff802db22b: =A0 48 89 85 f0 fe ff ff =A0 =A0mov =A0 =A0%rax,-0= x110(%rbp) >>>> > ffffffff802db232: =A0 48 89 85 f8 fe ff ff =A0 =A0mov =A0 =A0%rax,-0= x108(%rbp) >>>> > =A0 =A0 if (lock_list !=3D NULL && lock_list->ll_count !=3D 0) { >>>> > ffffffff802db239: =A0 0f 84 ff 00 00 00 =A0 =A0 =A0 je =A0 =A0 fffff= fff802db33e >>>> > >>>> > ffffffff802db23f: =A0 44 8b 60 50 =A0 =A0 =A0 =A0 =A0 =A0 mov =A0 = =A00x50(%rax),%r12d >>>> > >>>> > is it possible for the hardware to do any re-ordering here? >>>> > >>>> > The reason I'm suspicious is not just that the code doesn't have a >>>> > lock leak at the indicated point, but in one instance I can see in t= he >>>> > dump that the lock_list local from witness_warn is from the pcpu >>>> > structure for CPU 0 (and I was warned about sched lock 0), but the >>>> > thread id in panic_cpu is 2. =A0So clearly the thread was being migr= ated >>>> > right around panic time. >>>> > >>>> > This is the amd64 kernel on stable/7. =A0I'm not sure exactly what k= ind >>>> > of hardware; it's a 4-way Intel chip from about 3 or 4 years ago IIR= C. >>>> > >>>> > So... do we need some kind of barrier in the code for sched_pin() fo= r >>>> > it to really do what it claims? =A0Could the hardware have re-ordere= d >>>> > the "mov =A0 =A0%gs:0x48,%rax" PCPU_GET to before the sched_pin() >>>> > increment? >>>> >>>> Hmmm, I think it might be able to because they refer to different loca= tions. >>>> >>>> Note this rule in section 8.2.2 of Volume 3A: >>>> >>>> =A0 =95 Reads may be reordered with older writes to different location= s but not >>>> =A0 =A0 with older writes to the same location. >>>> >>>> It is certainly true that sparc64 could reorder with RMO. =A0I believe= ia64 >>>> could reorder as well. =A0Since sched_pin/unpin are frequently used to= provide >>>> this sort of synchronization, we could use memory barriers in pin/unpi= n >>>> like so: >>>> >>>> sched_pin() >>>> { >>>> =A0 =A0 =A0 td->td_pinned =3D atomic_load_acq_int(&td->td_pinned) + 1; >>>> } >>>> >>>> sched_unpin() >>>> { >>>> =A0 =A0 =A0 atomic_store_rel_int(&td->td_pinned, td->td_pinned - 1); >>>> } >>>> >>>> We could also just use atomic_add_acq_int() and atomic_sub_rel_int(), = but they >>>> are slightly more heavyweight, though it would be more clear what is h= appening >>>> I think. >>> >>> However, to actually get a race you'd have to have an interrupt fire an= d >>> migrate you so that the speculative read was from the other CPU. =A0How= ever, I >>> don't think the speculative read would be preserved in that case. =A0Th= e CPU >>> has to return to a specific PC when it returns from the interrupt and i= t has >>> no way of storing the state for what speculative reordering it might be >>> doing, so presumably it is thrown away? =A0I suppose it is possible tha= t it >>> actually retires both instructions (but reordered) and then returns to = the PC >>> value after the read of listlocks after the interrupt. =A0However, in t= hat case >>> the scheduler would not migrate as it would see td_pinned !=3D 0. =A0To= get the >>> race you have to have the interrupt take effect prior to modifying td_p= inned, >>> so I think the processor would have to discard the reordered read of >>> listlocks so it could safely resume execution at the 'incl' instruction= . >>> >>> The other nit there on x86 at least is that the incl instruction is doi= ng >>> both a read and a write and another rule in the section 8.2.2 is this: >>> >>> =A0=95 Reads are not reordered with other reads. >>> >>> That would seem to prevent the read of listlocks from passing the read = of >>> td_pinned in the incl instruction on x86. >> >> I wonder how that's interpreted in the microcode, though? =A0I.e. if the >> incr instruction decodes to load, add, store, does the h/w allow the >> later reads to pass the final store? >> >> I added the following: >> >> =A0 =A0 =A0 =A0sched_pin(); >> =A0 =A0 =A0 =A0lock_list =3D PCPU_GET(spinlocks); >> =A0 =A0 =A0 =A0if (lock_list !=3D NULL && lock_list->ll_count !=3D 0) { >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* XXX debug for bug 67957 */ >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 mfence(); >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 lle =3D PCPU_GET(spinlocks); >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (lle !=3D lock_list) { >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 panic("Bug 67957: had lock= list %p, now %p\n", >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 lock_list, lle); >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 } >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* XXX end debug */ >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0sched_unpin(); >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* >> >> ... and the panic triggered. =A0I think it's more likely that some >> barrier is needed in sched_pin() than that %gs is getting corrupted >> but can always be dereferenced. > > Are the 2 values just different or one of the 2 is NULL? They are just different. I don't have a valid dump for this panic, but the earlier one before I added this check showed that the two are likely to be from different PCPU structs. Thanks, matthew From owner-freebsd-hackers@FreeBSD.ORG Sun Aug 8 18:17:09 2010 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 81B09106564A; Sun, 8 Aug 2010 18:17:09 +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 242A78FC0A; Sun, 8 Aug 2010 18:17:09 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o78IEHi4044758; Sun, 8 Aug 2010 12:14:17 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sun, 08 Aug 2010 12:14:50 -0600 (MDT) Message-Id: <20100808.121450.752311254854610266.imp@bsdimp.com> To: emaste@FreeBSD.org From: "M. Warner Losh" In-Reply-To: <20100808130624.GB40928@sandvine.com> References: <864of680wv.fsf@ds4.des.no> <20100808130624.GB40928@sandvine.com> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: des@des.no, freebsd-hackers@FreeBSD.org, gcooper@FreeBSD.org, ivoras@FreeBSD.org, Garrett@FreeBSD.org Subject: Re: Why is TUNABLE_INT discouraged? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Aug 2010 18:17:09 -0000 In message: <20100808130624.GB40928@sandvine.com> Ed Maste writes: : On Sun, Aug 08, 2010 at 01:30:19AM +0200, Ivan Voras wrote: : : > 2010/8/8 Dag-Erling Sm??rgrav : : > > Garrett Cooper writes: : > >> Dag-Erling Sm??rgrav writes: : > >> > Perhaps. ??I don't remember all the details; I can't find a discussion in : > >> > the list archives (other than me announcing the change in response to a : > >> > bug report), but there must have been one, either on IRC or in Karlsruhe. : > >> > In any case, I never removed TUNABLE_INT(), so... : > >> It does matter for integers on 64-bit vs 32-bit architectures though, : > >> right : > > : > > Not sure what you mean. ??The original issue was that someone had used : > > TUNABLE_INT() for something that was actually a memory address. ??I : > > changed it to TUNABLE_ULONG(). ??Of course, if your tunable is a boolean : > > value or something like maxprocs, an int is fine - but so is a long. : > : > Semantically valid but using TUNABLE_INT to hold pointers is a : > developer bug, not the fault of the API, and there's nothing wrong : > with "int" as a data type in this context. : : I agree with Ivan here. If we can't find an actual reason to : universally prefer long I'd like to remove this comment. : : As a counterpoint to the preference for long I can offer a reason to : prefer int: the same variable is often exposed by both a tunable and a : sysctls, and a sysctl using long can have 32-bit compat issues. (That : is, a 32-bit app using sysctlbyname will try to use 4 bytes for a long.) There's absolutely no reason to not use TUNABLE_INT for simple integers. Back in the deep, dark, dim past, there was no TUNABLE_*LONG. TUNABLE_INT was introduce in r77900 by peter. DES added TUNABLE_LONG in r137099, as well as adding the comment. The comment is bogus, or at least not quite specific enough. It has been routinely ignored since it was added. There's absolutely nothing wrong with TUNABLE_INT. We really should have a TUNABLE_ADDRESS for this case, although there's at least three types of address that we need to worry about: Physical Addresses, Virtual Addresses and Bus Addresses. You don't know if ULONG or LONG is the right type for an address, or if you need a quad (for example, 32-bit MIPS can address, through PTE entries, addresses beyond the 32-bit barrier, so you'd need a QUAD). I'm in favor of changing the comment to: /* * Please do not use for addresses or pointers */ Warner From owner-freebsd-hackers@FreeBSD.ORG Sun Aug 8 20:08:20 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D393E106564A; Sun, 8 Aug 2010 20:08:20 +0000 (UTC) (envelope-from marius@nuenneri.ch) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 479B68FC1F; Sun, 8 Aug 2010 20:08:19 +0000 (UTC) Received: by qwg5 with SMTP id 5so5535847qwg.13 for ; Sun, 08 Aug 2010 13:08:19 -0700 (PDT) Received: by 10.229.214.13 with SMTP id gy13mr6441640qcb.155.1281298099105; Sun, 08 Aug 2010 13:08:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.219.17 with HTTP; Sun, 8 Aug 2010 13:07:59 -0700 (PDT) In-Reply-To: References: <20100808103055.GA2037@garage.freebsd.pl> From: =?UTF-8?Q?Marius_N=C3=BCnnerich?= Date: Sun, 8 Aug 2010 22:07:59 +0200 Message-ID: To: Ivan Voras Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, freebsd-geom@freebsd.org Subject: Re: glabel "force sectorsize" patch X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Aug 2010 20:08:20 -0000 On Sun, Aug 8, 2010 at 21:08, Ivan Voras wrote: > On 8.8.2010 14:57, Marius N=C3=BCnnerich wrote: >> On Sun, Aug 8, 2010 at 14:02, Ivan Voras wrote: > >>>>> This mechanism is a band-aid until there's a better way of dealing >>>>> with 4k drives. > >> I do not like this at all. Even if it's just for the KISS and POLA >> principles. A geom should do one thing and do it right imo. > > As the addition will not modify general behaviour of glabel but add a > new feature (which is actually clean and trivial to implement) invisible > to most of the users, I don't think either KISS nor POLA are in any > danger here. "Adding a new feature" maps directly to KISS, especially if the feature is in the wrong module. POLA: I wouldn't guess that a blocksize resizing is hidden in a _part_ of glabel. I am not using the native glabel part at all, just the named GPT partitions as most of the users seem to prefer nower days (and I guess will get even more traction after Dan's blog post). > I do agree that it shouldn't be glabel's job to do this but also am > *very* strongly against shipping 9.0 without any support for 4k drives, > and the way I've chosen is the lesser of two evils. I am against workarounds for stupid hardware vendors most of the time. Especially if it's just a minority, they break pola intentionally and is fixed easily without this kludge. Afaik if you align your Partitions to higher values (I use 1MB for example) ufs is not having any performance issues (I have not benchmarked this myself). > Code and patches by others are of course welcome. I'm hoping this > discussion will trigger someone with experience in the lower levels of > kernel to go and finally add the drive info parsing so it gets solved > the right way :) > >> Why not write a new geom class that does what you want? > > I'm not against this approach also. Technically, if we go this way, the > new GEOM class will be almost a line-for-line copy-paste of glabel with > this single metadata field added, so I'd rather fold it into glabel. I did not think of a new GEOM class that looks like glabel but one that has no metadata stored on disk . It is then activated and controlled by loader.conf variables. (Maybe like gnop? If I remember correctly, I did not take a look at that class for ages). This way you would get: - Your feature - no KISS violation, that class should be really simple - no POLA violation, feature is in a class with a discriptive name, glabel is left alone - no metadata store problem (is it in the last 512 or 4K bytes?) - No problem with future compatibilty, a user would have to active the class and it's configuration by hand, no magic here Marius From owner-freebsd-hackers@FreeBSD.ORG Sun Aug 8 23:15:05 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BC1E91065673; Sun, 8 Aug 2010 23:15:05 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id D925D8FC13; Sun, 8 Aug 2010 23:15:04 +0000 (UTC) Received: by bwz9 with SMTP id 9so1127247bwz.13 for ; Sun, 08 Aug 2010 16:15:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=6TeM0kBMemCq3+S0f0w2pUUxL/jL8NrAVbawFx/4MAw=; b=GoryctNbwtEhUwKgIGYbZNbC3Puss8ElsqXk3HnVXFReW+F4EqecFq1KIs3dlEGrEV kKEL35fjiyrEfqklGeFM+l9EvcS/a8lvOUdue9E8mbOKSC4mfgZ/hiz2k9U6ANoti0se oPBlBxnkuLbV+R5VJRDN+HQYzV8XNA/YrnW/U= 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; b=iTBkRyAtw79WWpRhIpCebIrvQd44Dd84icFTEs26/i35VpODFpzYfC/RnO003DRNrD Pzle4nv4rZE6yA+LMmh7InLAguvJAttS5E4fZSXS7Hf3WntuMxv6uuh0GcUgsybBFyoE TgZ03BoumtwFO3Ff7lLsZJ8iXFiW95w01LC18= MIME-Version: 1.0 Received: by 10.204.112.146 with SMTP id w18mr10080756bkp.16.1281309303703; Sun, 08 Aug 2010 16:15:03 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.204.21.204 with HTTP; Sun, 8 Aug 2010 16:15:03 -0700 (PDT) In-Reply-To: <20100808.121450.752311254854610266.imp@bsdimp.com> References: <864of680wv.fsf@ds4.des.no> <20100808130624.GB40928@sandvine.com> <20100808.121450.752311254854610266.imp@bsdimp.com> Date: Sun, 8 Aug 2010 16:15:03 -0700 X-Google-Sender-Auth: itz4mvf1w8Q9_MYENM9SLXpRU24 Message-ID: From: Garrett Cooper To: "M. Warner Losh" Content-Type: multipart/mixed; boundary=0016e6deddeae50ad7048d5811f8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: des@des.no, emaste@freebsd.org, ivoras@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: Why is TUNABLE_INT discouraged? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Aug 2010 23:15:05 -0000 --0016e6deddeae50ad7048d5811f8 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sun, Aug 8, 2010 at 11:14 AM, M. Warner Losh wrote: > In message: <20100808130624.GB40928@sandvine.com> > =A0 =A0 =A0 =A0 =A0 =A0Ed Maste writes: > : On Sun, Aug 08, 2010 at 01:30:19AM +0200, Ivan Voras wrote: > : > : > 2010/8/8 Dag-Erling Sm??rgrav : > : > > Garrett Cooper writes: > : > >> Dag-Erling Sm??rgrav writes: > : > >> > Perhaps. ??I don't remember all the details; I can't find a disc= ussion in > : > >> > the list archives (other than me announcing the change in respon= se to a > : > >> > bug report), but there must have been one, either on IRC or in K= arlsruhe. > : > >> > In any case, I never removed TUNABLE_INT(), so... > : > >> It does matter for integers on 64-bit vs 32-bit architectures thou= gh, > : > >> right > : > > > : > > Not sure what you mean. ??The original issue was that someone had u= sed > : > > TUNABLE_INT() for something that was actually a memory address. ??I > : > > changed it to TUNABLE_ULONG(). ??Of course, if your tunable is a bo= olean > : > > value or something like maxprocs, an int is fine - but so is a long= . > : > > : > Semantically valid but using TUNABLE_INT to hold pointers is a > : > developer bug, not the fault of the API, and there's nothing wrong > : > with "int" as a data type in this context. > : > : I agree with Ivan here. =A0If we can't find an actual reason to > : universally prefer long I'd like to remove this comment. > : > : As a counterpoint to the preference for long I can offer a reason to > : prefer int: the same variable is often exposed by both a tunable and a > : sysctls, and a sysctl using long can have 32-bit compat issues. =A0(Tha= t > : is, a 32-bit app using sysctlbyname will try to use 4 bytes for a long.= ) > > There's absolutely no reason to not use TUNABLE_INT for simple > integers. =A0Back in the deep, dark, dim past, there was no > TUNABLE_*LONG. =A0TUNABLE_INT was introduce in r77900 by peter. =A0DES > added TUNABLE_LONG in r137099, as well as adding the comment. > > The comment is bogus, or at least not quite specific enough. =A0It has > been routinely ignored since it was added. > > There's absolutely nothing wrong with TUNABLE_INT. > > We really should have a TUNABLE_ADDRESS for this case, although > there's at least three types of address that we need to worry about: > Physical Addresses, Virtual Addresses and Bus Addresses. =A0You don't > know if ULONG or LONG is the right type for an address, or if you need > a quad (for example, 32-bit MIPS can address, through PTE entries, > addresses beyond the 32-bit barrier, so you'd need a QUAD). > > I'm in favor of changing the comment to: > > /* > =A0* Please do not use for addresses or pointers > =A0*/ Then comes my next request: could someone please review this patch and commit it if it's ok? This adds comments to TUNABLE_INT (recommended by Warner) and also adds functionality for TUNABLE_UINT as well. I have a simple module and test script attached for it. Adding this functionality would make things more consistent with the TUNABLE KPIs, make my experimenting with sound(4) easier, and could help improve the sound(4) subsystem's code (I'll have to discuss some things with ariff@, because I'm not sure whether or not some quantities need to be signed or not). Thanks! -Garrett --0016e6deddeae50ad7048d5811f8 Content-Type: application/octet-stream; name="uint_tunable.diff" Content-Disposition: attachment; filename="uint_tunable.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gcmibyy41 SW5kZXg6IGtlcm4va2Vybl9lbnZpcm9ubWVudC5jCj09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIGtlcm4va2Vybl9l bnZpcm9ubWVudC5jCShyZXZpc2lvbiAyMTA4MjQpCisrKyBrZXJuL2tlcm5fZW52aXJvbm1lbnQu Ywkod29ya2luZyBjb3B5KQpAQCAtNTgzLDYgKzU4MywxNCBAQAogfQogCiB2b2lkCit0dW5hYmxl X3VpbnRfaW5pdCh2b2lkICpkYXRhKQoreworCXN0cnVjdCB0dW5hYmxlX3VpbnQgKmQgPSAoc3Ry dWN0IHR1bmFibGVfdWludCAqKWRhdGE7CisKKwlUVU5BQkxFX1VJTlRfRkVUQ0goZC0+cGF0aCwg ZC0+dmFyKTsKK30KKwordm9pZAogdHVuYWJsZV9sb25nX2luaXQodm9pZCAqZGF0YSkKIHsKIAlz dHJ1Y3QgdHVuYWJsZV9sb25nICpkID0gKHN0cnVjdCB0dW5hYmxlX2xvbmcgKilkYXRhOwpJbmRl eDogc3lzL2tlcm5lbC5oCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9rZXJuZWwuaAkocmV2aXNpb24gMjEw ODI0KQorKysgc3lzL2tlcm5lbC5oCSh3b3JraW5nIGNvcHkpCkBAIC0yNzUsNyArMjc1LDcgQEAK IAogLyoKICAqIGludAotICogcGxlYXNlIGF2b2lkIHVzaW5nIGZvciBuZXcgdHVuYWJsZXMhCisg KiBQbGVhc2UgZG8gbm90IHVzZSBmb3IgYWRkcmVzc2VzIG9yIHBvaW50ZXJzLgogICovCiBleHRl cm4gdm9pZCB0dW5hYmxlX2ludF9pbml0KHZvaWQgKik7CiBzdHJ1Y3QgdHVuYWJsZV9pbnQgewpA QCAtMjk0LDYgKzI5NCwyNiBAQAogI2RlZmluZQlUVU5BQkxFX0lOVF9GRVRDSChwYXRoLCB2YXIp CWdldGVudl9pbnQoKHBhdGgpLCAodmFyKSkKIAogLyoKKyAqIHVuc2lnbmVkIGludAorICogUGxl YXNlIGRvIG5vdCB1c2UgZm9yIGFkZHJlc3NlcyBvciBwb2ludGVycy4KKyAqLworZXh0ZXJuIHZv aWQgdHVuYWJsZV91aW50X2luaXQodm9pZCAqKTsKK3N0cnVjdCB0dW5hYmxlX3VpbnQgeworCWNv bnN0IGNoYXIgKnBhdGg7CisJdW5zaWduZWQgaW50ICp2YXI7Cit9OworI2RlZmluZQlUVU5BQkxF X1VJTlQocGF0aCwgdmFyKQkJCQkJXAorCXN0YXRpYyBzdHJ1Y3QgdHVuYWJsZV91aW50IF9fQ09O Q0FUKF9fdHVuYWJsZV91aW50XywgX19MSU5FX18pID0geyBcCisJCShwYXRoKSwJCQkJCQlcCisJ CSh2YXIpLAkJCQkJCVwKKwl9OwkJCQkJCQlcCisJU1lTSU5JVChfX0NPTkNBVChfX1R1bmFibGVf aW5pdF8sIF9fTElORV9fKSwJCVwKKwkgICAgU0lfU1VCX1RVTkFCTEVTLCBTSV9PUkRFUl9NSURE TEUsIHR1bmFibGVfdWludF9pbml0LCBcCisJICAgICZfX0NPTkNBVChfX3R1bmFibGVfdWludF8s IF9fTElORV9fKSkKKworI2RlZmluZQlUVU5BQkxFX1VJTlRfRkVUQ0gocGF0aCwgdmFyKQlnZXRl bnZfdWludCgocGF0aCksICh2YXIpKQorCisvKgogICogbG9uZwogICovCiBleHRlcm4gdm9pZCB0 dW5hYmxlX2xvbmdfaW5pdCh2b2lkICopOwo= --0016e6deddeae50ad7048d5811f8-- From owner-freebsd-hackers@FreeBSD.ORG Sun Aug 8 23:58:11 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 04DF21065672 for ; Sun, 8 Aug 2010 23:58:11 +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 B70168FC15 for ; Sun, 8 Aug 2010 23:58:10 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar8FADXhXkyDaFvO/2dsb2JhbACDFZA9jWOwe5BShEdzBIk7 X-IronPort-AV: E=Sophos;i="4.55,339,1278302400"; d="scan'208";a="89847814" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 08 Aug 2010 19:58:09 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id B03CAB3E96; Sun, 8 Aug 2010 19:58:09 -0400 (EDT) Date: Sun, 8 Aug 2010 19:58:09 -0400 (EDT) From: Rick Macklem To: rhfb@akira.stdio.com Message-ID: <282423324.419135.1281311889612.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20100729094046.AD3F3C2@akira.stdio.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_419134_272684746.1281311889610" X-Originating-IP: [24.65.230.102] X-Mailer: Zimbra 6.0.7_GA_2476.RHEL4 (ZimbraWebClient - SAF3 (Mac)/6.0.7_GA_2473.RHEL4_64) Cc: freebsd-hackers@freebsd.org, dfr@freebsd.org Subject: Re: NFS server hangs (was no subject) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Aug 2010 23:58:11 -0000 ------=_Part_419134_272684746.1281311889610 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit > I have a similar problem. > > I have a NFS server (8.0 upgraded a couple times since Feb 2010) that > locks up > and requires a reboot. > > The clients are busy vm's from VMWare ESXi using the NFS server for > vmdk virtual > disk storage. > > The ESXi reports nfs server inactive and all the vm's post disk write > errors when > trying to write to their disk. > > /etc/rc.d/nfsd restart fails to work (it can not kill the nfsd > process) > > The nfsd process runs at 100% cpu at rc_lo state in top. > > reboot is the only fix. > > It has only happened under two circumstances. > 1) Installation of a VM using Windows 2008. > 2) Migrating 16 million mail messages from a physical server to a VM > running FreeBSD with ZFS file system as a VM on the ESXi box that uses > NFS to store the VM's ZFS disk. > > The NFS server uses ZFS also. I don't think what you are seeing is the same as what others have reported. (I have a hunch that your problem might be a replay cache problem.) Please try the attached patch and make sure that your sys/rpc/svc.c is at r205562 (upgrade if it isn't). If this patch doesn't help, you could try using the experimental nfs server (which doesn't use the generic replay cache), by adding "-e" to mountd and nfsd. Please let me know if the patch or switching to the experimental nfs server helps, rick ------=_Part_419134_272684746.1281311889610 Content-Type: text/x-patch; name=replay.patch Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=replay.patch LS0tIHJwYy9yZXBsYXkuYy5zYXYJMjAxMC0wOC0wOCAxODowNTo1MC4wMDAwMDAwMDAgLTA0MDAK KysrIHJwYy9yZXBsYXkuYwkyMDEwLTA4LTA4IDE4OjE2OjQzLjAwMDAwMDAwMCAtMDQwMApAQCAt OTAsOCArOTAsMTAgQEAKIHJlcGxheV9zZXRzaXplKHN0cnVjdCByZXBsYXlfY2FjaGUgKnJjLCBz aXplX3QgbmV3bWF4c2l6ZSkKIHsKIAorCW10eF9sb2NrKCZyYy0+cmNfbG9jayk7CiAJcmMtPnJj X21heHNpemUgPSBuZXdtYXhzaXplOwogCXJlcGxheV9wcnVuZShyYyk7CisJbXR4X3VubG9jaygm cmMtPnJjX2xvY2spOwogfQogCiB2b2lkCkBAIC0xNDQsOCArMTQ2LDggQEAKIAlib29sX3QgZnJl ZWRfb25lOwogCiAJaWYgKHJjLT5yY19jb3VudCA+PSBSRVBMQVlfTUFYIHx8IHJjLT5yY19zaXpl ID4gcmMtPnJjX21heHNpemUpIHsKLQkJZnJlZWRfb25lID0gRkFMU0U7CiAJCWRvIHsKKwkJCWZy ZWVkX29uZSA9IEZBTFNFOwogCQkJLyoKIAkJCSAqIFRyeSB0byBmcmVlIGFuIGVudHJ5LiBEb24n dCBmcmVlIGluLXByb2dyZXNzIGVudHJpZXMKIAkJCSAqLwo= ------=_Part_419134_272684746.1281311889610-- From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 9 08:02:14 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2DC1D106566B; Mon, 9 Aug 2010 08:02:14 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id DF6E18FC17; Mon, 9 Aug 2010 08:02:13 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id DE1061FFC33; Mon, 9 Aug 2010 08:02:12 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id B68BE84528; Mon, 9 Aug 2010 10:02:12 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Ivan Voras References: <86fwyq8rsc.fsf@ds4.des.no> <86d3tujh72.fsf@ds4.des.no> <864of680wv.fsf@ds4.des.no> Date: Mon, 09 Aug 2010 10:02:12 +0200 In-Reply-To: (Ivan Voras's message of "Sun, 8 Aug 2010 01:30:19 +0200") Message-ID: <86aaowuscb.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, Garrett Cooper Subject: Re: Why is TUNABLE_INT discouraged? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2010 08:02:14 -0000 Ivan Voras writes: > Dag-Erling Sm=C3=B8rgrav writes: > > Not sure what you mean. The original issue was that someone had used > > TUNABLE_INT() for something that was actually a memory address. I > > changed it to TUNABLE_ULONG(). Of course, if your tunable is a boolean > > value or something like maxprocs, an int is fine - but so is a long. > Semantically valid but using TUNABLE_INT to hold pointers is a > developer bug, not the fault of the API, and there's nothing wrong > with "int" as a data type in this context. That's the point. There was no TUNABLE_ULONG() at the time. I added it to fix the bug. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 9 08:11:16 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F3655106566C; Mon, 9 Aug 2010 08:11:15 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id AFD348FC14; Mon, 9 Aug 2010 08:11:15 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id DF91F1FFC33; Mon, 9 Aug 2010 08:11:14 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id BD05B8452E; Mon, 9 Aug 2010 10:11:14 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Garrett Cooper References: <86fwyq8rsc.fsf@ds4.des.no> <86d3tujh72.fsf@ds4.des.no> <864of680wv.fsf@ds4.des.no> Date: Mon, 09 Aug 2010 10:11:14 +0200 In-Reply-To: (Garrett Cooper's message of "Sun, 8 Aug 2010 02:31:44 -0700") Message-ID: <8662zkurx9.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, Ivan Voras Subject: Re: Why is TUNABLE_INT discouraged? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2010 08:11:16 -0000 Garrett Cooper writes: > Why would someone express a tunable in a memory address (not being > sarcastic... I just don't see why it makes sense right now, but if > there's a valid reason I'm more than happy to be educated :)..)? A few examples: hw.acpi.host_mem_start hw.pci.host_mem_start hw.physmemstart The following are not addresses, but can be > 32 bits on 64-bit machines and even on some 32-bit machines using PAE / PTE: hw.physmem vm.kmem_size vm.kmem_size_max vm.kmem_size_min It might be a good idea to introduce TUNABLE_POINTER and TUNABLE_SIZE. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 9 08:51:46 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 086951065670; Mon, 9 Aug 2010 08:51:46 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id B51A58FC18; Mon, 9 Aug 2010 08:51:45 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id C4B9E1FFC36; Mon, 9 Aug 2010 08:51:44 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id A04F184428; Mon, 9 Aug 2010 10:51:44 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Marius =?utf-8?Q?N=C3=BCnnerich?= References: <20100808103055.GA2037@garage.freebsd.pl> Date: Mon, 09 Aug 2010 10:51:44 +0200 In-Reply-To: ("Marius =?utf-8?Q?N=C3=BCnnerich=22's?= message of "Sun, 8 Aug 2010 22:07:59 +0200") Message-ID: <86pqxstbhb.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, Ivan Voras , freebsd-geom@freebsd.org Subject: Re: glabel "force sectorsize" patch X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2010 08:51:46 -0000 Marius N=C3=BCnnerich writes: > I did not think of a new GEOM class that looks like glabel but one > that has no metadata stored on disk . It is then activated and > controlled by loader.conf variables. (Maybe like gnop? If I remember > correctly, I did not take a look at that class for ages). As you would know if you had followed the discussion about WD EARS disks, gnop does what you want and is currently the recommended solution. I am looking into a permanent solution and would appreciate if people held off on this for a couple of weeks. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 9 10:21:01 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B38611065675; Mon, 9 Aug 2010 10:21:01 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 467E98FC08; Mon, 9 Aug 2010 10:21:00 +0000 (UTC) Received: by qwg5 with SMTP id 5so6074865qwg.13 for ; Mon, 09 Aug 2010 03:21:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=Vs6qmxQl8+99VN8PPdD4WaLFKxnOCFrNxio7sYJEayI=; b=venrhW8Du410HFL2RwcP7dPbydaPenqaUqD/Eeooq8RgrmlpZjiuIGQxYS9g4pjwq9 4alrzNRVPd3x6Y0kVqfBhsca13xG60X4Vn8hgFiQzm4u1WEpZpGFgs4l34ynZvHE1wCl vfPs1PwBkPwhuFVBtZkLUg6P03inU7Vl/Qik8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=YS7GCQB5w+i7vmfvNVjojhFJwwE7jzHDZCGYfbZ5NIXO536XpBpL42vv6f4O41dZSR loKJDfc4LYSFoc3GFr+KVMIpsDpPYmpqUS11T3Gn/DkwLIKYoTcoSxBewa8ge9KdYjZW shhLuA1GAFoH9AB1Vco3z5GToxVp2QqdSrf18= Received: by 10.224.119.18 with SMTP id x18mr8258921qaq.302.1281349260158; Mon, 09 Aug 2010 03:21:00 -0700 (PDT) MIME-Version: 1.0 Sender: ivoras@gmail.com Received: by 10.229.236.132 with HTTP; Mon, 9 Aug 2010 03:20:40 -0700 (PDT) In-Reply-To: <86pqxstbhb.fsf@ds4.des.no> References: <20100808103055.GA2037@garage.freebsd.pl> <86pqxstbhb.fsf@ds4.des.no> From: Ivan Voras Date: Mon, 9 Aug 2010 12:20:40 +0200 X-Google-Sender-Auth: evNYVhj8bVPxozAHk0PL1NQIPB8 Message-ID: To: =?UTF-8?Q?Dag=2DErling_Sm=C3=B8rgrav?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, =?UTF-8?Q?Marius_N=C3=BCnnerich?= , freebsd-current@freebsd.org, freebsd-geom@freebsd.org Subject: Re: glabel "force sectorsize" patch X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2010 10:21:01 -0000 On 9 August 2010 10:51, Dag-Erling Sm=C3=B8rgrav wrote: > Marius N=C3=BCnnerich writes: >> I did not think of a new GEOM class that looks like glabel but one >> that has no metadata stored on disk . It is then activated and >> controlled by loader.conf variables. (Maybe like gnop? If I remember >> correctly, I did not take a look at that class for ages). > > As you would know if you had followed the discussion about WD EARS > disks, gnop does what you want and is currently the recommended > solution. Of course, but gnop as a testing GEOM class, does not save its metadata, meaning it has to be reconfigured after reboot, etc. > I am looking into a permanent solution and would appreciate if people > held off on this for a couple of weeks. Thank you! From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 9 12:13:20 2010 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 17BA31065670 for ; Mon, 9 Aug 2010 12:13:20 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from tower.berklix.org (tower.berklix.org [83.236.223.114]) by mx1.freebsd.org (Postfix) with ESMTP id 989758FC15 for ; Mon, 9 Aug 2010 12:13:19 +0000 (UTC) Received: from park.js.berklix.net (p549A30D4.dip.t-dialin.net [84.154.48.212]) (authenticated bits=0) by tower.berklix.org (8.14.2/8.14.2) with ESMTP id o79CDGRX068059 for ; Mon, 9 Aug 2010 12:13:17 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by park.js.berklix.net (8.13.8/8.13.8) with ESMTP id o79CD9ea038861 for ; Mon, 9 Aug 2010 14:13:09 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.3/8.14.3) with ESMTP id o79CD3I6061232 for ; Mon, 9 Aug 2010 14:13:09 +0200 (CEST) (envelope-from jhs@fire.js.berklix.net) Message-Id: <201008091213.o79CD3I6061232@fire.js.berklix.net> To: hackers@freebsd.org From: "Julian H. Stacey" Organization: http://www.berklix.com BSD Linux Unix Consultancy, Munich Germany User-agent: EXMH on FreeBSD http://www.berklix.com/free/ X-URL: http://www.berklix.com/~jhs/cv/ Date: Mon, 09 Aug 2010 14:13:03 +0200 Sender: jhs@berklix.com Cc: Subject: real memory falsely reports 8G, BIOS & avail memory reports 1G X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2010 12:13:20 -0000 Hi hackers@freebsd.org A laptop here emits a puzzlingly dmesg to both 8.1-RC2 & 8.1-RELEASE: real memory = 8572108800 (8175 MB) avail memory = 1018789888 (971 MB) BIOS reckons it has 1G. No panel to unscrew to inspect memory. I don't beleive 8G. If this is a bug in FreeBSD detect code ? I am ready to run test kernel patches againt 8.1-RELEASE & report back if anyone has code. (I have room to install a current too if necessary) Full dmesg here: http://www.berklix.com/~jhs/hardware/laptops/novatech-8355/dmesg/ Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Mail in plain text. HTML, quoted-printable & base 64 are dumped with spam. Avoid top posting, It cripples itemised cumulative responses. From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 9 12:37:30 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C76C61065677; Mon, 9 Aug 2010 12:37:30 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 8124A8FC1B; Mon, 9 Aug 2010 12:37:30 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 85FF21FFC33; Mon, 9 Aug 2010 12:37:29 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 5C2878452E; Mon, 9 Aug 2010 14:37:29 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Ivan Voras References: <20100808103055.GA2037@garage.freebsd.pl> <86pqxstbhb.fsf@ds4.des.no> Date: Mon, 09 Aug 2010 14:37:28 +0200 In-Reply-To: (Ivan Voras's message of "Mon, 9 Aug 2010 12:20:40 +0200") Message-ID: <86wrs055dj.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, Marius =?utf-8?Q?N=C3=BCnnerich?= , freebsd-current@freebsd.org, freebsd-geom@freebsd.org Subject: Re: glabel "force sectorsize" patch X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2010 12:37:30 -0000 Ivan Voras writes: > Dag-Erling Sm=C3=B8rgrav writes: > > Marius N=C3=BCnnerich writes: > > > I did not think of a new GEOM class that looks like glabel but one > > > that has no metadata stored on disk . It is then activated and > > > controlled by loader.conf variables. (Maybe like gnop? If I > > > remember correctly, I did not take a look at that class for ages). > > As you would know if you had followed the discussion about WD EARS > > disks, gnop does what you want and is currently the recommended > > solution. > Of course, but gnop as a testing GEOM class, does not save its > metadata, meaning it has to be reconfigured after reboot, etc. Please read what Marius wrote, which I quoted above. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 9 12:44:42 2010 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 031071065674 for ; Mon, 9 Aug 2010 12:44:42 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from tower.berklix.org (tower.berklix.org [83.236.223.114]) by mx1.freebsd.org (Postfix) with ESMTP id 858DB8FC1C for ; Mon, 9 Aug 2010 12:44:41 +0000 (UTC) Received: from park.js.berklix.net (p549A30D4.dip.t-dialin.net [84.154.48.212]) (authenticated bits=0) by tower.berklix.org (8.14.2/8.14.2) with ESMTP id o79CidXi068503 for ; Mon, 9 Aug 2010 12:44:40 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by park.js.berklix.net (8.13.8/8.13.8) with ESMTP id o79CiV98039003 for ; Mon, 9 Aug 2010 14:44:32 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.3/8.14.3) with ESMTP id o79CiQNR061713 for ; Mon, 9 Aug 2010 14:44:31 +0200 (CEST) (envelope-from jhs@fire.js.berklix.net) Message-Id: <201008091244.o79CiQNR061713@fire.js.berklix.net> to: hackers@freebsd.org From: "Julian H. Stacey" Organization: http://www.berklix.com BSD Unix Linux Consultancy, Munich Germany User-agent: EXMH on FreeBSD http://www.berklix.com/free/ X-URL: http://www.berklix.com In-reply-to: Your message "Mon, 09 Aug 2010 14:13:03 +0200." <201008091213.o79CD3I6061232@fire.js.berklix.net> Date: Mon, 09 Aug 2010 14:44:26 +0200 Sender: jhs@berklix.com Cc: Subject: Re: real memory falsely reports 8G, BIOS & avail memory reports 1G X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2010 12:44:42 -0000 > A laptop here emits a puzzlingly dmesg to both 8.1-RC2 & 8.1-RELEASE: > real memory = 8572108800 (8175 MB) > avail memory = 1018789888 (971 MB) > BIOS reckons it has 1G. No panel to unscrew to inspect memory. > I don't beleive 8G. PS sysctl -a | grep mem vm.kmem_size_scale: 3 vm.kmem_size_max: 329853485875 vm.kmem_size_min: 0 vm.kmem_size: 342405120 vfs.ufs.dirhash_lowmemcount: 4 vfs.ufs.dirhash_mem: 77734 vfs.ufs.dirhash_maxmem: 2097152 debug.fwmem_debug: 0 hw.physmem: 1059000320 hw.usermem: 812683264 hw.realmem: 1073676288 hw.firewire.fwmem.speed: 2 hw.firewire.fwmem.eui64_lo: 0 hw.firewire.fwmem.eui64_hi: 0 hw.cbb.start_memory: 2281701376 hw.pci.host_mem_start: 2147483648 p1003_1b.memlock: 0 p1003_1b.memlock_range: 0 p1003_1b.memory_protection: 0 p1003_1b.shared_memory_objects: 1 compat.ia32.maxvmem: 0 compat.linux32.maxvmem: 0 top: last pid: 49679; load averages: 1.23, 1.18, 0.90 up 0+03:52:44 14:42:40 91 processes: 2 running, 88 sleeping, 1 stopped CPU: 91.4% user, 0.0% nice, 8.6% system, 0.0% interrupt, 0.0% idle Mem: 186M Active, 444M Inact, 237M Wired, 5564K Cache, 111M Buf, 107M Free Swap: 3072M Total, 3072M Free Cheers, Julian -- Julian Stacey: BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Mail in plain text, Not HTML, quoted-printable & base 64 dumped with spam. Avoid top posting, It cripples itemised cumulative responses. From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 9 14:00:16 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5E6C31065678; Mon, 9 Aug 2010 14:00:16 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 477C38FC12; Mon, 9 Aug 2010 14:00:05 +0000 (UTC) Received: by qwg5 with SMTP id 5so6252962qwg.13 for ; Mon, 09 Aug 2010 07:00:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=9Vj8+jW3Ar/YwrxFCmorvmrQOxeq6HKLyK/z3Jonz14=; b=chC6B0sS00dUap6YyrdLcVJvVp64KFRnWCpqF7slTMDJvc1yW2XuH2kSzjKulMlyU0 qgEvAsCMRd85RvbZ5KoKxN4Ox+X2I8nPDLgBSB9vj7Hp90IX/19IkqYwFCo040WoVhTT 25v1Sj99tSsgCu7HqEp2XDVl85baxV8shLEIU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=eLnv+PW3k8Upu+3Fivyis4J9WN1naISDlGscXSFxWVTZvoBFqyh7oQ2XqljEGZPu/S J/tpizsZ9D/+JWstS6Pas3SMZMkEvAD7jW7hzDWBBXIQky0A0NYjQoR/cMztwox3eIL1 xhDvZ2Oz8J0J4f1raA4PjjbVzaw4FWwMpSdJE= Received: by 10.229.71.71 with SMTP id g7mr7147036qcj.177.1281362405300; Mon, 09 Aug 2010 07:00:05 -0700 (PDT) MIME-Version: 1.0 Sender: ivoras@gmail.com Received: by 10.229.236.132 with HTTP; Mon, 9 Aug 2010 06:59:44 -0700 (PDT) In-Reply-To: <86wrs055dj.fsf@ds4.des.no> References: <20100808103055.GA2037@garage.freebsd.pl> <86pqxstbhb.fsf@ds4.des.no> <86wrs055dj.fsf@ds4.des.no> From: Ivan Voras Date: Mon, 9 Aug 2010 15:59:44 +0200 X-Google-Sender-Auth: uLS1zjXa7gb-LBKckuFyV0GW57E Message-ID: To: =?UTF-8?Q?Dag=2DErling_Sm=C3=B8rgrav?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, =?UTF-8?Q?Marius_N=C3=BCnnerich?= , freebsd-current@freebsd.org, freebsd-geom@freebsd.org Subject: Re: glabel "force sectorsize" patch X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2010 14:00:16 -0000 On 9 August 2010 14:37, Dag-Erling Sm=C3=B8rgrav wrote: > Ivan Voras writes: >> Dag-Erling Sm=C3=B8rgrav writes: >> > Marius N=C3=BCnnerich writes: >> > > I did not think of a new GEOM class that looks like glabel but one >> > > that has no metadata stored on disk . It is then activated and >> > > controlled by loader.conf variables. (Maybe like gnop? If I >> > > remember correctly, I did not take a look at that class for ages). >> > As you would know if you had followed the discussion about WD EARS >> > disks, gnop does what you want and is currently the recommended >> > solution. >> Of course, but gnop as a testing GEOM class, does not save its >> metadata, meaning it has to be reconfigured after reboot, etc. > > Please read what Marius wrote, which I quoted above. You are right, I skipped that part of his message. Gnop fits that. From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 9 17:24:22 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5D3B7106564A for ; Mon, 9 Aug 2010 17:24:22 +0000 (UTC) (envelope-from snabb@epipe.com) Received: from tiktik.epipe.com (tiktik.epipe.com [IPv6:2001:470:8940:10::1]) by mx1.freebsd.org (Postfix) with ESMTP id 13CDB8FC0A for ; Mon, 9 Aug 2010 17:24:21 +0000 (UTC) Received: from tiktik.epipe.com (tiktik.epipe.com [IPv6:2001:470:8940:10::1]) by tiktik.epipe.com (8.14.4/8.14.4) with ESMTP id o79HOKu9061626 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Aug 2010 17:24:21 GMT (envelope-from snabb@epipe.com) X-DKIM: Sendmail DKIM Filter v2.8.3 tiktik.epipe.com o79HOKu9061626 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=epipe.com; s=default; t=1281374661; x=1281979461; bh=Ix2bVVfHYPrfAp1q4/zMUZQkFT2aKAnHUN3XAnMPJsU=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References: MIME-Version:Content-Type:Content-ID; b=g9xuCha7RtdR53FBBFfBIpxKC+v7SScR9rnk8XFj37urtGHulIrs8/4VFROEvCqYK GiPXML5ups85olnnDgSC2ur+CLmClmhFxo6ocztqTpCoiAzmPYJQ7b/K5l8J93KCKx 3+MhD0Z/9++elfUaia7O7OvBA1p0WiQ3MLPsF4hM= Date: Mon, 9 Aug 2010 17:24:20 +0000 (UTC) From: Janne Snabb To: Sergio Ligregni In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: X-Mailman-Approved-At: Mon, 09 Aug 2010 17:44:49 +0000 Cc: freebsd-hackers@freebsd.org Subject: Re: Improvement for Distributed Audit Project X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2010 17:24:22 -0000 On Thu, 29 Jul 2010, Sergio Ligregni wrote: > /* > * We have these posibilities, only the first one is allowed > * 20100619223115.20100619223131 20100619223131.not_terminated > * current > */ > if (strlen(path) == 29 && path[14] == '.' && isdigit(path[15])) { > /* XXX To improve this checking later */ > return 1; > } Please note that the file names have an addiitional suffix in case "host" is defined in /etc/security/audit_control. -- Janne Snabb / EPIPE Communications snabb@epipe.com - http://epipe.com/ From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 9 19:38:32 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ACFB21065674 for ; Mon, 9 Aug 2010 19:38:32 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 383658FC14 for ; Mon, 9 Aug 2010 19:38:31 +0000 (UTC) Received: by ewy26 with SMTP id 26so4168510ewy.13 for ; Mon, 09 Aug 2010 12:38:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=/qT7qAO5o5+FpDdJa0Whwkm/bhY/XxVrRwmv6Ar6UxQ=; b=mb3kaGd+/r5pyE1jnQ87NaL+B/tS+MnDUsXSTHu6RppL2Qt8maGvbXziiegOBV+QbN sNXyKDmkxXdHg2aIoUEZ7rmUHeL4SEmySpKuIgCAmHQkEwQLB9F9vRhlwrasQT/ufYBh xETVtDuH0gFx/fdZeEEdWGBgGASp/fOn2IGLU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=YYZZ5nno3E3+4aa++NqHCIt2b8TY/PB0usRVTHMHBbAv9O0sD/x+6EJFr0L+0Q7pOA rknwC7igh3ZwoOTaKESyDsm3+58+RgJPx29rYBc7O5eSmRkFy9sThBpEmSrFtmhb78zh d/tKFULLXTixDXGOzZEGpZJZyKDfeBRLHztlc= Received: by 10.213.19.74 with SMTP id z10mr12542878eba.37.1281382711096; Mon, 09 Aug 2010 12:38:31 -0700 (PDT) Received: from centel.dataix.local (adsl-99-19-46-227.dsl.klmzmi.sbcglobal.net [99.19.46.227]) by mx.google.com with ESMTPS id a48sm8361861eei.19.2010.08.09.12.38.29 (version=SSLv3 cipher=RC4-MD5); Mon, 09 Aug 2010 12:38:29 -0700 (PDT) Sender: "J. Hellenthal" Message-ID: <4C605933.5010309@dataix.net> Date: Mon, 09 Aug 2010 15:38:27 -0400 From: jhell User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.8) Gecko/20100806 Lightning/1.0b1 Thunderbird MIME-Version: 1.0 CC: freebsd-hackers@freebsd.org References: In-Reply-To: X-Enigmail-Version: 1.1.2 OpenPGP: id=89D8547E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: Improvement for Distributed Audit Project X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2010 19:38:32 -0000 On 08/09/2010 13:24, Janne Snabb wrote: > On Thu, 29 Jul 2010, Sergio Ligregni wrote: > >> /* >> * We have these posibilities, only the first one is allowed >> * 20100619223115.20100619223131 20100619223131.not_terminated >> * current >> */ >> if (strlen(path) == 29 && path[14] == '.' && isdigit(path[15])) { >> /* XXX To improve this checking later */ >> return 1; >> } > > Please note that the file names have an addiitional suffix in case > "host" is defined in /etc/security/audit_control. > Also note that auditd(8) complains to syslog that 'host:' is not set correctly in audit_control(5) currently. This may serve as a warning but it gets on your nerves after a while when you look at it like a error when you first see it. Since it deals with the audit system first glance of the warning sends error alerts off in your head. messages.0:Jun 4 19:47:15 disbatch auditd[1666]: audit_control(5) may be missing 'host:' field Is there some way that this could be silenced without actually adding 'host:' to audit_control(5) ? Maybe a possibility to just add 'host:localhost' to the default configuration of audit_control(5) ? If localhost would be an option and logging audits to a remote machine comes into play then would it be wise to ignore distribution of localhost from the receiving machine ? Regards, -- jhell,v From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 10 01:53:47 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8B9D11065677 for ; Tue, 10 Aug 2010 01:53:47 +0000 (UTC) (envelope-from arundel@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 5D6EF8FC14 for ; Tue, 10 Aug 2010 01:53:47 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o7A1rldC026438 for ; Tue, 10 Aug 2010 01:53:47 GMT (envelope-from arundel@freefall.freebsd.org) Received: (from arundel@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o7A1rlJW026437 for freebsd-hackers@freebsd.org; Tue, 10 Aug 2010 01:53:47 GMT (envelope-from arundel) Date: Tue, 10 Aug 2010 01:53:47 +0000 From: Alexander Best To: freebsd-hackers@freebsd.org Message-ID: <20100810015347.GA17233@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="vtzGhvizbBRQ85DL" Content-Disposition: inline Subject: tiny sys/sys/signal.h cleanup X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 01:53:47 -0000 --vtzGhvizbBRQ85DL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline hi there, just wanted to get some feedback for this tiny patch and if people think it makes sense. cheers. alex -- a13x --vtzGhvizbBRQ85DL Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="signal.h.diff" Index: sys/sys/signal.h =================================================================== --- sys/sys/signal.h (revision 211114) +++ sys/sys/signal.h (working copy) @@ -47,6 +47,14 @@ /* * System defined signals. + * + * Unlike previous signal facilities, the handler will not be reset when caught + * and remains installed after a signal has been delivered. + * + * With the exception of the SIGKILL and SIGSTOP signals, all other signals can + * be caught, be ignored, or generate an interrupt. Any attempt to ignore or + * supply a handler for SIGKILL or SIGSTOP will fail with error EINVAL and no + * action will take place. */ #if __POSIX_VISIBLE || __XSI_VISIBLE #define SIGHUP 1 /* hangup */ @@ -55,9 +63,9 @@ #if __POSIX_VISIBLE || __XSI_VISIBLE #define SIGQUIT 3 /* quit */ #endif -#define SIGILL 4 /* illegal instr. (not reset when caught) */ +#define SIGILL 4 /* illegal instruction */ #if __XSI_VISIBLE -#define SIGTRAP 5 /* trace trap (not reset when caught) */ +#define SIGTRAP 5 /* trace trap */ #endif #define SIGABRT 6 /* abort() */ #if __BSD_VISIBLE @@ -66,7 +74,7 @@ #endif #define SIGFPE 8 /* floating point exception */ #if __POSIX_VISIBLE || __XSI_VISIBLE -#define SIGKILL 9 /* kill (cannot be caught or ignored) */ +#define SIGKILL 9 /* kill */ #endif #if __POSIX_VISIBLE >= 200112 || __XSI_VISIBLE #define SIGBUS 10 /* bus error */ --vtzGhvizbBRQ85DL-- From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 10 09:18:09 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 77E241065679 for ; Tue, 10 Aug 2010 09:18:09 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id E9EC48FC12 for ; Tue, 10 Aug 2010 09:18:08 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o7A9I62D075875 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Aug 2010 12:18:06 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id o7A9I62W042805; Tue, 10 Aug 2010 12:18:06 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o7A9I60R042804; Tue, 10 Aug 2010 12:18:06 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 10 Aug 2010 12:18:06 +0300 From: Kostik Belousov To: Alexander Best Message-ID: <20100810091806.GC2396@deviant.kiev.zoral.com.ua> References: <20100810015347.GA17233@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UPT3ojh+0CqEDtpF" Content-Disposition: inline In-Reply-To: <20100810015347.GA17233@freebsd.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean Cc: freebsd-hackers@freebsd.org Subject: Re: tiny sys/sys/signal.h cleanup X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 09:18:09 -0000 --UPT3ojh+0CqEDtpF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 10, 2010 at 01:53:47AM +0000, Alexander Best wrote: > hi there, >=20 > just wanted to get some feedback for this tiny patch and if people think = it > makes sense. I almost agree with the part of the patch that removes excessive commenting for the individual signals. But I do not see much sense in repeating the text that would be better suited for the man page, like signal(3). --UPT3ojh+0CqEDtpF Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkxhGU4ACgkQC3+MBN1Mb4gOGgCdF6xXX9/G9kUEaddBeDCsvhAS ol4AnAtpjOn9pf2dRSYT5SWwVUlhFYn5 =YjR3 -----END PGP SIGNATURE----- --UPT3ojh+0CqEDtpF-- From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 10 10:02:39 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id E61DA1065677; Tue, 10 Aug 2010 10:02:39 +0000 (UTC) Date: Tue, 10 Aug 2010 10:02:39 +0000 From: Alexander Best To: Kostik Belousov Message-ID: <20100810100239.GA74125@freebsd.org> References: <20100810015347.GA17233@freebsd.org> <20100810091806.GC2396@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100810091806.GC2396@deviant.kiev.zoral.com.ua> Cc: freebsd-hackers@freebsd.org Subject: Re: tiny sys/sys/signal.h cleanup X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 10:02:40 -0000 On Tue Aug 10 10, Kostik Belousov wrote: > On Tue, Aug 10, 2010 at 01:53:47AM +0000, Alexander Best wrote: > > hi there, > > > > just wanted to get some feedback for this tiny patch and if people think it > > makes sense. > > I almost agree with the part of the patch that removes excessive commenting > for the individual signals. But I do not see much sense in repeating the > text that would be better suited for the man page, like signal(3). actually a lot of the comment is taken from signal(3). ;) i don't think however signals should be explained merely in one manual. sigaction(2) e.g. also documents the signals. so i thought having a brief explanation of the signals in signal.h would be helpful. plus as you said it gets rid of some of the individual signal-comments. cheers. alex -- a13x From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 10 08:28:30 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 05BC11065678 for ; Tue, 10 Aug 2010 08:28:30 +0000 (UTC) (envelope-from clement.lecigne@netasq.com) Received: from work.netasq.com (mars.netasq.com [91.212.116.3]) by mx1.freebsd.org (Postfix) with ESMTP id 9832C8FC14 for ; Tue, 10 Aug 2010 08:28:29 +0000 (UTC) Received: from localhost (unknown [10.2.0.1]) by work.netasq.com (Postfix) with ESMTP id 32D6E30CAF62 for ; Tue, 10 Aug 2010 10:08:45 +0200 (CEST) Date: Tue, 10 Aug 2010 10:08:20 +0200 From: Clement LECIGNE To: freebsd-hackers@freebsd.org Message-ID: <20100810080818.GA24002@clem1.netasq.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.5.19 (2009-01-05) X-Mailman-Approved-At: Tue, 10 Aug 2010 11:15:35 +0000 Subject: Optimized memcmp failure. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 08:28:30 -0000 Hi, Here is a link to a blog post speaking about timing attacks. http://rdist.root.org/2010/08/05/optimized-memcmp-leaks-useful-timing-differences/ It describes various memcmp() implementations of some OSes. FreeBSD is mentionned at the end of the post and it warns about the fact that gcc uses its own builtin memcmp() function when optimization (from O1 to O3) is set. Unfortunately the gcc builtin memcmp() seems less optimized (at least for i386 and amd64) than the FreeBSD memcmp() implementation (found in libc). I wonder if you know about that and if it could be a good thing to remove this feature during buildworld (through -fno-builtin or anything else) ? clem1~> cat memcmp.c int main(int ac, char **av){return memcmp("abcd", av[0], 4);} clem1~> gcc -O0 -S memcmp.c && cat memcmp.s (...) call memcmp (...) clem1~> gcc -O1 -S memcmp.c && cat memcmp.s (...) movl $4, %ecx cld repz cmpsb seta %al setb %dl subb %dl, %al movsbl %al,%eax (...) Cheers, -- Clement LECIGNE, « Hardly surprising. Apple. They build crap and make you pay extra. » From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 10 11:39:40 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A90FF106564A for ; Tue, 10 Aug 2010 11:39:40 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 6E1CB8FC13 for ; Tue, 10 Aug 2010 11:39:40 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:1c:f90a:bce2:9ed4] (unknown [IPv6:2001:7b8:3a7:0:1c:f90a:bce2:9ed4]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 448D25C43; Tue, 10 Aug 2010 13:39:39 +0200 (CEST) Message-ID: <4C613A83.9010809@andric.com> Date: Tue, 10 Aug 2010 13:39:47 +0200 From: Dimitry Andric User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.9pre) Gecko/20100803 Lanikai/3.1.3pre MIME-Version: 1.0 To: Clement LECIGNE References: <20100810080818.GA24002@clem1.netasq.com> In-Reply-To: <20100810080818.GA24002@clem1.netasq.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: Optimized memcmp failure. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 11:39:40 -0000 On 2010-08-10 10:08, Clement LECIGNE wrote: > It describes various memcmp() implementations of some OSes. FreeBSD is > mentionned at the end of the post and it warns about the fact that gcc > uses its own builtin memcmp() function when optimization (from O1 to O3) > is set. Unfortunately the gcc builtin memcmp() seems less optimized (at > least for i386 and amd64) than the FreeBSD memcmp() implementation (found > in libc). Some of the libc memcmp/cpy/etc implementations are hand-optimized assembly, and those might very well be faster than the built-in ones, for the general case. However, in some cases, the compiler has more information about the context in which a copy operation is taking place, and might be able to simplify the copy so much that it is more efficient than the libc memcpy. That said, the mentioned security issue is about sensitive information (the length of secret keys, etc) possibly being derived from timing memcpy calls. In that case it would probably even be better to let the compiler inline that code, since you cannot simply hook the libc memcpy function anymore. :) Better solutions for this (and similar issues) are more costly: you have to go through all code handling sensitive data carefully, identify the memcpy/memcmp/etc calls that could possibly leak secret information, and replace those with 'timing insensitive' versions. OpenBSD just went through a whole bunch of these checks... From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 10 17:37:13 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C8F21106567C for ; Tue, 10 Aug 2010 17:37:13 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe11.tele2.se [212.247.155.65]) by mx1.freebsd.org (Postfix) with ESMTP id 5D0118FC1B for ; Tue, 10 Aug 2010 17:37:12 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=v89yDwyNY1EA:10 a=8nJEP1OIZ-IA:10 a=M8b_wTzEtboA:10 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=8kQB0OdkAAAA:8 a=rYIz90Yos4e7FC7J1LAA:9 a=kJ5shmO7C9yzjAxWpleGwBfg5zwA:4 a=wPNLvfGTeEIA:10 a=9aOQ2cSd83gA:10 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe11.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 1249170766; Tue, 10 Aug 2010 19:32:10 +0200 From: Hans Petter Selasky To: Neel Natu Date: Tue, 10 Aug 2010 19:28:40 +0200 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.4.5; amd64; ; ) References: <201008041918.54028.hselasky@c2i.net> <201008042129.32095.hselasky@c2i.net> In-Reply-To: X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'(; _IjlA: hGE..Ew, XAQ*o#\/M~SC=S1-f9{EzRfT'|Hhll5Q]ha5Bt-s|oTlKMusi:1e[wJl}kd}GR Z0adGx-x_0zGbZj'e(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201008101928.40492.hselasky@c2i.net> Cc: freebsd-hackers@freebsd.org Subject: Re: Not getting interrupts from PCI express slot X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 17:37:14 -0000 On Wednesday 04 August 2010 23:24:12 Neel Natu wrote: > Hi, > > On Wed, Aug 4, 2010 at 12:29 PM, Hans Petter Selasky wrote: > > On Wednesday 04 August 2010 21:13:55 Neel Natu wrote: > >> Hi, > >> > >> On Wed, Aug 4, 2010 at 10:18 AM, Hans Petter Selasky > > > > wrote: > >> > Hi, > >> > > >> > I'm not getting any interrupts from a PCI express slot. When I insert > >> > a device, no attach event is generated. If the device is present > >> > during boot the device is fully detected, but still no IRQ's. Is > >> > there anything I can do or test? > >> > >> Is the driver using legacy INT-A style interrupt or MSI/MSI-X? > > > > I don't know. How can I find out. It is a PCI driver like EHCI. > > I looked at the ehci_pci.c driver and it looks like it only requests > legacy interrupt. It may be that the legacy interrupt routing is > screwed up by the BIOS. > Hi, > You can try a few things to narrow this down a bit: > > % devinfo -ru: this will tell you which irq is being assigned to the ehci > device > devinfo -ru | grep -Ei "irq|port|xhci" 16 (xhci0) I/O ports: 0xf6000000-0xf6001fff (xhci0) ACPI I/O ports: > % vmstat -i: this will tell you the number of interrupts received on > that irq. It would be especially telling if you saw any stray > interrupts as it may indicate bad interrupt routing. > vmstat -i irq16: xhci0 5538390 957 Thanks for your reply. I'm now getting interrupts like other PCI devices. The only problem left is that my XHCI PCI express device does not generate an attach event when inserted. It is only detected if I boot with the device plugged in. Is it so to understand that PCI express system is not supported? How much effort would be required to add support for this? --HPS From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 10 17:44:50 2010 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5D7DB1065674 for ; Tue, 10 Aug 2010 17:44:50 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 222518FC1B for ; Tue, 10 Aug 2010 17:44:49 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 913391FFC33; Tue, 10 Aug 2010 17:44:48 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 4C3F18452D; Tue, 10 Aug 2010 19:44:48 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: hackers@freebsd.org, geom@freebsd.org Date: Tue, 10 Aug 2010 19:44:48 +0200 Message-ID: <86wrry1hwv.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Subject: Support for WD Advanced Format disks X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 17:44:50 -0000 I'm looking into a clean, permanent solution for WD Green drives that use 4096-byte physical sectors. To summarize the information I've collected so far: - There are several types of WD Green disks. I am primarily interested in the 1+ TB models: EARS and EADS. - According to WD's own documentation, EARS disks are Advanced Format while EADS disks are not; furthermore, EARS disks have 64 MB cache while EADS disks have only 32 MB. - There is at least one source that provides model and serial numbers for two EADS disks that seem have the performance characteristics of an Advanced Format disk. One of them actually reports 4096-byte sectors, the other does not. I am not entirely certain that source is reliable. - Advanced Format disks should have a label that clearly describes them as such: http://media.bestofmicro.com/U/O/238272/original/Western-Digital-WD10EARS-t= op.jpg - I received an EADS disk and performed measurements which clearly show that it is *not* an Advanced Format disk. I had no trouble achieving 50 MBps with misaligned 8192-byte writes. Right now, I have two requests. The first is that people who have Advanced Format disks run a program I wrote that measures the performance of aligned and misaligned writes of different sizes. % svn co http://svn.freebsd.org/base/user/des/phybs % cd phybs % make % ./phybs -w /dev/adN Please note: - This test is *destructive*. Do not run it on a disk that contains data you care about; it *will* destroy them. - You can not run it on a file, but you *can* run it on a partition instead of the whole disk. You can even run it on a misaligned partition; the results will show by how much the partition is misaligned. - The test takes a long time. It took about half an hour on a WD20EADS connected by eSATA. It may take several hours on an Advanced Format disk. If you are impatient, try bumping MINSIZE to 1024 in phybs.c. The second request is for some kind soul to send me an EARS drive to play with; please contact me off-list if you're interested. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 10 19:05:39 2010 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 64350106566B; Tue, 10 Aug 2010 19:05:39 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from mail.bitblocks.com (mail.bitblocks.com [64.142.15.60]) by mx1.freebsd.org (Postfix) with ESMTP id 468008FC12; Tue, 10 Aug 2010 19:05:39 +0000 (UTC) Received: from bitblocks.com (localhost.bitblocks.com [127.0.0.1]) by mail.bitblocks.com (Postfix) with ESMTP id 21FED5B5A; Tue, 10 Aug 2010 11:48:53 -0700 (PDT) To: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= In-reply-to: Your message of "Tue, 10 Aug 2010 19:44:48 +0200." <86wrry1hwv.fsf@ds4.des.no> References: <86wrry1hwv.fsf@ds4.des.no> Comments: In-reply-to =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= message dated "Tue, 10 Aug 2010 19:44:48 +0200." Date: Tue, 10 Aug 2010 11:48:53 -0700 From: Bakul Shah Message-Id: <20100810184853.21FED5B5A@mail.bitblocks.com> Cc: geom@freebsd.org, hackers@freebsd.org Subject: Re: Support for WD Advanced Format disks X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 19:05:39 -0000 On Tue, 10 Aug 2010 19:44:48 +0200 =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= wrote: > I'm looking into a clean, permanent solution for WD Green drives that > use 4096-byte physical sectors. To summarize the information I've > collected so far: > > - There are several types of WD Green disks. I am primarily interested > in the 1+ TB models: EARS and EADS. > > - According to WD's own documentation, EARS disks are Advanced Format > while EADS disks are not; furthermore, EARS disks have 64 MB cache > while EADS disks have only 32 MB. http://www.wdc.com/en/library/2579-001028.pdf gives an explanation of what the drive letters mean but they don't talk about 4k sector size. > - There is at least one source that provides model and serial numbers > for two EADS disks that seem have the performance characteristics of > an Advanced Format disk. One of them actually reports 4096-byte > sectors, the other does not. I am not entirely certain that source > is reliable. See below. > - Advanced Format disks should have a label that clearly describes them > as such: > > http://media.bestofmicro.com/U/O/238272/original/Western-Digital-WD10EARS-top.jpg >From http://www.wdc.com/en/products/advancedformat/ What models utilize Advanced Format technology? Some models of the WD Caviar Green and WD Scorpio Blue product families are built using Advanced Format technology. Over time more models and capacities will be added. WD drives with Advanced Format technology include special installation information on the drive label so be sure to read the label on your drive before installing it. ^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ So it seems that only the label distinguishes 4k sector drives. From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 10 19:11:49 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 88CA2106566C for ; Tue, 10 Aug 2010 19:11:49 +0000 (UTC) (envelope-from mj@feral.com) Received: from ns1.feral.com (ns1.feral.com [192.67.166.1]) by mx1.freebsd.org (Postfix) with ESMTP id 3D9278FC12 for ; Tue, 10 Aug 2010 19:11:47 +0000 (UTC) Received: from [192.168.221.2] (remotevpn [192.168.221.2]) by ns1.feral.com (8.14.3/8.14.3) with ESMTP id o7AJBk4f022182 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 10 Aug 2010 12:11:46 -0700 (PDT) (envelope-from mj@feral.com) Message-ID: <4C61A46E.50200@feral.com> Date: Tue, 10 Aug 2010 12:11:42 -0700 From: Matthew Jacob Organization: Feral Software User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <86wrry1hwv.fsf@ds4.des.no> <20100810184853.21FED5B5A@mail.bitblocks.com> In-Reply-To: <20100810184853.21FED5B5A@mail.bitblocks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender DNS name whitelisted, not delayed by milter-greylist-4.2.3 (ns1.feral.com [192.168.221.1]); Tue, 10 Aug 2010 12:11:46 -0700 (PDT) Subject: Re: Support for WD Advanced Format disks X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 19:11:49 -0000 Is there truly no IDENTIFY information to determine the drive format? From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 10 21:08:43 2010 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0947410656AB; Tue, 10 Aug 2010 21:08:43 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id C03B88FC0A; Tue, 10 Aug 2010 21:08:42 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 9C9491FFC33; Tue, 10 Aug 2010 21:08:41 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 74D9F8455C; Tue, 10 Aug 2010 23:08:41 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Bakul Shah References: <86wrry1hwv.fsf@ds4.des.no> <20100810184853.21FED5B5A@mail.bitblocks.com> Date: Tue, 10 Aug 2010 23:08:41 +0200 In-Reply-To: <20100810184853.21FED5B5A@mail.bitblocks.com> (Bakul Shah's message of "Tue, 10 Aug 2010 11:48:53 -0700") Message-ID: <86mxsunpk6.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: geom@freebsd.org, hackers@freebsd.org Subject: Re: Support for WD Advanced Format disks X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 21:08:43 -0000 Bakul Shah writes: > http://www.wdc.com/en/library/2579-001028.pdf gives an > explanation of what the drive letters mean but they don't > talk about 4k sector size. The latest data sheet for the entire Green series is here: http://www.wdc.com/wdproducts/library/SpecSheet/ENG/2879-701229.pdf > Some models of the WD Caviar Green and WD Scorpio Blue > product families are built using Advanced Format technology. > Over time more models and capacities will be added. WD drives > with Advanced Format technology include special installation > information on the drive label so be sure to read the label > on your drive before installing it. ^^^^^^^^^^^^^^ > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > So it seems that only the label distinguishes 4k sector drives. The data sheet clearly says that *only* AARS and EARS disks are AF. Also, it's not just the label - AF disks have AF-specific jumper settings. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 10 22:50:14 2010 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0D5591065679; Tue, 10 Aug 2010 22:50:14 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from mail.bitblocks.com (mail.bitblocks.com [64.142.15.60]) by mx1.freebsd.org (Postfix) with ESMTP id E8FEF8FC19; Tue, 10 Aug 2010 22:50:13 +0000 (UTC) Received: from bitblocks.com (localhost.bitblocks.com [127.0.0.1]) by mail.bitblocks.com (Postfix) with ESMTP id A8CE35B67; Tue, 10 Aug 2010 15:50:12 -0700 (PDT) To: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= In-reply-to: Your message of "Tue, 10 Aug 2010 23:08:41 +0200." <86mxsunpk6.fsf@ds4.des.no> References: <86wrry1hwv.fsf@ds4.des.no> <20100810184853.21FED5B5A@mail.bitblocks.com> <86mxsunpk6.fsf@ds4.des.no> Comments: In-reply-to =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= message dated "Tue, 10 Aug 2010 23:08:41 +0200." Date: Tue, 10 Aug 2010 15:50:12 -0700 From: Bakul Shah Message-Id: <20100810225012.A8CE35B67@mail.bitblocks.com> Cc: geom@freebsd.org, hackers@freebsd.org Subject: Re: Support for WD Advanced Format disks X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 22:50:14 -0000 After poking around some, it seems ATA/ATAPI-7 Identify Device word 106 bit 13 is set to 1 and bits 0-3 are set to 3 (for 2^3 or 8 LBAs per sector) for a 4KB sector size (pin 7-8 jumper on a WD AF disks presumably changes this setting to 0,0). See page 121 of Atapi-7 volume 1 (google for ata-atapi-7.pdf). Hopefully this helps in whatever `clean solution' you are looking for? From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 10 23:09:47 2010 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D1AF71065676 for ; Tue, 10 Aug 2010 23:09:47 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (m209-73.dsl.rawbw.com [198.144.209.73]) by mx1.freebsd.org (Postfix) with ESMTP id 8ADF78FC1F for ; Tue, 10 Aug 2010 23:09:47 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.4/8.14.4) with ESMTP id o7AMcb7Y043386 for ; Tue, 10 Aug 2010 15:38:37 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.4/8.14.4/Submit) id o7AMcbGq043385 for hackers@freebsd.org; Tue, 10 Aug 2010 15:38:37 -0700 (PDT) (envelope-from david) Date: Tue, 10 Aug 2010 15:38:37 -0700 From: David Wolfskill To: hackers@freebsd.org Message-ID: <20100810223837.GQ22509@albert.catwhisker.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Pk/CTwBz1VvfPIDp" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: When should "netstat -i" truncate output? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 23:09:48 -0000 --Pk/CTwBz1VvfPIDp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable src/usr.bin/netstat/if.c was modified back in late November 1995, to expand the "Network" field from 11 characters to 13: | Revision 12459 - (view) (annotate) - [select for diffs] | Modified Wed Nov 22 22:21:04 1995 UTC (14 years, 8 months ago) by se | File length: 11619 byte(s) | Diff to previous 11819 |=20 | Increase width of Network column from 11 to 13 for the AF_INET case. | This seems to have been missed, when the recent IPX changes went in ... While I appreciate the thought & effort, it should be readily apparent that even 13 characters is insufficient to represent even an IPv4 address in dotted quad format (in the general case), let alone a network specification in CIDR format: 192.168.127.126/29 is 15 characters for the IPv4 address part itself, plus another 3 for the mask, totalling 18. I just checked NetBSD sources (), and it appears that they (also) use "%-13.13s" as the format specification for Network. (OpenBSD appears to use "%-11.11s", thus limiting the output to 11 characters.) OpenSolaris, per apparently uses "%-14s" as the format specification -- which avoids the (potentail) truncation issue entirely. I realize that the information in question is avaiklable in other ways, but limiting the size of the "Network" field of netstat(1) to 13 characters yields some rather ... odd ... results -- e.g.: d254(7.3-S)[23] netstat -nif inet Name Mtu Network Address Ipkts Ierrs Opkts Oerrs = Coll xl0 1500 192.168.7.0/2 192.168.7.254 95210 - 90017 - = - lo0 16384 127.0.0.0/8 127.0.0.1 195 - 195 - = - d254(7.3-S)[24]=20 As evidence that the xl0 NIX is, in fact, not on a /2, I submit: d254(7.3-S)[24] netstat -nrf inet Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 192.168.7.1 UGS 0 61386 xl0 127.0.0.1 127.0.0.1 UH 0 195 lo0 192.168.7.0/24 link#1 UC 0 0 xl0 192.168.7.1 00:1a:a0:62:96:09 UHLW 2 286 xl0 431 d254(7.3-S)[25] ifconfig xl0 xl0: flags=3D8843 metric 0 mtu 1500 options=3D9 ether 00:08:74:e9:c9:41 inet 192.168.7.254 netmask 0xffffff00 broadcast 192.168.7.255 media: Ethernet autoselect (100baseTX ) status: active d254(7.3-S)[26]=20 I suppose the thing that's bugging me here is that "netstat -nif inet" appears to be mis-stating the situation. I believe it would be ideal if it were to provide correct output, but failing that, I'm tempted to suggest that it might be better to be silent on the matter. Of course, the general output of netstat(1) is fairly well entrenched in history, and I don't advocate change for its own sake. Anyone else think this is enough of a "problem" that it merits modifying the code (e.g., in netstat/if.c) a bit? Peace, david --=20 David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --Pk/CTwBz1VvfPIDp Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iEYEARECAAYFAkxh1OwACgkQmprOCmdXAD1baQCeOvrlQSsnSIoKFVyxumusG3IY i7gAn3S8FCTOgxTiQcnM2gKHKJrqj+FI =y0dj -----END PGP SIGNATURE----- --Pk/CTwBz1VvfPIDp-- From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 11 04:11:36 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7CDAD1065672 for ; Wed, 11 Aug 2010 04:11:36 +0000 (UTC) (envelope-from mj@feral.com) Received: from ns1.feral.com (ns1.feral.com [192.67.166.1]) by mx1.freebsd.org (Postfix) with ESMTP id 474848FC19 for ; Wed, 11 Aug 2010 04:11:35 +0000 (UTC) Received: from [172.16.135.104] (lportal.in1.lcl [172.16.1.9]) by ns1.feral.com (8.14.3/8.14.3) with ESMTP id o7B4BZRb029607 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 10 Aug 2010 21:11:35 -0700 (PDT) (envelope-from mj@feral.com) Message-ID: <4C6222F1.8090205@feral.com> Date: Tue, 10 Aug 2010 21:11:29 -0700 From: Matthew Jacob Organization: Feral Software User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <86wrry1hwv.fsf@ds4.des.no> <20100810184853.21FED5B5A@mail.bitblocks.com> <86mxsunpk6.fsf@ds4.des.no> <20100810225012.A8CE35B67@mail.bitblocks.com> In-Reply-To: <20100810225012.A8CE35B67@mail.bitblocks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (ns1.feral.com [192.168.221.1]); Tue, 10 Aug 2010 21:11:35 -0700 (PDT) Subject: Re: Support for WD Advanced Format disks X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 04:11:36 -0000 Yes, that should be it! > After poking around some, it seems ATA/ATAPI-7 Identify > Device word 106 bit 13 is set to 1 and bits 0-3 are set to 3 > (for 2^3 or 8 LBAs per sector) for a 4KB sector size (pin 7-8 > jumper on a WD AF disks presumably changes this setting to > 0,0). See page 121 of Atapi-7 volume 1 (google for > ata-atapi-7.pdf). > > Hopefully this helps in whatever `clean solution' you are > looking for? > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 11 04:49:02 2010 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 69A0D1065672; Wed, 11 Aug 2010 04:49:02 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward1.mail.yandex.net (forward1.mail.yandex.net [77.88.46.6]) by mx1.freebsd.org (Postfix) with ESMTP id 0E1778FC15; Wed, 11 Aug 2010 04:49:01 +0000 (UTC) Received: from smtp4.mail.yandex.net (smtp4.mail.yandex.net [77.88.46.104]) by forward1.mail.yandex.net (Yandex) with ESMTP id 448B269E8FA0; Wed, 11 Aug 2010 08:49:00 +0400 (MSD) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1281502140; bh=+oYIP7PPrWNIpCcfxZuIrqh/mwUqHqiDEuwa6G4VIeM=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=ifJKDkR2gVhYEYGYfW6g82GukEwo7VBZ8CEXcdMlUDBeQl8b5F+K7MoUZSea/6Z4u CWyjpL3Djg8kjDKpDMOpJtPqsieOQMLyvFM6nOdZKAr0Mn1S9jpSKMFSRo8IEdtGI9 WGAArHwSUPU00Js7mHflU6mrEQpD0nQQyrpo8yWw= Received: from [127.0.0.1] (ns.kirov.so-ups.ru [77.72.136.145]) by smtp4.mail.yandex.net (Yandex) with ESMTPSA id E311012809F; Wed, 11 Aug 2010 08:48:59 +0400 (MSD) Message-ID: <4C622BB2.3090605@yandex.ru> Date: Wed, 11 Aug 2010 08:48:50 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: Bakul Shah References: <86wrry1hwv.fsf@ds4.des.no> <20100810184853.21FED5B5A@mail.bitblocks.com> <86mxsunpk6.fsf@ds4.des.no> <20100810225012.A8CE35B67@mail.bitblocks.com> In-Reply-To: <20100810225012.A8CE35B67@mail.bitblocks.com> X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig243CAC20AACDD45C175FCBAE" X-Yandex-TimeMark: 1281502140 X-Yandex-Spam: 1 X-Yandex-Front: smtp4.mail.yandex.net Cc: =?UTF-8?B?RGFnLUVybGluZyBTbcO4cmdyYXY=?= , Alexander Motin , hackers@freebsd.org, geom@freebsd.org Subject: Re: Support for WD Advanced Format disks X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 04:49:02 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig243CAC20AACDD45C175FCBAE Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 11.08.2010 2:50, Bakul Shah wrote: > After poking around some, it seems ATA/ATAPI-7 Identify > Device word 106 bit 13 is set to 1 and bits 0-3 are set to 3 > (for 2^3 or 8 LBAs per sector) for a 4KB sector size (pin 7-8 > jumper on a WD AF disks presumably changes this setting to > 0,0). See page 121 of Atapi-7 volume 1 (google for > ata-atapi-7.pdf). >=20 > Hopefully this helps in whatever `clean solution' you are > looking for? This information is already used by ada(4) driver. If your disk doesn't lie about sector size you can see both logical and physical sector sizes in output of `camcontrol identify ada0` command. --=20 WBR, Andrey V. Elsukov --------------enig243CAC20AACDD45C175FCBAE 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.10 (MingW32) iQEcBAEBAgAGBQJMYiu6AAoJEAHF6gQQyKF63IwH/399hfx0L7gHs85XUdGANNjY YUwBRMijGZ6bdAWVmMusRcfJupnHWFTQHxguxTlidbsJbEy6l2z5UejA93XI1zbq 1Th1oIy6NLZdMmIsZrqMGcel8zxlhgrYFJPe++qPk7jpZz2ldwIAd0cuw1O4pcit pEluSrP+9RhYo/lPKXccKbuGJYGzbQW/vOE7ZvciBfDZ21G6FxDCO8kfYbuE84Pu EuZ+GRZS0WTb9WVbI1SRqsWro0wImI9QlomBwsla3LOrjTzFuw1E4ORZBQTZZ6jI ElEj7gwhyZ55hbCIKTKvJ8CaibyIwT9vQdZXLBZFrqmARj/p0cYz/DAgO+wpf2Q= =do5u -----END PGP SIGNATURE----- --------------enig243CAC20AACDD45C175FCBAE-- From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 11 07:04:56 2010 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BE8C01065687; Wed, 11 Aug 2010 07:04:56 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward2.mail.yandex.net (forward2.mail.yandex.net [77.88.46.7]) by mx1.freebsd.org (Postfix) with ESMTP id 6B29C8FC16; Wed, 11 Aug 2010 07:04:56 +0000 (UTC) Received: from smtp3.mail.yandex.net (smtp3.mail.yandex.net [77.88.46.103]) by forward2.mail.yandex.net (Yandex) with ESMTP id 848D738A81CE; Wed, 11 Aug 2010 11:04:54 +0400 (MSD) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1281510294; bh=AqLOn4tRSupdX3bW7l5gMfNks0AkdATZ0zDDgIM2de4=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=UGm0RiSePz65MS/YO/Z2ga6/W9vo11H2Axydw6uySwRbSSLQslFdJ46d2Lu77FOqT FhtxdWU+tEHptEwJXeujOXKBogeVpDxa6Cme015SkBD3oJolPI0QDSlOTULzaqQv8p KUsfUww/Wh0Zh9On7ptUzqRpS9Hgh4SO0T2Jr7M0= Received: from [127.0.0.1] (mail.kirov.so-cdu.ru [77.72.136.145]) by smtp3.mail.yandex.net (Yandex) with ESMTPSA id 45B4027806E; Wed, 11 Aug 2010 11:04:54 +0400 (MSD) Message-ID: <4C624B90.3040101@yandex.ru> Date: Wed, 11 Aug 2010 11:04:48 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: netch@netch.kiev.ua References: <20100811060439.GD17926@netch.kiev.ua> In-Reply-To: <20100811060439.GD17926@netch.kiev.ua> X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig9ABFF4536DEDB480E6C5A675" X-Yandex-TimeMark: 1281510294 X-Yandex-Spam: 1 X-Yandex-Front: smtp3.mail.yandex.net Cc: geom@freebsd.org, hackers@freebsd.org Subject: Re: Support for WD Advanced Format disks X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 07:04:56 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig9ABFF4536DEDB480E6C5A675 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable On 11.08.2010 10:04, Valentin Nechayev wrote: > example, set up geometry xxx*64*32 for all new disks and align GPT > partitions on 1MB boundary. As soon as FS requests in FreeBSD are no > less than 4KB in size, this would satisfy any disk. >=20 > If 4KB sectors are our future for a few next years, this shall be > implemented anyway... Yet another idea - we can add auto-align feature in gpart(8) for disks, that properly reports sector size. --=20 WBR, Andrey V. Elsukov --------------enig9ABFF4536DEDB480E6C5A675 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.10 (MingW32) iQEcBAEBAgAGBQJMYkuUAAoJEAHF6gQQyKF6A5cIALJDKefh7t87xr1dHeCYZWH0 iTAOlbBuvJPZcSDo6POmz2ipSVnVprUV/DJaHBo3M9YAPpUT801WamFAr24mFsQ+ SsESHnQWI4047QFGbDt8BVfo2a54TLRpXZV0+Zl2KBogJ16sWckyY7a2eXpV6wNJ F3N4at+Auu+kI+pQbvyMnMI3wuDPreigxbgx76IRhbhIKivBqaPGdSjpQLNuNfr+ mI3AkWQ8gP0/HN/ej1JFx2wVGXm5SOGDV4Tgj/uyAXukRCCTyaqZAeKsHCKqcDjw r9pXQFR70hkPRMllOK7uzIGDsta/06okkbkle3NAfzv8uR6FgdUyjkC4qdcHN0w= =BUgA -----END PGP SIGNATURE----- --------------enig9ABFF4536DEDB480E6C5A675-- From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 11 08:27:00 2010 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A2B8A106567E; Wed, 11 Aug 2010 08:27:00 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 64C4F8FC1C; Wed, 11 Aug 2010 08:27:00 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 6C20D1FFC33; Wed, 11 Aug 2010 08:26:59 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 39D0984528; Wed, 11 Aug 2010 10:26:59 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Bakul Shah References: <86wrry1hwv.fsf@ds4.des.no> <20100810184853.21FED5B5A@mail.bitblocks.com> <86mxsunpk6.fsf@ds4.des.no> <20100810225012.A8CE35B67@mail.bitblocks.com> Date: Wed, 11 Aug 2010 10:26:58 +0200 In-Reply-To: <20100810225012.A8CE35B67@mail.bitblocks.com> (Bakul Shah's message of "Tue, 10 Aug 2010 15:50:12 -0700") Message-ID: <86sk2leer1.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: geom@freebsd.org, hackers@freebsd.org Subject: Re: Support for WD Advanced Format disks X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 08:27:00 -0000 Bakul Shah writes: > After poking around some, it seems ATA/ATAPI-7 Identify Device word > 106 bit 13 is set to 1 and bits 0-3 are set to 3 (for 2^3 or 8 LBAs > per sector) for a 4KB sector size (pin 7-8 jumper on a WD AF disks > presumably changes this setting to 0,0). See page 121 of Atapi-7 > volume 1 (google for ata-atapi-7.pdf). Yes. We already support this. The problem is that WD's Advanced Format disks (or at least some of them) lie. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 11 09:18:57 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1E9681065674 for ; Wed, 11 Aug 2010 09:18:57 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id D52E48FC0C for ; Wed, 11 Aug 2010 09:18:56 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 89CBA1FFC33; Wed, 11 Aug 2010 09:18:55 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 123EE84528; Wed, 11 Aug 2010 11:18:55 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Matthew Jacob References: <86wrry1hwv.fsf@ds4.des.no> <20100810184853.21FED5B5A@mail.bitblocks.com> <86mxsunpk6.fsf@ds4.des.no> <20100810225012.A8CE35B67@mail.bitblocks.com> <4C6222F1.8090205@feral.com> Date: Wed, 11 Aug 2010 11:18:55 +0200 In-Reply-To: <4C6222F1.8090205@feral.com> (Matthew Jacob's message of "Tue, 10 Aug 2010 21:11:29 -0700") Message-ID: <86bp99eccg.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: Support for WD Advanced Format disks X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 09:18:57 -0000 Matthew Jacob writes: > Yes, that should be it! No, it shouldn't, cf. extensive discussion about EARS disks on -current. They lie about their physical sector size. There's a jumper setting for "Windows XP compatibility", but apparently, it only affects the (fake) geometry the disk reports to the BIOS. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 11 11:06:41 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2BA24106566C for ; Wed, 11 Aug 2010 11:06:41 +0000 (UTC) (envelope-from dan@langille.org) Received: from nyi.unixathome.org (nyi.unixathome.org [64.147.113.42]) by mx1.freebsd.org (Postfix) with ESMTP id 012BD8FC0A for ; Wed, 11 Aug 2010 11:06:40 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by nyi.unixathome.org (Postfix) with ESMTP id 9B4B950BC3; Wed, 11 Aug 2010 11:47:26 +0100 (BST) X-Virus-Scanned: amavisd-new at unixathome.org Received: from nyi.unixathome.org ([127.0.0.1]) by localhost (nyi.unixathome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pcjy48lW-cEa; Wed, 11 Aug 2010 11:47:25 +0100 (BST) Received: from smtp-auth.unixathome.org (smtp-auth.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) by nyi.unixathome.org (Postfix) with ESMTPSA id B9F2C50BBF ; Wed, 11 Aug 2010 11:47:25 +0100 (BST) Message-ID: <4C627FB1.5060007@langille.org> Date: Wed, 11 Aug 2010 06:47:13 -0400 From: Dan Langille Organization: The FreeBSD Diary User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Andrew Heybey Subject: 8.1-STABLE amd64 machine check X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 11:06:41 -0000 I am encountering a situation similar to one reported by Andrew Heybey at http://docs.freebsd.org/cgi/mid.cgi?6E83197B-9DD5-4C7E-846D-AD176C25464D This morning I found this in my /var/log/messages: Aug 11 01:59:48 kraken kernel: MCA: Bank 4, Status 0x94614c62001c011b Aug 11 01:59:48 kraken kernel: MCA: Global Cap 0x0000000000000106, Status 0x0000000000000000 Aug 11 01:59:48 kraken kernel: MCA: Vendor "AuthenticAMD", ID 0x100f42, APIC ID 0 Aug 11 01:59:48 kraken kernel: MCA: CPU 0 COR GCACHE LG RD error Aug 11 01:59:48 kraken kernel: MCA: Address 0x5d0fe8c from /var/run/dmesg.boot Copyright (c) 1992-2010 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.1-STABLE #0: Sun Jul 25 19:18:56 EDT 2010 dan@kraken.example.org:/usr/obj/usr/src/sys/KRAKEN amd64 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Phenom(tm) II X4 945 Processor (3010.17-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x100f42 Family = 10 Model = 4 Stepping = 2 Features=0x178bfbff Features2=0x802009 AMD Features=0xee500800 AMD Features2=0x37ff TSC: P-state invariant real memory = 4294967296 (4096 MB) avail memory = 4100710400 (3910 MB) ACPI APIC Table: <111909 APIC1708> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 Andrew: You posted about this on July 14. Anything new since then? John: Is it time for me to get a new CPU? thanks -- Dan Langille - http://langille.org/ From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 11 06:16:01 2010 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 716561065672; Wed, 11 Aug 2010 06:16:01 +0000 (UTC) (envelope-from netch@segfault.kiev.ua) Received: from segfault.kiev.ua (segfault.kiev.ua [193.193.193.4]) by mx1.freebsd.org (Postfix) with ESMTP id F2C548FC14; Wed, 11 Aug 2010 06:16:00 +0000 (UTC) Received: from segfault.kiev.ua (localhost.segfault.kiev.ua [127.0.0.1]) by segfault.kiev.ua (8.14.4/8.14.4/8.Who.Cares) with ESMTP id o7B64iE5079932; Wed, 11 Aug 2010 09:04:44 +0300 (EEST) (envelope-from netch@segfault.kiev.ua) Received: (from netch@localhost) by segfault.kiev.ua (8.14.4/8.14.4/Submit) id o7B64dre079929; Wed, 11 Aug 2010 09:04:39 +0300 (EEST) (envelope-from netch) Date: Wed, 11 Aug 2010 09:04:39 +0300 From: Valentin Nechayev To: hackers@freebsd.org, geom@freebsd.org Message-ID: <20100811060439.GD17926@netch.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86wrry1hwv.fsf@ds4.des.no> X-42: On X-Mailman-Approved-At: Wed, 11 Aug 2010 11:23:13 +0000 Cc: Subject: Re: Support for WD Advanced Format disks X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: netch@netch.kiev.ua List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 06:16:01 -0000 > I'm looking into a clean, permanent solution for WD Green drives that > use 4096-byte physical sectors. To summarize the information I've > collected so far: There is attempt to look from another side - is it really needed? Captain Obvious says that if one have a new disk, it's easy to format it properly - i.e. not xxx*16*63 but aligned on 4KB boundary. For example, set up geometry xxx*64*32 for all new disks and align GPT partitions on 1MB boundary. As soon as FS requests in FreeBSD are no less than 4KB in size, this would satisfy any disk. If 4KB sectors are our future for a few next years, this shall be implemented anyway... -netch- From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 11 11:31:43 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5DFFE106564A; Wed, 11 Aug 2010 11:31:43 +0000 (UTC) (envelope-from ath@niksun.com) Received: from anuket.mj.niksun.com (gwnew.niksun.com [65.115.46.162]) by mx1.freebsd.org (Postfix) with ESMTP id 19CB18FC0C; Wed, 11 Aug 2010 11:31:41 +0000 (UTC) Received: from NCES01.mj.niksun.com (nces01.mj.niksun.com [10.25.8.17]) by anuket.mj.niksun.com (8.13.6/8.13.6) with ESMTP id o7BBVe8k078073; Wed, 11 Aug 2010 07:31:40 -0400 (EDT) (envelope-from ath@niksun.com) Received: from nces01.mj.niksun.com ([10.25.8.17]) by NCES01.mj.niksun.com ([10.25.8.17]) with mapi; Wed, 11 Aug 2010 07:31:39 -0400 From: Andrew Heybey To: Dan Langille Date: Wed, 11 Aug 2010 07:31:37 -0400 Thread-Topic: 8.1-STABLE amd64 machine check Thread-Index: Acs5SMMeubSFbEatSJy/3UYVJ1vHKg== Message-ID: <2531DCEC-527A-4830-8B5B-747294BE8D2C@niksun.com> References: <4C627FB1.5060007@langille.org> In-Reply-To: <4C627FB1.5060007@langille.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Virus-Scanned: clamav-milter 0.95.3 at anuket.mj.niksun.com X-Virus-Status: Clean Cc: "freebsd-hackers@freebsd.org" Subject: Re: 8.1-STABLE amd64 machine check X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 11:31:43 -0000 On Aug 11, 2010, at 6:47 AM, Dan Langille wrote: > I am encountering a situation similar to one reported by Andrew Heybey=20 > at http://docs.freebsd.org/cgi/mid.cgi?6E83197B-9DD5-4C7E-846D-AD176C2546= 4D >=20 > This morning I found this in my /var/log/messages: >=20 > Aug 11 01:59:48 kraken kernel: MCA: Bank 4, Status 0x94614c62001c011b > Aug 11 01:59:48 kraken kernel: MCA: Global Cap 0x0000000000000106,=20 > Status 0x0000000000000000 > Aug 11 01:59:48 kraken kernel: MCA: Vendor "AuthenticAMD", ID 0x100f42,=20 > APIC ID 0 > Aug 11 01:59:48 kraken kernel: MCA: CPU 0 COR GCACHE LG RD error > Aug 11 01:59:48 kraken kernel: MCA: Address 0x5d0fe8c >=20 > Andrew: You posted about this on July 14. Anything new since then? I took jkim's advice and RMAed the CPU to newegg since it was only a week o= ld. No machine checks from the new one yet. andrew From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 11 11:37:59 2010 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6AB3C1065679 for ; Wed, 11 Aug 2010 11:37:59 +0000 (UTC) (envelope-from netch@segfault.kiev.ua) Received: from segfault.kiev.ua (segfault.kiev.ua [193.193.193.4]) by mx1.freebsd.org (Postfix) with ESMTP id CB8EC8FC1D for ; Wed, 11 Aug 2010 11:37:58 +0000 (UTC) Received: from segfault.kiev.ua (localhost.segfault.kiev.ua [127.0.0.1]) by segfault.kiev.ua (8.14.4/8.14.4/8.Who.Cares) with ESMTP id o7BBbvee001151 for ; Wed, 11 Aug 2010 14:37:57 +0300 (EEST) (envelope-from netch@segfault.kiev.ua) Received: (from netch@localhost) by segfault.kiev.ua (8.14.4/8.14.4/Submit) id o7BBbqCq001148 for hackers@freebsd.org; Wed, 11 Aug 2010 14:37:52 +0300 (EEST) (envelope-from netch) Resent-From: netch@netch.kiev.ua Resent-Date: Wed, 11 Aug 2010 14:37:52 +0300 Resent-Message-ID: <20100811113752.GA1075@netch.kiev.ua> Resent-To: hackers@freebsd.org Date: Wed, 11 Aug 2010 14:15:20 +0300 From: Valentin Nechayev To: freebsd-hackers@freebsd.org Message-ID: <20100811111520.GF17926@netch.kiev.ua> References: <20100811060439.GD17926@netch.kiev.ua> <4C624B90.3040101@yandex.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86bp99eccg.fsf@ds4.des.no> X-42: On Cc: Subject: Re: Support for WD Advanced Format disks X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: netch@netch.kiev.ua List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 11:37:59 -0000 >>>>> des@ wrote: > There's a jumper setting for > "Windows XP compatibility", but apparently, it only affects the (fake) > geometry the disk reports to the BIOS. No, this jumper internally increases any linear block number learned from bus request by 1. I.e. the block number 1 without this jumper is seen as block number 0 with this jumper, and so on. So with this jumper, block 63 (internally it is 64) is at begin of physical sector. These data are from my own tests with WD15EARS, see links earlier. I didn't see any difference in fake reported geometry - moreover, with this WD15EARS instance all 512 bytes of identification page were equal with or without jumper. As I already told, it didn't shorten reported size and any tool which tries to read last block (RAID check, GPT reading) had failed with I/O error. I guess this is temporary error and future firmware editions would fix it. -netch- From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 11 11:44:05 2010 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7611F106564A; Wed, 11 Aug 2010 11:44:05 +0000 (UTC) (envelope-from eugen@eg.sd.rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [62.231.161.221]) by mx1.freebsd.org (Postfix) with ESMTP id B36FF8FC24; Wed, 11 Aug 2010 11:44:04 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.4/8.14.4) with ESMTP id o7BBRsbH072044; Wed, 11 Aug 2010 18:27:54 +0700 (NOVST) (envelope-from eugen@eg.sd.rdtc.ru) Received: (from eugen@localhost) by eg.sd.rdtc.ru (8.14.4/8.14.4/Submit) id o7BBRsth072043; Wed, 11 Aug 2010 18:27:54 +0700 (NOVST) (envelope-from eugen) Date: Wed, 11 Aug 2010 18:27:54 +0700 From: Eugene Grosbein To: Valentin Nechayev Message-ID: <20100811112754.GA72031@rdtc.ru> References: <86wrry1hwv.fsf@ds4.des.no> <20100811060439.GD17926@netch.kiev.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100811060439.GD17926@netch.kiev.ua> User-Agent: Mutt/1.4.2.3i Cc: geom@freebsd.org, hackers@freebsd.org Subject: Re: Support for WD Advanced Format disks X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 11:44:05 -0000 On Wed, Aug 11, 2010 at 09:04:39AM +0300, Valentin Nechayev wrote: > > I'm looking into a clean, permanent solution for WD Green drives that > > use 4096-byte physical sectors. To summarize the information I've > > collected so far: > > There is attempt to look from another side - is it really needed? > Captain Obvious says that if one have a new disk, it's easy to format > it properly - i.e. not xxx*16*63 but aligned on 4KB boundary. For > example, set up geometry xxx*64*32 for all new disks and align GPT > partitions on 1MB boundary. As soon as FS requests in FreeBSD are no > less than 4KB in size, this would satisfy any disk. > > If 4KB sectors are our future for a few next years, this shall be > implemented anyway... Also, we have geom_cache for performance-sensetive setups anyway :-) Eugene Grosbein From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 11 11:52:23 2010 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 17039106567C; Wed, 11 Aug 2010 11:52:23 +0000 (UTC) (envelope-from olivier@gid0.org) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 846AC8FC28; Wed, 11 Aug 2010 11:52:22 +0000 (UTC) Received: by eyh6 with SMTP id 6so5019086eyh.13 for ; Wed, 11 Aug 2010 04:52:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.213.75.139 with SMTP id y11mr14931825ebj.99.1281526210012; Wed, 11 Aug 2010 04:30:10 -0700 (PDT) Received: by 10.213.22.146 with HTTP; Wed, 11 Aug 2010 04:30:09 -0700 (PDT) In-Reply-To: <20100811060439.GD17926@netch.kiev.ua> References: <86wrry1hwv.fsf@ds4.des.no> <20100811060439.GD17926@netch.kiev.ua> Date: Wed, 11 Aug 2010 12:30:09 +0100 Message-ID: From: Olivier Smedts To: netch@netch.kiev.ua Content-Type: text/plain; charset=ISO-8859-1 Cc: geom@freebsd.org, hackers@freebsd.org Subject: Re: Support for WD Advanced Format disks X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 11:52:23 -0000 2010/8/11, Valentin Nechayev : >> I'm looking into a clean, permanent solution for WD Green drives that >> use 4096-byte physical sectors. To summarize the information I've >> collected so far: > > There is attempt to look from another side - is it really needed? > Captain Obvious says that if one have a new disk, it's easy to format > it properly - i.e. not xxx*16*63 but aligned on 4KB boundary. For > example, set up geometry xxx*64*32 for all new disks and align GPT > partitions on 1MB boundary. As soon as FS requests in FreeBSD are no > less than 4KB in size, this would satisfy any disk. That would not satisfy ZFS, which uses smaller (than 4KB) chunks for small files. That's a big problem on RAID-Z. > > If 4KB sectors are our future for a few next years, this shall be > implemented anyway... > > > -netch- > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: olivier@gid0.org - against HTML email & vCards X www: http://www.gid0.org - against proprietary attachments / \ "Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas." From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 11 13:07:50 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9BCA41065672; Wed, 11 Aug 2010 13:07:50 +0000 (UTC) (envelope-from dan@langille.org) Received: from nyi.unixathome.org (nyi.unixathome.org [64.147.113.42]) by mx1.freebsd.org (Postfix) with ESMTP id 6CE1F8FC18; Wed, 11 Aug 2010 13:07:49 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by nyi.unixathome.org (Postfix) with ESMTP id E701650BC3; Wed, 11 Aug 2010 14:07:48 +0100 (BST) X-Virus-Scanned: amavisd-new at unixathome.org Received: from nyi.unixathome.org ([127.0.0.1]) by localhost (nyi.unixathome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9moV4WqSepxv; Wed, 11 Aug 2010 14:07:48 +0100 (BST) Received: from nyi.unixathome.org (localhost [127.0.0.1]) by nyi.unixathome.org (Postfix) with ESMTP id 68B4750B88; Wed, 11 Aug 2010 14:07:47 +0100 (BST) Received: from 68.64.144.221 (SquirrelMail authenticated user dan) by nyi.unixathome.org with HTTP; Wed, 11 Aug 2010 09:07:47 -0400 Message-ID: <62ae01455434ddf2961879e814bfe2a8.squirrel@nyi.unixathome.org> In-Reply-To: <2531DCEC-527A-4830-8B5B-747294BE8D2C@niksun.com> References: <4C627FB1.5060007@langille.org> <2531DCEC-527A-4830-8B5B-747294BE8D2C@niksun.com> Date: Wed, 11 Aug 2010 09:07:47 -0400 From: "Dan Langille" To: "Andrew Heybey" User-Agent: SquirrelMail/1.4.20-RC2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: "freebsd-hackers@freebsd.org" , Dan Langille Subject: Re: 8.1-STABLE amd64 machine check X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 13:07:50 -0000 On Wed, August 11, 2010 7:31 am, Andrew Heybey wrote: > On Aug 11, 2010, at 6:47 AM, Dan Langille wrote: > >> I am encountering a situation similar to one reported by Andrew Heybey >> at >> http://docs.freebsd.org/cgi/mid.cgi?6E83197B-9DD5-4C7E-846D-AD176C25464D >> >> This morning I found this in my /var/log/messages: >> >> Aug 11 01:59:48 kraken kernel: MCA: Bank 4, Status 0x94614c62001c011b >> Aug 11 01:59:48 kraken kernel: MCA: Global Cap 0x0000000000000106, >> Status 0x0000000000000000 >> Aug 11 01:59:48 kraken kernel: MCA: Vendor "AuthenticAMD", ID 0x100f42, >> APIC ID 0 >> Aug 11 01:59:48 kraken kernel: MCA: CPU 0 COR GCACHE LG RD error >> Aug 11 01:59:48 kraken kernel: MCA: Address 0x5d0fe8c >> >> Andrew: You posted about this on July 14. Anything new since then? > > I took jkim's advice and RMAed the CPU to newegg since it was only a week > old. No machine checks from the new one yet. Thanks. My CPU is 6 months old, and now out of Newegg's warranty period (Replacement period: 30 days from original invoice date). -- Dan Langille -- http://langille.org/ From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 11 17:38:47 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1182F1065675 for ; Wed, 11 Aug 2010 17:38:47 +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 C06968FC18 for ; Wed, 11 Aug 2010 17:38:46 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 7209F46B64; Wed, 11 Aug 2010 13:38:46 -0400 (EDT) Received: from John-Baldwins-Macbook-Pro.local (75-48-78-116.lightspeed.cncrca.sbcglobal.net [75.48.78.116]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 18D358A03C; Wed, 11 Aug 2010 13:38:44 -0400 (EDT) Message-ID: <4C62E024.2090702@FreeBSD.org> Date: Wed, 11 Aug 2010 13:38:44 -0400 From: John Baldwin User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Dan Langille References: <4C627FB1.5060007@langille.org> In-Reply-To: <4C627FB1.5060007@langille.org> 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 (bigwig.baldwin.cx); Wed, 11 Aug 2010 13:38:45 -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_DYNAMIC autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Andrew Heybey , freebsd-hackers@freebsd.org Subject: Re: 8.1-STABLE amd64 machine check X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 17:38:47 -0000 Dan Langille wrote: > I am encountering a situation similar to one reported by Andrew Heybey > at http://docs.freebsd.org/cgi/mid.cgi?6E83197B-9DD5-4C7E-846D-AD176C25464D > > This morning I found this in my /var/log/messages: > > Aug 11 01:59:48 kraken kernel: MCA: Bank 4, Status 0x94614c62001c011b > Aug 11 01:59:48 kraken kernel: MCA: Global Cap 0x0000000000000106, > Status 0x0000000000000000 > Aug 11 01:59:48 kraken kernel: MCA: Vendor "AuthenticAMD", ID 0x100f42, > APIC ID 0 > Aug 11 01:59:48 kraken kernel: MCA: CPU 0 COR GCACHE LG RD error > Aug 11 01:59:48 kraken kernel: MCA: Address 0x5d0fe8c > > > from /var/run/dmesg.boot > > Copyright (c) 1992-2010 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.1-STABLE #0: Sun Jul 25 19:18:56 EDT 2010 > dan@kraken.example.org:/usr/obj/usr/src/sys/KRAKEN amd64 > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: AMD Phenom(tm) II X4 945 Processor (3010.17-MHz K8-class CPU) > Origin = "AuthenticAMD" Id = 0x100f42 Family = 10 Model = 4 > Stepping = 2 > > Features=0x178bfbff > > Features2=0x802009 > AMD > Features=0xee500800 > AMD > Features2=0x37ff > > TSC: P-state invariant > real memory = 4294967296 (4096 MB) > avail memory = 4100710400 (3910 MB) > ACPI APIC Table: <111909 APIC1708> > FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs > FreeBSD/SMP: 1 package(s) x 4 core(s) > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 > cpu2 (AP): APIC ID: 2 > cpu3 (AP): APIC ID: 3 > > > Andrew: You posted about this on July 14. Anything new since then? > > John: Is it time for me to get a new CPU? Hmm, this is what mcelog says: HARDWARE ERROR. This is *NOT* a software problem! Please contact your hardware vendor CPU 0 4 northbridge ADDR 5d0fe8c Northbridge NB Array Error bit33 = err cpu1 bit42 = L3 subcache in error bit 0 bit43 = L3 subcache in error bit 1 bit46 = corrected ecc error memory/cache error 'generic read mem transaction, generic transaction, level generic' STATUS 94614c62001c011b MCGSTATUS 0 MCGCAP 106 APICID 0 SOCKETID 0 CPUID Vendor AMD Family 16 Model 4 It was a corrected ECC error. If you get more than one then perhaps the CPU is busted, but if you only get one, an isolated bit flip may not be worth worrying about. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 11 18:22:59 2010 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1D5B4106564A for ; Wed, 11 Aug 2010 18:22:59 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from tower.berklix.org (tower.berklix.org [83.236.223.114]) by mx1.freebsd.org (Postfix) with ESMTP id 98E488FC12 for ; Wed, 11 Aug 2010 18:22:57 +0000 (UTC) Received: from park.js.berklix.net (p549A3049.dip.t-dialin.net [84.154.48.73]) (authenticated bits=0) by tower.berklix.org (8.14.2/8.14.2) with ESMTP id o7BIMebF024189; Wed, 11 Aug 2010 18:22:41 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by park.js.berklix.net (8.13.8/8.13.8) with ESMTP id o7BIMhhr052924; Wed, 11 Aug 2010 20:22:44 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.3/8.14.3) with ESMTP id o7BIMM1R053210; Wed, 11 Aug 2010 20:22:27 +0200 (CEST) (envelope-from jhs@fire.js.berklix.net) Message-Id: <201008111822.o7BIMM1R053210@fire.js.berklix.net> To: hackers@freebsd.org From: "Julian H. Stacey" Organization: http://www.berklix.com BSD Unix Linux Consultancy, Munich Germany User-agent: EXMH on FreeBSD http://www.berklix.com/free/ X-URL: http://www.berklix.com In-reply-to: Your message "Wed, 11 Aug 2010 09:32:35 -0000." <4C626E33.6030509@fletchermoorland.co.uk> Date: Wed, 11 Aug 2010 20:22:22 +0200 Sender: jhs@berklix.com Cc: Julian Elischer , Paul Wootton Subject: Re: real memory falsely reports 8G, BIOS & avail memory reports 1G X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 18:22:59 -0000 Ref. http://berklix.com/~jhs/hardware/laptops/novatech-8355/ I wrote > > A laptop here emits a puzzlingly dmesg to both 8.1-RC2 & 8.1-RELEASE: > > real memory = 8572108800 (8175 MB) > > avail memory = 1018789888 (971 MB) > > BIOS reckons it has 1G. No panel to unscrew to inspect memory. > > I don't beleive 8G Thanks to off list responses from Julian Elischer & Paul Wootton :-) dmidecode --type memory # /usr/ports/sysutils/dmidecode/ shows this laptop not returning good output, just # dmidecode 2.10 SMBIOS 2.3 present. Wrong DMI structures count: 43 announced, only 23 decoded. Well, laptop does work, X & audio etc :-) Source for me to look at later: vi -c/reasonable /sys/amd64/amd64/machdep.c Cheers, Julian -- Julian Stacey: BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Mail in plain text, Not HTML, quoted-printable & base 64 dumped with spam. Avoid top posting, It cripples itemised cumulative responses. From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 11 20:31:03 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DB36B106566B; Wed, 11 Aug 2010 20:31:03 +0000 (UTC) (envelope-from Hans-Joerg_Hoexer@genua.de) Received: from gg.genua.de (gg6.genua.de [IPv6:2001:a60:f08e:c000::1]) by mx1.freebsd.org (Postfix) with ESMTP id 0698C8FC1B; Wed, 11 Aug 2010 20:30:59 +0000 (UTC) Received: from gg.genua.de (localhost [127.0.0.1]) by gg.genua.de (8.14.3/8.14.3) with ESMTP id o7BKYYUf023603; Wed, 11 Aug 2010 22:34:34 +0200 (CEST) Received: (from localhost) by gg.genua.de (MSCAN) id 4/gg.genua.de/smtp-gw/mscan; Wed Aug 11 22:34:34 2010 Date: Wed, 11 Aug 2010 22:30:42 +0200 From: Hans-Joerg Hoexer To: Takanori Watanabe Message-ID: <20100811203042.GA26413@modermoor.genua.de> References: <201008040347.o743leeR046013@sana.init-main.com> <201008041039.o74AdfYO047937@sana.init-main.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201008041039.o74AdfYO047937@sana.init-main.com> User-Agent: Mutt/1.5.20 (2009-06-14) X-Mailman-Approved-At: Thu, 12 Aug 2010 01:24:46 +0000 Cc: tss-project@genua.de, freebsd-current@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: Driver tpm(4) and third party packages for trusted platform modules X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 20:31:03 -0000 Hi, On Wed, Aug 04, 2010 at 07:39:41PM +0900, Takanori Watanabe wrote: > Update my patch. Split bus attachment from main driver file > (need to update sys/conf/files), add detach method for convinience, > and attach softc to cdev.si_drv1 . I've updated our diff for 9-current, including your patch. Regards, HJ. diff -Nupr src-9.0-current/sys/dev/tpm/Makefile src/sys/dev/tpm/Makefile --- src-9.0-current/sys/dev/tpm/Makefile 1970-01-01 01:00:00.000000000 +0100 +++ src/sys/dev/tpm/Makefile 2010-08-11 14:11:34.000000000 +0200 @@ -0,0 +1,9 @@ +# $FreeBSD$ + +.PATH: ${.CURDIR}/../../dev/tpm + +KMOD= tpm +SRCS= tpm.c tpm_isa.c tpm_acpi.c isa_if.h opt_acpi.h acpi_if.h \ + bus_if.h device_if.h + +.include diff -Nupr src-9.0-current/sys/dev/tpm/tpm.c src/sys/dev/tpm/tpm.c --- src-9.0-current/sys/dev/tpm/tpm.c 1970-01-01 01:00:00.000000000 +0100 +++ src/sys/dev/tpm/tpm.c 2010-08-11 22:19:10.000000000 +0200 @@ -0,0 +1,1489 @@ +/* + * Copyright (c) 2008, 2009 Michael Shalayeff + * Copyright (c) 2009, 2010 Hans-Joerg Hoexer + * All rights reserved. + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES + * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF + * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR + * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES + * WHATSOEVER RESULTING FROM LOSS OF MIND, USE, DATA OR PROFITS, WHETHER IN + * AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT + * OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. + */ + +/* #define TPM_DEBUG */ + +#include +#include +#include +#include +#include + +#ifdef __FreeBSD__ +#include +#include +#include +#include + +#include +#include +#include + +#include + +#include +#include +#else +#include + +#include +#include +#include +#include + +#include +#include +#endif +#include "tpmvar.h" + +#ifndef __FreeBSD__ +/* XXX horrible hack for tcsd (-lpthread) workaround on OpenBSD */ +#undef PCATCH +#define PCATCH 0 +#endif + +#define TPM_BUFSIZ 1024 + +#define TPM_HDRSIZE 10 + +#define TPM_PARAM_SIZE 0x0001 + +#ifdef __FreeBSD__ +#define IRQUNK -1 +#endif + +#define TPM_ACCESS 0x0000 /* acess register */ +#define TPM_ACCESS_ESTABLISHMENT 0x01 /* establishment */ +#define TPM_ACCESS_REQUEST_USE 0x02 /* request using locality */ +#define TPM_ACCESS_REQUEST_PENDING 0x04 /* pending request */ +#define TPM_ACCESS_SEIZE 0x08 /* request locality seize */ +#define TPM_ACCESS_SEIZED 0x10 /* locality has been seized */ +#define TPM_ACCESS_ACTIVE_LOCALITY 0x20 /* locality is active */ +#define TPM_ACCESS_VALID 0x80 /* bits are valid */ +#define TPM_ACCESS_BITS \ + "\020\01EST\02REQ\03PEND\04SEIZE\05SEIZED\06ACT\010VALID" + +#define TPM_INTERRUPT_ENABLE 0x0008 +#define TPM_GLOBAL_INT_ENABLE 0x80000000 /* enable ints */ +#define TPM_CMD_READY_INT 0x00000080 /* cmd ready enable */ +#define TPM_INT_EDGE_FALLING 0x00000018 +#define TPM_INT_EDGE_RISING 0x00000010 +#define TPM_INT_LEVEL_LOW 0x00000008 +#define TPM_INT_LEVEL_HIGH 0x00000000 +#define TPM_LOCALITY_CHANGE_INT 0x00000004 /* locality change enable */ +#define TPM_STS_VALID_INT 0x00000002 /* int on TPM_STS_VALID is set */ +#define TPM_DATA_AVAIL_INT 0x00000001 /* int on TPM_STS_DATA_AVAIL is set */ +#define TPM_INTERRUPT_ENABLE_BITS \ + "\020\040ENA\010RDY\03LOCH\02STSV\01DRDY" + +#define TPM_INT_VECTOR 0x000c /* 8 bit reg for 4 bit irq vector */ +#define TPM_INT_STATUS 0x0010 /* bits are & 0x87 from TPM_INTERRUPT_ENABLE */ + +#define TPM_INTF_CAPABILITIES 0x0014 /* capability register */ +#define TPM_INTF_BURST_COUNT_STATIC 0x0100 /* TPM_STS_BMASK static */ +#define TPM_INTF_CMD_READY_INT 0x0080 /* int on ready supported */ +#define TPM_INTF_INT_EDGE_FALLING 0x0040 /* falling edge ints supported */ +#define TPM_INTF_INT_EDGE_RISING 0x0020 /* rising edge ints supported */ +#define TPM_INTF_INT_LEVEL_LOW 0x0010 /* level-low ints supported */ +#define TPM_INTF_INT_LEVEL_HIGH 0x0008 /* level-high ints supported */ +#define TPM_INTF_LOCALITY_CHANGE_INT 0x0004 /* locality-change int (mb 1) */ +#define TPM_INTF_STS_VALID_INT 0x0002 /* TPM_STS_VALID int supported */ +#define TPM_INTF_DATA_AVAIL_INT 0x0001 /* TPM_STS_DATA_AVAIL int supported (mb 1) */ +#define TPM_CAPSREQ \ + (TPM_INTF_DATA_AVAIL_INT|TPM_INTF_LOCALITY_CHANGE_INT|TPM_INTF_INT_LEVEL_LOW) +#define TPM_CAPBITS \ + "\020\01IDRDY\02ISTSV\03ILOCH\04IHIGH\05ILOW\06IEDGE\07IFALL\010IRDY\011BCST" + +#define TPM_STS 0x0018 /* status register */ +#define TPM_STS_MASK 0x000000ff /* status bits */ +#define TPM_STS_BMASK 0x00ffff00 /* ro io burst size */ +#define TPM_STS_VALID 0x00000080 /* ro other bits are valid */ +#define TPM_STS_CMD_READY 0x00000040 /* rw chip/signal ready */ +#define TPM_STS_GO 0x00000020 /* wo start the command */ +#define TPM_STS_DATA_AVAIL 0x00000010 /* ro data available */ +#define TPM_STS_DATA_EXPECT 0x00000008 /* ro more data to be written */ +#define TPM_STS_RESP_RETRY 0x00000002 /* wo resend the response */ +#define TPM_STS_BITS "\020\010VALID\07RDY\06GO\05DRDY\04EXPECT\02RETRY" + +#define TPM_DATA 0x0024 +#define TPM_ID 0x0f00 +#define TPM_REV 0x0f04 +#define TPM_SIZE 0x5000 /* five pages of the above */ + +#define TPM_ACCESS_TMO 2000 /* 2sec */ +#define TPM_READY_TMO 2000 /* 2sec */ +#define TPM_READ_TMO 120000 /* 2 minutes */ +#define TPM_BURST_TMO 2000 /* 2sec */ + +#define TPM_LEGACY_BUSY 0x01 +#define TPM_LEGACY_ABRT 0x01 +#define TPM_LEGACY_DA 0x02 +#define TPM_LEGACY_RE 0x04 +#define TPM_LEGACY_LAST 0x04 +#define TPM_LEGACY_BITS "\020\01BUSY\2DA\3RE\4LAST" +#define TPM_LEGACY_TMO (2*60) /* sec */ +#define TPM_LEGACY_SLEEP 5 /* ticks */ +#define TPM_LEGACY_DELAY 100 + +/* Set when enabling legacy interface in host bridge. */ +int tpm_enabled; + + +#ifdef __FreeBSD__ +#define TPMSOFTC(dev) \ + ((struct tpm_softc *)dev->si_drv1) + +d_open_t tpmopen; +d_close_t tpmclose; +d_read_t tpmread; +d_write_t tpmwrite; +d_ioctl_t tpmioctl; + +static struct cdevsw tpm_cdevsw = { + .d_version = D_VERSION, + .d_flags = D_NEEDGIANT, + .d_open = tpmopen, + .d_close = tpmclose, + .d_read = tpmread, + .d_write = tpmwrite, + .d_ioctl = tpmioctl, + .d_name = "tpm", +}; +#else +#define TPMSOFTC(dev) \ + (struct tpm_softc *)device_lookup(&tpm_cd, minor(dev)) + +struct cfdriver tpm_cd = { + NULL, "tpm", DV_DULL +}; + +int tpm_match(struct device *, void *, void *); +void tpm_attach(struct device *, struct device *, void *); + +struct cfattach tpm_ca = { + sizeof(struct tpm_softc), tpm_match, tpm_attach +}; +#endif + +const struct { + u_int32_t devid; + char name[32]; + int flags; +#define TPM_DEV_NOINTS 0x0001 +} tpm_devs[] = { + { 0x000615d1, "IFX SLD 9630 TT 1.1", 0 }, + { 0x000b15d1, "IFX SLB 9635 TT 1.2", 0 }, + { 0x100214e4, "Broadcom BCM0102", TPM_DEV_NOINTS }, + { 0x00fe1050, "WEC WPCT200", 0 }, + { 0x687119fa, "SNS SSX35", 0 }, + { 0x2e4d5453, "STM ST19WP18", 0 }, + { 0x32021114, "ATML 97SC3203", TPM_DEV_NOINTS }, + { 0x10408086, "INTEL INTC0102", 0 }, + { 0, "", TPM_DEV_NOINTS }, +}; + +int tpm_tis12_irqinit(struct tpm_softc *, int, int); +int tpm_tis12_init(struct tpm_softc *, int, const char *); +int tpm_tis12_start(struct tpm_softc *, int); +int tpm_tis12_read(struct tpm_softc *, void *, int, size_t *, int); +int tpm_tis12_write(struct tpm_softc *, void *, int); +int tpm_tis12_end(struct tpm_softc *, int, int); + +#ifdef __FreeBSD__ +void tpm_intr(void *); +#else +int tpm_intr(void *); +void tpm_powerhook(int, void *); +int tpm_suspend(struct tpm_softc *, int); +int tpm_resume(struct tpm_softc *, int); +#endif + +int tpm_waitfor_poll(struct tpm_softc *, u_int8_t, int, void *); +int tpm_waitfor_int(struct tpm_softc *, u_int8_t, int, void *, int); +int tpm_waitfor(struct tpm_softc *, u_int8_t, int, void *); +int tpm_request_locality(struct tpm_softc *, int); +int tpm_getburst(struct tpm_softc *); +u_int8_t tpm_status(struct tpm_softc *); +int tpm_tmotohz(int); + +int tpm_legacy_probe(bus_space_tag_t, bus_addr_t); +int tpm_legacy_init(struct tpm_softc *, int, const char *); +int tpm_legacy_start(struct tpm_softc *, int); +int tpm_legacy_read(struct tpm_softc *, void *, int, size_t *, int); +int tpm_legacy_write(struct tpm_softc *, void *, int); +int tpm_legacy_end(struct tpm_softc *, int, int); + +#ifdef __FreeBSD__ + +/* + * FreeBSD specific code for probing and attaching TPM to device tree. + */ +#if 0 +static void +tpm_identify(driver_t *driver, device_t parent) +{ + BUS_ADD_CHILD(parent, ISA_ORDER_SPECULATIVE, "tpm", 0); +} +#endif + + +int +tpm_attach(device_t dev) +{ + struct tpm_softc *sc = device_get_softc(dev); + int irq; + + sc->mem_rid = 0; + sc->mem_res = bus_alloc_resource_any(dev, SYS_RES_MEMORY, &sc->mem_rid, + RF_ACTIVE); + if (sc->mem_res == NULL) + return ENXIO; + + sc->sc_bt = rman_get_bustag(sc->mem_res); + sc->sc_bh = rman_get_bushandle(sc->mem_res); + + sc->irq_rid = 0; + sc->irq_res = bus_alloc_resource_any(dev, SYS_RES_IRQ, &sc->irq_rid, + RF_ACTIVE | RF_SHAREABLE); + if (sc->irq_res != NULL) + irq = rman_get_start(sc->irq_res); + else + irq = IRQUNK; + + /* In case PnP probe this may contain some initialization. */ + tpm_tis12_probe(sc->sc_bt, sc->sc_bh); + + if (tpm_legacy_probe(sc->sc_bt, sc->sc_bh)) { + sc->sc_init = tpm_legacy_init; + sc->sc_start = tpm_legacy_start; + sc->sc_read = tpm_legacy_read; + sc->sc_write = tpm_legacy_write; + sc->sc_end = tpm_legacy_end; + } else { + sc->sc_init = tpm_tis12_init; + sc->sc_start = tpm_tis12_start; + sc->sc_read = tpm_tis12_read; + sc->sc_write = tpm_tis12_write; + sc->sc_end = tpm_tis12_end; + } + + printf("%s", device_get_name(dev)); + if ((sc->sc_init)(sc, irq, "tpm")) { + tpm_detach(dev); + return ENXIO; + } + + if (sc->sc_init == tpm_tis12_init && sc->irq_res != NULL && + bus_setup_intr(dev, sc->irq_res, INTR_TYPE_TTY, NULL, + tpm_intr, sc, &sc->intr_cookie) != 0) { + tpm_detach(dev); + printf(": cannot establish interrupt\n"); + return 1; + } + + sc->sc_cdev = make_dev(&tpm_cdevsw, device_get_unit(dev), + UID_ROOT, GID_WHEEL, 0600, "tpm"); + sc->sc_cdev->si_drv1 = sc; + + return 0; +} + +int +tpm_detach(device_t dev) +{ + struct tpm_softc * sc = device_get_softc(dev); + + if(sc->intr_cookie){ + bus_teardown_intr(dev, sc->irq_res, sc->intr_cookie); + } + + if(sc->mem_res){ + bus_release_resource(dev, SYS_RES_MEMORY, + sc->mem_rid, sc->mem_res); + } + + if(sc->irq_res){ + bus_release_resource(dev, SYS_RES_IRQ, + sc->irq_rid, sc->irq_res); + } + if(sc->sc_cdev){ + destroy_dev(sc->sc_cdev); + } + + return 0; +} + + +#else +/* + * OpenBSD specific code for probing and attaching TPM to device tree. + */ +int +tpm_match(struct device *parent, void *match, void *aux) +{ + struct isa_attach_args *ia = aux; + struct cfdata *cf = match; + bus_space_tag_t bt = ia->ia_memt; + bus_space_handle_t bh; + int rv; + + /* There can be only one. */ + if (cf->cf_unit) + return 0; + + if (tpm_legacy_probe(ia->ia_iot, ia->ia_iobase)) { + ia->ia_iosize = 2; + return 1; + } + + if (ia->ia_maddr == -1) + return 0; + + if (bus_space_map(bt, ia->ia_maddr, TPM_SIZE, 0, &bh)) + return 0; + + if ((rv = tpm_tis12_probe(bt, bh))) { + ia->ia_iosize = 0; + ia->ia_msize = TPM_SIZE; + } + + bus_space_unmap(bt, bh, TPM_SIZE); + return rv; +} + +void +tpm_attach(struct device *parent, struct device *self, void *aux) +{ + struct tpm_softc *sc = (struct tpm_softc *)self; + struct isa_attach_args *ia = aux; + bus_addr_t iobase; + bus_size_t size; + int rv; + + if (tpm_legacy_probe(ia->ia_iot, ia->ia_iobase)) { + sc->sc_bt = ia->ia_iot; + iobase = ia->ia_iobase; + size = ia->ia_iosize; + sc->sc_batm = ia->ia_iot; + sc->sc_init = tpm_legacy_init; + sc->sc_start = tpm_legacy_start; + sc->sc_read = tpm_legacy_read; + sc->sc_write = tpm_legacy_write; + sc->sc_end = tpm_legacy_end; + } else { + sc->sc_bt = ia->ia_memt; + iobase = ia->ia_maddr; + size = TPM_SIZE; + sc->sc_init = tpm_tis12_init; + sc->sc_start = tpm_tis12_start; + sc->sc_read = tpm_tis12_read; + sc->sc_write = tpm_tis12_write; + sc->sc_end = tpm_tis12_end; + } + + if (bus_space_map(sc->sc_bt, iobase, size, 0, &sc->sc_bh)) { + printf(": cannot map registers\n"); + return; + } + + if ((rv = (sc->sc_init)(sc, ia->ia_irq, sc->sc_dev.dv_xname))) { + bus_space_unmap(sc->sc_bt, sc->sc_bh, size); + return; + } + + /* + * Only setup interrupt handler when we have a vector and the + * chip is TIS 1.2 compliant. + */ + if (sc->sc_init == tpm_tis12_init && ia->ia_irq != IRQUNK && + (sc->sc_ih = isa_intr_establish(ia->ia_ic, ia->ia_irq, IST_EDGE, + IPL_TTY, tpm_intr, sc, sc->sc_dev.dv_xname)) == NULL) { + bus_space_unmap(sc->sc_bt, sc->sc_bh, TPM_SIZE); + printf("%s: cannot establish interrupt\n", + sc->sc_dev.dv_xname); + return; + } + +#ifdef __FreeBSD__ + sc->sc_suspend = 0; +#else + sc->sc_suspend = PWR_RESUME; + sc->sc_powerhook = powerhook_establish(tpm_powerhook, sc); +#endif +} +#endif + +/* Probe TPM using TIS 1.2 interface. */ +int +tpm_tis12_probe(bus_space_tag_t bt, bus_space_handle_t bh) +{ + u_int32_t r; + u_int8_t save, reg; + + r = bus_space_read_4(bt, bh, TPM_INTF_CAPABILITIES); + if (r == 0xffffffff) + return 0; + +#ifdef TPM_DEBUG + printf("tpm: caps=%b\n", r, TPM_CAPBITS); +#endif + if ((r & TPM_CAPSREQ) != TPM_CAPSREQ || + !(r & (TPM_INTF_INT_EDGE_RISING | TPM_INTF_INT_LEVEL_LOW))) { +#ifdef TPM_DEBUG + printf("tpm: caps too low (caps=%b)\n", r, TPM_CAPBITS); +#endif + return 0; + } + + save = bus_space_read_1(bt, bh, TPM_ACCESS); + bus_space_write_1(bt, bh, TPM_ACCESS, TPM_ACCESS_REQUEST_USE); + reg = bus_space_read_1(bt, bh, TPM_ACCESS); + if ((reg & TPM_ACCESS_VALID) && (reg & TPM_ACCESS_ACTIVE_LOCALITY) && + bus_space_read_4(bt, bh, TPM_ID) != 0xffffffff) + return 1; + + bus_space_write_1(bt, bh, TPM_ACCESS, save); + return 0; +} + +/* + * Setup interrupt vector if one is provided and interrupts are know to + * work on that particular chip. + */ +int +tpm_tis12_irqinit(struct tpm_softc *sc, int irq, int idx) +{ + u_int32_t r; + + if ((irq == IRQUNK) || (tpm_devs[idx].flags & TPM_DEV_NOINTS)) { + sc->sc_vector = IRQUNK; + return 0; + } + + /* Ack and disable all interrupts. */ + bus_space_write_4(sc->sc_bt, sc->sc_bh, TPM_INTERRUPT_ENABLE, + bus_space_read_4(sc->sc_bt, sc->sc_bh, TPM_INTERRUPT_ENABLE) & + ~TPM_GLOBAL_INT_ENABLE); + bus_space_write_4(sc->sc_bt, sc->sc_bh, TPM_INT_STATUS, + bus_space_read_4(sc->sc_bt, sc->sc_bh, TPM_INT_STATUS)); + + /* Program interrupt vector. */ + bus_space_write_1(sc->sc_bt, sc->sc_bh, TPM_INT_VECTOR, irq); + sc->sc_vector = irq; + + /* Program interrupt type. */ + if (sc->sc_capabilities & TPM_INTF_INT_EDGE_RISING) + r = TPM_INT_EDGE_RISING; + else if (sc->sc_capabilities & TPM_INTF_INT_LEVEL_HIGH) + r = TPM_INT_LEVEL_HIGH; + else + r = TPM_INT_LEVEL_LOW; + bus_space_write_4(sc->sc_bt, sc->sc_bh, TPM_INTERRUPT_ENABLE, r); + + return 0; +} + +/* Setup TPM using TIS 1.2 interface. */ +int +tpm_tis12_init(struct tpm_softc *sc, int irq, const char *name) +{ + u_int32_t r; + int i; + + r = bus_space_read_4(sc->sc_bt, sc->sc_bh, TPM_INTF_CAPABILITIES); +#ifdef TPM_DEBUG + printf(" caps=%b ", r, TPM_CAPBITS); +#endif + if ((r & TPM_CAPSREQ) != TPM_CAPSREQ || + !(r & (TPM_INTF_INT_EDGE_RISING | TPM_INTF_INT_LEVEL_LOW))) { + printf(": capabilities too low (caps=%b)\n", r, TPM_CAPBITS); + return 1; + } + sc->sc_capabilities = r; + + sc->sc_devid = bus_space_read_4(sc->sc_bt, sc->sc_bh, TPM_ID); + sc->sc_rev = bus_space_read_1(sc->sc_bt, sc->sc_bh, TPM_REV); + + for (i = 0; tpm_devs[i].devid; i++) + if (tpm_devs[i].devid == sc->sc_devid) + break; + + if (tpm_devs[i].devid) + printf(": %s rev 0x%x\n", tpm_devs[i].name, sc->sc_rev); + else + printf(": device 0x%08x rev 0x%x\n", sc->sc_devid, sc->sc_rev); + + if (tpm_tis12_irqinit(sc, irq, i)) + return 1; + + if (tpm_request_locality(sc, 0)) + return 1; + + /* Abort whatever it thought it was doing. */ + bus_space_write_1(sc->sc_bt, sc->sc_bh, TPM_STS, TPM_STS_CMD_READY); + + return 0; +} + +int +tpm_request_locality(struct tpm_softc *sc, int l) +{ + u_int32_t r; + int to, rv; + + if (l != 0) + return EINVAL; + + if ((bus_space_read_1(sc->sc_bt, sc->sc_bh, TPM_ACCESS) & + (TPM_ACCESS_VALID | TPM_ACCESS_ACTIVE_LOCALITY)) == + (TPM_ACCESS_VALID | TPM_ACCESS_ACTIVE_LOCALITY)) + return 0; + + bus_space_write_1(sc->sc_bt, sc->sc_bh, TPM_ACCESS, + TPM_ACCESS_REQUEST_USE); + + to = tpm_tmotohz(TPM_ACCESS_TMO); + + while ((r = bus_space_read_1(sc->sc_bt, sc->sc_bh, TPM_ACCESS) & + (TPM_ACCESS_VALID | TPM_ACCESS_ACTIVE_LOCALITY)) != + (TPM_ACCESS_VALID | TPM_ACCESS_ACTIVE_LOCALITY) && to--) { + rv = tsleep(sc->sc_init, PRIBIO | PCATCH, "tpm_locality", 1); + if (rv && rv != EWOULDBLOCK) { +#ifdef TPM_DEBUG + printf("tpm_request_locality: interrupted %d\n", rv); +#endif + return rv; + } + } + + if ((r & (TPM_ACCESS_VALID | TPM_ACCESS_ACTIVE_LOCALITY)) != + (TPM_ACCESS_VALID | TPM_ACCESS_ACTIVE_LOCALITY)) { +#ifdef TPM_DEBUG + printf("tpm_request_locality: access %b\n", r, TPM_ACCESS_BITS); +#endif + return EBUSY; + } + + return 0; +} + +int +tpm_getburst(struct tpm_softc *sc) +{ + int burst, to, rv; + + to = tpm_tmotohz(TPM_BURST_TMO); + + burst = 0; + while (burst == 0 && to--) { + /* + * Burst count has to be read from bits 8 to 23 without + * touching any other bits, eg. the actual status bits 0 + * to 7. + */ + burst = bus_space_read_1(sc->sc_bt, sc->sc_bh, TPM_STS + 1); + burst |= bus_space_read_1(sc->sc_bt, sc->sc_bh, TPM_STS + 2) + << 8; +#ifdef TPM_DEBUG + printf("tpm_getburst: read %d\n", burst); +#endif + if (burst) + return burst; + + rv = tsleep(sc, PRIBIO | PCATCH, "tpm_getburst", 1); + if (rv && rv != EWOULDBLOCK) { + return 0; + } + } + + return 0; +} + +u_int8_t +tpm_status(struct tpm_softc *sc) +{ + u_int8_t status; + + status = bus_space_read_1(sc->sc_bt, sc->sc_bh, TPM_STS) & + TPM_STS_MASK; + + return status; +} + +int +tpm_tmotohz(int tmo) +{ + struct timeval tv; + + tv.tv_sec = tmo / 1000; + tv.tv_usec = 1000 * (tmo % 1000); + + return tvtohz(&tv); +} + +/* Save TPM state on suspend. */ +int +#ifdef __FreeBSD__ +tpm_suspend(device_t dev) +#else +tpm_suspend(struct tpm_softc *sc, int why) +#endif +{ +#ifdef __FreeBSD__ + struct tpm_softc *sc = device_get_softc(dev); + int why = 1; +#endif + u_int8_t command[] = { + 0, 193, /* TPM_TAG_RQU_COMMAND */ + 0, 0, 0, 10, /* Length in bytes */ + 0, 0, 0, 156 /* TPM_ORD_SaveStates */ + }; + + /* + * Power down: We have to issue the SaveStates command. + */ + sc->sc_write(sc, &command, sizeof(command)); + sc->sc_read(sc, &command, sizeof(command), NULL, TPM_HDRSIZE); +#ifdef TPM_DEBUG + printf("tpm_suspend: power down: %d -> %d\n", sc->sc_suspend, why); +#endif + sc->sc_suspend = why; + + return 0; +} + +/* + * Handle resume event. Actually nothing to do as the BIOS is supposed + * to restore the previously saved state. + */ +int +#ifdef __FreeBSD__ +tpm_resume(device_t dev) +#else +tpm_resume(struct tpm_softc *sc, int why) +#endif +{ +#ifdef __FreeBSD__ + struct tpm_softc *sc = device_get_softc(dev); + int why = 0; +#endif +#ifdef TPM_DEBUG + printf("tpm_resume: resume: %d -> %d\n", sc->sc_suspend, why); +#endif + sc->sc_suspend = why; + + return 0; +} + +/* Dispatch suspend and resume events. */ +#ifndef __FreeBSD__ +void +tpm_powerhook(int why, void *self) +{ + struct tpm_softc *sc = (struct tpm_softc *)self; + + if (why != PWR_RESUME) + tpm_suspend(sc, why); + else + tpm_resume(sc, why); +} +#endif /* !__FreeBSD__ */ + +/* Wait for given status bits using polling. */ +int +tpm_waitfor_poll(struct tpm_softc *sc, u_int8_t mask, int tmo, void *c) +{ + int rv; + + /* + * Poll until either the requested condition or a time out is + * met. + */ + while (((sc->sc_stat = tpm_status(sc)) & mask) != mask && tmo--) { + rv = tsleep(c, PRIBIO | PCATCH, "tpm_poll", 1); + if (rv && rv != EWOULDBLOCK) { +#ifdef TPM_DEBUG + printf("tpm_waitfor_poll: interrupted %d\n", rv); +#endif + return rv; + } + } + + return 0; +} + +/* Wait for given status bits using interrupts. */ +int +tpm_waitfor_int(struct tpm_softc *sc, u_int8_t mask, int tmo, void *c, + int inttype) +{ + int rv, to; + + /* Poll and return when condition is already met. */ + sc->sc_stat = tpm_status(sc); + if ((sc->sc_stat & mask) == mask) + return 0; + + /* + * Enable interrupt on tpm chip. Note that interrupts on our + * level (SPL_TTY) are disabled (see tpm{read,write} et al) and + * will not be delivered to the cpu until we call tsleep(9) below. + */ + bus_space_write_4(sc->sc_bt, sc->sc_bh, TPM_INTERRUPT_ENABLE, + bus_space_read_4(sc->sc_bt, sc->sc_bh, TPM_INTERRUPT_ENABLE) | + inttype); + bus_space_write_4(sc->sc_bt, sc->sc_bh, TPM_INTERRUPT_ENABLE, + bus_space_read_4(sc->sc_bt, sc->sc_bh, TPM_INTERRUPT_ENABLE) | + TPM_GLOBAL_INT_ENABLE); + + /* + * Poll once more to remedy the race between previous polling + * and enabling interrupts on the tpm chip. + */ + sc->sc_stat = tpm_status(sc); + if ((sc->sc_stat & mask) == mask) { + rv = 0; + goto out; + } + + to = tpm_tmotohz(tmo); +#ifdef TPM_DEBUG + printf("tpm_waitfor_int: sleeping for %d ticks on %p\n", to, c); +#endif + /* + * tsleep(9) enables interrupts on the cpu and returns after + * wake up with interrupts disabled again. Note that interrupts + * generated by the tpm chip while being at SPL_TTY are not lost + * but held and delivered as soon as the cpu goes below SPL_TTY. + */ + rv = tsleep(c, PRIBIO | PCATCH, "tpm_intr", to); + + sc->sc_stat = tpm_status(sc); +#ifdef TPM_DEBUG + printf("tpm_waitfor_int: woke up with rv %d stat %b\n", rv, + sc->sc_stat, TPM_STS_BITS); +#endif + if ((sc->sc_stat & mask) == mask) + rv = 0; + + /* Disable interrupts on tpm chip again. */ +out: bus_space_write_4(sc->sc_bt, sc->sc_bh, TPM_INTERRUPT_ENABLE, + bus_space_read_4(sc->sc_bt, sc->sc_bh, TPM_INTERRUPT_ENABLE) & + ~TPM_GLOBAL_INT_ENABLE); + bus_space_write_4(sc->sc_bt, sc->sc_bh, TPM_INTERRUPT_ENABLE, + bus_space_read_4(sc->sc_bt, sc->sc_bh, TPM_INTERRUPT_ENABLE) & + ~inttype); + + return rv; +} + +/* + * Wait on given status bits, uses interrupts where possible, otherwise polls. + */ +int +tpm_waitfor(struct tpm_softc *sc, u_int8_t b0, int tmo, void *c) +{ + u_int8_t b; + int re, to, rv; + +#ifdef TPM_DEBUG + printf("tpm_waitfor: b0 %b\n", b0, TPM_STS_BITS); +#endif + + /* + * If possible, use interrupts, otherwise poll. + * + * We use interrupts for TPM_STS_VALID and TPM_STS_DATA_AVAIL (if + * the tpm chips supports them) as waiting for those can take + * really long. The other TPM_STS* are not needed very often + * so we do not support them. + */ + if (sc->sc_vector != IRQUNK) { + b = b0; + + /* + * Wait for data ready. This interrupt only occures + * when both TPM_STS_VALID and TPM_STS_DATA_AVAIL are asserted. + * Thus we don't have to bother with TPM_STS_VALID + * separately and can just return. + * + * This only holds for interrupts! When using polling + * both flags have to be waited for, see below. + */ + if ((b & TPM_STS_DATA_AVAIL) && (sc->sc_capabilities & + TPM_INTF_DATA_AVAIL_INT)) + return tpm_waitfor_int(sc, b, tmo, c, + TPM_DATA_AVAIL_INT); + + /* Wait for status valid bit. */ + if ((b & TPM_STS_VALID) && (sc->sc_capabilities & + TPM_INTF_STS_VALID_INT)) { + rv = tpm_waitfor_int(sc, b, tmo, c, TPM_STS_VALID_INT); + if (rv != 0) + return rv; + else + b = b0 & ~TPM_STS_VALID; + } + + /* + * When all flags are taken care of, return. Otherwise + * use polling for eg. TPM_STS_CMD_READY. + */ + if (b == 0) + return 0; + } + + re = 3; +restart: + /* + * If requested wait for TPM_STS_VALID before dealing with + * any other flag. Eg. when both TPM_STS_DATA_AVAIL and TPM_STS_VALID + * are requested, wait for the latter first. + */ + b = b0; + if (b0 & TPM_STS_VALID) + b = TPM_STS_VALID; + + to = tpm_tmotohz(tmo); +again: + if ((rv = tpm_waitfor_poll(sc, b, to, c)) != 0) + return rv; + + if ((b & sc->sc_stat) == TPM_STS_VALID) { + /* Now wait for other flags. */ + b = b0 & ~TPM_STS_VALID; + to++; + goto again; + } + + if ((sc->sc_stat & b) != b) { +#ifdef TPM_DEBUG + printf("tpm_waitfor: timeout: stat=%b b=%b\n", + sc->sc_stat, TPM_STS_BITS, b, TPM_STS_BITS); +#endif + if (re-- && (b0 & TPM_STS_VALID)) { + bus_space_write_1(sc->sc_bt, sc->sc_bh, TPM_STS, + TPM_STS_RESP_RETRY); + goto restart; + } + return EIO; + } + + return 0; +} + +/* Start transaction. */ +int +tpm_tis12_start(struct tpm_softc *sc, int flag) +{ + int rv; + + if (flag == UIO_READ) { + rv = tpm_waitfor(sc, TPM_STS_DATA_AVAIL | TPM_STS_VALID, + TPM_READ_TMO, sc->sc_read); + return rv; + } + + /* Own our (0th) locality. */ + if ((rv = tpm_request_locality(sc, 0)) != 0) + return rv; + + sc->sc_stat = tpm_status(sc); + if (sc->sc_stat & TPM_STS_CMD_READY) { +#ifdef TPM_DEBUG + printf("tpm_tis12_start: UIO_WRITE status %b\n", sc->sc_stat, + TPM_STS_BITS); +#endif + return 0; + } + +#ifdef TPM_DEBUG + printf("tpm_tis12_start: UIO_WRITE readying chip\n"); +#endif + + /* Abort previous and restart. */ + bus_space_write_1(sc->sc_bt, sc->sc_bh, TPM_STS, TPM_STS_CMD_READY); + if ((rv = tpm_waitfor(sc, TPM_STS_CMD_READY, TPM_READY_TMO, + sc->sc_write))) { +#ifdef TPM_DEBUG + printf("tpm_tis12_start: UIO_WRITE readying failed %d\n", rv); +#endif + return rv; + } + +#ifdef TPM_DEBUG + printf("tpm_tis12_start: UIO_WRITE readying done\n"); +#endif + + return 0; +} + +int +tpm_tis12_read(struct tpm_softc *sc, void *buf, int len, size_t *count, + int flags) +{ + u_int8_t *p = buf; + size_t cnt; + int rv, n, bcnt; + +#ifdef TPM_DEBUG + printf("tpm_tis12_read: len %d\n", len); +#endif + cnt = 0; + while (len > 0) { + if ((rv = tpm_waitfor(sc, TPM_STS_DATA_AVAIL | TPM_STS_VALID, + TPM_READ_TMO, sc->sc_read))) + return rv; + + bcnt = tpm_getburst(sc); + n = MIN(len, bcnt); +#ifdef TPM_DEBUG + printf("tpm_tis12_read: fetching %d, burst is %d\n", n, bcnt); +#endif + for (; n--; len--) { + *p++ = bus_space_read_1(sc->sc_bt, sc->sc_bh, TPM_DATA); + cnt++; + } + + if ((flags & TPM_PARAM_SIZE) == 0 && cnt >= 6) + break; + } +#ifdef TPM_DEBUG + printf("tpm_tis12_read: read %zd bytes, len %d\n", cnt, len); +#endif + + if (count) + *count = cnt; + + return 0; +} + +int +tpm_tis12_write(struct tpm_softc *sc, void *buf, int len) +{ + u_int8_t *p = buf; + size_t cnt; + int rv, r; + +#ifdef TPM_DEBUG + printf("tpm_tis12_write: sc %p buf %p len %d\n", sc, buf, len); +#endif + + if ((rv = tpm_request_locality(sc, 0)) != 0) + return rv; + + cnt = 0; + while (cnt < len - 1) { + for (r = tpm_getburst(sc); r > 0 && cnt < len - 1; r--) { + bus_space_write_1(sc->sc_bt, sc->sc_bh, TPM_DATA, *p++); + cnt++; + } + if ((rv = tpm_waitfor(sc, TPM_STS_VALID, TPM_READ_TMO, sc))) { +#ifdef TPM_DEBUG + printf("tpm_tis12_write: failed burst rv %d\n", rv); +#endif + return rv; + } + sc->sc_stat = tpm_status(sc); + if (!(sc->sc_stat & TPM_STS_DATA_EXPECT)) { +#ifdef TPM_DEBUG + printf("tpm_tis12_write: failed rv %d stat=%b\n", rv, + sc->sc_stat, TPM_STS_BITS); +#endif + return EIO; + } + } + + bus_space_write_1(sc->sc_bt, sc->sc_bh, TPM_DATA, *p++); + cnt++; + + if ((rv = tpm_waitfor(sc, TPM_STS_VALID, TPM_READ_TMO, sc))) { +#ifdef TPM_DEBUG + printf("tpm_tis12_write: failed last byte rv %d\n", rv); +#endif + return rv; + } + if ((sc->sc_stat & TPM_STS_DATA_EXPECT) != 0) { +#ifdef TPM_DEBUG + printf("tpm_tis12_write: failed rv %d stat=%b\n", rv, + sc->sc_stat, TPM_STS_BITS); +#endif + return EIO; + } + +#ifdef TPM_DEBUG + printf("tpm_tis12_write: wrote %d byte\n", cnt); +#endif + + return 0; +} + +/* Finish transaction. */ +int +tpm_tis12_end(struct tpm_softc *sc, int flag, int err) +{ + int rv = 0; + + if (flag == UIO_READ) { + if ((rv = tpm_waitfor(sc, TPM_STS_VALID, TPM_READ_TMO, + sc->sc_read))) + return rv; + + /* Still more data? */ + sc->sc_stat = tpm_status(sc); + if (!err && ((sc->sc_stat & TPM_STS_DATA_AVAIL) == TPM_STS_DATA_AVAIL)) { +#ifdef TPM_DEBUG + printf("tpm_tis12_end: read failed stat=%b\n", + sc->sc_stat, TPM_STS_BITS); +#endif + rv = EIO; + } + + bus_space_write_1(sc->sc_bt, sc->sc_bh, TPM_STS, + TPM_STS_CMD_READY); + + /* Release our (0th) locality. */ + bus_space_write_1(sc->sc_bt, sc->sc_bh,TPM_ACCESS, + TPM_ACCESS_ACTIVE_LOCALITY); + } else { + /* Hungry for more? */ + sc->sc_stat = tpm_status(sc); + if (!err && (sc->sc_stat & TPM_STS_DATA_EXPECT)) { +#ifdef TPM_DEBUG + printf("tpm_tis12_end: write failed stat=%b\n", + sc->sc_stat, TPM_STS_BITS); +#endif + rv = EIO; + } + + bus_space_write_1(sc->sc_bt, sc->sc_bh, TPM_STS, + err ? TPM_STS_CMD_READY : TPM_STS_GO); + } + + return rv; +} + +#ifdef __FreeBSD__ +void +#else +int +#endif +tpm_intr(void *v) +{ + struct tpm_softc *sc = v; + u_int32_t r; +#ifdef TPM_DEBUG + static int cnt = 0; +#endif + + r = bus_space_read_4(sc->sc_bt, sc->sc_bh, TPM_INT_STATUS); +#ifdef TPM_DEBUG + if (r != 0) + printf("tpm_intr: int=%b (%d)\n", r, TPM_INTERRUPT_ENABLE_BITS, + cnt); + else + cnt++; +#endif + if (!(r & (TPM_CMD_READY_INT | TPM_LOCALITY_CHANGE_INT | + TPM_STS_VALID_INT | TPM_DATA_AVAIL_INT))) +#ifdef __FreeBSD__ + return; +#else + return 0; +#endif + if (r & TPM_STS_VALID_INT) + wakeup(sc); + + if (r & TPM_CMD_READY_INT) + wakeup(sc->sc_write); + + if (r & TPM_DATA_AVAIL_INT) + wakeup(sc->sc_read); + + if (r & TPM_LOCALITY_CHANGE_INT) + wakeup(sc->sc_init); + + bus_space_write_4(sc->sc_bt, sc->sc_bh, TPM_INT_STATUS, r); + +#ifdef __FreeBSD__ + return; +#else + return 1; +#endif +} + +/* Read single byte using legacy interface. */ +static inline u_int8_t +tpm_legacy_in(bus_space_tag_t iot, bus_space_handle_t ioh, int reg) +{ + bus_space_write_1(iot, ioh, 0, reg); + return bus_space_read_1(iot, ioh, 1); +} + +/* Write single byte using legacy interface. */ +static inline void +tpm_legacy_out(bus_space_tag_t iot, bus_space_handle_t ioh, int reg, u_int8_t v) +{ + bus_space_write_1(iot, ioh, 0, reg); + bus_space_write_1(iot, ioh, 1, v); +} + +/* Probe for TPM using legacy interface. */ +int +tpm_legacy_probe(bus_space_tag_t iot, bus_addr_t iobase) +{ + bus_space_handle_t ioh; + u_int8_t r, v; + int i, rv = 0; + char id[8]; + + if (!tpm_enabled || iobase == -1) + return 0; + + if (bus_space_map(iot, iobase, 2, 0, &ioh)) + return 0; + + v = bus_space_read_1(iot, ioh, 0); + if (v == 0xff) { + bus_space_unmap(iot, ioh, 2); + return 0; + } + r = bus_space_read_1(iot, ioh, 1); + + for (i = sizeof(id); i--; ) + id[i] = tpm_legacy_in(iot, ioh, TPM_ID + i); + +#ifdef TPM_DEBUG + printf("tpm_legacy_probe %.4s %d.%d.%d.%d\n", + &id[4], id[0], id[1], id[2], id[3]); +#endif + /* + * The only chips using the legacy interface we are aware of are + * by Atmel. For other chips more signature would have to be added. + */ + if (!bcmp(&id[4], "ATML", 4)) + rv = 1; + + if (!rv) { + bus_space_write_1(iot, ioh, r, 1); + bus_space_write_1(iot, ioh, v, 0); + } + bus_space_unmap(iot, ioh, 2); + + return rv; +} + +/* Setup TPM using legacy interface. */ +int +tpm_legacy_init(struct tpm_softc *sc, int irq, const char *name) +{ + char id[8]; + u_int8_t ioh, iol; + int i; + + if ((i = bus_space_map(sc->sc_batm, tpm_enabled, 2, 0, &sc->sc_bahm))) { + printf(": cannot map tpm registers (%d)\n", i); + tpm_enabled = 0; + return 1; + } + + for (i = sizeof(id); i--; ) + id[i] = tpm_legacy_in(sc->sc_bt, sc->sc_bh, TPM_ID + i); + + printf(": %.4s %d.%d @0x%x\n", &id[4], id[0], id[1], tpm_enabled); + iol = tpm_enabled & 0xff; + ioh = tpm_enabled >> 16; + tpm_enabled = 0; + + return 0; +} + +/* Start transaction. */ +int +tpm_legacy_start(struct tpm_softc *sc, int flag) +{ + struct timeval tv; + u_int8_t bits, r; + int to, rv; + + bits = flag == UIO_READ ? TPM_LEGACY_DA : 0; + tv.tv_sec = TPM_LEGACY_TMO; + tv.tv_usec = 0; + to = tvtohz(&tv) / TPM_LEGACY_SLEEP; + while (((r = bus_space_read_1(sc->sc_batm, sc->sc_bahm, 1)) & + (TPM_LEGACY_BUSY|bits)) != bits && to--) { + rv = tsleep(sc, PRIBIO | PCATCH, "legacy_tpm_start", + TPM_LEGACY_SLEEP); + if (rv && rv != EWOULDBLOCK) + return rv; + } + +#if defined(TPM_DEBUG) && !defined(__FreeBSD__) + printf("%s: bits %b\n", sc->sc_dev.dv_xname, r, TPM_LEGACY_BITS); +#endif + if ((r & (TPM_LEGACY_BUSY|bits)) != bits) + return EIO; + + return 0; +} + +int +tpm_legacy_read(struct tpm_softc *sc, void *buf, int len, size_t *count, + int flags) +{ + u_int8_t *p; + size_t cnt; + int to, rv; + + cnt = rv = 0; + for (p = buf; !rv && len > 0; len--) { + for (to = 1000; + !(bus_space_read_1(sc->sc_batm, sc->sc_bahm, 1) & + TPM_LEGACY_DA); DELAY(1)) + if (!to--) + return EIO; + + DELAY(TPM_LEGACY_DELAY); + *p++ = bus_space_read_1(sc->sc_batm, sc->sc_bahm, 0); + cnt++; + } + + *count = cnt; + return 0; +} + +int +tpm_legacy_write(struct tpm_softc *sc, void *buf, int len) +{ + u_int8_t *p; + int n; + + for (p = buf, n = len; n--; DELAY(TPM_LEGACY_DELAY)) { + if (!n && len != TPM_BUFSIZ) { + bus_space_write_1(sc->sc_batm, sc->sc_bahm, 1, + TPM_LEGACY_LAST); + DELAY(TPM_LEGACY_DELAY); + } + bus_space_write_1(sc->sc_batm, sc->sc_bahm, 0, *p++); + } + + return 0; +} + +/* Finish transaction. */ +int +tpm_legacy_end(struct tpm_softc *sc, int flag, int rv) +{ + struct timeval tv; + u_int8_t r; + int to; + + if (rv || flag == UIO_READ) + bus_space_write_1(sc->sc_batm, sc->sc_bahm, 1, TPM_LEGACY_ABRT); + else { + tv.tv_sec = TPM_LEGACY_TMO; + tv.tv_usec = 0; + to = tvtohz(&tv) / TPM_LEGACY_SLEEP; + while(((r = bus_space_read_1(sc->sc_batm, sc->sc_bahm, 1)) & + TPM_LEGACY_BUSY) && to--) { + rv = tsleep(sc, PRIBIO | PCATCH, "legacy_tpm_end", + TPM_LEGACY_SLEEP); + if (rv && rv != EWOULDBLOCK) + return rv; + } + +#if defined(TPM_DEBUG) && !defined(__FreeBSD__) + printf("%s: bits %b\n", sc->sc_dev.dv_xname, r, TPM_LEGACY_BITS); +#endif + if (r & TPM_LEGACY_BUSY) + return EIO; + + if (r & TPM_LEGACY_RE) + return EIO; /* XXX Retry the loop? */ + } + + return rv; +} + +int +#ifdef __FreeBSD__ +tpmopen(struct cdev *dev, int flag, int mode, struct thread *td) +#else +tpmopen(dev_t dev, int flag, int mode, struct proc *p) +#endif +{ + struct tpm_softc *sc = TPMSOFTC(dev); + + if (!sc) + return ENXIO; + + if (sc->sc_flags & TPM_OPEN) + return EBUSY; + + sc->sc_flags |= TPM_OPEN; + + return 0; +} + +int +#ifdef __FreeBSD__ +tpmclose(struct cdev *dev, int flag, int mode, struct thread *td) +#else +tpmclose(dev_t dev, int flag, int mode, struct proc *p) +#endif +{ + struct tpm_softc *sc = TPMSOFTC(dev); + + if (!sc) + return ENXIO; + + if (!(sc->sc_flags & TPM_OPEN)) + return EINVAL; + + sc->sc_flags &= ~TPM_OPEN; + + return 0; +} + +int +#ifdef __FreeBSD__ +tpmread(struct cdev *dev, struct uio *uio, int flags) +#else +tpmread(dev_t dev, struct uio *uio, int flags) +#endif +{ + struct tpm_softc *sc = TPMSOFTC(dev); + u_int8_t buf[TPM_BUFSIZ], *p; + size_t cnt; + int n, len, rv, s; + + if (!sc) + return ENXIO; + + s = spltty(); + if ((rv = (sc->sc_start)(sc, UIO_READ))) { + splx(s); + return rv; + } + +#ifdef TPM_DEBUG + printf("tpmread: getting header\n"); +#endif + if ((rv = (sc->sc_read)(sc, buf, TPM_HDRSIZE, &cnt, 0))) { + (sc->sc_end)(sc, UIO_READ, rv); + splx(s); + return rv; + } + + len = (buf[2] << 24) | (buf[3] << 16) | (buf[4] << 8) | buf[5]; +#ifdef TPM_DEBUG + printf("tpmread: len %d, io count %d\n", len, uio->uio_resid); +#endif + if (len > uio->uio_resid) { + rv = EIO; + (sc->sc_end)(sc, UIO_READ, rv); +#ifdef TPM_DEBUG + printf("tpmread: bad residual io count 0x%x\n", uio->uio_resid); +#endif + splx(s); + return rv; + } + + /* Copy out header. */ + if ((rv = uiomove((caddr_t)buf, cnt, uio))) { + (sc->sc_end)(sc, UIO_READ, rv); + splx(s); + return rv; + } + + /* Get remaining part of the answer (if anything is left). */ + for (len -= cnt, p = buf, n = sizeof(buf); len > 0; p = buf, len -= n, + n = sizeof(buf)) { + n = MIN(n, len); +#ifdef TPM_DEBUG + printf("tpmread: n %d len %d\n", n, len); +#endif + if ((rv = (sc->sc_read)(sc, p, n, NULL, TPM_PARAM_SIZE))) { + (sc->sc_end)(sc, UIO_READ, rv); + splx(s); + return rv; + } + p += n; + if ((rv = uiomove((caddr_t)buf, p - buf, uio))) { + (sc->sc_end)(sc, UIO_READ, rv); + splx(s); + return rv; + } + } + + rv = (sc->sc_end)(sc, UIO_READ, rv); + splx(s); + return rv; +} + +int +#ifdef __FreeBSD__ +tpmwrite(struct cdev *dev, struct uio *uio, int flags) +#else +tpmwrite(dev_t dev, struct uio *uio, int flags) +#endif +{ + struct tpm_softc *sc = TPMSOFTC(dev); + u_int8_t buf[TPM_BUFSIZ]; + int n, rv, s; + + if (!sc) + return ENXIO; + + s = spltty(); + +#ifdef TPM_DEBUG + printf("tpmwrite: io count %d\n", uio->uio_resid); +#endif + + n = MIN(sizeof(buf), uio->uio_resid); + if ((rv = uiomove((caddr_t)buf, n, uio))) { + splx(s); + return rv; + } + + if ((rv = (sc->sc_start)(sc, UIO_WRITE))) { + splx(s); + return rv; + } + + if ((rv = (sc->sc_write(sc, buf, n)))) { + splx(s); + return rv; + } + + rv = (sc->sc_end)(sc, UIO_WRITE, rv); + splx(s); + return rv; +} + +int +#ifdef __FreeBSD__ +tpmioctl(struct cdev *dev, u_long cmd, caddr_t data, int flags, + struct thread *td) +#else +tpmioctl(dev_t dev, u_long cmd, caddr_t data, int flags, struct proc *p) +#endif +{ + return ENOTTY; +} diff -Nupr src-9.0-current/sys/dev/tpm/tpm_acpi.c src/sys/dev/tpm/tpm_acpi.c --- src-9.0-current/sys/dev/tpm/tpm_acpi.c 1970-01-01 01:00:00.000000000 +0100 +++ src/sys/dev/tpm/tpm_acpi.c 2010-08-11 22:19:17.000000000 +0200 @@ -0,0 +1,79 @@ +/* + * Copyright (c) 2008, 2009 Michael Shalayeff + * Copyright (c) 2009, 2010 Hans-Joerg Hoexer + * All rights reserved. + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES + * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF + * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR + * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES + * WHATSOEVER RESULTING FROM LOSS OF MIND, USE, DATA OR PROFITS, WHETHER IN + * AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT + * OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. + */ + +#include +#include +#include +#include +#include + +#include +#include +#include +#include + +#include +#include +#include + +#include + +#include +#include +#include "tpmvar.h" + +#include "opt_acpi.h" +#include +#include +#include + + + +char *tpm_ids[] = {"ATM1200", "BCM0102", "INTC0102", "SNO3504", "WEC1000", + "PNP0C31", NULL}; + +static int +tpm_acpi_probe(device_t dev) +{ + if (ACPI_ID_PROBE(device_get_parent(dev), dev, tpm_ids) != NULL) { + device_set_desc(dev, "Trusted Platform Module"); + return BUS_PROBE_DEFAULT; + } + + return ENXIO; +} + +static device_method_t tpm_acpi_methods[] = { +#if 0 + /*In some case, TPM existance is found only in TPCA header*/ + DEVMETHOD(device_identify, tpm_acpi_identify), +#endif + + DEVMETHOD(device_probe, tpm_acpi_probe), + DEVMETHOD(device_attach, tpm_attach), + DEVMETHOD(device_detach, tpm_detach), + DEVMETHOD(device_suspend, tpm_suspend), + DEVMETHOD(device_resume, tpm_resume), + { 0, 0 } +}; +static driver_t tpm_acpi_driver = { + "tpm", tpm_acpi_methods, sizeof(struct tpm_softc), +}; + +devclass_t tpm_devclass; +DRIVER_MODULE(tpm, acpi, tpm_acpi_driver, tpm_devclass, 0, 0); diff -Nupr src-9.0-current/sys/dev/tpm/tpm_isa.c src/sys/dev/tpm/tpm_isa.c --- src-9.0-current/sys/dev/tpm/tpm_isa.c 1970-01-01 01:00:00.000000000 +0100 +++ src/sys/dev/tpm/tpm_isa.c 2010-08-11 22:19:26.000000000 +0200 @@ -0,0 +1,92 @@ +/* + * Copyright (c) 2008, 2009 Michael Shalayeff + * Copyright (c) 2009, 2010 Hans-Joerg Hoexer + * All rights reserved. + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES + * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF + * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR + * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES + * WHATSOEVER RESULTING FROM LOSS OF MIND, USE, DATA OR PROFITS, WHETHER IN + * AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT + * OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. + */ +#include +#include +#include +#include +#include + +#ifdef __FreeBSD__ +#include +#include +#include +#include + +#include +#include +#include + +#include + +#include +#include +#else +#include + +#include +#include +#include +#include + +#include +#include +#endif +#include "tpmvar.h" + +static int +tpm_isa_probe(device_t dev) +{ + bus_space_tag_t iot; + bus_space_handle_t ioh; + struct resource *mem_res; + int rv, mem_rid; + + mem_rid = 0; + mem_res = bus_alloc_resource_any(dev, SYS_RES_MEMORY, &mem_rid, + RF_ACTIVE); + if (mem_res == NULL) + return (ENXIO); + iot = rman_get_bustag(mem_res); + ioh = rman_get_bushandle(mem_res); + + if ((rv = tpm_tis12_probe(iot, ioh))) + device_set_desc(dev, "Trusted Platform Module"); + + bus_release_resource(dev, SYS_RES_MEMORY, mem_rid, mem_res); + return rv ? 0 : ENXIO; +} + +static device_method_t tpm_methods[] = { +#if 0 + DEVMETHOD(device_identify, tpm_identify), +#endif + DEVMETHOD(device_probe, tpm_isa_probe), + DEVMETHOD(device_attach, tpm_attach), + DEVMETHOD(device_detach, tpm_detach), + DEVMETHOD(device_suspend, tpm_suspend), + DEVMETHOD(device_resume, tpm_resume), + { 0, 0 } +}; + +static driver_t tpm_driver = { + "tpm", tpm_methods, sizeof(struct tpm_softc), +}; + +static devclass_t tpm_devclass; + +DRIVER_MODULE(tpm, isa, tpm_driver, tpm_devclass, 0, 0); diff -Nupr src-9.0-current/sys/dev/tpm/tpmvar.h src/sys/dev/tpm/tpmvar.h --- src-9.0-current/sys/dev/tpm/tpmvar.h 1970-01-01 01:00:00.000000000 +0100 +++ src/sys/dev/tpm/tpmvar.h 2010-08-11 14:11:34.000000000 +0200 @@ -0,0 +1,46 @@ +#ifndef _TPMVAR_H +#define _TPMVAR_H + +struct tpm_softc { +#ifndef __FreeBSD__ + struct device sc_dev; +#endif + void *sc_ih; + + int (*sc_init)(struct tpm_softc *, int, const char *); + int (*sc_start)(struct tpm_softc *, int); + int (*sc_read)(struct tpm_softc *, void *, int, size_t *, int); + int (*sc_write)(struct tpm_softc *, void *, int); + int (*sc_end)(struct tpm_softc *, int, int); + + bus_space_tag_t sc_bt, sc_batm; + bus_space_handle_t sc_bh, sc_bahm; + + u_int32_t sc_devid; + u_int32_t sc_rev; + u_int32_t sc_stat; + u_int32_t sc_capabilities; + + int sc_flags; +#define TPM_OPEN 0x0001 + + int sc_vector; +#ifdef __FreeBSD__ + void *intr_cookie; + int mem_rid, irq_rid; + struct resource *mem_res, *irq_res; + struct cdev *sc_cdev; +#endif + +#ifndef __FreeBSD__ + void *sc_powerhook; +#endif + int sc_suspend; +}; + +int tpm_tis12_probe(bus_space_tag_t iot, bus_space_handle_t ioh); +int tpm_attach(device_t dev); +int tpm_detach(device_t dev); +int tpm_suspend(device_t dev); +int tpm_resume(device_t dev); +#endif diff -Nupr src-9.0-current/sys/conf/files.i386 src/sys/conf/files.i386 --- src-9.0-current/sys/conf/files.i386 2010-08-10 12:04:27.000000000 +0200 +++ src/sys/conf/files.i386 2010-08-11 14:17:08.000000000 +0200 @@ -231,6 +231,9 @@ dev/syscons/scterm-teken.c optional sc dev/syscons/scvesactl.c optional sc vga vesa dev/syscons/scvgarndr.c optional sc vga dev/syscons/scvtb.c optional sc +dev/tpm/tpm.c optional tpm +dev/tpm/tpm_acpi.c optional tpm +dev/tpm/tpm_isa.c optional tpm isa dev/uart/uart_cpu_i386.c optional uart dev/acpica/acpi_if.m standard dev/acpi_support/acpi_wmi_if.m standard --- src-9.0-current/sys/i386/conf/GENERIC 2010-08-10 12:06:32.000000000 +0200 +++ src/sys/i386/conf/GENERIC 2010-08-10 16:03:09.000000000 +0200 @@ -198,6 +198,9 @@ device plip # TCP/IP over parallel device ppi # Parallel port interface device #device vpo # Requires scbus and da +# TPM device +device tpm + # If you've got a "dumb" serial or parallel PCI card that is # supported by the puc(4) glue driver, uncomment the following # line to enable it (connects to sio, uart and/or ppc drivers): diff -Nupr src-9.0-current/usr.sbin/acpi/acpidump/acpi.c src/usr.sbin/acpi/acpidump/acpi.c --- src-9.0-current/usr.sbin/acpi/acpidump/acpi.c 2009-08-25 22:35:57.000000000 +0200 +++ src/usr.sbin/acpi/acpidump/acpi.c 2010-08-11 13:57:38.000000000 +0200 @@ -68,6 +68,7 @@ static void acpi_print_srat_cpu(uint32_t static void acpi_print_srat_memory(ACPI_SRAT_MEM_AFFINITY *mp); static void acpi_print_srat(ACPI_SUBTABLE_HEADER *srat); static void acpi_handle_srat(ACPI_TABLE_HEADER *sdp); +static void acpi_handle_tcpa(ACPI_TABLE_HEADER *sdp); static void acpi_print_sdt(ACPI_TABLE_HEADER *sdp); static void acpi_print_fadt(ACPI_TABLE_HEADER *sdp); static void acpi_print_facs(ACPI_TABLE_FACS *facs); @@ -81,6 +82,46 @@ static void acpi_walk_subtables(ACPI_TAB /* Size of an address. 32-bit for ACPI 1.0, 64-bit for ACPI 2.0 and up. */ static int addr_size; +/* Strings used in the TCPA table */ +static const char *tcpa_event_type_strings[] = { + "PREBOOT Certificate", + "POST Code", + "Unused", + "No Action", + "Separator", + "Action", + "Event Tag", + "S-CRTM Contents", + "S-CRTM Version", + "CPU Microcode", + "Platform Config Flags", + "Table of Devices", + "Compact Hash", + "IPL", + "IPL Partition Data", + "Non-Host Code", + "Non-Host Config", + "Non-Host Info" +}; + +static const char *TCPA_pcclient_strings[] = { + "", + "SMBIOS", + "BIS Certificate", + "POST BIOS ROM Strings", + "ESCD", + "CMOS", + "NVRAM", + "Option ROM Execute", + "Option ROM Configurateion", + "", + "Option ROM Microcode Update ", + "S-CRTM Version String", + "S-CRTM Contents", + "POST Contents", + "Table of Devices", +}; + static void acpi_print_string(char *s, size_t length) { @@ -492,6 +533,165 @@ acpi_print_srat_cpu(uint32_t apic_id, ui printf("\tProximity Domain=%d\n", proximity_domain); } +static char * +acpi_tcpa_evname(struct TCPAevent *event) +{ + struct TCPApc_event *pc_event; + char *eventname = NULL; + + pc_event = (struct TCPApc_event *)(event + 1); + + switch(event->event_type) { + case PREBOOT: + case POST_CODE: + case UNUSED: + case NO_ACTION: + case SEPARATOR: + case SCRTM_CONTENTS: + case SCRTM_VERSION: + case CPU_MICROCODE: + case PLATFORM_CONFIG_FLAGS: + case TABLE_OF_DEVICES: + case COMPACT_HASH: + case IPL: + case IPL_PARTITION_DATA: + case NONHOST_CODE: + case NONHOST_CONFIG: + case NONHOST_INFO: + asprintf(&eventname, "%s", + tcpa_event_type_strings[event->event_type]); + break; + + case ACTION: + eventname = calloc(event->event_size + 1, sizeof(char)); + memcpy(eventname, pc_event, event->event_size); + break; + + case EVENT_TAG: + switch (pc_event->event_id) { + case SMBIOS: + case BIS_CERT: + case CMOS: + case NVRAM: + case OPTION_ROM_EXEC: + case OPTION_ROM_CONFIG: + case S_CRTM_VERSION: + case POST_BIOS_ROM: + case ESCD: + case OPTION_ROM_MICROCODE: + case S_CRTM_CONTENTS: + case POST_CONTENTS: + asprintf(&eventname, "%s", + TCPA_pcclient_strings[pc_event->event_id]); + break; + + default: + asprintf(&eventname, "", + pc_event->event_id); + break; + } + break; + + default: + asprintf(&eventname, "", event->event_type); + break; + } + + return eventname; +} + +static void +acpi_print_tcpa(struct TCPAevent *event) +{ + int i; + char *eventname; + + eventname = acpi_tcpa_evname(event); + + printf("\t%d", event->pcr_index); + printf(" 0x"); + for (i = 0; i < 20; i++) + printf("%02x", event->pcr_value[i]); + printf(" [%s]\n", eventname ? eventname : ""); + + free(eventname); +} + +static void +acpi_handle_tcpa(ACPI_TABLE_HEADER *sdp) +{ + struct TCPAbody *tcpa; + struct TCPAevent *event; + u_int64_t len, paddr; + unsigned char *vaddr = NULL; + unsigned char *vend = NULL; + + printf(BEGIN_COMMENT); + acpi_print_sdt(sdp); + tcpa = (struct TCPAbody *) sdp; + + switch (tcpa->platform_class) { + case ACPI_TCPA_BIOS_CLIENT: + len = tcpa->client.log_max_len; + paddr = tcpa->client.log_start_addr; + break; + + case ACPI_TCPA_BIOS_SERVER: + len = tcpa->server.log_max_len; + paddr = tcpa->server.log_start_addr; + break; + + default: + printf("XXX"); + printf(END_COMMENT); + return; + } + printf("\tClass %d Base Address 0x%jx Length %lld\n\n", + tcpa->platform_class, paddr, len); + + if (len == 0) { + printf("\tEmpty TCPA table\n"); + printf(END_COMMENT); + return; + } + + vaddr = (unsigned char *)acpi_map_physical(paddr, len); + vend = vaddr + len; + + while (vaddr != NULL) { + if (vaddr + sizeof(struct TCPAevent) >= vend) + break; + event = (struct TCPAevent *)vaddr; + if (vaddr + event->event_size >= vend) + break; + if (event->event_type == 0 && event->event_size == 0) + break; +#if 0 + { + unsigned int i, j, k; + + printf("\n\tsize %d\n\t\t%p ", event->event_size, vaddr); + for (j = 0, i = 0; i < + sizeof(struct TCPAevent) + event->event_size; i++) { + printf("%02x ", vaddr[i]); + if ((i+1) % 8 == 0) { + for (k = 0; k < 8; k++) + printf("%c", isprint(vaddr[j+k]) ? + vaddr[j+k] : '.'); + printf("\n\t\t%p ", &vaddr[i + 1]); + j = i + 1; + } + } + printf("\n"); } +#endif + acpi_print_tcpa(event); + + vaddr += sizeof(struct TCPAevent) + event->event_size; + } + + printf(END_COMMENT); +} + static void acpi_print_srat_memory(ACPI_SRAT_MEM_AFFINITY *mp) { @@ -886,6 +1086,8 @@ acpi_handle_rsdt(ACPI_TABLE_HEADER *rsdp acpi_handle_mcfg(sdp); else if (!memcmp(sdp->Signature, ACPI_SIG_SRAT, 4)) acpi_handle_srat(sdp); + else if (!memcmp(sdp->Signature, ACPI_SIG_TCPA, 4)) + acpi_handle_tcpa(sdp); else { printf(BEGIN_COMMENT); acpi_print_sdt(sdp); diff -Nupr src-9.0-current/usr.sbin/acpi/acpidump/acpidump.h src/usr.sbin/acpi/acpidump/acpidump.h --- src-9.0-current/usr.sbin/acpi/acpidump/acpidump.h 2009-08-25 22:35:57.000000000 +0200 +++ src/usr.sbin/acpi/acpidump/acpidump.h 2010-08-11 13:56:04.000000000 +0200 @@ -55,6 +55,78 @@ /* Find and map the RSD PTR structure and return it for parsing */ ACPI_TABLE_HEADER *sdt_load_devmem(void); +/* TCPA */ +struct TCPAbody { + ACPI_TABLE_HEADER header; + uint16_t platform_class; +#define ACPI_TCPA_BIOS_CLIENT 0x00 +#define ACPI_TCPA_BIOS_SERVER 0x01 + union { + struct client_hdr { + uint32_t log_max_len __packed; + uint64_t log_start_addr __packed; + } client; + struct server_hdr { + uint16_t reserved; + uint64_t log_max_len __packed; + uint64_t log_start_addr __packed; + } server; + }; +} __packed; + +struct TCPAevent { + u_int32_t pcr_index; + u_int32_t event_type; + u_int8_t pcr_value[20]; + u_int32_t event_size; + u_int8_t event_data[0]; +}; + +struct TCPApc_event { + u_int32_t event_id; + u_int32_t event_size; + u_int8_t event_data[0]; +}; + +enum TCPAevent_types { + PREBOOT = 0, + POST_CODE, + UNUSED, + NO_ACTION, + SEPARATOR, + ACTION, + EVENT_TAG, + SCRTM_CONTENTS, + SCRTM_VERSION, + CPU_MICROCODE, + PLATFORM_CONFIG_FLAGS, + TABLE_OF_DEVICES, + COMPACT_HASH, + IPL, + IPL_PARTITION_DATA, + NONHOST_CODE, + NONHOST_CONFIG, + NONHOST_INFO, + EVENT_TYPE_MAX, +}; + +enum TCPApcclient_ids { + SMBIOS = 1, + BIS_CERT, + POST_BIOS_ROM, + ESCD, + CMOS, + NVRAM, + OPTION_ROM_EXEC, + OPTION_ROM_CONFIG, + OPTION_ROM_MICROCODE = 10, + S_CRTM_VERSION, + S_CRTM_CONTENTS, + POST_CONTENTS, + HOST_TABLE_OF_DEVICES, + PCCLIENT_ID_MAX, +}; + /* * Load the DSDT from a previous save file. Note that other tables are * not saved (i.e. FADT) diff -Nupr src-9.0-current/share/man/man4/tpm.4 src/share/man/man4/tpm.4 --- src-9.0-current/share/man/man4/tpm.4 1970-01-01 01:00:00.000000000 +0100 +++ src/share/man/man4/tpm.4 2010-08-10 16:03:09.000000000 +0200 @@ -0,0 +1,74 @@ +.\" +.\" Copyright (c) 2010 Hans-J +.\" +.\" Permission to use, copy, modify, and distribute this software for any +.\" purpose with or without fee is hereby granted, provided that the above +.\" copyright notice and this permission notice appear in all copies. +.\" +.\" THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES +.\" WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF +.\" MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR +.\" ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES +.\" WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN +.\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF +.\" OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. +.\" +.\" $FreeBSD:$ +.\" +.Dd March 8, 2010 +.Dt TPM 4 +.Os +.Sh NAME +.Nm tpm +.Nd Trusted Platform Module +.Sh SYNOPSIS +.Cd "device tpm" +.Pp +In +.Pa /boot/device.hints : +.Cd hint.tpm.0.at="isa" +.Cd hint.tpm.0.maddr="0xfed40000" +.Cd hint.tpm.0.msize="0x5000" +.Cd hint.tpm.1.at="isa" +.Cd hint.tpm.1.maddr="0xfed40000" +.Cd hint.tpm.1.msize="0x1000" +.Sh DESCRIPTION +The +.Nm +driver provides support for various trusted platfrom modules (TPM) that can +store cryptographic keys. +.Pp +Supported modules: +.Pp +.Bl -bullet -compact -offset indent +.It +Atmel 97SC3203 +.It +Broadcom BCM0102 +.It +Infineon IFX SLD 9630 TT 1.1 and IFX SLB 9635 TT 1.2 +.It +Intel INTC0102 +.It +Sinosun SNS SSX35 +.It +STM ST19WP18 +.It +Winbond WEC WPCT200 +.El +.Pp +The driver can be configured to use an IRQ by providing a free ISA +interrupt vector in +.Pa /boot/device.hints . +.Sh SEE ALSO +.Xr intro 4 , +.Xr files.conf 5, +.Xr config 8 +.Sh AUTHORS +.An -nosplit +The +.Nm +driver was written by +.An Michael Shalayeff +and +.An Hans-Joerg Hoexer . From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 12 00:16:26 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9ADD91065687; Thu, 12 Aug 2010 00:16:26 +0000 (UTC) (envelope-from takawata@init-main.com) Received: from sana.init-main.com (unknown [IPv6:2001:240:28::1]) by mx1.freebsd.org (Postfix) with ESMTP id 38E7A8FC17; Thu, 12 Aug 2010 00:16:26 +0000 (UTC) Received: from ns.init-main.com (localhost [127.0.0.1]) by sana.init-main.com (8.14.3/8.14.3) with ESMTP id o7C0Ci7T091937; Thu, 12 Aug 2010 09:12:46 +0900 (JST) (envelope-from takawata@ns.init-main.com) Message-Id: <201008120012.o7C0Ci7T091937@sana.init-main.com> To: Hans-Joerg Hoexer In-reply-to: Your message of "Wed, 11 Aug 2010 22:30:42 +0200." <20100811203042.GA26413@modermoor.genua.de> Date: Thu, 12 Aug 2010 09:12:44 +0900 From: Takanori Watanabe Cc: tss-project@genua.de, freebsd-current@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: Driver tpm(4) and third party packages for trusted platform modules X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2010 00:16:26 -0000 In message <20100811203042.GA26413@modermoor.genua.de>, Hans-Joerg Hoexer wrote: >Hi, > >On Wed, Aug 04, 2010 at 07:39:41PM +0900, Takanori Watanabe wrote: >> Update my patch. Split bus attachment from main driver file >> (need to update sys/conf/files), add detach method for convinience, >> and attach softc to cdev.si_drv1 . > >I've updated our diff for 9-current, including your patch. Ok, I've commit them to the head. From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 12 08:08:51 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 42002106566C; Thu, 12 Aug 2010 08:08:51 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 92CAC8FC1C; Thu, 12 Aug 2010 08:08:49 +0000 (UTC) Received: by bwz9 with SMTP id 9so896486bwz.13 for ; Thu, 12 Aug 2010 01:08:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=WTMGZXv7oIBkogFhwoZPAImsc4uPVJR2KuTgcREASLY=; b=EmBFYSlewjg6hSITuP9WS2qxvzFtHVpM638b4pwpDOAtUBtvKK14if9EjLB8F53UAQ g7QiJiBJb34FYVBelyG4MVzOQsumNz7AwaPus3cSdcX0JoBT0uikcByS4z42U/Xe+XuJ EkOCQX4MD58jsUk52X/liAsAMZSZC4BjHqiu8= 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=Xh/T+1kbTs8t/c47+YDhBZmOmihEXkolUTnnyK0t0MrmwXHN/18+9PNRQM3N1aIsOX 6MTzAP+d2VZebkbe9VhSHPYutsaNV0pdjGRisNxBo7xxiZ50i1NSSjaZbYjhxUGk3VAd bFhbYr/zrHvDOcOYXH6Lqlu9zLaVfuWcoq6oE= MIME-Version: 1.0 Received: by 10.204.146.153 with SMTP id h25mr408792bkv.86.1281600528292; Thu, 12 Aug 2010 01:08:48 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.204.82.6 with HTTP; Thu, 12 Aug 2010 01:08:48 -0700 (PDT) In-Reply-To: <8662zkurx9.fsf@ds4.des.no> References: <86fwyq8rsc.fsf@ds4.des.no> <86d3tujh72.fsf@ds4.des.no> <864of680wv.fsf@ds4.des.no> <8662zkurx9.fsf@ds4.des.no> Date: Thu, 12 Aug 2010 01:08:48 -0700 X-Google-Sender-Auth: gRuHbC6J8Xg88knfbksyFdLZHOg Message-ID: From: Garrett Cooper To: =?ISO-8859-1?Q?Dag=2DErling_Sm=F8rgrav?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, Ivan Voras Subject: Re: Why is TUNABLE_INT discouraged? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2010 08:08:51 -0000 2010/8/9 Dag-Erling Sm=F8rgrav : > Garrett Cooper writes: >> Why would someone express a tunable in a memory address (not being >> sarcastic... I just don't see why it makes sense right now, but if >> there's a valid reason I'm more than happy to be educated :)..)? > > A few examples: > > hw.acpi.host_mem_start > hw.pci.host_mem_start > hw.physmemstart > > The following are not addresses, but can be > 32 bits on 64-bit machines > and even on some 32-bit machines using PAE / PTE: > > hw.physmem > vm.kmem_size > vm.kmem_size_max > vm.kmem_size_min Ok -- good to know. > It might be a good idea to introduce TUNABLE_POINTER and TUNABLE_SIZE. I would actually argue against doing that because it would only create divergence between sysctl and tunable KPIs... but that's just me. The patch I provided before would converge sysctl and tunables a bit more (and I'd more than happily submit patches for the other missing cases on the sysctl side to get parity with the tunables). If it makes sense to add the sysctls _and_ the tunables for POINTER and SIZE though, I'll provide a patch for both cases in one shot. (BTW, when you say TUNABLE_SIZE, I assume it would be a size_t quantity?) Something might need to be done to the values returned by the tunables though, because they don't respect boundaries, and can overflow right now (which exacerbates the issue with values crammed into smaller datatypes)... Thanks! -Garrett From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 12 12:25:42 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8A3D31065695; Thu, 12 Aug 2010 12:25:42 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 41E0B8FC1C; Thu, 12 Aug 2010 12:25:42 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 334C61FFC33; Thu, 12 Aug 2010 12:25:41 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 0120B8454D; Thu, 12 Aug 2010 14:25:40 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Garrett Cooper References: <86fwyq8rsc.fsf@ds4.des.no> <86d3tujh72.fsf@ds4.des.no> <864of680wv.fsf@ds4.des.no> <8662zkurx9.fsf@ds4.des.no> Date: Thu, 12 Aug 2010 14:25:40 +0200 In-Reply-To: (Garrett Cooper's message of "Thu, 12 Aug 2010 01:08:48 -0700") Message-ID: <8662zg586z.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, Ivan Voras Subject: Re: Why is TUNABLE_INT discouraged? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2010 12:25:42 -0000 Garrett Cooper writes: > Dag-Erling Sm=C3=B8rgrav writes: > > It might be a good idea to introduce TUNABLE_POINTER and TUNABLE_SIZE. > I would actually argue against doing that because it would only create > divergence between sysctl and tunable KPIs... Not if we also introduce corresponding SYSCTLs. Note that my idea is to have these as aliases for the correct primitive types. > (BTW, when you say TUNABLE_SIZE, I assume it would be a size_t quantity?) Yes. > Something might need to be done to the values returned by the tunables > though, because they don't respect boundaries, and can overflow right > now (which exacerbates the issue with values crammed into smaller > datatypes)... Yes. How about this: - rename getenv_quad() to getenv_signed() and getenv_unsigned() - add min / max arguments - implement getenv_quad() (and all the others) in terms of getenv_number() e.g.=20 int getenv_uint(const char *name, unsigned int *data) { unsigned long long tmp; int rval; if ((rval =3D getenv_unsigned(name, &tmp, 0, UINT_MAX)) =3D=3D 0) *data =3D (unsigned int)tmp; return (rval); } (note that due to the min / max arguments, the complexity of handling both signed and unsigned values in the same function probably exceeds the complexity of having two very similar functions) DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 12 20:19:19 2010 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1ADC51065698 for ; Thu, 12 Aug 2010 20:19:19 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from tower.berklix.org (tower.berklix.org [83.236.223.114]) by mx1.freebsd.org (Postfix) with ESMTP id 925798FC16 for ; Thu, 12 Aug 2010 20:19:18 +0000 (UTC) Received: from park.js.berklix.net (p549A44E0.dip.t-dialin.net [84.154.68.224]) (authenticated bits=0) by tower.berklix.org (8.14.2/8.14.2) with ESMTP id o7CKJ4du047639; Thu, 12 Aug 2010 20:19:05 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by park.js.berklix.net (8.13.8/8.13.8) with ESMTP id o7CKIxJc006655; Thu, 12 Aug 2010 22:18:59 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.3/8.14.3) with ESMTP id o7CKIc06020329; Thu, 12 Aug 2010 22:18:43 +0200 (CEST) (envelope-from jhs@fire.js.berklix.net) Message-Id: <201008122018.o7CKIc06020329@fire.js.berklix.net> To: hackers@freebsd.org From: "Julian H. Stacey" Organization: http://www.berklix.com BSD Unix Linux Consultancy, Munich Germany User-agent: EXMH on FreeBSD http://www.berklix.com/free/ X-URL: http://www.berklix.com In-reply-to: Your message "Wed, 11 Aug 2010 20:22:22 +0200." <201008111822.o7BIMM1R053210@fire.js.berklix.net> Date: Thu, 12 Aug 2010 22:18:38 +0200 Sender: jhs@berklix.com Cc: Julian Elischer , Paul Wootton Subject: Re: real memory falsely reports 8G, BIOS & avail memory reports 1G X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2010 20:19:19 -0000 > dmidecode --type memory # /usr/ports/sysutils/dmidecode/ > shows this laptop not returning good output, just > # dmidecode 2.10 > SMBIOS 2.3 present. > > Wrong DMI structures count: 43 announced, only 23 decoded. After cold reboot, though dmesg still weird: real memory = 8572108800 (8175 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009bfff, 634880 bytes (155 pages) 0x0000000000f1a000 - 0x000000003e19ffff, 1026056192 bytes (250502 pages) avail memory = 1018191872 (971 MB) dmidecode now gives more info (maybe new libs), but dmidecode output still weird, some extracts below, full version at http://berklix.com/~jhs/hardware/laptops/novatech-8355/dmidecode/ I've asked Novatech about a new BIOS for this MiTAC laptop. Handle 0x0013, DMI type 16, 15 bytes Physical Memory Array Use: System Memory Maximum Capacity: 256 MB Error Information Handle: 0x001A Number Of Devices: 2 Handle 0x0017, DMI type 17, 27 bytes Memory Device Array Handle: 0x0013 Total Width: 64 bits Data Width: 64 bits Size: 2047 MB Form Factor: DIMM Set: None Locator: DRAM Slot 0 Bank Locator: Banks 0/1 Type: DRAM Type Detail: EDO Handle 0x0018, DMI type 17, 27 bytes Memory Device Array Handle: 0x0013 Total Width: 64 bits Data Width: 64 bits Size: 2048 MB Form Factor: DIMM Set: None Locator: DRAM Slot 1 Bank Locator: Banks 2/3 Type: DRAM Type Detail: EDO Handle 0x0019, DMI type 17, 27 bytes Memory Device Array Handle: 0x0013 Total Width: 64 bits Data Width: 64 bits Size: 4080 MB Form Factor: DIMM Set: Unknown Locator: DRAM Slot 2 Bank Locator: Banks 4/5 Type: DRAM Type Detail: EDO Handle 0x001B, DMI type 19, 15 bytes Memory Array Mapped Address Starting Address: 0x00000000000 Ending Address: 0x000400003FF Range Size: 1048577 kB Handle 0x001C, DMI type 20, 19 bytes Memory Device Mapped Address Starting Address: 0x00000000000 Ending Address: 0x1FFFFFFFFFF Range Size: 2048 GB Handle 0x001D, DMI type 20, 19 bytes Memory Device Mapped Address Starting Address: 0x20000000000 Ending Address: 0x3FFFFFFFFFF Range Size: 2048 GB Handle 0x001E, DMI type 20, 19 bytes Memory Device Mapped Address Starting Address: 0x00000000000 Ending Address: 0x3FBFFFFFFFF Range Size: 4080 GB Cheers, Julian -- Julian Stacey: BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Mail in plain text, Not HTML, quoted-printable & base 64 dumped with spam. Avoid top posting, It cripples itemised cumulative responses. From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 12 22:24:16 2010 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E735A10656AE; Thu, 12 Aug 2010 22:24:16 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id AA2D98FC13; Thu, 12 Aug 2010 22:24:16 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id C5C881FFC34; Thu, 12 Aug 2010 22:24:15 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 86BFD84525; Fri, 13 Aug 2010 00:24:15 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: jhell References: <86wrry1hwv.fsf@ds4.des.no> <4C647362.7050006@dataix.net> Date: Fri, 13 Aug 2010 00:24:15 +0200 In-Reply-To: <4C647362.7050006@dataix.net> (jhell@dataix.net's message of "Thu, 12 Aug 2010 18:19:14 -0400") Message-ID: <86wrrv31ww.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: geom@freebsd.org, hackers@freebsd.org Subject: Re: Support for WD Advanced Format disks X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2010 22:24:17 -0000 jhell writes: > On stable/8 this is needed to build. Seems the need for linking against > libutil came in revision r211233. Yes, I forgot to commit the Makefile. Thank you for reminding me. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 12 22:48:10 2010 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9555F1065694; Thu, 12 Aug 2010 22:48:10 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 2A5C08FC0C; Thu, 12 Aug 2010 22:48:09 +0000 (UTC) Received: by qwg5 with SMTP id 5so2378270qwg.13 for ; Thu, 12 Aug 2010 15:48:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=bJae1njTwVtq2A99v5V0R0yukb7y7eAenq4WWs2JxKQ=; b=Quhz3HrRMh1R3n3EmIXYhx74OzbhhLvy7hCINe1WIj3eGU6NUqhCIrelRu0tJFgI5j 0Tjgc0+mysxB5nvIprMBe8t1IeYfN+6dmk9ZXNh0xZtVBv2zkifFzuACicb7KTQzMWaO ODkyaEU4cf+4UWHBmHSeMJyTzWd4NZ7HTDOo4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=HTJJEeirAP/cb8sNkG+ZzbVsz5+PqN0Jv/In6ScyoId/Z4dI6ufO62AJZa7coMlqwN o+gLOACUNDfrYVwlTdt5w1BggasLt60ceUUUNDma45wu1VVPTt3zhn1UUqo4fGZNKw1B ef9MgRdENoXzc+bNtbInNkrOicynhDFcylseQ= Received: by 10.224.65.147 with SMTP id j19mr432430qai.189.1281651558251; Thu, 12 Aug 2010 15:19:18 -0700 (PDT) Received: from centel.dataix.local (adsl-99-19-46-227.dsl.klmzmi.sbcglobal.net [99.19.46.227]) by mx.google.com with ESMTPS id w14sm815158vce.2.2010.08.12.15.19.15 (version=SSLv3 cipher=RC4-MD5); Thu, 12 Aug 2010 15:19:16 -0700 (PDT) Sender: "J. Hellenthal" Message-ID: <4C647362.7050006@dataix.net> Date: Thu, 12 Aug 2010 18:19:14 -0400 From: jhell User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.8) Gecko/20100806 Lightning/1.0b1 Thunderbird MIME-Version: 1.0 To: =?UTF-8?B?RGFnLUVybGluZyBTbcO4cmdyYXY=?= References: <86wrry1hwv.fsf@ds4.des.no> In-Reply-To: <86wrry1hwv.fsf@ds4.des.no> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: geom@freebsd.org, hackers@freebsd.org Subject: Re: Support for WD Advanced Format disks X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2010 22:48:10 -0000 On 08/10/2010 13:44, Dag-Erling Smørgrav wrote: > Right now, I have two requests. The first is that people who have > Advanced Format disks run a program I wrote that measures the > performance of aligned and misaligned writes of different sizes. > > % svn co http://svn.freebsd.org/base/user/des/phybs > % cd phybs > % make > % ./phybs -w /dev/adN DES, On stable/8 this is needed to build. Seems the need for linking against libutil came in revision r211233. Index: Makefile =================================================================== --- Makefile (revision 211244) +++ Makefile (working copy) @@ -4,5 +4,6 @@ CSTD ?= c99 WARNS ?= 6 MAN = # none +LDFLAGS += -lutil .include Regards, -- jhell,v From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 13 00:54:11 2010 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 00E491065675 for ; Fri, 13 Aug 2010 00:54:11 +0000 (UTC) (envelope-from amdmi3@amdmi3.ru) Received: from smtp.timeweb.ru (smtp.timeweb.ru [92.53.116.15]) by mx1.freebsd.org (Postfix) with ESMTP id B1C528FC1F for ; Fri, 13 Aug 2010 00:54:10 +0000 (UTC) Received: from [213.148.20.85] (helo=hive.panopticon) by smtp.timeweb.ru with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71) (envelope-from ) id 1Ojhsk-0004EV-JX for freebsd-hackers@FreeBSD.org; Fri, 13 Aug 2010 04:12:22 +0400 Received: from hades.panopticon (hades.panopticon [192.168.0.32]) by hive.panopticon (Postfix) with ESMTP id 280FCB84D for ; Fri, 13 Aug 2010 04:12:22 +0400 (MSD) Received: by hades.panopticon (Postfix, from userid 1000) id 1EE7FB84E; Fri, 13 Aug 2010 04:12:22 +0400 (MSD) Date: Fri, 13 Aug 2010 04:12:22 +0400 From: Dmitry Marakasov To: freebsd-hackers@FreeBSD.org Message-ID: <20100813001222.GG1591@hades.panopticon> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Subject: Any way to fix '/usr/lib/libstdc++.so.6: version GLIBCXX_3.4.11 required by ... not found'? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2010 00:54:11 -0000 Hi! I'm trying to update graphics/lightspark-devel port to the latest version, and it's firefox plugin now doesn't load. The supposed reason for that is that the plugin is build with gcc 4.4+ (as it uses c++0x features), and firefox is built with our default gcc 4.2, thus libstdc++ versions doesn't match -> dlopen fails. LoadPlugin: failed to initialize shared library /usr/local/lib/browser_plugins/lightspark-devel/liblightsparkplugin.so [/usr/lib/libstdc++.so.6: version GLIBCXX_3.4.11 required by /usr/local/lib/browser_plugins/lightspark-devel/liblightsparkplugin.so not found] Is there a way to fix that, maybe some linker magic? -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amdmi3@amdmi3.ru ..: jabber: amdmi3@jabber.ru http://www.amdmi3.ru From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 13 03:07:52 2010 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A401E1065674 for ; Fri, 13 Aug 2010 03:07:52 +0000 (UTC) (envelope-from bf1783@googlemail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 3346F8FC1F for ; Fri, 13 Aug 2010 03:07:51 +0000 (UTC) Received: by wwe15 with SMTP id 15so1515923wwe.31 for ; Thu, 12 Aug 2010 20:07:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:reply-to:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=CyZN8512GL6ex1w9/5yDhM+1E1FdfihRoiMdJbymkRE=; b=peH/+tOVPRjrVEjZ6cSeLzt+ICnUq/+a/fMfM6Tovcc17gU6sNGJ8WprIGKB1P20Bx dTPYz7B4yLnq8AjeK0e2YGHys/pYpkpwGFalx71U0BEdf1oCynR5pw/UQXeGyDNYMlOV aEu2L9nocvC47UvcXNIbVkiIv6VCMqhnpy/DA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:reply-to:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; b=CpSEwjbaJUDbQVq1givsaSBb2x+fwxsXaAzEZuezzK3wl4J/ihJpmOIX6UEOzghlsp 8YnUiQoFXymckxSEzAiVlplwesVowzl0RkLHj+Qlx6kH73xHrcQmueqrnDDEtvNZ1tUm +8yy3P+yJ/WCO/dJyT8xslTS1mpNP/FwQaOUE= MIME-Version: 1.0 Received: by 10.227.128.13 with SMTP id i13mr946616wbs.31.1281668871000; Thu, 12 Aug 2010 20:07:51 -0700 (PDT) Received: by 10.216.183.212 with HTTP; Thu, 12 Aug 2010 20:07:50 -0700 (PDT) Date: Fri, 13 Aug 2010 03:07:50 +0000 Message-ID: From: "b. f." To: freebsd-hackers@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Dmitry Marakasov Subject: Re: Any way to fix '/usr/lib/libstdc++.so.6: version GLIBCXX_3.4.11 required by ... not found'? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bf1783@gmail.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2010 03:07:52 -0000 >I'm trying to update graphics/lightspark-devel port to the latest >version, and it's firefox plugin now doesn't load. The supposed reason >for that is that the plugin is build with gcc 4.4+ (as it uses c++0x >features), and firefox is built with our default gcc 4.2, thus libstdc++ >versions doesn't match -> dlopen fails. > >LoadPlugin: failed to initialize shared library /usr/local/lib/browser_plu= gins/lightspark->devel/liblightsparkplugin.so [/usr/lib/libstdc++.so.6: ver= sion GLIBCXX_3.4.11 required by >/usr/local/lib/browser_plugins/lightspark-= devel/liblightsparkplugin.so not found] > >Is there a way to fix that, maybe some linker magic? I don't know, since we don't have a dlmopen(). Have you tried using libmap.conf(5) to use the newer libraries in ${LOCALBASE}/lib/gcc44 , rather than their base system counterparts, for firefox? Or using wrappers that set LD_LIBMAP or LD_LIBRARY_PATH, to attain the same end? The newer libraries are supposed to be mostly backwards-compatible with the old. b. From owner-freebsd-hackers@FreeBSD.ORG Sat Aug 14 14:35:05 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 62B20106566B; Sat, 14 Aug 2010 14:35:05 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id BC8BD8FC1B; Sat, 14 Aug 2010 14:35:04 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o7EEWSun066021 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 14 Aug 2010 17:32:28 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id o7EEWSWI016405; Sat, 14 Aug 2010 17:32:28 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o7EEWPrT016404; Sat, 14 Aug 2010 17:32:25 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 14 Aug 2010 17:32:25 +0300 From: Kostik Belousov To: Marius Strobl Message-ID: <20100814143225.GA2396@deviant.kiev.zoral.com.ua> References: <20100806050633.GK14016@felucia.tataz.chchile.org> <20100806090404.GI22295@deviant.kiev.zoral.com.ua> <20100806110807.GA68489@alchemy.franken.de> <20100806111131.GN22295@deviant.kiev.zoral.com.ua> <20100807135939.GA875@alchemy.franken.de> <20100807180904.GZ22295@deviant.kiev.zoral.com.ua> <20100807193722.GB875@alchemy.franken.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XCIqNWEteo88hZlY" Content-Disposition: inline In-Reply-To: <20100807193722.GB875@alchemy.franken.de> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-2.2 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_50, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: kan@freebsd.org, FreeBSD Hackers , Jeremie Le Hen , nwhitehorn@freebsd.org Subject: Re: Avoiding sysctl at program startup using ELF aux vector (was: concurrent sysctl implementation) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Aug 2010 14:35:05 -0000 --XCIqNWEteo88hZlY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Aug 07, 2010 at 09:37:22PM +0200, Marius Strobl wrote: > On Sat, Aug 07, 2010 at 09:09:04PM +0300, Kostik Belousov wrote: > > On Sat, Aug 07, 2010 at 03:59:39PM +0200, Marius Strobl wrote: > > > On Fri, Aug 06, 2010 at 02:11:31PM +0300, Kostik Belousov wrote: > > > > On Fri, Aug 06, 2010 at 01:08:08PM +0200, Marius Strobl wrote: > > > > > On Fri, Aug 06, 2010 at 12:04:04PM +0300, Kostik Belousov wrote: > > > > > > On Fri, Aug 06, 2010 at 07:06:33AM +0200, Jeremie Le Hen wrote: > > > > > > > Hi Kib, > > > > > > >=20 > > > > > > > In-Reply-To: <20100629083901.GG13238@deviant.kiev.zoral.com.u= a> > > > > > > > On Tue, Jun 29, 2010 at 11:39:01AM +0300, Kostik Belousov wro= te: > > > > > > > > On Tue, Jun 29, 2010 at 10:26:39AM +0200, Marius Strobl wro= te: > > > > > > > > > On Mon, Jun 28, 2010 at 05:48:59PM +0300, Kostik Belousov= wrote: > > > > > > > > > > On Wed, Jun 23, 2010 at 11:09:59PM +0200, Jeremie Le He= n wrote: > > > > > > > > > > > Hi Kostik, > > > > > > > > > > >=20 > > > > > > > > > > > This patch seems to have faded out from memory. Is i= t possible to go > > > > > > > > > > > forward and commit it? > > > > > > > > > > I refreshed the patch. Hopefully, nobody will object, a= nd I commit it > > > > > > > > > > shortly. > > > > > > > > > >=20 > > > > > > > > > > >=20 > > > > > > > > > > > Thanks, > > > > > > > > > > > Regards. > > > > > > > > > > >=20 > > > > > > > > > > > On Sat, Jul 25, 2009 at 12:29:16AM +0300, Kostik Belo= usov wrote: > > > > > > > > > > > > Below is the prototype that seems to work for me bo= th with patched and > > > > > > > > > > > > old rtld on i386. Patch also contains bits for amd6= 4 that I did not > > > > > > > > > > > > tested yet. All other arches are not buildable for = now. > > > > > > > > > > > >=20 > > > > > > > > > > > > Patch completely eliminates sysctl syscalls from th= e rtld and libc > > > > > > > > > > > > startup. Without the patch, a single run of /bin/ls= did 6 sysctls, > > > > > > > > > > > > with the patch, no sysctls is queried at all. > > > > > > > > > > > >=20 > > > > > > > > > > Comparing with the originally posted patch, I added sup= port for all > > > > > > > > > > architectures, tested amd64 and ia32 on amd64, and conv= erted getpagesizes(3) > > > > > > > > > > that added two more startup sysctls. > > > > > > > > > >=20 > > > > > > > > > > Would be nice to get a testing for at least some !x86 a= rchitectures > > > > > > > > > > before the commit, I added some people who helped me in= past, to the Cc:. > > > > > > > > > >=20 > > > > > > > > >=20 > > > > > > > > > Doesn't look good on sparc64: > > > > > > > > > <...> > > > > > > > > > NFS ROOT: 192.168.1.40:/usr/data/nfsroot/sparc64 > > > > > > > > > dc1: link state changed to UP > > > > > > > > > pid 24 (ifconfig), uid 0: exited on signal 11 > > > > > > > > > Segmentation fault > > > > > > > > > Interface IP-Address Broadcast > > > > > > > > > pid 29 (rcorder), uid 0: exited on signal 11 > > > > > > > > > Segmentation fault > > > > > > > > > pid 30 (grep), uid 0: exited on signal 11 > > > > > > > > > Segmentation fault > > > > > > > > > pid 31 (rcorder), uid 0: exited on signal 11 > > > > > > > > > Segmentation fault > > > > > > > > > =20 > > > > > > > > > pid 32 (date), uid 0: exited on signal 11 > > > > > > > > > Segmentation fault > > > > > > > > > Jun 29 12:20:50 getty[36]: open /dev/ttyv3: No such file = or directory > > > > > > > > > <...> > > > > > > > > >=20 > > > > > > > > > Unfortunately, I currently lack the time to debug this. > > > > > > > >=20 > > > > > > > > Thank you. > > > > > > >=20 > > > > > > > Did yu have time to look at this problem? It would be nice t= o have this > > > > > > > in the tree. > > > > > >=20 > > > > > > I cannot move forward without the help from somebody having acc= ess to > > > > > > sparc64 system where the problem is reproducable. > > > > >=20 > > > > > Do you have a debug version of the patch which outputs the necess= ary > > > > > information? > > > >=20 > > > > I would suggest to build rtld and libc with debugging symbols and > > > > get full backtrace from the faults. > > >=20 > > > v100# gdb /sbin/ifconfig ifconfig.core > > > GNU gdb 6.1.1 [FreeBSD] > > > Copyright 2004 Free Software Foundation, Inc. > > > GDB is free software, covered by the GNU General Public License, and = you are > > > welcome to change it and/or distribute copies of it under certain con= ditions. > > > Type "show copying" to see the conditions. > > > There is absolutely no warranty for GDB. Type "show warranty" for de= tails. > > > This GDB was configured as "sparc64-marcel-freebsd"... > > > Core was generated by `ifconfig'. > > > Program terminated with signal 11, Segmentation fault. > > > Reading symbols from /lib/libbsdxml.so.4...done. > > > Loaded symbols for /lib/libbsdxml.so.4 > > > Reading symbols from /lib/libjail.so.1...done. > > > Loaded symbols for /lib/libjail.so.1 > > > Reading symbols from /lib/libsbuf.so.5...done. > > > Loaded symbols for /lib/libsbuf.so.5 > > > Reading symbols from /lib/libipx.so.5...done. > > > Loaded symbols for /lib/libipx.so.5 > > > Reading symbols from /lib/libc.so.7...done. > > > Loaded symbols for /lib/libc.so.7 > > > Reading symbols from /libexec/ld-elf.so.1...done. > > > Loaded symbols for /libexec/ld-elf.so.1 > > > #0 0x000000004089ebdc in getpagesizes (pagesize=3D0x7fdffffe2f8, nel= em=3D1) > > > at /usr/home/marius/co/head/src/lib/libc/gen/getpagesizes.c:75 > > > 75 while (nops > 0 && ps[nops - 1] =3D=3D 0) > > > (gdb) bt > > > #0 0x000000004089ebdc in getpagesizes (pagesize=3D0x7fdffffe2f8, nel= em=3D1) > > > at /usr/home/marius/co/head/src/lib/libc/gen/getpagesizes.c:75 > > > #1 0x00000000407f4314 in malloc_init () > > > at /usr/home/marius/co/head/src/lib/libc/stdlib/malloc.c:5418 > > > #2 0x00000000407f67d8 in malloc (size=3D32) > > > at /usr/home/marius/co/head/src/lib/libc/stdlib/malloc.c:5932 > > > #3 0x00000000001069ac in clone_setdefcallback (ifprefix=3D0x11b8a8 "= wlan",=20 > > > p=3D0x10a1a0 ) > > > at /usr/home/marius/co/head/src/sbin/ifconfig/ifclone.c:106 > > > #4 0x0000000000119864 in __do_global_ctors_aux () > > > #5 0x000000000010243c in _init () > > > #6 0x0000000000102508 in _start () > > > #7 0x000000004022719c in .rtld_start () > > > at /usr/home/marius/co/head/src/libexec/rtld-elf/sparc64/rtld_sta= rt.S:59 > > > #8 0x000000004022719c in .rtld_start () > > > at /usr/home/marius/co/head/src/libexec/rtld-elf/sparc64/rtld_sta= rt.S:59 > > > Previous frame identical to this frame (corrupt stack?) > > >=20 > > > All faults I've looked at died the same why. > > Thank you. I think I found the reason, which was an unitialized > > variable. I also fixed a sillyness with osrelver. > >=20 > > In the patched tree, there is tools/test/auxinfo that could be used to > > quick-check the system. > >=20 > > Updated patch is available at > > http://people.freebsd.org/~kib/misc/rtld_auxinfo.1.patch >=20 > I can confirm that this versions works on sparc64. After the discussion with Alexander, I made the change to allow libc to access aux vectors, instead of providing rtld interface to fetch values. I decided to keep the single function that fetch the values, because it is convenient place to do digesting of the vector. http://people.freebsd.org/~kib/misc/rtld_auxinfo.2.patch --XCIqNWEteo88hZlY Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkxmqPkACgkQC3+MBN1Mb4j+6gCfTZ5aD/p6z76uqmmeF2jgBRAk sSgAnRRO5YEW2w+Z31wwvUHc85LtQFlJ =aH4f -----END PGP SIGNATURE----- --XCIqNWEteo88hZlY-- From owner-freebsd-hackers@FreeBSD.ORG Sat Aug 14 17:30:58 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E1E47106566B for ; Sat, 14 Aug 2010 17:30:58 +0000 (UTC) (envelope-from prt@prt.org) Received: from smtp5.uk.umis.net (smtp5.uk.umis.net [217.65.166.40]) by mx1.freebsd.org (Postfix) with ESMTP id ACA968FC12 for ; Sat, 14 Aug 2010 17:30:58 +0000 (UTC) Received: from kate.prtsystems.ltd.uk ([217.65.165.35]) by smtp5.uk.umis.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1OkKZN-000ISz-4p for freebsd-hackers@freebsd.org; Sat, 14 Aug 2010 17:30:57 +0000 Message-ID: <4C66D2CF.9040408@prt.org> Date: Sat, 14 Aug 2010 18:30:55 +0100 From: Paul Thornton User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Problem detecting and reacting to serial break X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Aug 2010 17:30:59 -0000 Hi, I'm working on a small piece of code that reads a data stream from the serial port, putting it into a buffer for processing later - for those interested, it is receiving DMX512 lighting control data - but I'm having trouble with the detection of a break condition on the serial line. I'd appreciate any suggestions from anyone. I'm using 8.0-RELEASE with uftdi and ucom driving the serial port. The format of this data is very simple - a break is sent, followed by 513 bytes of useful information; then after some arbitrary delay another break, and the next 513 bytes. So, I think, easy to do this - just wait for a break and read away. My problem is that despite setting the port up (as I think) correctly, the break seems to be ignored at a driver level and it appears as data byte of 0x00 (what I'd expect to see if IGNBRK was set). This is no good as I have no way to know where I am in the chunk of 513 bytes of data, so can't synchronize at all. I have the following code setting up my serial port: tcgetattr(fd, &options); printf("before: c_iflag=%x c_oflag=%x c_cflag=%x c_lflag=%x\n", options.c_iflag, options.c_oflag, options.c_cflag, options.c_lflag); options.c_iflag = (BRKINT | IGNPAR); options.c_oflag = 0; options.c_cflag = (CLOCAL | CREAD | CS8 | CSTOPB); options.c_lflag = 0; options.c_cc[VMIN] = 513; options.c_cc[VTIME] = 0; if (cfsetispeed(&options, BAUDRATE) < 0) { perror("cfsetispeed"); exit(1); } if (cfsetospeed(&options, BAUDRATE) < 0) { perror("cfsetospeed"); exit(1); } if (tcsetattr(fd, TCSANOW, &options) < 0) { perror("tcsetattr"); exit(1); } /* debug test - did anything change? */ tcgetattr(fd, &options); printf("after: c_iflag=%x c_oflag=%x c_cflag=%x c_lflag=%x\n", options.c_iflag, options.c_oflag, options.c_cflag, options.c_lflag); The debug output shows my set is doing what I expect it to: before: c_iflag=2005 c_oflag=3 c_cflag=cf00 c_lflag=443 after: c_iflag=6 c_oflag=0 c_cflag=8f00 c_lflag=0 So according to the documentation, the effect of the break should be to flush the input and output buffers, and send a SIGINT to my process. The buffer doesn't seem to get flushed, and I don't get sent the SIGINT. The data I'm getting in my buffer is valid, apart from the fact that I can't tell where byte 1 is - and every time I run the test program the location of byte 1 changes arbitrarily depending on what was in the receive buffer. Have I missed something here, or is there any other way that I can detect the presence of the break out-of-band? I cannot make any assumptions about the 513 bytes that I'm receiving and any combination of data may be present in there. Many thanks, Paul. From owner-freebsd-hackers@FreeBSD.ORG Sat Aug 14 22:09:30 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DD648106564A for ; Sat, 14 Aug 2010 22:09:30 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from mx0.hoeg.nl (unknown [IPv6:2a01:4f8:101:5343::aa]) by mx1.freebsd.org (Postfix) with ESMTP id 7BD2B8FC15 for ; Sat, 14 Aug 2010 22:09:30 +0000 (UTC) Received: by mx0.hoeg.nl (Postfix, from userid 1000) id B8E572A28DBC; Sun, 15 Aug 2010 00:09:29 +0200 (CEST) Date: Sun, 15 Aug 2010 00:09:29 +0200 From: Ed Schouten To: Paul Thornton Message-ID: <20100814220929.GI2978@hoeg.nl> References: <4C66D2CF.9040408@prt.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lQSB8Tqijvu1+4Ba" Content-Disposition: inline In-Reply-To: <4C66D2CF.9040408@prt.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-hackers@freebsd.org Subject: Re: Problem detecting and reacting to serial break X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Aug 2010 22:09:30 -0000 --lQSB8Tqijvu1+4Ba Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Paul Thornton wrote: > I'm using 8.0-RELEASE with uftdi and ucom driving the serial port. Somewhat unrelated question: have you ever tried running the this code on 7.x? If so, did it work? --=20 Ed Schouten WWW: http://80386.nl/ --lQSB8Tqijvu1+4Ba Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iEYEARECAAYFAkxnFBkACgkQ52SDGA2eCwXRzACbBjPt6fWX5jXSmqoRX72K4RjM P00Aniq2z3znmRhVXCciYCXSgrYz7xrD =Bk6o -----END PGP SIGNATURE----- --lQSB8Tqijvu1+4Ba-- From owner-freebsd-hackers@FreeBSD.ORG Sat Aug 14 23:43:17 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 992BC1065697 for ; Sat, 14 Aug 2010 23:43:17 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id EDBA68FC08 for ; Sat, 14 Aug 2010 23:43:16 +0000 (UTC) Received: from ur.dons.net.au (ppp121-45-156-6.lns6.adl6.internode.on.net [121.45.156.6]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id o7ENh7ai093872 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 15 Aug 2010 09:13:13 +0930 (CST) (envelope-from doconnor@gsoft.com.au) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-33-726993049; protocol="application/pkcs7-signature"; micalg=sha1 From: "Daniel O'Connor" In-Reply-To: <4C66D2CF.9040408@prt.org> Date: Sun, 15 Aug 2010 09:13:07 +0930 Message-Id: References: <4C66D2CF.9040408@prt.org> To: Paul Thornton X-Mailer: Apple Mail (2.1081) X-Spam-Score: 0.163 () BAYES_00,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org Subject: Re: Problem detecting and reacting to serial break X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Aug 2010 23:43:17 -0000 --Apple-Mail-33-726993049 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 15/08/2010, at 3:00, Paul Thornton wrote: > So according to the documentation, the effect of the break should be = to > flush the input and output buffers, and send a SIGINT to my process. = The > buffer doesn't seem to get flushed, and I don't get sent the SIGINT. It does sounds like it's ignoring your request :( However you won't get a SIGINT unless the serial port is the controlling = terminal of your process (which it won't be if you just open()'d it) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --Apple-Mail-33-726993049--