From nobody Mon Feb 20 13:53:21 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4PL3m325nSz3sqpq for ; Mon, 20 Feb 2023 13:53:23 +0000 (UTC) (envelope-from kd@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PL3m31SMCz3qXt; Mon, 20 Feb 2023 13:53:23 +0000 (UTC) (envelope-from kd@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1676901203; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Tfv3QfqZx9H7riBYfi58c1yoyilF/y7AdqP4LZb+kbU=; b=J8eBqmLeQ0XW7wzKb7/s72+iGyZI1QQOlRl6ZzYh6193Y+Vnc2lBxXwc/Sp029msrCW80Z 0nmsbgJx39DKzVs+uyq0QG9cmnBG/DpsHATjJLMEHbVNCm7HNu3yT2bhmWw0504b2DS+Je 78kNn3604xOv+87Fuf1McLeGgdbF5nBOA+cZlHwGgoduhjya8trF+dV/oPy322VZnQOMKk oq2LBAIStQTTIxmo1IWH/xOyYQQx6ll8qrVOnmEP14uI8adrsTRTuWq6NitlCiYFwBLeU5 fIyukYmx/PfMz3izoBdZG42Cz6Oq88voTUv9evjwtts7ZSix6CpYOsnSGjScRA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1676901203; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Tfv3QfqZx9H7riBYfi58c1yoyilF/y7AdqP4LZb+kbU=; b=kLWgMRK2HsmXs5C0PfvL67itmnnQux33JFiEbELqaHpCn4ZcOOIPokb3hyWHNQ5n7sAPK8 CqcxMWZOPU8tHRrwLiuMvYNSvwCY0Zx4OPtXlNzTN44F70UZBLqVockgosuuKc0rRPpqTO JJo+GVuvuO/cIqZ0Gea4Uz1McnYzBvW3KxmWPibu2n3lf7y/FSwILMDsfLvpL5oBuKLrKv KWZYN3/vPxtZsu089KtrIs2c2Q0M7jTfb0/EQYSkvvKaxrhJrCEkVkf6Fm33upptI01VxH z3/rmrxnsj9PqLiyKEgWBPVqflLMF6xBsXrHXysqPJEanHyoeYpKKcjjjJEA/w== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1676901203; a=rsa-sha256; cv=none; b=MBHpkoPj0ZzFj7MQ/cvMnMb42kM3qMkYnoC/jeMZrJULTAYlvCAPOCOnWNKFqyMSlDaS0K iW6RhvrGM6AEaP4W9Fkkum9MABFMvkyNRj7wj47N4oO0aFubWNZj5in3ijsHwtOky5w2LU 1pvNaF+oHLuqbMbET9unV4SGHvsxPIG8fPjlDf+5RaeGW4uaNk/7/zKiR141njoZPEMduD 09QZ6XnSO1hiKKyn7Pe1XcQoqF/PBGY2eERbJyetvRNpKxlesnukHouBFsu5zzYnQl4SK7 rScGSbY5lYlgUEPRKrj3VppByeq863xLS4UK4Ow1D5qVAGe1yynFhZ1G7ju8tw== Received: from [192.168.1.3] (46.205.209.129.nat.ftth.dynamic.t-mobile.pl [46.205.209.129]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) (Authenticated sender: kd) by smtp.freebsd.org (Postfix) with ESMTPSA id 4PL3m22RTWz15w2; Mon, 20 Feb 2023 13:53:22 +0000 (UTC) (envelope-from kd@FreeBSD.org) Content-Type: multipart/alternative; boundary="------------XrbroFEUeTXKeUEnFtS0aYSO" Message-ID: <6aafafbd-590e-29c8-d98f-5d776ebff4bc@FreeBSD.org> Date: Mon, 20 Feb 2023 14:53:21 +0100 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 Subject: Re: Armv7 panic on -current, rpi2 buildworld Content-Language: en-US To: Andrew Turner Cc: Mark Millard , bob prohaska , "freebsd-arm@freebsd.org" References: <20230215025741.GA32086@www.zefox.net> <85ed9a05-e4ea-2811-1701-b8f2e982e3b1@FreeBSD.org> <1572483E-D0CD-4384-BF73-A00FB3640F91@fubar.geek.nz> From: =?UTF-8?Q?Kornel_Dul=c4=99ba?= In-Reply-To: <1572483E-D0CD-4384-BF73-A00FB3640F91@fubar.geek.nz> X-ThisMailContainsUnwantedMimeParts: N This is a multi-part message in MIME format. --------------XrbroFEUeTXKeUEnFtS0aYSO Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 2/20/23 14:32, Andrew Turner wrote: > > >> On 20 Feb 2023, at 13:15, Kornel Dulęba wrote: >> >>> Can you try with 24abb6b82102eec577eff9bd8dd7726e8cab89f4? There >>> were conditional branch instructions that may mean the function to >>> save the VFP state was not being run. >> >> I'm currently debugging this and applying >> 24abb6b82102eec577eff9bd8dd7726e8cab89f4 didn't quite help. >> (I've tested it with dbl_and_ull_via_async that Mark shared in >> another thread.) >> The root cause is located in vfp_save_state. It's called during the >> dump, right before the assert is triggered: >> >> 359         /* >> 360          * savectx() will be called on panic with dumppcb as an >> argument, >> 361          * dumppcb doesn't have pcb_vfpsaved set, so set it to save >> 362          * the VFP registers. >> 363          */ >> 364         if (pcb->pcb_vfpsaved == NULL) >> 365                 pcb->pcb_vfpsaved = &pcb->pcb_vfpstate; >> >> Here pcb_vfpsaved == NULL, since the VFP has never been used in the >> kernel. >> This triggers the KASSERT in get_vfpcontext, causing the panic. >> Note that arm64 has very similar logic, so I wonder if a similar >> panic could be observed there. >> Any thoughts? >> > > It looks like cpu_copy_thread is missing setting pcb_vfpsaved so is > likely to be invalid. > > On arm64 we set the needed data in vfp_new_thread. This was added to > simplify adding SVE support, but could be reused on arm if it’s useful. Thanks, that's it! With some changes in cpu_copy_thread the assert is no longer triggered. I'll do some more testing, cleanup and will post the patch to phabricator. > > Andrew > --------------XrbroFEUeTXKeUEnFtS0aYSO Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

On 2/20/23 14:32, Andrew Turner wrote:



On 20 Feb 2023, at 13:15, Kornel Dulęba <kd@FreeBSD.org> wrote:

Can you try with 24abb6b82102eec577eff9bd8dd7726e8cab89f4? There were conditional branch instructions that may mean the function to save the VFP state was not being run.

I'm currently debugging this and applying 24abb6b82102eec577eff9bd8dd7726e8cab89f4 didn't quite help.
(I've tested it with dbl_and_ull_via_async that Mark shared in another thread.)
The root cause is located in vfp_save_state. It's called during the dump, right before the assert is triggered:

359         /*
360          * savectx() will be called on panic with dumppcb as an argument,
361          * dumppcb doesn't have pcb_vfpsaved set, so set it to save
362          * the VFP registers.
363          */
364         if (pcb->pcb_vfpsaved == NULL)
365                 pcb->pcb_vfpsaved = &pcb->pcb_vfpstate;

Here pcb_vfpsaved == NULL, since the VFP has never been used in the kernel.
This triggers the KASSERT in get_vfpcontext, causing the panic.
Note that arm64 has very similar logic, so I wonder if a similar panic could be observed there.
Any thoughts?


It looks like cpu_copy_thread is missing setting pcb_vfpsaved so is likely to be invalid.

On arm64 we set the needed data in vfp_new_thread. This was added to simplify adding SVE support, but could be reused on arm if it’s useful.
Thanks, that's it!
With some changes in cpu_copy_thread the assert is no longer triggered.
I'll do some more testing, cleanup and will post the patch to phabricator.

Andrew

--------------XrbroFEUeTXKeUEnFtS0aYSO--