From nobody Mon Sep 23 09:40:15 2024 X-Original-To: freebsd-hackers@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 4XByg72Z5gz511ZZ for ; Mon, 23 Sep 2024 09:41:23 +0000 (UTC) (envelope-from mail@eseipi.net) Received: from out-170.mta1.migadu.com (out-170.mta1.migadu.com [IPv6:2001:41d0:203:375::aa]) (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 4XByg620d2z4ZxS for ; Mon, 23 Sep 2024 09:41:22 +0000 (UTC) (envelope-from mail@eseipi.net) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=eseipi.net header.s=key1 header.b=yFqGlOu8; dmarc=pass (policy=quarantine) header.from=eseipi.net; spf=pass (mx1.freebsd.org: domain of mail@eseipi.net designates 2001:41d0:203:375::aa as permitted sender) smtp.mailfrom=mail@eseipi.net Date: Mon, 23 Sep 2024 09:40:15 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eseipi.net; s=key1; t=1727084474; 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=PUbQFSuCDfmyMNHtM6iMC6V9b5zi7ynIgRvb8KrXiJE=; b=yFqGlOu8tHbispkFwsiYogZLeN71Jp6p31vs+zEkM5VcO6+mOHuzva4Jg7mC9AJQzPvYm7 MGVH0aCnl7/4BJwgh85gt3HcrrX+y+0/qs6X5E7dVtcyvpbtiKsHRJchp5dp3IT0ThFCaQ kLCuGlMrNP1Eac6W3lwZu37FWxgF1IT/YZ5+ZsJzJzGozgmKhxbOVYKJb3346nGPN61FX1 AJ7Tn14mY1o3cffE7m6Vuz9DcuzX/oeClLrsHazgY1vh3tPfTRT1SgXQoQwVTe8oSFgoaY 7I89Y+JdrvRiWrR1QkhcaXsFFSjDKYXCs+icP2skAhv5kU0rYsqpGqWVru5/FA== X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Alexey Sukhoguzov To: freebsd-hackers@freebsd.org Subject: nvme(4): some non-operational power states are broken Message-ID: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Migadu-Flow: FLOW_OUT X-Spamd-Result: default: False [-3.99 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.994]; DMARC_POLICY_ALLOW(-0.50)[eseipi.net,quarantine]; R_SPF_ALLOW(-0.20)[+ip6:2001:41d0:203:375::/64]; R_DKIM_ALLOW(-0.20)[eseipi.net:s=key1]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_ONE(0.00)[1]; MISSING_XM_UA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:16276, ipnet:2001:41d0::/32, country:FR]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_COUNT_ZERO(0.00)[0]; TO_DN_NONE(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[eseipi.net:+] X-Rspamd-Queue-Id: 4XByg620d2z4ZxS X-Spamd-Bar: --- Hi, My NVMe controller is Toshiba XG5, and it has 6 power states: the first three (0-2) are normal and the last three (3-5) are NOPS. Here is 'nvmecontrol power -l nvme0' output: # Max pwr Enter Lat Exit Lat RT RL WT WL Idle Pwr Act Pwr Workloadd -- -------- --------- --------- -- -- -- -- -------- -------- -- 0: 8.0000W 0.000ms 0.000ms 0 0 0 0 0.0000W 0.0000W 0 1: 3.9000W 0.000ms 0.000ms 1 1 1 1 0.0000W 0.0000W 0 2: 2.0000W 0.000ms 0.000ms 2 2 2 2 0.0000W 0.0000W 0 3: 0.0500W* 1.500ms 1.500ms 3 3 3 3 0.0000W 0.0000W 0 4: 0.0050W* 6.000ms 14.000ms 4 4 4 4 0.0000W 0.0000W 0 5: 0.0030W* 50.000ms 80.000ms 5 5 5 5 0.0000W 0.0000W 0 The problem is that only one of the NOPS is working as expected (state 3). Another two (states 4-5) skyrocket the controller's power consumption far beyond normal (0-2) power states do, and far beyond reasonable. For example, when the controller is in state 3, my system consumes about 3-3.5 W at idle (according to acpiconf with laptop power cable unplugged), in states 0-2 - about 4 W, and in states 4-5 consumption is approaching 6 W. Thus, the NVMe becomes the hottest part of the system (>50C, still idle), and it eats up almost half of the battery alone. Linux doesn't have this issue, so it seems to be nvme(4) related. All the above data is collected on 14.1-RELEASE Live USB with no filesystem mounted. 15-CURRENT has the same problem. Any ideas what it might be? Regards, Alexey From nobody Mon Sep 23 09:47:16 2024 X-Original-To: freebsd-hackers@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 4XBypC5w9pz511rF for ; Mon, 23 Sep 2024 09:47:31 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pj1-x102c.google.com (mail-pj1-x102c.google.com [IPv6:2607:f8b0:4864:20::102c]) (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)) by mx1.freebsd.org (Postfix) with ESMTPS id 4XBypC247kz4cM9 for ; Mon, 23 Sep 2024 09:47:31 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pj1-x102c.google.com with SMTP id 98e67ed59e1d1-2d8a54f1250so2642326a91.0 for ; Mon, 23 Sep 2024 02:47:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1727084848; x=1727689648; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=WpmtajXBs42B0fUOkhSbwrIj4P6ls3o3JPonOI482xo=; b=usGwDuLBYAX3hIq0ZlHLQlR3IhAbyNvxHG1W6z6LbnQIG2Z+3jcf78qWGERb6HWolr bjFlEn1tdcoFytjqRd+VXtKacRsdhxPY8rYy1sgdPoSp7rfCE8DHFY6dcU8dGg5O+xyx Ktyl/CaMAgjF3ZZXAM/PTrbMVTm4JjYuD9APngzMn5VbfiTaQjk04hywc2etfgABNH0l RDE7hwWX9pB3cphLHHpfgqqnA3mbJB08p/1TAwRNrmMWo8MALuja0RMXIQ1tktsQrvLn GGtRSvabfYzh+020G075BAFf0vVONl1vvMn8xY1x/T3qwOFPU0R+WMx1byFN9hvj7/67 jbAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727084848; x=1727689648; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=WpmtajXBs42B0fUOkhSbwrIj4P6ls3o3JPonOI482xo=; b=AIKBHc+MmeR9wLzdLFHjKM1Pjx1nIV1upIwmnWw8OsD+Wbl2vH4L5UDyZYJjNv4sBo m4huplgBqiBSJ6iBw1zbpMROzWmyh/q8vrbgq0l3gcOAr9hImcCkIhcct6gcdUvEgvqV DrgqajeTEv9EmrZ9B0n43nwQTbaPd3B+9WW5zphyAHYsFm+VTjB6dDoP9BEMqL9KHfdm hNUBQ4GCQMyPhbWEm8xRd4fe/BoMcGQKTSf8bphb0A8Q+WFkctqMPx3kd3jSfW1Q9Bdr PwsalK9E4/lSf1kJjiV+YXsdm087fpGFnx/drfO+J8t+bwYnVszhzyKWA9jV5uYQIhxc fu5g== X-Gm-Message-State: AOJu0YxRbzxxnVqeF85OYxPOJyYgAyhO2ydzjb2ZO+48hfhnSz9kjgpi 2vou+UtTVP5nuFhd3INCFwjngQI6lLczgdiT/sxeCqFEUTfoG8mXWpjPzeyL31bvjmrcLtgPB6j rYHFcncO963Sju6XG/O9zVwO71DtncN3k8QDQTjNdYTo0QCUEZ7M= X-Google-Smtp-Source: AGHT+IGTmLQinRwGBP8Sn5jAHKyNXihFKGIC1v9gimzG/URW8DugXMfBMkqa+YmkyODEtmoBLOpU/h3poa+14Q+0sCc= X-Received: by 2002:a17:90a:b316:b0:2d3:ba42:775c with SMTP id 98e67ed59e1d1-2dd80bfd635mr12868480a91.1.1727084848007; Mon, 23 Sep 2024 02:47:28 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Mon, 23 Sep 2024 10:47:16 +0100 Message-ID: Subject: Re: nvme(4): some non-operational power states are broken To: Alexey Sukhoguzov Cc: FreeBSD Hackers Content-Type: multipart/alternative; boundary="000000000000dce7450622c6464f" X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4XBypC247kz4cM9 X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated --000000000000dce7450622c6464f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Sep 23, 2024, 10:41=E2=80=AFAM Alexey Sukhoguzov = wrote: > Hi, > > My NVMe controller is Toshiba XG5, and it has 6 power states: the > first three (0-2) are normal and the last three (3-5) are NOPS. > Here is 'nvmecontrol power -l nvme0' output: > > # Max pwr Enter Lat Exit Lat RT RL WT WL Idle Pwr Act Pwr Workloadd > -- -------- --------- --------- -- -- -- -- -------- -------- -- > 0: 8.0000W 0.000ms 0.000ms 0 0 0 0 0.0000W 0.0000W 0 > 1: 3.9000W 0.000ms 0.000ms 1 1 1 1 0.0000W 0.0000W 0 > 2: 2.0000W 0.000ms 0.000ms 2 2 2 2 0.0000W 0.0000W 0 > 3: 0.0500W* 1.500ms 1.500ms 3 3 3 3 0.0000W 0.0000W 0 > 4: 0.0050W* 6.000ms 14.000ms 4 4 4 4 0.0000W 0.0000W 0 > 5: 0.0030W* 50.000ms 80.000ms 5 5 5 5 0.0000W 0.0000W 0 > > The problem is that only one of the NOPS is working as expected > (state 3). Another two (states 4-5) skyrocket the controller's power > consumption far beyond normal (0-2) power states do, and far beyond > reasonable. For example, when the controller is in state 3, my > system consumes about 3-3.5 W at idle (according to acpiconf with > laptop power cable unplugged), in states 0-2 - about 4 W, and in > states 4-5 consumption is approaching 6 W. Thus, the NVMe becomes > the hottest part of the system (>50C, still idle), and it eats up > almost half of the battery alone. > > Linux doesn't have this issue, so it seems to be nvme(4) related. > All the above data is collected on 14.1-RELEASE Live USB with no > filesystem mounted. 15-CURRENT has the same problem. > > Any ideas what it might be? > Does Linux have active power state management? Warner > Regards, > Alexey > > --000000000000dce7450622c6464f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Sep 23, 2024, 10:41=E2=80=AFAM Alexey Sukhoguz= ov <mail@eseipi.net> wrote:
Hi,

My NVMe controller is Toshiba XG5, and it has 6 power states: the
first three (0-2) are normal and the last three (3-5) are NOPS.
Here is 'nvmecontrol power -l nvme0' output:

=C2=A0#=C2=A0 =C2=A0Max pwr=C2=A0 Enter Lat=C2=A0 Exit Lat RT RL WT WL Idle= Pwr=C2=A0 Act Pwr Workloadd
--=C2=A0 --------=C2=A0 --------- --------- -- -- -- -- -------- -------- -= -
=C2=A00:=C2=A0 8.0000W=C2=A0 =C2=A0 0.000ms=C2=A0 =C2=A00.000ms=C2=A0 0=C2= =A0 0=C2=A0 0=C2=A0 0=C2=A0 0.0000W=C2=A0 0.0000W 0
=C2=A01:=C2=A0 3.9000W=C2=A0 =C2=A0 0.000ms=C2=A0 =C2=A00.000ms=C2=A0 1=C2= =A0 1=C2=A0 1=C2=A0 1=C2=A0 0.0000W=C2=A0 0.0000W 0
=C2=A02:=C2=A0 2.0000W=C2=A0 =C2=A0 0.000ms=C2=A0 =C2=A00.000ms=C2=A0 2=C2= =A0 2=C2=A0 2=C2=A0 2=C2=A0 0.0000W=C2=A0 0.0000W 0
=C2=A03:=C2=A0 0.0500W*=C2=A0 =C2=A01.500ms=C2=A0 =C2=A01.500ms=C2=A0 3=C2= =A0 3=C2=A0 3=C2=A0 3=C2=A0 0.0000W=C2=A0 0.0000W 0
=C2=A04:=C2=A0 0.0050W*=C2=A0 =C2=A06.000ms=C2=A0 14.000ms=C2=A0 4=C2=A0 4= =C2=A0 4=C2=A0 4=C2=A0 0.0000W=C2=A0 0.0000W 0
=C2=A05:=C2=A0 0.0030W*=C2=A0 50.000ms=C2=A0 80.000ms=C2=A0 5=C2=A0 5=C2=A0= 5=C2=A0 5=C2=A0 0.0000W=C2=A0 0.0000W 0

The problem is that only one of the NOPS is working as expected
(state 3). Another two (states 4-5) skyrocket the controller's power consumption far beyond normal (0-2) power states do, and far beyond
reasonable. For example, when the controller is in state 3, my
system consumes about 3-3.5 W at idle (according to acpiconf with
laptop power cable unplugged), in states 0-2 - about 4 W, and in
states 4-5 consumption is approaching 6 W. Thus, the NVMe becomes
the hottest part of the system (>50C, still idle), and it eats up
almost half of the battery alone.

Linux doesn't have this issue, so it seems to be nvme(4) related.
All the above data is collected on 14.1-RELEASE Live USB with no
filesystem mounted. 15-CURRENT has the same problem.

Any ideas what it might be?
<= br>
Does Linux have active power state management?

Warner


Regards,
Alexey

--000000000000dce7450622c6464f-- From nobody Mon Sep 23 10:10:15 2024 X-Original-To: freebsd-hackers@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 4XBzJj194Wz513YS for ; Mon, 23 Sep 2024 10:10:29 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pj1-x1031.google.com (mail-pj1-x1031.google.com [IPv6:2607:f8b0:4864:20::1031]) (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)) by mx1.freebsd.org (Postfix) with ESMTPS id 4XBzJh0gcsz4gQw for ; Mon, 23 Sep 2024 10:10:28 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20230601.gappssmtp.com header.s=20230601 header.b=OKALkh7W; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::1031) smtp.mailfrom=wlosh@bsdimp.com Received: by mail-pj1-x1031.google.com with SMTP id 98e67ed59e1d1-2d889ba25f7so2797935a91.0 for ; Mon, 23 Sep 2024 03:10:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1727086227; x=1727691027; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=qNrauph181jYJvdtVJyt+3CUv315V+fM7Gtdo57QzHY=; b=OKALkh7WLSv1i7R5oIOUj2MnZvpoqgUnrjy4gwPMcqu4tb/Krg8dTfW2CVvnmBE7RS DzhZn+AtL4b6f+Bmt/HWazOUgRqATOy0HoTI43TfpVMfuW23TdU2ymc/TQb1OWdSiG1I QotaQ7rfo70JHCeoXV1Gh2UgaATG13z32owUOZcwFz6UdwwEDlygmLdflcytT/9v5RlA P0hJP2RVMgZxIiGuGjTVG9uL7b1qG2RDRIln39l3bpQQLDFrGJVWxzoRYBauEfxpPxUR abehE4B+bFzTZtCxds9LIjfT6vibUWbxq58cFi+y2R+sQasbNqGeI1mRzYbYzaKTTWzF XFpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727086227; x=1727691027; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=qNrauph181jYJvdtVJyt+3CUv315V+fM7Gtdo57QzHY=; b=LCW6ZO+vLtfk67wUa/I9O9sixml/xVjohG+vbNTznkL77av83PKmAZgaBzRnx0Cma4 OmkyvgeqDuJZUb+JyfmGH8SoXOIRNSjMECxD+I6gfsKY3QPSfxubgoUs8ZW+LctO4tph d4yfu/RjFzTNZA6NGxcprxU+U9of/e24Hox0IE+4+Wx38TDJX+0Px2NXW8c8QBFB/u9C hDfcRT+WzVWD0p6MpsUNsmytxMiqruLFwi+gkKKNH/qDYJBF7nFaRFkja+eRudTuhpUk tCWTtw8oZX5bHa7flDp74oibn0gJxMGtOmzZiSGxWpgRJpl4FnaH8RzFNyLk7+zf0NhD 4xfw== X-Gm-Message-State: AOJu0YxbAme8xGqMnOvnSoX5NkJeFFCWxdkKZGrlWbZY15tJKl+QzPnN Vv9B587Mu3cxVpSK/oNKhTTM2tDFm281i9BJe9FVNppLZNysKjlDq965Yxc3OaYP61OKqJpBqwo Sdv9xZKVUzHOyEjgEeUZa0f5XQl+P29sCLzxb6Q== X-Google-Smtp-Source: AGHT+IH0+hPeu/NVHpd7WElk8WeodH1rY7t6Qs9C5/tBPwbusCvjKJ6q8k551CBfmscf97I5DH6TUxv5ZkFpFffO1H8= X-Received: by 2002:a17:90b:2242:b0:2d8:9253:dffc with SMTP id 98e67ed59e1d1-2dd7f406557mr14696370a91.19.1727086226812; Mon, 23 Sep 2024 03:10:26 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Mon, 23 Sep 2024 11:10:15 +0100 Message-ID: Subject: Re: nvme(4): some non-operational power states are broken To: Alexey Sukhoguzov Cc: FreeBSD Hackers Content-Type: multipart/alternative; boundary="0000000000000bcc730622c699f5" X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.996]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20230601.gappssmtp.com:s=20230601]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; MISSING_XM_UA(0.00)[]; R_SPF_NA(0.00)[no SPF record]; DMARC_NA(0.00)[bsdimp.com]; RCPT_COUNT_TWO(0.00)[2]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; FROM_HAS_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::1031:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; DKIM_TRACE(0.00)[bsdimp-com.20230601.gappssmtp.com:+] X-Rspamd-Queue-Id: 4XBzJh0gcsz4gQw X-Spamd-Bar: -- --0000000000000bcc730622c699f5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Sep 23, 2024, 10:47=E2=80=AFAM Warner Losh wrote: > > > On Mon, Sep 23, 2024, 10:41=E2=80=AFAM Alexey Sukhoguzov wrote: > >> Hi, >> >> My NVMe controller is Toshiba XG5, and it has 6 power states: the >> first three (0-2) are normal and the last three (3-5) are NOPS. >> Here is 'nvmecontrol power -l nvme0' output: >> >> # Max pwr Enter Lat Exit Lat RT RL WT WL Idle Pwr Act Pwr Workload= d >> -- -------- --------- --------- -- -- -- -- -------- -------- -- >> 0: 8.0000W 0.000ms 0.000ms 0 0 0 0 0.0000W 0.0000W 0 >> 1: 3.9000W 0.000ms 0.000ms 1 1 1 1 0.0000W 0.0000W 0 >> 2: 2.0000W 0.000ms 0.000ms 2 2 2 2 0.0000W 0.0000W 0 >> 3: 0.0500W* 1.500ms 1.500ms 3 3 3 3 0.0000W 0.0000W 0 >> 4: 0.0050W* 6.000ms 14.000ms 4 4 4 4 0.0000W 0.0000W 0 >> 5: 0.0030W* 50.000ms 80.000ms 5 5 5 5 0.0000W 0.0000W 0 >> >> The problem is that only one of the NOPS is working as expected >> (state 3). Another two (states 4-5) skyrocket the controller's power >> consumption far beyond normal (0-2) power states do, and far beyond >> reasonable. For example, when the controller is in state 3, my >> system consumes about 3-3.5 W at idle (according to acpiconf with >> laptop power cable unplugged), in states 0-2 - about 4 W, and in >> states 4-5 consumption is approaching 6 W. Thus, the NVMe becomes >> the hottest part of the system (>50C, still idle), and it eats up >> almost half of the battery alone. >> >> Linux doesn't have this issue, so it seems to be nvme(4) related. >> All the above data is collected on 14.1-RELEASE Live USB with no >> filesystem mounted. 15-CURRENT has the same problem. >> >> Any ideas what it might be? >> > > Does Linux have active power state management? > And what's the workload? What performance are you seeing? And what's the reported model number? What form factor? I have an m.2 XG5 hanging around. We used these at work years ago, but in only one hw spin. We measured no power diffs btn the states in the system with our streaming workload. They also had a higher latency more quickly than other vendors, but not enough to matter so far (the machines they were in are nearing EOL) and it was only during high write loads iirc. I never looked at the temperature since they never got above our limits. Warner > Warner > > >> Regards, >> Alexey >> >> --0000000000000bcc730622c699f5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Sep 23, 2024, 10:47=E2=80=AFAM Warner Losh <= ;imp@bsdimp.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">


