From owner-freebsd-hackers@FreeBSD.ORG Sun Aug 1 01:26:18 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 6F1AF106564A; Sun, 1 Aug 2010 01:26:18 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 156898FC1F; Sun, 1 Aug 2010 01:26:17 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEALJjVEyDaFvO/2dsb2JhbACDE54FrRmQSYEmgyBzBIh/ X-IronPort-AV: E=Sophos;i="4.55,296,1278302400"; d="scan'208";a="86942942" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 31 Jul 2010 20:57:42 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id DD135B3EA2; Sat, 31 Jul 2010 20:57:42 -0400 (EDT) Date: Sat, 31 Jul 2010 20:57:42 -0400 (EDT) From: Rick Macklem To: krad Message-ID: <995936398.215591.1280624262743.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [24.65.230.102] X-Mailer: Zimbra 6.0.7_GA_2476.RHEL4 (ZimbraWebClient - FF3.0 (Mac)/6.0.7_GA_2473.RHEL4_64) Cc: freebsd-hackers@freebsd.org, FreeBSD Questions Subject: Re: possible NFS lockups 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, 01 Aug 2010 01:26:18 -0000 > From: "krad" > To: freebsd-hackers@freebsd.org, "FreeBSD Questions" > Sent: Tuesday, July 27, 2010 11:29:20 AM > Subject: possible NFS lockups > I have a production mail system with an nfs backend. Every now and > again we > see the nfs die on a particular head end. However it doesn't die > across all > the nodes. This suggests to me there isnt an issue with the filer > itself and > the stats from the filer concur with that. > > The symptoms are lines like this appearing in dmesg > > nfs server 10.44.17.138:/vol/vol1/mail: not responding > nfs server 10.44.17.138:/vol/vol1/mail: is alive again > > trussing df it seems to hang on getfsstat, this is presumably when it > tries > the nfs mounts > > eg > > __sysctl(0xbfbfe224,0x2,0xbfbfe22c,0xbfbfe230,0x0,0x0) = 0 (0x0) > mmap(0x0,1048576,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = > 1746583552 (0x681ac000) > mmap(0x682ac000,344064,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) > = > 1747632128 (0x682ac000) > munmap(0x681ac000,344064) = 0 (0x0) > getfsstat(0x68201000,0x1270,0x2,0xbfbfe960,0xbfbfe95c,0x1) = 9 (0x9) > > > I have played with mount options a fair bit but they dont make much > difference. This is what they are set to at present > > 10.44.17.138:/vol/vol1/mail /mail/0 nfs > rw,noatime,tcp,acdirmax=320,acdirmin=180,acregmax=320,acregmin=180 0 0 > > When this locking is occuring I find that if I do a show mount or > mount > 10.44.17.138:/vol/vol1/mail again under another mount point I can > access it > fine. > > One thing I have just noticed is that lockd and statd always seem to > have > died when this happens. Restarting does not help > > lockd and statd implement separate protocols (NLM ans NSM) that do locking. The protocols were poorly designed and fundamentally broken imho. (That refers to the protocols and not the implementation.) I am not familiar with the lockd and statd implementations, but if you don't need file locking to work for the same file when accessed concurrently from multiple clients (heads) concurrently, you can use the "nolockd" mount option to avoid using them. (I have no idea if the mail system you are using will work without lockd or not? It should be ok to use "nolockd" if file locking is only done on a given file in one client node.) I suspect that some interaction between your server and the lockd/statd client causes them to crash and then the client is stuck trying to talk to them, but I don't really know? Looking at where all the processes and threads are sleeping via "ps axlH" may tell you what is stuck and where. As others noted, intermittent "server not responding...server ok" messages just indicate slow response from the server and don't mean much. However, if a given process is hung and doesn't recover, knowing what it is sleeping on can help w.r.t diagnosis. rick From owner-freebsd-hackers@FreeBSD.ORG Sun Aug 1 23:11: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 7B11E1065674; Sun, 1 Aug 2010 23:11:58 +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 214A28FC1A; Sun, 1 Aug 2010 23:11:57 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEAB6cVUyDaFvO/2dsb2JhbACDE51zrjuQVYEmgU2BU3MEiH8 X-IronPort-AV: E=Sophos;i="4.55,299,1278302400"; d="scan'208";a="89147536" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 01 Aug 2010 19:11:57 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 17E46B3EA3; Sun, 1 Aug 2010 19:11:57 -0400 (EDT) Date: Sun, 1 Aug 2010 19:11:57 -0400 (EDT) From: Rick Macklem To: "Sam Fourman Jr." Message-ID: <1754387280.221911.1280704316965.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit 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, krad , FreeBSD Questions Subject: Re: possible NFS lockups 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, 01 Aug 2010 23:11:58 -0000 > From: "Sam Fourman > On Tue, Jul 27, 2010 at 10:29 AM, krad wrote: > > I have a production mail system with an nfs backend. Every now and > > again we > > see the nfs die on a particular head end. However it doesn't die > > across all > > the nodes. This suggests to me there isnt an issue with the filer > > itself and > > the stats from the filer concur with that. > > > > The symptoms are lines like this appearing in dmesg > > > > nfs server 10.44.17.138:/vol/vol1/mail: not responding > > nfs server 10.44.17.138:/vol/vol1/mail: is alive again > > > > trussing df it seems to hang on getfsstat, this is presumably when > > it tries > > the nfs mounts > > > > I also have this problem, where nfs locks up on a FreeBSD 9 server > and a FreeBSD RELENG_8 client > If by RELENG_8, you mean 8.0 (or pre-8.1), there are a number of patches for the client side krpc. They can be found at: http://people.freebsd.org/~rmacklem/freebsd8.0-patches (These are all in FreeBSD8.1, so ignore this if your client is already running FreeBSD8.1.) rick ps: "lock up" can mean many things. The more specific you can be w.r.t. the behaviour, the more likely it can be resolved. For example: - No more access to the subtree under the mount point is possible until the client is rebooted. When a "ps axlH" one process that was accessing a file in the mount point is shown with WCHAN rpclock and STAT DL. vs - All access to the mount point stops for about 1minute and then recovers. Also, showing what mount options are being used by the client and whether or not rpc.lockd and rpc.statd are running can also be useful. And if you can look at the net ttraffic with wireshark when it is locked up and see if any NFS traffic is happening can also be useful. From owner-freebsd-hackers@FreeBSD.ORG Sun Aug 1 19:45:48 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 858BF106566C for ; Sun, 1 Aug 2010 19:45:48 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout1.yahoo.com (mrout1.yahoo.com [216.145.54.171]) by mx1.freebsd.org (Postfix) with ESMTP id 6DEA78FC1E for ; Sun, 1 Aug 2010 19:45:48 +0000 (UTC) Received: from [127.0.0.1] (proxy8.corp.yahoo.com [216.145.48.13]) by mrout1.yahoo.com (8.13.8/8.13.8/y.out) with ESMTP id o71JjVij095595; Sun, 1 Aug 2010 12:45:31 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=subject:from:to:cc:in-reply-to:references:content-type:date: message-id:mime-version:x-mailer:content-transfer-encoding; b=G29h1uZp6b7jpYpyxtf1KRUq4YGxVGYDVfJOL++Ps8YzHv+sY1JSi9gakCG3u7Cs From: Sean Bruno To: Ed Maste In-Reply-To: <20100729210622.GA84094@sandvine.com> References: <201007281510.o6SFAV5J052045@svn.freebsd.org> <20100729210622.GA84094@sandvine.com> Content-Type: text/plain; charset="UTF-8" Date: Sun, 01 Aug 2010 12:45:30 -0700 Message-ID: <1280691930.6985.2.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 (2.28.3-1.fc12) Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 01 Aug 2010 23:17:21 +0000 Cc: "freebsd-hackers@freebsd.org" Subject: Re: svn commit: r210561 - projects/sv/sys/net 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, 01 Aug 2010 19:45:48 -0000 On Thu, 2010-07-29 at 14:06 -0700, Ed Maste wrote: > On Wed, Jul 28, 2010 at 03:10:31PM +0000, Attilio Rao wrote: > > > Log: > > Initial import of the netdump files. > > They still need a lot of polishing and cleanup so they might not be > > considered definitive at all. > > This code is a port to recent FreeBSD of Darrell Anderson's network > crashdump support, which was done in the 4.x days. I can't find a > current website with the original versions but archive.org has a cache > of course: > > http://web.archive.org/web/20041204223729/http://www.cs.duke.edu/~anderson/freebsd/netdump/ > > Quoting from the old readme: > > Netdump provides FreeBSD kernel crash dumping over the network. > Netdump is a FreeBSD kernel module client and user-level server. > > A normal kernel crash writes a raw dump of memory to a dedicated > partition (usually the swap partition) using a low-level disk routine, > and then copies that raw dump into a file (via savecore) during the > following boot process. > > Netdump replaces the standard dump routine. During a crash, a netdump > client broadcasts to locate a netdump server, then sends the dump as > UDP/IP packets (with retransmission after loss). The netdump server > creates a dump file suitable for gdb. If netdump fails (for example, > no netdump server is located), a normal disk dump is performed. > > There is cleanup work to be done still, but we plan to have this in > shape for 9.0. > > -Ed > _______________________________________________ Excellent. I'll start tracking this over here at Yahoo. Sean From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 2 09:53:03 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 8BE031065679; Mon, 2 Aug 2010 09:53:03 +0000 (UTC) (envelope-from jh@FreeBSD.org) Received: from gw01.mail.saunalahti.fi (gw01.mail.saunalahti.fi [195.197.172.115]) by mx1.freebsd.org (Postfix) with ESMTP id 1079C8FC1C; Mon, 2 Aug 2010 09:53:02 +0000 (UTC) Received: from a91-153-117-195.elisa-laajakaista.fi (a91-153-117-195.elisa-laajakaista.fi [91.153.117.195]) by gw01.mail.saunalahti.fi (Postfix) with SMTP id AA17D1514C8; Mon, 2 Aug 2010 12:52:56 +0300 (EEST) Date: Mon, 2 Aug 2010 12:52:56 +0300 From: Jaakko Heinonen To: Bruce Evans Message-ID: <20100802095255.GA1122@a91-153-117-195.elisa-laajakaista.fi> References: <20100721072225.GA1102@a91-153-117-195.elisa-laajakaista.fi> <20100721185227.N7492@delplex.bde.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100721185227.N7492@delplex.bde.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Garrett Cooper , standards@freebsd.org, hackers@freebsd.org Subject: Re: Chasing down bugs with access(2) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2010 09:53:03 -0000 On 2010-07-21, Bruce Evans wrote: > > See PR kern/125009 (http://www.freebsd.org/cgi/query-pr.cgi?pr=125009). > > I looked at the patches in the PR. It seems reasonable to require an X > but for VEXEC for all file types except directories, like I think the > vaccess() version of your patch does. Thanks for looking at. Both patches require it for non-directories only. I have updated the vaccess*() version of the patch. It now preserves the check in exec_check_permissions() to avoid causing regressions for file systems which are not using vaccess*() functions. %%% Index: sys/kern/kern_exec.c =================================================================== --- sys/kern/kern_exec.c (revision 210492) +++ sys/kern/kern_exec.c (working copy) @@ -1328,13 +1328,13 @@ exec_check_permissions(imgp) /* * 1) Check if file execution is disabled for the filesystem that this * file resides on. - * 2) Insure that at least one execute bit is on - otherwise root + * 2) Ensure that at least one execute bit is on - otherwise root * will always succeed, and we don't want to happen unless the * file really is executable. - * 3) Insure that the file is a regular file. + * 3) Ensure that the file is a regular file. */ if ((vp->v_mount->mnt_flag & MNT_NOEXEC) || - ((attr->va_mode & 0111) == 0) || + (attr->va_mode & (S_IXUSR | S_IXGRP | S_IXOTH)) == 0 || (attr->va_type != VREG)) return (EACCES); Index: sys/kern/vfs_subr.c =================================================================== --- sys/kern/vfs_subr.c (revision 210492) +++ sys/kern/vfs_subr.c (working copy) @@ -3600,8 +3600,14 @@ privcheck: !priv_check_cred(cred, PRIV_VFS_LOOKUP, 0)) priv_granted |= VEXEC; } else { + /* + * Ensure that at least one execute bit is on - otherwise + * privileged user will always succeed, and we don't want to + * happen unless the file really is executable. + */ if ((accmode & VEXEC) && ((dac_granted & VEXEC) == 0) && - !priv_check_cred(cred, PRIV_VFS_EXEC, 0)) + !priv_check_cred(cred, PRIV_VFS_EXEC, 0) && + (file_mode & (S_IXUSR | S_IXGRP | S_IXOTH)) != 0) priv_granted |= VEXEC; } Index: sys/kern/subr_acl_posix1e.c =================================================================== --- sys/kern/subr_acl_posix1e.c (revision 210492) +++ sys/kern/subr_acl_posix1e.c (working copy) @@ -90,8 +90,14 @@ vaccess_acl_posix1e(enum vtype type, uid PRIV_VFS_LOOKUP, 0)) priv_granted |= VEXEC; } else { + /* + * Ensure that at least one execute bit is on - otherwise + * privileged user will always succeed, and we don't want to + * happen unless the file really is executable. + */ if ((accmode & VEXEC) && !priv_check_cred(cred, - PRIV_VFS_EXEC, 0)) + PRIV_VFS_EXEC, 0) && (acl_posix1e_acl_to_mode(acl) & + (S_IXUSR | S_IXGRP | S_IXOTH)) != 0) priv_granted |= VEXEC; } Index: sys/kern/subr_acl_nfs4.c =================================================================== --- sys/kern/subr_acl_nfs4.c (revision 210492) +++ sys/kern/subr_acl_nfs4.c (working copy) @@ -162,6 +162,7 @@ vaccess_acl_nfs4(enum vtype type, uid_t accmode_t priv_granted = 0; int denied, explicitly_denied, access_mask, is_directory, must_be_owner = 0; + mode_t file_mode = 0; KASSERT((accmode & ~(VEXEC | VWRITE | VREAD | VADMIN | VAPPEND | VEXPLICIT_DENY | VREAD_NAMED_ATTRS | VWRITE_NAMED_ATTRS | @@ -236,8 +237,15 @@ vaccess_acl_nfs4(enum vtype type, uid_t PRIV_VFS_LOOKUP, 0)) priv_granted |= VEXEC; } else { + /* + * Ensure that at least one execute bit is on - otherwise + * privileged user will always succeed, and we don't want to + * happen unless the file really is executable. + */ + acl_nfs4_sync_mode_from_acl(&file_mode, aclp); if ((accmode & VEXEC) && !priv_check_cred(cred, - PRIV_VFS_EXEC, 0)) + PRIV_VFS_EXEC, 0) && (file_mode & + (S_IXUSR | S_IXGRP | S_IXOTH)) != 0) priv_granted |= VEXEC; } Index: sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c =================================================================== --- sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c (revision 210492) +++ sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c (working copy) @@ -4193,6 +4193,9 @@ zfs_freebsd_access(ap) struct thread *a_td; } */ *ap; { + vnode_t *vp = ap->a_vp; + znode_t *zp = VTOZ(vp); + znode_phys_t *zphys = zp->z_phys; accmode_t accmode; int error = 0; @@ -4209,16 +4212,20 @@ zfs_freebsd_access(ap) if (error == 0) { accmode = ap->a_accmode & ~(VREAD|VWRITE|VEXEC|VAPPEND); if (accmode != 0) { - vnode_t *vp = ap->a_vp; - znode_t *zp = VTOZ(vp); - znode_phys_t *zphys = zp->z_phys; - error = vaccess(vp->v_type, zphys->zp_mode, zphys->zp_uid, zphys->zp_gid, accmode, ap->a_cred, NULL); } } + /* + * For VEXEC, ensure that at least one execute bit is set for + * non-directories. + */ + if (error == 0 && (ap->a_accmode & VEXEC) != 0 && vp->v_type != VDIR && + (zphys->zp_mode & (S_IXUSR | S_IXGRP | S_IXOTH)) == 0) + error = EACCES; + return (error); } %%% -- Jaakko From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 2 08:09:30 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 7DEBF106564A for ; Mon, 2 Aug 2010 08:09:30 +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 446CD8FC0C for ; Mon, 2 Aug 2010 08:09:30 +0000 (UTC) Received: by iwn35 with SMTP id 35so5124857iwn.13 for ; Mon, 02 Aug 2010 01:09:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=dB0R4UQDKDwjUqfxVPrSeKNgFfnQDfNC/Np8npthjrk=; b=Hv3E3d+vYdMGmCYIGrfCmLuQ9bLf1uyFWLo3pZpbMhz3sJRd+ooh94BNJwfuaiLoJC obUsusyVY+/AAHI6uDCK6phBocpeOQIxNYpIkzfeMkpjiuxeC+Xm5w0Sx2VrbqEUjROx 7AwzvEB0EXy6SqpvqStR12DTez37FUF2ALeh8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=X1fVnYb3QgU61vhcjAf0QVVVjkCwNTIHrzjHH+huHRmO8nFsNjbXI0FjkJM2NJZV0j wr3z4dFzi4CbV6bq1PXHMmdYX2NhnnjVrTd7O8rARGIRFOdwdrqHOn8+IcFa+hNreSBd 6cdQV26Oixxy2z0xt+Dxl3eQ1K57Aht7nayxo= MIME-Version: 1.0 Received: by 10.231.174.65 with SMTP id s1mr6723403ibz.3.1280736569609; Mon, 02 Aug 2010 01:09:29 -0700 (PDT) Received: by 10.231.187.104 with HTTP; Mon, 2 Aug 2010 01:09:29 -0700 (PDT) In-Reply-To: References: Date: Mon, 2 Aug 2010 01:09:29 -0700 Message-ID: From: Garrett Cooper To: hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Mon, 02 Aug 2010 11:16:45 +0000 Cc: Subject: Re: nanosleep - does it make sense with tv_sec < 0? 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, 02 Aug 2010 08:09:30 -0000 On Wed, Jul 28, 2010 at 11:01 PM, Garrett Cooper wrote= : > Hi Hackers, > =A0 =A0I ran into an oddity with the POSIX spec that seems a bit unrealis= tic: > > [EINVAL] > =A0 =A0The rqtp argument specified a nanosecond value less than zero or > greater than or equal to 1000 million. > > =A0 =A0Seems like it should also apply for seconds < 0. We current > silently pass this argument in kern/kern_time.c:kern_nanosleep: > > int > kern_nanosleep(struct thread *td, struct timespec *rqt, struct timespec *= rmt) > { > =A0 =A0 =A0 =A0struct timespec ts, ts2, ts3; > =A0 =A0 =A0 =A0struct timeval tv; > =A0 =A0 =A0 =A0int error; > > =A0 =A0 =A0 =A0if (rqt->tv_nsec < 0 || rqt->tv_nsec >=3D 1000000000) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return (EINVAL); > =A0 =A0 =A0 =A0if (rqt->tv_sec < 0 || (rqt->tv_sec =3D=3D 0 && rqt->tv_ns= ec =3D=3D > 0)) // <-- first clause here > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return (0); > > =A0 =A0but I'm wondering whether or not it makes logical sense for us to > do this (sleep for a negative amount of time?)... > =A0 =A0FWIW Linux returns -1 and sets EINVAL in this case, which makes > more sense to me. After talking with the Austin Group folks, this appears to be an [optional] implementation detail with the fact that our time_t is signed. I think that this patch is valid for catching this case, because sleeping negative time doesn't seem logical... Thanks, -Garrett Index: lib/libc/sys/nanosleep.2 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- lib/libc/sys/nanosleep.2 (revision 210226) +++ lib/libc/sys/nanosleep.2 (working copy) @@ -87,19 +87,20 @@ .It Bq Er EINTR The .Fn nanosleep -system call -was interrupted by the delivery of a signal. +system call was interrupted by the delivery of a signal. .It Bq Er EINVAL The .Fa rqtp -argument -specified a nanosecond value less than zero +argument specified a nanosecond value less than zero or greater than or equal to 1000 million. +.It Bq Er EINVAL +The +.Fa rqtp +argument specified a second value less than zero. .It Bq Er ENOSYS The .Fn nanosleep -system call -is not supported by this implementation. +system call is not supported by this implementation. .El .Sh SEE ALSO .Xr sigsuspend 2 , Index: sys/kern/kern_time.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/kern/kern_time.c (revision 210226) +++ sys/kern/kern_time.c (working copy) @@ -358,7 +358,9 @@ if (rqt->tv_nsec < 0 || rqt->tv_nsec >=3D 1000000000) return (EINVAL); - if (rqt->tv_sec < 0 || (rqt->tv_sec =3D=3D 0 && rqt->tv_nsec =3D=3D 0)) + if (rqt->tv_sec < 0) + return (EINVAL); + if (rqt->tv_sec =3D=3D 0 && rqt->tv_nsec =3D=3D 0) return (0); getnanouptime(&ts); timespecadd(&ts, rqt); From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 2 14:21: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 E15B1106567A for ; Mon, 2 Aug 2010 14:21:39 +0000 (UTC) (envelope-from fabiokaminski@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 8C4AC8FC1A for ; Mon, 2 Aug 2010 14:21:39 +0000 (UTC) Received: by qwk3 with SMTP id 3so1862310qwk.13 for ; Mon, 02 Aug 2010 07:21:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=V0oI08PDx7RVBzHUqN06PEgm4X12ws+Kb5tWLnhlH/U=; b=Jczusre1KTlc1BqyR7pE/q6Bi4TrLtY+RMKrgJN3hvmHWClWML/Motm7x1xjh+j5qC QUbK2wSA16czR5sEi5T+b6IeWTPbAuQY8wOZl1rJLvZAfFYsJDuW4ElvR/N06obaKB8/ /WLqFFgE5EyY8XSCb2dxfeKZa+6/1fiWLjzKc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=tpjsn1H6CUcoYFZm6AiyoY68B2PnKU0qLDs95CvlynplE2B0OPOPU49Wx/msuyRbtp 6ztQSggQW96hfbqo6CaPB7e7Zr0tXTjUVsTQVvSuxzL25xGLg4n+usvVI6xQ6JJyvUwY /PT+9X/ckYIRzEki9LZH7EWGJm5o4nbzRKhBU= MIME-Version: 1.0 Received: by 10.229.219.139 with SMTP id hu11mr115500qcb.103.1280758898634; Mon, 02 Aug 2010 07:21:38 -0700 (PDT) Received: by 10.231.207.15 with HTTP; Mon, 2 Aug 2010 07:21:38 -0700 (PDT) In-Reply-To: References: <201007311206.o6VC6rdn023424@fire.js.berklix.net> <4C54154A.9040306@gmail.com> Date: Mon, 2 Aug 2010 11:21:38 -0300 Message-ID: From: Fabio Kaminski To: Ali Mashtizadeh Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "Julian H. Stacey" , hackers@freebsd.org Subject: Re: freebsd exokernel 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, 02 Aug 2010 14:21:40 -0000 Ali, thanks for pointing Corey, in fact im already studying its source ... thi= s core aware architecture , and share nothing mechanisms are just brilliant, each core running its own tcp stack, while it has one core exclusive for the device pooling its great... is jails working that way? Ow, errata about L4 , in fact it is an exokernel an it has a "OSLib".. i found OC.fiasco, a pitty is that it uses c++ and it gets harder to collaborate with the large operating system C stacks. i was pointed to the rump project from netbsd too http://www.netbsd.org/docs/rump/index.html, and is a oslib.. very nice! thanks everybody, for the help an tips! Fabio Kaminski On Sat, Jul 31, 2010 at 5:50 PM, Ali Mashtizadeh wro= te: > Hi Fabio, > > Exokernels are great operating systems for prototyping or learning. > You obviously incur a lot more performance hits when you implement > such an architecture. I haven't looked into the details of > DragonflyBSD too much but they have enough infrastructure to run a > userlevel kernel that is sort of paravirtualized. From what I've read > it seems it has enough infrastructure for you to use the platform as > an exokernel without too much modification. Might be a good starting > point for you. > > In addition to the original exokernel work from MIT you might want to > check out corey which has some interesting work on multicore > scalability. > http://pdos.csail.mit.edu/corey/ > > Thanks, > ~ Ali > > On Sat, Jul 31, 2010 at 11:32 AM, Fabio Kaminski > wrote: > > yes , i have snifed the mach.. but i dont like the message passing idea= .. > > its from the microkernel species > > and theres even a nouveau reincarnation called barrelfish > > http://www.barrelfish.org .. wich is a sort of microkernel but running > one > > kernel core nucleus for each core and message passing each other.. (thi= s > is > > very promissing for virtualization.. but monolitic still be the fastest= ) > > > > its more like this L4 kernel.. good link indeed.... but with security > > included.. in fact the original mit exokernel its more like a resource > > policy system... http://en.wikipedia.org/wiki/Exokernel > > > > and i think they solve the problem that L4 has, that you are left alone= .. > > and the applications are obligated to implement thought parts by > > themselfs.. putting the abstractions in the userland as libraries.. so = if > > you want user ZFS ,Bsd VMM, Btrfs or create your own abstraction or mix > > some, its just link with the proper .so file.. without needing to creat= e > a > > half kernel/half app application.. > > > > thanks for the links > > > > On Sat, Jul 31, 2010 at 9:21 AM, CDP wrote: > > > >> On 07/31/10 15:06, Julian H. Stacey wrote: > >> > >>> would it be a feasible project to borrow things from freebsd, and sta= rt > a > >>>> project like this? anyone like this idea ?? > >>>> > >>> > >>> The code is free to use :-) > >>> > >>> anyway, just some thoughts for now.. > >>>> > >>> > >>> See also eg Mach. > >>> http://en.wikipedia.org/wiki/Mach > >>> http://en.wikipedia.org/wiki/Mach_%28kernel%29 > >>> > >> > >> Add this to the list (have a look at the external links too): > >> http://en.wikipedia.org/wiki/L4_microkernel_family > >> > >> You might also want to look at this: > >> http://os.inf.tu-dresden.de/L4/LinuxOnL4/overview.shtml > >> > >> Regards, > >> Claudiu. > >> > > _______________________________________________ > > 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" > > > > > > -- > Ali Mashtizadeh > =D8=B9=D9=84=DB=8C =D9=85=D8=B4=D8=AA=DB=8C =D8=B2=D8=A7=D8=AF=D9=87 > From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 2 22:44:15 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 5AE121065676 for ; Mon, 2 Aug 2010 22:44:15 +0000 (UTC) (envelope-from guy.helmer@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id E8CFD8FC19 for ; Mon, 2 Aug 2010 22:44:14 +0000 (UTC) Received: by wyj26 with SMTP id 26so4631466wyj.13 for ; Mon, 02 Aug 2010 15:44:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=SQLsGG7d2VK7fwKvxSwkEARxReiCYgkRuYNO9+fipEU=; b=uH/UEal6N8qRvk/XC5McjYT9YJben6LRNjplCVVB8ODF6OUpWpR8aTIPHxCxSuP/oV HfOfIFRj+C5uDFu1V7nKIwSqmP9BfZOWd+HIHkF+2zSElEwIvRlfoige/BRoizvNg6G9 oLvS49ihqO/R3ZAWZe/PaWNC+vMjeNwp0jYBk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=SetNAmXjibFCD3DS49kWfBGjeiUmRJwph1bU0Sz9tVptKkJFyBNfinFdWd+lBUdiK/ MnRL6FFr3WtjALYBolqH8r0t7lmG0KT+m7HfsXEMM2dS8EjanXGHhU1eP92b/+iV1tdd 4bNpGW3joNb1/FB+ap2zpBqQexpCQnYZKm4Y0= MIME-Version: 1.0 Received: by 10.216.89.149 with SMTP id c21mr5505061wef.73.1280787230435; Mon, 02 Aug 2010 15:13:50 -0700 (PDT) Received: by 10.216.126.13 with HTTP; Mon, 2 Aug 2010 15:13:50 -0700 (PDT) Date: Mon, 2 Aug 2010 17:13:50 -0500 Message-ID: From: Guy Helmer To: freebsd-hackers@freebsd.org X-Mailman-Approved-At: Mon, 02 Aug 2010 22:53:01 +0000 Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Puzzling performance 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, 02 Aug 2010 22:44:15 -0000 On a FreeBSD 7.1 SCHED_ULE kernel, I have a large number of files opened and mmapped (with MAP_NOSYNC option) for shared-memory communication between processes. Normally, memcpy() copies data into these shared-memory buffers in a reasonable amount of time closely related to the size of the copy (roughly 10us per 10KB). However, due to performance issues I've found that sometimes a memcpy() takes an abnormally long time (10ms for 40KB, and I suspect longer times occurring when I have not had monitoring enabled). The system doesn't seem to be in memory overcommit -- there is just a minor amount of swap in use, and I've not seen page-ins or page-outs while watching systat or vmstat. Since I'm using MAP_NOSYNC, I would not expect the pager to flush dirty pages to disk and cause add delays. Any ideas where to look? Might it help to pin threads to CPUs in case a thread is getting moved to a different core? Thanks, Guy From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 3 11:15: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 6EBA01065695 for ; Tue, 3 Aug 2010 11:15:11 +0000 (UTC) (envelope-from osharoiko@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 EDC3E8FC13 for ; Tue, 3 Aug 2010 11:15:08 +0000 (UTC) Received: by iwn35 with SMTP id 35so824063iwn.13 for ; Tue, 03 Aug 2010 04:15:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=rThOGlCZXt8xl/vmCncIfvNAXHDczqPNaQvLA7WTkyA=; b=u/DvEufLzPkNkxmfKsDl0rmdNXpdwwVPwDhdDmiOxv9hP/gEP31Svwpxop8lGehvA+ 5NeoVPMMQkzdSeSBTmVpy79CzZfSR3YBYW9e4R4BIcF2NCgEOsrWMMACfEq3y30/sO/f V146tm0ci0Lc4HUH6LejAqmFNDsMQptO+H4+U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=E4hr9QDP5my5IjMKdJ6dLQWhkp7aG92nukFacTkQ6Zo0lFQT3XryCz2rwLvRJJv1GD CG13mICrhSGLkYksHfJjZ+pE+pPg1qZGwi3G/U9oZirCuQWJ0aVRJYnjItICrh5eZiVy IWqL6fvJf9jjiJ3Oc+NCze1sXaOWyAUdPApfw= MIME-Version: 1.0 Received: by 10.231.39.137 with SMTP id g9mr8421553ibe.133.1280832548013; Tue, 03 Aug 2010 03:49:08 -0700 (PDT) Received: by 10.231.168.20 with HTTP; Tue, 3 Aug 2010 03:49:07 -0700 (PDT) Date: Tue, 3 Aug 2010 14:49:07 +0400 Message-ID: From: Oleg Sharoyko To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 Subject: PCI config space is not restored upon resume (macbook pro) 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, 03 Aug 2010 11:15:11 -0000 Hi! I'm trying to make FreeBSD (9-Current, checkout on 2010-08-01) correctly suspend/resume on macbook pro. As of now I have to issues with resume: 1. Display stays blank upon resume. Got 'vga0: failed to reload state' in dmesg, but I haven't looked into this yet. 2. Some hardware is missing upon resume, specifically ath, msk and firewire. This devices disappear because rather strange values are being read from pci config space (such as vendor id, device id and others). This is how it looks when system boots: pci11: on pcib4 pci11: domain=0, physical bus=11 pcib4: pci_read_device: before if pcib4: pci_read_device: in if() pcib4: pci_read_device subvendor: 106b, vendor: 168c, device: 0024 pcib4: pci_read_device: after if() unknown: pci_cfg_save: subvendor: 106b, vendor: 168c, device: 0024 unknown: pci_cfg_restore: subvendor: 106b, vendor: 168c, device: 0024 found-> vendor=0x168c, dev=0x0024, revid=0x01 domain=0, bus=11, slot=0, func=0 class=02-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=7 powerspec 2 supports D0 D1 D3 current D0 MSI supports 1 message MSI-X supports 1 message in map 0x10 map[10]: type Memory, range 64, base 0x97300000, size 16, enabled pcib4: requested memory range 0x97300000-0x9730ffff: good pcib4: matched entry for 11.0.INTA pcib4: slot 0 INTA hardwired to IRQ 16 ath0: mem 0x97300000-0x9730ffff irq 16 at device 0.0 on pci11 everything as usual except for some debugging printfs I have added to the kernel. And here what I have upon resume: pci_resume: before restore pci0:11:0:0: Transition from D3 to D0 unknown: pci_cfg_restore: subvendor: 106b, vendor: 168c, device: 0024 pci_resume: before if pci_resume: in if unknown: pci_cfg_save: subvendor: ffff, vendor: ffff, device: ffff pci_resume: after if [some lines are skipped, please see [1] for a link to complete output of dmesg] pci11: driver added found-> vendor=0xffff, dev=0xffff, revid=0xff domain=0, bus=11, slot=0, func=0 class=ff-ff-ff, hdrtype=0x00, mfdev=0 cmdreg=0xffff, statreg=0x0010, cachelnsz=255 (dwords) lattimer=0xff (7650 ns), mingnt=0xff (63750 ns), maxlat=0xff (63750 ns) intpin=_, irq=255 powerspec 2 supports D0 D1 D3 current D3 MSI supports 1 message MSI-X supports 1 message in map 0x10 pci0:11:0:0: reprobing on driver added pci0:11:0:0: Transition from D3 to D0 unknown: pci_cfg_restore: subvendor: ffff, vendor: ffff, device: ffff unknown: pci_cfg_save: subvendor: ffff, vendor: ffff, device: ffff As far as I can see pci_resume() (from dev/pci/pci.c) tries to write saved values of pci config space and calls pci_cfg_restore() to achieve this. pci_cfg_restore() inded writes correct values to pci config space. But the next attempt to read these just written value returns incorrect data. What else can I do to understand and solve this issue? I would appreciate any help. Thank you! 1. Complete output of dmesg http://www.oleg-sharoyko.net/files/freebsd/pci_config.201008/dmesg.20100803.txt -- Oleg Sharoyko From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 3 13:57: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 ACCA11065687 for ; Tue, 3 Aug 2010 13:57:14 +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 7FE698FC22 for ; Tue, 3 Aug 2010 13:57:14 +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 38CE146B8C; Tue, 3 Aug 2010 09:57:14 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id C20808A04E; Tue, 3 Aug 2010 09:57:08 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Tue, 3 Aug 2010 09:41:30 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100217; KDE/4.4.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201008030941.30649.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Tue, 03 Aug 2010 09:57:08 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Guy Helmer Subject: Re: Puzzling performance 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, 03 Aug 2010 13:57:14 -0000 On Monday, August 02, 2010 6:13:50 pm Guy Helmer wrote: > On a FreeBSD 7.1 SCHED_ULE kernel, I have a large number of files opened and > mmapped (with MAP_NOSYNC option) for shared-memory communication between > processes. Normally, memcpy() copies data into these shared-memory buffers > in a reasonable amount of time closely related to the size of the copy > (roughly 10us per 10KB). However, due to performance issues I've found that > sometimes a memcpy() takes an abnormally long time (10ms for 40KB, and I > suspect longer times occurring when I have not had monitoring enabled). The > system doesn't seem to be in memory overcommit -- there is just a minor > amount of swap in use, and I've not seen page-ins or page-outs while > watching systat or vmstat. > > Since I'm using MAP_NOSYNC, I would not expect the pager to flush dirty > pages to disk and cause add delays. Any ideas where to look? Might it help > to pin threads to CPUs in case a thread is getting moved to a different > core? Pinning might help yes. You might also want to ensure there aren't any interrupts on that CPU. Currently there isn't a good way to figure that out short of kgdb though. :( -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 3 13:57: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 31ABB1065675 for ; Tue, 3 Aug 2010 13:57:16 +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 043898FC12 for ; Tue, 3 Aug 2010 13:57:16 +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 B181746B90; Tue, 3 Aug 2010 09:57:15 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id A8E3C8A04F; Tue, 3 Aug 2010 09:57:14 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Tue, 3 Aug 2010 09:44:00 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100217; KDE/4.4.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201008030944.01011.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Tue, 03 Aug 2010 09:57:14 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Oleg Sharoyko Subject: Re: PCI config space is not restored upon resume (macbook pro) 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, 03 Aug 2010 13:57:16 -0000 On Tuesday, August 03, 2010 6:49:07 am Oleg Sharoyko wrote: > Hi! > > I'm trying to make FreeBSD (9-Current, checkout on 2010-08-01) correctly > suspend/resume on macbook pro. As of now I have to issues with resume: > > 1. Display stays blank upon resume. Got 'vga0: failed to reload state' > in dmesg, but I haven't looked into this yet. > > 2. Some hardware is missing upon resume, specifically ath, msk and firewire. > This devices disappear because rather strange values are being > read from pci config space (such as vendor id, device id and others). I wonder if the bus numbers for PCI-PCI bridges need to be restored on resume? If they aren't then config transactions won't be routed properly. You could add a pcib_resume() method that prints out the various bus register values after resume to see if they match what we print out during boot. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 3 15:22:00 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 00628106566C; Tue, 3 Aug 2010 15:21:59 +0000 (UTC) (envelope-from jeremie@le-hen.org) Received: from smtpfb2-g21.free.fr (smtpfb2-g21.free.fr [212.27.42.10]) by mx1.freebsd.org (Postfix) with ESMTP id 162EE8FC08; Tue, 3 Aug 2010 15:21:57 +0000 (UTC) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by smtpfb2-g21.free.fr (Postfix) with ESMTP id CBAC6CA8F17; Tue, 3 Aug 2010 17:05:55 +0200 (CEST) Received: from endor.tataz.chchile.org (unknown [82.233.239.98]) by smtp5-g21.free.fr (Postfix) with ESMTP id 4AD0AD480F0; Tue, 3 Aug 2010 17:05:47 +0200 (CEST) Received: from felucia.tataz.chchile.org (felucia.tataz.chchile.org [192.168.1.9]) by endor.tataz.chchile.org (Postfix) with ESMTP id 35CA233F19; Tue, 3 Aug 2010 15:05:46 +0000 (UTC) Received: by felucia.tataz.chchile.org (Postfix, from userid 1000) id 251D8A10F5; Tue, 3 Aug 2010 15:05:46 +0000 (UTC) Date: Tue, 3 Aug 2010 17:05:46 +0200 From: Jeremie Le Hen To: freebsd-hackers@FreeBSD.org Message-ID: <20100803150545.GH14016@felucia.tataz.chchile.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Cc: kan@FreeBSD.org Subject: Add -lssp_nonshared to GCC's LIB_SPEC unconditionally 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, 03 Aug 2010 15:22:00 -0000 Hi, Currenty, -lssp_nonshared is appended at the link stage only when -fstack-protector is used on the gcc command-line. The problem I would like to fix is a library (static or shared) compiled with -fstack-protector being linked in without using the same flag: mygeeto# cc -I /usr/local/include -L /usr/local/lib -lintl conftest.c /usr/local/lib/libintl.so: undefined reference to `__stack_chk_fail_local' Since world is now compiled by default with -fstack-protector, this may happen to everyone naively compiling a source file like above. I therefore propose the following change to always link in libssp_nonshared.a. I think this change is harmless when the symbol is not needed in one of the objects linked together since the linker won't pull in the library member "ssp-local.o" in the target object. Index: freebsd-spec.h =================================================================== RCS file: /data/repos/freebsd-cvsroot/src/contrib/gcc/config/freebsd-spec.h,v retrieving revision 1.26.2.2 diff -u -r1.26.2.2 freebsd-spec.h --- freebsd-spec.h 27 Dec 2009 20:39:58 -0000 1.26.2.2 +++ freebsd-spec.h 3 Aug 2010 10:18:08 -0000 @@ -168,7 +168,7 @@ %{pg: %{pthread:-lpthread_p} -lc_p}} \ %{shared: \ %{pthread:-lpthread} -lc} \ - %{fstack-protector|fstack-protector-all:-lssp_nonshared} \ + -lssp_nonshared \ " #endif #endif This change is also important because I've submitted a PR (138228) to compile ports with SSP. Of course many of them (although relatively few) break. If we eventually want this feature to reach the ports tree, it is necessary to fix as much problems as possible. I've already provided a few patches in the PR, but sometimes it is exaggeratedly difficult to fix the problem. For instance, devel/p5-Locale-gettext tests the existence of libintl.so with a naively compiled source file which doesn't link because of this error. The easiest way after the one proposed above would be to apply a patch conditionnaly. Thank you. Regards, -- Jeremie Le Hen Humans are born free and equal. But some are more equal than others. Coluche From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 3 15:47: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 72371106566B; Tue, 3 Aug 2010 15:47:01 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0A1638FC12; Tue, 3 Aug 2010 15:47:00 +0000 (UTC) Received: by qyk32 with SMTP id 32so3498415qyk.13 for ; Tue, 03 Aug 2010 08:47:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:in-reply-to:references:x-mailer:mime-version :content-type; bh=Xgi9bS3xSwUTjlrVj1xjhbvAGXoC3WYyZB3c/s4P6Ks=; b=v7TJBWL9s5qKfIfUTmMoLY7Bgp3q7xsrAyEaew6QYkdHW8pJFPmlWAbt8YZumjvMb9 nY7NDov0nOCW56jcKvOu5gP+hOzh453wvWVOSOwKqDiiMshKXeswIYOXewqt9Zfe9dap 7kzVeBkwArfVSMbTHXqtwg0Nl2X2hsHvoe5XE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type; b=M3vzms+PAlFZm+kUIOkYl7AlXDotBRGeNmrNw43R/+tjevUEWLo/SmHn41GAz2OMU0 FF721+5VfvNFCZ7J44MQE6IvNpMcRjfsHncV7HMaQ8kqNlM67+M09hIsz1BcNUZEWkpL nX9Af/mYgToZUcUBIGcXQTXwfI6pWISx8NR94= Received: by 10.224.29.16 with SMTP id o16mr2665808qac.294.1280850419895; Tue, 03 Aug 2010 08:46:59 -0700 (PDT) Received: from kan.dnsalias.net (c-24-63-226-98.hsd1.ma.comcast.net [24.63.226.98]) by mx.google.com with ESMTPS id r1sm1595523qcq.10.2010.08.03.08.46.57 (version=SSLv3 cipher=RC4-MD5); Tue, 03 Aug 2010 08:46:58 -0700 (PDT) Date: Tue, 3 Aug 2010 11:46:51 -0400 From: Alexander Kabaev To: Jeremie Le Hen Message-ID: <20100803114651.651e0ea4@kan.dnsalias.net> In-Reply-To: <20100803150545.GH14016@felucia.tataz.chchile.org> References: <20100803150545.GH14016@felucia.tataz.chchile.org> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/0t_hMcEHU0cI.CHRt8b+CRZ"; protocol="application/pgp-signature" Cc: kan@FreeBSD.org, freebsd-hackers@FreeBSD.org Subject: Re: Add -lssp_nonshared to GCC's LIB_SPEC unconditionally 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, 03 Aug 2010 15:47:01 -0000 --Sig_/0t_hMcEHU0cI.CHRt8b+CRZ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Tue, 3 Aug 2010 17:05:46 +0200 Jeremie Le Hen wrote: > Hi, >=20 > Currenty, -lssp_nonshared is appended at the link stage only when > -fstack-protector is used on the gcc command-line. The problem I > would like to fix is a library (static or shared) compiled with > -fstack-protector being linked in without using the same flag: >=20 > mygeeto# cc -I /usr/local/include -L /usr/local/lib -lintl > conftest.c /usr/local/lib/libintl.so: undefined reference to > `__stack_chk_fail_local' >=20 > Since world is now compiled by default with -fstack-protector, this > may happen to everyone naively compiling a source file like above. >=20 > I therefore propose the following change to always link in > libssp_nonshared.a. I think this change is harmless when the symbol > is not needed in one of the objects linked together since the linker > won't pull in the library member "ssp-local.o" in the target object. >=20 > Index: freebsd-spec.h > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > RCS > file: /data/repos/freebsd-cvsroot/src/contrib/gcc/config/freebsd-spec.h,v > retrieving revision 1.26.2.2 diff -u -r1.26.2.2 freebsd-spec.h > --- freebsd-spec.h 27 Dec 2009 20:39:58 -0000 1.26.2.2 > +++ freebsd-spec.h 3 Aug 2010 10:18:08 -0000 > @@ -168,7 +168,7 @@ > %{pg: %{pthread:-lpthread_p} > -lc_p}} \ > %{shared: > \ %{pthread:-lpthread} -lc} \ > - > %{fstack-protector|fstack-protector-all:-lssp_nonshared} \ > + > -lssp_nonshared > \ " #endif > #endif >=20 >=20 > This change is also important because I've submitted a PR (138228) to > compile ports with SSP. Of course many of them (although relatively > few) break. If we eventually want this feature to reach the ports > tree, it is necessary to fix as much problems as possible. I've > already provided a few patches in the PR, but sometimes it is > exaggeratedly difficult to fix the problem. For instance, > devel/p5-Locale-gettext tests the existence of libintl.so with a > naively compiled source file which doesn't link because of this > error. The easiest way after the one proposed above would be to > apply a patch conditionnaly. >=20 > Thank you. > Regards, > --=20 > Jeremie Le Hen >=20 > Coluche I have no objection, but think we should cave in and investigate the possibility of using linker script wrapping libc.so in FreeBSD-9.0: Below is Linux' counterpart: /* GNU ld script Use the shared library, but some functions are only in the static library, so try that secondarily. */ OUTPUT_FORMAT(elf32-i386) GROUP ( /lib/libc.so.6 /usr/lib/libc_nonshared.a AS_NEEDED ( /lib/ld-linux.so.2 ) ) --=20 Alexander Kabaev --Sig_/0t_hMcEHU0cI.CHRt8b+CRZ Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (FreeBSD) iD8DBQFMWDnwQ6z1jMm+XZYRAttCAJ4ukd9FnlO98RZ4tqlNSTvRQnMcVACgoof4 Xo6xjP6GIF/cfSacFtOxx4o= =X8/a -----END PGP SIGNATURE----- --Sig_/0t_hMcEHU0cI.CHRt8b+CRZ-- From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 3 16:25: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 9EBB31065672 for ; Tue, 3 Aug 2010 16:25:05 +0000 (UTC) (envelope-from osharoiko@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 EE9CA8FC08 for ; Tue, 3 Aug 2010 16:25:04 +0000 (UTC) Received: by bwz12 with SMTP id 12so2711467bwz.13 for ; Tue, 03 Aug 2010 09:25:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=k8DhttIC6ZL+uuET0Y65y4WCTKX5Vi/L69G1ckpLbTk=; b=N4hSfXKHstArHycN3437IajBAY+UcEtq0iGdnWQTItj1NlcK2MHgYwtwuQsAu20PJe RI1JOOZLA9q9S1Tk5vukx2wMhnggu4A+fl1ahyON6i4cYuhl+oRcvOmVbxNPILl1HpDc FGS39eeaH1nBTkUTEmsX7QiwRW22PWt1cpbGU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=FX4isACtcmBC1cIxoHP+x8dNrHNdmKvPqtgApwNLkBXWYzxT5l+TJLYqLFH15bQFwa OC6SV1gJamL34rTiRhl6TfUgSTRiYHa7/8js39y3elEyhjgnaxMYsH7VJYqVku3mLi/3 fnQRvaVvb7J2KljMDnCkKO0AxBNqIFUbeHDn8= MIME-Version: 1.0 Received: by 10.204.102.2 with SMTP id e2mr5421797bko.112.1280852703150; Tue, 03 Aug 2010 09:25:03 -0700 (PDT) Received: by 10.204.97.143 with HTTP; Tue, 3 Aug 2010 09:25:03 -0700 (PDT) In-Reply-To: <201008030944.01011.jhb@freebsd.org> References: <201008030944.01011.jhb@freebsd.org> Date: Tue, 3 Aug 2010 20:25:03 +0400 Message-ID: From: Oleg Sharoyko To: John Baldwin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: PCI config space is not restored upon resume (macbook pro) 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, 03 Aug 2010 16:25:05 -0000 On 3 August 2010 17:44, John Baldwin wrote: > I wonder if the bus numbers for PCI-PCI bridges need to be restored on re= sume? > If they aren't then config transactions won't be routed properly. =C2=A0Y= ou could > add a pcib_resume() method that prints out the various bus register value= s > after resume to see if they match what we print out during boot. I'll do that tomorrow and report the results. As I can see PCI-PCI bridge (non ACPI) restores bus numbers, while ACPI version - don't. --=20 Oleg Sharoyko From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 3 17:11:29 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 C1588106568E for ; Tue, 3 Aug 2010 17:11:29 +0000 (UTC) (envelope-from Hans-Joerg_Hoexer@genua.de) Received: from gg.genua.de (hhv6.genua.de [IPv6:2001:a60:f08e:c000::11]) by mx1.freebsd.org (Postfix) with ESMTP id 984E48FC20 for ; Tue, 3 Aug 2010 17:11:28 +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 o72C6Mdr023200 for ; Mon, 2 Aug 2010 14:06:22 +0200 (CEST) Received: (from localhost) by gg.genua.de (MSCAN) id 4/gg.genua.de/smtp-gw/mscan; Mon Aug 2 14:06:22 2010 Date: Mon, 2 Aug 2010 14:02:36 +0200 From: Hans-Joerg Hoexer To: freebsd-hackers@freebsd.org Message-ID: <20100802120236.GB29950@modermoor.genua.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) X-Mailman-Approved-At: Tue, 03 Aug 2010 17:25:11 +0000 Subject: 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: Tue, 03 Aug 2010 17:11:30 -0000 Hi, we have developed a driver tpm(4) for various TPMs for OpenBSD 4.7 and FreeBSD 8.0 and have ported and updated several third party packages to enable use of TPMs on Open- and FreeBSD. This enables applications like OpenSSH to generate and store private keys inside a TPM. The supported TPMs are: - Atmel 97SC3203 - Broadcom BCM0102 - Infineon SLB 9635 TT 1.2 - Intel INTC0102 - Sinosun SNS SSX35 - STM ST19WP18 - Winbond WEC WPCT200 The supported third party packages are: - openCryptoki 2.3.1: An PKCS#11 implementation, including support for TPMs. OpenSSH can use this library to generate and store private RSA keys inside a TPM. - openssl_tpm_engine 0.4.1: An openssl engine supporting TPMs. - tpm-emulator 0.7.0: An emulator providing the functionality of a TPM. Used for development purposes. - tpm-tools 1.3.5: Various tools for managing a TPM, including key generation. - trousers 0.3.5: An implementation of the Trusted Software Stack. This is the backend libary for the afore mentioned packages. - trousers testsuite 0.2: A testsuite for trousers. - TrustedGRUB 1.1.4: An TPM enabled version of grub, including support for natively booting OpenBSD. A patch including the driver tpm(4) is attached, more information, full source code and patches for third party packages can be found at http://bsssd.sourceforge.net. Regards, HJ. ---- Patch for FreeBSD 8.0 Release It provides - tpm(4) driver - modified acpidump(8) for dumping the TCPA table Applying and building the patch: # cd /usr/src # patch -p1 < /tmp/freebsd-beta.diff # cd /usr/src/usr.sbin/acpi/acpidump/ # make obj && make depend && make && make install # cd /usr/src/sys/i386/conf/ # config GENERIC # cd ../compile/GENERIC # make cleandepend ; make depend && make && make install # cat >> /boot/device.hints hint.tpm.0.at="isa" hint.tpm.0.irq="7" hint.tpm.0.maddr="0xfed40000" hint.tpm.0.msize="0x5000" hint.tpm.1.at="isa" hint.tpm.1.irq="7" hint.tpm.1.maddr="0xfed40000" hint.tpm.1.msize="0x1000" ^D # reboot Note: The IRQ to be used with tpm(4) was chosen arbitrarily to be 7. If you machine has no free ISA IRQ, you can use the driver without IRQ by just not providing a hint (ie. delete the hint.tpm.?.irq from /boot/device.hints) diff -Nupr src.orig/share/man/man4/tpm.4 src/share/man/man4/tpm.4 --- src.orig/share/man/man4/tpm.4 1970-01-01 01:00:00.000000000 +0100 +++ src/share/man/man4/tpm.4 2010-03-10 18:30:36.000000000 +0100 @@ -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 . diff -Nupr src.orig/sys/conf/files.i386 src/sys/conf/files.i386 --- src.orig/sys/conf/files.i386 2010-03-10 17:50:07.000000000 +0100 +++ src/sys/conf/files.i386 2010-03-10 18:32:08.000000000 +0100 @@ -221,6 +221,7 @@ dev/syscons/scvesactl.c optional sc vga dev/syscons/scvgarndr.c optional sc vga dev/syscons/scvtb.c optional sc dev/syscons/teken/teken.c optional sc +dev/tpm/tpm.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 diff -Nupr src.orig/sys/dev/tpm/tpm.c src/sys/dev/tpm/tpm.c --- src.orig/sys/dev/tpm/tpm.c 1970-01-01 01:00:00.000000000 +0100 +++ src/sys/dev/tpm/tpm.c 2010-03-09 10:49:27.000000000 +0100 @@ -0,0 +1,1537 @@ +/* + * Copyright (c) 2008, 2009 Michael Shalayeff + * Copyright (c) 2009, 2010 Hans-J + * 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 + +#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; + +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; +#endif + +#ifndef __FreeBSD__ + void *sc_powerhook; +#endif + int sc_suspend; +}; + +#ifdef __FreeBSD__ +#define TPMSOFTC(dev) \ + ((struct tpm_softc *)devclass_get_softc(tpm_devclass, dev2unit(dev))) + +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_probe(bus_space_tag_t, bus_space_handle_t); +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 *); +int tpm_suspend(device_t); +int tpm_resume(device_t); +#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. + */ +static void +tpm_identify(driver_t *driver, device_t parent) +{ + BUS_ADD_CHILD(parent, ISA_ORDER_SPECULATIVE, "tpm", 0); +} + +static int +tpm_probe(device_t dev) +{ + struct tpm_softc *sc = device_get_softc(dev); + bus_space_tag_t iot; + bus_space_handle_t ioh; + struct resource *mem_res; + int rv, mem_rid; + + bzero(sc, sizeof(struct tpm_softc)); + + 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 int +tpm_attach(device_t dev) +{ + struct tpm_softc *sc = device_get_softc(dev); + struct resource *mem_res; + int mem_rid; + int irq_rid, irq; + struct resource *irq_res; + + mem_rid = 0; + mem_res = bus_alloc_resource_any(dev, SYS_RES_MEMORY, &mem_rid, + RF_ACTIVE); + if (mem_res == NULL) + return ENXIO; + + sc->sc_bt = rman_get_bustag(mem_res); + sc->sc_bh = rman_get_bushandle(mem_res); + + irq_rid = 0; + irq_res = bus_alloc_resource_any(dev, SYS_RES_IRQ, &irq_rid, + RF_ACTIVE | RF_SHAREABLE); + if (irq_res != NULL) + irq = rman_get_start(irq_res); + else + irq = IRQUNK; + + 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")) { + bus_release_resource(dev, SYS_RES_MEMORY, mem_rid, mem_res); + bus_release_resource(dev, SYS_RES_IRQ, irq_rid, irq_res); + return ENXIO; + } + + if (sc->sc_init == tpm_tis12_init && irq_res != NULL && + bus_setup_intr(dev, irq_res, INTR_TYPE_TTY, NULL, + tpm_intr, sc, &sc->intr_cookie) != 0) { + bus_release_resource(dev, SYS_RES_MEMORY, mem_rid, mem_res); + bus_release_resource(dev, SYS_RES_IRQ, irq_rid, irq_res); + printf(": cannot establish interrupt\n"); + return 1; + } + + make_dev(&tpm_cdevsw, device_get_unit(dev), UID_ROOT, GID_WHEEL, + 0600, "tpm"); + + return 0; +} + +static device_method_t tpm_methods[] = { + DEVMETHOD(device_identify, tpm_identify), + DEVMETHOD(device_probe, tpm_probe), + DEVMETHOD(device_attach, tpm_attach), + 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); +#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.orig/sys/i386/conf/GENERIC src/sys/i386/conf/GENERIC --- src.orig/sys/i386/conf/GENERIC 2010-03-10 17:50:30.000000000 +0100 +++ src/sys/i386/conf/GENERIC 2010-03-10 18:33:30.000000000 +0100 @@ -196,6 +196,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.orig/usr.sbin/acpi/acpidump/acpi.c src/usr.sbin/acpi/acpidump/acpi.c --- src.orig/usr.sbin/acpi/acpidump/acpi.c 2010-03-10 17:49:46.000000000 +0100 +++ src/usr.sbin/acpi/acpidump/acpi.c 2010-03-10 18:31:35.000000000 +0100 @@ -76,6 +76,46 @@ static void acpi_handle_rsdt(struct ACPI /* 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) { @@ -489,6 +529,164 @@ acpi_handle_srat(struct ACPIsdt *sdp) printf(END_COMMENT); } +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(struct ACPIsdt *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->body; + + 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(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_sdt(struct ACPIsdt *sdp) { @@ -786,7 +984,9 @@ acpi_handle_rsdt(struct ACPIsdt *rsdp) if (acpi_checksum(sdp, sdp->len)) { warnx("RSDT entry %d (sig %.4s) is corrupt", i, sdp->signature); +#if 0 /* XXX hshoexer */ continue; +#endif } if (!memcmp(sdp->signature, "FACP", 4)) acpi_handle_fadt(sdp); @@ -800,6 +1000,8 @@ acpi_handle_rsdt(struct ACPIsdt *rsdp) acpi_handle_mcfg(sdp); else if (!memcmp(sdp->signature, "SRAT", 4)) acpi_handle_srat(sdp); + else if (!memcmp(sdp->signature, "TCPA", 4)) + acpi_handle_tcpa(sdp); else { printf(BEGIN_COMMENT); acpi_print_sdt(sdp); diff -Nupr src.orig/usr.sbin/acpi/acpidump/acpidump.h src/usr.sbin/acpi/acpidump/acpidump.h --- src.orig/usr.sbin/acpi/acpidump/acpidump.h 2010-03-10 17:49:46.000000000 +0100 +++ src/usr.sbin/acpi/acpidump/acpidump.h 2010-03-10 18:31:35.000000000 +0100 @@ -368,6 +368,77 @@ struct SRATbody { /* Find and map the RSD PTR structure and return it for parsing */ struct ACPIsdt *sdt_load_devmem(void); +/* TCPA */ +struct TCPAbody { + 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) From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 4 01:46:18 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 7123B1065676; Wed, 4 Aug 2010 01:46:18 +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 274038FC17; Wed, 4 Aug 2010 01:46:17 +0000 (UTC) Received: by iwn35 with SMTP id 35so1568241iwn.13 for ; Tue, 03 Aug 2010 18:46:17 -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=lEc0+SKst34P2UVCn4RQh7vMjgEsE1rpw/aYkwct+7o=; b=MOvW0DbzQu/56xZZKFmp8ZZMjZy7oc1Ji74hoet0rZ/CtCyOe1vdNhl86wIf1OOfTA 2Eq6cFvln2Pqu0miOBqaTPWcb1w87+spas8elidCXfpPqsqsQTuyx6PkI6gnspyk8waK Y69FZ3cy2fcwXqHnvAVhr/0i1yBCDGz3HbZb8= 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=qnjoF/DMTT/Z5GQCWCxLdlyeqU1OzAlS3zrxb62fxb1uL2KmPaxIPs1+3yAT4fu+ci wX8RhCgEPLIdqJU13lSvt9rtTaoEj4dCo0rUcYx3AmixTnuy6gY3D4F4eG2V7AiOgDIN H2nWFqwMSfFNkWHBX377Z4lmXiYkvD7EmWqRo= MIME-Version: 1.0 Received: by 10.42.4.211 with SMTP id 19mr2665525ict.56.1280886376876; Tue, 03 Aug 2010 18:46:16 -0700 (PDT) Sender: mdf356@gmail.com Received: by 10.42.6.85 with HTTP; Tue, 3 Aug 2010 18:46:16 -0700 (PDT) In-Reply-To: <201007301031.34266.jhb@freebsd.org> References: <201007301008.22501.jhb@freebsd.org> <201007301031.34266.jhb@freebsd.org> Date: Wed, 4 Aug 2010 01:46:16 +0000 X-Google-Sender-Auth: D8Js6FpLflNDLBKJM0jFCQ1lPF0 Message-ID: From: mdf@FreeBSD.org To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: 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: Wed, 04 Aug 2010 01:46:18 -0000 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 was >> > 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(%rb= x) >> > =A0 =A0 =A0* Pin the thread in order to avoid problems with thread mig= ration. >> > =A0 =A0 =A0* Once that all verifies are passed about spinlocks ownersh= ip, >> > =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:0x48,= %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 mig= ration. >> > =A0 =A0 =A0* Once that all verifies are passed about spinlocks ownersh= ip, >> > =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,-0x1= 10(%rbp) >> > ffffffff802db232: =A0 48 89 85 f8 fe ff ff =A0 =A0mov =A0 =A0%rax,-0x1= 08(%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 fffffff= f802db33e >> > >> > ffffffff802db23f: =A0 44 8b 60 50 =A0 =A0 =A0 =A0 =A0 =A0 mov =A0 =A00= x50(%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 the >> > 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 migrat= ed >> > right around panic time. >> > >> > This is the amd64 kernel on stable/7. =A0I'm not sure exactly what kin= d >> > 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? =A0Could the hardware have re-ordered >> > 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 locati= ons. >> >> Note this rule in section 8.2.2 of Volume 3A: >> >> =A0 =95 Reads may be reordered with older writes to different locations = but not >> =A0 =A0 with older writes to the same location. >> >> It is certainly true that sparc64 could reorder with RMO. =A0I believe i= a64 >> could reorder as well. =A0Since sched_pin/unpin are frequently used to p= rovide >> this sort of synchronization, we could use memory barriers in pin/unpin >> 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(), bu= t they >> are slightly more heavyweight, though it would be more clear what is hap= pening >> 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. =A0Howev= er, I > don't think the speculative read would be preserved in that case. =A0The = 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? =A0I suppose it is possible that = it > actually retires both instructions (but reordered) and then returns to th= e PC > value after the read of listlocks after the interrupt. =A0However, in tha= t case > the scheduler would not migrate as it would see td_pinned !=3D 0. =A0To g= et the > race you have to have the interrupt take effect prior to modifying td_pin= ned, > 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 doing > 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? I.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: sched_pin(); lock_list =3D PCPU_GET(spinlocks); if (lock_list !=3D NULL && lock_list->ll_count !=3D 0) { + /* XXX debug for bug 67957 */ + mfence(); + lle =3D PCPU_GET(spinlocks); + if (lle !=3D lock_list) { + panic("Bug 67957: had lock list %p, now %p\n", + lock_list, lle); + } + /* XXX end debug */ sched_unpin(); /* ... and the panic triggered. I think it's more likely that some barrier is needed in sched_pin() than that %gs is getting corrupted but can always be dereferenced. An mfence() at the end of sched_pin() would be sufficient, but it seems like overkill since all we really need is to prevent instruction re-ordering. As I said above, on PowerPC this would be isync; what is the equivalent on x86? I can try it out and see if this panic goes away. Thanks, matthew From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 4 03:49: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 B51F41065673; Wed, 4 Aug 2010 03:49:51 +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 5F6488FC12; Wed, 4 Aug 2010 03:49:51 +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 o743leeR046013; Wed, 4 Aug 2010 12:47:40 +0900 (JST) (envelope-from takawata@ns.init-main.com) Message-Id: <201008040347.o743leeR046013@sana.init-main.com> To: Hans-Joerg Hoexer In-reply-to: Your message of "Mon, 02 Aug 2010 14:02:36 +0200." <20100802120236.GB29950@modermoor.genua.de> Date: Wed, 04 Aug 2010 12:47:40 +0900 From: Takanori Watanabe Cc: freebsd-hackers@freebsd.org, freebsd-current@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, 04 Aug 2010 03:49:51 -0000 In message <20100802120236.GB29950@modermoor.genua.de>, Hans-Joerg Hoexer wrote: >Hi, > >we have developed a driver tpm(4) for various TPMs for OpenBSD 4.7 and >FreeBSD 8.0 and have ported and updated several third party packages to >enable use of TPMs on Open- and FreeBSD. This enables applications like >OpenSSH to generate and store private keys inside a TPM. > >The supported TPMs are: > >- Atmel 97SC3203 >- Broadcom BCM0102 >- Infineon SLB 9635 TT 1.2 >- Intel INTC0102 >- Sinosun SNS SSX35 >- STM ST19WP18 >- Winbond WEC WPCT200 > >The supported third party packages are: > >- openCryptoki 2.3.1: An PKCS#11 implementation, including support > for TPMs. OpenSSH can use this library to generate and store private > RSA keys inside a TPM. >- openssl_tpm_engine 0.4.1: An openssl engine supporting TPMs. >- tpm-emulator 0.7.0: An emulator providing the functionality of a TPM. > Used for development purposes. >- tpm-tools 1.3.5: Various tools for managing a TPM, including key > generation. >- trousers 0.3.5: An implementation of the Trusted Software Stack. > This is the backend libary for the afore mentioned packages. >- trousers testsuite 0.2: A testsuite for trousers. >- TrustedGRUB 1.1.4: An TPM enabled version of grub, including support > for natively booting OpenBSD. > >A patch including the driver tpm(4) is attached, more information, >full source code and patches for third party packages can be found at >http://bsssd.sourceforge.net. Nice! Quick review and hack: 1.How about attaching it as acpi child driver? In some case, TPM may appear in ACPI namespace (with _HID) and TPM spec defines ACPI method to handle TPM specific request. 2. Is identify method needed? Writing device hint will attach isa child driver, I think. 3.Module build I don't know it is proper in TPM nature. === diff -ruN src/sys/dev/tpm/tpm.c src.new/sys/dev/tpm/tpm.c --- src/sys/dev/tpm/tpm.c 2010-08-04 12:39:05.000000000 +0900 +++ src.new/sys/dev/tpm/tpm.c 2010-08-04 12:27:41.000000000 +0900 @@ -264,15 +264,22 @@ int tpm_legacy_end(struct tpm_softc *, int, int); #ifdef __FreeBSD__ +static struct isa_pnp_id tpm_ids[] = { + {0x32021114, "Trusted Platform Module"}, + + {0} +}; + /* * 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 static int tpm_probe(device_t dev) { @@ -281,8 +288,14 @@ bus_space_handle_t ioh; struct resource *mem_res; int rv, mem_rid; + int ret; bzero(sc, sizeof(struct tpm_softc)); + + if((ret = ISA_PNP_PROBE(device_get_parent(dev), dev, tpm_ids)) + <= 0){ + return ret; + } mem_rid = 0; mem_res = bus_alloc_resource_any(dev, SYS_RES_MEMORY, &mem_rid, @@ -362,7 +375,9 @@ } static device_method_t tpm_methods[] = { +#if 0 DEVMETHOD(device_identify, tpm_identify), +#endif DEVMETHOD(device_probe, tpm_probe), DEVMETHOD(device_attach, tpm_attach), DEVMETHOD(device_suspend, tpm_suspend), @@ -377,6 +392,7 @@ static devclass_t tpm_devclass; DRIVER_MODULE(tpm, isa, tpm_driver, tpm_devclass, 0, 0); +DRIVER_MODULE(tpm, acpi, tpm_driver, tpm_devclass, 0, 0); #else /* * OpenBSD specific code for probing and attaching TPM to device tree. diff -ruN src/sys/modules/tpm/Makefile src.new/sys/modules/tpm/Makefile --- src/sys/modules/tpm/Makefile 1970-01-01 09:00:00.000000000 +0900 +++ src.new/sys/modules/tpm/Makefile 2010-08-04 12:43:59.000000000 +0900 @@ -0,0 +1,8 @@ +# $FreeBSD$ + +.PATH: ${.CURDIR}/../../dev/tpm + +KMOD= tpm +SRCS= tpm.c isa_if.h opt_acpi.h acpi_if.h bus_if.h device_if.h + +.include From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 4 07:13:06 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 C080E106566B; Wed, 4 Aug 2010 07:13:06 +0000 (UTC) (envelope-from osharoiko@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 77EA78FC08; Wed, 4 Aug 2010 07:13:06 +0000 (UTC) Received: by iwn35 with SMTP id 35so1886597iwn.13 for ; Wed, 04 Aug 2010 00:13:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Rnf8JLxVYc23mClQjnk4t8EDouZA2pDqif8RBUbWFPA=; b=FvOG4UoLQQK2TiVVT52fu+Aj0Ez8EtnXtvdU8x2zDaLgJpY970VkjCXW5DK65WyT5r VlRV0PHmxwCKSD4B/ZeUjcz3H4adZnQ1HJ+v9r0XnBgXMDUwbJzba7Rno+w9dBdEY0ly m1X69rzfa/Cc2CK4/iXG12I1/BOSw8GgI3O+U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=QZ8U9WsEeO4XfHmcBYhT5SkOfqCdUL2qo/UScQN+MTYsLBP5zAe/L6LxBHoGSJ2WM/ oiGUCozj8uh/HSUk3HKXRJ/KYqLQ1+o8VfUsEfqSHYWMm5abDt5ilX9IHU5A0dDKh1v5 wJ7o7Y4zaMcFlFyPr+jKpz98e54IADEuVqdaE= MIME-Version: 1.0 Received: by 10.231.30.130 with SMTP id u2mr9978772ibc.111.1280905985411; Wed, 04 Aug 2010 00:13:05 -0700 (PDT) Received: by 10.231.168.20 with HTTP; Wed, 4 Aug 2010 00:13:04 -0700 (PDT) In-Reply-To: References: <201008030944.01011.jhb@freebsd.org> Date: Wed, 4 Aug 2010 11:13:04 +0400 Message-ID: From: Oleg Sharoyko To: John Baldwin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: PCI config space is not restored upon resume (macbook pro) 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, 04 Aug 2010 07:13:06 -0000 On 3 August 2010 20:25, Oleg Sharoyko wrote: >> I wonder if the bus numbers for PCI-PCI bridges need to be restored on r= esume? >> If they aren't then config transactions won't be routed properly. =C2=A0= You could >> add a pcib_resume() method that prints out the various bus register valu= es >> after resume to see if they match what we print out during boot. Indeed this was the problem of PCI-PIC bridges' registers not being restored upon resume. Thanks for your advise! I'm including the patch, which uses exiting methods from dev/pic/pic_pci.c to save/restore bridges' registers on suspend/resume. With it my macbook pro no longer looses devices after resume. Unfortunately it doesn't help with videocard problem. Though I no longer see 'failed to reload state' message, display still stays blank and dark after resume. Would freebsd-acpi be the right list to ask for help or can you recommend anything else I can do to solve this problem? Index: dev/acpica/acpi_pcib_pci.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sys/dev/acpica/acpi_pcib_pci.c,v retrieving revision 1.18 diff -u -r1.18 acpi_pcib_pci.c --- dev/acpica/acpi_pcib_pci.c 5 Jun 2009 18:44:36 -0000 1.18 +++ dev/acpica/acpi_pcib_pci.c 4 Aug 2010 06:54:36 -0000 @@ -65,6 +65,7 @@ static int acpi_pcib_pci_probe(device_t bus); static int acpi_pcib_pci_attach(device_t bus); +static int acpi_pcib_pci_suspend(device_t bus); static int acpi_pcib_pci_resume(device_t bus); static int acpi_pcib_read_ivar(device_t dev, device_t child, int which, uintptr_t *result); @@ -76,7 +77,7 @@ DEVMETHOD(device_probe, acpi_pcib_pci_probe), DEVMETHOD(device_attach, acpi_pcib_pci_attach), DEVMETHOD(device_shutdown, bus_generic_shutdown), - DEVMETHOD(device_suspend, bus_generic_suspend), + DEVMETHOD(device_suspend, acpi_pcib_pci_suspend), DEVMETHOD(device_resume, acpi_pcib_pci_resume), /* Bus interface */ @@ -142,9 +143,20 @@ } static int -acpi_pcib_pci_resume(device_t dev) +acpi_pcib_pci_suspend(device_t dev) { + struct acpi_pcib_softc *sc; + sc =3D device_get_softc(dev); + pcib_cfg_save(&sc->ap_pcibsc); + return (bus_generic_suspend(dev)); +} +static int +acpi_pcib_pci_resume(device_t dev) +{ + struct acpi_pcib_softc *sc; + sc =3D device_get_softc(dev); + pcib_cfg_restore(&sc->ap_pcibsc); return (acpi_pcib_resume(dev)); } Index: dev/pci/pci_pci.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sys/dev/pci/pci_pci.c,v retrieving revision 1.61 diff -u -r1.61 pci_pci.c --- dev/pci/pci_pci.c 10 Dec 2009 01:01:53 -0000 1.61 +++ dev/pci/pci_pci.c 4 Aug 2010 06:54:36 -0000 @@ -238,7 +238,7 @@ /* * Get current bridge configuration. */ -static void +void pcib_cfg_save(struct pcib_softc *sc) { device_t dev; @@ -260,7 +260,7 @@ /* * Restore previous bridge configuration. */ -static void +void pcib_cfg_restore(struct pcib_softc *sc) { device_t dev; Index: dev/pci/pcib_private.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sys/dev/pci/pcib_private.h,v retrieving revision 1.15 diff -u -r1.15 pcib_private.h --- dev/pci/pcib_private.h 14 Mar 2009 14:08:53 -0000 1.15 +++ dev/pci/pcib_private.h 4 Aug 2010 06:54:36 -0000 @@ -82,5 +82,7 @@ int pcib_alloc_msix(device_t pcib, device_t dev, int *irq); int pcib_release_msix(device_t pcib, device_t dev, int irq); int pcib_map_msi(device_t pcib, device_t dev, int irq, uint64_t *addr, uint32_t *data); +void pcib_cfg_save(struct pcib_softc *sc); +void pcib_cfg_restore(struct pcib_softc *sc); #endif --=20 Oleg Sharoyko From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 4 10:41: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 7FAC61065676; Wed, 4 Aug 2010 10:41:57 +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 E2EBC8FC19; Wed, 4 Aug 2010 10:41:56 +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 o74AdfYO047937; Wed, 4 Aug 2010 19:39:42 +0900 (JST) (envelope-from takawata@ns.init-main.com) Message-Id: <201008041039.o74AdfYO047937@sana.init-main.com> To: tss-project@genua.de In-reply-to: Your message of "Wed, 04 Aug 2010 12:47:40 JST." <201008040347.o743leeR046013@sana.init-main.com> Date: Wed, 04 Aug 2010 19:39:41 +0900 From: Takanori Watanabe Cc: freebsd-hackers@freebsd.org, freebsd-current@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, 04 Aug 2010 10:41:57 -0000 In message <201008040347.o743leeR046013@sana.init-main.com>, wrote: >Quick review and hack: > >1.How about attaching it as acpi child driver? > >In some case, TPM may appear in ACPI namespace (with _HID) and >TPM spec defines ACPI method to handle TPM specific request. > >2. Is identify method needed? > >Writing device hint will attach isa child driver, I think. > >3.Module build > >I don't know it is proper in TPM nature. 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 . ==== diff -ruN src/sys/dev/tpm/tpm.c src.new/sys/dev/tpm/tpm.c --- src/sys/dev/tpm/tpm.c 2010-08-04 12:39:05.000000000 +0900 +++ src.new/sys/dev/tpm/tpm.c 2010-08-04 19:32:44.000000000 +0900 @@ -49,6 +49,7 @@ #include #include #endif +#include "tpmvar.h" #ifndef __FreeBSD__ /* XXX horrible hack for tcsd (-lpthread) workaround on OpenBSD */ @@ -142,43 +143,10 @@ /* Set when enabling legacy interface in host bridge. */ int tpm_enabled; -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; -#endif - -#ifndef __FreeBSD__ - void *sc_powerhook; -#endif - int sc_suspend; -}; #ifdef __FreeBSD__ #define TPMSOFTC(dev) \ - ((struct tpm_softc *)devclass_get_softc(tpm_devclass, dev2unit(dev))) + ((struct tpm_softc *)dev->si_drv1) d_open_t tpmopen; d_close_t tpmclose; @@ -229,7 +197,6 @@ { 0, "", TPM_DEV_NOINTS }, }; -int tpm_tis12_probe(bus_space_tag_t, bus_space_handle_t); 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); @@ -239,8 +206,6 @@ #ifdef __FreeBSD__ void tpm_intr(void *); -int tpm_suspend(device_t); -int tpm_resume(device_t); #else int tpm_intr(void *); void tpm_powerhook(int, void *); @@ -264,67 +229,45 @@ 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 -static int -tpm_probe(device_t dev) -{ - struct tpm_softc *sc = device_get_softc(dev); - bus_space_tag_t iot; - bus_space_handle_t ioh; - struct resource *mem_res; - int rv, mem_rid; - - bzero(sc, sizeof(struct tpm_softc)); - - 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 int +int tpm_attach(device_t dev) { struct tpm_softc *sc = device_get_softc(dev); - struct resource *mem_res; - int mem_rid; - int irq_rid, irq; - struct resource *irq_res; + int irq; - mem_rid = 0; - mem_res = bus_alloc_resource_any(dev, SYS_RES_MEMORY, &mem_rid, + sc->mem_rid = 0; + sc->mem_res = bus_alloc_resource_any(dev, SYS_RES_MEMORY, &sc->mem_rid, RF_ACTIVE); - if (mem_res == NULL) + if (sc->mem_res == NULL) return ENXIO; - sc->sc_bt = rman_get_bustag(mem_res); - sc->sc_bh = rman_get_bushandle(mem_res); + sc->sc_bt = rman_get_bustag(sc->mem_res); + sc->sc_bh = rman_get_bushandle(sc->mem_res); - irq_rid = 0; - irq_res = bus_alloc_resource_any(dev, SYS_RES_IRQ, &irq_rid, + sc->irq_rid = 0; + sc->irq_res = bus_alloc_resource_any(dev, SYS_RES_IRQ, &sc->irq_rid, RF_ACTIVE | RF_SHAREABLE); - if (irq_res != NULL) - irq = rman_get_start(irq_res); + 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; @@ -341,42 +284,51 @@ printf("%s", device_get_name(dev)); if ((sc->sc_init)(sc, irq, "tpm")) { - bus_release_resource(dev, SYS_RES_MEMORY, mem_rid, mem_res); - bus_release_resource(dev, SYS_RES_IRQ, irq_rid, irq_res); + tpm_detach(dev); return ENXIO; } - if (sc->sc_init == tpm_tis12_init && irq_res != NULL && - bus_setup_intr(dev, irq_res, INTR_TYPE_TTY, NULL, + 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) { - bus_release_resource(dev, SYS_RES_MEMORY, mem_rid, mem_res); - bus_release_resource(dev, SYS_RES_IRQ, irq_rid, irq_res); + tpm_detach(dev); printf(": cannot establish interrupt\n"); return 1; } - make_dev(&tpm_cdevsw, device_get_unit(dev), UID_ROOT, GID_WHEEL, - 0600, "tpm"); + 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; } -static device_method_t tpm_methods[] = { - DEVMETHOD(device_identify, tpm_identify), - DEVMETHOD(device_probe, tpm_probe), - DEVMETHOD(device_attach, tpm_attach), - DEVMETHOD(device_suspend, tpm_suspend), - DEVMETHOD(device_resume, tpm_resume), - { 0, 0 } -}; +int +tpm_detach(device_t dev) +{ + struct tpm_softc * sc = device_get_softc(dev); -static driver_t tpm_driver = { - "tpm", tpm_methods, sizeof(struct tpm_softc), -}; + 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; +} -static devclass_t tpm_devclass; -DRIVER_MODULE(tpm, isa, tpm_driver, tpm_devclass, 0, 0); #else /* * OpenBSD specific code for probing and attaching TPM to device tree. diff -ruN src/sys/dev/tpm/tpm_acpi.c src.new/sys/dev/tpm/tpm_acpi.c --- src/sys/dev/tpm/tpm_acpi.c 1970-01-01 09:00:00.000000000 +0900 +++ src.new/sys/dev/tpm/tpm_acpi.c 2010-08-04 15:43:08.000000000 +0900 @@ -0,0 +1,78 @@ +/* + * Copyright (c) 2008, 2009 Michael Shalayeff + * Copyright (c) 2009, 2010 Hans-J$(D+S(Brg H$(D+S(Bxer + * 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", "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 -ruN src/sys/dev/tpm/tpm_isa.c src.new/sys/dev/tpm/tpm_isa.c --- src/sys/dev/tpm/tpm_isa.c 1970-01-01 09:00:00.000000000 +0900 +++ src.new/sys/dev/tpm/tpm_isa.c 2010-08-04 15:21:07.000000000 +0900 @@ -0,0 +1,92 @@ +/* + * Copyright (c) 2008, 2009 Michael Shalayeff + * Copyright (c) 2009, 2010 Hans-J$(D+S(Brg H$(D+S(Bxer + * 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 -ruN src/sys/dev/tpm/tpmvar.h src.new/sys/dev/tpm/tpmvar.h --- src/sys/dev/tpm/tpmvar.h 1970-01-01 09:00:00.000000000 +0900 +++ src.new/sys/dev/tpm/tpmvar.h 2010-08-04 15:22:05.000000000 +0900 @@ -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 -ruN src/sys/modules/tpm/Makefile src.new/sys/modules/tpm/Makefile --- src/sys/modules/tpm/Makefile 1970-01-01 09:00:00.000000000 +0900 +++ src.new/sys/modules/tpm/Makefile 2010-08-04 19:17:26.000000000 +0900 @@ -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 From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 4 13:05: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 20E481065670 for ; Wed, 4 Aug 2010 13:05:52 +0000 (UTC) (envelope-from faust64@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 993D58FC0A for ; Wed, 4 Aug 2010 13:05:51 +0000 (UTC) Received: by bwz12 with SMTP id 12so3149412bwz.13 for ; Wed, 04 Aug 2010 06:05:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:from:date :message-id:subject:to:content-type; bh=aKdXPqznl9wxEEFu4c1pmzI0MdjzAMOsbB03b+391os=; b=Tq6bBfdS2IwHGbQcCgeNJYgUaXg41mKNoPAddas5VBXkTAhGO40EhU7I6LT1Jd65Sn 9RZ+YniYA2LeRcMorI38KdQvyPA2dDa/c02amfXaynRbWdl7hB39N7Cz1e0hxbJqV8Fw fcXazOC9ToqiY7c/VX/yCC3nmsqBXYLKCxtX0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=QsuTRXRcs+xwu0O1VE/9qp5Av6cZE43wryVDrypI998rTZYUA2UtuUgx0QSo19uLCh v3P4udWb6BFDX+x2AfFuF4oGJ1mSfIiLfvSMhZVdpkd+mrBIh1IA9rY9dfKIqDjH15S0 atE2gt5h/dmqitYPjKHXb2+eNvdEda6iMdJfc= Received: by 10.204.127.65 with SMTP id f1mr6259708bks.55.1280925657283; Wed, 04 Aug 2010 05:40:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.119.17 with HTTP; Wed, 4 Aug 2010 05:40:27 -0700 (PDT) From: =?ISO-8859-1?Q?Samuel_Mart=EDn_Moro?= Date: Wed, 4 Aug 2010 14:40:27 +0200 Message-ID: To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: behaviour changes in mdconfig? or something related? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2010 13:05:52 -0000 Hi, I started this thread in the freebsd-questions mailing list. But since I'm quite sure it's not a bsdlabel problem, I might find better answers here. We have a script that buids custom FreeBSD releases. This code works on 4.7, 5.4, 5.5, 6.2, 7.1 and 7.2. I want to make it work with FreeBSD-8.1. Brievly, it works like that: having minimum4, the following disktab layout: minimum4:ty=3Dmfs:se#512:nt#1:rm#300:\ :ns#11520:nc#1:\ :pa#11520:oa#0:ba#4096:fa#512:\ :pc#11520:oc#0:bc#4096:fc#512: dd if=3D/dev/zero of=3Dbootfile.img bs=3D18k count=3D4096 dev=3D`mdconfig -a -t vnode -f bootfile.img` bsdlabel -w -B -b $GENPATH/boot/boot /dev/$dev minimum4 newfs -O1 -i 4096 -o space -m 1 /dev/${dev}c mount /dev/${dev}c /mnt (cd cdroot ; find . | cpio -dump /mnt) [...] When bsdlabelling, I got these warnings: bsdlabel: partition c doesn't cover the whole unit! bsdlabel: An incorrect partition c may cause problems for standard system utilities But it never was a problem for older releases. Since 8.1 (8.0?), after calling bsdlabel, I still have /dev/${dev}a, but/dev/${dev}c doesn't show up anymore. I tried mounting a 7.2-generated image (where I had both md0a and md0c) on = a 8.1 host, and only had md0a listed in devs. I tried mounting a 8.1-generated image (where I had only /dev/md0a) on a 7.= 2 host, and /dev/md0c finally appeard. So, is it possible to / how could I make ${dev}c appear on 8.1, like it was in previous releases? Thanks! Samuel Mart=EDn Moro {EPITECH.} tek4 CamTrace S.A.S (+033) 1 41 38 37 60 1 All=E9e de la Venelle 92150 Suresnes FRANCE "Nobody wants to say how this works. Maybe nobody knows ..." Xorg.conf(5) From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 4 13:31:34 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 BF505106564A for ; Wed, 4 Aug 2010 13:31:34 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 777788FC18 for ; Wed, 4 Aug 2010 13:31:34 +0000 (UTC) Received: by ywf9 with SMTP id 9so2434264ywf.13 for ; Wed, 04 Aug 2010 06:31:33 -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=okuB1YUsjsfHxFTzAlwvNdetven9FVM7CCpkvEj61MU=; b=McDeIuiWmXf5NH4+qSkWdsWah2PkSLvfcvFNa3qBrSSVkD1rdvCP45fYdFQx2Cefqm u+w9GafkWXXk1JhvFiQeT1TQ89lW5yl8vaUOMtHyIdA6rzapGza2oB40W0zPeqyoT3fS Og4Bs5XAiVXOyriLV8BLzVh9VNdn7C3EIWO98= 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=EHhvTfNZW6YQ3TXTyiN1lKq+R44bIifKx8aU9K135DNWSS5AGpDEgvzraAcpEM9KWI U6vxjAOmU8JrOkzLdmuKkeD4uezQ+CN2bFF5gqiwabg1qVm6nR688UHbVSbwH2mrb/5L AigE/uxbZtF6kP4g2QERrjx8VGhyp0v+IuEBg= MIME-Version: 1.0 Received: by 10.151.50.14 with SMTP id c14mr10309115ybk.420.1280928693348; Wed, 04 Aug 2010 06:31:33 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.231.187.104 with HTTP; Wed, 4 Aug 2010 06:31:33 -0700 (PDT) In-Reply-To: References: Date: Wed, 4 Aug 2010 06:31:33 -0700 X-Google-Sender-Auth: c6mPw_HdQQ7-3gAqTIF63uePVbg Message-ID: From: Garrett Cooper To: =?ISO-8859-1?Q?Samuel_Mart=EDn_Moro?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: behaviour changes in mdconfig? or something related? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2010 13:31:34 -0000 On Wed, Aug 4, 2010 at 5:40 AM, Samuel Mart=EDn Moro wr= ote: > Hi, ... > So, is it possible to / how could I make ${dev}c appear on 8.1, like it w= as > in previous releases? It's a geom(4) change. Try ${dev} instead of ${dev}c (this should work on all releases, but I could be wrong). HTH, -Garrett From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 4 13:37: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 4E77B1065670 for ; Wed, 4 Aug 2010 13:37:53 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [204.109.60.94]) by mx1.freebsd.org (Postfix) with ESMTP id 2B02B8FC1E for ; Wed, 4 Aug 2010 13:37:52 +0000 (UTC) Received: from unknown (87-194-158-129.bethere.co.uk [87.194.158.129]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA id B3A445C94; Wed, 4 Aug 2010 13:18:45 +0000 (UTC) Date: Wed, 4 Aug 2010 14:18:58 +0100 From: Bruce Cran To: Samuel =?ISO-8859-1?Q?Mart=EDn?= Moro Message-ID: <20100804141858.00003610@unknown> In-Reply-To: References: X-Mailer: Claws Mail 3.7.4cvs1 (GTK+ 2.16.0; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: behaviour changes in mdconfig? or something related? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2010 13:37:53 -0000 On Wed, 4 Aug 2010 14:40:27 +0200 Samuel Mart=EDn Moro wrote: > Since 8.1 (8.0?), after calling bsdlabel, I still have /dev/${dev}a, > but/dev/${dev}c doesn't show up anymore. The 'c' partition is no longer created on FreeBSD 8 - you should use /dev/${dev} instead of /dev/${dev}c :=20 http://www.freebsddiary.org/upgrade8.php . --=20 Bruce=20 From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 4 14:27: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 5C42B1065678; Wed, 4 Aug 2010 14:27:16 +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 06B3E8FC1D; Wed, 4 Aug 2010 14:27:16 +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 9C1EC46B99; Wed, 4 Aug 2010 10:27:15 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id C1FC28A04E; Wed, 4 Aug 2010 10:27:14 -0400 (EDT) From: John Baldwin To: mdf@freebsd.org Date: Wed, 4 Aug 2010 10:26:17 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100217; KDE/4.4.5; amd64; ; ) References: <201007301031.34266.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Message-Id: <201008041026.17553.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Wed, 04 Aug 2010 10:27:14 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx 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: Wed, 04 Aug 2010 14:27:16 -0000 On Tuesday, August 03, 2010 9:46:16 pm mdf@freebsd.org wrote: > 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: > >> > > >> > thread_lock(td); > >> > td->td_flags &=3D ~TDF_SELECT; > >> > 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: 65 48 8b 1c 25 00 00 mov %gs:0x0,%rbx > >> > ffffffff802db217: 00 00 > >> > ffffffff802db219: ff 83 04 01 00 00 incl 0x104(%rbx) > >> > * Pin the thread in order to avoid problems with thread migrati= on. > >> > * Once that all verifies are passed about spinlocks ownership, > >> > * the thread is in a safe path and it can be unpinned. > >> > */ > >> > sched_pin(); > >> > lock_list =3D PCPU_GET(spinlocks); > >> > ffffffff802db21f: 65 48 8b 04 25 48 00 mov %gs:0x48,%rax > >> > ffffffff802db226: 00 00 > >> > if (lock_list !=3D NULL && lock_list->ll_count !=3D 0) { > >> > ffffffff802db228: 48 85 c0 test %rax,%rax > >> > * Pin the thread in order to avoid problems with thread migrati= on. > >> > * Once that all verifies are passed about spinlocks ownership, > >> > * the thread is in a safe path and it can be unpinned. > >> > */ > >> > sched_pin(); > >> > lock_list =3D PCPU_GET(spinlocks); > >> > ffffffff802db22b: 48 89 85 f0 fe ff ff mov %rax,-0x110(%rbp) > >> > ffffffff802db232: 48 89 85 f8 fe ff ff mov %rax,-0x108(%rbp) > >> > if (lock_list !=3D NULL && lock_list->ll_count !=3D 0) { > >> > ffffffff802db239: 0f 84 ff 00 00 00 je ffffffff802db33e > >> > > >> > ffffffff802db23f: 44 8b 60 50 mov 0x50(%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. So clearly the thread was being migrat= ed > >> > right around panic time. > >> > > >> > This is the amd64 kernel on stable/7. I'm not sure exactly what kind > >> > 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() for > >> > it to really do what it claims? Could the hardware have re-ordered > >> > the "mov %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: > >> > >> =95 Reads may be reordered with older writes to different locations = but not > >> with older writes to the same location. > >> > >> It is certainly true that sparc64 could reorder with RMO. I believe i= a64 > >> could reorder as well. Since sched_pin/unpin are frequently used to p= rovide > >> this sort of synchronization, we could use memory barriers in pin/unpin > >> like so: > >> > >> sched_pin() > >> { > >> td->td_pinned =3D atomic_load_acq_int(&td->td_pinned) + 1; > >> } > >> > >> sched_unpin() > >> { > >> 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 and > > migrate you so that the speculative read was from the other CPU. Howev= er, I > > don't think the speculative read would be preserved in that case. The = 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? I suppose it is possible that = it > > actually retires both instructions (but reordered) and then returns to = the PC > > value after the read of listlocks after the interrupt. However, in tha= t case > > the scheduler would not migrate as it would see td_pinned !=3D 0. To g= et 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: > > > > =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. >=20 > I wonder how that's interpreted in the microcode, though? I.e. if the > incr instruction decodes to load, add, store, does the h/w allow the > later reads to pass the final store? Well, the architecture is defined in terms of the ISA, not the microcode, p= er se, so I think it would have to treat the read for the incl as being an ear= lier read than 'spinlocks'. > I added the following: >=20 > sched_pin(); > lock_list =3D PCPU_GET(spinlocks); > if (lock_list !=3D NULL && lock_list->ll_count !=3D 0) { > + /* XXX debug for bug 67957 */ > + mfence(); > + lle =3D PCPU_GET(spinlocks); > + if (lle !=3D lock_list) { > + panic("Bug 67957: had lock list %p, now %p\n", > + lock_list, lle); > + } > + /* XXX end debug */ > sched_unpin(); >=20 > /* >=20 > ... and the panic triggered. I think it's more likely that some > barrier is needed in sched_pin() than that %gs is getting corrupted > but can always be dereferenced. Actually, I would beg to differ in that case. If PCPU_GET(spinlocks) returns non-NULL, then it means that you hold a spin lock, which means that interrupts are disabled and have been disabled for "a while" (from when the spin lock was acquired prior trying to acquire the lock that you hold now). I think that means that the only way you can have a problem is if you get an NMI. Do you have custom logic in your NMI handler? Perhaps it isn't calling swapgs correctly (either when it shouldn't, or isn't calling it when it should). I know that the Joseph Koshy spent a good bit of time getting the %gs handling in the NMI handler correct to handle NMIs firing at "bad" times (such as during the very end of a syscall return). It is worth noting that when the spinlock was acquired "ages" ago, it did a critical_enter() which would have forbid any context switches, so the thread would not have migrated to another CPU. I think it is almost certainly a corrupt %gs. > An mfence() at the end of sched_pin() would be sufficient, but it > seems like overkill since all we really need is to prevent instruction > re-ordering. As I said above, on PowerPC this would be isync; what is > the equivalent on x86? I can try it out and see if this panic goes > away. mfence() is the closest thing x86 has. It does not have an equivalent to isync as it is still defined to complete instructions in "program order". It does not reorder instructions, merely the scheduling of memory transactions from what I can tell. Mostly I think that all this is just to allow it to store writes in its store buffer, but a CPU will snoop its own store buffer to satisfy reads IIRC, so by and large a CPU is consistent with itself. =2D-=20 John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 4 15:39: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 81E621065672 for ; Wed, 4 Aug 2010 15:39:49 +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 4EC018FC13 for ; Wed, 4 Aug 2010 15:39:49 +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 E9CC746B96; Wed, 4 Aug 2010 11:39:48 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id B2B2A8A03C; Wed, 4 Aug 2010 11:39:47 -0400 (EDT) From: John Baldwin To: Oleg Sharoyko Date: Wed, 4 Aug 2010 11:12:28 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100217; KDE/4.4.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201008041112.28704.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Wed, 04 Aug 2010 11:39:47 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: freebsd-hackers@freebsd.org Subject: Re: PCI config space is not restored upon resume (macbook pro) 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, 04 Aug 2010 15:39:49 -0000 On Wednesday, August 04, 2010 3:13:04 am Oleg Sharoyko wrote: > On 3 August 2010 20:25, Oleg Sharoyko wrote: > > >> I wonder if the bus numbers for PCI-PCI bridges need to be restored on resume? > >> If they aren't then config transactions won't be routed properly. You could > >> add a pcib_resume() method that prints out the various bus register values > >> after resume to see if they match what we print out during boot. > > Indeed this was the problem of PCI-PIC bridges' registers not being > restored upon resume. > Thanks for your advise! I'm including the patch, which uses exiting > methods from dev/pic/pic_pci.c > to save/restore bridges' registers on suspend/resume. With it my > macbook pro no longer > looses devices after resume. Cool, I actually think that the ACPI PCI-PCI driver can just use the stock PCI-PCI bridge driver's suspend and resume methods. Can you try out this alternate patch instead? > Unfortunately it doesn't help with videocard problem. Though I no > longer see 'failed to reload state' > message, display still stays blank and dark after resume. Would > freebsd-acpi be the right list > to ask for help or can you recommend anything else I can do to solve > this problem? This sounds like the display just needs to be powered on via DPMS. You might be able to make this work via acpi_video and toggling the LCD status that way. You could also try dpms.ko. Index: dev/acpica/acpi_pcib.c =================================================================== --- dev/acpica/acpi_pcib.c (revision 210796) +++ dev/acpica/acpi_pcib.c (working copy) @@ -171,13 +171,6 @@ return_VALUE (bus_generic_attach(dev)); } -int -acpi_pcib_resume(device_t dev) -{ - - return (bus_generic_resume(dev)); -} - static void prt_lookup_device(ACPI_PCI_ROUTING_TABLE *entry, void *arg) { Index: dev/acpica/acpi_pcib_pci.c =================================================================== --- dev/acpica/acpi_pcib_pci.c (revision 210796) +++ dev/acpica/acpi_pcib_pci.c (working copy) @@ -65,7 +65,6 @@ static int acpi_pcib_pci_probe(device_t bus); static int acpi_pcib_pci_attach(device_t bus); -static int acpi_pcib_pci_resume(device_t bus); static int acpi_pcib_read_ivar(device_t dev, device_t child, int which, uintptr_t *result); static int acpi_pcib_pci_route_interrupt(device_t pcib, @@ -75,39 +74,20 @@ /* Device interface */ DEVMETHOD(device_probe, acpi_pcib_pci_probe), DEVMETHOD(device_attach, acpi_pcib_pci_attach), - DEVMETHOD(device_shutdown, bus_generic_shutdown), - DEVMETHOD(device_suspend, bus_generic_suspend), - DEVMETHOD(device_resume, acpi_pcib_pci_resume), /* Bus interface */ - DEVMETHOD(bus_print_child, bus_generic_print_child), DEVMETHOD(bus_read_ivar, acpi_pcib_read_ivar), - DEVMETHOD(bus_write_ivar, pcib_write_ivar), - DEVMETHOD(bus_alloc_resource, pcib_alloc_resource), - DEVMETHOD(bus_release_resource, bus_generic_release_resource), - DEVMETHOD(bus_activate_resource, bus_generic_activate_resource), - DEVMETHOD(bus_deactivate_resource, bus_generic_deactivate_resource), - DEVMETHOD(bus_setup_intr, bus_generic_setup_intr), - DEVMETHOD(bus_teardown_intr, bus_generic_teardown_intr), /* pcib interface */ - DEVMETHOD(pcib_maxslots, pcib_maxslots), - DEVMETHOD(pcib_read_config, pcib_read_config), - DEVMETHOD(pcib_write_config, pcib_write_config), DEVMETHOD(pcib_route_interrupt, acpi_pcib_pci_route_interrupt), - DEVMETHOD(pcib_alloc_msi, pcib_alloc_msi), - DEVMETHOD(pcib_release_msi, pcib_release_msi), - DEVMETHOD(pcib_alloc_msix, pcib_alloc_msix), - DEVMETHOD(pcib_release_msix, pcib_release_msix), - DEVMETHOD(pcib_map_msi, pcib_map_msi), {0, 0} }; static devclass_t pcib_devclass; -DEFINE_CLASS_0(pcib, acpi_pcib_pci_driver, acpi_pcib_pci_methods, - sizeof(struct acpi_pcib_softc)); +DEFINE_CLASS_1(pcib, acpi_pcib_pci_driver, acpi_pcib_pci_methods, + sizeof(struct acpi_pcib_softc), pcib_driver); DRIVER_MODULE(acpi_pcib, pci, acpi_pcib_pci_driver, pcib_devclass, 0, 0); MODULE_DEPEND(acpi_pcib, acpi, 1, 1, 1); @@ -142,13 +123,6 @@ } static int -acpi_pcib_pci_resume(device_t dev) -{ - - return (acpi_pcib_resume(dev)); -} - -static int acpi_pcib_read_ivar(device_t dev, device_t child, int which, uintptr_t *result) { struct acpi_pcib_softc *sc = device_get_softc(dev); Index: dev/acpica/acpi_pcib_acpi.c =================================================================== --- dev/acpica/acpi_pcib_acpi.c (revision 210796) +++ dev/acpica/acpi_pcib_acpi.c (working copy) @@ -65,7 +65,6 @@ static int acpi_pcib_acpi_probe(device_t bus); static int acpi_pcib_acpi_attach(device_t bus); -static int acpi_pcib_acpi_resume(device_t bus); static int acpi_pcib_read_ivar(device_t dev, device_t child, int which, uintptr_t *result); static int acpi_pcib_write_ivar(device_t dev, device_t child, @@ -94,7 +93,7 @@ DEVMETHOD(device_attach, acpi_pcib_acpi_attach), DEVMETHOD(device_shutdown, bus_generic_shutdown), DEVMETHOD(device_suspend, bus_generic_suspend), - DEVMETHOD(device_resume, acpi_pcib_acpi_resume), + DEVMETHOD(device_resume, bus_generic_resume), /* Bus interface */ DEVMETHOD(bus_print_child, bus_generic_print_child), @@ -257,13 +257,6 @@ return (acpi_pcib_attach(dev, &sc->ap_prt, sc->ap_bus)); } -static int -acpi_pcib_acpi_resume(device_t dev) -{ - - return (acpi_pcib_resume(dev)); -} - /* * Support for standard PCI bridge ivars. */ Index: dev/acpica/acpi_pcibvar.h =================================================================== --- dev/acpica/acpi_pcibvar.h (revision 210796) +++ dev/acpica/acpi_pcibvar.h (working copy) @@ -31,13 +31,14 @@ #define _ACPI_PCIBVAR_H_ #ifdef _KERNEL + void acpi_pci_link_add_reference(device_t dev, int index, device_t pcib, int slot, int pin); int acpi_pci_link_route_interrupt(device_t dev, int index); int acpi_pcib_attach(device_t bus, ACPI_BUFFER *prt, int busno); int acpi_pcib_route_interrupt(device_t pcib, device_t dev, int pin, ACPI_BUFFER *prtbuf); -int acpi_pcib_resume(device_t dev); + #endif /* _KERNEL */ #endif /* !_ACPI_PCIBVAR_H_ */ Index: dev/pci/pcib_private.h =================================================================== --- dev/pci/pcib_private.h (revision 210796) +++ dev/pci/pcib_private.h (working copy) @@ -37,6 +37,7 @@ * Export portions of generic PCI:PCI bridge support so that it can be * used by subclasses. */ +DECLARE_CLASS(pcib_driver); /* * Bridge-specific data. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 4 16:09:33 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 0FC981065674 for ; Wed, 4 Aug 2010 16:09:33 +0000 (UTC) (envelope-from faust64@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 652278FC1F for ; Wed, 4 Aug 2010 16:09:32 +0000 (UTC) Received: by bwz12 with SMTP id 12so3278933bwz.13 for ; Wed, 04 Aug 2010 09:09:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=H8J0hZz5G+t6sfUPplY7hYxmvW3B6qUPA5LJ1GbODz0=; b=hA+XK9FYhBtlcwUjRisNKUYHbZ3EKgr/ZeLp7dYGzj6F2D3vvV2fRGIoW7Y/PYdBoX Zh5URikrrz1OOVpWsDfF6LjZtanudKo68ceC5Ygclol9Nwt3v2Nruo53E3ZSCtuAf6Is BPP8id96Ec5zKfM5iuVbjKtH/JQ6axrGMRyZU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=Ol7+D9/+BJTOdl2NvtIU/PsJHEc5FtWmufcwbc5qICl3wdIUuKt1SpMXcQI/tQExuN kUseKefMKd7ldfb0gMB2Xxg2sRxmW2asNWCo6U6MPKOdGKgEF5DI+TR9w2Qk6O2LaF9z tAQJYdEmHHAtScHPbN1Fc4D8975PpKuAynBLY= Received: by 10.204.81.130 with SMTP id x2mr6327574bkk.210.1280938171128; Wed, 04 Aug 2010 09:09:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.119.17 with HTTP; Wed, 4 Aug 2010 09:09:01 -0700 (PDT) In-Reply-To: References: From: =?ISO-8859-1?Q?Samuel_Mart=EDn_Moro?= Date: Wed, 4 Aug 2010 18:09:01 +0200 Message-ID: To: Garrett Cooper Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org Subject: Re: behaviour changes in mdconfig? or something related? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2010 16:09:33 -0000 Indeed, it works using ${dev} instead of ${dev}c Thanks! Samuel Mart=EDn Moro {EPITECH.} tek4 CamTrace S.A.S (+033) 1 41 38 37 60 1 All=E9e de la Venelle 92150 Suresnes FRANCE "Nobody wants to say how this works. Maybe nobody knows ..." Xorg.conf(5) On Wed, Aug 4, 2010 at 3:31 PM, Garrett Cooper wrote: > On Wed, Aug 4, 2010 at 5:40 AM, Samuel Mart=EDn Moro > wrote: > > Hi, > > ... > > > So, is it possible to / how could I make ${dev}c appear on 8.1, like it > was > > in previous releases? > > It's a geom(4) change. Try ${dev} instead of ${dev}c (this should work > on all releases, but I could be wrong). > HTH, > -Garrett > From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 4 16:20:33 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 259BC106566C; Wed, 4 Aug 2010 16:20:33 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id ACA808FC12; Wed, 4 Aug 2010 16:20:32 +0000 (UTC) Received: by pvh1 with SMTP id 1so2306099pvh.13 for ; Wed, 04 Aug 2010 09:20:32 -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=Yem72Wg8t2zOSB7igFgTlmV3HZjhrDx5hgzYXguLuGU=; b=pv0JQCzStY1s6hwNdbDTlZuOWM3S1blpc7HaVcNEyxaMl8/7vMFrIYwryOkCW00T1V xxD1rWX3/AqxlJSMmfRW8yXC8ZGgkQL97o/PMqJlY57zslZ+kstVdXZRBZQNWd2GJJWn JAVNmqAAxzzsitjLechujUULjPsynLX4oHD24= 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=VcR53/t19FouyAekce8EX07rkq2Byvl3PV6j7qPx6Z5NXw9eGifacDihXatDlIkdZ1 7Pn7Q8qW+VITq17RLY1MdDbohhrKP+sSawepfvquOtqrUTDM1ZIQhtB1I1D3bSWisdsn ZwVDaUBCWClPup1F27m10BuXUPHUpIprXj+WE= MIME-Version: 1.0 Received: by 10.142.133.20 with SMTP id g20mr7990320wfd.0.1280938832244; Wed, 04 Aug 2010 09:20:32 -0700 (PDT) Sender: mdf356@gmail.com Received: by 10.42.6.85 with HTTP; Wed, 4 Aug 2010 09:20:31 -0700 (PDT) In-Reply-To: <201008041026.17553.jhb@freebsd.org> References: <201007301031.34266.jhb@freebsd.org> <201008041026.17553.jhb@freebsd.org> Date: Wed, 4 Aug 2010 16:20:31 +0000 X-Google-Sender-Auth: MszHhj851rfOFBM2bmCV5HPhoJE Message-ID: From: mdf@FreeBSD.org To: John Baldwin 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: Wed, 04 Aug 2010 16:20:33 -0000 On Wed, Aug 4, 2010 at 2:26 PM, John Baldwin wrote: > On Tuesday, August 03, 2010 9:46:16 pm mdf@freebsd.org wrote: >> 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 = was >> >> > 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:0x= 0,%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 = migration. >> >> > =A0 =A0 =A0* Once that all verifies are passed about spinlocks owne= rship, >> >> > =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:0x= 48,%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 = migration. >> >> > =A0 =A0 =A0* Once that all verifies are passed about spinlocks owne= rship, >> >> > =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,-= 0x110(%rbp) >> >> > ffffffff802db232: =A0 48 89 85 f8 fe ff ff =A0 =A0mov =A0 =A0%rax,-= 0x108(%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 ffff= ffff802db33e >> >> > >> >> > 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 = the >> >> > 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 mig= rated >> >> > right around panic time. >> >> > >> >> > This is the amd64 kernel on stable/7. =A0I'm not sure exactly what = kind >> >> > of hardware; it's a 4-way Intel chip from about 3 or 4 years ago II= RC. >> >> > >> >> > So... do we need some kind of barrier in the code for sched_pin() f= or >> >> > it to really do what it claims? =A0Could the hardware have re-order= ed >> >> > 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 loc= ations. >> >> >> >> Note this rule in section 8.2.2 of Volume 3A: >> >> >> >> =A0 =95 Reads may be reordered with older writes to different locatio= ns but not >> >> =A0 =A0 with older writes to the same location. >> >> >> >> It is certainly true that sparc64 could reorder with RMO. =A0I believ= e ia64 >> >> could reorder as well. =A0Since sched_pin/unpin are frequently used t= o provide >> >> this sort of synchronization, we could use memory barriers in pin/unp= in >> >> 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 = happening >> >> I think. >> > >> > However, to actually get a race you'd have to have an interrupt fire a= nd >> > migrate you so that the speculative read was from the other CPU. =A0Ho= wever, I >> > don't think the speculative read would be preserved in that case. =A0T= he 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 b= e >> > doing, so presumably it is thrown away? =A0I suppose it is possible th= at it >> > actually retires both instructions (but reordered) and then returns to= the PC >> > value after the read of listlocks after the interrupt. =A0However, in = that case >> > the scheduler would not migrate as it would see td_pinned !=3D 0. =A0T= o get the >> > race you have to have the interrupt take effect prior to modifying td_= pinned, >> > so I think the processor would have to discard the reordered read of >> > listlocks so it could safely resume execution at the 'incl' instructio= n. >> > >> > The other nit there on x86 at least is that the incl instruction is do= ing >> > 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? > > Well, the architecture is defined in terms of the ISA, not the microcode,= per > se, so I think it would have to treat the read for the incl as being an e= arlier > read than 'spinlocks'. > >> I added the following: >> >> =A0 =A0 =A0 sched_pin(); >> =A0 =A0 =A0 lock_list =3D PCPU_GET(spinlocks); >> =A0 =A0 =A0 if (lock_list !=3D NULL && lock_list->ll_count !=3D 0) { >> + =A0 =A0 =A0 =A0 =A0 =A0 /* XXX debug for bug 67957 */ >> + =A0 =A0 =A0 =A0 =A0 =A0 mfence(); >> + =A0 =A0 =A0 =A0 =A0 =A0 lle =3D PCPU_GET(spinlocks); >> + =A0 =A0 =A0 =A0 =A0 =A0 if (lle !=3D lock_list) { >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 panic("Bug 67957: had lock lis= t %p, now %p\n", >> + =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 /* XXX end debug */ >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 sched_unpin(); >> >> =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. > > Actually, I would beg to differ in that case. =A0If PCPU_GET(spinlocks) > returns non-NULL, then it means that you hold a spin lock, ll_count is 0 for the "correct" pc_spinlocks and non-zero for the "wrong" one, though. So I think it can be non-NULL but the current thread/CPU doesn't hold a spinlock. I don't believe we have any code in the NMI handler. I'm on vacation today so I'll check tomorrow. Thanks, matthew > which > means that interrupts are disabled and have been disabled for "a while" > (from when the spin lock was acquired prior trying to acquire the > lock that you hold now). =A0I think that means that the only way you can > have a problem is if you get an NMI. =A0Do you have custom logic in your > NMI handler? =A0Perhaps it isn't calling swapgs correctly (either when it > shouldn't, or isn't calling it when it should). =A0I know that the Joseph > Koshy spent a good bit of time getting the %gs handling in the NMI > handler correct to handle NMIs firing at "bad" times (such as during the > very end of a syscall return). > > It is worth noting that when the spinlock was acquired "ages" ago, it > did a critical_enter() which would have forbid any context switches, > so the thread would not have migrated to another CPU. =A0I think it is > almost certainly a corrupt %gs. > >> An mfence() at the end of sched_pin() would be sufficient, but it >> seems like overkill since all we really need is to prevent instruction >> re-ordering. =A0As I said above, on PowerPC this would be isync; what is >> the equivalent on x86? =A0I can try it out and see if this panic goes >> away. > > mfence() is the closest thing x86 has. =A0It does not have an equivalent > to isync as it is still defined to complete instructions in "program > order". =A0It does not reorder instructions, merely the scheduling of > memory transactions from what I can tell. =A0Mostly I think that all this > is just to allow it to store writes in its store buffer, but a CPU will > snoop its own store buffer to satisfy reads IIRC, so by and large a CPU > is consistent with itself. > > -- > John Baldwin > From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 4 17:27: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 D8D8C1065675 for ; Wed, 4 Aug 2010 17:27:14 +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 684148FC0A for ; Wed, 4 Aug 2010 17:27:13 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=_8GgO4CLWNIA:10 a=kj9zAlcOel0A:10 a=M8b_wTzEtboA:10 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=nLrMZui6rxegqKTwC_wA:9 a=XXKc3SUhJl8O5i2eLqm47Mi-7X0A:4 a=CjuIK1q_8ugA: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 1247663444 for freebsd-hackers@freebsd.org; Wed, 04 Aug 2010 19:22:11 +0200 From: Hans Petter Selasky To: freebsd-hackers@freebsd.org Date: Wed, 4 Aug 2010 19:18:53 +0200 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.4.5; amd64; ; ) X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'( =?utf-8?q?=3B=5FIjlA=3A=0A=09hGE=2E=2EEw?=, =?utf-8?q?XAQ*o=23=5C/M=7ESC=3DS1-f9=7BEzRfT=27=7CHhll5Q=5Dha5Bt-s=7CoTlKM?= =?utf-8?q?usi=3A1e=5BwJl=7Dkd=7DGR=0A=09Z0adGx-x=5F0zGbZj=27e?=(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201008041918.54028.hselasky@c2i.net> Subject: 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: Wed, 04 Aug 2010 17:27:14 -0000 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? I'm running 8-stable on amd64. --HPS From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 4 18:56:44 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 4FD931065676; Wed, 4 Aug 2010 18:56:44 +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 EA3FE8FC0A; Wed, 4 Aug 2010 18:56:43 +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 83C3546B96; Wed, 4 Aug 2010 14:56:43 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 9A5438A04E; Wed, 4 Aug 2010 14:56:42 -0400 (EDT) From: John Baldwin To: mdf@freebsd.org Date: Wed, 4 Aug 2010 14:55:25 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100217; KDE/4.4.5; amd64; ; ) References: <201008041026.17553.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Message-Id: <201008041455.26066.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Wed, 04 Aug 2010 14:56:42 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx 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: Wed, 04 Aug 2010 18:56:44 -0000 On Wednesday, August 04, 2010 12:20:31 pm mdf@freebsd.org wrote: > On Wed, Aug 4, 2010 at 2:26 PM, John Baldwin wrote: > > On Tuesday, August 03, 2010 9:46:16 pm mdf@freebsd.org wrote: > >> 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 i= t was > >> >> > held by is in fact sometimes not possible to keep the lock, like: > >> >> > > >> >> > thread_lock(td); > >> >> > td->td_flags &=3D ~TDF_SELECT; > >> >> > thread_unlock(td); > >> >> > > >> >> > What I was wondering is, even though the assembly I see in objdum= p -S > >> >> > for witness_warn has the increment of td_pinned before the PCPU_G= ET: > >> >> > > >> >> > ffffffff802db210: 65 48 8b 1c 25 00 00 mov %gs:0x0,%rbx > >> >> > ffffffff802db217: 00 00 > >> >> > ffffffff802db219: ff 83 04 01 00 00 incl 0x104(%rbx) > >> >> > * Pin the thread in order to avoid problems with thread migr= ation. > >> >> > * Once that all verifies are passed about spinlocks ownershi= p, > >> >> > * the thread is in a safe path and it can be unpinned. > >> >> > */ > >> >> > sched_pin(); > >> >> > lock_list =3D PCPU_GET(spinlocks); > >> >> > ffffffff802db21f: 65 48 8b 04 25 48 00 mov %gs:0x48,%rax > >> >> > ffffffff802db226: 00 00 > >> >> > if (lock_list !=3D NULL && lock_list->ll_count !=3D 0) { > >> >> > ffffffff802db228: 48 85 c0 test %rax,%rax > >> >> > * Pin the thread in order to avoid problems with thread migr= ation. > >> >> > * Once that all verifies are passed about spinlocks ownershi= p, > >> >> > * the thread is in a safe path and it can be unpinned. > >> >> > */ > >> >> > sched_pin(); > >> >> > lock_list =3D PCPU_GET(spinlocks); > >> >> > ffffffff802db22b: 48 89 85 f0 fe ff ff mov %rax,-0x110(%r= bp) > >> >> > ffffffff802db232: 48 89 85 f8 fe ff ff mov %rax,-0x108(%r= bp) > >> >> > if (lock_list !=3D NULL && lock_list->ll_count !=3D 0) { > >> >> > ffffffff802db239: 0f 84 ff 00 00 00 je ffffffff802db3= 3e > >> >> > > >> >> > ffffffff802db23f: 44 8b 60 50 mov 0x50(%rax),%r1= 2d > >> >> > > >> >> > 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 i= n the > >> >> > 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. So clearly the thread was being mig= rated > >> >> > right around panic time. > >> >> > > >> >> > This is the amd64 kernel on stable/7. I'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? Could the hardware have re-order= ed > >> >> > the "mov %gs:0x48,%rax" PCPU_GET to before the sched_pin() > >> >> > increment? > >> >> > >> >> Hmmm, I think it might be able to because they refer to different l= ocations. > >> >> > >> >> Note this rule in section 8.2.2 of Volume 3A: > >> >> > >> >> =95 Reads may be reordered with older writes to different locatio= ns but not > >> >> with older writes to the same location. > >> >> > >> >> It is certainly true that sparc64 could reorder with RMO. I believ= e ia64 > >> >> could reorder as well. Since sched_pin/unpin are frequently used t= o provide > >> >> this sort of synchronization, we could use memory barriers in pin/u= npin > >> >> like so: > >> >> > >> >> sched_pin() > >> >> { > >> >> td->td_pinned =3D atomic_load_acq_int(&td->td_pinned) + 1; > >> >> } > >> >> > >> >> sched_unpin() > >> >> { > >> >> 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 i= s happening > >> >> 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. Ho= wever, I > >> > don't think the speculative read would be preserved in that case. T= he CPU > >> > has to return to a specific PC when it returns from the interrupt an= d it has > >> > no way of storing the state for what speculative reordering it might= be > >> > doing, so presumably it is thrown away? I suppose it is possible th= at it > >> > actually retires both instructions (but reordered) and then returns = to the PC > >> > value after the read of listlocks after the interrupt. However, in = that case > >> > the scheduler would not migrate as it would see td_pinned !=3D 0. T= o get the > >> > race you have to have the interrupt take effect prior to modifying t= d_pinned, > >> > so I think the processor would have to discard the reordered read of > >> > listlocks so it could safely resume execution at the 'incl' instruct= ion. > >> > > >> > The other nit there on x86 at least is that the incl instruction is = doing > >> > both a read and a write and another rule in the section 8.2.2 is thi= s: > >> > > >> > =95 Reads are not reordered with other reads. > >> > > >> > That would seem to prevent the read of listlocks from passing the re= ad of > >> > td_pinned in the incl instruction on x86. > >> > >> I wonder how that's interpreted in the microcode, though? I.e. if the > >> incr instruction decodes to load, add, store, does the h/w allow the > >> later reads to pass the final store? > > > > Well, the architecture is defined in terms of the ISA, not the microcod= e, per > > se, so I think it would have to treat the read for the incl as being an= earlier > > read than 'spinlocks'. > > > >> I added the following: > >> > >> sched_pin(); > >> lock_list =3D PCPU_GET(spinlocks); > >> if (lock_list !=3D NULL && lock_list->ll_count !=3D 0) { > >> + /* XXX debug for bug 67957 */ > >> + mfence(); > >> + lle =3D PCPU_GET(spinlocks); > >> + if (lle !=3D lock_list) { > >> + panic("Bug 67957: had lock list %p, now %p\n", > >> + lock_list, lle); > >> + } > >> + /* XXX end debug */ > >> sched_unpin(); > >> > >> /* > >> > >> ... and the panic triggered. I think it's more likely that some > >> barrier is needed in sched_pin() than that %gs is getting corrupted > >> but can always be dereferenced. > > > > Actually, I would beg to differ in that case. If PCPU_GET(spinlocks) > > returns non-NULL, then it means that you hold a spin lock, >=20 > ll_count is 0 for the "correct" pc_spinlocks and non-zero for the > "wrong" one, though. So I think it can be non-NULL but the current > thread/CPU doesn't hold a spinlock. Hmm, does the 'lock_list' pointer value in the dump match 'lock_list' from another CPU? =2D-=20 John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 4 19:13: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 8A0B41065672 for ; Wed, 4 Aug 2010 19:13:57 +0000 (UTC) (envelope-from neelnatu@gmail.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 2126B8FC15 for ; Wed, 4 Aug 2010 19:13:56 +0000 (UTC) Received: by wwa36 with SMTP id 36so5631983wwa.31 for ; Wed, 04 Aug 2010 12:13:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=rIhFwRLgfR/7eFwXk+/F2V7T+S0pmtkmnygqjqVVrq8=; b=V+pe0NmxmeGSHjbVvM8ZN0y+W2jZW0eWvN2A5MdRpz6lAU/KIH3BzvkaiNMTt0pr3J 8Qg5VUJCP5FBagrK+WXmQzzNzl9nkaglOXcqDFf8Py386KpTCBeTvqUmJWnBi8/tbsUv jtB6WkeDaM9QUhxX8OL+s4Y2z1Thz2kOzZHNo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Ijp4skOO2Y6rC6mUZr1hYJSNiKylBigyuSJYyGotM9gmDK3rtLA4qrRTQ6vub/Hy3v /zVu3uOGRjiNIaUBobXFi+p0+2uVvUn4i7mPC94JdvEcN2jg3lAR35ycLnX0YsKhPPzi zfnown0zAVveSbT5u+OhQwEuCeSyHVfSc92WQ= MIME-Version: 1.0 Received: by 10.216.162.72 with SMTP id x50mr2076630wek.3.1280949235653; Wed, 04 Aug 2010 12:13:55 -0700 (PDT) Received: by 10.216.80.8 with HTTP; Wed, 4 Aug 2010 12:13:55 -0700 (PDT) In-Reply-To: <201008041918.54028.hselasky@c2i.net> References: <201008041918.54028.hselasky@c2i.net> Date: Wed, 4 Aug 2010 12:13:55 -0700 Message-ID: From: Neel Natu To: Hans Petter Selasky Content-Type: text/plain; charset=ISO-8859-1 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: Wed, 04 Aug 2010 19:13:57 -0000 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? best Neel > I'm running 8-stable on amd64. > > --HPS > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 4 19:32: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 9AF77106564A for ; Wed, 4 Aug 2010 19:32:51 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe10.swipnet.se [212.247.155.33]) by mx1.freebsd.org (Postfix) with ESMTP id 27C3C8FC21 for ; Wed, 4 Aug 2010 19:32:50 +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=BvjWnucTkTp-XqHJ5GUA:9 a=23toIidKKBbpDeb5VbmYm4XZB4UA:4 a=wPNLvfGTeEIA:10 a=9aOQ2cSd83gA:10 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe10.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 1214535535; Wed, 04 Aug 2010 21:32:49 +0200 From: Hans Petter Selasky To: Neel Natu Date: Wed, 4 Aug 2010 21:29:32 +0200 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.4.5; amd64; ; ) References: <201008041918.54028.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: <201008042129.32095.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: Wed, 04 Aug 2010 19:32:51 -0000 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. --HPS From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 4 20:23:23 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 37C06106567D for ; Wed, 4 Aug 2010 20:23:23 +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 096848FC16 for ; Wed, 4 Aug 2010 20:23:23 +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 9AA7046B65; Wed, 4 Aug 2010 16:23:22 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id CD5628A04E; Wed, 4 Aug 2010 16:23:21 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Wed, 4 Aug 2010 16:22:19 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100217; KDE/4.4.5; amd64; ; ) References: <201008041918.54028.hselasky@c2i.net> In-Reply-To: <201008041918.54028.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201008041622.19372.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Wed, 04 Aug 2010 16:23:21 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Hans Petter Selasky 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: Wed, 04 Aug 2010 20:23:23 -0000 On Wednesday, August 04, 2010 1:18:53 pm 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? > > I'm running 8-stable on amd64. In general FreeBSD doesn't support hotplug PCI currently. Likely you'd need some sort of hotplug bridge driver similar to cbb(4) for Cardbus slots that would catch whatever interrupt is generated when a card is inserted and add the device, etc. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 4 21:24: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 37E001065679 for ; Wed, 4 Aug 2010 21:24:14 +0000 (UTC) (envelope-from neelnatu@gmail.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 BD5B78FC26 for ; Wed, 4 Aug 2010 21:24:13 +0000 (UTC) Received: by wwa36 with SMTP id 36so5797329wwa.31 for ; Wed, 04 Aug 2010 14:24:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=Hf2MBoatV83IbrynEpvhJPGINxWXWcMM7Phgeh2T9b4=; b=PxcMbTVGGGQSU6zDNYMMucZogBL571QU2bp4up9x0/jB9Z5zRyUWNM2KwNEvyoWxRT yTDEq7GAUQSUGhu6A8qqgh4FqfpogYeBwdbDyULAqRMQL4LEBHVCM0ZhuUdJT7AVjWX+ BlD9uWyiTiYnJSYl9ZRdRtxcnIWr5LhySPYIM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=tLG8+XoWfeTNhmHZQFmy+MjNDS6Qel2gj3mrPZr3e5eOaRNQneDQ+Q+ewzbVx+BKGb FoaWkX186jBSaX82jniHm8o/NT/x2LHQlbG3syofUfwQiRP/tPYRJx/dUBmbKpdTAGdD gBGTmjLBBeaqj5OGth0ccWWvskJVHGQZkOjgw= MIME-Version: 1.0 Received: by 10.227.133.81 with SMTP id e17mr7920480wbt.186.1280957052506; Wed, 04 Aug 2010 14:24:12 -0700 (PDT) Received: by 10.216.80.8 with HTTP; Wed, 4 Aug 2010 14:24:12 -0700 (PDT) In-Reply-To: <201008042129.32095.hselasky@c2i.net> References: <201008041918.54028.hselasky@c2i.net> <201008042129.32095.hselasky@c2i.net> Date: Wed, 4 Aug 2010 14:24:12 -0700 Message-ID: From: Neel Natu To: Hans Petter Selasky Content-Type: text/plain; charset=ISO-8859-1 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: Wed, 04 Aug 2010 21:24:14 -0000 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. 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 % 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. Hope this helps. best Neel > --HPS > From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 5 15:30: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 5DD0D106576B; Thu, 5 Aug 2010 15:30:25 +0000 (UTC) (envelope-from osharoiko@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 019618FC15; Thu, 5 Aug 2010 15:30:24 +0000 (UTC) Received: by gwj23 with SMTP id 23so3117022gwj.13 for ; Thu, 05 Aug 2010 08:30:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=94SbVYdCArf458UKYHJk9XIRvuuvP6aYuaiFk2AP81M=; b=AohLCahSfBzblVutKvEdAKugwcI8yA9yGfapo6ZttTPX32YXI+SMgtbw4gGx5ExnRY 2hi9VVWSPZhvu1aqkAdtLnVQQCLgXGJBmiO856qOki/phy3NUvtzqtvB09Ak4xAxHQjD PmjFAz6ogZ73+rw/iKv2IZJOV/cxaCiIG9Dn4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Llljkd/7yAAK7QFzc4Ar3cubMRZONAAhkHycpVTsvEv3yc2r7DWxMadeSodZn+2mAO wzMVTl2f2OH+49/fuyZwwjYVMaj6o3QysZbCejUFfHwDscUuu0UwlcDybIUwnwXAAcjd cn03n1lbH8r/Dvb6Mz3QmXFT/4wjuyiXqezbc= MIME-Version: 1.0 Received: by 10.101.116.3 with SMTP id t3mr12114649anm.137.1281022224009; Thu, 05 Aug 2010 08:30:24 -0700 (PDT) Received: by 10.231.168.20 with HTTP; Thu, 5 Aug 2010 08:30:23 -0700 (PDT) In-Reply-To: <201008041112.28704.jhb@freebsd.org> References: <201008041112.28704.jhb@freebsd.org> Date: Thu, 5 Aug 2010 19:30:23 +0400 Message-ID: From: Oleg Sharoyko To: John Baldwin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: PCI config space is not restored upon resume (macbook pro) 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, 05 Aug 2010 15:30:25 -0000 On 4 August 2010 19:12, John Baldwin wrote: > Cool, I actually think that the ACPI PCI-PCI driver can just use the > stock PCI-PCI bridge driver's suspend and resume methods. =C2=A0Can you t= ry > out this alternate patch instead? It works, and sure looks better than mine. I didn't know there's such a nic= e way to inherit methods. > This sounds like the display just needs to be powered on via DPMS. > You might be able to make this work via acpi_video and toggling the > LCD status that way. =C2=A0You could also try dpms.ko. I'm afraid things are not that simple. I have tried without success acpi_video.ko, dmps.ko, sysctl hw.acpi.reset_video and sysutils/vbetool. And what worries = me, X server cannon start on resumed system. From Xorg.log: (EE) NV(0): Failed to determine the amount of available video memory It looks like videcard just ignores any requests. --=20 Oleg Sharoyko From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 5 15:59: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 2E9FE1065679; Thu, 5 Aug 2010 15:59:40 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id C5BF88FC1A; Thu, 5 Aug 2010 15:59:39 +0000 (UTC) Received: by gyg4 with SMTP id 4so3183035gyg.13 for ; Thu, 05 Aug 2010 08:59: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=qujKzgS1L1L6tNSHytuGoNPYa9NOONgGyJ3SSGqHt6E=; b=H7Pwe4QKvnKdJcAO4mIkDzJtP53RE4sP9IaFYxs48LqEjKmwY4zospvG7jld58DI+e Xo7A1MgWkMEPlhTui/74vgl6FWZwO4h2k+xlMe2YFNzF/Syqu8j1t1cbxpAXlMcCFU7s ysWRlaGp56NGTquo6zZqijTqOmkd94ZZS/db0= 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=KbHnXNRa9xEhSSqK0ebxFl0UCS3vd+zQqeKaHfQLVw+1SjpKVzPJbojYWNLZ10KZLr WNpd/81xnbNfCZYdJA9kQYoAk8o30pre06EvOX15OZvfNXnQ/i1M/O9chDV92raOB5S5 H1iBdjj8L3/V6l7aijo16zTvSd9arA9xBCBio= MIME-Version: 1.0 Received: by 10.150.69.20 with SMTP id r20mr12345124yba.304.1281023977437; Thu, 05 Aug 2010 08:59:37 -0700 (PDT) Sender: mdf356@gmail.com Received: by 10.42.3.140 with HTTP; Thu, 5 Aug 2010 08:59:37 -0700 (PDT) In-Reply-To: <201008041455.26066.jhb@freebsd.org> References: <201008041026.17553.jhb@freebsd.org> <201008041455.26066.jhb@freebsd.org> Date: Thu, 5 Aug 2010 08:59:37 -0700 X-Google-Sender-Auth: kKXescuvGqjCHgcg21ILPweaFYI Message-ID: From: mdf@FreeBSD.org To: John Baldwin 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: Thu, 05 Aug 2010 15:59:40 -0000 On Wed, Aug 4, 2010 at 11:55 AM, John Baldwin wrote: > On Wednesday, August 04, 2010 12:20:31 pm mdf@freebsd.org wrote: >> On Wed, Aug 4, 2010 at 2:26 PM, John Baldwin wrote: >> > On Tuesday, August 03, 2010 9:46:16 pm mdf@freebsd.org wrote: >> >> 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 was >> >> >> > 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 objdu= mp -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 0x1= 04(%rbx) >> >> >> > =A0 =A0 =A0* Pin the thread in order to avoid problems with thre= ad migration. >> >> >> > =A0 =A0 =A0* Once that all verifies are passed about spinlocks o= wnership, >> >> >> > =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= :0x48,%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 =A0te= st =A0 %rax,%rax >> >> >> > =A0 =A0 =A0* Pin the thread in order to avoid problems with thre= ad migration. >> >> >> > =A0 =A0 =A0* Once that all verifies are passed about spinlocks o= wnership, >> >> >> > =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%ra= x,-0x110(%rbp) >> >> >> > ffffffff802db232: =A0 48 89 85 f8 fe ff ff =A0 =A0mov =A0 =A0%ra= x,-0x108(%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 f= fffffff802db33e >> >> >> > >> >> >> > 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 the >> >> >> > 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 t= he >> >> >> > thread id in panic_cpu is 2. =A0So clearly the thread was being = migrated >> >> >> > right around panic time. >> >> >> > >> >> >> > This is the amd64 kernel on stable/7. =A0I'm not sure exactly wh= at 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? =A0Could the hardware have re-or= dered >> >> >> > 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 = locations. >> >> >> >> >> >> Note this rule in section 8.2.2 of Volume 3A: >> >> >> >> >> >> =A0 =95 Reads may be reordered with older writes to different loca= tions but not >> >> >> =A0 =A0 with older writes to the same location. >> >> >> >> >> >> It is certainly true that sparc64 could reorder with RMO. =A0I bel= ieve ia64 >> >> >> could reorder as well. =A0Since sched_pin/unpin are frequently use= d to provide >> >> >> this sort of synchronization, we could use memory barriers in pin/= unpin >> >> >> 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 happening >> >> >> I think. >> >> > >> >> > However, to actually get a race you'd have to have an interrupt fir= e and >> >> > migrate you so that the speculative read was from the other CPU. = =A0However, I >> >> > don't think the speculative read would be preserved in that case. = =A0The CPU >> >> > has to return to a specific PC when it returns from the interrupt a= nd it has >> >> > no way of storing the state for what speculative reordering it migh= t be >> >> > doing, so presumably it is thrown away? =A0I suppose it is possible= that it >> >> > actually retires both instructions (but reordered) and then returns= to the PC >> >> > value after the read of listlocks after the interrupt. =A0However, = in that 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_pinned, >> >> > so I think the processor would have to discard the reordered read o= f >> >> > listlocks so it could safely resume execution at the 'incl' instruc= tion. >> >> > >> >> > The other nit there on x86 at least is that the incl instruction is= doing >> >> > both a read and a write and another rule in the section 8.2.2 is th= is: >> >> > >> >> > =A0=95 Reads are not reordered with other reads. >> >> > >> >> > That would seem to prevent the read of listlocks from passing the r= ead 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? >> > >> > Well, the architecture is defined in terms of the ISA, not the microco= de, per >> > se, so I think it would have to treat the read for the incl as being a= n earlier >> > read than 'spinlocks'. >> > >> >> I added the following: >> >> >> >> =A0 =A0 =A0 sched_pin(); >> >> =A0 =A0 =A0 lock_list =3D PCPU_GET(spinlocks); >> >> =A0 =A0 =A0 if (lock_list !=3D NULL && lock_list->ll_count !=3D 0) { >> >> + =A0 =A0 =A0 =A0 =A0 =A0 /* XXX debug for bug 67957 */ >> >> + =A0 =A0 =A0 =A0 =A0 =A0 mfence(); >> >> + =A0 =A0 =A0 =A0 =A0 =A0 lle =3D PCPU_GET(spinlocks); >> >> + =A0 =A0 =A0 =A0 =A0 =A0 if (lle !=3D lock_list) { >> >> + =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 lock_list, lle); >> >> + =A0 =A0 =A0 =A0 =A0 =A0 } >> >> + =A0 =A0 =A0 =A0 =A0 =A0 /* XXX end debug */ >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 sched_unpin(); >> >> >> >> =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. >> > >> > Actually, I would beg to differ in that case. =A0If PCPU_GET(spinlocks= ) >> > returns non-NULL, then it means that you hold a spin lock, >> >> ll_count is 0 for the "correct" pc_spinlocks and non-zero for the >> "wrong" one, though. =A0So I think it can be non-NULL but the current >> thread/CPU doesn't hold a spinlock. > > Hmm, does the 'lock_list' pointer value in the dump match 'lock_list' > from another CPU? Yes: (gdb) p panic_cpu $9 =3D 2 (gdb) p dumptid $12 =3D 100751 (gdb) p cpuhead.slh_first->pc_allcpu.sle_next->pc_curthread->td_tid $14 =3D 100751 (gdb) p *cpuhead.slh_first->pc_allcpu.sle_next $6 =3D { pc_curthread =3D 0xffffff00716d6960, pc_cpuid =3D 2, pc_spinlocks =3D 0xffffffff80803198, (gdb) p lock_list $2 =3D (struct lock_list_entry *) 0xffffffff80803fb0 (gdb) p *cpuhead.slh_first->pc_allcpu.sle_next->pc_allcpu.sle_next->pc_allc= pu.sle_next $8 =3D { pc_curthread =3D 0xffffff0005479960, pc_cpuid =3D 0, pc_spinlocks =3D 0xffffffff80803fb0, I.e. we're dumping on CPU 2, but the lock_list pointer that was saved in the dump matches that of CPU 0. Thanks, matthew From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 5 16:01:24 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 F2D651065677; Thu, 5 Aug 2010 16:01:23 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id B49D18FC29; Thu, 5 Aug 2010 16:01:23 +0000 (UTC) Received: by pwj4 with SMTP id 4so146938pwj.13 for ; Thu, 05 Aug 2010 09:01:23 -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=xbN1Fv55Pv2Qqf9Y1GMeInfDdiE+MyMyPYBzSM87bT0=; b=xQ8ltdfuoYujW2Stw09sJS7qzDQgn5ym1qlOQr5YjPLOppbwnUJn7GmvNw5Fehe98g hNq2S+gzFKvPlV8Z5xxTGg8ZS4q0sABYdBa3g7YCK193oW9V1oQ/sM1JsOLBe2U9EV2x 0jEUdObhegVfTpIGZkCo1b9Maw+kWdIPPdAO8= 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=KeggLZ6692lO5kOXwACPl8xZBMH5qfvlazOKys+WdyHmwhY9gMbDN/wMLzG/8tWC6O U6mAX2eY8IJFaa2R7CjMH75+CXGvreiWXk6I19Ag/fk6s+fdK+qpGN6/pSBUJMsN1KWz 8l8V8XqcXnOb7C4VZiJUPZXpQnhZS9eJzxYC0= MIME-Version: 1.0 Received: by 10.114.38.6 with SMTP id l6mr12485570wal.47.1281024082601; Thu, 05 Aug 2010 09:01:22 -0700 (PDT) Sender: mdf356@gmail.com Received: by 10.42.3.140 with HTTP; Thu, 5 Aug 2010 09:01:22 -0700 (PDT) In-Reply-To: References: <201007301031.34266.jhb@freebsd.org> <201008041026.17553.jhb@freebsd.org> Date: Thu, 5 Aug 2010 09:01:22 -0700 X-Google-Sender-Auth: yzOmpixTq9gMWJC5q2S6SJcAAkA Message-ID: From: mdf@FreeBSD.org To: mdf@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 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: Thu, 05 Aug 2010 16:01:24 -0000 On Wed, Aug 4, 2010 at 9:20 AM, wrote: > On Wed, Aug 4, 2010 at 2:26 PM, John Baldwin wrote: >> Actually, I would beg to differ in that case. =A0If PCPU_GET(spinlocks) >> returns non-NULL, then it means that you hold a spin lock, > > ll_count is 0 for the "correct" pc_spinlocks and non-zero for the > "wrong" one, though. =A0So I think it can be non-NULL but the current > thread/CPU doesn't hold a spinlock. > > I don't believe we have any code in the NMI handler. =A0I'm on vacation > today so I'll check tomorrow. I checked and ipi_nmi_handler() doesn't appear to have any local changes. I assume that's where I should look? Thanks, matthew From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 5 16:17: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 47C4D106568E; Thu, 5 Aug 2010 16:17:41 +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 9C2088FC23; Thu, 5 Aug 2010 16:17:40 +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 o75GHanL023307 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Aug 2010 19:17:36 +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 o75GHani076009; Thu, 5 Aug 2010 19:17:36 +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 o75GHai0076008; Thu, 5 Aug 2010 19:17:36 +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: Thu, 5 Aug 2010 19:17:36 +0300 From: Kostik Belousov To: mdf@freebsd.org Message-ID: <20100805161736.GG22295@deviant.kiev.zoral.com.ua> References: <201007301031.34266.jhb@freebsd.org> <201008041026.17553.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="O1CYMfe3aCBmNHuM" Content-Disposition: inline In-Reply-To: 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.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_05, 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: 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: Thu, 05 Aug 2010 16:17:41 -0000 --O1CYMfe3aCBmNHuM Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 05, 2010 at 09:01:22AM -0700, mdf@freebsd.org wrote: > On Wed, Aug 4, 2010 at 9:20 AM, wrote: > > On Wed, Aug 4, 2010 at 2:26 PM, John Baldwin wrote: > >> Actually, I would beg to differ in that case. =9AIf PCPU_GET(spinlocks) > >> returns non-NULL, then it means that you hold a spin lock, > > > > ll_count is 0 for the "correct" pc_spinlocks and non-zero for the > > "wrong" one, though. =9ASo I think it can be non-NULL but the current > > thread/CPU doesn't hold a spinlock. > > > > I don't believe we have any code in the NMI handler. =9AI'm on vacation > > today so I'll check tomorrow. >=20 > I checked and ipi_nmi_handler() doesn't appear to have any local > changes. I assume that's where I should look? I think that, in case you do not use hwpmc, you could add "iretq" as the first instruction of the nmi handler in exception.S and see whether the issue is reproducable. --O1CYMfe3aCBmNHuM Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkxa5CAACgkQC3+MBN1Mb4jYQQCg9Z+MoEIQH9Et1KshKjOMdAAn SvgAn1Bm81F/ZJIz76TF9CucVL8Fh3Vt =WE3y -----END PGP SIGNATURE----- --O1CYMfe3aCBmNHuM-- From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 5 17:11: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 5692F1065670 for ; Thu, 5 Aug 2010 17:11:42 +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 25B298FC1E for ; Thu, 5 Aug 2010 17:11:42 +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 B7A7046B51; Thu, 5 Aug 2010 13:11:41 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id D06A58A03C; Thu, 5 Aug 2010 13:11:40 -0400 (EDT) From: John Baldwin To: Oleg Sharoyko Date: Thu, 5 Aug 2010 11:45:53 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100217; KDE/4.4.5; amd64; ; ) References: <201008041112.28704.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201008051145.53737.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Thu, 05 Aug 2010 13:11:40 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: freebsd-hackers@freebsd.org Subject: Re: PCI config space is not restored upon resume (macbook pro) 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, 05 Aug 2010 17:11:42 -0000 On Thursday, August 05, 2010 11:30:23 am Oleg Sharoyko wrote: > On 4 August 2010 19:12, John Baldwin wrote: > > > Cool, I actually think that the ACPI PCI-PCI driver can just use the > > stock PCI-PCI bridge driver's suspend and resume methods. Can you try > > out this alternate patch instead? > > It works, and sure looks better than mine. I didn't know there's such a nice > way to inherit methods. > > > This sounds like the display just needs to be powered on via DPMS. > > You might be able to make this work via acpi_video and toggling the > > LCD status that way. You could also try dpms.ko. > > I'm afraid things are not that simple. I have tried without success > acpi_video.ko, > dmps.ko, sysctl hw.acpi.reset_video and sysutils/vbetool. And what worries me, > X server cannon start on resumed system. From Xorg.log: > > (EE) NV(0): Failed to determine the amount of available video memory > > It looks like videcard just ignores any requests. Are you using the nvidia-driver or the "nv" driver from X? -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 5 17:11: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 41DE6106566B; Thu, 5 Aug 2010 17:11:43 +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 139FA8FC22; Thu, 5 Aug 2010 17:11:43 +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 C18AF46B5B; Thu, 5 Aug 2010 13:11:42 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id A80148A04E; Thu, 5 Aug 2010 13:11:41 -0400 (EDT) From: John Baldwin To: mdf@freebsd.org Date: Thu, 5 Aug 2010 13:10:46 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100217; KDE/4.4.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201008051310.46994.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Thu, 05 Aug 2010 13:11:41 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx 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: Thu, 05 Aug 2010 17:11:43 -0000 On Thursday, August 05, 2010 12:01:22 pm mdf@freebsd.org wrote: > On Wed, Aug 4, 2010 at 9:20 AM, wrote: > > On Wed, Aug 4, 2010 at 2:26 PM, John Baldwin wrote: > >> Actually, I would beg to differ in that case. If PCPU_GET(spinlocks) > >> returns non-NULL, then it means that you hold a spin lock, > > > > ll_count is 0 for the "correct" pc_spinlocks and non-zero for the > > "wrong" one, though. So I think it can be non-NULL but the current > > thread/CPU doesn't hold a spinlock. > > > > I don't believe we have any code in the NMI handler. I'm on vacation > > today so I'll check tomorrow. > > I checked and ipi_nmi_handler() doesn't appear to have any local > changes. I assume that's where I should look? The tricky bits are all in the assembly rather than in C, probably in exception.S. However, if %gs were corrupt I would not expect it to point to another CPU's data, but garbage from userland. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 5 18:41: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 80BDA106564A; Thu, 5 Aug 2010 18:41:30 +0000 (UTC) (envelope-from osharoiko@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 399E68FC1B; Thu, 5 Aug 2010 18:41:29 +0000 (UTC) Received: by iwn10 with SMTP id 10so462546iwn.13 for ; Thu, 05 Aug 2010 11:41:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=HX3gCUSEc+ro0wDdJknlh5G+gz0LPw3EuR4uGjvjMxE=; b=Qb2nAxMMpJoGbEcSPziCxX4yyQsKW//EHfYGydc33zVGUBqCmkrlE6wSpsaf0Rnmq3 W8OFLGK5gs9dmZsSiOpRe1q3NzW78odsr26i5sfJOXJ6Q9atW24gkjBXQCBcoMWOfp2R uACDCoj5tW7yYc2GQrRPsGyBmGJe8P5apbtlY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=JAhDDBqQ+goLePKjwNttH3D9zVr40/AW5z91fzHcnsDKE2P1iP5tJcz1LJnXsORMDK heATDl/Rl2bOJaarX0GQDtXaEYN6bLPBWx7tqjJDuJ68iOa5flKUQ+GQ+SJmLBxl1wiZ vkwoOXO6OGfTGcl2mSVR+VmFYPicgUzHMQl4c= MIME-Version: 1.0 Received: by 10.231.34.70 with SMTP id k6mr12482427ibd.25.1281033686772; Thu, 05 Aug 2010 11:41:26 -0700 (PDT) Received: by 10.231.168.20 with HTTP; Thu, 5 Aug 2010 11:41:26 -0700 (PDT) In-Reply-To: <201008051145.53737.jhb@freebsd.org> References: <201008041112.28704.jhb@freebsd.org> <201008051145.53737.jhb@freebsd.org> Date: Thu, 5 Aug 2010 22:41:26 +0400 Message-ID: From: Oleg Sharoyko To: John Baldwin Content-Type: text/plain; charset=UTF-8 Cc: freebsd-hackers@freebsd.org Subject: Re: PCI config space is not restored upon resume (macbook pro) 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, 05 Aug 2010 18:41:30 -0000 On 5 August 2010 19:45, John Baldwin wrote: >> I'm afraid things are not that simple. I have tried without success >> acpi_video.ko, >> dmps.ko, sysctl hw.acpi.reset_video and sysutils/vbetool. And what worries me, >> X server cannon start on resumed system. From Xorg.log: >> (EE) NV(0): Failed to determine the amount of available video memory >> It looks like videcard just ignores any requests. > Are you using the nvidia-driver or the "nv" driver from X? Have tried both. Error above is from "nv", and "nvidia" told that it couldn't copy video bios and paniced. I have also tried "vesa" which gave rather strange records in Xorg.0.log (see [1] for complete log (63Mb)). Here some interesting lines: (--) PCI:*(0:1:0:0) 10de:0407:106b:00a0 nVidia Corporation G84 [GeForce 8600M GT] rev 161, Mem @ 0x92000000/16777216, 0x80000000/268435456, 0x90000000/33554432, I/O @ 0x00005000/128, BIOS @ 0x????????/65536 (==) VESA(0): Write-combining range (0xa0000,0x20000) was already clear (==) VESA(0): Write-combining range (0xc0000,0x40000) was already clear (II) VESA(0): Primary V_BIOS segment is: 0xc000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (II) VESA(0): VESA BIOS detected (II) VESA(0): VESA VBE Version 165.165 (II) VESA(0): VESA VBE Total Mem: 2713920 kB (II) VESA(0): VESA VBE OEM: (II) VESA(0): VESA VBE OEM Software Rev: 165.165 (II) VESA(0): VESA VBE OEM Vendor: (II) VESA(0): VESA VBE OEM Product: (II) VESA(0): VESA VBE OEM Product Rev: (EE) VESA(0): Driver can't support depth 24 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear The last line repeats 983070 times. Strings with were very long, I truncated them for readability. This is odd. 1. http://www.oleg-sharoyko.net/files/freebsd/pci_config.201008/Xorg.vesa.log -- Oleg Sharoyko From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 5 19:14: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 BF8221065677; Thu, 5 Aug 2010 19:14:57 +0000 (UTC) (envelope-from jeremie@le-hen.org) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by mx1.freebsd.org (Postfix) with ESMTP id 888408FC29; Thu, 5 Aug 2010 19:14:54 +0000 (UTC) Received: from endor.tataz.chchile.org (unknown [82.233.239.98]) by smtp5-g21.free.fr (Postfix) with ESMTP id C3F95D4803C; Thu, 5 Aug 2010 21:14:47 +0200 (CEST) Received: from felucia.tataz.chchile.org (felucia.tataz.chchile.org [192.168.1.9]) by endor.tataz.chchile.org (Postfix) with ESMTP id 2CAB733F19; Thu, 5 Aug 2010 19:14:46 +0000 (UTC) Received: by felucia.tataz.chchile.org (Postfix, from userid 1000) id 2A2A8A124B; Thu, 5 Aug 2010 19:14:46 +0000 (UTC) Date: Thu, 5 Aug 2010 21:14:46 +0200 From: Jeremie Le Hen To: Alexander Kabaev Message-ID: <20100805191446.GJ14016@felucia.tataz.chchile.org> References: <20100803150545.GH14016@felucia.tataz.chchile.org> <20100803114651.651e0ea4@kan.dnsalias.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100803114651.651e0ea4@kan.dnsalias.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: kan@FreeBSD.org, freebsd-hackers@FreeBSD.org, Jeremie Le Hen Subject: Re: Add -lssp_nonshared to GCC's LIB_SPEC unconditionally 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, 05 Aug 2010 19:14:57 -0000 On Tue, Aug 03, 2010 at 11:46:51AM -0400, Alexander Kabaev wrote: > > I have no objection, but think we should cave in and investigate the > possibility of using linker script wrapping libc.so in FreeBSD-9.0: > > Below is Linux' counterpart: > > /* GNU ld script > Use the shared library, but some functions are only in > the static library, so try that secondarily. */ > OUTPUT_FORMAT(elf32-i386) > GROUP ( /lib/libc.so.6 /usr/lib/libc_nonshared.a AS_NEEDED > ( /lib/ld-linux.so.2 ) ) Ok. For now can you commit the proposed modification. I'll try to make a patch with your proposal. Thanks. Regards, -- Jeremie Humans are born free and equal. But some are more equal than others. Coluche From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 5 19:46:33 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 5A396106567F; Thu, 5 Aug 2010 19:46:33 +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 1AFDB8FC25; Thu, 5 Aug 2010 19:46:33 +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 94F6746B86; Thu, 5 Aug 2010 15:46:32 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 220D68A050; Thu, 5 Aug 2010 15:45:58 -0400 (EDT) From: John Baldwin To: mdf@freebsd.org Date: Thu, 5 Aug 2010 13:12:25 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100217; KDE/4.4.5; amd64; ; ) References: <201008041455.26066.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Message-Id: <201008051312.25854.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Thu, 05 Aug 2010 15:46:27 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx 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: Thu, 05 Aug 2010 19:46:33 -0000 On Thursday, August 05, 2010 11:59:37 am mdf@freebsd.org wrote: > On Wed, Aug 4, 2010 at 11:55 AM, John Baldwin wrote: > > On Wednesday, August 04, 2010 12:20:31 pm mdf@freebsd.org wrote: > >> On Wed, Aug 4, 2010 at 2:26 PM, John Baldwin wrote: > >> > On Tuesday, August 03, 2010 9:46:16 pm mdf@freebsd.org wrote: > >> >> On Fri, Jul 30, 2010 at 2:31 PM, John Baldwin wro= te: > >> >> > 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 claim= s=20 it was > >> >> >> > held by is in fact sometimes not possible to keep the lock, li= ke: > >> >> >> > > >> >> >> > thread_lock(td); > >> >> >> > td->td_flags &=3D ~TDF_SELECT; > >> >> >> > thread_unlock(td); > >> >> >> > > >> >> >> > What I was wondering is, even though the assembly I see in=20 objdump -S > >> >> >> > for witness_warn has the increment of td_pinned before the=20 PCPU_GET: > >> >> >> > > >> >> >> > ffffffff802db210: 65 48 8b 1c 25 00 00 mov %gs:0x0,%rbx > >> >> >> > ffffffff802db217: 00 00 > >> >> >> > ffffffff802db219: ff 83 04 01 00 00 incl 0x104(%rbx) > >> >> >> > * Pin the thread in order to avoid problems with thread=20 migration. > >> >> >> > * Once that all verifies are passed about spinlocks=20 ownership, > >> >> >> > * the thread is in a safe path and it can be unpinned. > >> >> >> > */ > >> >> >> > sched_pin(); > >> >> >> > lock_list =3D PCPU_GET(spinlocks); > >> >> >> > ffffffff802db21f: 65 48 8b 04 25 48 00 mov %gs:0x48,%r= ax > >> >> >> > ffffffff802db226: 00 00 > >> >> >> > if (lock_list !=3D NULL && lock_list->ll_count !=3D 0) { > >> >> >> > ffffffff802db228: 48 85 c0 test %rax,%rax > >> >> >> > * Pin the thread in order to avoid problems with thread=20 migration. > >> >> >> > * Once that all verifies are passed about spinlocks=20 ownership, > >> >> >> > * the thread is in a safe path and it can be unpinned. > >> >> >> > */ > >> >> >> > sched_pin(); > >> >> >> > lock_list =3D PCPU_GET(spinlocks); > >> >> >> > ffffffff802db22b: 48 89 85 f0 fe ff ff mov =20 %rax,-0x110(%rbp) > >> >> >> > ffffffff802db232: 48 89 85 f8 fe ff ff mov =20 %rax,-0x108(%rbp) > >> >> >> > if (lock_list !=3D NULL && lock_list->ll_count !=3D 0) { > >> >> >> > ffffffff802db239: 0f 84 ff 00 00 00 je =20 ffffffff802db33e > >> >> >> > > >> >> >> > ffffffff802db23f: 44 8b 60 50 mov 0x50(%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 ha= ve=20 a > >> >> >> > lock leak at the indicated point, but in one instance I can se= e=20 in the > >> >> >> > dump that the lock_list local from witness_warn is from the pc= pu > >> >> >> > structure for CPU 0 (and I was warned about sched lock 0), but= =20 the > >> >> >> > thread id in panic_cpu is 2. So clearly the thread was being= =20 migrated > >> >> >> > right around panic time. > >> >> >> > > >> >> >> > This is the amd64 kernel on stable/7. I'm not sure exactly wh= at=20 kind > >> >> >> > of hardware; it's a 4-way Intel chip from about 3 or 4 years a= go=20 IIRC. > >> >> >> > > >> >> >> > So... do we need some kind of barrier in the code for sched_pi= n()=20 for > >> >> >> > it to really do what it claims? Could the hardware have re- ordered > >> >> >> > the "mov %gs:0x48,%rax" PCPU_GET to before the sched_pin() > >> >> >> > increment? > >> >> >> > >> >> >> Hmmm, I think it might be able to because they refer to differen= t=20 locations. > >> >> >> > >> >> >> Note this rule in section 8.2.2 of Volume 3A: > >> >> >> > >> >> >> =95 Reads may be reordered with older writes to different loca= tions=20 but not > >> >> >> with older writes to the same location. > >> >> >> > >> >> >> It is certainly true that sparc64 could reorder with RMO. I=20 believe ia64 > >> >> >> could reorder as well. Since sched_pin/unpin are frequently use= d=20 to provide > >> >> >> this sort of synchronization, we could use memory barriers in=20 pin/unpin > >> >> >> like so: > >> >> >> > >> >> >> sched_pin() > >> >> >> { > >> >> >> td->td_pinned =3D atomic_load_acq_int(&td->td_pinned) + 1; > >> >> >> } > >> >> >> > >> >> >> sched_unpin() > >> >> >> { > >> >> >> atomic_store_rel_int(&td->td_pinned, td->td_pinned - 1); > >> >> >> } > >> >> >> > >> >> >> We could also just use atomic_add_acq_int() and=20 atomic_sub_rel_int(), but they > >> >> >> are slightly more heavyweight, though it would be more clear wha= t=20 is happening > >> >> >> I think. > >> >> > > >> >> > However, to actually get a race you'd have to have an interrupt f= ire=20 and > >> >> > migrate you so that the speculative read was from the other CPU.= =20 However, I > >> >> > don't think the speculative read would be preserved in that case.= =20 The CPU > >> >> > has to return to a specific PC when it returns from the interrupt= =20 and it has > >> >> > no way of storing the state for what speculative reordering it mi= ght=20 be > >> >> > doing, so presumably it is thrown away? I suppose it is possible= =20 that it > >> >> > actually retires both instructions (but reordered) and then retur= ns=20 to the PC > >> >> > value after the read of listlocks after the interrupt. However, = in=20 that case > >> >> > the scheduler would not migrate as it would see td_pinned !=3D 0.= To=20 get the > >> >> > race you have to have the interrupt take effect prior to modifyin= g=20 td_pinned, > >> >> > so I think the processor would have to discard the reordered read= of > >> >> > listlocks so it could safely resume execution at the 'incl'=20 instruction. > >> >> > > >> >> > The other nit there on x86 at least is that the incl instruction = is=20 doing > >> >> > both a read and a write and another rule in the section 8.2.2 is= =20 this: > >> >> > > >> >> > =95 Reads are not reordered with other reads. > >> >> > > >> >> > That would seem to prevent the read of listlocks from passing the= =20 read of > >> >> > td_pinned in the incl instruction on x86. > >> >> > >> >> I wonder how that's interpreted in the microcode, though? I.e. if = the > >> >> incr instruction decodes to load, add, store, does the h/w allow the > >> >> later reads to pass the final store? > >> > > >> > Well, the architecture is defined in terms of the ISA, not the=20 microcode, per > >> > se, so I think it would have to treat the read for the incl as being= an=20 earlier > >> > read than 'spinlocks'. > >> > > >> >> I added the following: > >> >> > >> >> sched_pin(); > >> >> lock_list =3D PCPU_GET(spinlocks); > >> >> if (lock_list !=3D NULL && lock_list->ll_count !=3D 0) { > >> >> + /* XXX debug for bug 67957 */ > >> >> + mfence(); > >> >> + lle =3D PCPU_GET(spinlocks); > >> >> + if (lle !=3D lock_list) { > >> >> + panic("Bug 67957: had lock list %p, now %p\n", > >> >> + lock_list, lle); > >> >> + } > >> >> + /* XXX end debug */ > >> >> sched_unpin(); > >> >> > >> >> /* > >> >> > >> >> ... and the panic triggered. I think it's more likely that some > >> >> barrier is needed in sched_pin() than that %gs is getting corrupted > >> >> but can always be dereferenced. > >> > > >> > Actually, I would beg to differ in that case. If PCPU_GET(spinlocks) > >> > returns non-NULL, then it means that you hold a spin lock, > >> > >> ll_count is 0 for the "correct" pc_spinlocks and non-zero for the > >> "wrong" one, though. So I think it can be non-NULL but the current > >> thread/CPU doesn't hold a spinlock. > > > > Hmm, does the 'lock_list' pointer value in the dump match 'lock_list' > > from another CPU? >=20 > Yes: >=20 > (gdb) p panic_cpu > $9 =3D 2 > (gdb) p dumptid > $12 =3D 100751 > (gdb) p cpuhead.slh_first->pc_allcpu.sle_next->pc_curthread->td_tid > $14 =3D 100751 >=20 > (gdb) p *cpuhead.slh_first->pc_allcpu.sle_next > $6 =3D { > pc_curthread =3D 0xffffff00716d6960, > pc_cpuid =3D 2, > pc_spinlocks =3D 0xffffffff80803198, >=20 > (gdb) p lock_list > $2 =3D (struct lock_list_entry *) 0xffffffff80803fb0 >=20 > (gdb) p *cpuhead.slh_first->pc_allcpu.sle_next->pc_allcpu.sle_next- >pc_allcpu.sle_next > $8 =3D { > pc_curthread =3D 0xffffff0005479960, > pc_cpuid =3D 0, > pc_spinlocks =3D 0xffffffff80803fb0, >=20 > I.e. we're dumping on CPU 2, but the lock_list pointer that was saved > in the dump matches that of CPU 0. Can you print out the tid's for the two curthreads? It's not impossible th= at=20 the thread migrated after calling panic. In fact we force threads to CPU 0= =20 during shutdown. =2D-=20 John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 5 20:14:38 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 E6A2B1065679; Thu, 5 Aug 2010 20:14:38 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 89A8D8FC13; Thu, 5 Aug 2010 20:14:38 +0000 (UTC) Received: by ywf9 with SMTP id 9so3275303ywf.13 for ; Thu, 05 Aug 2010 13:14:37 -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=rRQ+JFjhhcogWQNgD/AMDZQnKwCoAVxVk6nKg+x5y9E=; b=ekBivTMeqjG+uqG6Xc/8A6rVQG12dDYb06VYqX/LHZ/v1Qpnn/ZvVeG3gUWwvw+nul ZG0COcoJVLE1Smwvy8JvncZ80B5UElLnpzVhG60kVAxTyf8oA3ErEuQwLqohV4yrCuT4 l6/3zlNf9J3/Mxug9d3gAPvtiHK6IDT7/355k= 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=WW+S6mb++OSHct7j1Wb1CKyhO50b7YYGVKdFa3cpfzfAwbYTYXkbpY0Trr/9/XS3B8 zSTsJ/YvBBMLVXF8FyRC/Q2QR67sq6ci0HrswjADG53VXVd2Oaz6odPKOsmppWckhw6S Ucgp95wz6tyhf0Y+An76FJGfW+8B3FBF0tYTE= MIME-Version: 1.0 Received: by 10.150.13.15 with SMTP id 15mr13145253ybm.40.1281039277755; Thu, 05 Aug 2010 13:14:37 -0700 (PDT) Sender: mdf356@gmail.com Received: by 10.42.3.140 with HTTP; Thu, 5 Aug 2010 13:14:37 -0700 (PDT) In-Reply-To: <201008051312.25854.jhb@freebsd.org> References: <201008041455.26066.jhb@freebsd.org> <201008051312.25854.jhb@freebsd.org> Date: Thu, 5 Aug 2010 13:14:37 -0700 X-Google-Sender-Auth: aMCHHOwGEKrg8ig0f10WvWyHVEA Message-ID: From: mdf@FreeBSD.org To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 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: Thu, 05 Aug 2010 20:14:39 -0000 >> (gdb) p panic_cpu >> $9 =3D 2 >> (gdb) p dumptid >> $12 =3D 100751 >> (gdb) p cpuhead.slh_first->pc_allcpu.sle_next->pc_curthread->td_tid >> $14 =3D 100751 >> >> (gdb) p *cpuhead.slh_first->pc_allcpu.sle_next >> $6 =3D { >> =A0 pc_curthread =3D 0xffffff00716d6960, >> =A0 pc_cpuid =3D 2, >> =A0 pc_spinlocks =3D 0xffffffff80803198, >> >> (gdb) p lock_list >> $2 =3D (struct lock_list_entry *) 0xffffffff80803fb0 >> >> (gdb) p *cpuhead.slh_first->pc_allcpu.sle_next->pc_allcpu.sle_next- >>pc_allcpu.sle_next >> $8 =3D { >> =A0 pc_curthread =3D 0xffffff0005479960, >> =A0 pc_cpuid =3D 0, >> =A0 pc_spinlocks =3D 0xffffffff80803fb0, >> >> I.e. we're dumping on CPU 2, but the lock_list pointer that was saved >> in the dump matches that of CPU 0. > > Can you print out the tid's for the two curthreads? =A0It's not impossibl= e that > the thread migrated after calling panic. =A0In fact we force threads to C= PU 0 > during shutdown. dumptid matches the pc_curthread for CPU 2 and is printed above. The lock_list local variable matches the PCPU for CPU 0, which has tid: (gdb) p cpuhead.slh_first->pc_allcpu.sle_next->pc_allcpu.sle_next->pc_allcp= u.sle_next->pc_curthread->td_tid $2 =3D 100005 (gdb) p cpuhead.slh_first->pc_allcpu.sle_next->pc_allcpu.sle_next->pc_allcp= u.sle_next->pc_curthread->td_proc->p_comm $3 =3D "idle: cpu0\000\000\000\000\000\000\000\000\000" Note that lock_list->ll_count is now 0, but of course wasn't when we panic'd. Also, the panic message showed "exclusive spin mutex sched lock 0 (sched lock) r =3D 0 (0xffffffff806cf640) locked @ /build/mnt/src/sys/kern/sys_generic.c:826"; i.e. the lock was for CPU 0 as well. If we truly were returning to user space with that lock held it would still be held and we'd still be on CPU 0. Cheers, matthew From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 5 20:19: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 3E4611065670 for ; Thu, 5 Aug 2010 20:19:57 +0000 (UTC) (envelope-from chzander@nvidia.com) Received: from hqemgate03.nvidia.com (hqemgate03.nvidia.com [216.228.121.140]) by mx1.freebsd.org (Postfix) with ESMTP id 1E9138FC08 for ; Thu, 5 Aug 2010 20:19:56 +0000 (UTC) Received: from hqnvupgp02.nvidia.com (Not Verified[172.17.98.15]) by hqemgate03.nvidia.com id ; Thu, 05 Aug 2010 13:03:24 -0700 Received: from hqemfe02.nvidia.com ([172.17.108.22]) by hqnvupgp02.nvidia.com (PGP Universal service); Thu, 05 Aug 2010 12:59:53 -0700 X-PGP-Universal: processed; by hqnvupgp02.nvidia.com on Thu, 05 Aug 2010 12:59:53 -0700 Received: from nvidia.com ([172.20.144.16]) by hqemfe02.nvidia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Aug 2010 12:59:53 -0700 Date: Thu, 5 Aug 2010 13:00:22 -0700 From: Christian Zander To: Oleg Sharoyko Message-ID: <20100805200022.GB3610@panther.nvidia.com> References: <201008041112.28704.jhb@freebsd.org> <201008051145.53737.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-NVConfidentiality: public X-OriginalArrivalTime: 05 Aug 2010 19:59:53.0352 (UTC) FILETIME=[C509B880:01CB34D8] Cc: "freebsd-hackers@freebsd.org" Subject: Re: PCI config space is not restored upon resume (macbook pro) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Christian Zander List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 20:19:57 -0000 On Thu, Aug 05, 2010 at 11:41:26AM -0700, Oleg Sharoyko wrote: (...) > >> I'm afraid things are not that simple. I have tried without success > >> acpi_video.ko, > >> dmps.ko, sysctl hw.acpi.reset_video and sysutils/vbetool. And what worries me, > >> X server cannon start on resumed system. From Xorg.log: > >> (EE) NV(0): Failed to determine the amount of available video memory > >> It looks like videcard just ignores any requests. > > Are you using the nvidia-driver or the "nv" driver from X? > > Have tried both. Error above is from "nv", and "nvidia" told that it couldn't > copy video bios and paniced. I have also tried "vesa" which gave rather > strange records in Xorg.0.log (see [1] for complete log (63Mb)). Here > some interesting lines: > > (--) PCI:*(0:1:0:0) 10de:0407:106b:00a0 nVidia Corporation G84 > [GeForce 8600M GT] rev 161, Mem @ 0x92000000/16777216, > 0x80000000/268435456, 0x90000000/33554432, I/O @ 0x00005000/128, BIOS > @ 0x????????/65536 > (==) VESA(0): Write-combining range (0xa0000,0x20000) was already clear > (==) VESA(0): Write-combining range (0xc0000,0x40000) was already clear > (II) VESA(0): Primary V_BIOS segment is: 0xc000 > (==) VESA(0): Write-combining range (0x0,0x1000) was already clear > (==) VESA(0): Write-combining range (0x0,0x1000) was already clear > (==) VESA(0): Write-combining range (0x0,0x1000) was already clear > (II) VESA(0): VESA BIOS detected > (II) VESA(0): VESA VBE Version 165.165 > (II) VESA(0): VESA VBE Total Mem: 2713920 kB > (II) VESA(0): VESA VBE OEM: > (II) VESA(0): VESA VBE OEM Software Rev: 165.165 > (II) VESA(0): VESA VBE OEM Vendor: > (II) VESA(0): VESA VBE OEM Product: > (II) VESA(0): VESA VBE OEM Product Rev: > (EE) VESA(0): Driver can't support depth 24 > (==) VESA(0): Write-combining range (0x0,0x1000) was already clear > > The last line repeats 983070 times. Strings with were very > long, I truncated them for readability. This is odd. > > 1. http://www.oleg-sharoyko.net/files/freebsd/pci_config.201008/Xorg.vesa.log > Neither the `nv' nor the `vesa' driver have support for power management. You'll typically only be able to get X back with those drivers if you're starting it from scratch following an S4 cycle, or an S3 cycle that involved a POST (either issued by the SBIOS or via software). When using the NVIDIA driver, you will need to make sure that you're using 256.44, you'll need to be running X at the time of entry to S3/S4, and you'll need to make sure you've switched away from X's VT (this didn't happen automatically on FreeBSD last time I checked). However, NVIDIA suspend/resume is largely untested on FreeBSD. Thanks, -- christian zander ch?zander@nvidia.com From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 5 20:24:02 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id E70C7106567A; Thu, 5 Aug 2010 20:24:01 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-hackers@freebsd.org Date: Thu, 5 Aug 2010 16:23:41 -0400 User-Agent: KMail/1.6.2 References: <201008051145.53737.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201008051623.53328.jkim@FreeBSD.org> Cc: Oleg Sharoyko Subject: Re: PCI config space is not restored upon resume (macbook pro) 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, 05 Aug 2010 20:24:02 -0000 On Thursday 05 August 2010 02:41 pm, Oleg Sharoyko wrote: > On 5 August 2010 19:45, John Baldwin wrote: > >> I'm afraid things are not that simple. I have tried without > >> success acpi_video.ko, > >> dmps.ko, sysctl hw.acpi.reset_video and sysutils/vbetool. And > >> what worries me, X server cannon start on resumed system. From > >> Xorg.log: (EE) NV(0): Failed to determine the amount of > >> available video memory It looks like videcard just ignores any > >> requests. > > > > Are you using the nvidia-driver or the "nv" driver from X? > > Have tried both. Error above is from "nv", and "nvidia" told that > it couldn't copy video bios and paniced. I have also tried "vesa" > which gave rather strange records in Xorg.0.log (see [1] for > complete log (63Mb)). Here some interesting lines: > > (--) PCI:*(0:1:0:0) 10de:0407:106b:00a0 nVidia Corporation G84 > [GeForce 8600M GT] rev 161, Mem @ 0x92000000/16777216, > 0x80000000/268435456, 0x90000000/33554432, I/O @ 0x00005000/128, > BIOS @ 0x????????/65536 > (==) VESA(0): Write-combining range (0xa0000,0x20000) was already > clear (==) VESA(0): Write-combining range (0xc0000,0x40000) was > already clear (II) VESA(0): Primary V_BIOS segment is: 0xc000 > (==) VESA(0): Write-combining range (0x0,0x1000) was already clear > (==) VESA(0): Write-combining range (0x0,0x1000) was already clear > (==) VESA(0): Write-combining range (0x0,0x1000) was already clear > (II) VESA(0): VESA BIOS detected > (II) VESA(0): VESA VBE Version 165.165 > (II) VESA(0): VESA VBE Total Mem: 2713920 kB > (II) VESA(0): VESA VBE OEM: > (II) VESA(0): VESA VBE OEM Software Rev: 165.165 > (II) VESA(0): VESA VBE OEM Vendor: > (II) VESA(0): VESA VBE OEM Product: > (II) VESA(0): VESA VBE OEM Product Rev: > (EE) VESA(0): Driver can't support depth 24 > (==) VESA(0): Write-combining range (0x0,0x1000) was already clear > > The last line repeats 983070 times. Strings with were very > long, I truncated them for readability. This is odd. > > 1. > http://www.oleg-sharoyko.net/files/freebsd/pci_config.201008/Xorg.v >esa.log Basically, it means the video ROM is not accessible or failed to POST. FYI, Mac's don't have "BIOS" any more. It is just emulated via "Boot Camp". Thus, my guess is the BIOS emulation is not being restored and/or video ROM is not shadowed properly. Jung-uk Kim From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 5 20:35:17 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id A154D10656B0; Thu, 5 Aug 2010 20:35:16 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-hackers@freebsd.org, Christian Zander Date: Thu, 5 Aug 2010 16:35:01 -0400 User-Agent: KMail/1.6.2 References: <20100805200022.GB3610@panther.nvidia.com> In-Reply-To: <20100805200022.GB3610@panther.nvidia.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201008051635.09273.jkim@FreeBSD.org> Cc: "freebsd-hackers@freebsd.org" , Oleg Sharoyko Subject: Re: PCI config space is not restored upon resume (macbook pro) 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, 05 Aug 2010 20:35:17 -0000 On Thursday 05 August 2010 04:00 pm, Christian Zander wrote: > When using the NVIDIA driver, you will need to make sure that > you're using 256.44, you'll need to be running X at the time of > entry to S3/S4, and you'll need to make sure you've switched > away from X's VT (this didn't happen automatically on FreeBSD > last time I checked). We *do* switch VTs unless it is explicitly turned off by 'sysctl hw.syscons.sc_no_suspend_vtswitch=1'. However, it was slightly broken but I fixed it recently. http://svn.freebsd.org/viewvc/base?view=revision&revision=210303 > However, NVIDIA suspend/resume is largely untested on FreeBSD. That's very sad news. :-( Jung-uk Kim From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 5 20:43: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 EDAF41065676 for ; Thu, 5 Aug 2010 20:43:49 +0000 (UTC) (envelope-from chzander@nvidia.com) Received: from hqemgate04.nvidia.com (hqemgate04.nvidia.com [216.228.121.35]) by mx1.freebsd.org (Postfix) with ESMTP id CF0638FC16 for ; Thu, 5 Aug 2010 20:43:49 +0000 (UTC) Received: from hqnvupgp04.nvidia.com (Not Verified[172.20.161.48]) by hqemgate04.nvidia.com id ; Thu, 05 Aug 2010 13:41:24 -0700 Received: from hqemfe02.nvidia.com ([172.17.108.22]) by hqnvupgp04.nvidia.com (PGP Universal service); Thu, 05 Aug 2010 13:43:49 -0700 X-PGP-Universal: processed; by hqnvupgp04.nvidia.com on Thu, 05 Aug 2010 13:43:49 -0700 Received: from nvidia.com ([172.20.144.16]) by hqemfe02.nvidia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Aug 2010 13:43:48 -0700 Date: Thu, 5 Aug 2010 13:44:17 -0700 From: Christian Zander To: Jung-uk Kim Message-ID: <20100805204417.GF3610@panther.nvidia.com> References: <20100805200022.GB3610@panther.nvidia.com> <201008051635.09273.jkim@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201008051635.09273.jkim@FreeBSD.org> User-Agent: Mutt/1.4.2.3i X-NVConfidentiality: public X-OriginalArrivalTime: 05 Aug 2010 20:43:48.0914 (UTC) FILETIME=[E7F49120:01CB34DE] Cc: Christian Zander , "freebsd-hackers@freebsd.org" , Oleg Sharoyko Subject: Re: PCI config space is not restored upon resume (macbook pro) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Christian Zander List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 20:43:50 -0000 On Thu, Aug 05, 2010 at 01:35:01PM -0700, Jung-uk Kim wrote: (...) > > When using the NVIDIA driver, you will need to make sure that > > you're using 256.44, you'll need to be running X at the time of > > entry to S3/S4, and you'll need to make sure you've switched > > away from X's VT (this didn't happen automatically on FreeBSD > > last time I checked). > > We *do* switch VTs unless it is explicitly turned off by 'sysctl > hw.syscons.sc_no_suspend_vtswitch=1'. However, it was slightly > broken but I fixed it recently. > > http://svn.freebsd.org/viewvc/base?view=revision&revision=210303 > OK. It didn't happen on FreeBSD 8.1 when I tried recently. That's the only recent data point I have, though. > > However, NVIDIA suspend/resume is largely untested on FreeBSD. > > That's very sad news. :-( > Well, it's not entirely by choice. I have yet to find a system on which FreeBSD comes back from S3. In any case, the driver paths taken on FreeBSD are nearly identical to those taken on Linux, so given a sufficiently stable host, mileage should be the same on both platforms -- christian zander ch?zander@nvidia.com From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 5 21:49: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 756951065674 for ; Thu, 5 Aug 2010 21:49:50 +0000 (UTC) (envelope-from bf1783@googlemail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id D56ED8FC0C for ; Thu, 5 Aug 2010 21:49:49 +0000 (UTC) Received: by wyj26 with SMTP id 26so8853383wyj.13 for ; Thu, 05 Aug 2010 14:49:48 -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; bh=ySi0I2PXp3xKs39ccu5+RXeRNXdZUliuqBE4N6H/Eng=; b=G6KCegIjytbA46kJpP7mgBitXDS/qIgXVXiCk0rpE13vDYwjhafo4BHbj4DEz8+EmJ w6mEkPf+7T+++xH1dDXxJE8huaPYh5Xy0Ka3AoCGSM06x4GDC5bL2tfFQN5F5kJeI9Uq msSJN1G7uRpYTpsz0kXETpvXezSmZEBfTOVAo= 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; b=qCeXytFTHi5A+dWey5Bq0rs3O0mINSOyRgWu0HYeLDj7EHCyaKv6FJo6PGWkAIl8Qb YB6F/Q5QyGyKSIb6MMbNN3H0jpc5GqvdSDUoPbXo4Aqh3A2qHRhMU8gmxNfPAx/YjBtU 8f/WGyUo/sK22QdL4+aDi8dlK/fx1DRL7roYk= MIME-Version: 1.0 Received: by 10.227.134.136 with SMTP id j8mr9812706wbt.206.1281044988612; Thu, 05 Aug 2010 14:49:48 -0700 (PDT) Received: by 10.216.183.212 with HTTP; Thu, 5 Aug 2010 14:49:48 -0700 (PDT) Date: Thu, 5 Aug 2010 21:49:48 +0000 Message-ID: From: "b. f." To: freebsd-hackers@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1 Cc: gerald@FreeBSD.org, Jeremie Le Hen Subject: Re: Add -lssp_nonshared to GCC's LIB_SPEC unconditionally 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: Thu, 05 Aug 2010 21:49:50 -0000 On Tue Aug 3 15:22:00 UTC 2010, Jeremie Le Hen wrote: ... >I therefore propose the following change to always link in >libssp_nonshared.a. I think this change is harmless when the symbol is >not needed in one of the objects linked together since the linker won't >pull in the library member "ssp-local.o" in the target object. Will this do the right thing when the base system is built WITHOUT_SSP? How about the case of WITHOUT_DYNAMICROOT/NOSHARED/NO_SHARED=yes, with and without this change? Are changes to the specs of the lang/gcc* ports needed? What about clang? b. From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 6 04:01:44 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 EB9BF1065673; Fri, 6 Aug 2010 04:01:44 +0000 (UTC) (envelope-from osharoiko@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 8FD568FC15; Fri, 6 Aug 2010 04:01:44 +0000 (UTC) Received: by iwn10 with SMTP id 10so1046732iwn.13 for ; Thu, 05 Aug 2010 21:01:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=6z8JZYhTpdviExtNb2kphUKgcLwPwdrHtDLr2nr/rGs=; b=LiiETCH6zQgzM0mP5zIhUByh34IvFQQBxNU4OlGSiARNK+AnKIERIyL6m1jEcOOGX1 IVQGzX4Wf81YPdK1wZI6z1ULjqPbJnidZRmAh9qYA0aEAzYfm3VXB194MMk2nIZHn5EU MdQKQX0I61qW6ywQY6IXx1h1vksKp1Rtn4IcU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=M/BigOxnl0agFaIVyCWibDdqT3I2cYH4mz8M9W7L2m5yL+CWPEbSVgfmy5p1dYRgRH Z/HcihImXo/f9bH2IAc1r6PgZ29kX/tiHxmw7jx8mSulX0MSsDjMFGzcuN+N+OkS/ewy beCNHjBApYHc30GgYCmm9gIb5NSOfM28PsHbk= MIME-Version: 1.0 Received: by 10.231.32.132 with SMTP id c4mr12994539ibd.84.1281067303398; Thu, 05 Aug 2010 21:01:43 -0700 (PDT) Received: by 10.231.168.20 with HTTP; Thu, 5 Aug 2010 21:01:42 -0700 (PDT) In-Reply-To: <201008051623.53328.jkim@FreeBSD.org> References: <201008051145.53737.jhb@freebsd.org> <201008051623.53328.jkim@FreeBSD.org> Date: Fri, 6 Aug 2010 08:01:42 +0400 Message-ID: From: Oleg Sharoyko To: Jung-uk Kim Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: PCI config space is not restored upon resume (macbook pro) 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, 06 Aug 2010 04:01:45 -0000 On 6 August 2010 00:23, Jung-uk Kim wrote: > Basically, it means the video ROM is not accessible or failed to POST. > FYI, Mac's don't have "BIOS" any more. =C2=A0It is just emulated via "Boo= t > Camp". =C2=A0Thus, my guess is the BIOS emulation is not being restored > and/or video ROM is not shadowed properly. I guess this might happen, because I don't use Boot Camp and have FreeBSD installed to the whole HDD. I'll see if going with Boot Camp and rEFIt will help. Thanks! --=20 Oleg Sharoyko From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 6 04:03:34 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 10D44106566B for ; Fri, 6 Aug 2010 04:03:34 +0000 (UTC) (envelope-from osharoiko@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 BB0098FC0C for ; Fri, 6 Aug 2010 04:03:33 +0000 (UTC) Received: by iwn10 with SMTP id 10so1048473iwn.13 for ; Thu, 05 Aug 2010 21:03:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=pWso/kcZGb/tjGTmT6DMS+PxdSkzW6bovz0XGszc5RI=; b=igLTDyms5TrywlL/qggCuZqApDNFVJxIuoi1Lj9kFEmY/ARA1dxgLEqlLYR6Fp4GmF TQ9Nzzr2CPj8+7MHo4QFP9ZAgCQ/hSK2GLjxoHLuzoRthi16YIghmG5DSjiUnIUkJ/mC Ts3tlMStAdwUxVyPllOUbflyiJBcKHnjzTvic= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=FlSOba6MwNhtYxrwj8TAvNnE6u8jwMHzYnx+qwBvxbCPbBTYZBtqbjb6xhzHOIWj3S J5YbZqbHK05KpXuJ6CIdKJQmtg0IV5H4n1Kqqwk/qavCENPLBhksvCjTKfMbUHhOCH5u 3OEE4Kh/mBDDSVzBQhTalLiV12W6DzXeLLkfE= MIME-Version: 1.0 Received: by 10.231.19.7 with SMTP id y7mr13139493iba.152.1281067412534; Thu, 05 Aug 2010 21:03:32 -0700 (PDT) Received: by 10.231.168.20 with HTTP; Thu, 5 Aug 2010 21:03:32 -0700 (PDT) In-Reply-To: <201008051635.09273.jkim@FreeBSD.org> References: <20100805200022.GB3610@panther.nvidia.com> <201008051635.09273.jkim@FreeBSD.org> Date: Fri, 6 Aug 2010 08:03:32 +0400 Message-ID: From: Oleg Sharoyko To: Jung-uk Kim Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, Christian Zander Subject: Re: PCI config space is not restored upon resume (macbook pro) 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, 06 Aug 2010 04:03:34 -0000 On 6 August 2010 00:35, Jung-uk Kim wrote: > We *do* switch VTs unless it is explicitly turned off by 'sysctl > hw.syscons.sc_no_suspend_vtswitch=3D1'. =C2=A0However, it was slightly > broken but I fixed it recently. I can confirm that it works on another box with rather recent stable. --=20 Oleg Sharoyko From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 6 04:15: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 5D8071065679; Fri, 6 Aug 2010 04:15:14 +0000 (UTC) (envelope-from osharoiko@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 133828FC13; Fri, 6 Aug 2010 04:15:13 +0000 (UTC) Received: by iwn10 with SMTP id 10so1059772iwn.13 for ; Thu, 05 Aug 2010 21:15:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=5l9LHeuiI5FtvoKqToMrzBsSmFFSfxpNAXLAjXEhT/k=; b=nxNZ+9ycyeiipU8mOW9j83mZqqJ6HTBXmxfWz4gj9GZ5baV/kl8TGnpihb5GhHLgu6 wlyrO3LoWTcb425M9DfpbIziCKNgAaqjiaNFcvyXtjcAtC8qtdayH/6NJtocHy8Kmv+x MjjxEkSDmO6TNXUpTjD8LZYIOiFOQ/iVhuV/8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=unOHx+FpWwSXCVbZExx4ZizBTA+41rp6l5fxGnd5I17alUGdGOXzRCvf8ccq+hpG04 xKepcMJ9J6JH6QdQ8Os+D+goIgY4Z7O4fMWCb1n+V3G5mzb94IU5GTJ1YLPkdjAnG7DH IsfK/SGYBGegAsbB5dmIUwVz9ACIwgHHDPGeU= MIME-Version: 1.0 Received: by 10.231.190.149 with SMTP id di21mr13556289ibb.27.1281068113380; Thu, 05 Aug 2010 21:15:13 -0700 (PDT) Received: by 10.231.168.20 with HTTP; Thu, 5 Aug 2010 21:15:13 -0700 (PDT) In-Reply-To: <20100805200022.GB3610@panther.nvidia.com> References: <201008041112.28704.jhb@freebsd.org> <201008051145.53737.jhb@freebsd.org> <20100805200022.GB3610@panther.nvidia.com> Date: Fri, 6 Aug 2010 08:15:13 +0400 Message-ID: From: Oleg Sharoyko To: Christian Zander Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-hackers@freebsd.org" Subject: Re: PCI config space is not restored upon resume (macbook pro) 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, 06 Aug 2010 04:15:14 -0000 On 6 August 2010 00:00, Christian Zander wrote: > Neither the `nv' nor the `vesa' driver have support for power > management. You'll typically only be able to get X back > with those drivers if you're starting it from scratch following > an S4 cycle, or an S3 cycle that involved a POST (either > issued by the SBIOS or via software). Actually, this is exactly what I was trying to do. And I suspect that it doesn work, because I don't have bios emulation initialized properly. > When using the NVIDIA driver, you will need to make sure that > you're using 256.44, you'll need to be running X at the time of > entry to S3/S4, and you'll need to make sure you've switched > away from X's VT (this didn't happen automatically on FreeBSD > last time I checked). I'll give 256.44 a try, but at first I'll try to fix bios emulation issues. -- Oleg Sharoyko From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 6 05:06:44 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 736881065677 for ; Fri, 6 Aug 2010 05:06:44 +0000 (UTC) (envelope-from jeremie@le-hen.org) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by mx1.freebsd.org (Postfix) with ESMTP id 73E138FC08 for ; Fri, 6 Aug 2010 05:06:41 +0000 (UTC) Received: from endor.tataz.chchile.org (unknown [82.233.239.98]) by smtp5-g21.free.fr (Postfix) with ESMTP id D7FCDD48082; Fri, 6 Aug 2010 07:06:35 +0200 (CEST) Received: from felucia.tataz.chchile.org (felucia.tataz.chchile.org [192.168.1.9]) by endor.tataz.chchile.org (Postfix) with ESMTP id DA42633F19; Fri, 6 Aug 2010 05:06:33 +0000 (UTC) Received: by felucia.tataz.chchile.org (Postfix, from userid 1000) id B96E8A115E; Fri, 6 Aug 2010 05:06:33 +0000 (UTC) Date: Fri, 6 Aug 2010 07:06:33 +0200 From: Jeremie Le Hen To: Kostik Belousov Message-ID: <20100806050633.GK14016@felucia.tataz.chchile.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Cc: FreeBSD Hackers , Jeremie Le Hen , nwhitehorn@freebsd.org, Marius Strobl 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: Fri, 06 Aug 2010 05:06:44 -0000 Hi Kib, In-Reply-To: <20100629083901.GG13238@deviant.kiev.zoral.com.ua> On Tue, Jun 29, 2010 at 11:39:01AM +0300, Kostik Belousov wrote: > On Tue, Jun 29, 2010 at 10:26:39AM +0200, Marius Strobl wrote: > > 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 Hen wrote: > > > > Hi Kostik, > > > > > > > > This patch seems to have faded out from memory. Is it possible to go > > > > forward and commit it? > > > I refreshed the patch. Hopefully, nobody will object, and I commit it > > > shortly. > > > > > > > > > > > Thanks, > > > > Regards. > > > > > > > > On Sat, Jul 25, 2009 at 12:29:16AM +0300, Kostik Belousov wrote: > > > > > Below is the prototype that seems to work for me both with patched and > > > > > old rtld on i386. Patch also contains bits for amd64 that I did not > > > > > tested yet. All other arches are not buildable for now. > > > > > > > > > > Patch completely eliminates sysctl syscalls from the 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. > > > > > > > > Comparing with the originally posted patch, I added support for all > > > architectures, tested amd64 and ia32 on amd64, and converted getpagesizes(3) > > > that added two more startup sysctls. > > > > > > Would be nice to get a testing for at least some !x86 architectures > > > before the commit, I added some people who helped me in past, to the Cc:. > > > > > > > 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 > > > > 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 > > <...> > > > > Unfortunately, I currently lack the time to debug this. > > Thank you. Did yu have time to look at this problem? It would be nice to have this in the tree. Thanks, -- Jeremie Le Hen Humans are born free and equal. But some are more equal than others. Coluche From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 6 09:04: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 8A0D21065679; Fri, 6 Aug 2010 09:04:10 +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 2185B8FC1B; Fri, 6 Aug 2010 09:04:09 +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 o769454K002082 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Aug 2010 12:04:05 +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 o76944HN014969; Fri, 6 Aug 2010 12:04:04 +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 o76944LH014968; Fri, 6 Aug 2010 12:04:04 +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: Fri, 6 Aug 2010 12:04:04 +0300 From: Kostik Belousov To: Jeremie Le Hen Message-ID: <20100806090404.GI22295@deviant.kiev.zoral.com.ua> References: <20100806050633.GK14016@felucia.tataz.chchile.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="aEQgRVFBwimJ3+rv" Content-Disposition: inline In-Reply-To: <20100806050633.GK14016@felucia.tataz.chchile.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 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: FreeBSD Hackers , nwhitehorn@freebsd.org, Marius Strobl 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: Fri, 06 Aug 2010 09:04:10 -0000 --aEQgRVFBwimJ3+rv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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.ua> > On Tue, Jun 29, 2010 at 11:39:01AM +0300, Kostik Belousov wrote: > > On Tue, Jun 29, 2010 at 10:26:39AM +0200, Marius Strobl wrote: > > > 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 Hen wrote: > > > > > Hi Kostik, > > > > >=20 > > > > > This patch seems to have faded out from memory. Is it possible t= o go > > > > > forward and commit it? > > > > I refreshed the patch. Hopefully, nobody will object, and I commit = it > > > > shortly. > > > >=20 > > > > >=20 > > > > > Thanks, > > > > > Regards. > > > > >=20 > > > > > On Sat, Jul 25, 2009 at 12:29:16AM +0300, Kostik Belousov wrote: > > > > > > Below is the prototype that seems to work for me both with patc= hed and > > > > > > old rtld on i386. Patch also contains bits for amd64 that I did= not > > > > > > tested yet. All other arches are not buildable for now. > > > > > >=20 > > > > > > Patch completely eliminates sysctl syscalls from the rtld and l= ibc > > > > > > startup. Without the patch, a single run of /bin/ls did 6 sysct= ls, > > > > > > with the patch, no sysctls is queried at all. > > > > > >=20 > > > > Comparing with the originally posted patch, I added support for all > > > > architectures, tested amd64 and ia32 on amd64, and converted getpag= esizes(3) > > > > that added two more startup sysctls. > > > >=20 > > > > Would be nice to get a testing for at least some !x86 architectures > > > > before the commit, I added some people who helped me in past, to th= e 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 to have this > in the tree. I cannot move forward without the help from somebody having access to sparc64 system where the problem is reproducable. --aEQgRVFBwimJ3+rv Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkxb0AQACgkQC3+MBN1Mb4gKiQCgpJ+gv9QcMLuMjUMr2VDflcJb XmIAoIvZZc5NOEmliteN2AckGJBAcP8U =6lrM -----END PGP SIGNATURE----- --aEQgRVFBwimJ3+rv-- From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 6 11:13:00 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 9C7A01065677; Fri, 6 Aug 2010 11:13:00 +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 1A0E38FC1D; Fri, 6 Aug 2010 11:12:59 +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 o76BBVFQ013997 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Aug 2010 14:11:31 +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 o76BBViV053769; Fri, 6 Aug 2010 14:11:31 +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 o76BBVwt053768; Fri, 6 Aug 2010 14:11:31 +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: Fri, 6 Aug 2010 14:11:31 +0300 From: Kostik Belousov To: Marius Strobl Message-ID: <20100806111131.GN22295@deviant.kiev.zoral.com.ua> References: <20100806050633.GK14016@felucia.tataz.chchile.org> <20100806090404.GI22295@deviant.kiev.zoral.com.ua> <20100806110807.GA68489@alchemy.franken.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="txKCGZfNyLhwRtdd" Content-Disposition: inline In-Reply-To: <20100806110807.GA68489@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: 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: Fri, 06 Aug 2010 11:13:00 -0000 --txKCGZfNyLhwRtdd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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.ua> > > > On Tue, Jun 29, 2010 at 11:39:01AM +0300, Kostik Belousov wrote: > > > > On Tue, Jun 29, 2010 at 10:26:39AM +0200, Marius Strobl wrote: > > > > > 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 Hen wrote: > > > > > > > Hi Kostik, > > > > > > >=20 > > > > > > > This patch seems to have faded out from memory. Is it possib= le to go > > > > > > > forward and commit it? > > > > > > I refreshed the patch. Hopefully, nobody will object, and I com= mit it > > > > > > shortly. > > > > > >=20 > > > > > > >=20 > > > > > > > Thanks, > > > > > > > Regards. > > > > > > >=20 > > > > > > > On Sat, Jul 25, 2009 at 12:29:16AM +0300, Kostik Belousov wro= te: > > > > > > > > Below is the prototype that seems to work for me both with = patched and > > > > > > > > old rtld on i386. Patch also contains bits for amd64 that I= did not > > > > > > > > tested yet. All other arches are not buildable for now. > > > > > > > >=20 > > > > > > > > Patch completely eliminates sysctl syscalls from the rtld a= nd libc > > > > > > > > startup. Without the patch, a single run of /bin/ls did 6 s= ysctls, > > > > > > > > with the patch, no sysctls is queried at all. > > > > > > > >=20 > > > > > > Comparing with the originally posted patch, I added support for= all > > > > > > architectures, tested amd64 and ia32 on amd64, and converted ge= tpagesizes(3) > > > > > > that added two more startup sysctls. > > > > > >=20 > > > > > > Would be nice to get a testing for at least some !x86 architect= ures > > > > > > before the commit, I added some people who helped me in past, t= o 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 direc= tory > > > > > <...> > > > > >=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 to have t= his > > > in the tree. > >=20 > > I cannot move forward without the help from somebody having access to > > sparc64 system where the problem is reproducable. >=20 > Do you have a debug version of the patch which outputs the necessary > information? I would suggest to build rtld and libc with debugging symbols and get full backtrace from the faults. --txKCGZfNyLhwRtdd Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkxb7eIACgkQC3+MBN1Mb4i2jQCg01khz784JFRZt8ZOGIdK/rQN 6k4AoNhxTOrhteKhrIfCqz+CJgUh6P/l =XxKl -----END PGP SIGNATURE----- --txKCGZfNyLhwRtdd-- From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 6 15:12:56 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 C8217106566B; Fri, 6 Aug 2010 15:12:56 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 545E88FC13; Fri, 6 Aug 2010 15:12:55 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.3/8.14.3/ALCHEMY.FRANKEN.DE) with ESMTP id o76B89Hu069372; Fri, 6 Aug 2010 13:08:09 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.3/8.14.3/Submit) id o76B88wB069371; Fri, 6 Aug 2010 13:08:08 +0200 (CEST) (envelope-from marius) Date: Fri, 6 Aug 2010 13:08:08 +0200 From: Marius Strobl To: Kostik Belousov Message-ID: <20100806110807.GA68489@alchemy.franken.de> References: <20100806050633.GK14016@felucia.tataz.chchile.org> <20100806090404.GI22295@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100806090404.GI22295@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.4.2.3i Cc: 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: Fri, 06 Aug 2010 15:12:57 -0000 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, > > > > In-Reply-To: <20100629083901.GG13238@deviant.kiev.zoral.com.ua> > > On Tue, Jun 29, 2010 at 11:39:01AM +0300, Kostik Belousov wrote: > > > On Tue, Jun 29, 2010 at 10:26:39AM +0200, Marius Strobl wrote: > > > > 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 Hen wrote: > > > > > > Hi Kostik, > > > > > > > > > > > > This patch seems to have faded out from memory. Is it possible to go > > > > > > forward and commit it? > > > > > I refreshed the patch. Hopefully, nobody will object, and I commit it > > > > > shortly. > > > > > > > > > > > > > > > > > Thanks, > > > > > > Regards. > > > > > > > > > > > > On Sat, Jul 25, 2009 at 12:29:16AM +0300, Kostik Belousov wrote: > > > > > > > Below is the prototype that seems to work for me both with patched and > > > > > > > old rtld on i386. Patch also contains bits for amd64 that I did not > > > > > > > tested yet. All other arches are not buildable for now. > > > > > > > > > > > > > > Patch completely eliminates sysctl syscalls from the 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. > > > > > > > > > > > > Comparing with the originally posted patch, I added support for all > > > > > architectures, tested amd64 and ia32 on amd64, and converted getpagesizes(3) > > > > > that added two more startup sysctls. > > > > > > > > > > Would be nice to get a testing for at least some !x86 architectures > > > > > before the commit, I added some people who helped me in past, to the Cc:. > > > > > > > > > > > > > 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 > > > > > > > > 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 > > > > <...> > > > > > > > > Unfortunately, I currently lack the time to debug this. > > > > > > Thank you. > > > > Did yu have time to look at this problem? It would be nice to have this > > in the tree. > > I cannot move forward without the help from somebody having access to > sparc64 system where the problem is reproducable. Do you have a debug version of the patch which outputs the necessary information? Marius From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 6 23:28: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 0E6CA106566B; Fri, 6 Aug 2010 23:28:41 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by mx1.freebsd.org (Postfix) with ESMTP id 420988FC08; Fri, 6 Aug 2010 23:28:39 +0000 (UTC) Received: by wwf26 with SMTP id 26so383589wwf.1 for ; Fri, 06 Aug 2010 16:28:39 -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=PhPny5An+nrksa7qkUH1e+mZc+KwFCupwJMnw2Z8bXY=; b=RzB9qUpZM7vTj/0dgX6cK0H2vO+XZewoWfJKGwoORVFmnn7XEZYFt8ldnm6Eb8VbDJ HN6YN/ZB/CiLo4skMqCQ0EgR89GRtNUujCoFfitOVJLjfXR/pbvbh2BnSH/mGtlbkv6G n6/xkplzPdh6i5vU6hQdik1F7+U5DkNkPThhk= 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=eCCjq90Zi1tECDuLr2kaGk6gI81v2GHWhbEXzXWWis9lw3/YHPgUNp6CyhI3MgSZRM T98IWV0vR/7mRn7XnMjsH0ZT7hkx5WWapau0umwTDRl7LwunuzsVqqgj2/qKhY9WPTjN v99FvyhzmJqbNMmUH9HuOH2QAO2y9OHbtgTcc= MIME-Version: 1.0 Received: by 10.216.79.66 with SMTP id h44mr11215225wee.6.1281137318946; Fri, 06 Aug 2010 16:28:38 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.216.238.16 with HTTP; Fri, 6 Aug 2010 16:28:38 -0700 (PDT) In-Reply-To: <201008051312.25854.jhb@freebsd.org> References: <201008041455.26066.jhb@freebsd.org> <201008051312.25854.jhb@freebsd.org> Date: Sat, 7 Aug 2010 01:28:38 +0200 X-Google-Sender-Auth: e7TvOTDuU9b0EpaEK-PxJ_S-Bak Message-ID: From: Attilio Rao To: John Baldwin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: mdf@freebsd.org, 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: Fri, 06 Aug 2010 23:28:41 -0000 2010/8/5 John Baldwin : > On Thursday, August 05, 2010 11:59:37 am mdf@freebsd.org wrote: >> On Wed, Aug 4, 2010 at 11:55 AM, John Baldwin wrote: >> > On Wednesday, August 04, 2010 12:20:31 pm mdf@freebsd.org wrote: >> >> On Wed, Aug 4, 2010 at 2:26 PM, John Baldwin wrote: >> >> > On Tuesday, August 03, 2010 9:46:16 pm mdf@freebsd.org wrote: >> >> >> On Fri, Jul 30, 2010 at 2:31 PM, John Baldwin wr= ote: >> >> >> > 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 as= t() >> >> >> >> > indicates the sched lock is still held, but the place it clai= ms > it was >> >> >> >> > held by is in fact sometimes not possible to keep the lock, l= ike: >> >> >> >> > >> >> >> >> > =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=A0mo= v =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 proble= ms with thread > migration. >> >> >> >> > =C2=A0 =C2=A0 =C2=A0* Once that all verifies are passed about= spinlocks > ownership, >> >> >> >> > =C2=A0 =C2=A0 =C2=A0* the thread is in a safe path and it can= be unpinned. >> >> >> >> > =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=A0mo= v =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 proble= ms with thread > migration. >> >> >> >> > =C2=A0 =C2=A0 =C2=A0* Once that all verifies are passed about= spinlocks > ownership, >> >> >> >> > =C2=A0 =C2=A0 =C2=A0* the thread is in a safe path and it can= be unpinned. >> >> >> >> > =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=A0mo= v > =C2=A0%rax,-0x110(%rbp) >> >> >> >> > ffffffff802db232: =C2=A0 48 89 85 f8 fe ff ff =C2=A0 =C2=A0mo= v > =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 > 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 h= ave > a >> >> >> >> > lock leak at the indicated point, but in one instance I can s= ee > in the >> >> >> >> > dump that the lock_list local from witness_warn is from the p= cpu >> >> >> >> > structure for CPU 0 (and I was warned about sched lock 0), bu= t > the >> >> >> >> > thread id in panic_cpu is 2. =C2=A0So clearly the thread was = being > migrated >> >> >> >> > right around panic time. >> >> >> >> > >> >> >> >> > This is the amd64 kernel on stable/7. =C2=A0I'm not sure exac= tly 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_p= in() > for >> >> >> >> > it to really do what it claims? =C2=A0Could the hardware have= re- > ordered >> >> >> >> > the "mov =C2=A0 =C2=A0%gs:0x48,%rax" PCPU_GET to before the s= ched_pin() >> >> >> >> > increment? >> >> >> >> >> >> >> >> Hmmm, I think it might be able to because they refer to differe= nt > locations. >> >> >> >> >> >> >> >> Note this rule in section 8.2.2 of Volume 3A: >> >> >> >> >> >> >> >> =C2=A0 =E2=80=A2 Reads may be reordered with older writes to di= fferent 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 > believe ia64 >> >> >> >> could reorder as well. =C2=A0Since sched_pin/unpin are frequent= ly 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_pinned) + 1; >> >> >> >> } >> >> >> >> >> >> >> >> sched_unpin() >> >> >> >> { >> >> >> >> =C2=A0 =C2=A0 =C2=A0 atomic_store_rel_int(&td->td_pinned, td->t= d_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 wh= at > is happening >> >> >> >> 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=A0However, I >> >> >> > don't think the speculative read would be preserved in that case= . > =C2=A0The CPU >> >> >> > has to return to a specific PC when it returns from the interrup= t > and it has >> >> >> > no way of storing the state for what speculative reordering it m= ight > be >> >> >> > doing, so presumably it is thrown away? =C2=A0I suppose it is po= ssible > that it >> >> >> > actually retires both instructions (but reordered) and then retu= rns > to the PC >> >> >> > value after the read of listlocks after the interrupt. =C2=A0How= ever, in > that case >> >> >> > the scheduler would not migrate as it would see td_pinned !=3D 0= . =C2=A0To > get the >> >> >> > race you have to have the interrupt take effect prior to modifyi= ng > td_pinned, >> >> >> > so I think the processor would have to discard the reordered rea= d 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 > doing >> >> >> > 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 th= e > read of >> >> >> > td_pinned in the incl instruction on x86. >> >> >> >> >> >> I wonder how that's interpreted in the microcode, though? =C2=A0I.= e. if the >> >> >> incr instruction decodes to load, add, store, does the h/w allow t= he >> >> >> later reads to pass the final store? >> >> > >> >> > Well, the architecture is defined in terms of the ISA, not the > microcode, per >> >> > se, so I think it would have to treat the read for the incl as bein= g an > earlier >> >> > read than 'spinlocks'. >> >> > >> >> >> I added the following: >> >> >> >> >> >> =C2=A0 =C2=A0 =C2=A0 sched_pin(); >> >> >> =C2=A0 =C2=A0 =C2=A0 lock_list =3D PCPU_GET(spinlocks); >> >> >> =C2=A0 =C2=A0 =C2=A0 if (lock_list !=3D NULL && lock_list->ll_coun= t !=3D 0) { >> >> >> + =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 mfence(); >> >> >> + =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 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 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 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 /* XXX end debug */ >> >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 sched_unpin(); >> >> >> >> >> >> =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 s= ome >> >> >> barrier is needed in sched_pin() than that %gs is getting corrupte= d >> >> >> but can always be dereferenced. >> >> > >> >> > Actually, I would beg to differ in that case. =C2=A0If PCPU_GET(spi= nlocks) >> >> > returns non-NULL, then it means that you hold a spin lock, >> >> >> >> ll_count is 0 for the "correct" pc_spinlocks and non-zero for the >> >> "wrong" one, though. =C2=A0So I think it can be non-NULL but the curr= ent >> >> thread/CPU doesn't hold a spinlock. >> > >> > Hmm, does the 'lock_list' pointer value in the dump match 'lock_list' >> > from another CPU? >> >> Yes: >> >> (gdb) p panic_cpu >> $9 =3D 2 >> (gdb) p dumptid >> $12 =3D 100751 >> (gdb) p cpuhead.slh_first->pc_allcpu.sle_next->pc_curthread->td_tid >> $14 =3D 100751 >> >> (gdb) p *cpuhead.slh_first->pc_allcpu.sle_next >> $6 =3D { >> =C2=A0 pc_curthread =3D 0xffffff00716d6960, >> =C2=A0 pc_cpuid =3D 2, >> =C2=A0 pc_spinlocks =3D 0xffffffff80803198, >> >> (gdb) p lock_list >> $2 =3D (struct lock_list_entry *) 0xffffffff80803fb0 >> >> (gdb) p *cpuhead.slh_first->pc_allcpu.sle_next->pc_allcpu.sle_next- >>pc_allcpu.sle_next >> $8 =3D { >> =C2=A0 pc_curthread =3D 0xffffff0005479960, >> =C2=A0 pc_cpuid =3D 0, >> =C2=A0 pc_spinlocks =3D 0xffffffff80803fb0, >> >> I.e. we're dumping on CPU 2, but the lock_list pointer that was saved >> in the dump matches that of CPU 0. > > Can you print out the tid's for the two curthreads? =C2=A0It's not imposs= ible that > the thread migrated after calling panic. =C2=A0In fact we force threads t= o CPU 0 > during shutdown. The problem here is not migration but the fact that witness thinks there is a spinlock held when it is not true (we are sure the code is not bogus, right?). As long as a thread staying on a cpu has a spinlock it can't be switched out, we should rule out any migration specific problem and the only way the first thing that cames to my mind is a stale %gs. Thanks, Attilio --=20 Peace can only be achieved by understanding - A. Einstein From owner-freebsd-hackers@FreeBSD.ORG Sat Aug 7 06:48: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 5EBAC1065678 for ; Sat, 7 Aug 2010 06:48:20 +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 1C0FC8FC13 for ; Sat, 7 Aug 2010 06:48:20 +0000 (UTC) Received: by iwn10 with SMTP id 10so2448988iwn.13 for ; Fri, 06 Aug 2010 23:48:19 -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:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=y0jUOEB8pNwF82dzxDOHYejI9JCPxMe+If7ykLTdnBY=; b=oueooFrNypyl8B5IeadZRt/zfIbafXFLFjS5kyf9jR0//OH753beNMUEohZJ1nf7hE RFi0uDyqtQJQ9jdBlADrF9MyXpKKdYaBiuBkXblA0tfBPZbGZUoRLZn08fsIl8pbXzmS GsKS0SkLqXomMdU7v8f+Ynl3M5sSy9qlUdFvE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; b=v4UXA3RQyciTUyYTrc96X1WA6zUD7J2Y80WRM+Z0u3pT/+6RZF/1ZmlA20mxDI40LZ 43lKatCHTtptT3J5CHBo34DJyXNupHbdqnNudvlWuDc3X71s/+O9XsQvL6JpnpTe2Xwo fV/1M2gBEzHOPTfF07qxMMuep+GzPK4FBFsTs= MIME-Version: 1.0 Received: by 10.231.183.134 with SMTP id cg6mr10244622ibb.197.1281163699615; Fri, 06 Aug 2010 23:48:19 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.231.173.133 with HTTP; Fri, 6 Aug 2010 23:48:19 -0700 (PDT) Date: Fri, 6 Aug 2010 23:48:19 -0700 X-Google-Sender-Auth: _Z83BQoqEjkqhVpmzuhhYaFkkSw Message-ID: From: Garrett Cooper To: hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: des@freebsd.org Subject: 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: Sat, 07 Aug 2010 06:48:20 -0000 Hi Hackers, Poking around the sound(4) drivers, I looked into converting one of the TUNABLE_INTs to an unsigned tunable for testing purposes. I looked in kernel.h and I saw the following comment: /* * int * please avoid using for new tunables! */ I found the commit where it was made (by des@ -- cvs revision 1.120), but unfortunately I lack the context as to why that suggestion is made; the commit isn't very explicit as to why integers tunables should be discouraged -- and in the case of hw.sound.feeder_rate_round, it makes just as much sense to use an integer type or a long integer type, as accepted input values are small enough to fit in an integer value with a _lot_ of headroom: hw.snd.feeder_rate_round Sample rate rounding threshold, to avoid large prime division at the cost of accuracy. All requested sample rates will be rounded to the nearest threshold value. Possible values range between 0 (disabled) and 500. Default is 25. It would be nice to know why TUNABLE_INT is discouraged :). Thanks! -Garrett From owner-freebsd-hackers@FreeBSD.ORG Sat Aug 7 12:05: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 70427106566B for ; Sat, 7 Aug 2010 12:05:32 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [IPv6:2001:470:a803::1]) by mx1.freebsd.org (Postfix) with ESMTP id DACD58FC18 for ; Sat, 7 Aug 2010 12:05:31 +0000 (UTC) Received: from mail.geekcn.org (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id 719F8A5E5C4; Sat, 7 Aug 2010 20:05:29 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by mail.geekcn.org (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with LMTP id W+Jvbw5tlt0Q; Sat, 7 Aug 2010 20:05:22 +0800 (CST) Received: from delta.delphij.net (c-24-4-100-103.hsd1.ca.comcast.net [24.4.100.103]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id 27299A5E59B; Sat, 7 Aug 2010 20:05:20 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=nFLIoIdLwO5JX4uutF9+X4SpsE5l//fdq8yycNar6drx5Kk60haKnfw1cc7I9tA7C LYPZ7KyxFAhKBomnLx99w== Message-ID: <4C5D4BFD.9080803@delphij.net> Date: Sat, 07 Aug 2010 05:05:17 -0700 From: Xin LI Organization: The Geek China Organization User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.11) Gecko/20100721 Thunderbird/3.0.6 ThunderBrowse/3.3.1 MIME-Version: 1.0 To: =?UTF-8?B?RGFnLUVybGluZyBTbcO4cmdyYXY=?= References: <4C2B07F5.6030801@delphij.net> <4C2B4D35.8060903@feral.com> <86lj9wmbrz.fsf@ds4.des.no> <4C2BBF3C.4070503@delphij.net> <86hbkkmad1.fsf@ds4.des.no> <4C2BD498.3090704@delphij.net> <86d3v7n093.fsf@ds4.des.no> In-Reply-To: <86d3v7n093.fsf@ds4.des.no> X-Enigmail-Version: 1.0.1 OpenPGP: id=3FCA37C1; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: Matthew Jacob , d@delphij.net, freebsd-hackers@freebsd.org Subject: Winbond Watchdog [Was Re: Supermicro BIOS's watchdog feature?] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Aug 2010 12:05:32 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2010/07/01 00:12, Dag-Erling Smørgrav wrote: > Xin LI writes: >> "Dag-Erling Smørgrav" writes: >>> Perhaps the motherboard has additional watchdog hardware? If you >>> disable the watchdog in BIOS, does ichwd still work? >> If I kill -9 watchdogd the system do reset itself so I think ichwd(4) >> really works even if BIOS setting is 'Disabled' (but I'm not sure if >> this method is right? Looking at the code I think the answer is >> probably "Yes" though) > > Yes. This confirms my hypothesis, which is that your motherboard has > additional watchdog hardware, and that the BIOS setting controls that, > not the ichwd watchdog timer. Just disable the watchdog in BIOS and use > ichwd instead. Thanks, you are absolutely correct that they are using another watchdog (on Winbond Super I/O chip). With help from some datasheets floating around the Internet and playing with the motherboard a little bit, now I have a first cut of a watchdog(9) interfaced driver for the chip and have confirmed working on the motherboard. I'm still polishing up the driver, there seems to be no way to figure out the base port address directly (datasheet said it's either 0x2e and 0x4e) so for now I have its device identify method to do some dirty hacks (outb/inb directly) and only check if with appropriate key entered to the port we will get non-0xff value. I'm not sure if that would be acceptable? I'll try to further read the spec and see if we have some better way of doing this and publish the driver code hopefully in the next week. Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iQEcBAEBCAAGBQJMXUv9AAoJEATO+BI/yjfBd3QIAMi3JV5+kQA9Mq6VJvs307jM GStdcuG0zXfXIsS4H4r8VYdphUD8aTk10QNCXBLnXSW5fZjFMlyEocpPlSn1Jtah TM1uApjc5rrAIdM9S0GQxPUdJLvc7O3okTsQRnze0Nv8EvO0p6ZQinRjMJT/1qfH CuggvbTsAO9Yg5N65CsbHIUgPm1vu5a/uyFVN7nhpWtzaCuex+mB0n1r5qObPqY2 UaiF/s3SFssJtx27cwCo4KuuLhX9aI/qaDzjpmpBXIGY//gGYjW5cd180bW8V744 abWfVExqQqtdRLXqacrjWeUyrRE27pZ6ghj/6cRBwK018GLweFntX9p5SJ9S3Rs= =cK+Y -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Sat Aug 7 12:53:12 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 2427B106566B for ; Sat, 7 Aug 2010 12:53:12 +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 D98CD8FC16 for ; Sat, 7 Aug 2010 12:53:11 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id B368C1FFC33; Sat, 7 Aug 2010 12:53:10 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 8D1188452D; Sat, 7 Aug 2010 14:53:10 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: d@delphij.net References: <4C2B07F5.6030801@delphij.net> <4C2B4D35.8060903@feral.com> <86lj9wmbrz.fsf@ds4.des.no> <4C2BBF3C.4070503@delphij.net> <86hbkkmad1.fsf@ds4.des.no> <4C2BD498.3090704@delphij.net> <86d3v7n093.fsf@ds4.des.no> <4C5D4BFD.9080803@delphij.net> Date: Sat, 07 Aug 2010 14:53:10 +0200 In-Reply-To: <4C5D4BFD.9080803@delphij.net> (Xin LI's message of "Sat, 07 Aug 2010 05:05:17 -0700") Message-ID: <86ocde8tzd.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, Matthew Jacob Subject: Re: Winbond Watchdog 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, 07 Aug 2010 12:53:12 -0000 Xin LI writes: > I'm still polishing up the driver, there seems to be no way to figure > out the base port address directly (datasheet said it's either 0x2e and > 0x4e) so for now I have its device identify method to do some dirty > hacks (outb/inb directly) and only check if with appropriate key entered > to the port we will get non-0xff value. Sounds gross, but if there's no other way, I guess it'll have to do. I imagine you check the PCI id etc. first? DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Sat Aug 7 13:57: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 137E8106564A; Sat, 7 Aug 2010 13:57:41 +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 F0C018FC1D; Sat, 7 Aug 2010 13:57:40 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 44CE21FFC33; Sat, 7 Aug 2010 13:40:35 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 203E78454C; Sat, 7 Aug 2010 15:40:35 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Garrett Cooper References: Date: Sat, 07 Aug 2010 15:40:35 +0200 In-Reply-To: (Garrett Cooper's message of "Fri, 6 Aug 2010 23:48:19 -0700") Message-ID: <86fwyq8rsc.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: 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: Sat, 07 Aug 2010 13:57:43 -0000 Garrett Cooper writes: > I found the commit where it was made (by des@ -- cvs revision > 1.120), but unfortunately I lack the context as to why that suggestion > is made; the commit isn't very explicit as to why integers tunables > should be discouraged You're supposed to use TUNABLE_LONG or TUNABLE_ULONG instead. From digging in the -current archives, it seems that the motivation was a bug that resulted from using a TUNABLE_INT for a value that was actually an address. It was doubly broken: first because it was too small on 64-bit systems, and second because it was signed. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Sat Aug 7 13:59: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 433871065678; Sat, 7 Aug 2010 13:59:42 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 95CFA8FC16; Sat, 7 Aug 2010 13:59:40 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.3/8.14.3/ALCHEMY.FRANKEN.DE) with ESMTP id o77Dxdr1012644; Sat, 7 Aug 2010 15:59:39 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.3/8.14.3/Submit) id o77DxdBh012643; Sat, 7 Aug 2010 15:59:39 +0200 (CEST) (envelope-from marius) Date: Sat, 7 Aug 2010 15:59:39 +0200 From: Marius Strobl To: Kostik Belousov Message-ID: <20100807135939.GA875@alchemy.franken.de> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100806111131.GN22295@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.4.2.3i Cc: 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, 07 Aug 2010 13:59:42 -0000 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, > > > > > > > > In-Reply-To: <20100629083901.GG13238@deviant.kiev.zoral.com.ua> > > > > On Tue, Jun 29, 2010 at 11:39:01AM +0300, Kostik Belousov wrote: > > > > > On Tue, Jun 29, 2010 at 10:26:39AM +0200, Marius Strobl wrote: > > > > > > 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 Hen wrote: > > > > > > > > Hi Kostik, > > > > > > > > > > > > > > > > This patch seems to have faded out from memory. Is it possible to go > > > > > > > > forward and commit it? > > > > > > > I refreshed the patch. Hopefully, nobody will object, and I commit it > > > > > > > shortly. > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > Regards. > > > > > > > > > > > > > > > > On Sat, Jul 25, 2009 at 12:29:16AM +0300, Kostik Belousov wrote: > > > > > > > > > Below is the prototype that seems to work for me both with patched and > > > > > > > > > old rtld on i386. Patch also contains bits for amd64 that I did not > > > > > > > > > tested yet. All other arches are not buildable for now. > > > > > > > > > > > > > > > > > > Patch completely eliminates sysctl syscalls from the 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. > > > > > > > > > > > > > > > > Comparing with the originally posted patch, I added support for all > > > > > > > architectures, tested amd64 and ia32 on amd64, and converted getpagesizes(3) > > > > > > > that added two more startup sysctls. > > > > > > > > > > > > > > Would be nice to get a testing for at least some !x86 architectures > > > > > > > before the commit, I added some people who helped me in past, to the Cc:. > > > > > > > > > > > > > > > > > > > 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 > > > > > > > > > > > > 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 > > > > > > <...> > > > > > > > > > > > > Unfortunately, I currently lack the time to debug this. > > > > > > > > > > Thank you. > > > > > > > > Did yu have time to look at this problem? It would be nice to have this > > > > in the tree. > > > > > > I cannot move forward without the help from somebody having access to > > > sparc64 system where the problem is reproducable. > > > > Do you have a debug version of the patch which outputs the necessary > > information? > > I would suggest to build rtld and libc with debugging symbols and > get full backtrace from the faults. 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 conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "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=0x7fdffffe2f8, nelem=1) at /usr/home/marius/co/head/src/lib/libc/gen/getpagesizes.c:75 75 while (nops > 0 && ps[nops - 1] == 0) (gdb) bt #0 0x000000004089ebdc in getpagesizes (pagesize=0x7fdffffe2f8, nelem=1) 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=32) at /usr/home/marius/co/head/src/lib/libc/stdlib/malloc.c:5932 #3 0x00000000001069ac in clone_setdefcallback (ifprefix=0x11b8a8 "wlan", p=0x10a1a0 ) 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_start.S:59 #8 0x000000004022719c in .rtld_start () at /usr/home/marius/co/head/src/libexec/rtld-elf/sparc64/rtld_start.S:59 Previous frame identical to this frame (corrupt stack?) All faults I've looked at died the same why. Marius From owner-freebsd-hackers@FreeBSD.ORG Sat Aug 7 17:40:08 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 590471065672 for ; Sat, 7 Aug 2010 17:40:08 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [IPv6:2001:4068:10::3]) by mx1.freebsd.org (Postfix) with ESMTP id 02C308FC08 for ; Sat, 7 Aug 2010 17:40:08 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id F022A41C705; Sat, 7 Aug 2010 19:40:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([192.168.74.103]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id x-wPZ5qLq1sA; Sat, 7 Aug 2010 19:40:06 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id 2B97541C713; Sat, 7 Aug 2010 19:40:06 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 419DC4448EC; Sat, 7 Aug 2010 17:39:04 +0000 (UTC) Date: Sat, 7 Aug 2010 17:39:04 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: d@delphij.net In-Reply-To: <4C5D4BFD.9080803@delphij.net> Message-ID: <20100807173222.W48418@maildrop.int.zabbadoz.net> References: <4C2B07F5.6030801@delphij.net> <4C2B4D35.8060903@feral.com> <86lj9wmbrz.fsf@ds4.des.no> <4C2BBF3C.4070503@delphij.net> <86hbkkmad1.fsf@ds4.des.no> <4C2BD498.3090704@delphij.net> <86d3v7n093.fsf@ds4.des.no> <4C5D4BFD.9080803@delphij.net> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1956331165-1281202744=:48418" Cc: =?UTF-8?B?RGFnLUVybGluZyBTbcO4cmdyYXY=?= , Matthew Jacob , freebsd-hackers@freebsd.org Subject: Re: Winbond Watchdog [Was Re: Supermicro BIOS's watchdog feature?] 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, 07 Aug 2010 17:40:08 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1956331165-1281202744=:48418 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Sat, 7 Aug 2010, Xin LI wrote: Hey, a bit unrealted but I faced some of those problems lately as well. > On 2010/07/01 00:12, Dag-Erling Sm=F8rgrav wrote: >> Xin LI writes: >>> "Dag-Erling Sm=F8rgrav" writes: >>>> Perhaps the motherboard has additional watchdog hardware? If you >>>> disable the watchdog in BIOS, does ichwd still work? >>> If I kill -9 watchdogd the system do reset itself so I think ichwd(4) >>> really works even if BIOS setting is 'Disabled' (but I'm not sure if >>> this method is right? Looking at the code I think the answer is >>> probably "Yes" though) >> >> Yes. This confirms my hypothesis, which is that your motherboard has >> additional watchdog hardware, and that the BIOS setting controls that, >> not the ichwd watchdog timer. Just disable the watchdog in BIOS and use >> ichwd instead. > > Thanks, you are absolutely correct that they are using another watchdog > (on Winbond Super I/O chip). > > With help from some datasheets floating around the Internet and playing > with the motherboard a little bit, now I have a first cut of a > watchdog(9) interfaced driver for the chip and have confirmed working on > the motherboard. > > I'm still polishing up the driver, there seems to be no way to figure > out the base port address directly (datasheet said it's either 0x2e and > 0x4e) so for now I have its device identify method to do some dirty > hacks (outb/inb directly) and only check if with appropriate key entered > to the port we will get non-0xff value. I'm not sure if that would be > acceptable? I'll try to further read the spec and see if we have some > better way of doing this and publish the driver code hopefully in the > next week. > I have a fintek locally but they all basically seem to operate after the same scheme. I had a very simple inb/outb /dev/io based user space solution for it and went to the quick and dirty kernel module. There are not many assertions put in place and it only checks one of the two base ports as I had only done it for me so far. Unfortunately there is no ACPI WDRT entry here (either?). devinfo -r was to some use though. In case it'll help you or someone else I just put it online: http://people.freebsd.org/~bz/20100807-02-wd-fintek-f71882fg.diff /bz --=20 Bjoern A. Zeeb This signature is about you not me. --0-1956331165-1281202744=:48418-- From owner-freebsd-hackers@FreeBSD.ORG Sat Aug 7 17:42:04 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 2F471106564A for ; Sat, 7 Aug 2010 17:42:04 +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 E71C08FC1C for ; Sat, 7 Aug 2010 17:42:03 +0000 (UTC) Received: by iwn10 with SMTP id 10so2992211iwn.13 for ; Sat, 07 Aug 2010 10:42: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:content-transfer-encoding; bh=P3ZbxXnF03FQlFGXe4ciyojZgic/eF14XsXcW1fQZJk=; b=ZLCwe42j38rCXbJLY8JC96j75SfgJ5E/dd2xol0CcaXhA8mDgOK42u4c98IEk3sMiW o/mJxsNLeAfU6/Pb9rjdareyvoOtejrPGkfhuM61HLWamAcgFgmN/Y4aIqyHFPqXQ72h 0TDIOitsy6zHKbdXqr9obOll1XPhjsRmptLuA= 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=nx1ZuBAxLMnpcU8pC0cxp/uQB1UggU0RCAQSqUWEuqjNcwLNA3EqVj001mhxdeiwOM GRBZ7dMmarqYvaYvY0zyx5ug3J/NcpJd+Y/SgxN7SF7ThJkdggSrHp7jehNAekT7C2gi qFqubpM/aky3bM5QXOmM/nNWznWj2EguCkEho= MIME-Version: 1.0 Received: by 10.231.169.10 with SMTP id w10mr16287049iby.106.1281202922801; Sat, 07 Aug 2010 10:42:02 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.231.173.133 with HTTP; Sat, 7 Aug 2010 10:42:02 -0700 (PDT) In-Reply-To: <86fwyq8rsc.fsf@ds4.des.no> References: <86fwyq8rsc.fsf@ds4.des.no> Date: Sat, 7 Aug 2010 10:42:02 -0700 X-Google-Sender-Auth: 5Pj_Myq0EMTa9jvslKAmuSOwTOQ 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: 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: Sat, 07 Aug 2010 17:42:04 -0000 2010/8/7 Dag-Erling Sm=F8rgrav : > Garrett Cooper writes: >> =A0 =A0I found the commit where it was made (by des@ -- cvs revision >> 1.120), but unfortunately I lack the context as to why that suggestion >> is made; the commit isn't very explicit as to why integers tunables >> should be discouraged > > You're supposed to use TUNABLE_LONG or TUNABLE_ULONG instead. =A0From > digging in the -current archives, it seems that the motivation was a bug > that resulted from using a TUNABLE_INT for a value that was actually an > address. =A0It was doubly broken: first because it was too small on 64-bi= t > systems, and second because it was signed. Thanks for the explanation. I just found it interesting how the interfaces to [PCI BUS] resources, sysctls, and tunables are inconsistent in terms of what data types they support; resources only supports signed integers of various widths, sysctls support everything under the sun, and we know the story on tunables now. It's ok most of the time, but as we all know there are limits to the ranges for integers, and there's something a bit quirky about some of the code in sound(4) that I'm experimenting with to see whether or not it was there's an issue with bad casting, comparison, an uninitialized value, or another random race condition, that's wreaking havoc with my Audigy card every time I attach the driver as a module. Thanks! -Garrett From owner-freebsd-hackers@FreeBSD.ORG Sat Aug 7 18:09: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 95206106567A; Sat, 7 Aug 2010 18:09:13 +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 F2B1F8FC16; Sat, 7 Aug 2010 18:09:12 +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 o77I98jc073399 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 7 Aug 2010 21:09:08 +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 o77I97RE056885; Sat, 7 Aug 2010 21:09:07 +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 o77I94Uf056884; Sat, 7 Aug 2010 21:09:04 +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, 7 Aug 2010 21:09:04 +0300 From: Kostik Belousov To: Marius Strobl Message-ID: <20100807180904.GZ22295@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> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="iZGt3Nu4N+9AUM+d" Content-Disposition: inline In-Reply-To: <20100807135939.GA875@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: 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, 07 Aug 2010 18:09:13 -0000 --iZGt3Nu4N+9AUM+d Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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.ua> > > > > > On Tue, Jun 29, 2010 at 11:39:01AM +0300, Kostik Belousov wrote: > > > > > > On Tue, Jun 29, 2010 at 10:26:39AM +0200, Marius Strobl wrote: > > > > > > > On Mon, Jun 28, 2010 at 05:48:59PM +0300, Kostik Belousov wro= te: > > > > > > > > On Wed, Jun 23, 2010 at 11:09:59PM +0200, Jeremie Le Hen wr= ote: > > > > > > > > > Hi Kostik, > > > > > > > > >=20 > > > > > > > > > This patch seems to have faded out from memory. Is it po= ssible to go > > > > > > > > > forward and commit it? > > > > > > > > I refreshed the patch. Hopefully, nobody will object, and I= commit it > > > > > > > > shortly. > > > > > > > >=20 > > > > > > > > >=20 > > > > > > > > > Thanks, > > > > > > > > > Regards. > > > > > > > > >=20 > > > > > > > > > On Sat, Jul 25, 2009 at 12:29:16AM +0300, Kostik Belousov= wrote: > > > > > > > > > > Below is the prototype that seems to work for me both w= ith patched and > > > > > > > > > > old rtld on i386. Patch also contains bits for amd64 th= at I did not > > > > > > > > > > tested yet. All other arches are not buildable for now. > > > > > > > > > >=20 > > > > > > > > > > Patch completely eliminates sysctl syscalls from the rt= ld 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 support= for all > > > > > > > > architectures, tested amd64 and ia32 on amd64, and converte= d getpagesizes(3) > > > > > > > > that added two more startup sysctls. > > > > > > > >=20 > > > > > > > > Would be nice to get a testing for at least some !x86 archi= tectures > > > > > > > > before the commit, I added some people who helped me in pas= t, 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 d= irectory > > > > > > > <...> > > > > > > >=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 to ha= ve this > > > > > in the tree. > > > >=20 > > > > I cannot move forward without the help from somebody having access = to > > > > sparc64 system where the problem is reproducable. > > >=20 > > > Do you have a debug version of the patch which outputs the necessary > > > 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 conditi= ons. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for detail= s. > This GDB was configured as "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, nelem= =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, nelem= =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_start.S= :59 > #8 0x000000004022719c in .rtld_start () > at /usr/home/marius/co/head/src/libexec/rtld-elf/sparc64/rtld_start.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. In the patched tree, there is tools/test/auxinfo that could be used to quick-check the system. Updated patch is available at http://people.freebsd.org/~kib/misc/rtld_auxinfo.1.patch --iZGt3Nu4N+9AUM+d Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkxdoUAACgkQC3+MBN1Mb4i14wCfViUP1Y//ehqpanyIC0ptMprS w8cAn18MZTSDfItH2nytNpZth55p8ehN =YfQx -----END PGP SIGNATURE----- --iZGt3Nu4N+9AUM+d-- From owner-freebsd-hackers@FreeBSD.ORG Sat Aug 7 19:19:02 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 DF2A71065674 for ; Sat, 7 Aug 2010 19:19:02 +0000 (UTC) (envelope-from freebsd-hackers@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 922908FC2A for ; Sat, 7 Aug 2010 19:19:02 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1Ohov6-0001dO-2n for freebsd-hackers@freebsd.org; Sat, 07 Aug 2010 21:19:00 +0200 Received: from 89-164-124-179.dsl.iskon.hr ([89.164.124.179]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 07 Aug 2010 21:19:00 +0200 Received: from ivoras by 89-164-124-179.dsl.iskon.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 07 Aug 2010 21:19:00 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-hackers@freebsd.org From: Ivan Voras Date: Sat, 07 Aug 2010 21:18:47 +0200 Lines: 19 Message-ID: References: <86fwyq8rsc.fsf@ds4.des.no> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 89-164-124-179.dsl.iskon.hr User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 In-Reply-To: <86fwyq8rsc.fsf@ds4.des.no> 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: Sat, 07 Aug 2010 19:19:03 -0000 On 7.8.2010 15:40, Dag-Erling Smørgrav wrote: > Garrett Cooper writes: >> I found the commit where it was made (by des@ -- cvs revision >> 1.120), but unfortunately I lack the context as to why that suggestion >> is made; the commit isn't very explicit as to why integers tunables >> should be discouraged > > You're supposed to use TUNABLE_LONG or TUNABLE_ULONG instead. From > digging in the -current archives, it seems that the motivation was a bug > that resulted from using a TUNABLE_INT for a value that was actually an > address. It was doubly broken: first because it was too small on 64-bit > systems, and second because it was signed. Ok, but still - if the underlying value really is declared as "int", doesn't it make perfect sense to have something like TUNABLE_INT for it? Forcing "long" is a bit weird in this context, as C long is 32-bit on i386 and 64-bit on amd64. From owner-freebsd-hackers@FreeBSD.ORG Sat Aug 7 19:37:24 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 118E21065675; Sat, 7 Aug 2010 19:37:24 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 7DA1C8FC23; Sat, 7 Aug 2010 19:37:23 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.3/8.14.3/ALCHEMY.FRANKEN.DE) with ESMTP id o77JbMOx018327; Sat, 7 Aug 2010 21:37:22 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.3/8.14.3/Submit) id o77JbMka018326; Sat, 7 Aug 2010 21:37:22 +0200 (CEST) (envelope-from marius) Date: Sat, 7 Aug 2010 21:37:22 +0200 From: Marius Strobl To: Kostik Belousov Message-ID: <20100807193722.GB875@alchemy.franken.de> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100807180904.GZ22295@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.4.2.3i Cc: 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, 07 Aug 2010 19:37:24 -0000 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, > > > > > > > > > > > > In-Reply-To: <20100629083901.GG13238@deviant.kiev.zoral.com.ua> > > > > > > On Tue, Jun 29, 2010 at 11:39:01AM +0300, Kostik Belousov wrote: > > > > > > > On Tue, Jun 29, 2010 at 10:26:39AM +0200, Marius Strobl wrote: > > > > > > > > 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 Hen wrote: > > > > > > > > > > Hi Kostik, > > > > > > > > > > > > > > > > > > > > This patch seems to have faded out from memory. Is it possible to go > > > > > > > > > > forward and commit it? > > > > > > > > > I refreshed the patch. Hopefully, nobody will object, and I commit it > > > > > > > > > shortly. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > Regards. > > > > > > > > > > > > > > > > > > > > On Sat, Jul 25, 2009 at 12:29:16AM +0300, Kostik Belousov wrote: > > > > > > > > > > > Below is the prototype that seems to work for me both with patched and > > > > > > > > > > > old rtld on i386. Patch also contains bits for amd64 that I did not > > > > > > > > > > > tested yet. All other arches are not buildable for now. > > > > > > > > > > > > > > > > > > > > > > Patch completely eliminates sysctl syscalls from the 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. > > > > > > > > > > > > > > > > > > > > Comparing with the originally posted patch, I added support for all > > > > > > > > > architectures, tested amd64 and ia32 on amd64, and converted getpagesizes(3) > > > > > > > > > that added two more startup sysctls. > > > > > > > > > > > > > > > > > > Would be nice to get a testing for at least some !x86 architectures > > > > > > > > > before the commit, I added some people who helped me in past, to the Cc:. > > > > > > > > > > > > > > > > > > > > > > > > > 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 > > > > > > > > > > > > > > > > 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 > > > > > > > > <...> > > > > > > > > > > > > > > > > Unfortunately, I currently lack the time to debug this. > > > > > > > > > > > > > > Thank you. > > > > > > > > > > > > Did yu have time to look at this problem? It would be nice to have this > > > > > > in the tree. > > > > > > > > > > I cannot move forward without the help from somebody having access to > > > > > sparc64 system where the problem is reproducable. > > > > > > > > Do you have a debug version of the patch which outputs the necessary > > > > information? > > > > > > I would suggest to build rtld and libc with debugging symbols and > > > get full backtrace from the faults. > > > > 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 conditions. > > Type "show copying" to see the conditions. > > There is absolutely no warranty for GDB. Type "show warranty" for details. > > This GDB was configured as "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=0x7fdffffe2f8, nelem=1) > > at /usr/home/marius/co/head/src/lib/libc/gen/getpagesizes.c:75 > > 75 while (nops > 0 && ps[nops - 1] == 0) > > (gdb) bt > > #0 0x000000004089ebdc in getpagesizes (pagesize=0x7fdffffe2f8, nelem=1) > > 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=32) > > at /usr/home/marius/co/head/src/lib/libc/stdlib/malloc.c:5932 > > #3 0x00000000001069ac in clone_setdefcallback (ifprefix=0x11b8a8 "wlan", > > p=0x10a1a0 ) > > 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_start.S:59 > > #8 0x000000004022719c in .rtld_start () > > at /usr/home/marius/co/head/src/libexec/rtld-elf/sparc64/rtld_start.S:59 > > Previous frame identical to this frame (corrupt stack?) > > > > 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. > > In the patched tree, there is tools/test/auxinfo that could be used to > quick-check the system. > > Updated patch is available at > http://people.freebsd.org/~kib/misc/rtld_auxinfo.1.patch I can confirm that this versions works on sparc64. Marius From owner-freebsd-hackers@FreeBSD.ORG Sat Aug 7 20:33:55 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 35EC9106567C; Sat, 7 Aug 2010 20:33:55 +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 EB8EE8FC12; Sat, 7 Aug 2010 20:33:54 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 0B32B1FFC34; Sat, 7 Aug 2010 20:33:54 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id E2B548455C; Sat, 7 Aug 2010 22:33:53 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Ivan Voras References: <86fwyq8rsc.fsf@ds4.des.no> Date: Sat, 07 Aug 2010 22:33:53 +0200 In-Reply-To: (Ivan Voras's message of "Sat, 07 Aug 2010 21:18:47 +0200") Message-ID: <86d3tujh72.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: 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: Sat, 07 Aug 2010 20:33:55 -0000 Ivan Voras writes: > Ok, but still - if the underlying value really is declared as "int", > doesn't it make perfect sense to have something like TUNABLE_INT for it? 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... DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Sat Aug 7 22:19:38 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 CB2801065673; Sat, 7 Aug 2010 22:19:38 +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 815998FC16; Sat, 7 Aug 2010 22:19:38 +0000 (UTC) Received: by iwn10 with SMTP id 10so3180730iwn.13 for ; Sat, 07 Aug 2010 15:19:37 -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=O/8RQAHlSiS7RzrtFhL31uIQd6T6OT5kVl+G7Ih4aVY=; b=azXo0AD91cGS8cnmi8cSyvC2qTb7eQQM6VhlM7PQvJevFucq2yknYwsN7DCZcfWHXS juBBnZ3wGg7wWdUv1nIa/p5DhOvMTeD5rvJozwgqoa63RjhvUDeHLFE7/Jgd9nmudNkq uD+nAScph+cLsHhgmgV3L4volvvIPjBMu3TBQ= 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=EAInWvozrq5d/fGZnFhDL1eQP52fk7ivg7Nco1FZZwzgHRgcmJAWbGAlRz5rdI7r02 NAHWMhwwPZwgYb2tZ0p6xQKHPskYXNAntpff35o+pDTuOJre78oVficdi3HNB99et5H1 ARiScWE++KAfvj5i57otaaB5V25DBEdB5krvM= MIME-Version: 1.0 Received: by 10.231.184.71 with SMTP id cj7mr16143893ibb.159.1281219577851; Sat, 07 Aug 2010 15:19:37 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.231.173.133 with HTTP; Sat, 7 Aug 2010 15:19:37 -0700 (PDT) In-Reply-To: <86d3tujh72.fsf@ds4.des.no> References: <86fwyq8rsc.fsf@ds4.des.no> <86d3tujh72.fsf@ds4.des.no> Date: Sat, 7 Aug 2010 15:19:37 -0700 X-Google-Sender-Auth: 6Qj-W3aY8vxdSLxmGKx_zg-7sEo 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: Sat, 07 Aug 2010 22:19:38 -0000 2010/8/7 Dag-Erling Sm=F8rgrav : > Ivan Voras writes: >> Ok, but still - if the underlying value really is declared as "int", >> doesn't it make perfect sense to have something like TUNABLE_INT for it? > > Perhaps. =A0I don't remember all the details; I can't find a discussion i= n > 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 (feel free to ignore the second i386 value for _limits.h... it was a hack for gcc according to the comment)? $ egrep -nr '#define[[:space:]]+__LONG_MAX' amd64/include/ i386/include/ | grep -v svn amd64/include/_limits.h:63:#define __LONG_MAX 0x7fffffffffffffffL /* max for a long */ i386/include/_limits.h:65:#define __LONG_MAX 0x7fffffffffffffffL i386/include/_limits.h:69:#define __LONG_MAX 0x7fffffffL /* max value for a long */ $ egrep -nr '#define[[:space:]]+__INT_MAX' amd64/include/ i386/include/ | grep -v svn amd64/include/_limits.h:59:#define __INT_MAX 0x7fffffff /* max value for an int */ i386/include/_limits.h:59:#define __INT_MAX 0x7fffffff /* max value for an int */ I was originally asking because I didn't have the background to know why a TUNABLE_UINT set of macros didn't exist. Thanks, -Garrett From owner-freebsd-hackers@FreeBSD.ORG Sat Aug 7 23:21:06 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 4BF8F1065673; Sat, 7 Aug 2010 23:21:06 +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 0A9948FC23; Sat, 7 Aug 2010 23:21:05 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 232351FFC33; Sat, 7 Aug 2010 23:21:05 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 07D1684525; Sun, 8 Aug 2010 01:21:05 +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> Date: Sun, 08 Aug 2010 01:21:04 +0200 In-Reply-To: (Garrett Cooper's message of "Sat, 7 Aug 2010 15:19:37 -0700") Message-ID: <864of680wv.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: Sat, 07 Aug 2010 23:21:06 -0000 Garrett Cooper writes: > Dag-Erling Sm=C3=B8rgrav 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 Karlsruh= e. > > 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. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Sat Aug 7 23:57:24 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 644E61065670 for ; Sat, 7 Aug 2010 23:57:24 +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 10C088FC08 for ; Sat, 7 Aug 2010 23:57:23 +0000 (UTC) Received: by qwg5 with SMTP id 5so4970480qwg.13 for ; Sat, 07 Aug 2010 16:57:23 -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=MMeNRz5MvvAuy733UHDSxBNpJnmLPNbRa1zb/Gppa08=; b=dGnmPradG+55Mj2/Rc2vFsf5+FnvDUEUc+tHtCfPKOYZMa19Ufa4q22epnSgmNHut4 ma1jcwL8uotoeuAU/jgHBj2AZrstbaZrL5LuU9RkTn9Fgkhnu1fW0ouWF0cmqjFu2+hG dxCYb5TwJ4aG8n55C4KcEi78ZdprfGoxWqjQU= 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=UYiuEYSgiww3u1AozwQlBGBRPiwHr4tNU7enu5FzFzpMWGCYP5X1QyrFskwZoSAJtT 4o7pmllt6r8JNTYrxan3xTTyuWviERrT9tD76rXssS22dKcsz1QLrI093guhJQjv4zz6 qX8TER67XTMPv4piuGAC1mVA3tvlcjR4ydFRg= Received: by 10.229.222.65 with SMTP id if1mr6047998qcb.31.1281223839175; Sat, 07 Aug 2010 16:30:39 -0700 (PDT) MIME-Version: 1.0 Sender: ivoras@gmail.com Received: by 10.229.236.132 with HTTP; Sat, 7 Aug 2010 16:30:19 -0700 (PDT) In-Reply-To: <864of680wv.fsf@ds4.des.no> References: <86fwyq8rsc.fsf@ds4.des.no> <86d3tujh72.fsf@ds4.des.no> <864of680wv.fsf@ds4.des.no> From: Ivan Voras Date: Sun, 8 Aug 2010 01:30:19 +0200 X-Google-Sender-Auth: phyiFOCeRN8Ayq3jn8nCKlwBmvU 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, 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: Sat, 07 Aug 2010 23:57:24 -0000 2010/8/8 Dag-Erling Sm=C3=B8rgrav : > Garrett Cooper writes: >> Dag-Erling Sm=C3=B8rgrav writes: >> > Perhaps. =C2=A0I don't remember all the details; I can't find a discus= sion 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 Karlsru= he. >> > 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. =C2=A0The original issue was that someone had use= d > TUNABLE_INT() for something that was actually a memory address. =C2=A0I > changed it to TUNABLE_ULONG(). =C2=A0Of course, if your tunable is a bool= ean > 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. 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