From nobody Mon Nov 18 11:03:29 2024 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 4XsPrF1GVlz5cj0k for ; Mon, 18 Nov 2024 11:03:41 +0000 (UTC) (envelope-from eduardo@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 "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4XsPrF0kyRz4D8d for ; Mon, 18 Nov 2024 11:03:41 +0000 (UTC) (envelope-from eduardo@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1731927821; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=2LnW6zQIhMs9AM9Y+SEcJpmVAngOeriqeduc6EkPJSw=; b=dC2c54l/LICUzE0dNTek4oAmSMJt27VCcOZMZswR+RA3ujEVtcGxPLgZl32OgacS27DUTL AT70LnUaefMw1Fveo6a8fiVB5zb2wGSJ3TTfH+WTkCNQR+DKJ9ZItzbmvMlhP3GBZtJS8m 8mM8Ui9OvQBhUEZxTMyfo39ppUhf7eg7IsCIJhUa87ktbE5okS6vGgTE8Ng+EL+XX6S1oe vjluLrdOv3fFhCRi+oPs4iospfQVE6nESxxpD1s3729646j2SKJI57MyoKZ4YBuWM5dvY1 kI52R1c6BZeycixzaA03rGlXVxMTbe2Ln503ntosOH7jhG8Ybpf1ep4s4m2HAg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1731927821; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=2LnW6zQIhMs9AM9Y+SEcJpmVAngOeriqeduc6EkPJSw=; b=twfZjx067/RochYi/ZspfBMgIWJ2t7UJj9kaH+yKr/JStou9wJ6y+Dfr/Gf+ExUvTDdAbS 64aVFhOEoJH2ULr58+cbhSjaeYPy8/5ILATgz8DNrfdebusUB9e4v1mQKXY0qc/RGtbLz0 qRD1t0/h01NqYA6Dw2/3RsS9/YCdcN3FylF7ZWrPF/L4+2kYCaeoa1+3V9Gw7vxGNeqOan kyQewJXomaa2V4hrFUmCs6Ad9s0xCSIsVgDlMBdeK6T+dD52jvvK7pDPRBRWDy/k/h7nOm nyZCGQgqZ5djW7mIdNHht4qKYqtVVsSvcPCwrAdY0nN1Zhct2DY1x31wINBMLA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1731927821; a=rsa-sha256; cv=none; b=K/s2SoFATmhCz2JYn27Qq2CllkhVh5o4TyY4MYNKp2sr25J+lmDD9EJr0MfmOoSiOGilUl Eq2KqibGPVqsLY9G/r8oXkCKciKPJ7Fn7eVF//8gvds+mAcZy1eCNft2uAFCSEn68VQr8X k2DBta7nsSEiAg8ZeNCi4vzQGJax3QAzwLA8ocFhXwScqt+m9E4ZJKO/YYd1zrcx7WWTO+ Tgdv5kWEeB1TaImRZESCBkLR1NMwtcG6Posj/h3OC1R6vk3A/WZdV41BITcgVgGN+sAQdY gScq3GIfBZOGtBs4MoqEjnPx6aVo3YHGWi7UaC/jtvhRTvIQC2DmiLXo55h3xg== Received: from mail-qv1-f54.google.com (mail-qv1-f54.google.com [209.85.219.54]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) (Authenticated sender: eduardo) by smtp.freebsd.org (Postfix) with ESMTPSA id 4XsPrF0Cn8zhwS for ; Mon, 18 Nov 2024 11:03:41 +0000 (UTC) (envelope-from eduardo@freebsd.org) Received: by mail-qv1-f54.google.com with SMTP id 6a1803df08f44-6d415a532a9so1062916d6.3 for ; Mon, 18 Nov 2024 03:03:40 -0800 (PST) X-Gm-Message-State: AOJu0YzC8Rdic9DROmc2tw6K5XcOx9ye1OtA7DO8NRX45BzocpN5nVpG /ROlnqKrUknMyKMEmimDZ4f2LNCl/GIUZYgAg/q899x76YyaBLJ1S4ixlzxjTe7pLit1sWraRq4 ZzEQaA+9uZXIbqTDFid4RGrXtTgQ= X-Google-Smtp-Source: AGHT+IHIiiLNEmKe+Sw9VClP80YhuxawJG3KUoDg9w/zl++SP0B7BkVt1n/iIw2paKf0Y+anuPMDnrnuB0CyrRH30ew= X-Received: by 2002:a05:622a:10f:b0:458:2619:45b4 with SMTP id d75a77b69052e-46363e2f732mr81858061cf.7.1731927820437; Mon, 18 Nov 2024 03:03:40 -0800 (PST) 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 From: Nuno Teixeira Date: Mon, 18 Nov 2024 11:03:29 +0000 X-Gmail-Original-Message-ID: Message-ID: Subject: rpi4 fan speed control To: FreeBSD ARM List Content-Type: multipart/alternative; boundary="000000000000839b0106272dde82" --000000000000839b0106272dde82 Content-Type: text/plain; charset="UTF-8" Hello all, My rpi4 small fan is about to die since it started to have noises. Its a small 40x10 fan attached to a plastic box. I'm thinking in something like: https://www.zdnet.com/home-and-office/the-best-cooler-for-raspberry-pi-power-users/ Anyone controlling speed fan, i.e., not using fan a full speed all the time? Thanks, -- Nuno Teixeira FreeBSD UNIX: Web: https://FreeBSD.org --000000000000839b0106272dde82 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello all,

My rpi4 small fan= is about to die since it started to have noises. Its a small 40x10 fan att= ached to a plastic box.


Anyone contro= lling speed fan, i.e., not using fan a full speed all the time?

Thanks,

--
Nuno Teixeira=
FreeBSD UNIX:=C2=A0 <eduardo@FreeBSD.org>=C2=A0 =C2=A0Web:=C2=A0 https://Fr= eeBSD.org
--000000000000839b0106272dde82-- From nobody Mon Nov 18 11:53:37 2024 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 4XsQy70SCyz5d1Zs for ; Mon, 18 Nov 2024 11:53:51 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mx.blih.net (mx.blih.net [212.83.155.74]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4XsQy633Tyz4MfP; Mon, 18 Nov 2024 11:53:50 +0000 (UTC) (envelope-from manu@bidouilliste.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bidouilliste.com; s=mx; t=1731930821; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=z65ZyNyYgpzPwFfdNBkvrnXxKzmVXffSzlo+KlmPj+s=; b=McPHK4ZJ6oGADacRiAG+38pH1h+8j4MZvSFuR8776gXj5AMBQj2Q9P3rY96DtM1eN+Sgty zWbq8grKAwvvGCzD3bG0iZgFRVjSH48E0DJUHWkt4a3BmpPDlEPyMv/83PToAuknGgDvDL IGzWWkGTfn1qzozz8tfKq/vu9eVVj4Y= Received: from skull.home.blih.net (arennes-299-1-68-49.w92-159.abo.wanadoo.fr [92.159.163.49]) by mx.blih.net (OpenSMTPD) with ESMTPSA id 1e4ea143 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Mon, 18 Nov 2024 11:53:41 +0000 (UTC) Date: Mon, 18 Nov 2024 12:53:37 +0100 From: Emmanuel Vadot To: Nuno Teixeira Cc: FreeBSD ARM List Subject: Re: rpi4 fan speed control Message-Id: <20241118125337.b54d024802f26faac8fa25c2@bidouilliste.com> In-Reply-To: References: X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd15.0) 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 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:12876, ipnet:212.83.128.0/19, country:FR] X-Rspamd-Queue-Id: 4XsQy633Tyz4MfP X-Spamd-Bar: ---- On Mon, 18 Nov 2024 11:03:29 +0000 Nuno Teixeira wrote: > Hello all, > > My rpi4 small fan is about to die since it started to have noises. Its a > small 40x10 fan attached to a plastic box. > > I'm thinking in something like: > https://www.zdnet.com/home-and-office/the-best-cooler-for-raspberry-pi-power-users/ > > Anyone controlling speed fan, i.e., not using fan a full speed all the time? > > Thanks, > > -- > Nuno Teixeira > FreeBSD UNIX: Web: https://FreeBSD.org I find the wiring a bit weird, usually you use a pwm controller to control the speed of a fan and we have support for rpi pwm (even though it's not handled by the pwm(4) framework iirc) but on the website they plug the control pin to the uart TX ??? Cheers -- Emmanuel Vadot From nobody Mon Nov 18 12:35:10 2024 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 4XsRt15TwBz5d39T for ; Mon, 18 Nov 2024 12:35:21 +0000 (UTC) (envelope-from eduardo@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 "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4XsRt14tVWz4RKp for ; Mon, 18 Nov 2024 12:35:21 +0000 (UTC) (envelope-from eduardo@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1731933321; 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=yyqmZH3yuv3b3ixU7O2sRIMrWaVtObuF83RaQuqgA/g=; b=WwEsHWMbEB33kOjvXJwlbd9skxp2H8O+5V5DSa3GyuzLgUl01DxLfGbsJRl7V2TaIozYVC VgvP9YIADIUSxDS40p2KVuGPiD6AxuoP9EBZFqcvNwp9UozLSiFy4XqDIdFfB95DB9p6Vg 6YQ+dQYPdA9FxJfd08RZitCjtXfS51WMd0vIxjbXodXq/dmeWcPcVrEKrsq45mDvxC/eqh yTb0TzSdRxmbek0EChcnyZplMHzsRJr5S0Joqyf/yVBMGLGCGSoi+6c6q2DB+EfIjfyces hxRZ8lT1UI6s48NwcL3hXSK1DMjnRgbEtZo6vhGz3y0LD9PeymkSmfEtG+4sAA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1731933321; 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=yyqmZH3yuv3b3ixU7O2sRIMrWaVtObuF83RaQuqgA/g=; b=w6i8uG80YM+UH+fWSrEBr73oDugGcSqa9VnVDojfCIij4z2JNkTFI/u8DcDLcvH75/aAsl WyPx30p2WzxnmmC4r0zbf5SMUVUFj1/Ei5ZCFPMBO6RcS8uGMO8ada2RrCkBJb2CAtLyeI yFgZEYnz2pjCT1tK1fwb9AYFRTqda+YCvB1ND4OEfD3McWG8wjiirpymeG5G6kdlie6vfz waIz+xMjwiqK7XQF5atexJYYXBV0ihhA8anDgSs8FN5y+T6bG/yj9z1Gub30Cq29iZdmrK CeQJ+VKsTBh/R615QrmUOQk9OoyA2X8dpYx6bFKudgd7HVkknfFEZ/iJYoU+ug== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1731933321; a=rsa-sha256; cv=none; b=rfThxFiXFA1gVUNUCxrnM4m1utGBEN9zdjFqIgrESZPiJWG880RFnLfw/wFqsuEaT8edYX YIUcI1S59PAeHKTkRBUwQVWTu19F2otCg81bzcTTxWBS7sVTlHk4e0F6nGibj14smnMslH +OqrF/75BzWP41Q+f9hwwQU9Ne4DUToVslzl7whp2qKBtKw1hjUiyMVpfyvbY3OkdqwmHt 1lAv/HpZ8k7nzl06pRHmGfH5lTMwDeEkYDQyLE2shHXNRCnFgbuxI8JPxngTQM5KFPVx0y lflRUqKb5EL/htLc/fddfulL+7987OTES3QiCp249odwzoT1tDUbvlMYCrlEYg== Received: from mail-qk1-f171.google.com (mail-qk1-f171.google.com [209.85.222.171]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) (Authenticated sender: eduardo) by smtp.freebsd.org (Postfix) with ESMTPSA id 4XsRt14GwKz10jS for ; Mon, 18 Nov 2024 12:35:21 +0000 (UTC) (envelope-from eduardo@freebsd.org) Received: by mail-qk1-f171.google.com with SMTP id af79cd13be357-7b15479cecaso19273485a.2 for ; Mon, 18 Nov 2024 04:35:21 -0800 (PST) X-Gm-Message-State: AOJu0Yz26BfFAZXT7wssPbZZy1KfukMmY/tUa0gsF4X2WLcD4/V4xd03 Om6n0a0PmU3PWfO3/kql+BY4Bh66inwIbYZRhOg+5hrrO22mEHBERmqZELzOFPZ7k26OWEApbVv wbzGBB531XKWnXG8rsnX0VBIjuZ4= X-Google-Smtp-Source: AGHT+IEpAcgX06oMbgeztHxD4mTgS48x3UFgZr1t5QLD4IBUz34RtuBNuNd8DDoeaGCJSvX2toRu3+I+spHYoXU9OQY= X-Received: by 2002:a05:622a:19a4:b0:460:e4e3:457 with SMTP id d75a77b69052e-46363e972acmr79874261cf.11.1731933321007; Mon, 18 Nov 2024 04:35:21 -0800 (PST) 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 References: <20241118125337.b54d024802f26faac8fa25c2@bidouilliste.com> In-Reply-To: <20241118125337.b54d024802f26faac8fa25c2@bidouilliste.com> From: Nuno Teixeira Date: Mon, 18 Nov 2024 12:35:10 +0000 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: rpi4 fan speed control To: Emmanuel Vadot Cc: FreeBSD ARM List Content-Type: multipart/alternative; boundary="0000000000005fa30206272f269c" --0000000000005fa30206272f269c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Official fan connects same way: https://youtu.be/BP44pCxQWAY?t=3D60 4 - 5v - Red 6- GND - Black 8 - GPIO- Blue While in some schmatics for rpi4 8 pin is UART0 TX... Can't get it Emmanuel Vadot escreveu (segunda, 18/11/2024 =C3=A0= (s) 11:53): > On Mon, 18 Nov 2024 11:03:29 +0000 > Nuno Teixeira wrote: > > > Hello all, > > > > My rpi4 small fan is about to die since it started to have noises. Its = a > > small 40x10 fan attached to a plastic box. > > > > I'm thinking in something like: > > > https://www.zdnet.com/home-and-office/the-best-cooler-for-raspberry-pi-po= wer-users/ > > > > Anyone controlling speed fan, i.e., not using fan a full speed all the > time? > > > > Thanks, > > > > -- > > Nuno Teixeira > > FreeBSD UNIX: Web: https://FreeBSD.org > > I find the wiring a bit weird, usually you use a pwm controller to > control the speed of a fan and we have support for rpi pwm (even though > it's not handled by the pwm(4) framework iirc) but on the website they > plug the control pin to the uart TX ??? > > Cheers > > -- > Emmanuel Vadot > --=20 Nuno Teixeira FreeBSD UNIX: Web: https://FreeBSD.org --0000000000005fa30206272f269c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Official fan connects same way:

<= div>https://youtu.be/BP44pC= xQWAY?t=3D60

4 - 5v - Red
6- GND - B= lack
8 - GPIO- Blue


While in some schmatics= for rpi4 8 pin is UART0 TX... Can't get it

Emmanuel Vadot <= ;manu@bidouilliste.com> esc= reveu (segunda, 18/11/2024 =C3=A0(s) 11:53):
On Mon, 18 Nov 2024 11:03:29 +0000
Nuno Teixeira <= eduardo@freebsd.org> wrote:

> Hello all,
>
> My rpi4 small fan is about to die since it started to have noises. Its= a
> small 40x10 fan attached to a plastic box.
>
> I'm thinking in something like:
> https://www.= zdnet.com/home-and-office/the-best-cooler-for-raspberry-pi-power-users/=
>
> Anyone controlling speed fan, i.e., not using fan a full speed all the= time?
>
> Thanks,
>
> --
> Nuno Teixeira
> FreeBSD UNIX:=C2=A0 <eduardo@FreeBSD.org>=C2=A0 =C2=A0Web:=C2=A0= https= ://FreeBSD.org

=C2=A0I find the wiring a bit weird, usually you use a pwm controller to control the speed of a fan and we have support for rpi pwm (even though
it's not handled by the pwm(4) framework iirc) but on the website they<= br> plug the control pin to the uart TX ???

=C2=A0Cheers

--
Emmanuel Vadot <manu@bidouilliste.com> <manu@freebsd.org>


--
Nuno Teixeira
=
FreeBSD UNIX:=C2=A0 <eduardo@FreeBSD.org>=C2=A0 =C2=A0Web:=C2=A0 https://Fr= eeBSD.org
--0000000000005fa30206272f269c-- From nobody Wed Nov 20 16:29:42 2024 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 4Xtmzq0Y06z5dSj2 for ; Wed, 20 Nov 2024 16:29:59 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic313-19.consmr.mail.gq1.yahoo.com (sonic313-19.consmr.mail.gq1.yahoo.com [98.137.65.82]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Xtmzn6QGLz4H9M for ; Wed, 20 Nov 2024 16:29:57 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=ECs00BiP; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.82 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1732120196; bh=X2Fvn8NAWBMFa3096q+Nnv7y1IaTP4poVEa2gSAoCLw=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From:Subject:Reply-To; b=ECs00BiPcjDMDOgEIDi00zD9mi4YSPx0DHxPhNvey9t9dNnDOgY/VenODHFbRVE8L+nQo/LnDbHZQAlZMuJai8RptkZ12K0poXZhOeT5bxwiJj/kTzFkzYO5bNn5J8C++J2pR9uUXVjgbClvOt6UZq2J9vd+s9hzNyZAqun/ist3locfiyurqOXxZt3s0jSphv6c+dA4ApHgEH/1/EuHhdItREkFgrGWSsEo0n5X/wfYC4pXLJZAMA0Q5j+TX1qzMQ9A74vLQXrNLKZFmrXpaihKaZzAGnN7flm7HRfI0kRMs04D8LCZrSs6YQ36KHXwE2AK99inQVA/VzyKMLWsmA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1732120196; bh=FEEZHTiBryz5R7poltR+MMlyIItZZfqTrEm74hbMsRX=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=ZJLTPAVC7NAHPTpgT3whQSYS/VXb+0trADciYh8iWMDGudvnRIcfStm3gGA3x4g33C7OplfdgyNzLep2O59YsoQy2pZOiRtwBIxngWM6b1wFdvD1w1PobtsYv1qeLpuqsefgkxBwVEVeQg5zCOp7aWo5oK+dOTsjZucjnV3rSIlNrnuTpyvCCOuMYZkrICWu7547hiYIpQT2LibSkuLwzhvaNzwRbzjbUqyS46ra367ofFkEeyBJ4J8RLNdnYiMgTZ/CrENomGwP163YvMbYa+laepBBhU3UOMNCz51rv8dTP3ZShiZiwJ5aXTUSS45AUsJt0AmCi5wxUWgaH5bKWw== X-YMail-OSG: GqouuHgVM1keJT5JddK7FIY8OCyZOohM1Yl6gWBK5twvfue2uEsnzER665It.DH SP6.9pYFNqZ9KuExsl9hnoMXbh5swWTy.rkaP7wX1voLURXpoKvh20GBs1La_xSnPPyDKZRQ0yx3 KzoQi1kYW_SEQ4i.4.q6oZdyu.KY8ys1GsCk3KsNA3aFFwkvwXRsSPsE9yDBtEi.n0VJmVOvN9Ve AGuuBAO3senugVvCkFgIkBZMkdzFxaZnvMmBbsXJfj.UPMWUGqIp92wJ6NInexNeG4XqsevyqOeM MCKdO98g_1DO4Dd5ZvmUUlVD17j8atnhElCOGyGHU5vx45ChaOqNjIfr.ngqagWC3r16co99axyI TunIwetNMVcSx3XxOXoGyVgiu1WzoD.YUEBwPzOoFkK6WXihZgvLFz79x63LVukGASnUgARNDbJK JqOwQxy6YB51yGaEMzcS3IQalkmdQmVPtT_mCQFkFNn4F.5wfAT3Ty0LfanrUTQdhir_Gg1dQLaL HWYU.0W0cHtKxKDzsab6xabfp46YH1miOJT2WOskAPONU1Qs72rHGngInO.hduxWkKE0NwR44uSe jfxYOm0btFk6xLDzlMBqZkBQhmftuPpbixl_uQ7K.eeG_XIZNZTeVkGetJe_7OfLIBXH9THiqQqL vnkwHZ8okgsimPQEDD0CBuUyAy.1Yvp.KaOgcxP39iMXNMx1cM5UprF1JuQGxend1Nh1jgq.26rT FTNmpygYCkRGvYUSfRF0Rt7FmFDWwGuAH9c9txQfARYK7UjTFxwHc0CArbdHfpcQ4s_W_SnepzRc mTkwykSFy_yJAbZiHFTEBuf14Jux_iVyC2bm1ngVIlQNfVHuUSlNiVDqS4daehDpIZlNUkedLB8A qyKDpG8JXCYUWd9QO__FppU.GfZflfq4icnUwl.pifKSf_1Rsq2a8362BhH0pg8.HOZuydRa46RD GQ.F0PPsUcYc6chgLW95aRjs5EacBZCpD6BfyRaCBnBvn4vNgEi35BbPtGwMVfMwpnaHHbboQdiP cNWlg_C5oFuQ7fs5gF5TU0BxJxptXxVphlR_8rOwd2VemSQadoRlg3rtGfcyF7hvsR83BsMbp_tZ QZazAkhDOPidliv8XAy4waQ9zpk9ISEIXkA5o.TO4t4VV.rBAxr_ddnVagF7R8.BFvfwL6igKAIz 3uN9xN_Lr1D.cc8fGVu67HnPwSBMBti_tFt7VZZbnz91n6q6wK_xAID5YywecedAOMfGazz2f0Fc fa01.2kKsxoSzpDonqIqaN0eo0rezH9tAnH8Li7IGBjPfLKjO2feN3uWXdpzhbfsp569XsNMhavj JRx1NzWeAmSjk0H6plb8VVrdaqMk.UOuych6iop6.it.4jmlkf2Bjzbam_xVj4DpWcDGDPFmUw7M xk4z3BCFJQwqVriRBo.3u99v0Bop45wloFMFaqtzVm9AVuvI5XZJfXZoLPaqtydJ1Tnpmks5GOyA fIYo.KqvVgoRISeMXEv8w_7czOGgYC4WbCdhT81Kb2xoDiig9IKE.A_G8OYus71XaCqQNFmPWqhe 8Sfiv5GhEwgdCobo4U7RlE8SKcD6NaV_iXpgMRptt8XmpkWgzvad2WGyavWEDNgM1fn2XzqOd_6P berigNcPCt6SP1q6mSwyI6ov0FXqnAGfWf2B1.uuqHk9lTmlGYJ4PVSQUMPrRW.mNRHzcGS3q5nX dP0BZNrDD6co3q50IewPyxMGJPtHXUAFP.bHJh1kA203LLl2BwB9ovRiA_2U3QPhq468v1xLBbYt cHQ.eHIEVk8S6KKwAgugwCrHhhglszMDt5wDiW9S5u6qTbygB1fDeJCQ.ZqpCfseD0Sbtm9L1E2x gkVFC5fLkkNpGfc2cBe.NHNMv_thIGsWKE7sY4fijOG.7qsIvGAkwHtI26rVCUyZjqr8GNVqUvmA mY6Zi4bxhi_cnKhkNtOsmB3LWUBaJb4uVVYmKL6FNkJTzr3hggR2gjUUZIjxsCoY0If55ckVQP4E f2cYtJUitfjFcgF0HgeYQA02n10YMbIGh1KdtKnQ_._IJMWXi3pj2z7zFnnRtzPWe2JqDP7TZYXW 4aBPIFdRA45tqPe0KAV2tcsZOMpv1sfor6MWNka7uYbKBHF7ZAvigcRkgQdOkRBRLH9Hh_CohL7m _OQuUQxMODhbiA_7y_CyPB9AGehjoGNyAAL97JXGsUb7c82nO3EQ._018NL8_uLhFUU08AfrFQ.m S5exQ1p89yPurp4lwayQ0Ktv8BcZeBIIPN8Bjki.w_d02jm2tzUCPC7vdMlaMqDfuOXUowjc2gsf 5tKIh4mnrhQ_KoLo- X-Sonic-MF: X-Sonic-ID: d1f0c9fb-63ca-4826-b6f9-e73f79c087a7 Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.gq1.yahoo.com with HTTP; Wed, 20 Nov 2024 16:29:56 +0000 Received: by hermes--production-gq1-5dd4b47f46-5kxd4 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 028dc3a2dcf3d6919cc9af8302f6555c; Wed, 20 Nov 2024 16:29:53 +0000 (UTC) From: Mark Millard Message-Id: <7E60FC8D-1770-444F-A4FA-953A2A2FEDB8@yahoo.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_294CD89F-DEEB-4FB5-89D5-BE573B9F8557" 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 (Mac OS X Mail 16.0 \(3776.700.51\)) Subject: Re: Should stable/1[34] and supported 1[34].*-RELEASE have -ftls-model=initial-exec fixes MFC'd and/or EC'd for armv7? Date: Wed, 20 Nov 2024 08:29:42 -0800 In-Reply-To: Cc: Jessica Clarke To: FreeBSD-STABLE Mailing List , FreeBSD ARM List References: X-Mailer: Apple Mail (2.3776.700.51) X-Spamd-Result: default: False [-2.99 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; NEURAL_HAM_SHORT(-0.99)[-0.992]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; DKIM_TRACE(0.00)[yahoo.com:+]; TO_DN_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCPT_COUNT_THREE(0.00)[3]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.82:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; APPLE_MAILER_COMMON(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.82:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] X-Rspamd-Queue-Id: 4Xtmzn6QGLz4H9M X-Spamd-Bar: -- --Apple-Mail=_294CD89F-DEEB-4FB5-89D5-BE573B9F8557 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii [Just CC'ing Jessica C. instead of kib. This is based on = https://reviews.freebsd.org/D42415 having Jessica's note: If IE is fixed then lib/libc/Makefile probably should enable it on arm = as a follow-up, which I *think* is the only architecture not covered by = that if statement, unless I'm missing something ] On Nov 17, 2024, at 10:50, Mark Millard wrote: [Not that they could be timed for 14.2-RELEASE at this point.] Given an update to the bootstrap lang/rust compiler that has already been fixed, the below fixes why lang/rust has not built on the official package build server s for 1[34].* since at least lang/rust 1.77.0 . (The traceable records do not go back beyond that. But it may be that rust became dependent at 1.77.0 for all I know.) It also blocks private armv7 lang/rust builds for stable/1[34] . Other packages may have build failures that are related but I'll use the lang/rust activity here: used as the test case. I have locally tested building lang/rust 1.82.0_1 on stable/14 both with and without the changes in question. With the 2 commits it built just fine, unlike without. (I did not try just 1 of the 2, just the pair as I unit.) The primary, recent bugzilla activity is at: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D282663 But the below avoids going through the discovery process and history that is recorded there. (There are also other related bugzilla's around but this one is where the potential MFC's were identified.) See also the fallout records for lang/rust for armv7: = https://portsfallout.com/fallout?port=3Dlang%2Frust&maintainer=3D&env=3Dar= mv7&category=3D&flavor=3D (but ignore the lang/rustpython lines that also match the pattern used). Only main got the fixes back in 2023-Nov and only main has worked for lang/rust for the official armv7 package build servers since then for any records that I've found -- lang/rust 1.77.0 and later. The 2 commits are: = https://cgit.freebsd.org/src/commit/?id=3D98fd69f0090da73d9d0451bd769d7752= 468284c6 = https://cgit.freebsd.org/src/commit/?id=3D6e5b1ff71e01bd48172483cb6df921f8= 4300ea3a I show the details below. Whitespace might not be accurately preserved = below. https://cgit.freebsd.org/src/commit/?id=3D98fd69f0090d is: author R. Christian McDonald 2023-11-03 12:56:58 +0000 committer Kristof Provost 2023-11-03 21:43:40 +0000 . . . rtld/arm: fix initial-exec (IE) thread-local storage relocation net/frr[89] revealed an interesting edge-case on arm when dynamically linking a shared library that declares more than one static TLS variable with at least one using the "initial-exec" TLS model. In the case of frr[89], this library was libfrr.so which essentially does the following: #include #include "lib.h" static __thread int *a __attribute__((tls_model("initial-exec"))); void lib_test() { static __thread int b =3D -1; printf("&a =3D %p\n", &a); printf(" a =3D %p\n", a); printf("\n"); printf("&b =3D %p\n", &b); printf(" b =3D %d\n", b); } Allocates a file scoped `static __thread` pointer with tls_model("initial-exec") and later a block scoped TLS int. Notice in the above minimal reproducer, `b =3D=3D -1`. The relocation process does the wrong thing and ends up pointing both `a` and `b` at the same place in memory. The output of the above in the broken state is: &a =3D 0x4009c018 a =3D 0xffffffff &b =3D 0x4009c018 b =3D -1 With the patch applied, the output becomes: &a =3D 0x4009c01c a =3D 0x0 &b =3D 0x4009c018 b =3D -1 Reviewed by: kib Sponsored by: Rubicon Communications, LLC ("Netgate") Differential Revision: https://reviews.freebsd.org/D42415/ Diffstat -rw-r--r-- libexec/rtld-elf/arm/reloc.c 7=09 1 files changed, 5 insertions, 2 deletions diff --git a/libexec/rtld-elf/arm/reloc.c b/libexec/rtld-elf/arm/reloc.c index c3e95940be74..6efc9f499761 100644 --- a/libexec/rtld-elf/arm/reloc.c +++ b/libexec/rtld-elf/arm/reloc.c @@ -280,10 +280,13 @@ reloc_nonplt_object(Obj_Entry *obj, const Elf_Rel = *rel, SymCache *cache, return -1; tmp =3D (Elf_Addr)def->st_value + = defobj->tlsoffset; - if (__predict_true(RELOC_ALIGNED_P(where))) + if (__predict_true(RELOC_ALIGNED_P(where))) { + tmp +=3D *where; *where =3D tmp; - else + } else { + tmp +=3D load_ptr(where); store_ptr(where, tmp); + } dbg("TLS_TPOFF32 %s in %s --> %p", obj->strtab + obj->symtab[symnum].st_name, obj->path, (void *)tmp); https://cgit.freebsd.org/src/commit/?id=3D6e5b1ff71e01 is: author R. Christian McDonald 2023-11-09 20:22:21 = +0000 committer Kristof Provost 2023-11-09 = 20:24:23 +0000 . . . Reviewed by: kib Sponsored by: Rubicon Communications, LLC ("Netgate") Differential Revision: https://reviews.freebsd.org/D42415/ libc: enable initial-exec (IE) as default thread-local storage model on = arm As suggested by jrtc27@ in https://reviews.freebsd.org/D42415, this patch enables IE as default thread-local storage model in libc on arm. Reviewed by: kib Sponsored by: Rubicon Communications, LLC ("Netgate") Differential Revision: https://reviews.freebsd.org/D42445 Diffstat -rw-r--r-- lib/libc/Makefile 4=09 1 files changed, 0 insertions, 4 deletions diff --git a/lib/libc/Makefile b/lib/libc/Makefile index 7540eb8c21ad..e817104642b8 100644 --- a/lib/libc/Makefile +++ b/lib/libc/Makefile @@ -54,11 +54,7 @@ CFLAGS+=3D${CANCELPOINTS_CFLAGS} # Use a more efficient TLS model for libc since we can reasonably assume = that # it will be loaded during program startup. -.if ${LIBC_ARCH} =3D=3D "aarch64" || ${LIBC_ARCH} =3D=3D "amd64" || \ - ${LIBC_ARCH} =3D=3D "i386" || ${LIBC_ARCH} =3D=3D "riscv" || \ - ${LIBC_ARCH:Mpowerpc*} !=3D "" CFLAGS+=3D -ftls-model=3Dinitial-exec -.endif # # Link with static libcompiler_rt.a. =3D=3D=3D Mark Millard marklmi at yahoo.com =3D=3D=3D Mark Millard marklmi at yahoo.com --Apple-Mail=_294CD89F-DEEB-4FB5-89D5-BE573B9F8557 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii [Just CC'ing = Jessica C. instead of kib. This is based on https://reviews.freebsd.org/D4= 2415
having Jessica's note:

If IE is fixed then = lib/libc/Makefile probably should enable it on arm as a follow-up, which = I *think* is the only architecture not covered by that if statement, = unless I'm missing something
]

On Nov 17, 2024, at = 10:50, Mark Millard <marklmi@yahoo.com> wrote:

[Not that they could be = timed for 14.2-RELEASE at this point.]

Given an update to the = bootstrap lang/rust compiler that has
already been fixed, the below = fixes why lang/rust has not
built on the official package build = server s for 1[34].* since
at least lang/rust 1.77.0 . (The = traceable
records do not go back beyond that. But it may be = that
rust  became dependent at 1.77.0 for all I know.) It = also
blocks private armv7 lang/rust builds for stable/1[34] = .

Other packages may have build failures that are related
but = I'll use the lang/rust activity here: used as the
test case.

I = have locally tested building lang/rust 1.82.0_1 on
stable/14 both = with and without the changes in question.
With the 2 commits it built = just fine, unlike without.
(I did not try just 1 of the 2, just the = pair as I unit.)

The primary, recent bugzilla activity is = at:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D282663
<= br>But the below avoids going through the discovery process = and
history that is recorded there. (There are also other = related
bugzilla's around but this one is where the potential = MFC's
were identified.)

See also the fallout records for = lang/rust for = armv7:

https://portsfallout.com/fallout?port=3Dlang%2Frust&main= tainer=3D&env=3Darmv7&category=3D&flavor=3D

(but = ignore the lang/rustpython lines that also match the pattern = used).


Only main got the fixes back in 2023-Nov and only main = has worked for
lang/rust for the official armv7 package build servers = since then
for any records that I've found -- lang/rust 1.77.0 and = later.


The 2 commits = are:

https://cgit.freebsd.org/src/commit/?id=3D98fd69f0090da73d9d04= 51bd769d7752468284c6

https://cgit.freebsd.org/src/commit/?id=3D6e5b= 1ff71e01bd48172483cb6df921f84300ea3a

I show the details below. = Whitespace might not be accurately preserved = below.


https://cgit.freebsd.org/src/commit/?id=3D98fd69f0090d = is:

author R. Christian McDonald <rcm@rcm.sh> 2023-11-03 = 12:56:58 +0000
committer Kristof Provost <kp@FreeBSD.org> = 2023-11-03 21:43:40 +0000
. . .

rtld/arm: fix initial-exec = (IE) thread-local storage relocation

net/frr[89] revealed an = interesting edge-case on arm when dynamically
linking a shared = library that declares more than one static TLS variable
with at least = one  using the "initial-exec" TLS model. In the case
of frr[89], = this library was libfrr.so which essentially does = the
following:

#include = <stdio.h>

#include "lib.h"

static = __thread int *a
= __attribute__((tls_model("initial-exec")));

void = lib_test()
= {
= = static __thread int b =3D -1;

printf("&a =3D %p\n", = &a);
= = printf(" a =3D %p\n", a);

printf("\n");

= printf("&b =3D %p\n", &b);
printf(" = b =3D %d\n", b);
}

Allocates a file scoped = `static __thread` pointer with
tls_model("initial-exec") and later a = block scoped TLS int. Notice in
the above minimal reproducer, `b =3D=3D= -1`. The relocation process does
the wrong thing and ends up = pointing both `a` and `b` at the same place
in memory.

The = output of the above in the broken state is:

&a =3D = 0x4009c018
= a =3D 0xffffffff

&b =3D 0x4009c018
b =3D = -1

With the patch applied, the output becomes:

&a =3D = 0x4009c01c
= a =3D 0x0

&b =3D 0x4009c018
b =3D = -1

Reviewed by: kib
Sponsored by: Rubicon Communications, LLC = ("Netgate")
Differential Revision: = https://reviews.freebsd.org/D42415/

Diffstat
-rw-r--r-- = libexec/rtld-elf/arm/reloc.c 7
1 files changed, 5 = insertions, 2 deletions
diff --git a/libexec/rtld-elf/arm/reloc.c = b/libexec/rtld-elf/arm/reloc.c
index c3e95940be74..6efc9f499761 = 100644
--- a/libexec/rtld-elf/arm/reloc.c
+++ = b/libexec/rtld-elf/arm/reloc.c
@@ -280,10 +280,13 @@ = reloc_nonplt_object(Obj_Entry *obj, const Elf_Rel *rel, SymCache = *cache,
= = = = return -1;

tmp =3D = (Elf_Addr)def->st_value + defobj->tlsoffset;
- if = (__predict_true(RELOC_ALIGNED_P(where)))
+ if = (__predict_true(RELOC_ALIGNED_P(where))) {
+ tmp +=3D = *where;
= = = = *where =3D tmp;
- else
+ } else = {
+ = = = = tmp +=3D load_ptr(where);
store_ptr(where, tmp);
+ }
= = = = dbg("TLS_TPOFF32 %s in %s --> %p",
=    obj->strtab + obj->symtab[symnum].st_name,
= = = =    obj->path, (void = *)tmp);


https://cgit.freebsd.org/src/commit/?id=3D6e5b1ff71e01 = is:

author= R. Christian McDonald <rcm@rcm.sh> = 2023-11-09 20:22:21 +0000
committer Kristof = Provost <kp@FreeBSD.org> 2023-11-09 20:24:23 +0000
. . = .

Reviewed by: kib
Sponsored by: Rubicon = Communications, LLC ("Netgate")
Differential Revision: = https://reviews.freebsd.org/D42415/

libc: enable = initial-exec (IE) as default thread-local storage model on arm

As = suggested by jrtc27@ in https://reviews.freebsd.org/D42415, = this
patch enables IE as default thread-local storage model in libc = on arm.

Reviewed by: kib
Sponsored by: Rubicon = Communications, LLC ("Netgate")
Differential Revision: = https://reviews.freebsd.org/D42445

Diffstat
-rw-r--r-- = lib/libc/Makefile 4
1 files changed, 0 = insertions, 4 deletions
diff --git a/lib/libc/Makefile = b/lib/libc/Makefile
index 7540eb8c21ad..e817104642b8 100644
--- = a/lib/libc/Makefile
+++ b/lib/libc/Makefile
@@ -54,11 +54,7 @@ = CFLAGS+=3D${CANCELPOINTS_CFLAGS}

# Use a more efficient TLS = model for libc since we can reasonably assume that
# it will be = loaded during program startup.
-.if ${LIBC_ARCH} =3D=3D "aarch64" || = ${LIBC_ARCH} =3D=3D "amd64" || \
-    ${LIBC_ARCH} =3D=3D= "i386" || ${LIBC_ARCH} =3D=3D "riscv" || \
- =    ${LIBC_ARCH:Mpowerpc*} !=3D ""
CFLAGS+=3D = -ftls-model=3Dinitial-exec
-.endif

#
# Link with static = libcompiler_rt.a.

=3D=3D=3D
Mark Millard
marklmi at = yahoo.com


=3D=3D=3D
Mark = Millard
marklmi at = yahoo.com

= --Apple-Mail=_294CD89F-DEEB-4FB5-89D5-BE573B9F8557-- From nobody Sat Nov 23 17:28:53 2024 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 4Xwf8P2W0Gz5db6d for ; Sat, 23 Nov 2024 17:28:53 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (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 "mxrelay.nyi.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Xwf8N72qZz4W7q for ; Sat, 23 Nov 2024 17:28:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1732382933; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=MIHbR3mpXXCUdLTLYGgT/qfIa7MbVCggK67fDv7rUdM=; b=u94HlndMOtM8IiPKspMzXVUJjN5cUW/cZpmaYypesyAtLNL7Op3sxd+LlT5Ly/u7irEXEj haEZwbLu/c9puNLozrfsW14Wqca6YVMs47cD5vHohOkJW2BsPcRQu45SjVlIIc8wu4D4/E v0KF3VwFFX+3Av52liqCCrN4dKUftv2oPAuTTN2MmcyImO5qbadLf1d62Xh74lHf2DLxKG CewHOstbaaGiIWQotiHPjrVqTXP55ZeGsKWdQRGM9WEzbjKghMIDCnXhDZL7M7N3aVGLKx YsMFbP8ZDaCs3FIMoyyfHfG54BIGOP5neTFiZ4CEFghkA8/RXYfElT2uMYgyjg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1732382933; a=rsa-sha256; cv=none; b=t2vwXLzSPCqgoH88TniKOrQ2PjhP8CskFU8JGVw5dVYdR7RDNIcl8SYvXnBvnoLlM+mU48 9sH1FZtyXdogiIkQQRXNDg7FkgAibOnR0X0AgjrUIV3HqxXexQM0Zt7AoJbmNKfXl6AYM5 0ThFoF8pSsoYTvLVXg00iS6UHRJLo2xhma6ytYKj8lWlHjDRxowzwMcM9gqW5a5vXsMquI dkeiMhJydObuz/puYsLx9OKt1ALOdWWZtG1WfcthZEU7pO70QhdSaDrVleGu/dcNCYe+R6 MC6VdmJjgJusX1fmUpUe1AlnOllT5tFKOXZ126uZrY3TxIiFG0Rvt4urEqOeJA== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (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 did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4Xwf8N5ycdzJRC for ; Sat, 23 Nov 2024 17:28:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 4ANHSqvp048751 for ; Sat, 23 Nov 2024 17:28:52 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 4ANHSqvh048750 for freebsd-arm@FreeBSD.org; Sat, 23 Nov 2024 17:28:52 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 282936] no longer able to boot under UTM MacOS Date: Sat, 23 Nov 2024 17:28:53 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 15.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: rdunkle@smallcatbrain.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated 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 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D282936 Bug ID: 282936 Summary: no longer able to boot under UTM MacOS Product: Base System Version: 15.0-CURRENT Hardware: arm64 OS: Any Status: New Severity: Affects Only Me Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: rdunkle@smallcatbrain.com FreeBSD-15.0-CURRENT used to boot on UTM (4.5.4) MacOS (15.1.1) Now it hangs right after the EFI information, and never boots. Tested last week and this week snapshot iso images. FreeBSD-15.0-CURRENT-arm64-aarch64-20241121-e8263ace39c8-273771-bootonly.iso The iso is OK, and boots on arm64- Orange Pi 5 Plus.=20 It was suggested to me to look at: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D282493 I did a revert on that change, then rebuilt world and kernel. I see the same hang on UTM. --=20 You are receiving this mail because: You are the assignee for the bug.=