On Mon, Sep 23, 2024, 10= :41=E2=80=AFAM Alexey Sukhoguzov <mail@eseipi.net> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">Hi,

My NVMe controller is Toshiba XG5, and it has 6 power states: the
first three (0-2) are normal and the last three (3-5) are NOPS.
Here is 'nvmecontrol power -l nvme0' output:

=C2=A0#=C2=A0 =C2=A0Max pwr=C2=A0 Enter Lat=C2=A0 Exit Lat RT RL WT WL Idle= Pwr=C2=A0 Act Pwr Workloadd
--=C2=A0 --------=C2=A0 --------- --------- -- -- -- -- -------- -------- -= -
=C2=A00:=C2=A0 8.0000W=C2=A0 =C2=A0 0.000ms=C2=A0 =C2=A00.000ms=C2=A0 0=C2= =A0 0=C2=A0 0=C2=A0 0=C2=A0 0.0000W=C2=A0 0.0000W 0
=C2=A01:=C2=A0 3.9000W=C2=A0 =C2=A0 0.000ms=C2=A0 =C2=A00.000ms=C2=A0 1=C2= =A0 1=C2=A0 1=C2=A0 1=C2=A0 0.0000W=C2=A0 0.0000W 0
=C2=A02:=C2=A0 2.0000W=C2=A0 =C2=A0 0.000ms=C2=A0 =C2=A00.000ms=C2=A0 2=C2= =A0 2=C2=A0 2=C2=A0 2=C2=A0 0.0000W=C2=A0 0.0000W 0
=C2=A03:=C2=A0 0.0500W*=C2=A0 =C2=A01.500ms=C2=A0 =C2=A01.500ms=C2=A0 3=C2= =A0 3=C2=A0 3=C2=A0 3=C2=A0 0.0000W=C2=A0 0.0000W 0
=C2=A04:=C2=A0 0.0050W*=C2=A0 =C2=A06.000ms=C2=A0 14.000ms=C2=A0 4=C2=A0 4= =C2=A0 4=C2=A0 4=C2=A0 0.0000W=C2=A0 0.0000W 0
=C2=A05:=C2=A0 0.0030W*=C2=A0 50.000ms=C2=A0 80.000ms=C2=A0 5=C2=A0 5=C2=A0= 5=C2=A0 5=C2=A0 0.0000W=C2=A0 0.0000W 0

