From owner-freebsd-amd64@FreeBSD.ORG Sun Jul 7 21:35:02 2013 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B2A669A1; Sun, 7 Jul 2013 21:35:02 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 0D50F1789; Sun, 7 Jul 2013 21:35:01 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r67LYwhL038096; Mon, 8 Jul 2013 00:34:58 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r67LYwhL038096 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r67LYwAV038095; Mon, 8 Jul 2013 00:34:58 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 8 Jul 2013 00:34:58 +0300 From: Konstantin Belousov To: Davide Italiano Subject: Re: Accessing struct pthread from kernel Message-ID: <20130707213458.GH91021@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="KUl1BpUVukgrQ7uD" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-amd64@freebsd.org, freebsd-threads@freebsd.org X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2013 21:35:02 -0000 --KUl1BpUVukgrQ7uD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jul 06, 2013 at 01:22:05AM +0200, Davide Italiano wrote: > Hi, > as a preliminary step in the implementation of adaptive spinning for > umtx, I'm switching the pthread/umtx code so that a thread that > acquires a pthread_mutex writes the address of struct pthread in the > owner field of the lock instead of the thread id (tid). This is > because having struct pthread pointer allows easily to access > informations of the thread, and makes easy to get the state of the > thread exported from the kernel (once this will be implemented). >=20 > For what concerns the libthr side, the internal function > _get_curthread() goes into the TLS to obtain the struct field of > curthread, so I'm done. > OTOH, I'm quite unsure instead about how to get address of struct > pthread for curthread from the kernel side (for example, in > do_lock_umutex() sys/kern/kern_umtx.c). You should not, see below. >=20 > I guess I need to write some MD code because the TLS is different on > the various architecture supported in FreeBSD, and as a first step I > focused on amd64. > It looks like from the SDM that %%fs register points to the base of > the TLS, so I think that accessing using curthread->td_pcb->pcb_fsbase > (and then adding the proper offset to acces the right field) is a > viable solution to do this. Am I correct? > In particular what worries me is if the read of 'struct pthread' for > curthread from the TLS register is atomic with respect to preemptions. >=20 > Alternatively, is there an (easier way) to accomplish this task? Coupling the libthr thread structure and kernel makes the ABI cast in stone and avoids most possibilities of changing the libthr internals. The same is true for kernel accessing the userspace TLS area of the thread. If you want kernel<->usermode communication of the thread run state, and possibly also a way to advisory prevent a preemption of the spinning usermode thread, you should create a dedicated parameter block communicated from usermode to kernel on thread creation. For the main thread, the block could be allocated by kernel by image activator, placed on the stack and its address passed to the usermode by auxv. Note that you cannot access the usermode from the context switch code. Wiring the corresponding page is very wasteful (think about a process with 10,000 threads) and still does not provide any guarantees since usermode can unmap or remap the range. You might see my 'fast sigprocmask' patches where somewhat similar idea was implemented. I also recommend you to look at the Solaris schedctl(2). --KUl1BpUVukgrQ7uD Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJR2d8BAAoJEJDCuSvBvK1B2eMP/3wSALXdp5FSZb407N2oD6d/ 9vbhDnwRa5wMt5qzlktX7HSTUMsRjUSMyS7PfR7nLXp6/G5UKfQ/uBMR/R+J5bVs Z8nyIJ6tzE5+sYiAeWOzRI1tYk8K2uaC8lKeDB0NiVg0M1EaBRQMsJ894UJ9bhJq 71EC3YrS/WNl8KJKKZAoWP/ZR/aOtXbqZ7c69A7PC9yLvfp1oxtWbXoEBNNLx+UZ y3zf0TAyaWCpafl78Ftpb8ZGL3LaULR97JDYnachXVP0ATGVchDee10W3D/6FnBT cdI9mQ5hBYcAbC6pAz1gkotBDNeqGau6rneaCosSiehJmpVDTHTBLLey05SW3MWR 0ND9rwoQJvDcpWyPSVFx5ubcYQMXZ5wM1r0Us4znIELy4IXm5PArAnyN5nJVfKx+ SfPUNAAJz8eXybkFufnpdHavqaMyvetBjQ+20VdpI1hxtgIZXE8KHfYpAHl53Ozp pINKqlnZKLScjjWVOcQEHqwSPZYAYIuVBRcuCh23cYteBS5FDr4uGLIHQZ7usP0l Z1LhuVe6y+eMPSosI8AyCl9crcQHHIzTb7utHP9FzHVNXBkDj2XL+XgE1HL9+cEY l1rPg3hBnxyH4yzD8gQnMAJTeWQTUUb89CDT9FLi20YgyiWFpOh/Uh3yfmFc9xan JMA232G6Ic8crBLbFU2i =T71R -----END PGP SIGNATURE----- --KUl1BpUVukgrQ7uD-- From owner-freebsd-amd64@FreeBSD.ORG Sun Jul 7 16:48:08 2013 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D97912BE; Sun, 7 Jul 2013 16:48:08 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id B0DBE1B86; Sun, 7 Jul 2013 16:48:08 +0000 (UTC) Received: from jre-mbp.elischer.org (ppp121-45-226-51.lns20.per1.internode.on.net [121.45.226.51]) (authenticated bits=0) by vps1.elischer.org (8.14.5/8.14.5) with ESMTP id r67GlvQ8002275 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 7 Jul 2013 09:48:01 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <51D99BB7.1020101@freebsd.org> Date: Mon, 08 Jul 2013 00:47:51 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Davide Italiano Subject: Re: Accessing struct pthread from kernel References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 07 Jul 2013 23:19:05 +0000 Cc: freebsd-amd64@freebsd.org, freebsd-threads@freebsd.org X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2013 16:48:08 -0000 On 7/6/13 7:22 AM, Davide Italiano wrote: > Hi, > as a preliminary step in the implementation of adaptive spinning for > umtx, I'm switching the pthread/umtx code so that a thread that > acquires a pthread_mutex writes the address of struct pthread in the > owner field of the lock instead of the thread id (tid). This is > because having struct pthread pointer allows easily to access > informations of the thread, and makes easy to get the state of the > thread exported from the kernel (once this will be implemented). > > For what concerns the libthr side, the internal function > _get_curthread() goes into the TLS to obtain the struct field of > curthread, so I'm done. > OTOH, I'm quite unsure instead about how to get address of struct > pthread for curthread from the kernel side (for example, in > do_lock_umutex() sys/kern/kern_umtx.c). > > I guess I need to write some MD code because the TLS is different on > the various architecture supported in FreeBSD, and as a first step I > focused on amd64. > It looks like from the SDM that %%fs register points to the base of > the TLS, so I think that accessing using curthread->td_pcb->pcb_fsbase > (and then adding the proper offset to acces the right field) is a > viable solution to do this. Am I correct? > In particular what worries me is if the read of 'struct pthread' for > curthread from the TLS register is atomic with respect to preemptions. > > Alternatively, is there an (easier way) to accomplish this task? there is a struct pthread for each tid (and visa versa) you could notify the kernel of it when you make a new thread. (new arg/call) for what it's worth the M:N threading system used to do something like this, with a user callback straucture supplied to the kernel.. > > Thanks, > From owner-freebsd-amd64@FreeBSD.ORG Sun Jul 7 17:03:50 2013 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id AEE4BAA1; Sun, 7 Jul 2013 17:03:50 +0000 (UTC) (envelope-from davide.italiano@gmail.com) Received: from mail-ve0-x235.google.com (mail-ve0-x235.google.com [IPv6:2607:f8b0:400c:c01::235]) by mx1.freebsd.org (Postfix) with ESMTP id 5002E1C24; Sun, 7 Jul 2013 17:03:50 +0000 (UTC) Received: by mail-ve0-f181.google.com with SMTP id db10so2869779veb.40 for ; Sun, 07 Jul 2013 10:03:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=lUiWnj24mPctHnyA2HS04n0pXIdnKdzYztlAwIb21mA=; b=XfiDy9DYC8yOpBOlDqf8YWZxFmuyYuNA9odyM8UIkgnExkyEf5+LAv4Fd+yLPUqnif sHRxYXzTS8rpnjBlpIQuSJQs3/nRCkPLA5VwIRuCNlwowJTsujHSrXEWhb5B94moLGdA MHegK6qFhhWvlKMAkqc3sJZ34fOD6EF1bsSkx2svn/JHczxcVc/gHLxyHGIJ+9GdVvvx pVvbHKIr/6mtB/qgbuUuAT/18t12QvOMFo5sKSZlQ2GnPQRy/IMUgNmSxmvL1nx3GZtj NWvxfc78PWgI4+DsW1j/XbivaFO9EuCt96dkkgHwmL+i/4u89hav/Mo8q5rLOuutZVcv ShRA== MIME-Version: 1.0 X-Received: by 10.58.197.5 with SMTP id iq5mr12233635vec.30.1373216629907; Sun, 07 Jul 2013 10:03:49 -0700 (PDT) Sender: davide.italiano@gmail.com Received: by 10.220.206.202 with HTTP; Sun, 7 Jul 2013 10:03:49 -0700 (PDT) In-Reply-To: <51D99BB7.1020101@freebsd.org> References: <51D99BB7.1020101@freebsd.org> Date: Sun, 7 Jul 2013 10:03:49 -0700 X-Google-Sender-Auth: q2jx5irjvUuVaWQxw88FWamPo84 Message-ID: Subject: Re: Accessing struct pthread from kernel From: Davide Italiano To: Julian Elischer Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Sun, 07 Jul 2013 23:19:35 +0000 Cc: freebsd-amd64@freebsd.org, freebsd-threads@freebsd.org X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2013 17:03:50 -0000 On Sun, Jul 7, 2013 at 9:47 AM, Julian Elischer wrote: > On 7/6/13 7:22 AM, Davide Italiano wrote: >> >> Hi, >> as a preliminary step in the implementation of adaptive spinning for >> umtx, I'm switching the pthread/umtx code so that a thread that >> acquires a pthread_mutex writes the address of struct pthread in the >> owner field of the lock instead of the thread id (tid). This is >> because having struct pthread pointer allows easily to access >> informations of the thread, and makes easy to get the state of the >> thread exported from the kernel (once this will be implemented). >> >> For what concerns the libthr side, the internal function >> _get_curthread() goes into the TLS to obtain the struct field of >> curthread, so I'm done. >> OTOH, I'm quite unsure instead about how to get address of struct >> pthread for curthread from the kernel side (for example, in >> do_lock_umutex() sys/kern/kern_umtx.c). >> >> I guess I need to write some MD code because the TLS is different on >> the various architecture supported in FreeBSD, and as a first step I >> focused on amd64. >> It looks like from the SDM that %%fs register points to the base of >> the TLS, so I think that accessing using curthread->td_pcb->pcb_fsbase >> (and then adding the proper offset to acces the right field) is a >> viable solution to do this. Am I correct? >> In particular what worries me is if the read of 'struct pthread' for >> curthread from the TLS register is atomic with respect to preemptions. >> >> Alternatively, is there an (easier way) to accomplish this task? > > there is a struct pthread for each tid (and visa versa) > you could notify the kernel of it when you make a new thread. > (new arg/call) > Yes, I previously tried implementing something like what you propose, exploiting the fact that thr_create() pass the pointer to struct pthread to the kernel as argument. The problem I see here is that the main thread is not created by thr_create() but by fork(). So, another way to pass the struct to the kernel is needed. One might think about adding another system call for the purpose, but I guess this is overkill so if you have other suggestions I'll be happpy to hear. > for what it's worth the M:N threading system used to do something like this, > with a user callback straucture supplied to the kernel.. > > >> >> Thanks, >> > Thanks for your answer, -- Davide "There are no solved problems; there are only problems that are more or less solved" -- Henri Poincare From owner-freebsd-amd64@FreeBSD.ORG Sun Jul 7 22:22:19 2013 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id BC0E1C9E; Sun, 7 Jul 2013 22:22:19 +0000 (UTC) (envelope-from davide.italiano@gmail.com) Received: from mail-vc0-x22f.google.com (mail-vc0-x22f.google.com [IPv6:2607:f8b0:400c:c03::22f]) by mx1.freebsd.org (Postfix) with ESMTP id 6E72A193E; Sun, 7 Jul 2013 22:22:19 +0000 (UTC) Received: by mail-vc0-f175.google.com with SMTP id hr11so2855664vcb.34 for ; Sun, 07 Jul 2013 15:22:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=uF/VfJIQYq8JjiRJSp/3idocAHN/KlcvFyYXTVpvl+M=; b=AF+B3DihQTWl3Xu2J53FU4pRJVjgFGtiDlFG8im7hBGmYW+/KUmrc5JXEI1RfVI63N 6mINPZdvNhaSkH967QesF5QceWZq2kOvZiAX0u2ib0o4p/JsMbXGTyAdeFdNIOkgiopB RZl4hNJuO1NOMg4Ld+FmDDAg6gbPzW5LGPFq9ywkaEPBj/A13mrJcrRWIMs0MWysDMCi YIhh/ZC2sJEMvY+GtTFHG0qFsRpOHXhzejG7JeIFh6rn+RkDwh0L5Zv+83OxYULZEMMV BD8GbW6V81h+DK2kGz04uMwiG9UYQ/+CbuZ1pDVwmhzGXTHdRjrhTWkQB6/n6Wc1JPgS OM2w== MIME-Version: 1.0 X-Received: by 10.52.66.104 with SMTP id e8mr10579798vdt.5.1373235738941; Sun, 07 Jul 2013 15:22:18 -0700 (PDT) Sender: davide.italiano@gmail.com Received: by 10.220.206.202 with HTTP; Sun, 7 Jul 2013 15:22:18 -0700 (PDT) In-Reply-To: <20130707213458.GH91021@kib.kiev.ua> References: <20130707213458.GH91021@kib.kiev.ua> Date: Sun, 7 Jul 2013 15:22:18 -0700 X-Google-Sender-Auth: XcJDmZA5zjq3nxivJoiI_WPA8Rw Message-ID: Subject: Re: Accessing struct pthread from kernel From: Davide Italiano To: Konstantin Belousov Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Mon, 08 Jul 2013 00:12:14 +0000 Cc: freebsd-amd64@freebsd.org, freebsd-threads@freebsd.org X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2013 22:22:19 -0000 On Sun, Jul 7, 2013 at 2:34 PM, Konstantin Belousov wrote: > On Sat, Jul 06, 2013 at 01:22:05AM +0200, Davide Italiano wrote: >> Hi, >> as a preliminary step in the implementation of adaptive spinning for >> umtx, I'm switching the pthread/umtx code so that a thread that >> acquires a pthread_mutex writes the address of struct pthread in the >> owner field of the lock instead of the thread id (tid). This is >> because having struct pthread pointer allows easily to access >> informations of the thread, and makes easy to get the state of the >> thread exported from the kernel (once this will be implemented). >> >> For what concerns the libthr side, the internal function >> _get_curthread() goes into the TLS to obtain the struct field of >> curthread, so I'm done. >> OTOH, I'm quite unsure instead about how to get address of struct >> pthread for curthread from the kernel side (for example, in >> do_lock_umutex() sys/kern/kern_umtx.c). > You should not, see below. > >> >> I guess I need to write some MD code because the TLS is different on >> the various architecture supported in FreeBSD, and as a first step I >> focused on amd64. >> It looks like from the SDM that %%fs register points to the base of >> the TLS, so I think that accessing using curthread->td_pcb->pcb_fsbase >> (and then adding the proper offset to acces the right field) is a >> viable solution to do this. Am I correct? >> In particular what worries me is if the read of 'struct pthread' for >> curthread from the TLS register is atomic with respect to preemptions. >> >> Alternatively, is there an (easier way) to accomplish this task? > > Coupling the libthr thread structure and kernel makes the ABI cast in > stone and avoids most possibilities of changing the libthr internals. > The same is true for kernel accessing the userspace TLS area of the thread. > > If you want kernel<->usermode communication of the thread run state, > and possibly also a way to advisory prevent a preemption of the > spinning usermode thread, you should create a dedicated parameter block > communicated from usermode to kernel on thread creation. For the main > thread, the block could be allocated by kernel by image activator, > placed on the stack and its address passed to the usermode by auxv. > > Note that you cannot access the usermode from the context switch > code. Wiring the corresponding page is very wasteful (think about a > process with 10,000 threads) and still does not provide any guarantees > since usermode can unmap or remap the range. You might see my 'fast > sigprocmask' patches where somewhat similar idea was implemented. > I think the tecnique you used for sigprocmask is neat and could be reused for sharing thread state between kernel and userland, with some modifications, thanks. That said, the problem I faced out before was slightly different. In order to implement adaptive spinning 'efficiently'[1], threads waiting for a lock held by some other thread should be able to access easily the state owner. If I understand the kernel locking code properly, to accomplish this, once a thread acquire a lock it writes the address of its struct thread in the owner field of the lock, so that other threads can easily access to his state. Now, it looks like applying such a tecnique for userspace is just impossible for the reasons you mentioned in your previous mail. The two alternatives that came up to the top of my mind are: 1) maintain an hashtable that keep track of the mapping tid->curthread, so that other thread perform a lookup on the hash table to get curthread access. 2) having an array indexed by tid where the state is stuck so that other threads can check what is the state of the lock owner. I do see problem in both of my ideas: 1) is clearly time inefficient, having to perform an hash table lookup might make useless the speedup obtained from the adaptive spinning implementation. 2) is clearly space inefficient, because in most of the situation the array would be 'sparse'. What do you prefer? If none, is there an alternative I'm missing? Thanks, > I also recommend you to look at the Solaris schedctl(2). I'll take a look at it in the next hours. [1] for some definition of 'efficient' -- Davide "There are no solved problems; there are only problems that are more or less solved" -- Henri Poincare From owner-freebsd-amd64@FreeBSD.ORG Mon Jul 8 11:41:11 2013 Return-Path: Delivered-To: freebsd-amd64@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 85DE7586 for ; Mon, 8 Jul 2013 11:41:11 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 7842115CF for ; Mon, 8 Jul 2013 11:41:11 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r68BeXga053981 for ; Mon, 8 Jul 2013 11:41:11 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r68B6XBT046065 for freebsd-amd64@FreeBSD.org; Mon, 8 Jul 2013 11:06:33 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 8 Jul 2013 11:06:33 GMT Message-Id: <201307081106.r68B6XBT046065@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-amd64@FreeBSD.org Subject: Current problem reports assigned to freebsd-amd64@FreeBSD.org X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 11:41:11 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o amd64/180018 amd64 [panic] System panics when bsnmpd is started o amd64/179996 amd64 lib32/libcrypto.so.6 causes apache SSL to crash due to o amd64/179556 amd64 FreeBSD 9-1 amd64 - Install freeze on HP Proliant DL58 o amd64/179376 amd64 xhci ehci irq storm o amd64/179288 amd64 unable to install on HP ProLiant DL380p Gen8 with 128G o amd64/179282 amd64 [PATCH] Intel SMAP for FreeBSD-CURRENT o amd64/179038 amd64 instant reboot doesnt even try too install o amd64/178792 amd64 -march=native fails with clang on certain CPU's o amd64/178357 amd64 [patch] export CPU physical and virtual address sizes o amd64/178247 amd64 linker.hints erroneously included in 9.1-RELEASE-p3 bi o amd64/176835 amd64 Fatal trap 12: page fault while in kernel mode o amd64/176474 amd64 kernel panic o amd64/175725 amd64 Audio through USB has not as good hi quality as it has o amd64/175655 amd64 When enabled tty console OS hang during boot o amd64/175370 amd64 kernel panic the rebuild kernel with vimage options in o amd64/175282 amd64 Freebsd 9.1 release amd64, mb Intel D525MW, not worked o amd64/175129 amd64 laptop won't suspend on lid close o amd64/174679 amd64 Intel i5 laptop overheats and shuts down [regression] o amd64/173869 amd64 buildworld breaks with clang o amd64/173680 amd64 9.1rc3 installer hangs at "rootpass" o amd64/173502 amd64 Patch inhibition of warnings that appear in the combin o amd64/173465 amd64 FreeBSD 9.1 restarts in random fashion after upgrade t o amd64/173311 amd64 FreeBSD 9.1 RC2 , 12 servers restart in random fashion o amd64/173235 amd64 Have received two crashes within 1 day after installin o amd64/172926 amd64 [boot] booting hangs after 9.1-RC2 install in 2nd (MBR o amd64/171835 amd64 bsdinstall abort on Dell PowerEdge R420 with PERC H310 o amd64/171814 amd64 [panic] bioq_init or bioq_remove (unsure which) o amd64/171701 amd64 [install] 9.0-rel amd64 installer 'guided' or 'manual' o amd64/171250 amd64 ldd32 cannot find some i386 libraries o amd64/170487 amd64 [boot] Thinkpad X61s cannot boot 9.1-BETA1 o amd64/170351 amd64 [kernel] [patch] amd64: 64-bit process can't always ge o amd64/170115 amd64 Serial boot broken in 9.0 o amd64/168659 amd64 [boot] FreeBSD 9 - Crash upon booting off install CD ( o amd64/167582 amd64 Compile of MySQL NDB Cluster Fails 8.2 AMD64 o amd64/167543 amd64 [kernel] Install FreeBSD can show error message with c o amd64/167393 amd64 [boot] MacBook4,1 hangs on SMP boot o amd64/166639 amd64 [boot] Syscons issue Intel D2700 o amd64/166229 amd64 [boot] Unable to install FreeBSD 9 on Acer Extensa 522 o amd64/165850 amd64 [build] 8.3-RC1 (amd64): world doesn't build with CPUT o amd64/165845 amd64 [build] Unable to build kernel on 8.2-STABLE o amd64/165351 amd64 [boot] Error while installing or booting the freeBSD O o amd64/164773 amd64 [boot] 9.0 amd64 fails to boot on HP DL145 G3 [regress o amd64/164707 amd64 FreeBSD 9 installer does not work with IBM uefi o amd64/164643 amd64 Kernel Panic at 9.0-RELEASE o amd64/164619 amd64 when logged in as root the user and group applications o amd64/164457 amd64 [install] Can't install FreeBSD 9.0 (amd64) on HP Blad o amd64/164301 amd64 [install] 9.0 - Can't install, no DHCP lease o amd64/164136 amd64 after fresh install 8.1 release or 8.2 release the har o amd64/164116 amd64 [boot] FreeBSD 9.0-RELEASE installations mediums fails o amd64/164089 amd64 FreeBSD-9.0-RELEASE-amd64-memstick.img does not boot o amd64/164073 amd64 /etc/rc warning after booting o amd64/164036 amd64 [keyboard] Moused fails on 9_0_RELENG o amd64/163736 amd64 Freebsd 8.2 with MPD5 and about 100 PPPoE clients pani o amd64/163710 amd64 setjump in userboot.so causes stack corruption o amd64/163625 amd64 Install problems of RC3 amd64 on ASRock N68 GE3 UCC o amd64/163568 amd64 hard drive naming o amd64/163285 amd64 when installing gnome2-lite not all dependent packages o amd64/163284 amd64 print manager failed to install correctly o amd64/163114 amd64 no boot on Via Nanao netbook Samsung NC20 o amd64/163092 amd64 FreeBSD 9.0-RC2 fails to boot from raid-z2 if AHCI is o amd64/163048 amd64 normal user cant mount ntfs-3g o amd64/162936 amd64 fails boot and destabilizes other OSes on FreeBSD 9 RC o amd64/162489 amd64 After some time X blanks the screen and does not respo o amd64/162314 amd64 not able to install FreeBSD-8.2-RELEASE-amd64-dvd1 as o amd64/162170 amd64 Unable to install due to freeze at "run_interrupt_driv o amd64/161974 amd64 FreeBSD 9 new installer installs succesful, renders ma o kern/160833 amd64 Keyboard USB doesn't work o amd64/157386 amd64 [powerd] Enabling powerd(8) with default settings on I o amd64/156106 amd64 [boot] boot0 fails to start o amd64/155135 amd64 [boot] Does Not Boot On a Very Standard Hardware o amd64/154957 amd64 [boot] Install boot CD won't boot up - keeps rebooting o amd64/154629 amd64 [panic] Fatal trap 9: general protection fault while i o amd64/153935 amd64 [hang] system hangs while trying to do 'shutdown -h no o amd64/153831 amd64 [boot] CD bootloader won't on Tyan s2912G2nr o amd64/153496 amd64 [hyper-v] [install] Install on Hyper-V leaves corrupt o amd64/153372 amd64 [panic] kernel panic o amd64/153175 amd64 [amd64] Kernel Panic on only FreeBSD 8 amd64 o amd64/152874 amd64 [install] 8.1 install fails where 7.3 works due to lac o amd64/152430 amd64 [boot] HP ProLiant Microserver n36l cannot boot into i o amd64/145991 amd64 [NOTES] [patch] Add a requires line to /sys/amd64/conf o amd64/144405 amd64 [build] [patch] include /usr/obj/lib32 in cleanworld t s amd64/143173 amd64 [ata] Promise FastTrack TX4 + SATA DVD, installer can' p amd64/141413 amd64 [hang] Tyan 2881 m3289 SMDC freeze o amd64/137942 amd64 [pci] 8.0-BETA2 having problems with Asus M2N-SLI-delu o amd64/127640 amd64 [amd64] gcc(1) will not build shared libraries with -f o amd64/115194 amd64 LCD screen remains blank after Dell XPS M1210 lid is c 86 problems total. From owner-freebsd-amd64@FreeBSD.ORG Mon Jul 8 21:26:09 2013 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id DB49F70E; Mon, 8 Jul 2013 21:26:09 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) by mx1.freebsd.org (Postfix) with ESMTP id 871441A11; Mon, 8 Jul 2013 21:26:09 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id E461AB94B; Mon, 8 Jul 2013 17:26:08 -0400 (EDT) From: John Baldwin To: freebsd-amd64@freebsd.org Subject: Re: Accessing struct pthread from kernel Date: Mon, 8 Jul 2013 14:56:54 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <20130707213458.GH91021@kib.kiev.ua> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201307081456.54944.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 08 Jul 2013 17:26:09 -0400 (EDT) Cc: Davide Italiano , freebsd-threads@freebsd.org X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 21:26:09 -0000 On Sunday, July 07, 2013 6:22:18 pm Davide Italiano wrote: > On Sun, Jul 7, 2013 at 2:34 PM, Konstantin Belousov wrote: > > On Sat, Jul 06, 2013 at 01:22:05AM +0200, Davide Italiano wrote: > >> Hi, > >> as a preliminary step in the implementation of adaptive spinning for > >> umtx, I'm switching the pthread/umtx code so that a thread that > >> acquires a pthread_mutex writes the address of struct pthread in the > >> owner field of the lock instead of the thread id (tid). This is > >> because having struct pthread pointer allows easily to access > >> informations of the thread, and makes easy to get the state of the > >> thread exported from the kernel (once this will be implemented). > >> > >> For what concerns the libthr side, the internal function > >> _get_curthread() goes into the TLS to obtain the struct field of > >> curthread, so I'm done. > >> OTOH, I'm quite unsure instead about how to get address of struct > >> pthread for curthread from the kernel side (for example, in > >> do_lock_umutex() sys/kern/kern_umtx.c). > > You should not, see below. > > > >> > >> I guess I need to write some MD code because the TLS is different on > >> the various architecture supported in FreeBSD, and as a first step I > >> focused on amd64. > >> It looks like from the SDM that %%fs register points to the base of > >> the TLS, so I think that accessing using curthread->td_pcb->pcb_fsbase > >> (and then adding the proper offset to acces the right field) is a > >> viable solution to do this. Am I correct? > >> In particular what worries me is if the read of 'struct pthread' for > >> curthread from the TLS register is atomic with respect to preemptions. > >> > >> Alternatively, is there an (easier way) to accomplish this task? > > > > Coupling the libthr thread structure and kernel makes the ABI cast in > > stone and avoids most possibilities of changing the libthr internals. > > The same is true for kernel accessing the userspace TLS area of the thread. > > > > If you want kernel<->usermode communication of the thread run state, > > and possibly also a way to advisory prevent a preemption of the > > spinning usermode thread, you should create a dedicated parameter block > > communicated from usermode to kernel on thread creation. For the main > > thread, the block could be allocated by kernel by image activator, > > placed on the stack and its address passed to the usermode by auxv. > > > > Note that you cannot access the usermode from the context switch > > code. Wiring the corresponding page is very wasteful (think about a > > process with 10,000 threads) and still does not provide any guarantees > > since usermode can unmap or remap the range. You might see my 'fast > > sigprocmask' patches where somewhat similar idea was implemented. > > > > I think the tecnique you used for sigprocmask is neat and could be > reused for sharing thread state between kernel and userland, with some > modifications, thanks. > > That said, the problem I faced out before was slightly different. > In order to implement adaptive spinning 'efficiently'[1], threads > waiting for a lock held by some other thread should be able to access > easily the state owner. If I understand the kernel locking code > properly, to accomplish this, once a thread acquire a lock it writes > the address of its struct thread in the owner field of the lock, so > that other threads can easily access to his state. > > Now, it looks like applying such a tecnique for userspace is just > impossible for the reasons you mentioned in your previous mail. > The two alternatives that came up to the top of my mind are: > 1) maintain an hashtable that keep track of the mapping > tid->curthread, so that other thread perform a lookup on the hash > table to get curthread access. If you have a good hash, this should be close to O(1) in the common case, so the lookup shouldn't be bad. However, you have to handle the race of a thread being added or removed to the table while you are spinning, and that seems more problematic / expensive. You only have to do a best effort though, so you could perhaps never remove items from the table (just mark them as dead somehow, though even that isn't completely safe). > 2) having an array indexed by tid where the state is stuck so that > other threads can check what is the state of the lock owner. This might not be a bad idea, though I'd possibly make it a hash table. It handles the remaining race from above since an exiting thread can just tag its tid with a "dead" state and you don't have to worry about threads trying to deref a free'd pointer. -- John Baldwin From owner-freebsd-amd64@FreeBSD.ORG Tue Jul 9 14:12:13 2013 Return-Path: Delivered-To: amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 04757831; Tue, 9 Jul 2013 14:12:13 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id CD10B1219; Tue, 9 Jul 2013 14:12:12 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r69ECCqF003064; Tue, 9 Jul 2013 10:12:12 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r69ECCA1003063; Tue, 9 Jul 2013 14:12:12 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 9 Jul 2013 14:12:12 GMT Message-Id: <201307091412.r69ECCA1003063@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on amd64/amd64 Precedence: bulk X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 14:12:13 -0000 TB --- 2013-07-09 10:10:19 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-07-09 10:10:19 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-07-09 10:10:19 - starting HEAD tinderbox run for amd64/amd64 TB --- 2013-07-09 10:10:19 - cleaning the object tree TB --- 2013-07-09 10:10:19 - /usr/local/bin/svn stat /src TB --- 2013-07-09 10:10:23 - At svn revision 253088 TB --- 2013-07-09 10:10:24 - building world TB --- 2013-07-09 10:10:24 - CROSS_BUILD_TESTING=YES TB --- 2013-07-09 10:10:24 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-09 10:10:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-09 10:10:24 - SRCCONF=/dev/null TB --- 2013-07-09 10:10:24 - TARGET=amd64 TB --- 2013-07-09 10:10:24 - TARGET_ARCH=amd64 TB --- 2013-07-09 10:10:24 - TZ=UTC TB --- 2013-07-09 10:10:24 - __MAKE_CONF=/dev/null TB --- 2013-07-09 10:10:24 - cd /src TB --- 2013-07-09 10:10:24 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Tue Jul 9 10:10:33 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Tue Jul 9 13:57:07 UTC 2013 TB --- 2013-07-09 13:57:07 - generating LINT kernel config TB --- 2013-07-09 13:57:07 - cd /src/sys/amd64/conf TB --- 2013-07-09 13:57:07 - /usr/bin/make -B LINT TB --- 2013-07-09 13:57:07 - cd /src/sys/amd64/conf TB --- 2013-07-09 13:57:07 - /usr/sbin/config -m LINT TB --- 2013-07-09 13:57:07 - building LINT kernel TB --- 2013-07-09 13:57:07 - CROSS_BUILD_TESTING=YES TB --- 2013-07-09 13:57:07 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-09 13:57:07 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-09 13:57:07 - SRCCONF=/dev/null TB --- 2013-07-09 13:57:07 - TARGET=amd64 TB --- 2013-07-09 13:57:07 - TARGET_ARCH=amd64 TB --- 2013-07-09 13:57:07 - TZ=UTC TB --- 2013-07-09 13:57:07 - __MAKE_CONF=/dev/null TB --- 2013-07-09 13:57:07 - cd /src TB --- 2013-07-09 13:57:07 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jul 9 13:57:07 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] ^ /src/sys/net/vnet.h:440:37: note: expanded from macro 'VNET_DECLARE' #define VNET_DECLARE(t, n) extern t n ^ /src/sys/netinet/sctp_input.c:5717:30: error: member reference base type 'counter_u64_t [1570]' is not a structure or union MODULE_GLOBAL(ipsec6stat).in_polvio++; ~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~ 4 errors generated. *** Error code 1 Stop. make: stopped in /obj/amd64.amd64/src/sys/LINT *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-07-09 14:12:11 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-07-09 14:12:11 - ERROR: failed to build LINT kernel TB --- 2013-07-09 14:12:11 - 11533.05 user 2076.41 system 14512.22 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-amd64-amd64.full From owner-freebsd-amd64@FreeBSD.ORG Thu Jul 11 23:02:48 2013 Return-Path: Delivered-To: amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BA92466D; Thu, 11 Jul 2013 23:02:48 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 8CC501C9D; Thu, 11 Jul 2013 23:02:48 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r6BN2lcC090235; Thu, 11 Jul 2013 19:02:47 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r6BN2lLf090233; Thu, 11 Jul 2013 23:02:47 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 11 Jul 2013 23:02:47 GMT Message-Id: <201307112302.r6BN2lLf090233@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on amd64/amd64 Precedence: bulk X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 23:02:48 -0000 TB --- 2013-07-11 17:00:18 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-07-11 17:00:18 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-07-11 17:00:18 - starting HEAD tinderbox run for amd64/amd64 TB --- 2013-07-11 17:00:18 - cleaning the object tree TB --- 2013-07-11 17:00:18 - /usr/local/bin/svn stat /src TB --- 2013-07-11 17:00:23 - At svn revision 253214 TB --- 2013-07-11 17:00:24 - building world TB --- 2013-07-11 17:00:24 - CROSS_BUILD_TESTING=YES TB --- 2013-07-11 17:00:24 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-11 17:00:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-11 17:00:24 - SRCCONF=/dev/null TB --- 2013-07-11 17:00:24 - TARGET=amd64 TB --- 2013-07-11 17:00:24 - TARGET_ARCH=amd64 TB --- 2013-07-11 17:00:24 - TZ=UTC TB --- 2013-07-11 17:00:24 - __MAKE_CONF=/dev/null TB --- 2013-07-11 17:00:24 - cd /src TB --- 2013-07-11 17:00:24 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Thu Jul 11 17:00:31 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Thu Jul 11 20:48:41 UTC 2013 TB --- 2013-07-11 20:48:41 - generating LINT kernel config TB --- 2013-07-11 20:48:41 - cd /src/sys/amd64/conf TB --- 2013-07-11 20:48:41 - /usr/bin/make -B LINT TB --- 2013-07-11 20:48:41 - cd /src/sys/amd64/conf TB --- 2013-07-11 20:48:41 - /usr/sbin/config -m LINT TB --- 2013-07-11 20:48:41 - building LINT kernel TB --- 2013-07-11 20:48:41 - CROSS_BUILD_TESTING=YES TB --- 2013-07-11 20:48:41 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-11 20:48:41 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-11 20:48:41 - SRCCONF=/dev/null TB --- 2013-07-11 20:48:41 - TARGET=amd64 TB --- 2013-07-11 20:48:41 - TARGET_ARCH=amd64 TB --- 2013-07-11 20:48:41 - TZ=UTC TB --- 2013-07-11 20:48:41 - __MAKE_CONF=/dev/null TB --- 2013-07-11 20:48:41 - cd /src TB --- 2013-07-11 20:48:41 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Jul 11 20:48:41 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Thu Jul 11 21:20:29 UTC 2013 TB --- 2013-07-11 21:20:29 - cd /src/sys/amd64/conf TB --- 2013-07-11 21:20:29 - /usr/sbin/config -m LINT-NOINET TB --- 2013-07-11 21:20:29 - building LINT-NOINET kernel TB --- 2013-07-11 21:20:29 - CROSS_BUILD_TESTING=YES TB --- 2013-07-11 21:20:29 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-11 21:20:29 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-11 21:20:29 - SRCCONF=/dev/null TB --- 2013-07-11 21:20:29 - TARGET=amd64 TB --- 2013-07-11 21:20:29 - TARGET_ARCH=amd64 TB --- 2013-07-11 21:20:29 - TZ=UTC TB --- 2013-07-11 21:20:29 - __MAKE_CONF=/dev/null TB --- 2013-07-11 21:20:29 - cd /src TB --- 2013-07-11 21:20:29 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET >>> Kernel build for LINT-NOINET started on Thu Jul 11 21:20:30 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOINET completed on Thu Jul 11 21:50:20 UTC 2013 TB --- 2013-07-11 21:50:20 - cd /src/sys/amd64/conf TB --- 2013-07-11 21:50:20 - /usr/sbin/config -m LINT-NOINET6 TB --- 2013-07-11 21:50:20 - building LINT-NOINET6 kernel TB --- 2013-07-11 21:50:20 - CROSS_BUILD_TESTING=YES TB --- 2013-07-11 21:50:20 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-11 21:50:20 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-11 21:50:20 - SRCCONF=/dev/null TB --- 2013-07-11 21:50:20 - TARGET=amd64 TB --- 2013-07-11 21:50:20 - TARGET_ARCH=amd64 TB --- 2013-07-11 21:50:20 - TZ=UTC TB --- 2013-07-11 21:50:20 - __MAKE_CONF=/dev/null TB --- 2013-07-11 21:50:20 - cd /src TB --- 2013-07-11 21:50:20 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 >>> Kernel build for LINT-NOINET6 started on Thu Jul 11 21:50:20 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOINET6 completed on Thu Jul 11 22:20:11 UTC 2013 TB --- 2013-07-11 22:20:11 - cd /src/sys/amd64/conf TB --- 2013-07-11 22:20:11 - /usr/sbin/config -m LINT-NOIP TB --- 2013-07-11 22:20:11 - building LINT-NOIP kernel TB --- 2013-07-11 22:20:11 - CROSS_BUILD_TESTING=YES TB --- 2013-07-11 22:20:11 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-11 22:20:11 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-11 22:20:11 - SRCCONF=/dev/null TB --- 2013-07-11 22:20:11 - TARGET=amd64 TB --- 2013-07-11 22:20:11 - TARGET_ARCH=amd64 TB --- 2013-07-11 22:20:11 - TZ=UTC TB --- 2013-07-11 22:20:11 - __MAKE_CONF=/dev/null TB --- 2013-07-11 22:20:11 - cd /src TB --- 2013-07-11 22:20:11 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOIP >>> Kernel build for LINT-NOIP started on Thu Jul 11 22:20:11 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOIP completed on Thu Jul 11 22:47:36 UTC 2013 TB --- 2013-07-11 22:47:36 - cd /src/sys/amd64/conf TB --- 2013-07-11 22:47:36 - /usr/sbin/config -m LINT-VIMAGE TB --- 2013-07-11 22:47:36 - building LINT-VIMAGE kernel TB --- 2013-07-11 22:47:36 - CROSS_BUILD_TESTING=YES TB --- 2013-07-11 22:47:36 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-11 22:47:36 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-11 22:47:36 - SRCCONF=/dev/null TB --- 2013-07-11 22:47:36 - TARGET=amd64 TB --- 2013-07-11 22:47:36 - TARGET_ARCH=amd64 TB --- 2013-07-11 22:47:36 - TZ=UTC TB --- 2013-07-11 22:47:36 - __MAKE_CONF=/dev/null TB --- 2013-07-11 22:47:36 - cd /src TB --- 2013-07-11 22:47:36 - /usr/bin/make -B buildkernel KERNCONF=LINT-VIMAGE >>> Kernel build for LINT-VIMAGE started on Thu Jul 11 22:47:36 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] ^ /src/sys/net/vnet.h:217:20: note: expanded from macro 'CURVNET_SET_VERBOSE' CURVNET_SET_QUIET(arg) ^ /src/sys/net/vnet.h:214:12: note: expanded from macro 'CURVNET_SET_QUIET' curvnet = arg; ^ 5 errors generated. *** Error code 1 Stop. make: stopped in /obj/amd64.amd64/src/sys/LINT-VIMAGE *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-07-11 23:02:47 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-07-11 23:02:47 - ERROR: failed to build LINT-VIMAGE kernel TB --- 2013-07-11 23:02:47 - 17093.32 user 3202.59 system 21748.86 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-amd64-amd64.full From owner-freebsd-amd64@FreeBSD.ORG Fri Jul 12 03:25:13 2013 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 14E4A3C3; Fri, 12 Jul 2013 03:25:13 +0000 (UTC) (envelope-from bsd-lists@1command.com) Received: from udns.ultimateDNS.NET (ultimatedns.net [209.180.214.225]) by mx1.freebsd.org (Postfix) with ESMTP id D25DB16B1; Fri, 12 Jul 2013 03:25:12 +0000 (UTC) Received: from udns.ultimateDNS.NET (localhost [127.0.0.1]) by udns.ultimateDNS.NET (8.14.5/8.14.5) with ESMTP id r6C3P06q009288; Thu, 11 Jul 2013 20:25:06 -0700 (PDT) (envelope-from bsd-lists@1command.com) Received: (from www@localhost) by udns.ultimateDNS.NET (8.14.5/8.14.5/Submit) id r6C3OtNu009287; Thu, 11 Jul 2013 20:24:55 -0700 (PDT) (envelope-from bsd-lists@1command.com) Received: from udns.ultimatedns.net ([209.180.214.225]) (UDNSMS authenticated user chrish) by ultimatedns.net with HTTP; Thu, 11 Jul 2013 20:24:55 -0700 (PDT) Message-ID: <4640843f1a35075d295f99aa9e8ed951.authenticated@ultimatedns.net> Date: Thu, 11 Jul 2013 20:24:55 -0700 (PDT) Subject: What are the ideal ranges for kern.ipc.shm*? From: "Chris H" To: "freebsd-amd64" , "freebsd-stable" User-Agent: UDNSMS/2.0.3 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 03:25:13 -0000 Greetings, Over the years using the xfce4 desktop, I would occasionally receive SHM ERROR messages. As they never interfered (so's I could notice), I always put off attempting to track the cause down. However, now having performed a fairly major upgrade (~1yr since last), The error appears to greatly affect KDE4 (used to use kde3) applications I run within xfce4. The windows don't re-draw correctly, and I receive additional errors,as well: ... Resource id: 0x0 X Error: BadDrawable (invalid Pixmap or Window parameter) 9 Major opcode: 62 (X_CopyArea) Resource id: 0x0 X Error: BadDrawable (invalid Pixmap or Window parameter) 9 Major opcode: 62 (X_CopyArea) Resource id: 0x0 X Error: BadDrawable (invalid Pixmap or Window parameter) 9 Major opcode: 62 (X_CopyArea) Resource id: 0x0 X Error: BadDrawable (invalid Pixmap or Window parameter) 9 Major opcode: 62 (X_CopyArea) Resource id: 0x0 QCoreApplication::postEvent: Unexpected null receiver ... After much searching, it would appear to be related to the kern.ipc.shm* values. pertinent details follow: FreeBSD udns 8.4-STABLE FreeBSD 8.4-STABLE #3: Tue Jul 2 13:41:21 PDT 2013 root@udns:/usr/obj/usr/src/sys/AMD64 amd64 with 64Gb ram, and 3 cores, and nvidia-driver-308.88_1. # ipcs -M shminfo: shmmax: 33554432 (max shared memory segment size) shmmin: 1 (min shared memory segment size) shmmni: 192 (max number of shared memory identifiers) shmseg: 128 (max shared memory segments per process) shmall: 8192 (max amount of shared memory in pages) Thank you for all your time, and consideration. --chris From owner-freebsd-amd64@FreeBSD.ORG Fri Jul 12 05:45:37 2013 Return-Path: Delivered-To: amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D598C5A2; Fri, 12 Jul 2013 05:45:37 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 8934F1B1A; Fri, 12 Jul 2013 05:45:37 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r6C5jbWc048902; Fri, 12 Jul 2013 01:45:37 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r6C5jbO8048897; Fri, 12 Jul 2013 05:45:37 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 12 Jul 2013 05:45:37 GMT Message-Id: <201307120545.r6C5jbO8048897@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on amd64/amd64 Precedence: bulk X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 05:45:37 -0000 TB --- 2013-07-12 04:10:19 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-07-12 04:10:19 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-07-12 04:10:19 - starting HEAD tinderbox run for amd64/amd64 TB --- 2013-07-12 04:10:19 - cleaning the object tree TB --- 2013-07-12 04:18:47 - /usr/local/bin/svn stat /src TB --- 2013-07-12 04:18:50 - At svn revision 253248 TB --- 2013-07-12 04:18:51 - building world TB --- 2013-07-12 04:18:51 - CROSS_BUILD_TESTING=YES TB --- 2013-07-12 04:18:51 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-12 04:18:51 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-12 04:18:51 - SRCCONF=/dev/null TB --- 2013-07-12 04:18:51 - TARGET=amd64 TB --- 2013-07-12 04:18:51 - TARGET_ARCH=amd64 TB --- 2013-07-12 04:18:51 - TZ=UTC TB --- 2013-07-12 04:18:51 - __MAKE_CONF=/dev/null TB --- 2013-07-12 04:18:51 - cd /src TB --- 2013-07-12 04:18:51 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Jul 12 04:18:58 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] ^~~~~~~~~~~~ /obj/amd64.amd64/src/tmp/usr/include/math.h:128:20: note: expanded from macro 'signbit' #define signbit(x) __fp_type_select(x, __signbitf, __signbit, __signbitl) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /obj/amd64.amd64/src/tmp/usr/include/math.h:91:2: note: expanded from macro '__fp_type_select' __builtin_types_compatible_p(__typeof(x), long double), ld(x), \ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 6 errors generated. *** Error code 1 Stop. make: stopped in /src/gnu/lib/libstdc++ *** Error code 1 Stop. make: stopped in /src/gnu/lib *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-07-12 05:45:37 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-07-12 05:45:37 - ERROR: failed to build world TB --- 2013-07-12 05:45:37 - 4353.59 user 679.80 system 5717.27 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-amd64-amd64.full From owner-freebsd-amd64@FreeBSD.ORG Fri Jul 12 08:40:53 2013 Return-Path: Delivered-To: amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C777C235; Fri, 12 Jul 2013 08:40:53 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 7A0481633; Fri, 12 Jul 2013 08:40:53 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r6C8eqgr066106; Fri, 12 Jul 2013 04:40:52 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r6C8eqJr066105; Fri, 12 Jul 2013 08:40:52 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 12 Jul 2013 08:40:52 GMT Message-Id: <201307120840.r6C8eqJr066105@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on amd64/amd64 Precedence: bulk X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 08:40:53 -0000 TB --- 2013-07-12 07:10:22 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-07-12 07:10:22 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-07-12 07:10:22 - starting HEAD tinderbox run for amd64/amd64 TB --- 2013-07-12 07:10:22 - cleaning the object tree TB --- 2013-07-12 07:12:15 - /usr/local/bin/svn stat /src TB --- 2013-07-12 07:12:19 - At svn revision 253253 TB --- 2013-07-12 07:12:20 - building world TB --- 2013-07-12 07:12:20 - CROSS_BUILD_TESTING=YES TB --- 2013-07-12 07:12:20 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-12 07:12:20 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-12 07:12:20 - SRCCONF=/dev/null TB --- 2013-07-12 07:12:20 - TARGET=amd64 TB --- 2013-07-12 07:12:20 - TARGET_ARCH=amd64 TB --- 2013-07-12 07:12:20 - TZ=UTC TB --- 2013-07-12 07:12:20 - __MAKE_CONF=/dev/null TB --- 2013-07-12 07:12:20 - cd /src TB --- 2013-07-12 07:12:20 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Jul 12 07:12:27 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] ^~~~~~~~~~~~ /obj/amd64.amd64/src/tmp/usr/include/math.h:128:20: note: expanded from macro 'signbit' #define signbit(x) __fp_type_select(x, __signbitf, __signbit, __signbitl) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /obj/amd64.amd64/src/tmp/usr/include/math.h:91:2: note: expanded from macro '__fp_type_select' __builtin_types_compatible_p(__typeof(x), long double), ld(x), \ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 6 errors generated. *** Error code 1 Stop. make: stopped in /src/gnu/lib/libstdc++ *** Error code 1 Stop. make: stopped in /src/gnu/lib *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-07-12 08:40:52 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-07-12 08:40:52 - ERROR: failed to build world TB --- 2013-07-12 08:40:52 - 4354.00 user 703.61 system 5430.38 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-amd64-amd64.full From owner-freebsd-amd64@FreeBSD.ORG Fri Jul 12 09:38:56 2013 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A2D72192; Fri, 12 Jul 2013 09:38:56 +0000 (UTC) (envelope-from villa.alberto@gmail.com) Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::236]) by mx1.freebsd.org (Postfix) with ESMTP id 18E9219CF; Fri, 12 Jul 2013 09:38:55 +0000 (UTC) Received: by mail-wg0-f54.google.com with SMTP id n11so7897715wgh.33 for ; Fri, 12 Jul 2013 02:38:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=Bq2P/5UgVaslEAc1iigrH1cX1U1dRiEXy4FvT6fUSSs=; b=FAjU60+NHO11CH6X4B52m9DZ0lIkv7yQ3s/snhBFgS5/sTnrvjKi/PejnfV822DJbl ifUvHogFp+0FDkjgjl6rkhSmrZqNP8EQmTGScI6V8mZyOz5UMncNqRdoZxz7mRBKA4nL tfklQ89K7CG+2BFxVWWRcg3wKtHK4QhdKVe7WMIra0q7NUpe+aS8xr/NAv4FKj9vxEdW d36SXXavFavG15bVD7n4OFQiWdARchvOeK5BDbZ6f3pb/8V4GpLQ/eV3LsFKPSUKTr/W xcIY7/Yo4dXHVJRGZajH821Zx7MOgVo5RCWDaj1EQOoo0PVTLDsBB8U7dNZP8WU7+FgQ e3lw== X-Received: by 10.194.20.97 with SMTP id m1mr23394954wje.31.1373621934297; Fri, 12 Jul 2013 02:38:54 -0700 (PDT) MIME-Version: 1.0 Sender: villa.alberto@gmail.com Received: by 10.217.117.136 with HTTP; Fri, 12 Jul 2013 02:38:33 -0700 (PDT) In-Reply-To: <4640843f1a35075d295f99aa9e8ed951.authenticated@ultimatedns.net> References: <4640843f1a35075d295f99aa9e8ed951.authenticated@ultimatedns.net> From: Alberto Villa Date: Fri, 12 Jul 2013 11:38:33 +0200 X-Google-Sender-Auth: xAA5a70zvC8kZ_2QBVP_RTF8I1Q Message-ID: Subject: Re: What are the ideal ranges for kern.ipc.shm*? To: Chris H Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Fri, 12 Jul 2013 11:28:36 +0000 Cc: freebsd-stable , freebsd-amd64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 09:38:56 -0000 On Fri, Jul 12, 2013 at 5:24 AM, Chris H wrote: > Greetings, > Over the years using the xfce4 desktop, I would occasionally receive > SHM ERROR messages. As they never interfered (so's I could notice), I > always put off attempting to track the cause down. However, now having > performed a fairly major upgrade (~1yr since last), The error appears > to greatly affect KDE4 (used to use kde3) applications I run within > xfce4. The windows don't re-draw correctly, and I receive additional > errors,as well: > ... > Resource id: 0x0 > X Error: BadDrawable (invalid Pixmap or Window parameter) 9 > Major opcode: 62 (X_CopyArea) > Resource id: 0x0 > ... > After much searching, it would appear to be related to the > kern.ipc.shm* values. $ cat /usr/ports/x11-toolkits/qt4-gui/pkg-message Qt paint engine makes common use of shared memory. To avoid MIT-SHM errors (i.e., blank windows), you probably need to raise shared memory limits in loader.conf(5). The following should be safe values for the KDE Plasma Desktop: kern.ipc.shmall=32768 kern.ipc.shmmni=1024 kern.ipc.shmseg=1024 -- Alberto Villa, FreeBSD committer http://people.FreeBSD.org/~avilla From owner-freebsd-amd64@FreeBSD.ORG Fri Jul 12 11:49:46 2013 Return-Path: Delivered-To: amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6D680D67; Fri, 12 Jul 2013 11:49:46 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 22B4E1F0D; Fri, 12 Jul 2013 11:49:46 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r6CBnjPo011030; Fri, 12 Jul 2013 07:49:45 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r6CBnjoJ011029; Fri, 12 Jul 2013 11:49:45 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 12 Jul 2013 11:49:45 GMT Message-Id: <201307121149.r6CBnjoJ011029@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on amd64/amd64 Precedence: bulk X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 11:49:46 -0000 TB --- 2013-07-12 10:20:16 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-07-12 10:20:16 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-07-12 10:20:16 - starting HEAD tinderbox run for amd64/amd64 TB --- 2013-07-12 10:20:16 - cleaning the object tree TB --- 2013-07-12 10:22:42 - /usr/local/bin/svn stat /src TB --- 2013-07-12 10:22:46 - At svn revision 253259 TB --- 2013-07-12 10:22:47 - building world TB --- 2013-07-12 10:22:47 - CROSS_BUILD_TESTING=YES TB --- 2013-07-12 10:22:47 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-12 10:22:47 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-12 10:22:47 - SRCCONF=/dev/null TB --- 2013-07-12 10:22:47 - TARGET=amd64 TB --- 2013-07-12 10:22:47 - TARGET_ARCH=amd64 TB --- 2013-07-12 10:22:47 - TZ=UTC TB --- 2013-07-12 10:22:47 - __MAKE_CONF=/dev/null TB --- 2013-07-12 10:22:47 - cd /src TB --- 2013-07-12 10:22:47 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Jul 12 10:22:53 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] ^~~~~~~~~~~~ /obj/amd64.amd64/src/tmp/usr/include/math.h:128:20: note: expanded from macro 'signbit' #define signbit(x) __fp_type_select(x, __signbitf, __signbit, __signbitl) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /obj/amd64.amd64/src/tmp/usr/include/math.h:91:2: note: expanded from macro '__fp_type_select' __builtin_types_compatible_p(__typeof(x), long double), ld(x), \ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 6 errors generated. *** Error code 1 Stop. make: stopped in /src/gnu/lib/libstdc++ *** Error code 1 Stop. make: stopped in /src/gnu/lib *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-07-12 11:49:45 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-07-12 11:49:45 - ERROR: failed to build world TB --- 2013-07-12 11:49:45 - 4351.96 user 686.09 system 5368.91 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-amd64-amd64.full From owner-freebsd-amd64@FreeBSD.ORG Fri Jul 12 13:40:27 2013 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BE89C7D5; Fri, 12 Jul 2013 13:40:27 +0000 (UTC) (envelope-from bsd-lists@1command.com) Received: from udns.ultimateDNS.NET (ultimatedns.net [209.180.214.225]) by mx1.freebsd.org (Postfix) with ESMTP id 7368D16FD; Fri, 12 Jul 2013 13:40:26 +0000 (UTC) Received: from udns.ultimateDNS.NET (localhost [127.0.0.1]) by udns.ultimateDNS.NET (8.14.5/8.14.5) with ESMTP id r6CDeLIU041047; Fri, 12 Jul 2013 06:40:27 -0700 (PDT) (envelope-from bsd-lists@1command.com) Received: (from www@localhost) by udns.ultimateDNS.NET (8.14.5/8.14.5/Submit) id r6CDeG0J041041; Fri, 12 Jul 2013 06:40:16 -0700 (PDT) (envelope-from bsd-lists@1command.com) Received: from udns.ultimatedns.net ([209.180.214.225]) (UDNSMS authenticated user chrish) by ultimatedns.net with HTTP; Fri, 12 Jul 2013 06:40:16 -0700 (PDT) Message-ID: <7a0e92dcb2921d9b6bf29476baf09e47.authenticated@ultimatedns.net> In-Reply-To: References: <4640843f1a35075d295f99aa9e8ed951.authenticated@ultimatedns.net> Date: Fri, 12 Jul 2013 06:40:16 -0700 (PDT) Subject: Re: What are the ideal ranges for kern.ipc.shm*? From: "Chris H" To: "freebsd-stable" , "freebsd-amd64" User-Agent: UDNSMS/2.0.3 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 13:40:27 -0000 Greetings Alberto, and thank you for the reply. > On Fri, Jul 12, 2013 at 5:24 AM, Chris H wrote: >> Greetings, >> Over the years using the xfce4 desktop, I would occasionally receive >> SHM ERROR messages. As they never interfered (so's I could notice), I >> always put off attempting to track the cause down. However, now having >> performed a fairly major upgrade (~1yr since last), The error appears >> to greatly affect KDE4 (used to use kde3) applications I run within >> xfce4. The windows don't re-draw correctly, and I receive additional >> errors,as well: >> ... >> Resource id: 0x0 >> X Error: BadDrawable (invalid Pixmap or Window parameter) 9 >> Major opcode: 62 (X_CopyArea) >> Resource id: 0x0 >> ... >> After much searching, it would appear to be related to the >> kern.ipc.shm* values. > > $ cat /usr/ports/x11-toolkits/qt4-gui/pkg-message > > Qt paint engine makes common use of shared memory. To avoid MIT-SHM > errors (i.e., blank windows), you probably need to raise shared memory > limits in loader.conf(5). The following should be safe values for the > KDE Plasma Desktop: > > kern.ipc.shmall=32768 > kern.ipc.shmmni=1024 > kern.ipc.shmseg=1024 Yes, I followed those instructions when I received the message after the upgrade from qt3 --> qt4. Entering those numbers in loader.conf(5) caused the server to freeze and re-boot ~20 seconds after starting X. --chris > -- > Alberto Villa, FreeBSD committer > http://people.FreeBSD.org/~avilla > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >