From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HTML_MESSAGE,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 17506 invoked from network); 8 Nov 2023 23:42:19 -0000 Received: from tb-ob1.topicbox.com (64.147.108.173) by inbox.vuxu.org with ESMTPUTF8; 8 Nov 2023 23:42:19 -0000 Received: from tb-mx0.topicbox.com (tb-mx0.nyi.icgroup.com [10.90.30.73]) by tb-ob1.topicbox.com (Postfix) with ESMTP id BFB211A029 for ; Wed, 8 Nov 2023 18:42:17 -0500 (EST) (envelope-from bounce.mM62c35c1979d8c1e3f89621f0.r522be890-2105-11eb-b15e-8d699134e1fa@9fans.bounce.topicbox.com) Received: by tb-mx0.topicbox.com (Postfix, from userid 1132) id B79FA2D7083A; Wed, 8 Nov 2023 18:42:17 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=9fans.net; h=to:subject :message-id:references:in-reply-to:date:mime-version :content-type:content-transfer-encoding:list-help:list-id :list-post:list-subscribe:reply-to:from:list-unsubscribe; s= dkim-1; t=1699486937; x=1699573337; bh=WR7DyuAG0gltCEMqhFY5CZOOF LZXNfEom6fg99yQ3qI=; b=qhhSNzHey3osNVsz58OMKOrbjxLdC7euuLazcy8Kr 8KKNI3MKUjZfrhcntY1zu3vF02KeRRfa8c5Bfos2aNF6CSby/liSbW3NbDeiC1us Tif3g2UkErntLypkrs90Q7QRCcgBrCP6l2AGycAHi0GgG0uWQR6su49Niy+Z3C9a yY= To: 9fans <9fans@9fans.net> Subject: Re: [9fans] odd rwakeup qunlock behaviour in 9vx Message-Id: <16994869310.bb41deF.62237@composer.9fans.topicbox.com> References: <05DC7BC5698D779E601D2AB8E1882F4B@eigenstate.org> In-Reply-To: <05DC7BC5698D779E601D2AB8E1882F4B@eigenstate.org> Date: Wed, 8 Nov 2023 18:42:11 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=16994869311.614e1Ca.62237 Content-Transfer-Encoding: 7bit Topicbox-Policy-Reasoning: allow: sender is a member Topicbox-Message-UUID: 702cbb58-7e90-11ee-a673-34c640decc0b Archived-At: =?UTF-8?B?PGh0dHBzOi8vOWZhbnMudG9waWNib3guY29tL2dyb3Vwcy85?= =?UTF-8?B?ZmFucy9UN2E1YmIzY2RlNTBhOGE5YS1NNjJjMzVjMTk3OWQ4YzFlM2Y4OTYy?= =?UTF-8?B?MWYwPg==?= List-Help: List-Id: "9fans" <9fans.9fans.net> List-Post: List-Software: Topicbox v0 List-Subscribe: Precedence: list Reply-To: 9fans <9fans@9fans.net> From: "ibrahim via 9fans" <9fans@9fans.net> List-Unsubscribe: , Topicbox-Delivery-ID: 2:9fans:437d30aa-c441-11e9-8a57-d036212d11b0:522be890-2105-11eb-b15e-8d699134e1fa:M62c35c1979d8c1e3f89621f0:1:maFWVhSbajRIKzDIaY23H-5Emvsfz5bH35lGwtiAHIc --16994869311.614e1Ca.62237 Date: Wed, 8 Nov 2023 18:42:11 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks for your reply. This behavior only appeared while using shared memor= y in form of segments. I already solved this problem by exchanging qlock, q= unlock by lock (canlock). I also didn't have any problems while using other= forms of memory constellations but while using shared memory segments this= problem surfaced. I need this for my vgafb implementation which makes use of shared physical = and normal shared memory segments. After testing on bare metal I also found= out that qlock, qunlock, rsleep, rwake ... caused kernel crashes on bare m= etal while usual locks work without any problems.=20 On 9vx I had to simulate vgafb with a implementation which provided my fram= ebuffer with a shared segment to transfer changes to devdraw this made deve= lopment easier but the moment I had concurrent access my software crashed. = Debugging made clear the source of the crash was the described call combina= tion while using shared memory segments. If there is interest for reproducing the exact circumstances I can write a = small example app which involves different processes accessing the same sha= red memory segments which are inherited by the rfork methods. ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T7a5bb3cde50a8a9a-M62c35= c1979d8c1e3f89621f0 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription --16994869311.614e1Ca.62237 Date: Wed, 8 Nov 2023 18:42:11 -0500 MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for your reply. This behavior only appe= ared while using shared memory in form of segments. I already solved this p= roblem by exchanging qlock, qunlock by lock (canlock). I also didn't ha= ve any problems while using other forms of memory constellations but while = using shared memory segments this problem surfaced.

<= /div>
I need this for my vgafb implementation which makes use of shared= physical and normal shared memory segments. After testing on bare metal I = also found out that qlock, qunlock, rsleep, rwake ... caused kernel crashes= on bare metal while usual locks work without any problems.

On 9vx I had to simulate vgafb with a implementation whi= ch provided my framebuffer with a shared segment to transfer changes to dev= draw this made development easier but the moment I had concurrent access my= software crashed. Debugging made clear the source of the crash was the des= cribed call combination while using shared memory segments.

If there is interest for reproducing the exact circumstan= ces I can write a small example app which involves different processes acce= ssing the same shared memory segments which are inherited by the rfork meth= ods.

= --16994869311.614e1Ca.62237--