The problem is that only one of the NOPS is working as expected
(state 3). Another two (states 4-5) skyrocket the controller's power consumption far beyond normal (0-2) power states do, and far beyond
reasonable. For example, when the controller is in state 3, my
system consumes about 3-3.5 W at idle (according to acpiconf with
laptop power cable unplugged), in states 0-2 - about 4 W, and in
states 4-5 consumption is approaching 6 W. Thus, the NVMe becomes
the hottest part of the system (>50C, still idle), and it eats up
almost half of the battery alone.

Linux doesn't have this issue, so it seems to be nvme(4) related.
All the above data is collected on 14.1-RELEASE Live USB with no
filesystem mounted. 15-CURRENT has the same problem.

Any ideas what it might be?
<= br>
Does Linux have active power state management?

And what's the workload? What performance are you seeing? And wha= t's the reported model number? What form factor? I have an m.2 XG5 hang= ing around. We used these at work years ago, but in only one hw spin. We me= asured no power diffs btn the states in the system with our streaming workl= oad. They also had a higher latency more quickly than other vendors, but no= t enough to matter so far (the machines they were in are nearing EOL) and i= t was only during high write loads iirc. I never looked at the temperature = since they never got above our limits.

Warner

<= div dir=3D"auto">
Warner
=

Regards,
Alexey

--0000000000000bcc730622c699f5-- From nobody Mon Sep 23 12:42:47 2024 X-Original-To: freebsd-hackers@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 4XC2hf08X7z52DhR for ; Mon, 23 Sep 2024 12:42:58 +0000 (UTC) (envelope-from mail@eseipi.net) Received: from out-170.mta1.migadu.com (out-170.mta1.migadu.com [95.215.58.170]) (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 4XC2hc5y47z4vd0 for ; Mon, 23 Sep 2024 12:42:56 +0000 (UTC) (envelope-from mail@eseipi.net) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=eseipi.net header.s=key1 header.b=AqKW3LNO; dmarc=pass (policy=quarantine) header.from=eseipi.net; spf=pass (mx1.freebsd.org: domain of mail@eseipi.net designates 95.215.58.170 as permitted sender) smtp.mailfrom=mail@eseipi.net Date: Mon, 23 Sep 2024 12:42:47 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eseipi.net; s=key1; t=1727095374; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Pi3i2660lCIWf3gsWSrhQJnvf21jlC5kzf0ohoXeICg=; b=AqKW3LNOru+sVMeOs1DDbKHr61R6hmsXQwfD/7weF6i5k+pnjy1zTG+l215Lw461hVHmDh ps9Gw3ZFGQZ9uPXEZBFIg/qtJOkykO8mYX9PrhpC1/zr8Frq/v4dZajsjCwlbpgfOPqwhl BXwGnkQaAvBXSKdUBk5J51TaYJ5ozVFPjgMGglxVb0NfHEtmu+3BgfT++FC5RDgVZ2oCCm aOiAjcUiWDblxwN9q3xq8Lo1aM8K2JGB6QxJAkhJrKCgey5ZKf7Xdmwv+RcnKJFMLCxslH 7SFx3Oud6AinICWmBy//1zsjVvlsA8Cm8N1voBxULq7g6DdwEcaGnqe48BoasA== X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Alexey Sukhoguzov To: freebsd-hackers@freebsd.org Subject: Re: nvme(4): some non-operational power states are broken Message-ID: References: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Migadu-Flow: FLOW_OUT X-Spamd-Result: default: False [-4.10 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[eseipi.net,quarantine]; R_DKIM_ALLOW(-0.20)[eseipi.net:s=key1]; R_SPF_ALLOW(-0.20)[+ip4:95.215.58.0/24]; RCVD_IN_DNSWL_LOW(-0.10)[95.215.58.170:from]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:202172, ipnet:95.215.58.0/24, country:CH]; MIME_TRACE(0.00)[0:+]; MISSING_XM_UA(0.00)[]; RCVD_COUNT_ZERO(0.00)[0]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; DKIM_TRACE(0.00)[eseipi.net:+] X-Rspamd-Queue-Id: 4XC2hc5y47z4vd0 X-Spamd-Bar: ---- On Mon, Sep 23, 2024 at 11:10:15AM +0100, Warner Losh wrote: > Does Linux have active power state management? I didn't know there was such a thing, thanks! I tried to boot with 'pcie_aspm=off' kernel parameter and dmesg said that ASPM was disabled, but I didn't see any difference in terms of temperature or /sys/class/power_supply/BAT0/power_now value, they all are within normal boundaries. > And what's the workload? This machine is my workstation, so I would say there is almost no workload in terms of IO. > What performance are you seeing? I have no other issues with the device, except for power consumption in states 4 and 5. After enabling APST (I patched the kernel for this) and limiting idle transitions to state 3 this problem was mostly resolved as well, but I think it would still be worth finding out what is actually going on. > And what's the reported model number? What form factor? Model number is KXG5AZNV256G, form factor is M.2 2280. If necessary, I can send Identify command output. > We used these at work years ago, but in only one hw spin. For production machines idle power consumption may not be relevant at all, but for a laptop it's a huge difference. And that's a good news if it's just my faulty device and no one else is having the same problem. No additional work is needed then, which is always great :) From nobody Mon Sep 23 16:21:22 2024 X-Original-To: freebsd-hackers@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 4XC7Xx5MN8z5WBTb for ; Mon, 23 Sep 2024 16:21:37 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-ua1-f42.google.com (mail-ua1-f42.google.com [209.85.222.42]) (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)) by mx1.freebsd.org (Postfix) with ESMTPS id 4XC7Xw2wn6z4LSj for ; Mon, 23 Sep 2024 16:21:36 +0000 (UTC) (envelope-from asomers@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=freebsd.org (policy=none); spf=pass (mx1.freebsd.org: domain of asomers@gmail.com designates 209.85.222.42 as permitted sender) smtp.mailfrom=asomers@gmail.com Received: by mail-ua1-f42.google.com with SMTP id a1e0cc1a2514c-846be74b299so1195477241.3 for ; Mon, 23 Sep 2024 09:21:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727108495; x=1727713295; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=osWDmjUiwWBh76ksVzMw6KEQtRJjf35tzkpb2egAWfY=; b=UyiH4DFjU2JGNE9tguY40WjaYWHnblHbg5Fg/VYIL3vHpw7VlZDOny1l/BKWhWfX7i OWL4D8v4Dgdaty3DNWeq6UPmHVLUJr3FIXar99f0f/KfExdfuc6l1YJS420oEHdWkGnG hP9D6fFh1jWCZLMEsICa+zpaDWABLqx4uslgg6/CIIU2mVizzKKQb26tIV/rIaqx4ENM MbD5I1ab2dIk25Gpp10C+26pahqRuxBo+QHvJBRsiJVAb8yyQj4bkeQSeeHdDJdAHFpF ChU8+jZR2f37a9Hzh69uajv7e+C1i8aCd/ZfRi6Mq84CiyfXPB/q++OexkBtKCwf+fXu jVdg== X-Gm-Message-State: AOJu0YyYYSIMpJVIiQCWtu75C0TEPStcK+mvlnRwEq/32lwevlCLPK5N zFZPbE6rFJ8nhuXxGD25NXG/1QrgX0L8qee7kM5LcdaVoD6iY9lmxKMrT1fh0u4AJGg6tXpBP5H TPd2nzD8p4D/pQdnr7n/SBY+4ZufWeA== X-Google-Smtp-Source: AGHT+IHWV1rxx8+ZZcSbsfbe6+660wgRghm7dTxgFhqU887cjXvnJ28akY3ECohtcoAcgMn24/b7Nrb4xqlLBuCk2FM= X-Received: by 2002:a05:6122:2a41:b0:501:2842:428a with SMTP id 71dfb90a1353d-503e04d917cmr9300475e0c.8.1727108494624; Mon, 23 Sep 2024 09:21:34 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 From: Alan Somers Date: Mon, 23 Sep 2024 10:21:22 -0600 Message-ID: Subject: Help wanted with armv7 and powerpc To: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Spamd-Result: default: False [2.35 / 15.00]; NEURAL_SPAM_MEDIUM(0.92)[0.917]; NEURAL_SPAM_LONG(0.69)[0.691]; NEURAL_SPAM_SHORT(0.64)[0.640]; FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; MIME_GOOD(-0.10)[text/plain]; DMARC_POLICY_SOFTFAIL(0.10)[freebsd.org : SPF not aligned (relaxed), No valid DKIM,none]; TO_DN_ALL(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; MISSING_XM_UA(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com]; RCVD_IN_DNSWL_NONE(0.00)[209.85.222.42:from]; R_DKIM_NA(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.222.42:from]; TO_DOM_EQ_FROM_DOM(0.00)[]; FREEFALL_USER(0.00)[asomers]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_HAS_DN(0.00)[] X-Rspamd-Queue-Id: 4XC7Xw2wn6z4LSj X-Spamd-Bar: ++ I need to test some code on a 32-bit FreeBSD system that isn't i386. Would anybody be willing to lend me access to such a system? I don't need root access. I just need lang/rust installed. devel/git would help too, but I can make do without. I'm not ready yet, but I probably will be by the end of the day. From nobody Tue Sep 24 00:00:39 2024 X-Original-To: freebsd-hackers@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 4XCKkb61GLz5WjlR; Tue, 24 Sep 2024 00:00:39 +0000 (UTC) (envelope-from salvadore@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (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 "freefall.freebsd.org", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4XCKkb5HFvz41sk; Tue, 24 Sep 2024 00:00:39 +0000 (UTC) (envelope-from salvadore@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1727136039; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc; bh=DEAticYWSpDMCy6Gf/wNbVxud+L0bKovl3lBkTu6fHk=; b=MNgR/zgTrIjdBVF4Vy8vVFO/VjAh9Akxf00qGsgJkNSWn3cgtpn60t1h07eX6SV/t1t6fA KGbxBLrhq1WDp4iM/08NflLjXVO7Ymug8DsCfADg113+Lfqeio1cvau1tPZL2yVTA70u3p 9+fMYSMiMVtCIXvJLnvtulWvxNoLIxsj7+RU2y5va2twGl+2yxgwj/aj1T6RuWNJZFy8iy YL/3G1fRPR8kaDUU278iplycsc1R40VWjthZ/VHYuexT69H6CIZaY6gl3Wmcl243IqEBTg u4VKeh9f9iceTyAXI5LBzus+8ObL3pn66fRqkHCovUc8oylTO78qzTvbI2UWpQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1727136039; a=rsa-sha256; cv=none; b=MkdqRznpQQ+FMFqSrAclk7K/vuI2gIOiNj/gWl5P1bR8EY2FrjONzCNU8c2AgWBZQHPAWY pxeG7ng47s6DmreE1rn8c2bFAbGBjdttNPv/8UjuK5Yl/8POSQurUYnjnLYCsf+MZsaiUC EeKQHN7D1iPI9a5jZNZtxEi6Ix0qa0XD0amS3oet8qhovPTFpa66gu5TNB7N8WLRmdqn6J rK8Fwm6fmRMePhfnbljRbXcaBRf5gn7qrtjqGjlEZNPnAwkMXwUsXYD3LOKxcJlPeianqB 70WPvhJzZoK6382A3fTpbBbHjG4zu3fOSD/bNWY/V3oymKtPo5EDkI1ppK6IIw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1727136039; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc; bh=DEAticYWSpDMCy6Gf/wNbVxud+L0bKovl3lBkTu6fHk=; b=egn4ANG+aKN7o++9KFeSpDOvoVYqZrnt9u7kVm3tY+vWv4xnoVp8uKC0Qhho2hyaHROkus gj6Iw2tZrkAgRR1BoShcyRNH369X5TccbK7kIaANnPJ5SLKqSL8zK4gdbPsJ6gfLhSdAxM pykCoX2eiEQShXy8A1mTdkY44/EvncY3t53ScKOyDD2EUyYQh8v4zndhoiHyR5xrIlQPfL 3DZ4wCP/oRyTAz4olNI2SSB8IBLuEpUxV1LbOKROlSBUQK3gDh5ZsZ6e+T20Bn+bXunIzY hHFUzZIG0Pj7w8fSEHeXFuwUejilAVW+Jp/UvXIlqBxXlu3G4Ooj5i4THOw1Fw== Received: by freefall.freebsd.org (Postfix, from userid 1472) id 9EB438559; Tue, 24 Sep 2024 00:00:39 +0000 (UTC) To: freebsd-status-calls@FreeBSD.org Subject: [LAST OFFICIAL REMINDER] Call for 2024Q3 status reports Cc: freebsd-current@FreeBSD.org,freebsd-hackers@FreeBSD.org,devsummit@FreeBSD.org,soc-students@FreeBSD.org,soc-mentors@FreeBSD.org Message-Id: <20240924000039.9EB438559@freefall.freebsd.org> Date: Tue, 24 Sep 2024 00:00:39 +0000 (UTC) From: Lorenzo Salvadore List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org Dear FreeBSD Community, The deadline for the next FreeBSD Status Report update is September, 30th 2024 for work done since the last round of quarterly reports: July 2024 - September 2024. I would like to remind you that reports are published on a quarterly basis and are usually collected during the last month of each quarter, You are also welcome to submit them even earlier if you want, and the earlier you submit them, the more time we have for reviewing. Status report submissions do not need to be very long. They may be about anything happening in the FreeBSD project and community, and they provide a great way to inform FreeBSD users and developers about work that is underway or has been completed. Report submissions are not limited to committers; anyone doing anything interesting and FreeBSD related can -- and should -- write one! The following methods are available to submit your reports: * submit a review on Phabricator and add the group "status" to the reviewers list. You should put your reports in the directory doc/website/content/en/status/report-2024-07-2024-09/ (create it if it is missing); * submit a pull request at . You should put your reports in the directory doc/website/content/en/status/report-2024-07-2024-09/ (create it if it is missing); * send an email to status-submissions@FreeBSD.org including your report. An AsciiDoc template is available at . We look forward to seeing your 2024Q3 reports! Thanks, Lorenzo Salvadore (on behalf of status@) From nobody Tue Sep 24 11:08:36 2024 X-Original-To: freebsd-hackers@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 4XCcYX4347z5XfVT for ; Tue, 24 Sep 2024 11:08:48 +0000 (UTC) (envelope-from developer@lorenzosalvadore.it) Received: from mail-4022.proton.ch (mail-4022.proton.ch [185.70.40.22]) (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 "protonmail.com", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4XCcYT58vcz54dR for ; Tue, 24 Sep 2024 11:08:45 +0000 (UTC) (envelope-from developer@lorenzosalvadore.it) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=lorenzosalvadore.it header.s=protonmail2 header.b=MhpOFDlx; dmarc=pass (policy=quarantine) header.from=lorenzosalvadore.it; spf=pass (mx1.freebsd.org: domain of developer@lorenzosalvadore.it designates 185.70.40.22 as permitted sender) smtp.mailfrom=developer@lorenzosalvadore.it DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lorenzosalvadore.it; s=protonmail2; t=1727176120; x=1727435320; bh=zFXELPYJGEpLDQk6hvfM3JmZq103aCwZD0jTnpQPU7Y=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=MhpOFDlx5+aP7eDiR2KDu9DMhRqKCAUNHGXObo0sxGdHALBjHwcLE4pxsL9iQaFqD Mgnzwr1ld6nc74W/pRsBC63lI+HJuC11zf5WtzfMy4GiE6F/yW9ODO4uuUygDuwF3y gF8CXw/8DawRnxMlFEdcfHZTm5s+8XqaAGqmeApj8Qs1PMTETp5Eg9dEBndxWS77nQ MTrC9g2j3dQOQ0UvhdKWh46TR7LZV4y03CQbp+cLZoSPJGNa9O+oTZb754LquqAK6H elknIuBKSGU8VVKamJwLAGPuyAXHuIJSAlmt3LOdm9E1/mUG5trFnLUgbTNAKVBxs9 HO0XxgP/W3f5A== Date: Tue, 24 Sep 2024 11:08:36 +0000 To: Alex Arslan From: Lorenzo Salvadore Cc: FreeBSD Hackers Subject: Re: Wrong OSABI for GCC from Ports Message-ID: In-Reply-To: References: Feedback-ID: 53711648:user:proton X-Pm-Message-ID: c4432e9a0ef440c72b2b229e2ff99373b5e80ae7 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spamd-Result: default: False [-4.20 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; DMARC_POLICY_ALLOW(-0.50)[lorenzosalvadore.it,quarantine]; R_SPF_ALLOW(-0.20)[+ip4:185.70.40.0/24]; RWL_MAILSPIKE_VERYGOOD(-0.20)[185.70.40.22:from]; R_DKIM_ALLOW(-0.20)[lorenzosalvadore.it:s=protonmail2]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; MISSING_XM_UA(0.00)[]; ASN(0.00)[asn:62371, ipnet:185.70.40.0/24, country:CH]; RCVD_COUNT_ZERO(0.00)[0]; MID_RHS_MATCH_FROM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; FREEMAIL_TO(0.00)[comcast.net]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[lorenzosalvadore.it:+] X-Rspamd-Queue-Id: 4XCcYT58vcz54dR X-Spamd-Bar: ---- On Tuesday, September 10th, 2024 at 18:13, Alex Arslan wrote: >=20 >=20 > I noticed that GCC and its associated libraries, when installed from pkg > on FreeBSD 14.1 AArch64, have an OS/ABI value of NONE (0) rather than > FreeBSD (9), as reported by readelf --file-header. I also observed this > when cross compiling GCC for FreeBSD 13.2 AArch64 on Alpine Linux; I > assumed it was an issue with the cross compilation setup until I realized > that the one from pkg exhibited the same thing. This does not seem to > occur with x86_64, neither from pkg nor cross compiled. Does anyone know > why this would happen and whether it could be addressed with a patch to > GCC? Apologies if this is already known and has been discussed somewhere. Hello, I am the maintainer for the GCC ports, sorry for the late response. I have created a bug report to track this issue, so we do not forget about it: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D281681 Is the bug only about the value reported by readelf? Or is the compiler actually broken? If the compiler works, what is the value reported by readelf for binary compiled by it? Thanks for your bug report, Lorenzo Salvadore From nobody Tue Sep 24 16:05:45 2024 X-Original-To: freebsd-hackers@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 4XCl941rVCz5XxPF for ; Tue, 24 Sep 2024 16:06:32 +0000 (UTC) (envelope-from ararslan@comcast.net) Received: from resqmta-h2p-567063.sys.comcast.net (resqmta-h2p-567063.sys.comcast.net [IPv6:2001:558:fd02:2446::b]) (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 4XCl933LjVz4Kt5 for ; Tue, 24 Sep 2024 16:06:31 +0000 (UTC) (envelope-from ararslan@comcast.net) Authentication-Results: mx1.freebsd.org; none Received: from resomta-h2p-555058.sys.comcast.net ([96.102.179.196]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 256/256 bits) (Client did not present a certificate) by resqmta-h2p-567063.sys.comcast.net with ESMTPS id t6gvsHD1BU9Ptt83OszSts; Tue, 24 Sep 2024 16:06:18 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=20190202a; t=1727193978; bh=AcaZlgZv/m25fRL36MtjNidIP2+1Xm5Bf272TbNld10=; h=Received:Received:Content-Type:Mime-Version:Subject:From:Date: Message-Id:To:Xfinity-Spam-Result; b=pQzpQ+8HEFDMhAJl4V8Bauo7JwJh4P9PaR0N9L1YgC4xBxd1CfcDjT3U3aBO7R4hM 6rFacwFrHyBP4N1XfJPIAklNvnAL4KAEjYDgfMUKQm+8/WLCe4Npqgw9TFhz651Al6 oZR6Y81Auq674kE+57KqcY6Mmgxx6echJwyxvK1d8R9UuYz4IH20Z5NeW5mmVGdn4t EV4FZcY/+Ok+ypQV7b8PxAfAHphUh1xlyhIVEN9ui8Q4okICt4uOHF+MVkEZYCRi0m Y0ShVGZheIOHfiXMyASJ5EjW/7WCd1jRpuDmZzCyOAj8o5f0s3XaYXM8Ey+erAp3ns mnVwVs8cr3jQw== Received: from smtpclient.apple ([67.160.29.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 256/256 bits) (Client did not present a certificate) by resomta-h2p-555058.sys.comcast.net with ESMTPSA id t831sW40hhyDYt832sHlXv; Tue, 24 Sep 2024 16:05:57 +0000 Content-Type: text/plain; charset=utf-8 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3776.700.51\)) Subject: Re: Wrong OSABI for GCC from Ports From: Alex Arslan In-Reply-To: Date: Tue, 24 Sep 2024 09:05:45 -0700 Cc: FreeBSD Hackers Content-Transfer-Encoding: quoted-printable Message-Id: <52727CFE-BE16-4778-83BD-2EE07B44C9A5@comcast.net> References: To: Lorenzo Salvadore X-Mailer: Apple Mail (2.3776.700.51) X-CMAE-Envelope: MS4xfKML6TGme6y3Gn+BaIu1MxLTHfaw72Dk3w7JqHIZiC1Tfncg7wTvBq4hPQssPV84HXEZIKyYlriUmJBrlfcDibmWzq6FQP3/NkiEych2bx9BBnYf4zNl TwF8W1j5PJg2DovHAlUtNHkynvF/bJWfH1P6x9VjShPrmA2Hik8T+Zxw2/GQOIjCJ3QZBnRP6bogQQ4QM3Xz7YDhCcRqUHaZpmfurnQxZspMe7E8DaVlofWU i868sOunY221BNXpJ8T6ng== X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7922, ipnet:2001:558::/29, country:US] X-Rspamd-Queue-Id: 4XCl933LjVz4Kt5 X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated > On Sep 24, 2024, at 4:08=E2=80=AFAM, Lorenzo Salvadore = wrote: >=20 > On Tuesday, September 10th, 2024 at 18:13, Alex Arslan = wrote: >=20 >>=20 >>=20 >> I noticed that GCC and its associated libraries, when installed from = pkg >> on FreeBSD 14.1 AArch64, have an OS/ABI value of NONE (0) rather than >> FreeBSD (9), as reported by readelf --file-header. I also observed = this >> when cross compiling GCC for FreeBSD 13.2 AArch64 on Alpine Linux; I >> assumed it was an issue with the cross compilation setup until I = realized >> that the one from pkg exhibited the same thing. This does not seem to >> occur with x86_64, neither from pkg nor cross compiled. Does anyone = know >> why this would happen and whether it could be addressed with a patch = to >> GCC? Apologies if this is already known and has been discussed = somewhere. >=20 > Hello, >=20 > I am the maintainer for the GCC ports, sorry for the late response. > I have created a bug report to track this issue, so we do not forget > about it: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D281681 Thank you! Mik=C3=A4el Urankar pointed out that what I described sounds = similar to https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D252490 and I = believe it is actually the exact same phenomenon as what I described. > Is the bug only about the value reported by readelf? Or is the = compiler > actually broken? If the compiler works, what is the value reported by > readelf for binary compiled by it? The compiler itself works just fine, it's only the OS/ABI in the ELF = file header that isn't set to FreeBSD. It does have a FreeBSD branded ELF = note though. Binaries produced by cc set OS/ABI to FreeBSD and include the = ELF note, whereas binaries produced by the GCC port (13.2.0) have OS/ABI set to NONE but do still include the branded ELF note. The produced binaries are similarly functional. Based on the discussion in Mik=C3=A4el's bug report, it sounds like this behavior is expected, so I guess there's no bug after all? > Thanks for your bug report, >=20 > Lorenzo Salvadore >=20 From nobody Tue Sep 24 19:48:36 2024 X-Original-To: freebsd-hackers@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 4XCr5d6h70z5YCpN for ; Tue, 24 Sep 2024 19:48:53 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 4XCr5d4hvhz4tHL for ; Tue, 24 Sep 2024 19:48:53 +0000 (UTC) (envelope-from kostikbel@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: from tom.home (kib@localhost [127.0.0.1] (may be forged)) by kib.kiev.ua (8.18.1/8.18.1) with ESMTP id 48OJmadc032162; Tue, 24 Sep 2024 22:48:39 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 48OJmadc032162 Received: (from kostik@localhost) by tom.home (8.18.1/8.18.1/Submit) id 48OJmaeN032161; Tue, 24 Sep 2024 22:48:36 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 24 Sep 2024 22:48:36 +0300 From: Konstantin Belousov To: Alex Arslan Cc: Lorenzo Salvadore , FreeBSD Hackers Subject: Re: Wrong OSABI for GCC from Ports Message-ID: References: <52727CFE-BE16-4778-83BD-2EE07B44C9A5@comcast.net> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <52727CFE-BE16-4778-83BD-2EE07B44C9A5@comcast.net> X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=4.0.1 X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on tom.home X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US] X-Rspamd-Queue-Id: 4XCr5d4hvhz4tHL X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated On Tue, Sep 24, 2024 at 09:05:45AM -0700, Alex Arslan wrote: > > > On Sep 24, 2024, at 4:08 AM, Lorenzo Salvadore wrote: > > > > On Tuesday, September 10th, 2024 at 18:13, Alex Arslan wrote: > > > >> > >> > >> I noticed that GCC and its associated libraries, when installed from pkg > >> on FreeBSD 14.1 AArch64, have an OS/ABI value of NONE (0) rather than > >> FreeBSD (9), as reported by readelf --file-header. I also observed this > >> when cross compiling GCC for FreeBSD 13.2 AArch64 on Alpine Linux; I > >> assumed it was an issue with the cross compilation setup until I realized > >> that the one from pkg exhibited the same thing. This does not seem to > >> occur with x86_64, neither from pkg nor cross compiled. Does anyone know > >> why this would happen and whether it could be addressed with a patch to > >> GCC? Apologies if this is already known and has been discussed somewhere. > > > > Hello, > > > > I am the maintainer for the GCC ports, sorry for the late response. > > I have created a bug report to track this issue, so we do not forget > > about it: > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=281681 > > Thank you! Mikäel Urankar pointed out that what I described sounds similar > to https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252490 and I believe > it is actually the exact same phenomenon as what I described. > > > Is the bug only about the value reported by readelf? Or is the compiler > > actually broken? If the compiler works, what is the value reported by > > readelf for binary compiled by it? > > The compiler itself works just fine, it's only the OS/ABI in the ELF file > header that isn't set to FreeBSD. It does have a FreeBSD branded ELF note > though. Binaries produced by cc set OS/ABI to FreeBSD and include the ELF > note, whereas binaries produced by the GCC port (13.2.0) have OS/ABI set > to NONE but do still include the branded ELF note. The produced binaries > are similarly functional. > > Based on the discussion in Mikäel's bug report, it sounds like this > behavior is expected, so I guess there's no bug after all? Kernel needs ELF note to decide to use FreeBSD emulation for the binary. So lack of the OSABI branding might only affect utilities like readelf that AFAIR indeed change their behavior on decoding e.g. dwarf unwind information, but I am not sure. On the other hand, since gcc uses base system' csu, it includes the noinit note, but gcc is not configured with --enable-initfini-array. This makes all static global constructors non-functional. From nobody Wed Sep 25 13:34:51 2024 X-Original-To: freebsd-hackers@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 4XDHlp6Fsjz5XTn6 for ; Wed, 25 Sep 2024 13:35:02 +0000 (UTC) (envelope-from fullermd@over-yonder.net) Received: from mail.infocus-llc.com (mail.infocus-llc.com [199.15.120.13]) (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 4XDHll6M1xz43Ms for ; Wed, 25 Sep 2024 13:34:59 +0000 (UTC) (envelope-from fullermd@over-yonder.net) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of fullermd@over-yonder.net designates 199.15.120.13 as permitted sender) smtp.mailfrom=fullermd@over-yonder.net; dmarc=none Received: from draco.over-yonder.net (draco.over-yonder.net [IPv6:2001:470:1f0f:11ae::5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.tarragon.infocus-llc.com (Postfix) with ESMTPSA id 4XDHlc71vxzLHM; Wed, 25 Sep 2024 08:34:52 -0500 (CDT) Received: by draco.over-yonder.net (Postfix, from userid 100) id 4XDHlb5k9VzNh2; Wed, 25 Sep 2024 08:34:51 -0500 (CDT) Date: Wed, 25 Sep 2024 08:34:51 -0500 From: "Matthew D. Fuller" To: Eirik =?iso-8859-1?Q?=D8verby?= Cc: freebsd-hackers@freebsd.org Subject: Re: Announcing freebsd-rustdate Message-ID: References: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/2.2.13 (2024-03-09) X-Spamd-Result: default: False [-3.28 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.98)[-0.978]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:33069, ipnet:199.15.120.0/22, country:US]; MID_RHS_MATCH_FROM(0.00)[]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DMARC_NA(0.00)[over-yonder.net]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+] X-Rspamd-Queue-Id: 4XDHll6M1xz43Ms X-Spamd-Bar: --- > Any hope of seeing this in ports? Then I could actually play with it > at some scale around here.. As of this morning, it now is: https://cgit.freebsd.org/ports/commit/?id=cd98eb34489646fd0a340bbaca9ba0088d6576a4 So portaphiles should be set to build it from there now. Packagarians would be sometime around the weekend, I s'pose. -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From nobody Fri Sep 27 11:52:45 2024 X-Original-To: hackers@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 4XFTlZ11mpz5XvxF for ; Fri, 27 Sep 2024 12:08:58 +0000 (UTC) (envelope-from Stephane.ROCHOY@stormshield.eu) Received: from mail.stormshield.eu (mail.stormshield.eu [91.212.116.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.stormshield.eu", Issuer "Sectigo RSA Organization Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4XFTlX6wVMz4kgs for ; Fri, 27 Sep 2024 12:08:56 +0000 (UTC) (envelope-from Stephane.ROCHOY@stormshield.eu) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=stormshield.eu header.s=signer2 header.b=o83d9k10; spf=pass (mx1.freebsd.org: domain of Stephane.ROCHOY@stormshield.eu designates 91.212.116.25 as permitted sender) smtp.mailfrom=Stephane.ROCHOY@stormshield.eu; dmarc=pass (policy=quarantine) header.from=stormshield.eu DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stormshield.eu; s=signer2; t=1727438934; h=From:Subject:Date:Message-ID:To:MIME-Version :Content-Type:Content-Transfer-Encoding; bh=Rk1dmorpa+g6M2Tdq6VZB2TticZhe ISlUtw0F+R3NU0=; b=o83d9k101YtQOyXuU2lWLvOhhv/3XWXIAtuAyv3MNCs7dWwMhvJUUJ wMl+ObYsQAjDDLhNC8bNOODdwXgqcj6e6LGd0aBqjWd/znrbHrWunVGX5uk+QS7TOYEbICfzv nHOM1+01OZTdrIodaUKWNgVpODvmyfySXi5Me7YNzQocVoyPsGUJ1U0QD/flcxkwsvF84Wnf4 oAQL/XWT/2TTzzGeDmCYAWfGRJwGYYbTcNZJUTFZjfSo3h4h3adpgn/WKQNszbUug5AuRVpcW Gayj0pUC2DI74LfvDxYAz6v8wkb/o6WaSxV7EBFwe7GZMDS16m3mkKWIMt2BT3oHi8VBw==; User-agent: mu4e 1.10.7; emacs 29.4 From: Stephane Rochoy To: "freebsd-hackers@freebsd.org" Subject: atrtc Couldn't map I/O Date: Fri, 27 Sep 2024 13:52:45 +0200 Message-ID: <86cykpe1t5.fsf@cthulhu.stephaner.labo.int> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: quoted-printable X-ClientProxiedBy: ICTDCCEXCH002.one.local (10.180.4.2) To ICTDCCEXCH002.one.local (10.180.4.2) X-DKIM-Signer: DkimX (v3.60.360) X-Spamd-Result: default: False [-3.99 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.994]; DMARC_POLICY_ALLOW(-0.50)[stormshield.eu,quarantine]; R_SPF_ALLOW(-0.20)[+a:mail.stormshield.eu]; R_DKIM_ALLOW(-0.20)[stormshield.eu:s=signer2]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:49068, ipnet:91.212.116.0/24, country:FR]; MLMMJ_DEST(0.00)[hackers@freebsd.org]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; TO_DN_ALL(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[stormshield.eu:+] X-Rspamd-Queue-Id: 4XFTlX6wVMz4kgs X-Spamd-Bar: --- Hi Hackers, I have a board running 14.1 with the following warning reported by atrtc(4): atrtc0: Warning: Couldn't map I/O. It seems to comes from atrtc_attach: sc->port_res =3D bus_alloc_resource(dev, SYS_RES_IOPORT,=20 &sc->port_rid, IO_RTC, IO_RTC + 1, 2, RF_ACTIVE); if (sc->port_res =3D=3D NULL) device_printf(dev, "Warning: Couldn't map I/O.\n"); What puzzle me a bit is that: - nobody seems to use sc->port_res - and IO_RTC (0x70) is manipulated directly via outb/inb instead of bus_write/bus_read, thus ignoring the failure of bus_alloc_resource. But what puzzle me more is that bootverbose show that ACPI expose an I/O port range (type 4) containing 0x70: pcib0: port 0xcf8-0xcff on acpi0 pcib0: decoding 5 range 0-0xfe pcib0: decoding 4 range 0-0xcf7 pcib0: decoding 4 range 0xd00-0xffff pcib0: decoding 3 range 0xa0000-0xbffff pcib0: decoding 3 range 0xe0000-0xe3fff pcib0: decoding 3 range 0xe4000-0xe7fff pcib0: decoding 3 range 0xe8000-0xebfff pcib0: decoding 3 range 0xec000-0xeffff pcib0: decoding 3 range 0xf0000-0xfffff pcib0: decoding 3 range 0x80000000-0xbfffffff pcib0: decoding 3 range 0x4000000000-0x7fffffffff and nobody reclaim it: pcib0: allocated type 4 (0xefa0-0xefbf) for rid 20 of=20 pci0:0:31:4 pcib0: allocated type 4 (0x2e-0x2f) for rid 0 of superio0 pcib0: allocated type 4 (0x4e-0x4f) for rid 0 of superio1 pcib0: allocated type 4 (0x2e-0x2f) for rid 0 of superio0 pcib0: allocated type 4 (0x60-0x60) for rid 0 of atkbdc0 pcib0: allocated type 4 (0x64-0x64) for rid 1 of atkbdc0 So what could explain bus_alloc_resource's failure then? And can it be a real problem as atrtc stubbornly use the port. Regards, --=20 St=C3=A9phane Rochoy O: Stormshield From nobody Sun Sep 29 16:17:52 2024 X-Original-To: freebsd-hackers@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 4XGqB10mhZz5Xs2C for ; Sun, 29 Sep 2024 16:18:01 +0000 (UTC) (envelope-from void@f-m.fm) Received: from fout-a7-smtp.messagingengine.com (fout-a7-smtp.messagingengine.com [103.168.172.150]) (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 4XGqB02Jr6z3xdb for ; Sun, 29 Sep 2024 16:18:00 +0000 (UTC) (envelope-from void@f-m.fm) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=f-m.fm header.s=fm2 header.b=rCtyAuQO; dkim=pass header.d=messagingengine.com header.s=fm2 header.b=RWrJkIp+; spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 103.168.172.150 as permitted sender) smtp.mailfrom=void@f-m.fm; dmarc=pass (policy=none) header.from=f-m.fm Received: from phl-compute-12.internal (phl-compute-12.phl.internal [10.202.2.52]) by mailfout.phl.internal (Postfix) with ESMTP id D13A1138026A for ; Sun, 29 Sep 2024 12:17:54 -0400 (EDT) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-12.internal (MEProxy); Sun, 29 Sep 2024 12:17:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=cc :content-type:content-type:date:date:from:from:in-reply-to :message-id:mime-version:reply-to:subject:subject:to:to; s=fm2; t=1727626674; x=1727713074; bh=a+CcUCuAj/hK4CMfQIB3WlbBKCFT5Pkn jNi1Rjgf7lM=; b=rCtyAuQONqn49nk3XLjgg8XoMy90d7lyGxKk2NSBmgBgrmNR xa5kAD3psyIRGLKh++SdDEM/KUW057BtOkgK2ZOMpwraVQCrw2UrHR/vIw1rvdEc 8Wp9iM2ISu7LzFA2pavE0ip6TGypNjwt7spry5/GDMkNAqLJJv9TbivskMjLOLuy /lK5VJ0/UYAuKNDZfs1sKj20/74Fmy+cqp1JL4voJuEBb3Re9mtZ6w5TbD3iyPCL H9IxMVxEf3doi3q4gDktwSuBRK92EI9cGHVaZfVQSptQCtgoTrnqBdt+2fL4LiTn C/FRQnjqDSV5RnTvbLSUQ+izisCIl7RIzse19g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:message-id :mime-version:reply-to:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t= 1727626674; x=1727713074; bh=a+CcUCuAj/hK4CMfQIB3WlbBKCFT5PknjNi 1Rjgf7lM=; b=RWrJkIp+A/rnevlhHq2jZb7sX9pKoKEJGMTp6o7JVvbnEpQGG9W 6SqytgJMHm6AbXDM+Q/ANb9xW4e4RPBxTWDXDwc7zmHQjVPayQ3LDS1Atv797NEh VYCAqVegiBR8ygJFwFCmPMJNr7JNxjCQwOmSCNuioaqXMJp3amgvD6WK4RhUlrog ACfIqkLZ1tLuONL9cp7LUUop7j+caqKXQI1SxJcDUE9cOwcMNOEamqQeaunSBLEe j/UAsbj0ACo+B0E2opDxdAB8JMnasaZqMXmo/XCBY3ke23iYvw7hO3agJkPQiPti R+fNOHpymRRL2RQQ8qkT2RyfiAeN2m7elbA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrvddufedguddtudcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdp uffrtefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecunecujfgurhepfffhvf fukfggtggusehttdertddttddvnecuhfhrohhmpehvohhiugcuoehvohhiugesfhdqmhdr fhhmqeenucggtffrrghtthgvrhhnpeevudffiedvffffgffhgeefjeefffdtieetheetke efhfdvfefgtedtueehgeffueenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhep mhgrihhlfhhrohhmpehvohhiugesfhdqmhdrfhhmpdhnsggprhgtphhtthhopedupdhmoh guvgepshhmthhpohhuthdprhgtphhtthhopehfrhgvvggsshguqdhhrggtkhgvrhhssehf rhgvvggsshgurdhorhhg X-ME-Proxy: Feedback-ID: i2541463c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Sun, 29 Sep 2024 12:17:54 -0400 (EDT) Date: Sun, 29 Sep 2024 17:17:52 +0100 From: void To: freebsd-hackers@freebsd.org Subject: sccache-overlay and building for different major os versions Message-ID: Mail-Followup-To: freebsd-hackers@freebsd.org List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline X-Spamd-Result: default: False [-3.79 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.995]; DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none]; MID_RHS_NOT_FQDN(0.50)[]; R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm2,messagingengine.com:s=fm2]; RWL_MAILSPIKE_VERYGOOD(-0.20)[103.168.172.150:from]; R_SPF_ALLOW(-0.20)[+ip4:103.168.172.128/27]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[103.168.172.150:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; FREEMAIL_FROM(0.00)[f-m.fm]; RCVD_COUNT_THREE(0.00)[3]; MIME_TRACE(0.00)[0:+]; FROM_HAS_DN(0.00)[]; FREEMAIL_ENVFROM(0.00)[f-m.fm]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; ASN(0.00)[asn:209242, ipnet:103.168.172.0/24, country:US]; RCVD_VIA_SMTP_AUTH(0.00)[]; MISSING_XM_UA(0.00)[]; DWL_DNSWL_NONE(0.00)[messagingengine.com:dkim] X-Rspamd-Queue-Id: 4XGqB02Jr6z3xdb X-Spamd-Bar: --- Hello, am asking this here because I guess most of you will be familiar with building in poudriere. Is it expected that using sccache-overlay will work when the host is running current but the builder is for example a 14.1-p6 poudriere jail? --