From nobody Mon Sep 30 21:32:57 2024 X-Original-To: freebsd-stable@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 4XHZ7H0JSQz5Xhnr for ; Mon, 30 Sep 2024 21:33:15 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic312-24.consmr.mail.gq1.yahoo.com (sonic312-24.consmr.mail.gq1.yahoo.com [98.137.69.205]) (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 4XHZ7F15Dlz4Q1s for ; Mon, 30 Sep 2024 21:33:13 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=W8H1OLU8; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.205 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=1727731990; bh=fmOVaRQ7yLbzEvIWS6IkWMYrz6e9PAkxx/IiU4fp9kc=; h=From:Subject:Date:Cc:To:References:From:Subject:Reply-To; b=W8H1OLU8B3VMQhwhGxVoGFYvAL57qQq6I17JwUoLQXxcxCd/fIOUUDfp/Zu2vC7PCeIz/pXOtDNqosLbzmGUac0G4cnGztU1cNViQUouP6Mq8kfp+i32NJN2onCQ7WZ0DgB12M62AorfrlFZFfRQ0w5ikoK75aVqy+LExVZPQZRe42G6N6T9kUDZvnv7HulkY+ESZY8Rv4hkGmf3aQ1J2zNB6Z2F2cYe6qIb3Z9lUZN9jH3VafdMX2gQvj9MGxV6wdDzdJs99nA7Oj3f30uupVQgwxRw0f8ICkVYe0vIPkId7N4+M8MPNUtlJ4TYkrWf3JgdiyJymN/FptSulE4Yow== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1727731990; bh=GuugBo9KvT2JOLUjd/BQOYWVovFEijBdCvU6c4pFR1G=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=EnZOIPgMIOh0gpu17IIdONn5PPSHKaEpFC4V3I/YjjAZFiNK4bldTw1RftiSl4pofdLEp3ZJC2z8+82BAY30Cdad8NYh64xRMxPE5AJpS5auogneQMipedlTbc1zrXghAhhLtk3wVxQCMG1uujE4IYpTCnNZW+HKHblb15HQ/Qou0h26iKZg41GoJYHYiyHzM1i094sbaOC98kpcyDp3JhKq7476+cx0RY3iuByTSdfd5YeD3UnB3mo6zXCcaeDabmjw6W4d8+ij28q40rYtvq3GZ2/hLK3jD+sDlEZhuMI1glZy0ODJV1+ymhBJHxmwhHCo7T07ViiZM6C8OX2GGA== X-YMail-OSG: duXNpNkVM1nEuvdKjKdewqLtDcaY9dYF8zOqSvkBK7WIZ6uLPbyik1nnGK1knJ. ne_kudmxFuNVZlzvgaqmPa0tSo8tWiDakOaj1jbCQLFYWaoxTIUUfx5R6HLOijL5T5HVyQBk7uZ7 OWEilYRs1g2VZy_0kNPbJ3dXKKcHIJESiUahsu_TSQ6qZDSyuG9nMhvdmFTNckUFihMaZLlZADl9 7ztZ4watZa0wfoPrPtKUIeGW5mxnkS0POU_auNTp09rcT02cMwGX2KckE0rdTSDJY..abGH5t.3a 5orb1qWutcvY7O2hASzPtNW7dk2O2gfVzMwsuiZZpiMUfmH_.DdQ.TjSrRAzw5zEnReYwew26kY5 zSgXS5GwhrrOb9hiDKYSskVV26NcJUqSWZhuAvq9KS_jeHr7CKuaJ.raWgtZMclclcYeNqYlw7PE y3Mp_Q8MBGotOmZyvHjjH.xU7Wyt9Ttbv4BvXlCn7uMEiZcCQbAfv0CA4bl7hBVsD6sdJAByzL8x pMzwoXGFhSPN7KJV9e4buf8dw86qc7ZqICwTqtxc4BB5A.KGZAcY_pYDw86whvpeWVpe0PfCo1.k eLBVV9pjQzvnujVWSDlHq7abOpDV2vcemue_zGxTDundcVVMXjRdpuyfso_yapxOfG3ee8HpnNkz 1wdexy3yTdT051nVIeD97V70ywaGqEOSKtGG3Lp8Km6SWp6fIeNudvqJdZbndA8T833iYnwfMMYS DnF0JqAzJrr2o_HjxEu3_GVmmnBCEjSXHfTimdiXBxd6zPfozRspDUHQ40vUxLCZq5ClNXcJLbpt B1Sf04IQn7iQc47klZeDfLoqLOMIy9ByWSLkFq6JaUnIug5nbdIAdUSKKqhdT0M83ABmONGz3dHv kUM87ZCDRHMMQ_MfYketkZalzyNGBFiUj8nVC13qV7ixKiKP981ZVTuBvnOFONxw0izORDG.fEGQ Ma1cdmqiakYqMp89al0YyQHs52564wDIq01bafBYbi6ptbcyWknU0X5ICbXe9QgXrQ34pAuvs0nQ WE7e1Q72p86ndS.qePpU4DKpQE3JuSLWTWBle6L4.hUvIsTYHVEZ1fLQJ0RHuQFFrE2c8AQ0D0lG OBLKc2pPxUIRXhGGxZ22BomOGXRiYvfwXwFD0LrC_2cYr.uDhRFOiFGPksjnPYriOJquUKZOf1kT LFaGKpknW2NwkysVwaWpKxOee9V18fTaiJzjAL32so.XcpnfxSb6NDbWcV5WID5fREqsDGdhzKcv rJe3eQZK3opvYdel_orcMilA7tPH758yVn3ZTz1tTcOnnebPuXYhPduVKmT7e8BEdhtwscKTmwAx Fw7CmVA4w0VH04BG2E7LDjqGsGnFVkiZQh41dkCc07g7Z2CQgeAtqPH.4bFqeOtz.m6oi4Hb6FRQ DzmKt8op0t3DpLLy7CX6A3rMhH148m4vzMPJ5csVufKXrZQJ56Ou_dij_HNICp896K3V3dArlLS4 XqtdkGEeOmk0b57IEbeJuzoknKvu1LLojOGcJ_AVZi8_dXbWUmiKvMFTPspuI2YSf3pJdjHwp0EM x.1_tg4K07or1b2hTnFjPQF827ayw7mt_HtNHEcTJhY1_JMBLsokWTtXI6Ij94ZvfNIqSXG0Zgom WUQIDwVDyput21krdQBqNP4GkulDqLgN5GpHhvUHrOUVR66yzECRX9Fwwk8KC7mwfiiBrua8WHOS huV9DO86Qds9qafytshz0.dSZHfxyBQO2JOeFpxRn05rp3GG9Ui8Yt_J248rbplOYQYAVcYDS8eJ yekv5UI3By5TkiEQx_.mdzrS9jS_TbuVnxv5tPS_Xf4Vxl566R_fcTaT.NGlqJD2uwykD4Fh6BW3 cbm9R8c4qbRq0B_AkfdpQ1KftFTo4u_T12XnKTGj6_sVjcA9zqkP76FUX8ILkUd0cPXkoHdscRsc xsYg_fNiLesP3iN78dMTdTVlfkgzfYMprlSbO9f44Y9zUZFFclMMuzn3JAg6RbrCs4KmUxUWeA.L pLShKbVL3v2BqXYS9oRhpiUvyrmB.dtgs9DGALzPcBkiLzAAy8M1VUu19Ip_OzI7MXR4L3ZfokdG p4mY0oe_Muuo6O_TDkuo4leQNGKzpfAT25n.ApDBT6ip3CDTw_D3WcvjzJ9YI17cadktk5oIlA9U psFFs4IfLrJPGncnmEQ3_Bo1eDWwiD6M0vTbWOraUfDV_KQF1DAxA3ePycLo8_r9XB9Bb.bF_Ggt yZFclqHTA.z_r7xjtbXNGb53r9COmHv.dNNiCgOOSKgOm3D7JUet3D6CDR34Sq04g9BhoXcZrSYJ udVASd2KjeESSK4og6g-- X-Sonic-MF: X-Sonic-ID: 458af069-5d23-45fe-aabf-d1a769936ae5 Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Mon, 30 Sep 2024 21:33:10 +0000 Received: by hermes--production-gq1-5d95dc458-c8wt4 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID fea2da6b2ef6c78d247e52168a3cede3; Mon, 30 Sep 2024 21:33:08 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-stable@freebsd.org Sender: owner-freebsd-stable@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3776.700.51\)) Subject: Gradually vanishing total over time for Active+Inact+Laundry+Wired+Free as seen in top (14.1-RELEASE at least) Message-Id: <00911A45-1F43-4192-B2D5-74C0781EE1E3@yahoo.com> Date: Mon, 30 Sep 2024 14:32:57 -0700 Cc: henrichhartzer@tuta.io To: FreeBSD-STABLE Mailing List X-Mailer: Apple Mail (2.3776.700.51) References: <00911A45-1F43-4192-B2D5-74C0781EE1E3.ref@yahoo.com> X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; 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)[text/plain]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; RCPT_COUNT_TWO(0.00)[2]; FREEMAIL_FROM(0.00)[yahoo.com]; TO_DN_SOME(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MLMMJ_DEST(0.00)[freebsd-stable@freebsd.org]; APPLE_MAILER_COMMON(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.205:from]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.205:from] X-Rspamd-Queue-Id: 4XHZ7F15Dlz4Q1s X-Spamd-Bar: --- This note is based on: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D280846 comments 9 and 11. (I'm not the person that reported the issue. I do not run 14.1-RELEASE .) Comment 9 was about duplicating a ZFS context to UFS media and then booting that UFS media, no ZFS file systems. It continued to have the property that Active+Inact+Laundry+Wired+Free decreased over time. It turned out zfs_enable=3D"YES" had been left in place so that ZFS was loaded but otherwise unused. Reported after some use was (for a system with 8 GiBytes of RAM): QUOTE [of text from top, other than the "(empty . . .)" note] Mem: 28M Active, 76M Inact, 76M Laundry, 1464M Wired, 642M Buf, 369M = Free ARC: (empty, of course) END QUOTE Comment 11 was about then doing a "kldunload zfs.ko". That resulted in (shown by another run of top): QUOTE Mem: 1536M Active, 1590M Inact, 306M Laundry, 1371M Wired, 603M Buf, = 221M Free END QUOTE (No ARC, as expected.) So it appears that zfs.ko being loaded was sufficient for memory to gradually land in (effectively) a "Mem:" category that top does not report. (Possibly the system does not report/track more generally?) But: 1536+1590+306+1371+221 =3D=3D 5024 So it still does not total close to 8192 . =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Tue Oct 1 02:06:41 2024 X-Original-To: freebsd-stable@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 4XHhBr0xHrz5Y1pg for ; Tue, 01 Oct 2024 02:06:44 +0000 (UTC) (envelope-from christos@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 4XHhBr0QHCz462G; Tue, 1 Oct 2024 02:06:44 +0000 (UTC) (envelope-from christos@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1727748404; 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=RluXmSWM9DoBiEczhAJzp1VpMX8S+aRDJghVmNU624Y=; b=C15bi7JZ3Cjr9SfPezZqHeinlect0pkAyA9e7D5jRXvNZEPQOANQMdHbMPUCcZayUpxlU+ COGMmmrBaYrOREe7zzOUBm3c689EYWc+wF06AD1Z3glwKNFzKGeKht4wJqLiPjLNY368AX bpwhQBylY69Gw5P9YRkY6g9XmLTSVnkuf7RV8CkbAmJe8s4jnKvh+mezgLjxHlhtjuzyd3 eu/W5nxksvyx1QKqxQuni/6lt+/vLZ0xg3Z/EkPEatJ2IdO3E57JBVWvCu+YcCHrqs6sVm o7y78Esoqirscbx3y9KKMa9xS15H1BUP6gbb/0MCqyDYXfTgmAsUdi0jzFeOGw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1727748404; 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:dkim-signature; bh=RluXmSWM9DoBiEczhAJzp1VpMX8S+aRDJghVmNU624Y=; b=BsDm1AhsdL6BF6Ju2vM/bv4EH/hpQNidksp9JhvUKc0WR+sOaoaHORA5nlD4+5Z0sw06j1 8JTzIIu6sMu7DmI9Fq7F3aJR0K8IBCOecMOpo1TiRiB1ol+mReb5G/lBxRj8NlIrSfdI6T CRmjnpsXh7vp5kug0i7uaR5J54Q8XKFmJCkCzS0OtgE7pOhExG/2lrMgSk0DCinEYKJ5X1 kB2v2kdU/2iIUtADh7zCXih3dzvh7QYnGydc4klPJEa8vdGvc5/FX6Ve2If1gpmAQD6e0h r+WX+LaczWjyt2czVKk3p/8E0MeePOnBBSkX5qViMHWaEFj4ejevLrUar/2tcw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1727748404; a=rsa-sha256; cv=none; b=areI3YcS0mJcKFdCTcjP4SSpMTc3OahynaRXpIjPTIhcsQ3ylxwKHVzyt+LYmcCXuqesw/ IZPmUCR5o627/3XoE9pMi1fZxC8PPVlDfFZ+YAMnFjiJ8/BcH/Qb7ZqeIiCT7DZIov5RAO mAaq7FpMNIYkLL5SBQwVk+WF+CMThNgalB5NEpYpHXoOv/jGMR6Yc32exkCISkWi/wWJ2V US6yDVP+7BESb22oYPY7fvyV1jXYqvnegE2YgXPe/7aR81t7pN/aX9fGxJUJEklaoUVfEO DCVvfRq0ddivtTlgNSxtHpv7ejsJwjt1EYnYdPFKo1kjoHdPurA+SKYNhCT19w== Received: from margiolis.net (mail.margiolis.net [95.179.159.8]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA512) (Client did not present a certificate) (Authenticated sender: christos/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4XHhBq4GyszbTJ; Tue, 1 Oct 2024 02:06:43 +0000 (UTC) (envelope-from christos@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=mail; bh=gO75/1PkrGEi3/l F1v1IA+PBl1olRH1JjtZ7H3YF+Uk=; h=in-reply-to:references:subject:cc:to: from:date; d=margiolis.net; b=X0PuiuaN145anMH4tgzKOTW8N9fQ2XzPPtyUdBJI I+05wEG+PfOu6SIu6F7GmrWQ5oCYF1GY6F8e1q5y55dVceWcw/2rB8ypNW4Wx0A/WjOueE ys4W3VlfZ3+qdqu6BtZ+ccGngpA8Oax3TLAUsImU2lcFDj2DM3Zd+tRcC79n8= Received: from tpad (host-84-205-228-1.cpe.syzefxis.ote.gr [84.205.228.1]) by margiolis.net (OpenSMTPD) with ESMTPSA id cca41e42 (TLSv1.3:AEAD-AES256-GCM-SHA384:256:NO); Tue, 1 Oct 2024 02:06:41 +0000 (UTC) Date: Tue, 1 Oct 2024 05:06:41 +0300 From: Christos Margiolis To: Jamie Landeg-Jones Cc: haramrae@gmail.com, freebsd-stable@freebsd.org Subject: Re: uaudio device re-attach and persisting dev.pcm.$pcm.bitperfect sysctl Message-ID: References: <202409291624.48TGO0L7014234@donotpassgo.dyslexicfish.net> List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-stable@freebsd.org Sender: owner-freebsd-stable@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <202409291624.48TGO0L7014234@donotpassgo.dyslexicfish.net> Jamie Landeg-Jones wrote: > Christos Margiolis wrote: > > > Is there a reboot involved here? If not, then /etc/sysctl.conf is not > > read again, so it makes sense that it falls back to the defaults. > > May I humbly suggest that whilst it make sense to us who know how FreeBSD > works, it doesn't make sense to a casual user. > > I guess devd would be the solution, maybe this could be documented/scripted > for users with these issues? I will test the devd solution, and if it works, will propose a patch soon. Christos From nobody Wed Oct 2 11:24:23 2024 X-Original-To: freebsd-stable@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 4XJXWs1HB3z5YP0N for ; Wed, 02 Oct 2024 11:24:25 +0000 (UTC) (envelope-from des@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (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 4XJXWs0f5fz4QJ0; Wed, 2 Oct 2024 11:24:25 +0000 (UTC) (envelope-from des@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1727868265; 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=ZTNiOrkJxascpaOUgHevXisV7tiFarlE6KfYJPATZLY=; b=uPkPjnxeYtXwYzBTF/4/WgHBO79ayQDh6WjZd2AakhU4Pcl/7jR9qUlzhSMEUfwhx+6elI v7bJatD0RUZN/FvtLKTtcdAcNCg6bJC/IUKDAWsY/tpmJZT5cunjMpigHW6hSg6JXosSLs sWS022y39dDIX3gwT4N9sbRvuyJolZZgDNcRPAGYpFH86uWQZjDyN2+SW1x77XOfhxXBHM nPe4ycZJ4Y/k5fP8UyUf32jDhY4ibAe3hGtmyWEcLTV6NI3WVFWJms/e1Y/Y+nQA8Xp0Bu RaocCcGXLS7hnnInDff57Hdo2givoSVJkWFh/YBWsa+TzwopzEH85pSfAsDLsQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1727868265; 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=ZTNiOrkJxascpaOUgHevXisV7tiFarlE6KfYJPATZLY=; b=WJ4mT4CdNUtV83Uc+wQ098kB5RXGNJs9CxpKSX6uUc+o/AG/a29PF/5YHGw0W0hTj8KXUP I99Ut/3PQ7aYetLCIQ8R102m2C7kYgROrLWgcl/frkAqNd2jOzz9S5QasKX9aC3c29oNze JDxOpW8S7PDhKDppZXbN4OTpLga/GmWJy0nax8INvGYRXenXVyBclOvIKTQQYAD/r3SWgw fNOVQparUBZpUkZo4Htxfgp58FLwk8d3Ko/Kvvb8aXOVbJC0dZcxdCJ9p9o1MLeRUKxteW ADwgDgvd70806ZjYX6bez7nNwwftoLke+NSUBvS38o6hbv8HpGq/SrJevm/ASQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1727868265; a=rsa-sha256; cv=none; b=UDPywRS92P5Y0amh7SBV/RLGMUnSo78CxhPWy6au8M6b1c4Csx4rLFg3PgzVcno2945ihZ TcjXYGQ39qR28Mwaq86G96dYqAT19gauRb+9lGHAKx7I9JRnBzAiI4U7/swdCeOir+PNAt PBjENGVbGCKAkuVJcJAOdlor2qWvRWcIOIKq8kpDTl4DNe2fJv6/G0xAGKSB9WSCuwIbir oQFHmh3yY64va55UcBf7PYBafRSDQnu79cj3YvljJ5UoiC3A+zkXjIr+heSJ33rDI1hBfX X/JuhU/TCGq34SWvd9+KYKjErF/aQK6ncZ98XvKkqppzvrr6m7U2QMZtX2F2Hg== Received: from ltc.des.dev (unknown [IPv6:2a01:e0a:386:9c20:922e:16ff:fef1:acef]) (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) (Authenticated sender: des) by smtp.freebsd.org (Postfix) with ESMTPSA id 4XJXWr6g32zJ03; Wed, 2 Oct 2024 11:24:24 +0000 (UTC) (envelope-from des@freebsd.org) Received: by ltc.des.dev (Postfix, from userid 1001) id 728C8BEF6A; Wed, 02 Oct 2024 13:24:23 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Alban Hertroys Cc: freebsd-stable@freebsd.org Subject: Re: uaudio device re-attach and persisting dev.pcm.$pcm.bitperfect sysctl In-Reply-To: (Alban Hertroys's message of "Sun, 29 Sep 2024 12:09:24 +0200") References: User-Agent: Gnus/5.13 (Gnus v5.13) Date: Wed, 02 Oct 2024 13:24:23 +0200 Message-ID: <86ploiwxw8.fsf@ltc.des.dev> List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-stable@freebsd.org Sender: owner-freebsd-stable@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Alban Hertroys writes: > I have a number of sysctl=E2=80=99s in /etc/sysctl.conf to tune my audio = output: > > hw.snd.default_unit=3D2 > hw.snd.maxautovchans=3D0 > dev.pcm.2.play.vchans=3D0 > dev.pcm.2.bitperfect=3D1 This only works by accident because your DSP happens to be switched on and attached to pcm2 when sysctl.conf is processed during boot. If you boot your machine with the DSP switched off or unplugged, you will see errors during boot because these sysctl nodes do not exist until the DSP is turned on and the driver attaches to it. You need to set up devd to run the correct sysctl commands (with the correct device unit numbers, don't assume your DSP is always pcm2!) when your DSP is attached. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@FreeBSD.org From nobody Wed Oct 2 20:11:57 2024 X-Original-To: freebsd-stable@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 4XJmDp3p3vz5Y22F for ; Wed, 02 Oct 2024 20:12:10 +0000 (UTC) (envelope-from haramrae@gmail.com) Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [IPv6:2a00:1450:4864:20::629]) (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 4XJmDp1y4Nz4cxZ; Wed, 2 Oct 2024 20:12:10 +0000 (UTC) (envelope-from haramrae@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ej1-x629.google.com with SMTP id a640c23a62f3a-a90f263c60fso1620566b.3; Wed, 02 Oct 2024 13:12:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1727899929; x=1728504729; darn=freebsd.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=VKr4u9F18rez1MN2qWIpLw5XnlhLm6rRTtmOR4/Ar0o=; b=L3eTXbqC5bIkBPzDYbrEArtZ8BgCSQbndY38cfIYn1ljC3H+MuEmi9kad4wShJHq2f 0exRNPvk9tPXvH75XGUqioDFF+yZsDgsiSHtl4ZYPTK5tbPF5S12ooSQsBmfmcAVo6S8 5XwZdtB+gFaJyiMVewoYR/+jYOQUXC7okzqz++9INGJ/eGuDhK1mnlVIkWKydc7bBtlJ SVnUvBWqHGITrU8nVwSajPCL8H9em7rkCnJ9DWb0jyEoQHEEI9indqKhYncr0ziQ35H0 oIeQRwvHv0n7kAYRW9Woz9HPPyjJVx4OtxaT/ecvj65ZtPqnIfrqIS5guvLjQXiS9Rxg qN+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727899929; x=1728504729; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=VKr4u9F18rez1MN2qWIpLw5XnlhLm6rRTtmOR4/Ar0o=; b=Hh2v4GBK40FRivxvr6YRKj7K9tvgue4POl+pRYaF2aN/J/rUMbswRzi7vWXL9Dsz7a NYFxwP8VrLb4h4pEy9FBiJ3abLTPrJqitGuPNulxvmHytQMmCCHNaQ+DBTRIogz/x/h9 Mg95PDdcnWFhq1vBpExBgFlyDBIM/Q3OpYc5i8gzBpRBSwRtLO61hKDAqPpQu7Ks7+RB faI3Lc305+qorufuIDnkxcPoTGGtnVz2x00nmoZZ0bSn3p9X15RjW+3MfGLBG0OQlWfW gb+JaW9wJy89HYqoXiLNVtiIzu0Tv269MKj+8lNr3NVJfJB56CiuXF1S1jw5jfPYi/nz EOiQ== X-Gm-Message-State: AOJu0YwoXU6NvMlY6kF0DcNzrxu7d4ZiR6Xkzg4bcYCVIyFrYSNKFFGQ NAR/kwCOcgHS2PMVSVyZ+geN/JctFcuGjC1rog3dmyjy0EUqQet5TAdi1A== X-Google-Smtp-Source: AGHT+IFGbzh0u9e7vAmPAhEFCg4dA+zzEBzca0r0t5/pIJkAjZjuv+bhMD7EpDBXZqily7lB+ReUzw== X-Received: by 2002:a17:906:d553:b0:a90:3497:e138 with SMTP id a640c23a62f3a-a98f8386d7dmr137683766b.13.1727899928561; Wed, 02 Oct 2024 13:12:08 -0700 (PDT) Received: from smtpclient.apple ([188.212.112.125]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a93c277c056sm905873666b.33.2024.10.02.13.12.07 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 Oct 2024 13:12:07 -0700 (PDT) Content-Type: text/plain; charset=utf-8 List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-stable@freebsd.org Sender: owner-freebsd-stable@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3818.100.11.1.3\)) Subject: Re: uaudio device re-attach and persisting dev.pcm.$pcm.bitperfect sysctl From: Alban Hertroys In-Reply-To: <86ploiwxw8.fsf@ltc.des.dev> Date: Wed, 2 Oct 2024 22:11:57 +0200 Cc: freebsd-stable@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <8745F9FB-9CC1-476C-9445-DC0A7A76165F@gmail.com> References: <86ploiwxw8.fsf@ltc.des.dev> To: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= X-Mailer: Apple Mail (2.3818.100.11.1.3) 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:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Queue-Id: 4XJmDp1y4Nz4cxZ X-Spamd-Bar: ---- > On 2 Oct 2024, at 13:24, Dag-Erling Sm=C3=B8rgrav = wrote: >=20 > Alban Hertroys writes: >> I have a number of sysctl=E2=80=99s in /etc/sysctl.conf to tune my = audio output: >>=20 >> hw.snd.default_unit=3D2 >> hw.snd.maxautovchans=3D0 >> dev.pcm.2.play.vchans=3D0 >> dev.pcm.2.bitperfect=3D1 >=20 > This only works by accident because your DSP happens to be switched on > and attached to pcm2 when sysctl.conf is processed during boot. If = you > boot your machine with the DSP switched off or unplugged, you will see > errors during boot because these sysctl nodes do not exist until the = DSP > is turned on and the driver attaches to it. You need to set up devd = to > run the correct sysctl commands (with the correct device unit numbers, > don't assume your DSP is always pcm2!) when your DSP is attached. Those sysctl's happen to be what several posts on the FreeBSD forums = advise for setting up USB DACs. That=E2=80=99s where I got my info when = setting this up a while ago (during 13.1-RELEASE, I=E2=80=99d be a = little hard-pressed to provide URL=E2=80=99s now). Just pointing out the = trap there. Meanwhile, several people here suggested that devd is the way to go = about this. I had actually looked into that a bit, but that seemed to = require a related device node in /dev, and there=E2=80=99s neither one = for pcm nor for uaudio, so I discarded that as not being a viable = option. Perhaps too soon. I=E2=80=99ve been trying a bit, but I=E2=80=99m unfamiliar with = devd.conf, so I got stuck at the point of: notify 100 { match "system" "USB"; match "subsystem" "DEVICE"; match "type" "ATTACH"; match "vendor" "0x152a"; match "product" "0x8750"; action "PCM=3D`sysctl dev.pcm | grep 'Topping D90SE' | cut -d . = -f 3` && sysctl 'hw.snd.default_unit=3D${PCM} = dev.pcm.${PCM}.play.vchans=3D0 dev.pcm.$ }; I can see devd looking to match uaudio0 and pcm2 devices to several = names it knows (probably from other devd confs?), but it doesn=E2=80=99t = seem to match my attempt. Let alone that it got around to attempting to = parse my sh tidbit. Sysctl reports the device as: dev.uaudio.0.%pnpinfo: vendor=3D0x152a product=3D0x8750 devclass=3D0xef = devsubclass=3D0x02 devproto=3D0x01 sernum=3D"" release=3D0x0188 = mode=3Dhost intclass=3D0x01 intsubclass=3D0x01 intprotocol=3D0x20 dev.uaudio.0.%location: bus=3D0 hubaddr=3D5 port=3D4 devaddr=3D6 = interface=3D0 ugen=3Dugen0.6dev.uaudio.0.%driver: uaudio dev.uaudio.0.%desc: Topping D90SE, class 239/2, rev 2.00/1.88, addr 14 dev.uaudio.%parent:=20 Corrections and improvements are welcome. How to use the actual device = name from the event as a variable in grep instead of hard-coding it, for = example. Meanwhile, I have my hopes up for what Christos comes up with. Regards, Alban Hertroys -- Als je de draak wilt steken met iemand, dan helpt het, als die een punthoofd heeft. From nobody Wed Oct 2 21:53:45 2024 X-Original-To: freebsd-stable@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 4XJpV701rbz5Y8jw for ; Wed, 02 Oct 2024 21:53:51 +0000 (UTC) (envelope-from christos@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 4XJpV65wMmz4pkL; Wed, 2 Oct 2024 21:53:50 +0000 (UTC) (envelope-from christos@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1727906030; 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=/m9kJBIni3aqRUq2JCNdkpLpDPsV54xMjQfd5/98nTg=; b=wrlP9R/uBoiVpZuRzfglX7CmlpBuwXywI7q38Ne5lK0xhN81d/GZeGthLTrF+XNzitRvCk Jzyfp6cceqOqgSbXlEUZRsyFdXJG6c9IV4E5KTkVY6VBvj4toZXrVoKHdOycTQ4qfqQsBO X24sSPgAqyeRUo3ZrYGSee9vHXvj0RDiPuosYoKCIehcDXDhxAPFIj0gL9RLjJbVooNghS qvM5fzIr+PPR1x++zeHp0DkFcIukR2X9eF8BhmTn6pB5DlNGFfErsroX1Eit4oEenHzROZ esnXx1bu0UMd+vriVPo2Iew0rkgTwAXoFJbEWB83fOH7wCypAZ9t1gnuCJIt4A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1727906030; 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:dkim-signature; bh=/m9kJBIni3aqRUq2JCNdkpLpDPsV54xMjQfd5/98nTg=; b=YUAT8JSabQ2qoLzbnq5SnEDqphGZkljOf6RHdpKumrc4wU2spSCuCRPZTl2OQQPHswkIHW SeCj32SJvkZ7tXsbuq4akEl5Pyg9A0uOArhzKwJF/ZeIKDuynZFxtFbvsam8krx15uNsuv jiNecR5fk7qP9o1l0741K/1uctNxqw779BhbjylLEh1IIbjtOxM/SblL6wCF1vAuCbyY93 ol3FHIYP5WFw22g6ebrBW5+bC9k/gLhREv64cjwzQL+3w38AYPiI6eZIoHkiHDLUxXUBB8 6/4yebI9vK2ktL9hxvSULqMrwYuYGaQAGG1HO1FUWlg2vi1dsSzmMp6Zf9LVjA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1727906030; a=rsa-sha256; cv=none; b=BzE9RLC2wrbEK5rpdVjRQPzJKSDOiq4MxrW61nIYJjC3S4RxBvSBl1s/qM8+rJLt74KA96 UoBN0YJVkrL/OMBL9gfKG9ijuXA9Lz+nfcnA315r1ltucJP5/lxwAFR81kvyd0A0jsS+nH ctwz2b2qLgcs+qSmwrXcbSHi1IyGALS3tBYVnC7xC8Nb7ich7ghkPWUvZd293C5lDve8RJ edcLUjEop4OnP+7/4OCt1i4C+NIVH0sC91zHlOyu66sSGU1NmHz5E6dymJhG5tKMd6IOAC /p8IWgWiAg/zCyPtGdJ+feYEtd8eMB7thkwSmPmTADdTq/gU3oFLPjBT4416mQ== Received: from margiolis.net (mail.margiolis.net [95.179.159.8]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA512) (Client did not present a certificate) (Authenticated sender: christos/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4XJpV62hCFzWCN; Wed, 2 Oct 2024 21:53:50 +0000 (UTC) (envelope-from christos@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=mail; bh=BefGBl38iixjUXE 6SgG954KX9LvfH5OPL5OBHYbVOmo=; h=in-reply-to:references:subject:cc:to: from:date; d=margiolis.net; b=KFCEKwzLXKYJrMEmp6ZXacQqE6Dni/B6TXK0uK9Y FpVInbE01hnDxaagG/ygV4TRU5cPjbbJqp8MdNQUrrnrStz0lWoBtxBetQLWYc6RJnrzkJ emyIMVhCmK35GgI0+qjC694DOE778FutrynKmZwaaTI9WHc7wnRZUf3+oA1SU= X-Spam-Score: 6.4 / 15 X-Spam-Status: Yes, score=6.400 required=15.000 tests=[ARC_NA=0.000, ASN=0.000, FREEMAIL_ENVRCPT=0.000 FREEMAIL_TO=0.000, FROM_EQ_ENVFROM=0.000, FROM_HAS_DN=0.000 MID_RHS_NOT_FQDN=0.500, MIME_GOOD=-0.100, MIME_TRACE=0.000 NEURAL_SPAM=0.000, RCPT_COUNT_THREE=0.000, RCVD_COUNT_ONE=0.000 RCVD_TLS_ALL=0.000, RCVD_VIA_SMTP_AUTH=0.000, SPAM_FLAG=5.000 SUBJECT_HAS_CURRENCY=1.000, TO_DN_SOME=0.000 TO_MATCH_ENVRCPT_ALL=0.000] Received: from tpad (31-217-175-193.cgn.acro.cosmote.net [31.217.175.193]) by margiolis.net (OpenSMTPD) with ESMTPSA id 7884f06d (TLSv1.3:AEAD-AES256-GCM-SHA384:256:NO); Wed, 2 Oct 2024 21:53:47 +0000 (UTC) Date: Thu, 3 Oct 2024 00:53:45 +0300 From: Christos Margiolis To: Alban Hertroys Cc: Dag-Erling =?utf-8?B?U23DuHJncmF2?= , freebsd-stable@freebsd.org Subject: Re: uaudio device re-attach and persisting dev.pcm.$pcm.bitperfect sysctl Message-ID: References: <86ploiwxw8.fsf@ltc.des.dev> <8745F9FB-9CC1-476C-9445-DC0A7A76165F@gmail.com> List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-stable@freebsd.org Sender: owner-freebsd-stable@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <8745F9FB-9CC1-476C-9445-DC0A7A76165F@gmail.com> Alban Hertroys wrote: > Meanwhile, several people here suggested that devd is the way to go > about this. I had actually looked into that a bit, but that seemed to > require a related device node in /dev, and there’s neither one for pcm > nor for uaudio, so I discarded that as not being a viable option. > Perhaps too soon. Audio device nodes are /dev/dspX, where X is the unit number, which has a 1-1 relation with the pcmX unit number, so pcm2's device node is /dev/dsp2. To clarify some more things, the sound subsystem roughly consists of the following layers: - The sound(4) layer, which is the highest-level layer, and among other things, is responsible for mixing channels, doing conversions, providing some generic functions for sound drivers to use, as well as providing a uniform device interface (i.e pcmX). - The device driver (e.g snd_uaudio(4), snd_hda(4), ...) layer, which is responsible for actually communicating with the sound card. You could visualize it as follows: some usb card -> uaudio0 -> pcm0 some other usb card -> uaudio1 -> pcm1 some intel card -> hdaa0 -> pcm2 > > [...] > > I can see devd looking to match uaudio0 and pcm2 devices to several > names it knows (probably from other devd confs?), but it doesn’t seem > to match my attempt. Let alone that it got around to attempting to > parse my sh tidbit. So in your case, "pcm2" is a generic name given to the device by sound(4) and "uaudio0" is the name of the driver this device is using, but the actual device node is /dev/dsp2. What I think is confusing is that sound(4) names devices as "pcm", but creates the nodes as "dsp"... Maybe I should propose a patch to get rid of this scheme, and simply name them everywhere as either "pcm", "dsp", or something else like "snd". Christos From nobody Thu Oct 3 14:10:16 2024 X-Original-To: freebsd-stable@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 4XKD901w4cz5YN3g for ; Thu, 03 Oct 2024 14:10:28 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (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 4XKD8z40gpz4WW5; Thu, 3 Oct 2024 14:10:26 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Authentication-Results: mx1.freebsd.org; none Received: from kalamity.joker.local (123-1-21-232.area1b.commufa.jp [123.1.21.232]) (authenticated bits=0) by www121.sakura.ne.jp (8.17.1/8.17.1/[SAKURA-WEB]/20201212) with ESMTPA id 493EAG40085648; Thu, 3 Oct 2024 23:10:16 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dec.sakura.ne.jp; s=s2405; t=1727964617; bh=2pLgU2Y9TdZpptTJIXkwiY/O8U8daU+HABNPb+BMnSs=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=FA1VO6IRAmI4FBJV7tZ+LNkHZPA/z+dP2bAAmvr69d5x6NOl+jNMICUuN0IQlvsyN FzcnAVB3o8i22yf9jYa2WmZ5lhQwzPrEKLIigtjFZYyf+R4/aSsCI1b6sw/aQ8LmkZ ZpIhePD9hPdTpjF4Y4yBvU39Jri0Af7Vw0/pM+t4= Date: Thu, 3 Oct 2024 23:10:16 +0900 From: Tomoaki AOKI To: Christos Margiolis Cc: Alban Hertroys , Dag-Erling =?UTF-8?B?U23DuHJncmF2?= , freebsd-stable@freebsd.org Subject: Re: uaudio device re-attach and persisting dev.pcm.$pcm.bitperfect sysctl Message-Id: <20241003231016.47f74f2d2ada7b4a76d065dd@dec.sakura.ne.jp> In-Reply-To: References: <86ploiwxw8.fsf@ltc.des.dev> <8745F9FB-9CC1-476C-9445-DC0A7A76165F@gmail.com> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.1) List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-stable@freebsd.org Sender: owner-freebsd-stable@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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:7684, ipnet:153.125.128.0/18, country:JP] X-Rspamd-Queue-Id: 4XKD8z40gpz4WW5 X-Spamd-Bar: ---- On Thu, 3 Oct 2024 00:53:45 +0300 Christos Margiolis wrote: > Alban Hertroys wrote: > > Meanwhile, several people here suggested that devd is the way to go > > about this. I had actually looked into that a bit, but that seemed to > > require a related device node in /dev, and there’s neither one for pcm > > nor for uaudio, so I discarded that as not being a viable option. > > Perhaps too soon. > > Audio device nodes are /dev/dspX, where X is the unit number, which has > a 1-1 relation with the pcmX unit number, so pcm2's device node is > /dev/dsp2. > > To clarify some more things, the sound subsystem roughly consists of the > following layers: > - The sound(4) layer, which is the highest-level layer, and among other > things, is responsible for mixing channels, doing conversions, > providing some generic functions for sound drivers to use, as well as > providing a uniform device interface (i.e pcmX). > - The device driver (e.g snd_uaudio(4), snd_hda(4), ...) layer, which is > responsible for actually communicating with the sound card. > > You could visualize it as follows: > > some usb card -> uaudio0 -> pcm0 > some other usb card -> uaudio1 -> pcm1 > some intel card -> hdaa0 -> pcm2 > > > > > [...] > > > > I can see devd looking to match uaudio0 and pcm2 devices to several > > names it knows (probably from other devd confs?), but it doesn’t seem > > to match my attempt. Let alone that it got around to attempting to > > parse my sh tidbit. > > So in your case, "pcm2" is a generic name given to the device by > sound(4) and "uaudio0" is the name of the driver this device is using, > but the actual device node is /dev/dsp2. > > What I think is confusing is that sound(4) names devices as "pcm", but > creates the nodes as "dsp"... Maybe I should propose a patch to get rid > of this scheme, and simply name them everywhere as either "pcm", "dsp", > or something else like "snd". > > Christos Maybe what newbies want would be: *Currently active audio device is always seen as exactly the same, without device number or something. *Basically newly attached "physical" device is always preferred. For example: If a USB audio is plugged and powered on, it is preferred. After that, if a headphone is plugged into the connector, the headphone is automagically selected and other outputs are automatically muted. After that, if optical SPDIF is connected, mute headphone and route output to SPDIF. When the SPDIF plug is disconnected, automatically fall back to headphone. If the headphone is plugged out before SPDIF, fall back to USB, and more, if USB is not available ATM, fall back to PC speaker. Cannot point into specific posts, but I see screams like "Hey, I cannot hear audio output from headphone. How can I do it?!" in Forums. And currently the answers should be quite specific with the questioner's environment (including hardware quirks) and hard to answer. Would be complexed to implement (automate). But parts of those is possible by virtual_oss, by letting it create /dev/dsp, without number. And ports supporting base OSS to default to unnumbered device. My basic assumption is that virtual_oss would be worth incorporated in base at some time in the future. Regards. -- Tomoaki AOKI From nobody Thu Oct 3 14:30:57 2024 X-Original-To: freebsd-stable@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 4XKDcl6CY2z5YPDp for ; Thu, 03 Oct 2024 14:31:03 +0000 (UTC) (envelope-from christos@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 4XKDcl5kYHz4Ypy; Thu, 3 Oct 2024 14:31:03 +0000 (UTC) (envelope-from christos@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1727965863; 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=N/HfE9GKcrzLhVgSyI/YoyuvWwm2M2ycOW0bZLB5kRY=; b=KrhZ/zDubyrgB2FhrNPGShho7k6XTvMbEXxKJtVs4TrZ/kbomsFcQQ+Uz1q2dg1UuI+Znf V29IwkwrFpcz6cEsQRK1k4K1Qs9RNfeDhHPJ+MmAbECetPGU7rEA33D1JE6wj6YLBXYQOF yoA99B17rOxvMj+WKzmWHWkB1uT/r//j12i8+WdmS+qGDkqKauxIBFS9SSHNBwaLpC/Qjc 9uV/82/+ysfSri8E0hyPS6aQYBKhsD9B4r6T463niN5TVv1w+lTlho9/jHCVMUA5dr2TEg 7PeM46HGrE+hlDPUnB6nh2mDN4ph1S4ob5vVoiEdtQuqtQOsDFuOX7aI7cVmVw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1727965863; 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:dkim-signature; bh=N/HfE9GKcrzLhVgSyI/YoyuvWwm2M2ycOW0bZLB5kRY=; b=rXrBKR9JinflEhVNh/t7glILLx2uC/EA7/UaD4jXkDj6psTYDZ7PDJG/29QeEO03MTHbvh 2SgGhaYwOmDNnkDkZF1u9Wk7UHUbHJr8lgzZiucPn+JcSYoQ4FymTHYkBfXXTq0jDW5RCO bJRr9qLlcFLx0q9XJr4gh5KlJ/rrm6nVfgZsOxUmFujGK4S+A6BrNpHCDXpJ6ilHEk681i /ebUAfOrOR0uy9o+SfPeE4lRfioE/xgu2CKW4kXieC0Uj5RzWDbboJVOjJ0mr/URQUok7O ESV47qbm/g+MonVIlmab/gDFn0KgqK89lFuOLL+bXTOQoHijgxQXCTOm94ey5w== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1727965863; a=rsa-sha256; cv=none; b=eRcIYX1Tug/dteSTqgzkEDLKywLV+krb+o1tK45usxq0VxH4Nj8RJ2fTLqeQCSR6uVb1UB ucy15bdFeNkWwz/2KzDSIV6DgfMg1AEnG6dA6pa9HENY6TkclFLKgK9z6hN3jBzHrSdoO2 CPjRpOWu+o2MhcBylxV9nJWkYa2V3k34LTe860sNvAVr9wtrBHEeCFfJ7HyCbvqTrmXubN I1/FLH77ZejP5suTxcMesyMgby3nVnqWYd08JlMNouA9YAdVL3tmkq9XsrNSChFkZX/EAh 3YYQmARjWBopluf+bcKLwvEytlMmX7lNq81MLE7iZUO5vcCMp+7B33horwYLBw== Received: from margiolis.net (mail.margiolis.net [95.179.159.8]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA512) (Client did not present a certificate) (Authenticated sender: christos/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4XKDcl1GVbz15T8; Thu, 3 Oct 2024 14:31:03 +0000 (UTC) (envelope-from christos@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=mail; bh=QHBW2jZYKDXq7HK jig5+m+7AFrX/522SvuSwaUhSsAc=; h=in-reply-to:references:subject:cc:to: from:date; d=margiolis.net; b=Y5H78fIs5BuBkk0ZGYn+NHePwf6+E5jXuNQT6u0o DLYf9Hn3jhGIAN2MKncSlUnzRV7QF1boKNP7W3ap4Q9AT4NBMsVZZqeikWDvl7z3vAbYpq kvAvgklFnvnQcWc/inWTpsdAK72q1Ax1zFGCc0zxHAX8XUNVQYfGqnoSHQspk= X-Spam-Score: 6.4 / 15 X-Spam-Status: Yes, score=6.400 required=15.000 tests=[ARC_NA=0.000, ASN=0.000, FREEMAIL_CC=0.000 FREEMAIL_ENVRCPT=0.000, FROM_EQ_ENVFROM=0.000, FROM_HAS_DN=0.000 MID_RHS_NOT_FQDN=0.500, MIME_GOOD=-0.100, MIME_TRACE=0.000 NEURAL_SPAM=0.000, RCPT_COUNT_FIVE=0.000, RCVD_COUNT_ONE=0.000 RCVD_TLS_ALL=0.000, RCVD_VIA_SMTP_AUTH=0.000, SPAM_FLAG=5.000 SUBJECT_HAS_CURRENCY=1.000, TO_DN_SOME=0.000 TO_MATCH_ENVRCPT_ALL=0.000] Received: from tpad (31-217-175-193.cgn.acro.cosmote.net [31.217.175.193]) by margiolis.net (OpenSMTPD) with ESMTPSA id 0c773225 (TLSv1.3:AEAD-AES256-GCM-SHA384:256:NO); Thu, 3 Oct 2024 14:30:59 +0000 (UTC) Date: Thu, 3 Oct 2024 17:30:57 +0300 From: Christos Margiolis To: Tomoaki AOKI Cc: Christos Margiolis , Alban Hertroys , Dag-Erling =?utf-8?B?U23DuHJncmF2?= , freebsd-stable@freebsd.org Subject: Re: uaudio device re-attach and persisting dev.pcm.$pcm.bitperfect sysctl Message-ID: References: <86ploiwxw8.fsf@ltc.des.dev> <8745F9FB-9CC1-476C-9445-DC0A7A76165F@gmail.com> <20241003231016.47f74f2d2ada7b4a76d065dd@dec.sakura.ne.jp> List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-stable@freebsd.org Sender: owner-freebsd-stable@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20241003231016.47f74f2d2ada7b4a76d065dd@dec.sakura.ne.jp> Hello Tomasz, Tomoaki AOKI wrote: > Maybe what newbies want would be: > *Currently active audio device is always seen as exactly the same, > without device number or something. What do you mean exactly? > *Basically newly attached "physical" device is always preferred. > For example: > If a USB audio is plugged and powered on, it is preferred. > After that, if a headphone is plugged into the connector, > the headphone is automagically selected and other outputs > are automatically muted. > After that, if optical SPDIF is connected, mute headphone and > route output to SPDIF. > When the SPDIF plug is disconnected, automatically fall back to > headphone. > If the headphone is plugged out before SPDIF, fall back to USB, > and more, if USB is not available ATM, fall back to PC speaker. > > Cannot point into specific posts, but I see screams like "Hey, I > cannot hear audio output from headphone. How can I do it?!" in Forums. > And currently the answers should be quite specific with the > questioner's environment (including hardware quirks) and hard to > answer. The headphone issue is present only in snd_hda(4), and it's because many HDA manufacturers assign non-standard mappings to the headphone and jack pins, so the driver needs to be manually patched in order to support them. That being said, I am planning to attempt to automate the method with which we tell what the correct mappings should be. If this attempt works, it will most likely still not solve all cases, but might simplify things a bit. > Would be complexed to implement (automate). But parts of those is > possible by virtual_oss, by letting it create /dev/dsp, without number. > And ports supporting base OSS to default to unnumbered device. > > My basic assumption is that virtual_oss would be worth incorporated > in base at some time in the future. That's in the plans already. The only obstacle at the moment is that virutal_oss uses third party libraries. Christos From nobody Thu Oct 3 16:57:44 2024 X-Original-To: freebsd-stable@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 4XKHtC4yBfz5YY7f for ; Thu, 03 Oct 2024 16:57:55 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (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 4XKHtC0WDPz4r5L; Thu, 3 Oct 2024 16:57:54 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Authentication-Results: mx1.freebsd.org; none Received: from kalamity.joker.local (123-1-21-232.area1b.commufa.jp [123.1.21.232]) (authenticated bits=0) by www121.sakura.ne.jp (8.17.1/8.17.1/[SAKURA-WEB]/20201212) with ESMTPA id 493GviIK019315; Fri, 4 Oct 2024 01:57:49 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dec.sakura.ne.jp; s=s2405; t=1727974670; bh=uToN2whX0dqnohHNNC5M9rtBOPGX2hN7edZ7ZuxqIms=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=jH0pZhCmnJrjQFPqF6TqBUtyYZEgNlinXvFgR4RfyXvmawWro2QKB98/Sr3G4WUm9 ou9htDVT8GKuT50mD+mx6QmmFS+Nt6MLFCkA39r/q0MpuvDUgfU4/HcrMxUFyUYEMa VedZuD5JZEXGTWTTuFSZLqYBPuPKLUPWdTEAa0FM= Date: Fri, 4 Oct 2024 01:57:44 +0900 From: Tomoaki AOKI To: Christos Margiolis Cc: Alban Hertroys , Dag-Erling =?UTF-8?B?U23DuHJncmF2?= , freebsd-stable@freebsd.org Subject: Re: uaudio device re-attach and persisting dev.pcm.$pcm.bitperfect sysctl Message-Id: <20241004015744.6a735e6e3c041ac9d94df44f@dec.sakura.ne.jp> In-Reply-To: References: <86ploiwxw8.fsf@ltc.des.dev> <8745F9FB-9CC1-476C-9445-DC0A7A76165F@gmail.com> <20241003231016.47f74f2d2ada7b4a76d065dd@dec.sakura.ne.jp> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.1) List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-stable@freebsd.org Sender: owner-freebsd-stable@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:7684, ipnet:153.125.128.0/18, country:JP] X-Rspamd-Queue-Id: 4XKHtC0WDPz4r5L X-Spamd-Bar: ---- On Thu, 3 Oct 2024 17:30:57 +0300 Christos Margiolis wrote: > Hello Tomasz, > > Tomoaki AOKI wrote: > > Maybe what newbies want would be: > > *Currently active audio device is always seen as exactly the same, > > without device number or something. > > What do you mean exactly? Assuming there are 2 audio outoputs via HDMI as /dev/pcm0 and /dev/pcm1 1 audio output via PC speaker (i.e., HDA) as /dev/pcm2 1 audio output via headphone connetor as /dev/pcm3 at start, if snddetect_enable="YES" is set on /etc/rc.conf[.local], the last /dev/pcm3 would be chosen as default. If not, IIRC (not even tried for a long time), /dev/pcm0 was the default. What I meant is "if /dev/pcm always automatically points to configured default, configuring /dev/pcm as the only audio device for audio and multimedia apps which directly supports base OSS on ports tree would be easiest to use. > > *Basically newly attached "physical" device is always preferred. > > For example: > > If a USB audio is plugged and powered on, it is preferred. > > After that, if a headphone is plugged into the connector, > > the headphone is automagically selected and other outputs > > are automatically muted. > > After that, if optical SPDIF is connected, mute headphone and > > route output to SPDIF. > > When the SPDIF plug is disconnected, automatically fall back to > > headphone. > > If the headphone is plugged out before SPDIF, fall back to USB, > > and more, if USB is not available ATM, fall back to PC speaker. > > > > Cannot point into specific posts, but I see screams like "Hey, I > > cannot hear audio output from headphone. How can I do it?!" in Forums. > > And currently the answers should be quite specific with the > > questioner's environment (including hardware quirks) and hard to > > answer. > > The headphone issue is present only in snd_hda(4), and it's because many > HDA manufacturers assign non-standard mappings to the headphone and jack > pins, so the driver needs to be manually patched in order to support > them. That being said, I am planning to attempt to automate the method > with which we tell what the correct mappings should be. If this attempt > works, it will most likely still not solve all cases, but might simplify > things a bit. Exactly. But unfortunately, HDA seems to be the majority now. Don't know how other OS'es are resolving the "quirks". If the headphone jack is made like as was in old radios and/or TVs, include physical switch in itself, the problem cannot happen. (As when internal switch in the jack is pushed by the phone plug, the electric circuit to speaker is opened (shut down) and to the phone is closed (functional) and when unplugged, the switch does the reverse. Of course, it is not at all good for sound qualitiy.) People who doesn't know the HDA problem (in their physical impleentations) would expect the headphone jack to work as above. And so would be as anything plugged/unplugged after boot. Automating "as natural human naturally expect" selection/routing would help it, but if active device name always switches on each auto selection makes users confused. So if fixed device name like /dev/pcm (without number) always routed to active default device, it would be helpful. > > Would be complexed to implement (automate). But parts of those is > > possible by virtual_oss, by letting it create /dev/dsp, without number. > > And ports supporting base OSS to default to unnumbered device. > > > > My basic assumption is that virtual_oss would be worth incorporated > > in base at some time in the future. > > That's in the plans already. The only obstacle at the moment is that > virutal_oss uses third party libraries. > > Christos Glad to know it! Thanks in advance. -- Tomoaki AOKI From nobody Fri Oct 4 15:24:43 2024 X-Original-To: freebsd-stable@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 4XKsmQ6HxNz5Xw7C for ; Fri, 04 Oct 2024 15:24:54 +0000 (UTC) (envelope-from hlh@restart.be) Received: from tignes.restart.be (tignes.restart.be [37.187.123.11]) (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 (2048 bits) client-digest SHA256) (Client CN "tignes.restart.be", Issuer "CA master" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4XKsmQ0Mx4z58Kt for ; Fri, 4 Oct 2024 15:24:54 +0000 (UTC) (envelope-from hlh@restart.be) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=restart.be header.s=tignes header.b=Wl1sr5Cg; spf=pass (mx1.freebsd.org: domain of hlh@restart.be designates 37.187.123.11 as permitted sender) smtp.mailfrom=hlh@restart.be; dmarc=pass (policy=reject) header.from=restart.be DKIM-Filter: OpenDKIM Filter v2.10.3 tignes.restart.be 4XKsmF2RwnzBQ DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=restart.be; s=tignes; t=1728055485; bh=K0lyrroVULNa2/vosqfY0mCIjSknx3lWMt4GteWgiJ8=; h=Date:To:From:Subject; z=Date:=20Fri,=204=20Oct=202024=2017:24:43=20+0200|To:=20FreeBSD-ST ABLE=20Mailing=20List=20|From:=20Henri =20Hennebert=20|Subject:=2014.1-STABE=20-=20zfs-2. 2.6=20sluggish=20on=20arm64=20and=20arc_prune=20at=2099%=20during= 0D=0A=20poudriere; b=Wl1sr5Cgqq6CMkxv+600wTgyEbGSVWVcUr6/OyhEzVHUllKM728CbkIOydBUC9JwG xQJ+W0+2Ijp0+fGo9LNa7HJHs6Y7mAiGQYhq7G8UFjpDgFuM8+BP5U/lO3lkLMLmIo +kY0fioQNv7YvA5N0QZC+NLNmMYm2yAgZlGKVc/sOECngbc5xBSExEpZOVjNXlzbqh 73XnLXKo3y0G7epi8d/0iHinn6Es6auJGCxN725XdfPT2PqwTcvWImIrV1HQ1gFgyK Ok707Tc8mZM056BHauN/upJLIqXja9/rw68kvh3mexdrKdmJA9uQ28hsVSrVn2TXR3 TmkEvDPgUOWIw== Received: from restart.be (norquay.tunnel.bel [192.168.25.127]) (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 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.restart.be", Issuer "CA master" (verified OK)) by tignes.restart.be (Postfix) with ESMTPS id 4XKsmF2RwnzBQ for ; Fri, 04 Oct 2024 17:24:45 +0200 (CEST) Received: from morzine.restart.be (morzine.restart.be [IPv6:2001:41d0:a:f40b:1:1:0:1]) (authenticated bits=0) by restart.be (8.18.1/8.18.1) with ESMTPSA id 494FOhWi095131 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=OK) for ; Fri, 4 Oct 2024 17:24:43 +0200 (CEST) (envelope-from hlh@restart.be) Message-ID: <0be81d87-3e37-4f9a-b87d-a44e915c49bb@restart.be> Date: Fri, 4 Oct 2024 17:24:43 +0200 List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-stable@freebsd.org Sender: owner-freebsd-stable@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: FreeBSD-STABLE Mailing List Content-Language: en-US From: Henri Hennebert Subject: 14.1-STABE - zfs-2.2.6 sluggish on arm64 and arc_prune at 99% during poudriere Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[restart.be,reject]; R_DKIM_ALLOW(-0.20)[restart.be:s=tignes]; R_SPF_ALLOW(-0.20)[+ip4:37.187.123.11/32]; MIME_GOOD(-0.10)[text/plain]; XM_UA_NO_VERSION(0.01)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:16276, ipnet:37.187.0.0/16, country:FR]; RCPT_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_ALL(0.00)[]; TO_DN_ALL(0.00)[]; ARC_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; PREVIOUSLY_DELIVERED(0.00)[freebsd-stable@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-stable@freebsd.org]; DKIM_TRACE(0.00)[restart.be:+] X-Rspamd-Queue-Id: 4XKsmQ0Mx4z58Kt X-Spamd-Bar: --- Hello, Since I upgrade my rockpro64 to FreeBSD keystone.lab.bel 14.1-STABLE FreeBSD 14.1-STABLE #0 stable/14-n268744-79c34d704f31: Sun Sep 29 13:38:10 CEST 2024 root@keystone.lab.bel:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64 when I start cpuset -c -l 4-5 poudriere bulk -j 14aarch64 -z pine64 -f /usr/local/poudriere/pine64-pkglst everything is running at least 2 to 3 times slower than under FreeBSD 14.1-STABLE #0 stable/14-n267830-339b47f01985 Some build repeatedly fail with eg : pkg-static: Fail to chmod /afm/public/nanumtype1/nanummjbd7.afm:Bad file descriptor previously this fail was rather uncommon. Moreover at soon as poudriere bulk start top -SH show: last pid: 79185; load averages: 3.53, 3.72, 3.85 up 5+01:17:19 17:14:19 502 threads: 13 running, 463 sleeping, 26 waiting CPU: 0.1% user, 0.2% nice, 38.8% system, 0.1% interrupt, 60.9% idle Mem: 77M Active, 422M Inact, 4112K Laundry, 1318M Wired, 1987M Free ARC: 676M Total, 284M MFU, 66M MRU, 11M Anon, 14M Header, 301M Other 69M Compressed, 294M Uncompressed, 4.25:1 Ratio Swap: 8192M Total, 35M Used, 8157M Free PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 0 root -8 - 0B 2432K CPU1 1 96.8H 99.61% kernel{arc_prune} 11 root 187 ki31 0B 96K RUN 0 98.0H 98.76% idle{idle: cpu0} 11 root 187 ki31 0B 96K RUN 1 94.6H 97.63% idle{idle: cpu1} 26388 root 135 4 110M 78M CPU5 5 82:53 94.30% bsdtar 11 root 187 ki31 0B 96K RUN 3 91.9H 79.92% idle{idle: cpu3} 11 root 187 ki31 0B 96K RUN 2 98.8H 61.87% idle{idle: cpu2} 11 root 187 ki31 0B 96K RUN 5 26.5H 27.09% idle{idle: cpu5} ...... arc_prone running at 99% on one of the CPU all the time, note that 1987M Free. Does anyone encounter this sort of problems? Thanks for your time Henri From nobody Sat Oct 5 12:01:23 2024 X-Original-To: freebsd-stable@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 4XLPCP2vxyz5YD0h for ; Sat, 05 Oct 2024 12:01:37 +0000 (UTC) (envelope-from haramrae@gmail.com) Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [IPv6:2a00:1450:4864:20::629]) (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 4XLPCN5fStz4tdn; Sat, 5 Oct 2024 12:01:36 +0000 (UTC) (envelope-from haramrae@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=BCO53Xo3; spf=pass (mx1.freebsd.org: domain of haramrae@gmail.com designates 2a00:1450:4864:20::629 as permitted sender) smtp.mailfrom=haramrae@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-ej1-x629.google.com with SMTP id a640c23a62f3a-a99409f1cc7so620766b.2; Sat, 05 Oct 2024 05:01:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1728129695; x=1728734495; darn=freebsd.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=B+ZA9Fgv7L9X4/nWwkjq33og8YI8jf6TY0F+zWZX22E=; b=BCO53Xo36/wSNYSYuOjSBIAR8xGfmH0NneKYEDE9NVL6Ji96ILde+3HdRSoQsEG4rW F8Yb0MVD+4xwUjmvDBOvwE7zaZpp66r7cm4md+TBLE4XzcilX4o7j+hZQFGn2CbXlfk1 Wl/ZWLZojL2PAdL6KZQ7/Db4O2PfF3qbwPYAfjze1YqQGe/Rs8suTIO9JOk+fUlogJAv UDiJ6QBoJhoE2KOiGx+FwJmpAUgcVXXc7mDJPMeu/adU2aYC9XEoKqK9LS817l1+54pJ wh/nNJEFaSSY5Lrs3Gq7frhT4Bam+FKmpXd/yL+MELtni5NnTuCIrICWapBiPUFpHLWz hQzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1728129695; x=1728734495; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=B+ZA9Fgv7L9X4/nWwkjq33og8YI8jf6TY0F+zWZX22E=; b=pE9GzY5vA4uwMbYUNNbwlZP5Mpc1Hn8ZMc71FfOcIMSXyk//8YsUFNhMJgqFXHhC9q 2i0s1WD7WdDYFjM159xOxziReTOG7Lk6idzFzxxhnLrf81WiAW0SKpEcWlXslCrSSJqN 7T3m+F18bokiwyA7ZCpRJxPTbYtfztNIUeUGEOjsoqy2/McnJIWu/4H0Cu66o8FAW+c0 EurWCdwEDT0fXFU1LS9MB9+wdghPO2+EPvl0/QPutzJ/+n5aqjw3anpzRgMTpPzdRCjI 26Fwnmjaxb3GnxOjnThzS0/3NLDGOZ4QMmfaB548yctDunDgyU0e0PPIZ83A4+e4/E9A Wivg== X-Forwarded-Encrypted: i=1; AJvYcCVjMw+U26SnZjJNJmiQPI3OMIVgCHrjskA4wGq9tFjgyP5vlQPWQN0SiVSvgcS3aGOC2x6kGHQxj9CFGc3HfA==@freebsd.org X-Gm-Message-State: AOJu0YyHTmC+NMd4CKvMpj7Cpdl+ubwdEhTbwXk+sY5RgGAr1pqSSJR5 gNVossUeM/KfPSs199I28p/Lt8ex0UrzrmINmY24jYg55vH5vCasoyLeJQ== X-Google-Smtp-Source: AGHT+IG3xZf6GF7f+XIzjF7vOIWOdeKEb3uhD69cxiE10aMb2MRjdlkflVuEB+iVEAUSMdeZjRfqlA== X-Received: by 2002:a17:907:9805:b0:a90:34ba:506e with SMTP id a640c23a62f3a-a991bd71df3mr282238866b.8.1728129694586; Sat, 05 Oct 2024 05:01:34 -0700 (PDT) Received: from smtpclient.apple ([188.212.112.125]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a992e7df993sm123843766b.194.2024.10.05.05.01.33 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 05 Oct 2024 05:01:33 -0700 (PDT) Content-Type: text/plain; charset=utf-8 List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-stable@freebsd.org Sender: owner-freebsd-stable@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3818.100.11.1.3\)) Subject: Re: uaudio device re-attach and persisting dev.pcm.$pcm.bitperfect sysctl From: Alban Hertroys In-Reply-To: Date: Sat, 5 Oct 2024 14:01:23 +0200 Cc: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= , freebsd-stable@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <8F8158B8-4D78-4A17-90B7-659ECB9988B5@gmail.com> References: <86ploiwxw8.fsf@ltc.des.dev> <8745F9FB-9CC1-476C-9445-DC0A7A76165F@gmail.com> To: Christos Margiolis X-Mailer: Apple Mail (2.3818.100.11.1.3) X-Spamd-Result: default: False [-2.08 / 15.00]; SUBJECT_HAS_CURRENCY(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.93)[-0.928]; NEURAL_HAM_MEDIUM(-0.66)[-0.656]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; MIME_GOOD(-0.10)[text/plain]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MLMMJ_DEST(0.00)[freebsd-stable@freebsd.org]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::629:from] X-Rspamd-Queue-Id: 4XLPCN5fStz4tdn X-Spamd-Bar: -- > On 2 Oct 2024, at 23:53, Christos Margiolis = wrote: >=20 > Alban Hertroys wrote: >> Meanwhile, several people here suggested that devd is the way to go >> about this. I had actually looked into that a bit, but that seemed to >> require a related device node in /dev, and there=E2=80=99s neither = one for pcm >> nor for uaudio, so I discarded that as not being a viable option. >> Perhaps too soon. >=20 > Audio device nodes are /dev/dspX, where X is the unit number, which = has > a 1-1 relation with the pcmX unit number, so pcm2's device node is > /dev/dsp2. Doh! I knew that, just didn=E2=80=99t realise it while writing that devd = config. I got it working now. Here=E2=80=99s what I came up with: > cat /usr/local/etc/devd/uaudio.conf notify 100 { match "system" "USB"; match "subsystem" "DEVICE"; match "type" "ATTACH"; match "vendor" "0x152a"; match "product" "0x8750"; action "/usr/bin/touch /var/run/usb.0x152a.0x8750"; }; notify 100 { match "system" "USB"; match "subsystem" "DEVICE"; match "type" "DETACH"; match "vendor" "0x152a"; match "product" "0x8750"; action "/bin/rm -f /var/run/usb.0x152a.0x8750"; }; notify 100 { match "system" "DEVFS"; match "subsystem" "CDEV"; match "type" "CREATE"; match "cdev" "dsp[0-9]"; action "test -f /var/run/usb.0x152a.0x8750 && \ PCM=3D`echo $cdev | sed 's@^dsp@@'` && \ sysctl hw.snd.default_unit=3D${PCM} \ dev.pcm.${PCM}.play.vchans=3D0 \ dev.pcm.${PCM}.bitperfect=3D1"; }; As you can see, I build in a check that it=E2=80=99s the correct device = before starting to set sysctl=E2=80=99s, by checking against a file = created in /var/run. I=E2=80=99m not too enthusiastic about that = solution=E2=80=A6 Better suggestions are welcome. It would be nice if I could set a variable in the USB ATTACH and = =E2=80=98match=E2=80=99 that in the CDEV CREATE step to filter the rule, = or something like that. Originally I tried checking for the device using: test "`sysctl -n dev.pcm.${PCM}.%desc`" =3D 'Topping D90SE=E2=80=99= , but that statement seems to require the double-quotes for test to = accept it, which conflict with the double-quotes of the action string. I = couldn=E2=80=99t find a way to escape those inner quotes. So that=E2=80=99= s another issue I ran into, although approaches to use the USB attach = event for matching the dsp device to the usb device are clearly superior = to reading out a sysctl that=E2=80=99s an effect of it.=20 Additionally, I noticed that other people also use sed or similar to cut = the device number off the cdev variable in their devd configs. That = would have been a convenient variable to have available by default, I = think. I mean, obviously it=E2=80=99s cool that we can show off how good we are = at looking up sed expressions on Google, but as a data engineer I = can=E2=80=99t help but feel that the data that we need for these configs = could be easier to get at. All in all, I got it working, thanks to the help here. Regards, Alban Hertroys -- There is always an exception to always. From nobody Sun Oct 6 08:55:27 2024 X-Original-To: freebsd-stable@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 4XLx292ZFSz5YWXB for ; Sun, 06 Oct 2024 08:55:29 +0000 (UTC) (envelope-from des@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 4XLx2925XDz4cnN; Sun, 6 Oct 2024 08:55:29 +0000 (UTC) (envelope-from des@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1728204929; 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=N4wWk7iP5xmOUlELqDwWrUygdX/xT5YCwgj1yGfMzoY=; b=wmH5DIguWjoIUkYfFyFk65HmGtIMjzr3413WOhyDSAjYHU2iI98lj1ZiYHZqXQ6Gd6sSrG qqqoPlaqbaD6WgqhrSIeNIMFx0FNgyto/vkwMJAhZ1oYDqDQ9ZxXNEMHai3C2c7V0uw/3D /fwEJKSYxVn9xYGPfMNDg3x9x9l/McAFZAUm5Etph049uy04O97FGDSIe6Z6eRdntjn8sl jm5qV7iol2TGJbAikouGk0t8fssiVqpC67ruogJx5IO6I3MKNjQJ2wi/sRyVDj5dT/IPOY AiAC5hQ72vO9FdaDdX/IUNFzXOqjCIayM9EiDe7+0gZVBZ9vGGrSyzVKyCYjgw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1728204929; 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=N4wWk7iP5xmOUlELqDwWrUygdX/xT5YCwgj1yGfMzoY=; b=SH5XTBc6jWeHFaaL9dw75iX2gEEBgweDa3Gsz0bdgbc7xxRoPQc8YXlfRgWm7L8EI0x4eU xWOgcxxDw6eCJKIx4G0F0KZNd9y0Za9/d4DxXq0Gb4OzhDqMTiqso+62j1DXBK3hD21Jtd n79HVmb42hQ4giNfTwSex4A57i/05osNT6pxzYDL3B74plgzxq2F4cIXW1rnELLjgZXXJI RwQtVWxyrZHnVkzEkLEKuNOz9L4MuqPo1YIIhSA/1StGazLqgDKGvlNU3dVE6Q56BtupdH j0QyBaXAB5nKyJuLesb/YBVqX6QgT7qtb8VF0oNAgGtnIutxcAn6qqq+Fx9aSQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1728204929; a=rsa-sha256; cv=none; b=Gje6JK5DtYrBosEyhx0+dbpkWBs848rj/DtsQQ6DmFPqWpNFp+RjqOkYjtZRvCbXzwyhcA CVcN1dpn8LBqan4rw+4sdPWtys07TK1dm4thP5o2fGRzHqQ2a6DS+cCgfQiroKuU8jfhI5 II/rEnnxtU0eUqOaV4Y7YWMjSVtBFKKmUu3n+bkdVetiCQc9S4J0PLgfsQbtjthkNduHNQ xqlUOcqQZ8kRLdzMAyit94pr0b6haO5H+Y4P37NwrdGZMK8+q9sEbJ+RlmNjPQMLw63bNk S8+dcNvVWSqOnqoUC1GOwLxnNqwN53SFAlwtR7rmz2sbhWk9BSlxjDbrAX2Vfg== Received: from ltc.des.dev (unknown [91.174.26.112]) (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) (Authenticated sender: des) by smtp.freebsd.org (Postfix) with ESMTPSA id 4XLx290sLqzFYN; Sun, 6 Oct 2024 08:55:29 +0000 (UTC) (envelope-from des@freebsd.org) Received: by ltc.des.dev (Postfix, from userid 1001) id 3913DBF52D; Sun, 06 Oct 2024 10:55:27 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Alban Hertroys Cc: Christos Margiolis , freebsd-stable@freebsd.org Subject: Re: uaudio device re-attach and persisting dev.pcm.$pcm.bitperfect sysctl In-Reply-To: <8F8158B8-4D78-4A17-90B7-659ECB9988B5@gmail.com> (Alban Hertroys's message of "Sat, 5 Oct 2024 14:01:23 +0200") References: <86ploiwxw8.fsf@ltc.des.dev> <8745F9FB-9CC1-476C-9445-DC0A7A76165F@gmail.com> <8F8158B8-4D78-4A17-90B7-659ECB9988B5@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Date: Sun, 06 Oct 2024 10:55:27 +0200 Message-ID: <86v7y5vce8.fsf@ltc.des.dev> List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-stable@freebsd.org Sender: owner-freebsd-stable@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Alban Hertroys writes: > Originally I tried checking for the device using: > test "`sysctl -n dev.pcm.${PCM}.%desc`" =3D 'Topping D90SE=E2=80=99 > , but that statement seems to require the double-quotes for test to > accept it, which conflict with the double-quotes of the action > string. I couldn=E2=80=99t find a way to escape those inner quotes. So th= at=E2=80=99s > another issue I ran into, although approaches to use the USB attach > event for matching the dsp device to the usb device are clearly > superior to reading out a sysctl that=E2=80=99s an effect of it. You realize you can just put everything in a shell script which devd invokes, right? DES --=20 Dag-Erling Sm=C3=B8rgrav - des@FreeBSD.org From nobody Sun Oct 6 12:35:15 2024 X-Original-To: freebsd-stable@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 4XM1w75X70z5XmCX for ; Sun, 06 Oct 2024 12:35:35 +0000 (UTC) (envelope-from stefan.hegnauer@gmx.ch) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mout.gmx.net", Issuer "Telekom Security ServerID OV Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4XM1w63HMnz53nX for ; Sun, 6 Oct 2024 12:35:34 +0000 (UTC) (envelope-from stefan.hegnauer@gmx.ch) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmx.ch header.s=s31663417 header.b="KNlOd/hw"; spf=pass (mx1.freebsd.org: domain of stefan.hegnauer@gmx.ch designates 212.227.15.18 as permitted sender) smtp.mailfrom=stefan.hegnauer@gmx.ch; dmarc=pass (policy=quarantine) header.from=gmx.ch DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.ch; s=s31663417; t=1728218132; x=1728822932; i=stefan.hegnauer@gmx.ch; bh=DP2pOc1VFG6gxyD6n4C1tA8va2w+njD5JgjXU2gzSkU=; h=X-UI-Sender-Class:Message-ID:Date:MIME-Version:To:From:Subject: Content-Type:Content-Transfer-Encoding:cc: content-transfer-encoding:content-type:date:from:message-id: mime-version:reply-to:subject:to; b=KNlOd/hw/aG2mUdJ9FEiAaQ34GsvOnnPl8OMXnOGOaIXL3SVt5TZlsnzkA5pn5zQ m3f5H2YK0ivQZtiBpjv2yGq3LtG59J0Fyf6yvU2n+0QZxfloTlQjQoa19ws8ENOHE TUP5xttQD35S8GeJOcP5V7NwWx+P5BjegGhaP67wHMIRCsZPxMxglBd8bCaWsC3Th 0wKaK8rw7dGK8sNWd+VV/yfbDuBPmEdcc3FKQBBF9BEXawSEj9Wc91c0cDkgTs2GR huwdbDUQP3986juY4F6qJeDujAtxeYUVxGvFsT0R/Ycs17BgyljDSEQN5Ycs4DNNK 2R1k6ZLFACPKgAz+6g== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from [192.168.20.10] ([84.73.192.40]) by mail.gmx.net (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MJVHe-1tHIol3dNo-00P0Ow for ; Sun, 06 Oct 2024 14:35:31 +0200 Message-ID: Date: Sun, 6 Oct 2024 14:35:15 +0200 List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-stable@freebsd.org Sender: owner-freebsd-stable@FreeBSD.org MIME-Version: 1.0 User-Agent: Betterbird (Windows) To: freebsd-stable@freebsd.org Content-Language: en-US From: Stefan Hegnauer Subject: APU1 bricked on stable/14 - solved Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:fkPEXwbzSBF1m6ARXts2OrZVyyb7ZPuycqhA/DHYrBGBM9VD8wE g9Z/Bor+OTKHscBJZ+XscJ/jdVpYP8V4psHqWpx9XHSZLTth9h9VsYZ0KHpe0aa0PIOta52 CGJhVpjfda1RugEMzJb2MXRV+uSzd9XVN1MNc43lXq2qh7Pn1zS76tpiFw/1h8Fw7dIZ7wv LCYf/BBeO7VjSnCuq3ZEQ== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:V5fbeWxR8YE=;qobonxn+mtVrlDoQ/TKEGkH/L5M mPKGAlCUPL3XfyE31FnthnppAmuWfowH44mvm+ajgHJ0Pex0WlsUL+aLdVNKZTMlkSwSI2hTe dTcv+vkAfD5wY2PzdXO6ICUe96+Bcrkt/nrsI3XyG13nZEQK9o6SOWz/xPtXkxR5Eh5L1GHQV cBJtttBPun2W2Si5QMTWpHhcG8aPc7G+m48rnT7qmGCxY/Qhq/O7e4fuxhaghF2pD1G4hzRE1 6dFMOJ8RAB/wHgHSyKKp64oFxkuw+1GWDKrvUZRkuFh1m5x2Bi83L0cr/2hwCThKUM2yAIxxr s8YhKhybr5tLxs/hidid7vTwLFPzcqazSEkmWZwP3wD8hHDEwPTsXtOLEZZzmGIsBP02R94J7 /AePvatuuDvY5BSYKNWB1tdt2uyo0neEj4R0oL89JhKBjbvaFkZadkc0igvNZLu+8z4W+/Az1 uNEeBDrViS4LU/Fvv/D/mim0a8xmwGRXWaK0gpnQJpyngaqYuHlgWEHu1Iq/N/cmhBtPS4xoi RyHOury4ZK2nDMl+0w+9PNT/Y4Fa4iN5e8f+p54VY5EkiVzn+GKID35uXC5U5PIH8Z6CzGms+ 6/I9Uf0asvN0OUHHnQYMH03/umAgIQ42mt47Ok44+OzHC0CnwUpKc48NE6T6OiNJQlpbGYsyo hJvNk6yoWXyCYwlLtI8Sboat79ciEeM5hxuneq70IUS7NJYkoAcWc3GSH8/WBZH7SG84WpiO5 fKVcA2Wr1iJM9rXfHYa3+wNDRz7PcwWWIUDEqUpsff5mc/Efn5V+mr6qy04zQk0B3mKUlipBj 11UEj/YyuHIdlWHD2pkZJvVw== X-Spamd-Result: default: False [-3.44 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[gmx.ch,quarantine]; NEURAL_HAM_SHORT(-0.45)[-0.447]; R_SPF_ALLOW(-0.20)[+a:mout.gmx.net]; R_DKIM_ALLOW(-0.20)[gmx.ch:s=s31663417]; ONCE_RECEIVED(0.10)[]; RCVD_IN_DNSWL_LOW(-0.10)[212.227.15.18:from]; MIME_GOOD(-0.10)[text/plain]; XM_UA_NO_VERSION(0.01)[]; DKIM_TRACE(0.00)[gmx.ch:+]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:8560, ipnet:212.227.0.0/16, country:DE]; PREVIOUSLY_DELIVERED(0.00)[freebsd-stable@freebsd.org]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_FROM(0.00)[gmx.ch]; MLMMJ_DEST(0.00)[freebsd-stable@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[212.227.15.18:from]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmx.ch] X-Rspamd-Queue-Id: 4XM1w63HMnz53nX X-Spamd-Bar: --- I have a few pc-engines APU1 appliances running in headless mode under Nanobsd. Maintenance is by means of=C2=A0 direct COM port connection. After a recent update a few weeks back I was not able to connect by COM port anymore - console output and input went away after booting and before single- or multi-user mode would start. Even re-flashing the SDcard with a fresh image did not help. After some longish trials and errors it turned out that both - commit 74b9fc7a 'amd64 GENERIC: Switch uart hints from "isa" to "acpi"' as well as - commit 4ba4cfaf 'acpi: Narrow workaround for broken interrupt settings on x86' broke things for me. Restoring hints and setting hw.acpi.override_isa_irq_polarity=3D1 in /boot/loader.conf.local restored working order. I agree that APU1 is EOL, however I would have expected an entry to UPDATING for such a POLA violation. Note that pc-engines APU2 models are not affected as the BIOS ACPI tables contain correct UART descriptions. - Stefan From nobody Sun Oct 6 13:47:32 2024 X-Original-To: freebsd-stable@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 4XM3WS4zDgz5Y6Fq for ; Sun, 06 Oct 2024 13:47:48 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pg1-x532.google.com (mail-pg1-x532.google.com [IPv6:2607:f8b0:4864:20::532]) (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 4XM3WR6d0Hz3wcM for ; Sun, 6 Oct 2024 13:47:47 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pg1-x532.google.com with SMTP id 41be03b00d2f7-7ea0ff74b15so32132a12.3 for ; Sun, 06 Oct 2024 06:47:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1728222466; x=1728827266; 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=V3sFjvSS90UJBO9XnaUdo+Iq354O/BDwZpXPg2109Ig=; b=HZKEnS72ue9MCnGceRDsNTzuObXvIgab3dVlvS0/vl9JJWz4RX/a4OWrBdGpF7mtpK ClQBGda0B7cE1Ym3pGHAEQhja9L7FH9s5o3N6O8P7nQoyKkQAPZAJMNW941Jbjg9e+cq 7Xzk/01zRlkcNzMsDQOcRuQFTfuCKQBltdSsupP+JTX+m2LlzUsGrAiP1sXpuI2X+JRq 3pOQchAcPLiHaWZHrNm0XrsHtZ/eYulwx4E3ENuznDUzqPEQI40aMmmSGD8p0JdGiR8F USK5AZwfnpCP1apg89jiPRQMIs2LagovstVK6CGMx4wlRHGl6vGWPiTpWC1n1+JNNHSd OOig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1728222466; x=1728827266; 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=V3sFjvSS90UJBO9XnaUdo+Iq354O/BDwZpXPg2109Ig=; b=nMkXrLJZ3nAZhEKXRZkgiA66KMpL6giugcG65pgeSpYOWIuuQM47PU5lorb8N3OqCH 6FOkk8bv2Yuwtyu3h+ff8a0Tb7jlnaVkY3cuCPymOnrHGDMC6V6taVaGLas2R0Qbd7rW R2NAHH9tUtSFFlyBnqdMSNCht+7hWCkEnwINeslFUt6j0Y/SgIfRsOJqIIXrm72XCU8s 5EPZvGtRRqkiA1p6cx8+JiQvLg44EUk33D9eE3MBp/5p+05b7hKqTh+hqCdjvV3GrPDo xtnxUPV7N7DwNeHAup3vEs5Flz1Wvs6O9OsAjuyYszUklpoYVajI3qLw1xWy7F8n9jRy 6+Ow== X-Gm-Message-State: AOJu0YyAGFTa2gHjJIsIfEMkjJ8s0ENUtmVhtFK8Eguc0AFu5gwxprlb 6BeYPv/t+YbKub9B40B4ozg/ExZ79VTBE8hZYvE+udedamF0hoQXBgpvBalVbKUGF3KWBTjFMBU 11+oH4I9kl8zBupI5U2Oghvce4BNQ+2F28g/j7A== X-Google-Smtp-Source: AGHT+IHZnkCfTAjZ6gszr9n1Iu7qcqRq3iLjClCQYsYWfmsRrlS4bvVfYaCy2sR3+1QXgwkk68tL9wv5ZsbujvCNybc= X-Received: by 2002:a17:90a:7186:b0:2e1:e19f:609b with SMTP id 98e67ed59e1d1-2e1e627f41fmr10251982a91.24.1728222466346; Sun, 06 Oct 2024 06:47:46 -0700 (PDT) List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-stable@freebsd.org Sender: owner-freebsd-stable@FreeBSD.org MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Sun, 6 Oct 2024 07:47:32 -0600 Message-ID: Subject: Re: APU1 bricked on stable/14 - solved To: Stefan Hegnauer Cc: freebsd-stable@freebsd.org Content-Type: multipart/alternative; boundary="000000000000332c130623cf26d8" 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:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4XM3WR6d0Hz3wcM X-Spamd-Bar: ---- --000000000000332c130623cf26d8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Oct 6, 2024 at 6:35=E2=80=AFAM Stefan Hegnauer wrote: > I have a few pc-engines APU1 appliances running in headless mode under > Nanobsd. Maintenance is by means of direct COM port connection. > After a recent update a few weeks back I was not able to connect by COM > port anymore - console output and input went away after booting and > before single- or multi-user mode would start. Even re-flashing the > SDcard with a fresh image did not help. > > After some longish trials and errors it turned out that both > - commit 74b9fc7a 'amd64 GENERIC: Switch uart hints from "isa" to > "acpi"' as well as > - commit 4ba4cfaf 'acpi: Narrow workaround for broken interrupt settings > on x86' > broke things for me. Restoring hints and setting > hw.acpi.override_isa_irq_polarity=3D1 in /boot/loader.conf.local restored > working order. > > I agree that APU1 is EOL, however I would have expected an entry to > UPDATING for such a POLA violation. > Likely, but really really old gear like this is going to hit edge cases tha= t developers haven't seen. The hint thing wasn't though to actually negativel= y affect any deployed hardware since it dealt with details that changed 15 or 20 years ago... Looks like the APU1 used coreboot which at the time was trailing adaptation of ACPI, so it makes sense... I knew that Soekris boxes had issues, but the= y are another 5 or 10 years older than the APUs and mine sadly isn't operational. So I can write a better UPDATING entry, can you share with me the dmesg from both APU1 and APU2? Warner > Note that pc-engines APU2 models are not affected as the BIOS ACPI > tables contain correct UART descriptions. > > - Stefan > > --000000000000332c130623cf26d8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Oct 6, 2024 at 6:35=E2=80=AFA= M Stefan Hegnauer <stefan.hegn= auer@gmx.ch> wrote:
I have a few pc-engines APU1 appliances running in headless mode= under
Nanobsd. Maintenance is by means of=C2=A0 direct COM port connection.
After a recent update a few weeks back I was not able to connect by COM
port anymore - console output and input went away after booting and
before single- or multi-user mode would start. Even re-flashing the
SDcard with a fresh image did not help.

After some longish trials and errors it turned out that both
- commit 74b9fc7a 'amd64 GENERIC: Switch uart hints from "isa"= ; to
"acpi"' as well as
- commit 4ba4cfaf 'acpi: Narrow workaround for broken interrupt setting= s
on x86'
broke things for me. Restoring hints and setting
hw.acpi.override_isa_irq_polarity=3D1 in /boot/loader.conf.local restored working order.

I agree that APU1 is EOL, however I would have expected an entry to
UPDATING for such a POLA violation.

Lik= ely, but really really old gear like this is going to hit edge cases that
developers haven't seen. The hint thing wasn't though to a= ctually negatively
affect any deployed hardware since it dealt wi= th details that changed 15 or
20 years ago...

Looks like the APU1 used coreboot which at the time was trailing adap= tation
of ACPI, so it makes sense... I knew that Soekris boxes ha= d issues, but they
are another 5 or 10 years older than the APUs = and mine sadly isn't operational.

So I can wri= te a better UPDATING entry, can you share with me the dmesg
from = both APU1 and APU2?

Warner
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex"> Note that pc-engines APU2 models are not affected as the BIOS ACPI
tables contain correct UART descriptions.

- Stefan

--000000000000332c130623cf26d8-- From nobody Sun Oct 6 13:55:32 2024 X-Original-To: stable@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 4XM3hZ014Bz5Y6lj for ; Sun, 06 Oct 2024 13:55:42 +0000 (UTC) (envelope-from karl@denninger.net) Received: from colo1.denninger.net (colo1.denninger.net [104.236.120.189]) (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 4XM3hX3Tmmz3xlD for ; Sun, 6 Oct 2024 13:55:40 +0000 (UTC) (envelope-from karl@denninger.net) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of karl@denninger.net designates 104.236.120.189 as permitted sender) smtp.mailfrom=karl@denninger.net; dmarc=pass (policy=none) header.from=denninger.net Received: from denninger.net (syn-071-015-252-132.res.spectrum.com [71.15.252.132]) by colo1.denninger.net (Postfix) with ESMTP id C470E2110D6 for ; Sun, 06 Oct 2024 09:56:09 -0400 (EDT) Received: from [192.168.10.23] (D13.Denninger.Net [192.168.10.23]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by denninger.net (Postfix) with ESMTPSA id AD91B8D616 for ; Sun, 06 Oct 2024 09:55:32 -0400 (EDT) Message-ID: Date: Sun, 6 Oct 2024 09:55:32 -0400 List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-stable@freebsd.org Sender: owner-freebsd-stable@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: APU1 bricked on stable/14 - solved To: stable@freebsd.org References: Content-Language: en-US From: Karl Denninger In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms020901070407040906000605" X-Spamd-Result: default: False [-5.24 / 15.00]; SIGNED_SMIME(-2.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[denninger.net,none]; NEURAL_HAM_SHORT(-0.45)[-0.445]; MIME_GOOD(-0.20)[multipart/signed,multipart/alternative,text/plain]; R_SPF_ALLOW(-0.20)[+mx]; MIME_BASE64_TEXT(0.10)[]; XM_UA_NO_VERSION(0.01)[]; HAS_ATTACHMENT(0.00)[]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; FREEFALL_USER(0.00)[karl]; RCVD_VIA_SMTP_AUTH(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~,4:~]; TO_DN_NONE(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:14061, ipnet:104.236.64.0/18, country:US]; PREVIOUSLY_DELIVERED(0.00)[stable@freebsd.org]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[stable@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[] X-Rspamd-Queue-Id: 4XM3hX3Tmmz3xlD X-Spamd-Bar: ----- This is a cryptographically signed message in MIME format. --------------ms020901070407040906000605 Content-Type: multipart/alternative; boundary="------------RhCF6oZWSndL3RWdzV1GDiYL" --------------RhCF6oZWSndL3RWdzV1GDiYL Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 IEZyb20gb25lIG9mIHRoZSBBUFVzIEkgaGF2ZSBoZXJlOg0KDQotLS08PEJPT1Q+Pi0tLQ0K Q29weXJpZ2h0IChjKSAxOTkyLTIwMjMgVGhlIEZyZWVCU0QgUHJvamVjdC4NCkNvcHlyaWdo dCAoYykgMTk3OSwgMTk4MCwgMTk4MywgMTk4NiwgMTk4OCwgMTk4OSwgMTk5MSwgMTk5Miwg MTk5MywgMTk5NA0KIMKgwqDCoMKgwqDCoMKgIFRoZSBSZWdlbnRzIG9mIHRoZSBVbml2ZXJz aXR5IG9mIENhbGlmb3JuaWEuIEFsbCByaWdodHMgcmVzZXJ2ZWQuDQpGcmVlQlNEIGlzIGEg cmVnaXN0ZXJlZCB0cmFkZW1hcmsgb2YgVGhlIEZyZWVCU0QgRm91bmRhdGlvbi4NCkZyZWVC U0QgMTQuMS1TVEFCTEUgc3RhYmxlLzE0LW4yNjg3NDEtOWZmM2MwOTRmZGUzIEdFTkVSSUMg YW1kNjQNCkZyZWVCU0QgY2xhbmcgdmVyc2lvbiAxOC4xLjYgKGh0dHBzOi8vZ2l0aHViLmNv bS9sbHZtL2xsdm0tcHJvamVjdC5naXQgDQpsbHZtb3JnLTENCjguMS42LTAtZzExMThjMmUw NWU2NykNClZUKHZnYSk6IHJlc29sdXRpb24gNjQweDQ4MA0KQ1BVOiBBTUQgR1gtNDEyVEMg U09DwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqAgKDk5OC4xOC1NSHogDQpLOC1jbGFzcyBDUFUpDQogwqAgT3JpZ2luPSJB dXRoZW50aWNBTUQiwqAgSWQ9MHg3MzBmMDHCoCBGYW1pbHk9MHgxNsKgIE1vZGVsPTB4MzAg U3RlcHBpbmc9MQ0KRmVhdHVyZXM9MHgxNzhiZmJmZjxGUFUsVk1FLERFLFBTRSxUU0MsTVNS LFBBRSxNQ0UsQ1g4LEFQSUMsU0VQLE1UUlIsUEdFLE1DQSxDDQpNT1YsUEFULFBTRTM2LENM RkxVU0gsTU1YLEZYU1IsU1NFLFNTRTIsSFRUPg0KRmVhdHVyZXMyPTB4M2VkODIyMGI8U1NF MyxQQ0xNVUxRRFEsTU9OLFNTU0UzLENYMTYsU1NFNC4xLFNTRTQuMixNT1ZCRSxQT1BDTlQs DQpBRVNOSSxYU0FWRSxPU1hTQVZFLEFWWCxGMTZDPg0KIMKgIEFNRCBGZWF0dXJlcz0weDJl NTAwODAwPFNZU0NBTEwsTlgsTU1YKyxGRlhTUixQYWdlMUdCLFJEVFNDUCxMTT4NCiDCoCBB TUQgDQpGZWF0dXJlczI9MHgxZDQwMzdmZjxMQUhGLENNUCxTVk0sRXh0QVBJQyxDUjgsQUJN LFNTRTRBLE1BUyxQcmVmZXRjaCxPU1ZXLA0KSUJTLFNLSU5JVCxXRFQsVG9wb2xvZ3ksUE5Y QyxEQkUsUFRTQyxQTDJJPg0KIMKgIFN0cnVjdHVyZWQgRXh0ZW5kZWQgRmVhdHVyZXM9MHg4 PEJNSTE+DQogwqAgWFNBVkUgRmVhdHVyZXM9MHgxPFhTQVZFT1BUPg0KIMKgIFNWTTogTlAs TlJJUCxBRmx1c2gsREFzc2lzdCxOQXNpZHM9OA0KIMKgIFRTQzogUC1zdGF0ZSBpbnZhcmlh bnQsIHBlcmZvcm1hbmNlIHN0YXRpc3RpY3MNCnJlYWwgbWVtb3J5wqAgPSAyMDEzMDYxMTIw ICgxOTE5IE1CKQ0KYXZhaWwgbWVtb3J5ID0gMTkxMjI4NzIzMiAoMTgyMyBNQikNCkV2ZW50 IHRpbWVyICJMQVBJQyIgcXVhbGl0eSAxMDANCkFDUEkgQVBJQyBUYWJsZTogPENPUkXCoMKg IENPUkVCT09UPg0KRnJlZUJTRC9TTVA6IE11bHRpcHJvY2Vzc29yIFN5c3RlbSBEZXRlY3Rl ZDogNCBDUFVzDQpGcmVlQlNEL1NNUDogMSBwYWNrYWdlKHMpIHggNCBjb3JlKHMpDQphcmM0 cmFuZG9tOiBXQVJOSU5HOiBpbml0aWFsIHNlZWRpbmcgYnlwYXNzZWQgdGhlIGNyeXB0b2dy YXBoaWMgcmFuZG9tIA0KZGV2aWNlIGJlDQpjYXVzZSBpdCB3YXMgbm90IHlldCBzZWVkZWQg YW5kIHRoZSBrbm9iICdieXBhc3NfYmVmb3JlX3NlZWRpbmcnIHdhcyANCmVuYWJsZWQuDQpp b2FwaWMxOiBNQURUIEFQSUMgSUQgNSAhPSBodyBpZCAwDQppb2FwaWMwIDxWZXJzaW9uIDIu MT4gaXJxcyAwLTIzDQppb2FwaWMxIDxWZXJzaW9uIDIuMT4gaXJxcyAyNC01NQ0KTGF1bmNo aW5nIEFQczogMyAxIDINCnJhbmRvbTogZW50cm9weSBkZXZpY2UgZXh0ZXJuYWwgaW50ZXJm YWNlDQprYmQwIGF0IGtiZG11eDANCnZ0dmdhMDogPFZUIFZHQSBkcml2ZXI+DQpzbWJpb3Mw OiA8U3lzdGVtIE1hbmFnZW1lbnQgQklPUz4gYXQgaW9tZW0gMHhmMzc0MC0weGYzNzVlDQpz bWJpb3MwOiBWZXJzaW9uOiAyLjcNCmFlc25pMDogPEFFUy1DQkMsQUVTLUNDTSxBRVMtR0NN LEFFUy1JQ00sQUVTLVhUUz4NCmFjcGkwOiA8Q09SRSBDT1JFQk9PVD4NCmFjcGkwOiBQb3dl ciBCdXR0b24gKGZpeGVkKQ0KY3B1MDogPEFDUEkgQ1BVPiBvbiBhY3BpMA0KYXRydGMwOiA8 QVQgcmVhbHRpbWUgY2xvY2s+IHBvcnQgMHg3MC0weDcxIGlycSA4IG9uIGFjcGkwDQphdHJ0 YzA6IHJlZ2lzdGVyZWQgYXMgYSB0aW1lLW9mLWRheSBjbG9jaywgcmVzb2x1dGlvbiAxLjAw MDAwMHMNCkV2ZW50IHRpbWVyICJSVEMiIGZyZXF1ZW5jeSAzMjc2OCBIeiBxdWFsaXR5IDAN CmF0dGltZXIwOiA8QVQgdGltZXI+IHBvcnQgMHg0MC0weDQzIGlycSAwIG9uIGFjcGkwDQpU aW1lY291bnRlciAiaTgyNTQiIGZyZXF1ZW5jeSAxMTkzMTgyIEh6IHF1YWxpdHkgMA0KRXZl bnQgdGltZXIgImk4MjU0IiBmcmVxdWVuY3kgMTE5MzE4MiBIeiBxdWFsaXR5IDEwMA0KYXBl aTA6IDxBQ1BJIFBsYXRmb3JtIEVycm9yIEludGVyZmFjZT4gb24gYWNwaTANCmhwZXQwOiA8 SGlnaCBQcmVjaXNpb24gRXZlbnQgVGltZXI+IGlvbWVtIDB4ZmVkMDAwMDAtMHhmZWQwMDNm ZiBvbiBhY3BpMA0KVGltZWNvdW50ZXIgIkhQRVQiIGZyZXF1ZW5jeSAxNDMxODE4MCBIeiBx dWFsaXR5IDk1MA0KVGltZWNvdW50ZXIgIkFDUEktZmFzdCIgZnJlcXVlbmN5IDM1Nzk1NDUg SHogcXVhbGl0eSA5MDANCmFjcGlfdGltZXIwOiA8MzItYml0IHRpbWVyIGF0IDMuNTc5NTQ1 TUh6PiBwb3J0IDB4ODE4LTB4ODFiIG9uIGFjcGkwDQphY3BpX2J1dHRvbjA6IDxQb3dlciBC dXR0b24+IG9uIGFjcGkwDQpwY2liMDogPEFDUEkgSG9zdC1QQ0kgYnJpZGdlPiBwb3J0IDB4 Y2Y4LTB4Y2ZmIG9uIGFjcGkwDQpwY2kwOiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liMA0KcGNp YjE6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgMi4yIG9uIHBjaTANCnBjaWIx OiBmYWlsZWQgdG8gYWxsb2NhdGUgaW5pdGlhbCBJL08gcG9ydCB3aW5kb3c6IDB4MTAwMC0w eDFmZmYNCnBjaTE6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIxDQppZ2IwOiA8SW50ZWwoUikg STIxMSAoQ29wcGVyKT4gcG9ydCAweDIwMDAtMHgyMDFmIG1lbSANCjB4ZmU3MDAwMDAtMHhm ZTcxZmZmZiwweGZlDQo3MjAwMDAtMHhmZTcyM2ZmZiBhdCBkZXZpY2UgMC4wIG9uIHBjaTEN CmlnYjA6IE5WTSBWMC42IGltZ3R5cGUxDQppZ2IwOiBVc2luZyAxMDI0IFRYIGRlc2NyaXB0 b3JzIGFuZCAxMDI0IFJYIGRlc2NyaXB0b3JzDQppZ2IwOiBVc2luZyAyIFJYIHF1ZXVlcyAy IFRYIHF1ZXVlcw0KaWdiMDogVXNpbmcgTVNJLVggaW50ZXJydXB0cyB3aXRoIDMgdmVjdG9y cw0KaWdiMDogRXRoZXJuZXQgYWRkcmVzczogMDA6MGQ6Yjk6NDY6NzE6ODgNCmlnYjA6IG5l dG1hcCBxdWV1ZXMvc2xvdHM6IFRYIDIvMTAyNCwgUlggMi8xMDI0DQpwY2liMjogPEFDUEkg UENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSAyLjQgb24gcGNpMA0KcGNpYjI6IGZhaWxlZCB0 byBhbGxvY2F0ZSBpbml0aWFsIEkvTyBwb3J0IHdpbmRvdzogMHgyMDAwLTB4MmZmZg0KcGNp MjogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjINCmlnYjE6IDxJbnRlbChSKSBJMjExIChDb3Bw ZXIpPiBwb3J0IDB4NDAwMC0weDQwMWYgbWVtIA0KMHhmZTgwMDAwMC0weGZlODFmZmZmLDB4 ZmUNCjgyMDAwMC0weGZlODIzZmZmIGF0IGRldmljZSAwLjAgb24gcGNpMg0KaWdiMTogTlZN IFYwLjYgaW1ndHlwZTENCmlnYjE6IFVzaW5nIDEwMjQgVFggZGVzY3JpcHRvcnMgYW5kIDEw MjQgUlggZGVzY3JpcHRvcnMNCmlnYjE6IFVzaW5nIDIgUlggcXVldWVzIDIgVFggcXVldWVz DQppZ2IxOiBVc2luZyBNU0ktWCBpbnRlcnJ1cHRzIHdpdGggMyB2ZWN0b3JzDQppZ2IxOiBF dGhlcm5ldCBhZGRyZXNzOiAwMDowZDpiOTo0Njo3MTo4OQ0KaWdiMTogbmV0bWFwIHF1ZXVl cy9zbG90czogVFggMi8xMDI0LCBSWCAyLzEwMjQNCnBjaTA6IDxlbmNyeXB0L2RlY3J5cHQ+ IGF0IGRldmljZSA4LjAgKG5vIGRyaXZlciBhdHRhY2hlZCkNCnhoY2kwOiA8QU1EIEZDSCBV U0IgMy4wIGNvbnRyb2xsZXI+IG1lbSAweGZlYjIyMDAwLTB4ZmViMjNmZmYgYXQgZGV2aWNl IA0KMTYuMCBvbg0KcGNpMA0KeGhjaTA6IDMyIGJ5dGVzIGNvbnRleHQgc2l6ZSwgNjQtYml0 IERNQQ0KdXNidXMwIG9uIHhoY2kwDQp1c2J1czA6IDUuMEdicHMgU3VwZXIgU3BlZWQgVVNC IHYzLjANCmFoY2kwOiA8QU1EIEh1ZHNvbi0yIEFIQ0kgU0FUQSBjb250cm9sbGVyPiBwb3J0 IA0KMHgzMDEwLTB4MzAxNywweDMwMjAtMHgzMDIzLDB4MzANCjE4LTB4MzAxZiwweDMwMjQt MHgzMDI3LDB4MzAwMC0weDMwMGYgbWVtIDB4ZmViMjUwMDAtMHhmZWIyNTNmZiBhdCANCmRl dmljZSAxNy4wIG8NCm4gcGNpMA0KYWhjaTA6IEFIQ0kgdjEuMzAgd2l0aCAyIDZHYnBzIHBv cnRzLCBQb3J0IE11bHRpcGxpZXIgc3VwcG9ydGVkIHdpdGggRkJTDQphaGNpY2gwOiA8QUhD SSBjaGFubmVsPiBhdCBjaGFubmVsIDAgb24gYWhjaTANCmFoY2ljaDE6IDxBSENJIGNoYW5u ZWw+IGF0IGNoYW5uZWwgMSBvbiBhaGNpMA0KZWhjaTA6IDxBTUQgRkNIIFVTQiAyLjAgY29u dHJvbGxlcj4gbWVtIDB4ODAwMDAwMDAtMHg4MDAwMDBmZiBhdCBkZXZpY2UgDQoxOC4wIG9u DQpwY2kwDQp1c2J1czE6IEVIQ0kgdmVyc2lvbiAxLjANCnVzYnVzMSBvbiBlaGNpMA0KdXNi dXMxOiA0ODBNYnBzIEhpZ2ggU3BlZWQgVVNCIHYyLjANCmVoY2kxOiA8QU1EIEZDSCBVU0Ig Mi4wIGNvbnRyb2xsZXI+IG1lbSAweGZlYjI1NDAwLTB4ZmViMjU0ZmYgYXQgZGV2aWNlIA0K MTkuMCBvbg0KcGNpMA0KdXNidXMyOiBFSENJIHZlcnNpb24gMS4wDQp1c2J1czIgb24gZWhj aTENCnVzYnVzMjogNDgwTWJwcyBIaWdoIFNwZWVkIFVTQiB2Mi4wDQppc2FiMDogPFBDSS1J U0EgYnJpZGdlPiBhdCBkZXZpY2UgMjAuMyBvbiBwY2kwDQppc2EwOiA8SVNBIGJ1cz4gb24g aXNhYjANCnNkaGNpX3BjaTA6IDxHZW5lcmljIFNEIEhDST4gbWVtIDB4ZmViMjU1MDAtMHhm ZWIyNTVmZiBhdCBkZXZpY2UgMjAuNyBvbiANCnBjaTANCnNkaGNpX3BjaTA6IDEgc2xvdChz KSBhbGxvY2F0ZWQNCm1tYzA6IDxNTUMvU0QgYnVzPiBvbiBzZGhjaV9wY2kwDQp1YXJ0MDog PDE2NTUwIG9yIGNvbXBhdGlibGU+IHBvcnQgMHgzZjgtMHgzZmYgaXJxIDQgZmxhZ3MgMHgx MCBvbiBhY3BpMA0KbnM4MjUwOiBVQVJUIEZDUiBpcyBicm9rZW4NCnVhcnQwOiBjb25zb2xl ICgxMTUyMDAsbiw4LDEpDQpvcm0wOiA8SVNBIE9wdGlvbiBST00+IGF0IGlvbWVtIDB4ZWYw MDAtMHhlZmZmZiBwbnBpZCBPUk0wMDAwIG9uIGlzYTANCmh3cHN0YXRlMDogPENvb2xgbidR dWlldCAyLjA+IG9uIGNwdTANClRpbWVjb3VudGVyICJUU0MiIGZyZXF1ZW5jeSA5OTgxMjcy MzQgSHogcXVhbGl0eSAxMDAwDQpUaW1lY291bnRlcnMgdGljayBldmVyeSAxLjAwMCBtc2Vj DQp1Z2VuMi4xOiA8QU1EIEVIQ0kgcm9vdCBIVUI+IGF0IHVzYnVzMg0KdWdlbjEuMTogPEFN RCBFSENJIHJvb3QgSFVCPiBhdCB1c2J1czENCnVnZW4wLjE6IDxBTUQgWEhDSSByb290IEhV Qj4gYXQgdXNidXMwDQp1aHViMCBvbiB1c2J1czINCnVodWIwOiA8QU1EIEVIQ0kgcm9vdCBI VUIsIGNsYXNzIDkvMCwgcmV2IDIuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2J1czINCnVodWIx IG9uIHVzYnVzMA0KdWh1YjE6IDxBTUQgWEhDSSByb290IEhVQiwgY2xhc3MgOS8wLCByZXYg My4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYnVzMA0KdWh1YjIgb24gdXNidXMxDQp1aHViMjog PEFNRCBFSENJIHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJldiAyLjAwLzEuMDAsIGFkZHIgMT4g b24gdXNidXMxDQptbWNzZDA6IDE2R0IgPFNESEMgU0wxNkcgOC4wIFNOIEE0OTgxQTIyIE1G RyAwMS8yMDE3IGJ5IDMgU0Q+IGF0IG1tYzAgDQo1MC4wTUh6LzRiDQppdC82NTUzNS1ibG9j aw0KVHJ5aW5nIHRvIG1vdW50IHJvb3QgZnJvbSB1ZnM6L2Rldi9tbWNzZDBzMWEgW3JvXS4u Lg0KDQouLi4uDQoNClRoaXMgaXMgYW4gQVBVMjsgSSd2ZSBnb3QgYSBidW5jaCBvZiB0aGVt IGluIHRoZSBmaWVsZCAob25lIGlzIG15IG93biANCnBlcnNvbmFsIGZpcmV3YWxsL2dhdGV3 YXkpIGJ1dCB0aGV5J3JlIEVPTCdkIGFzIHRoZSBTT0Mgd2FzIGRlcHJlY2F0ZWQuwqAgDQpU aGV5IHJ1biBxdWl0ZSB3ZWxsIGFuZCBJJ20gb24gc3RhYmxlLzE0IHdpdGggdGhlbSBhdCBw cmVzZW50Lg0KDQoNCk9uIDEwLzYvMjAyNCA5OjQ3IEFNLCBXYXJuZXIgTG9zaCB3cm90ZToN Cj4NCj4NCj4gT24gU3VuLCBPY3QgNiwgMjAyNCBhdCA2OjM14oCvQU0gU3RlZmFuIEhlZ25h dWVyIA0KPiA8c3RlZmFuLmhlZ25hdWVyQGdteC5jaD4gd3JvdGU6DQo+DQo+ICAgICBJIGhh dmUgYSBmZXcgcGMtZW5naW5lcyBBUFUxIGFwcGxpYW5jZXMgcnVubmluZyBpbiBoZWFkbGVz cyBtb2RlIHVuZGVyDQo+ICAgICBOYW5vYnNkLiBNYWludGVuYW5jZSBpcyBieSBtZWFucyBv ZsKgIGRpcmVjdCBDT00gcG9ydCBjb25uZWN0aW9uLg0KPiAgICAgQWZ0ZXIgYSByZWNlbnQg dXBkYXRlIGEgZmV3IHdlZWtzIGJhY2sgSSB3YXMgbm90IGFibGUgdG8gY29ubmVjdA0KPiAg ICAgYnkgQ09NDQo+ICAgICBwb3J0IGFueW1vcmUgLSBjb25zb2xlIG91dHB1dCBhbmQgaW5w dXQgd2VudCBhd2F5IGFmdGVyIGJvb3RpbmcgYW5kDQo+ICAgICBiZWZvcmUgc2luZ2xlLSBv ciBtdWx0aS11c2VyIG1vZGUgd291bGQgc3RhcnQuIEV2ZW4gcmUtZmxhc2hpbmcgdGhlDQo+ ICAgICBTRGNhcmQgd2l0aCBhIGZyZXNoIGltYWdlIGRpZCBub3QgaGVscC4NCj4NCj4gICAg IEFmdGVyIHNvbWUgbG9uZ2lzaCB0cmlhbHMgYW5kIGVycm9ycyBpdCB0dXJuZWQgb3V0IHRo YXQgYm90aA0KPiAgICAgLSBjb21taXQgNzRiOWZjN2EgJ2FtZDY0IEdFTkVSSUM6IFN3aXRj aCB1YXJ0IGhpbnRzIGZyb20gImlzYSIgdG8NCj4gICAgICJhY3BpIicgYXMgd2VsbCBhcw0K PiAgICAgLSBjb21taXQgNGJhNGNmYWYgJ2FjcGk6IE5hcnJvdyB3b3JrYXJvdW5kIGZvciBi cm9rZW4gaW50ZXJydXB0DQo+ICAgICBzZXR0aW5ncw0KPiAgICAgb24geDg2Jw0KPiAgICAg YnJva2UgdGhpbmdzIGZvciBtZS4gUmVzdG9yaW5nIGhpbnRzIGFuZCBzZXR0aW5nDQo+ICAg ICBody5hY3BpLm92ZXJyaWRlX2lzYV9pcnFfcG9sYXJpdHk9MSBpbiAvYm9vdC9sb2FkZXIu Y29uZi5sb2NhbA0KPiAgICAgcmVzdG9yZWQNCj4gICAgIHdvcmtpbmcgb3JkZXIuDQo+DQo+ ICAgICBJIGFncmVlIHRoYXQgQVBVMSBpcyBFT0wsIGhvd2V2ZXIgSSB3b3VsZCBoYXZlIGV4 cGVjdGVkIGFuIGVudHJ5IHRvDQo+ICAgICBVUERBVElORyBmb3Igc3VjaCBhIFBPTEEgdmlv bGF0aW9uLg0KPg0KPg0KPiBMaWtlbHksIGJ1dCByZWFsbHkgcmVhbGx5IG9sZCBnZWFyIGxp a2UgdGhpcyBpcyBnb2luZyB0byBoaXQgZWRnZSANCj4gY2FzZXMgdGhhdA0KPiBkZXZlbG9w ZXJzIGhhdmVuJ3Qgc2Vlbi4gVGhlIGhpbnQgdGhpbmcgd2Fzbid0IHRob3VnaCB0byBhY3R1 YWxseSANCj4gbmVnYXRpdmVseQ0KPiBhZmZlY3QgYW55IGRlcGxveWVkIGhhcmR3YXJlIHNp bmNlIGl0IGRlYWx0IHdpdGggZGV0YWlscyB0aGF0IGNoYW5nZWQgDQo+IDE1IG9yDQo+IDIw IHllYXJzIGFnby4uLg0KPg0KPiBMb29rcyBsaWtlIHRoZSBBUFUxIHVzZWQgY29yZWJvb3Qg d2hpY2ggYXQgdGhlIHRpbWUgd2FzIHRyYWlsaW5nIA0KPiBhZGFwdGF0aW9uDQo+IG9mIEFD UEksIHNvIGl0IG1ha2VzIHNlbnNlLi4uIEkga25ldyB0aGF0IFNvZWtyaXMgYm94ZXMgaGFk IGlzc3VlcywgDQo+IGJ1dCB0aGV5DQo+IGFyZSBhbm90aGVyIDUgb3IgMTAgeWVhcnMgb2xk ZXIgdGhhbiB0aGUgQVBVcyBhbmQgbWluZSBzYWRseSBpc24ndCANCj4gb3BlcmF0aW9uYWwu DQo+DQo+IFNvIEkgY2FuIHdyaXRlIGEgYmV0dGVyIFVQREFUSU5HIGVudHJ5LCBjYW4geW91 IHNoYXJlIHdpdGggbWUgdGhlIGRtZXNnDQo+IGZyb20gYm90aCBBUFUxIGFuZCBBUFUyPw0K Pg0KPiBXYXJuZXINCj4NCj4gICAgIE5vdGUgdGhhdCBwYy1lbmdpbmVzIEFQVTIgbW9kZWxz IGFyZSBub3QgYWZmZWN0ZWQgYXMgdGhlIEJJT1MgQUNQSQ0KPiAgICAgdGFibGVzIGNvbnRh aW4gY29ycmVjdCBVQVJUIGRlc2NyaXB0aW9ucy4NCj4NCj4gICAgIC0gU3RlZmFuDQo+DQot LSANCkthcmwgRGVubmluZ2VyDQprYXJsQGRlbm5pbmdlci5uZXQNCi9UaGUgTWFya2V0IFRp Y2tlci8NCi9bUy9NSU1FIGVuY3J5cHRlZCBlbWFpbCBwcmVmZXJyZWRdLw0K --------------RhCF6oZWSndL3RWdzV1GDiYL Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

From one of the APUs I have here:

---<<BOOT>>---
Copyright (c) 1992-2023 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The Regents of the Unive= rsity of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 14.1-STABLE stable/14-n268741-9ff3c094fde3 GENERIC amd64 FreeBSD clang version 18.1.6 (https://github.com/llvm/llvm-project.git llvmorg-1=
8.1.6-0-g1118c2e05e67)
VT(vga): resolution 640x480
CPU: AMD GX-412TC SOC=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (998.18-M= Hz K8-class CPU)
=C2=A0 Origin=3D"AuthenticAMD"=C2=A0 Id=3D0x730f01=C2=A0 Family=3D0= x16=C2=A0 Model=3D0x30=C2=A0 Stepping=3D1
=C2=A0 Features=3D0x178bfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR= ,PGE,MCA,C
MOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT>
=C2=A0 Features2=3D0x3ed8220b<SSE3,PCLMULQDQ,MON,SSSE3,CX16,SSE4.1,SSE4.2,MOV= BE,POPCNT,
AESNI,XSAVE,OSXSAVE,AVX,F16C>
=C2=A0 AMD Features=3D0x2e500800<SYSCALL,NX,MMX+,FFXSR,Page1GB,RDTSCP,LM>= ;
=C2=A0 AMD Features2=3D0x1d4037ff<LAHF,CMP,SVM,ExtAPIC,CR8,ABM,SSE4A,MAS,Prefetch= ,OSVW,
IBS,SKINIT,WDT,Topology,PNXC,DBE,PTSC,PL2I>
=C2=A0 Structured Extended Features=3D0x8<BMI1>
=C2=A0 XSAVE Features=3D0x1<XSAVEOPT>
=C2=A0 SVM: NP,NRIP,AFlush,DAssist,NAsids=3D8
=C2=A0 TSC: P-state invariant, performance statistics
real memory=C2=A0 =3D 2013061120 (1919 MB)
avail memory =3D 1912287232 (1823 MB)
Event timer "LAPIC" quality 100
ACPI APIC Table: <CORE=C2=A0=C2=A0 COREBOOT>
FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
FreeBSD/SMP: 1 package(s) x 4 core(s)
arc4random: WARNING: initial seeding bypassed the cryptographic random device be
cause it was not yet seeded and the knob 'bypass_before_seeding' was enabled.
ioapic1: MADT APIC ID 5 !=3D hw id 0
ioapic0 <Version 2.1> irqs 0-23
ioapic1 <Version 2.1> irqs 24-55
Launching APs: 3 1 2
random: entropy device external interface
kbd0 at kbdmux0
vtvga0: <VT VGA driver>
smbios0: <System Management BIOS> at iomem 0xf3740-0xf375e smbios0: Version: 2.7
aesni0: <AES-CBC,AES-CCM,AES-GCM,AES-ICM,AES-XTS>
acpi0: <CORE COREBOOT>
acpi0: Power Button (fixed)
cpu0: <ACPI CPU> on acpi0
atrtc0: <AT realtime clock> port 0x70-0x71 irq 8 on acpi0
= atrtc0: registered as a time-of-day clock, resolution 1.000000s
= Event timer "RTC" frequency 32768 Hz quality 0
attimer0: <AT timer> port 0x40-0x43 irq 0 on acpi0
Timecounter "i8254" frequency 1193182 Hz quality 0
Event timer "i8254" frequency 1193182 Hz quality 100
apei0: <ACPI Platform Error Interface> on acpi0
hpet0: <High Precision Event Timer> iomem 0xfed00000-0xfed003ff on acpi0
Timecounter "HPET" frequency 14318180 Hz quality 950
Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
acpi_timer0: <32-bit timer at 3.579545MHz> port 0x818-0x81b on acpi0
acpi_button0: <Power Button> on acpi0
pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
pci0: <ACPI PCI bus> on pcib0
pcib1: <ACPI PCI-PCI bridge> at device 2.2 on pci0
pcib1: failed to allocate initial I/O port window: 0x1000-0x1fff pci1: <ACPI PCI bus> on pcib1
igb0: <Intel(R) I211 (Copper)> port 0x2000-0x201f mem 0xfe700000-0xfe71ffff,0xfe
720000-0xfe723fff at device 0.0 on pci1
igb0: NVM V0.6 imgtype1
igb0: Using 1024 TX descriptors and 1024 RX descriptors
igb0: Using 2 RX queues 2 TX queues
igb0: Using MSI-X interrupts with 3 vectors
igb0: Ethernet address: 00:0d:b9:46:71:88
igb0: netmap queues/slots: TX 2/1024, RX 2/1024
pcib2: <ACPI PCI-PCI bridge> at device 2.4 on pci0
pcib2: failed to allocate initial I/O port window: 0x2000-0x2fff pci2: <ACPI PCI bus> on pcib2
igb1: <Intel(R) I211 (Copper)> port 0x4000-0x401f mem 0xfe800000-0xfe81ffff,0xfe
820000-0xfe823fff at device 0.0 on pci2
igb1: NVM V0.6 imgtype1
igb1: Using 1024 TX descriptors and 1024 RX descriptors
igb1: Using 2 RX queues 2 TX queues
igb1: Using MSI-X interrupts with 3 vectors
igb1: Ethernet address: 00:0d:b9:46:71:89
igb1: netmap queues/slots: TX 2/1024, RX 2/1024
pci0: <encrypt/decrypt> at device 8.0 (no driver attached) xhci0: <AMD FCH USB 3.0 controller> mem 0xfeb22000-0xfeb23fff at device 16.0 on
pci0
xhci0: 32 bytes context size, 64-bit DMA
usbus0 on xhci0
usbus0: 5.0Gbps Super Speed USB v3.0
ahci0: <AMD Hudson-2 AHCI SATA controller> port 0x3010-0x3017,0x3020-0x3023,0x30
18-0x301f,0x3024-0x3027,0x3000-0x300f mem 0xfeb25000-0xfeb253ff at device 17.0 o
n pci0
ahci0: AHCI v1.30 with 2 6Gbps ports, Port Multiplier supported with FBS
ahcich0: <AHCI channel> at channel 0 on ahci0
ahcich1: <AHCI channel> at channel 1 on ahci0
ehci0: <AMD FCH USB 2.0 controller> mem 0x80000000-0x800000ff at device 18.0 on
pci0
usbus1: EHCI version 1.0
usbus1 on ehci0
usbus1: 480Mbps High Speed USB v2.0
ehci1: <AMD FCH USB 2.0 controller> mem 0xfeb25400-0xfeb254ff at device 19.0 on
pci0
usbus2: EHCI version 1.0
usbus2 on ehci1
usbus2: 480Mbps High Speed USB v2.0
isab0: <PCI-ISA bridge> at device 20.3 on pci0
isa0: <ISA bus> on isab0
sdhci_pci0: <Generic SD HCI> mem 0xfeb25500-0xfeb255ff at device 20.7 on pci0
sdhci_pci0: 1 slot(s) allocated
mmc0: <MMC/SD bus> on sdhci_pci0
uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
ns8250: UART FCR is broken
uart0: console (115200,n,8,1)
orm0: <ISA Option ROM> at iomem 0xef000-0xeffff pnpid ORM0000 on isa0
hwpstate0: <Cool`n'Quiet 2.0> on cpu0
Timecounter "TSC" frequency 998127234 Hz quality 1000
Timecounters tick every 1.000 msec
ugen2.1: <AMD EHCI root HUB> at usbus2
ugen1.1: <AMD EHCI root HUB> at usbus1
ugen0.1: <AMD XHCI root HUB> at usbus0
uhub0 on usbus2
uhub0: <AMD EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus2
uhub1 on usbus0
uhub1: <AMD XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0
uhub2 on usbus1
uhub2: <AMD EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus1
mmcsd0: 16GB <SDHC SL16G 8.0 SN A4981A22 MFG 01/2017 by 3 SD> at mmc0 50.0MHz/4b
it/65535-block
Trying to mount root from ufs:/dev/mmcsd0s1a [ro]...

....

This is an APU2; I've got a bunch of them in the field (one is my own personal firewall/gateway) but they're EOL'd as the SOC was deprecated.=C2=A0 They run quite well and I'm on stable/14 with the= m at present.


On 10/6/2024 9:47 AM, Warner Losh wrote:


On Sun, Oct 6, 2024 at 6:35=E2=80=AFAM Stefan Hegnauer <st= efan.hegnauer@gmx.ch> wrote:
I have a few pc-engines APU1 appliances running in headless mode under
Nanobsd. Maintenance is by means of=C2=A0 direct COM port connection.
After a recent update a few weeks back I was not able to connect by COM
port anymore - console output and input went away after booting and
before single- or multi-user mode would start. Even re-flashing the
SDcard with a fresh image did not help.

After some longish trials and errors it turned out that both<= br> - commit 74b9fc7a 'amd64 GENERIC: Switch uart hints from "isa" to
"acpi"' as well as
- commit 4ba4cfaf 'acpi: Narrow workaround for broken interrupt settings
on x86'
broke things for me. Restoring hints and setting
hw.acpi.override_isa_irq_polarity=3D1 in /boot/loader.conf.local restored
working order.

I agree that APU1 is EOL, however I would have expected an entry to
UPDATING for such a POLA violation.

Likely, but really really old gear like this is going to hit edge cases that
developers haven't seen. The hint thing wasn't though to actually negatively
affect any deployed hardware since it dealt with details that changed 15 or
20 years ago...

Looks like the APU1 used coreboot which at the time was trailing adaptation
of ACPI, so it makes sense... I knew that Soekris boxes had issues, but they
are another 5 or 10 years older than the APUs and mine sadly isn't operational.

So I can write a better UPDATING entry, can you share with me the dmesg
from both APU1 and APU2?

Warner
=C2=A0
Note that pc-engines APU2 models are not affected as the BIOS ACPI
tables contain correct UART descriptions.

- Stefan

--
Karl Denninger
karl@denninger.net
The Market Ticker
[S/MIME encrypted email preferred]<= /div> --------------RhCF6oZWSndL3RWdzV1GDiYL-- --------------ms020901070407040906000605 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC C4owggWZMIIDgaADAgECAhRZU8dKdMneRI1Vq5kv0k54Q5rQuDANBgkqhkiG9w0BAQsFADB2 MQswCQYDVQQGEwJVUzESMBAGA1UECAwJVGVubmVzc2VlMRYwFAYDVQQKDA1EZW5uaW5nZXIu TmV0MRcwFQYDVQQDDA5EZW5uaW5nZXIgUm9vdDEiMCAGCSqGSIb3DQEJARYTYWRtaW5AZGVu bmluZ2VyLm5ldDAeFw0yNDA1MDkyMTA4MDNaFw00NDA1MDQyMTA4MDNaMF0xCzAJBgNVBAYT AlVTMRIwEAYDVQQIDAlUZW5uZXNzZWUxFjAUBgNVBAoMDURlbm5pbmdlci5uZXQxIjAgBgNV BAMMGURlbm5pbmdlci5OZXQgU2lnbmluZyBJbnQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDbR0tSiuLG5HPfo+cWtdeYQ8jc8Bjfuo0GTcNRT0glHnH1apUtInIktUknEZDH ohahInN+mMBdKg54FCHOiYZrJbyxBIo9FwX7hRmOc+spxmSYWnOd2E/YcGInMK4ZpjPzldzB Yt1n3zygkhx2bssxTJS3x4nv1qAXfLSZd1VwqoQufifEoPyTtymkkvHLv86vLgqAqooM/cXc 4LSIQ5u2uM308n42r8RkKtp7X1v9fJW8oRZN2XnFZtiUPH44YY2rHqyN2Hea9Y3+TXbldXjo xhPHTA+JYVFq8KTmbQBqU7YcMhlIG0cSxPeFLMxnP6pqPcIVTAlK+a6YGRFppfjZAgMBAAGj ggE2MIIBMjAdBgNVHQ4EFgQUH+VuxXhBxaJAQrvDekwkH91hBi4wgbMGA1UdIwSBqzCBqIAU RFYC4p6L6KITnEvrpx2cyt+PcMmheqR4MHYxCzAJBgNVBAYTAlVTMRIwEAYDVQQIDAlUZW5u ZXNzZWUxFjAUBgNVBAoMDURlbm5pbmdlci5OZXQxFzAVBgNVBAMMDkRlbm5pbmdlciBSb290 MSIwIAYJKoZIhvcNAQkBFhNhZG1pbkBkZW5uaW5nZXIubmV0ghQZE7NBItWtQsCouuwU6jZ+ HPPwnjAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBBjA6BgNVHR8EMzAxMC+gLaAr hilodHRwOi8vd3d3LmRlbm5pbmdlci5uZXQvcm9vdC1yZXZva2VkLmNybDANBgkqhkiG9w0B AQsFAAOCAgEAfFbhPc82AfhyUqONs7IccYD36w+OP4nQgwfC4IWf3y/aQAZ2Zk6IITzYqwf7 PFM0bJRT3zi7xyetolqHDhfMJvnOQWpITZiyM/FSKwIvuBsy/uJUqPuqui4XQMYoSbAA1qmI MW/z7VZZHwaRFoeWE40UirYcf0fNcooBZ72bmd+iBaVyjtZvky0Vgcz0eC6e6LR5kNb23yC6 TkyQIlGyQkK5/afXUYFzk49rOHVbVyxW3oXRfq8Ow6HCrpDGAS8p84S04MFwBVAUfbe4aXs3 bampaI2LzKgkVywyFP14LSvvdjCfLYfnLy1Z9hm2EHMqNHA2tCGdRhWp2d7aZC1MYFqng0ZS fjPJjqHrI1qPU0p6k9A1GxAtrQlL2v/IUzUnMZkiawFV3qlxMGZf/kTYTUOcJhx1KU4zSLHu 80qO7ldRpp5gHssCAGFbeTu2gp6LxfmaFhLPDBJ1VGfdPx9lUrU/9OcoHczcl5x2Rb8IUZyX 9elzP5WdAU8p5R/DLlOAq24VcabhFtYBCA2dOESLupSfWKNQuJCN/1gz7ysSc+mjnnPV77IO mpszJfkFFJEDNJlGIVKX1vwwygtC/9Ulox8frgbZlRAYAgDc/YbOBFxticVVre0Y3Ujx6Kzb tkgZRlgfdZWbT1W5smncqJxg5qAL8e/yTb3fCe2nJ0jhiP4wggXpMIIE0aADAgECAhMAmNFt CiCF3j+FwQLYtBTmGjzkMA0GCSqGSIb3DQEBCwUAMF0xCzAJBgNVBAYTAlVTMRIwEAYDVQQI DAlUZW5uZXNzZWUxFjAUBgNVBAoMDURlbm5pbmdlci5uZXQxIjAgBgNVBAMMGURlbm5pbmdl ci5OZXQgU2lnbmluZyBJbnQwHhcNMjQwNTEwMTkyNjU5WhcNMjkwNTA5MTkyNjU5WjBXMQsw CQYDVQQGEwJVUzESMBAGA1UECAwJVGVubmVzc2VlMRcwFQYDVQQKDA5LYXJsIERlbm5pbmdl cjEbMBkGA1UEAwwSa2FybEBkZW5uaW5nZXIubmV0MIICIjANBgkqhkiG9w0BAQEFAAOCAg8A MIICCgKCAgEAvh1UssVbSYctzobPjwBkbjv/w4WvQNepeRTwE6+sLnXvc41+X9pa5EclPL4Q l02Vu1m71mSqXGfK9HbWZoivbhefBHOoYb35MSc24PelhwcORbpneWoWc7giQ7QgFlvEe/yj fs8M0H9fgdzFS5m2lwBQbis8kioSjHB2yt/8I1GE4Mvt1Cur9kga6ML5FAQvo8TYN1stdhrE 13FEv/BWCF4FVT4H2Wa2ySW+R1jkKb74SC6Twg98bGCRTShD5bVylh0+0LXNhzaopIDcI/KK jm/j3mRjIlmqbGrSpvJsbjjhjhAYQKE1U8FB5TDU4OkFAibblhQit/KjgspPR2o/vOpVFPER uhZEV1oDGzUJtZlkREIcN2sYBi0p7Y4585ya+b7L10mEenPlyi3eSkGXEuiy/BR2DY6lShwW DPoQ5602TKmttCSwBdWGoLrQ4jEVEVNt4lku2wPbTHF3KpHJU0g7RbcWoUYn10SOxKathkir hF3v9U32+QhPELGwqRrH0sL9rWf0qalRtPDHUYl8TebZmYkFqNeSMlqHijl5f4SsQPSj7gx5 4F19Ntm9ZcvuWTmW8QQGWTKHeMuG+BYkVIUSPe6/ZQsbD/xDx7rkyGfNgWIa4W7Wm/B7kaNq H53tk3wFmNgZQOxMTPF0oTHfW0T2azU6JD0D1AlgoAnSAE0CAwEAAaOCAaYwggGiMDoGCCsG AQUFBwEBBC4wLDAqBggrBgEFBQcwAYYeaHR0cDovL29jc3AuZGVubmluZ2VyLm5ldDo3Nzc3 MAwGA1UdEwEB/wQCMAAwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDAzBglghkgBhvhCAQ0EJhYkT3BlblNTTCBHZW5lcmF0ZWQgQ2xpZW50IENlcnRp ZmljYXRlMB0GA1UdDgQWBBSxJZjVnlYLAT3uzvDYgc4742J6UTCBswYDVR0jBIGrMIGogBQf 5W7FeEHFokBCu8N6TCQf3WEGLqF6pHgwdjELMAkGA1UEBhMCVVMxEjAQBgNVBAgMCVRlbm5l c3NlZTEWMBQGA1UECgwNRGVubmluZ2VyLk5ldDEXMBUGA1UEAwwORGVubmluZ2VyIFJvb3Qx IjAgBgkqhkiG9w0BCQEWE2FkbWluQGRlbm5pbmdlci5uZXSCFFlTx0p0yd5EjVWrmS/STnhD mtC4MB0GA1UdEQQWMBSBEmthcmxAZGVubmluZ2VyLm5ldDANBgkqhkiG9w0BAQsFAAOCAQEA TrQ45/tBN3SiuqItFv/V+CF3h7Hxe0YLsL+A/P+q9ZhxIscaNjaclgQhPA+rUr+l8DGoXJ/w yAl1E0SSBK+9phIc/9xFOBg3rCy4ngubzP+lHS1t03nMCBSUNsu5qPzqLBPiKaPabUu3Gr9o koRezSszgM3/zNJfr8cMO93csCK/fBccsMx5q+3nxB5XeT7UciicjfEzUA4m2mQxBmGk9SSU 147Gy8UmdSq57Tw82KqUrQ1pJ6IOzVPLREpwlqGbHykSU3MwtPYPtfQeFVjvO/XcWvoFQjbV UyhzAqMMYFudxoVLlJQiAgU38OScTLDgKxCO41h7VOjb2mss0zHndzGCBZUwggWRAgEBMHQw XTELMAkGA1UEBhMCVVMxEjAQBgNVBAgMCVRlbm5lc3NlZTEWMBQGA1UECgwNRGVubmluZ2Vy Lm5ldDEiMCAGA1UEAwwZRGVubmluZ2VyLk5ldCBTaWduaW5nIEludAITAJjRbQoghd4/hcEC 2LQU5ho85DANBglghkgBZQMEAgMFAKCCAvIwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAc BgkqhkiG9w0BCQUxDxcNMjQxMDA2MTM1NTMzWjBPBgkqhkiG9w0BCQQxQgRAnLbf74dlsIvp iAsHxNvZ6o6G+qKUBJp/ynvzS4upkVCLT9DPNWQp0KWedRiOhc9B2fem1yilXs/cmOOPXV5j ljCBgwYJKwYBBAGCNxAEMXYwdDBdMQswCQYDVQQGEwJVUzESMBAGA1UECAwJVGVubmVzc2Vl MRYwFAYDVQQKDA1EZW5uaW5nZXIubmV0MSIwIAYDVQQDDBlEZW5uaW5nZXIuTmV0IFNpZ25p bmcgSW50AhMAmNFtCiCF3j+FwQLYtBTmGjzkMIGFBgsqhkiG9w0BCRACCzF2oHQwXTELMAkG A1UEBhMCVVMxEjAQBgNVBAgMCVRlbm5lc3NlZTEWMBQGA1UECgwNRGVubmluZ2VyLm5ldDEi MCAGA1UEAwwZRGVubmluZ2VyLk5ldCBTaWduaW5nIEludAITAJjRbQoghd4/hcEC2LQU5ho8 5DCCAVcGCSqGSIb3DQEJDzGCAUgwggFEMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYI KoZIhvcNAwcwDQYIKoZIhvcNAwICAQUwDQYIKoZIhvcNAwICAQUwBwYFKw4DAgcwDQYIKoZI hvcNAwICAQUwBwYFKw4DAhowCwYJYIZIAWUDBAIBMAsGCWCGSAFlAwQCAjALBglghkgBZQME AgMwCwYJYIZIAWUDBAIEMAsGCWCGSAFlAwQCBzALBglghkgBZQMEAggwCwYJYIZIAWUDBAIJ MAsGCWCGSAFlAwQCCjALBgkqhkiG9w0BAQEwCwYJK4EFEIZIPwACMAgGBiuBBAELADAIBgYr gQQBCwEwCAYGK4EEAQsCMAgGBiuBBAELAzALBgkrgQUQhkg/AAMwCAYGK4EEAQ4AMAgGBiuB BAEOATAIBgYrgQQBDgIwCAYGK4EEAQ4DMA0GCSqGSIb3DQEBAQUABIICAK1mjmXhM1B7TWKg T2yWA2KyzFfGT4PAFaq54o3rbDUtFTlTvZEvGQsnxnz1sCFCtKHB9OHYRUoTf6cavUhyyNAk x7ojvspxluDUhYBmaCKKJO4ZH81ES9Jk595GNeUuCoMQgW1OzF53nLyUnsWbA9nZwHZ/2lo9 a+XmMQ8D7ioxkGKjtOD9hni4nnCuIWZM6d5i77M4dO6uzMFn74sqwqBEepZiF9fHt2IayFsN qHRWwQJHMNWbobHYIWLAHaMCagLq6py5wHMyvWmNFGA5gcIF7vhKpKGbwDnnqq7XhCpUCSYk Ksc5nsu+nKzkG2N8NvrI5E0jFsoH8SLX7BXk90xszxaW2NLMDEx/NV5LHb8qBwDJIVoTV2I2 x7Os19u1K2hq+wyNqyuypNKXm6GfQwJfqxMYh0npbHi/KgvbECsvrg7lQz15TYMZIrgCSeJZ IY/39KQ7a3cjI5NSywgc2Ol6QuoYrkppEHHV1zwoMEeXTCakz4LxcbpFUxmLerqqKSgN1i0U Iw6nfnRFJDntMriSqEXyfd2stKFtp3haK3wm8VtDvGTMFnjaYBwReww+MxttuepbUKieZyPH mdLQkbV2AYpZiyMDTeiYOATxzZgDPUekpzK1GN1rAFeeofwk+NNvNMDu/Lry8pBWh/Bpz+vY oNqNUcEX4M0pL4RAU1F1AAAAAAAA --------------ms020901070407040906000605-- From nobody Sun Oct 6 14:11:30 2024 X-Original-To: stable@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 4XM4331hMVz5Y7Ng for ; Sun, 06 Oct 2024 14:11:43 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pg1-x536.google.com (mail-pg1-x536.google.com [IPv6:2607:f8b0:4864:20::536]) (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 4XM4326lTyz430q for ; Sun, 6 Oct 2024 14:11:42 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pg1-x536.google.com with SMTP id 41be03b00d2f7-7db637d1e4eso2505825a12.2 for ; Sun, 06 Oct 2024 07:11:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1728223901; x=1728828701; 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=M/v/JquHJeh8VamIVR1xxGrDVkPNr9QUmsf1TbrRR84=; b=eM0M54KXWLcb9vgY/IKACxzW0s3RYgJdklU7zNBiOGF7QFkQIgPPUi0HWm5374ehb6 EdJOSTBl0mhDlJMRdkk20QR9TrjAWtqz5fML0YzYcPDqbvdb8TrSqA3v2WbkEN6IZvAY f1NFqHIhjAOm8+b3QXMXEMTpslYrt3LNsbyzrVk0ZpHPlKN2oKd3nLw4+Ww8PzcJ5SpM y2JZL0y8wsrhDmMXpVLD7zutCF/o3GN+aoTuIdsc4S1RPoTAegrT9ZJtLHqtfQZIumdv 74BoeuHVAcDqeYabkg6wo2jyOlFL35z1ClCzUHttHDuxQz52m2idHdyaLaJEn1Z6Aeb1 XxfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1728223901; x=1728828701; 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=M/v/JquHJeh8VamIVR1xxGrDVkPNr9QUmsf1TbrRR84=; b=MSYiMphfu/T/s50VdZPUJEhrDHSArU8VBBbH0r0tQwhP2Ty8PNsWMaK1RZ5H6t5O1f /V8kyoBDUbv+ZtwDGe1na9Uan+zbO4Wb6z+esXzBuMTIhzFlUwRbovkTy7NulcbqpUIy /2mxDOnECSeT5prdGiLUFq1sta98qlXoWtMvUDuPUecwRV6AiZ5SiX9Yb3HRfwOntB3n R9VtMzyv4lNavBK3a2HJMy6E+3zb4THH6QgR3rNd8ThAmh7OvsvOk4ND/d6R3Wfm1gdd SfDgWeVrbF4HS6ILRF53EOnjvgC+BwDWf1Z5sG30B1fbBp8UpYSHy7dfH7xxu8MXBzw6 NmAA== X-Gm-Message-State: AOJu0YyiO4XuMnhLVTAslxobBvIyDA7Y9qgvw4KXQYnbjLmx0XtP8lrA uJB6coOP4vlOspL4lUtHC1D2elpMO1K2EK1jWkgvCClnoAkmJt8LyD/N+rNJrSCsHdGasgOaAQ9 aqKtTZumigbNWHgVJALiSg2AHsS49tv5GmdRmIFoty10FTUFF X-Google-Smtp-Source: AGHT+IFVgI9QLfKQPrVZsZNultYPuHVJLcJjh0muXO5gN+brE6MRS78Llg7/966K4g3pDuOVA8L1KUmFlgLNHRSbUHk= X-Received: by 2002:a17:90b:180d:b0:2d8:8f24:bd88 with SMTP id 98e67ed59e1d1-2e1e6227288mr10536854a91.14.1728223901537; Sun, 06 Oct 2024 07:11:41 -0700 (PDT) List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-stable@freebsd.org Sender: owner-freebsd-stable@FreeBSD.org MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Sun, 6 Oct 2024 08:11:30 -0600 Message-ID: Subject: Re: APU1 bricked on stable/14 - solved To: Karl Denninger Cc: FreeBSD Stable ML Content-Type: multipart/alternative; boundary="000000000000be785a0623cf7b2e" 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:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4XM4326lTyz430q X-Spamd-Bar: ---- --000000000000be785a0623cf7b2e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Great. Just need the APU1 now. Warner On Sun, Oct 6, 2024, 7:56=E2=80=AFAM Karl Denninger wr= ote: > From one of the APUs I have here: > > ---<>--- > Copyright (c) 1992-2023 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 14.1-STABLE stable/14-n268741-9ff3c094fde3 GENERIC amd64 > FreeBSD clang version 18.1.6 (https://github.com/llvm/llvm-project.git > llvmorg-1 > 8.1.6-0-g1118c2e05e67) > VT(vga): resolution 640x480 > CPU: AMD GX-412TC SOC (998.18-MHz K8-class > CPU) > Origin=3D"AuthenticAMD" Id=3D0x730f01 Family=3D0x16 Model=3D0x30 St= epping=3D1 > > Features=3D0x178bfbff MOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT> > > Features2=3D0x3ed8220b AESNI,XSAVE,OSXSAVE,AVX,F16C> > AMD Features=3D0x2e500800 > AMD > Features2=3D0x1d4037ff IBS,SKINIT,WDT,Topology,PNXC,DBE,PTSC,PL2I> > Structured Extended Features=3D0x8 > XSAVE Features=3D0x1 > SVM: NP,NRIP,AFlush,DAssist,NAsids=3D8 > TSC: P-state invariant, performance statistics > real memory =3D 2013061120 (1919 MB) > avail memory =3D 1912287232 (1823 MB) > Event timer "LAPIC" quality 100 > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs > FreeBSD/SMP: 1 package(s) x 4 core(s) > arc4random: WARNING: initial seeding bypassed the cryptographic random > device be > cause it was not yet seeded and the knob 'bypass_before_seeding' was > enabled. > ioapic1: MADT APIC ID 5 !=3D hw id 0 > ioapic0 irqs 0-23 > ioapic1 irqs 24-55 > Launching APs: 3 1 2 > random: entropy device external interface > kbd0 at kbdmux0 > vtvga0: > smbios0: at iomem 0xf3740-0xf375e > smbios0: Version: 2.7 > aesni0: > acpi0: > acpi0: Power Button (fixed) > cpu0: on acpi0 > atrtc0: port 0x70-0x71 irq 8 on acpi0 > atrtc0: registered as a time-of-day clock, resolution 1.000000s > Event timer "RTC" frequency 32768 Hz quality 0 > attimer0: port 0x40-0x43 irq 0 on acpi0 > Timecounter "i8254" frequency 1193182 Hz quality 0 > Event timer "i8254" frequency 1193182 Hz quality 100 > apei0: on acpi0 > hpet0: iomem 0xfed00000-0xfed003ff on acpi0 > Timecounter "HPET" frequency 14318180 Hz quality 950 > Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 > acpi_timer0: <32-bit timer at 3.579545MHz> port 0x818-0x81b on acpi0 > acpi_button0: on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > pcib1: at device 2.2 on pci0 > pcib1: failed to allocate initial I/O port window: 0x1000-0x1fff > pci1: on pcib1 > igb0: port 0x2000-0x201f mem > 0xfe700000-0xfe71ffff,0xfe > 720000-0xfe723fff at device 0.0 on pci1 > igb0: NVM V0.6 imgtype1 > igb0: Using 1024 TX descriptors and 1024 RX descriptors > igb0: Using 2 RX queues 2 TX queues > igb0: Using MSI-X interrupts with 3 vectors > igb0: Ethernet address: 00:0d:b9:46:71:88 > igb0: netmap queues/slots: TX 2/1024, RX 2/1024 > pcib2: at device 2.4 on pci0 > pcib2: failed to allocate initial I/O port window: 0x2000-0x2fff > pci2: on pcib2 > igb1: port 0x4000-0x401f mem > 0xfe800000-0xfe81ffff,0xfe > 820000-0xfe823fff at device 0.0 on pci2 > igb1: NVM V0.6 imgtype1 > igb1: Using 1024 TX descriptors and 1024 RX descriptors > igb1: Using 2 RX queues 2 TX queues > igb1: Using MSI-X interrupts with 3 vectors > igb1: Ethernet address: 00:0d:b9:46:71:89 > igb1: netmap queues/slots: TX 2/1024, RX 2/1024 > pci0: at device 8.0 (no driver attached) > xhci0: mem 0xfeb22000-0xfeb23fff at device > 16.0 on > pci0 > xhci0: 32 bytes context size, 64-bit DMA > usbus0 on xhci0 > usbus0: 5.0Gbps Super Speed USB v3.0 > ahci0: port > 0x3010-0x3017,0x3020-0x3023,0x30 > 18-0x301f,0x3024-0x3027,0x3000-0x300f mem 0xfeb25000-0xfeb253ff at device > 17.0 o > n pci0 > ahci0: AHCI v1.30 with 2 6Gbps ports, Port Multiplier supported with FBS > ahcich0: at channel 0 on ahci0 > ahcich1: at channel 1 on ahci0 > ehci0: mem 0x80000000-0x800000ff at device > 18.0 on > pci0 > usbus1: EHCI version 1.0 > usbus1 on ehci0 > usbus1: 480Mbps High Speed USB v2.0 > ehci1: mem 0xfeb25400-0xfeb254ff at device > 19.0 on > pci0 > usbus2: EHCI version 1.0 > usbus2 on ehci1 > usbus2: 480Mbps High Speed USB v2.0 > isab0: at device 20.3 on pci0 > isa0: on isab0 > sdhci_pci0: mem 0xfeb25500-0xfeb255ff at device 20.7 on > pci0 > sdhci_pci0: 1 slot(s) allocated > mmc0: on sdhci_pci0 > uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 > ns8250: UART FCR is broken > uart0: console (115200,n,8,1) > orm0: at iomem 0xef000-0xeffff pnpid ORM0000 on isa0 > hwpstate0: on cpu0 > Timecounter "TSC" frequency 998127234 Hz quality 1000 > Timecounters tick every 1.000 msec > ugen2.1: at usbus2 > ugen1.1: at usbus1 > ugen0.1: at usbus0 > uhub0 on usbus2 > uhub0: on usbus2 > uhub1 on usbus0 > uhub1: on usbus0 > uhub2 on usbus1 > uhub2: on usbus1 > mmcsd0: 16GB at mmc0 > 50.0MHz/4b > it/65535-block > Trying to mount root from ufs:/dev/mmcsd0s1a [ro]... > > .... > > This is an APU2; I've got a bunch of them in the field (one is my own > personal firewall/gateway) but they're EOL'd as the SOC was deprecated. > They run quite well and I'm on stable/14 with them at present. > > > On 10/6/2024 9:47 AM, Warner Losh wrote: > > > > On Sun, Oct 6, 2024 at 6:35=E2=80=AFAM Stefan Hegnauer > wrote: > >> I have a few pc-engines APU1 appliances running in headless mode under >> Nanobsd. Maintenance is by means of direct COM port connection. >> After a recent update a few weeks back I was not able to connect by COM >> port anymore - console output and input went away after booting and >> before single- or multi-user mode would start. Even re-flashing the >> SDcard with a fresh image did not help. >> >> After some longish trials and errors it turned out that both >> - commit 74b9fc7a 'amd64 GENERIC: Switch uart hints from "isa" to >> "acpi"' as well as >> - commit 4ba4cfaf 'acpi: Narrow workaround for broken interrupt settings >> on x86' >> broke things for me. Restoring hints and setting >> hw.acpi.override_isa_irq_polarity=3D1 in /boot/loader.conf.local restore= d >> working order. >> >> I agree that APU1 is EOL, however I would have expected an entry to >> UPDATING for such a POLA violation. >> > > Likely, but really really old gear like this is going to hit edge cases > that > developers haven't seen. The hint thing wasn't though to actually > negatively > affect any deployed hardware since it dealt with details that changed 15 = or > 20 years ago... > > Looks like the APU1 used coreboot which at the time was trailing adaptati= on > of ACPI, so it makes sense... I knew that Soekris boxes had issues, but > they > are another 5 or 10 years older than the APUs and mine sadly isn't > operational. > > So I can write a better UPDATING entry, can you share with me the dmesg > from both APU1 and APU2? > > Warner > > >> Note that pc-engines APU2 models are not affected as the BIOS ACPI >> tables contain correct UART descriptions. >> >> - Stefan >> >> -- > Karl Denninger > karl@denninger.net > *The Market Ticker* > *[S/MIME encrypted email preferred]* > --000000000000be785a0623cf7b2e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Great. Just need the APU1 now.

Warner=C2=A0

<= div dir=3D"ltr" class=3D"gmail_attr">On Sun, Oct 6, 2024, 7:56=E2=80=AFAM K= arl Denninger <karl@denninger.net<= /a>> wrote:
=20 =20 =20

From one of the APUs I have here:

---<<BOOT>>---
Copyright (c) 1992-2023 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The Regents of the Univers= ity of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 14.1-STABLE stable/14-n268741-9ff3c094fde3 GENERIC amd64
FreeBSD clang version 18.1.6 (https://github.com/llvm/llvm-project.git llvmorg-= 1
8.1.6-0-g1118c2e05e67)
VT(vga): resolution 640x480
CPU: AMD GX-412TC SOC=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (998.18-MHz K8-class CPU)
=C2=A0 Origin=3D"AuthenticAMD"=C2=A0 Id=3D0x730f01=C2=A0 Fa= mily=3D0x16=C2=A0 Model=3D0x30=C2=A0 Stepping=3D1
=C2=A0 Features=3D0x178bfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,P= GE,MCA,C
MOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT>
=C2=A0 Features2=3D0x3ed8220b<SSE3,PCLMULQDQ,MON,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE= ,POPCNT,
AESNI,XSAVE,OSXSAVE,AVX,F16C>
=C2=A0 AMD Features=3D0x2e500800<SYSCALL,NX,MMX+,FFXSR,Page1GB,RDTSCP,LM><= br> =C2=A0 AMD Features2=3D0x1d4037ff<LAHF,CMP,SVM,ExtAPIC,CR8,ABM,SSE4A,MAS,Prefetch,O= SVW,
IBS,SKINIT,WDT,Topology,PNXC,DBE,PTSC,PL2I>
=C2=A0 Structured Extended Features=3D0x8<BMI1>
=C2=A0 XSAVE Features=3D0x1<XSAVEOPT>
=C2=A0 SVM: NP,NRIP,AFlush,DAssist,NAsids=3D8
=C2=A0 TSC: P-state invariant, performance statistics
real memory=C2=A0 =3D 2013061120 (1919 MB)
avail memory =3D 1912287232 (1823 MB)
Event timer "LAPIC" quality 100
ACPI APIC Table: <CORE=C2=A0=C2=A0 COREBOOT>
FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
FreeBSD/SMP: 1 package(s) x 4 core(s)
arc4random: WARNING: initial seeding bypassed the cryptographic random device be
cause it was not yet seeded and the knob 'bypass_before_seeding&#= 39; was enabled.
ioapic1: MADT APIC ID 5 !=3D hw id 0
ioapic0 <Version 2.1> irqs 0-23
ioapic1 <Version 2.1> irqs 24-55
Launching APs: 3 1 2
random: entropy device external interface
kbd0 at kbdmux0
vtvga0: <VT VGA driver>
smbios0: <System Management BIOS> at iomem 0xf3740-0xf375e
smbios0: Version: 2.7
aesni0: <AES-CBC,AES-CCM,AES-GCM,AES-ICM,AES-XTS>
acpi0: <CORE COREBOOT>
acpi0: Power Button (fixed)
cpu0: <ACPI CPU> on acpi0
atrtc0: <AT realtime clock> port 0x70-0x71 irq 8 on acpi0
atrtc0: registered as a time-of-day clock, resolution 1.000000s
Event timer "RTC" frequency 32768 Hz quality 0
attimer0: <AT timer> port 0x40-0x43 irq 0 on acpi0
Timecounter "i8254" frequency 1193182 Hz quality 0
Event timer "i8254" frequency 1193182 Hz quality 100
apei0: <ACPI Platform Error Interface> on acpi0
hpet0: <High Precision Event Timer> iomem 0xfed00000-0xfed003ff on acpi0
Timecounter "HPET" frequency 14318180 Hz quality 950
Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x818-0x81b on acpi0
acpi_button0: <Power Button> on acpi0
pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
pci0: <ACPI PCI bus> on pcib0
pcib1: <ACPI PCI-PCI bridge> at device 2.2 on pci0
pcib1: failed to allocate initial I/O port window: 0x1000-0x1fff
pci1: <ACPI PCI bus> on pcib1
igb0: <Intel(R) I211 (Copper)> port 0x2000-0x201f mem 0xfe700000-0xfe71ffff,0xfe
720000-0xfe723fff at device 0.0 on pci1
igb0: NVM V0.6 imgtype1
igb0: Using 1024 TX descriptors and 1024 RX descriptors
igb0: Using 2 RX queues 2 TX queues
igb0: Using MSI-X interrupts with 3 vectors
igb0: Ethernet address: 00:0d:b9:46:71:88
igb0: netmap queues/slots: TX 2/1024, RX 2/1024
pcib2: <ACPI PCI-PCI bridge> at device 2.4 on pci0
pcib2: failed to allocate initial I/O port window: 0x2000-0x2fff
pci2: <ACPI PCI bus> on pcib2
igb1: <Intel(R) I211 (Copper)> port 0x4000-0x401f mem 0xfe800000-0xfe81ffff,0xfe
820000-0xfe823fff at device 0.0 on pci2
igb1: NVM V0.6 imgtype1
igb1: Using 1024 TX descriptors and 1024 RX descriptors
igb1: Using 2 RX queues 2 TX queues
igb1: Using MSI-X interrupts with 3 vectors
igb1: Ethernet address: 00:0d:b9:46:71:89
igb1: netmap queues/slots: TX 2/1024, RX 2/1024
pci0: <encrypt/decrypt> at device 8.0 (no driver attached)
xhci0: <AMD FCH USB 3.0 controller> mem 0xfeb22000-0xfeb23fff at device 16.0 on
pci0
xhci0: 32 bytes context size, 64-bit DMA
usbus0 on xhci0
usbus0: 5.0Gbps Super Speed USB v3.0
ahci0: <AMD Hudson-2 AHCI SATA controller> port 0x3010-0x3017,0x3020-0x3023,0x30
18-0x301f,0x3024-0x3027,0x3000-0x300f mem 0xfeb25000-0xfeb253ff at device 17.0 o
n pci0
ahci0: AHCI v1.30 with 2 6Gbps ports, Port Multiplier supported with FBS
ahcich0: <AHCI channel> at channel 0 on ahci0
ahcich1: <AHCI channel> at channel 1 on ahci0
ehci0: <AMD FCH USB 2.0 controller> mem 0x80000000-0x800000ff at device 18.0 on
pci0
usbus1: EHCI version 1.0
usbus1 on ehci0
usbus1: 480Mbps High Speed USB v2.0
ehci1: <AMD FCH USB 2.0 controller> mem 0xfeb25400-0xfeb254ff at device 19.0 on
pci0
usbus2: EHCI version 1.0
usbus2 on ehci1
usbus2: 480Mbps High Speed USB v2.0
isab0: <PCI-ISA bridge> at device 20.3 on pci0
isa0: <ISA bus> on isab0
sdhci_pci0: <Generic SD HCI> mem 0xfeb25500-0xfeb255ff at device 20.7 on pci0
sdhci_pci0: 1 slot(s) allocated
mmc0: <MMC/SD bus> on sdhci_pci0
uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
ns8250: UART FCR is broken
uart0: console (115200,n,8,1)
orm0: <ISA Option ROM> at iomem 0xef000-0xeffff pnpid ORM0000 on isa0
hwpstate0: <Cool`n'Quiet 2.0> on cpu0
Timecounter "TSC" frequency 998127234 Hz quality 1000
Timecounters tick every 1.000 msec
ugen2.1: <AMD EHCI root HUB> at usbus2
ugen1.1: <AMD EHCI root HUB> at usbus1
ugen0.1: <AMD XHCI root HUB> at usbus0
uhub0 on usbus2
uhub0: <AMD EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus2
uhub1 on usbus0
uhub1: <AMD XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0
uhub2 on usbus1
uhub2: <AMD EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus1
mmcsd0: 16GB <SDHC SL16G 8.0 SN A4981A22 MFG 01/2017 by 3 SD> at mmc0 50.0MHz/4b
it/65535-block
Trying to mount root from ufs:/dev/mmcsd0s1a [ro]...

....

This is an APU2; I've got a bunch of them in the field (one is m= y own personal firewall/gateway) but they're EOL'd as the SOC w= as deprecated.=C2=A0 They run quite well and I'm on stable/14 with t= hem at present.


On 10/6/2024 9:47 AM, Warner Losh wrote:
=20


On Sun, Oct 6, 2024 at 6:35=E2=80=AFAM Stefan Hegnauer <stefan.hegnauer@gmx.ch<= /a>> wrote:
I have a few pc-engines APU1 appliances running in headless mode under
Nanobsd. Maintenance is by means of=C2=A0 direct COM port connection.
After a recent update a few weeks back I was not able to connect by COM
port anymore - console output and input went away after booting and
before single- or multi-user mode would start. Even re-flashing the
SDcard with a fresh image did not help.

After some longish trials and errors it turned out that both - commit 74b9fc7a 'amd64 GENERIC: Switch uart hints from "isa" to
"acpi"' as well as
- commit 4ba4cfaf 'acpi: Narrow workaround for broken interrupt settings
on x86'
broke things for me. Restoring hints and setting
hw.acpi.override_isa_irq_polarity=3D1 in /boot/loader.conf.local restored
working order.

I agree that APU1 is EOL, however I would have expected an entry to
UPDATING for such a POLA violation.

Likely, but really really old gear like this is going to hit edge cases that
developers haven't seen. The hint thing wasn't thoug= h to actually negatively
affect any deployed hardware since it dealt with details that changed 15 or
20 years ago...

Looks like the APU1 used coreboot which at the time was trailing adaptation
of ACPI, so it makes sense... I knew that Soekris boxes had issues, but they
are another 5 or 10 years older than the APUs and mine sadly isn't operational.

So I can write a better UPDATING entry, can you share with me the dmesg
from both APU1 and APU2?

Warner
=C2=A0
Note that pc-engines APU2 models are not affected as the BIOS ACPI
tables contain correct UART descriptions.

- Stefan

--
Karl Denninger
karl@denninger.net
The Market Ticker
[S/MIME encrypted email preferred]
--000000000000be785a0623cf7b2e-- From nobody Sun Oct 6 14:23:33 2024 X-Original-To: stable@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 4XM4Jt5CfSz5Y8TP for ; Sun, 06 Oct 2024 14:23:42 +0000 (UTC) (envelope-from pi@freebsd.org) Received: from fc.opsec.eu (fc.opsec.eu [IPv6:2001:14f8:200:4::4]) by mx1.freebsd.org (Postfix) with ESMTP id 4XM4Jt1C1Hz44Qw for ; Sun, 6 Oct 2024 14:23:42 +0000 (UTC) (envelope-from pi@freebsd.org) Authentication-Results: mx1.freebsd.org; none Received: from pi (uid 104) (envelope-from pi@freebsd.org) id 8a99b by fc.opsec.eu (DragonFly Mail Agent v0.13+ on fc.opsec.eu); Sun, 06 Oct 2024 16:23:33 +0200 Date: Sun, 6 Oct 2024 16:23:33 +0200 From: Kurt Jaeger To: Warner Losh Cc: Karl Denninger , FreeBSD Stable ML Subject: Re: APU1 bricked on stable/14 - solved Message-ID: References: List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-stable@freebsd.org Sender: owner-freebsd-stable@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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:12502, ipnet:2001:14f8::/32, country:DE] X-Rspamd-Queue-Id: 4XM4Jt1C1Hz44Qw X-Spamd-Bar: ---- Hi! > Great. Just need the APU1 now. Here's some from one of my apu1 boxes. https://people.freebsd.org/~pi/apu1/dmesg.boot https://people.freebsd.org/~pi/apu1/dmide.txt -- pi@FreeBSD.org +49 171 3101372 Now what ? From nobody Sun Oct 6 19:14:24 2024 X-Original-To: freebsd-stable@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 4XMBml3q6Jz5YRZh for ; Sun, 06 Oct 2024 19:14:47 +0000 (UTC) (envelope-from stefan.hegnauer@gmx.ch) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mout.gmx.net", Issuer "Telekom Security ServerID OV Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4XMBmk6vvTz4YJC for ; Sun, 6 Oct 2024 19:14:46 +0000 (UTC) (envelope-from stefan.hegnauer@gmx.ch) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.ch; s=s31663417; t=1728242083; x=1728846883; i=stefan.hegnauer@gmx.ch; bh=Y0X0DsbssPhTkYJhaaJdEqAOTpB9NAxv/YyEqGTrKF8=; h=X-UI-Sender-Class:Content-Type:Message-ID:Date:MIME-Version: Subject:To:Cc:References:From:In-Reply-To:cc: content-transfer-encoding:content-type:date:from:message-id: mime-version:reply-to:subject:to; b=cT/NC0sTcEp9AJY4dLNxdRQhz6kcSZPBzFC4EVsVl1948QUjHtoulRhBhqeZeRvV yHaypaJmOnxFeERdE1rMy9KI6GQhbtPZMC+DMIdT5Hb//Dqr3irr2iHPZeVavk15q MtUdapa1tCm2Z5tb6GzuWev/KXvH0g1qUUF/1pVO1EurX053Keok8kBtlvrVJpA+r 4omlPj86AIyerYc8PznTWbmE56tOq4FlSMecoVyA8vWi8AifXeEFuavoDhHJSe9Yl vLHYfOl4PHkOAXMZnA9jLl9pm3s1ZG63dhyaYZwKeLHHw6lNYgkooBfMlEd1Bx5L0 O+NZXwoDQmlQp+3N3g== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from [192.168.20.55] ([84.73.192.40]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MTzay-1tNH3h05Hm-00TyzN; Sun, 06 Oct 2024 21:14:43 +0200 Content-Type: multipart/alternative; boundary="------------W4b11FnXwJkWtate8VbeEWZF" Message-ID: Date: Sun, 6 Oct 2024 21:14:24 +0200 List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-stable@freebsd.org Sender: owner-freebsd-stable@FreeBSD.org MIME-Version: 1.0 User-Agent: Betterbird (Windows) Subject: Re: APU1 bricked on stable/14 - solved To: Warner Losh Cc: freebsd-stable@freebsd.org References: Content-Language: en-US From: Stefan Hegnauer In-Reply-To: X-Provags-ID: V03:K1:4+Ddeb218bLLlnydX0ZFnJzkc8AP/Z6m+sziJDSgmahoY835cCZ 9oEbkiC/XFXpaDFgyWHqXl9WmVw/mLvPIqT+htUCQRHI2dty1LIENq7oxhPD/SbZ35/66Y6 A+fp61Lb+Mb0RHGAc86FTxOzdtBGVnNdgr9j94RKQeF7N80Qv0ILfM3DzOFHKHqmpXsf9af Pgy/Fx8xaWvd3Uf2gcBVA== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:cBJT8vesoWE=;sJ0ehzLRBb8UUmDRmhZn2CQ5IX6 PCGUCJLDXT16/fyxS+jVQLq9K+kIU7BUI/UTaFCNDypLiaJKJ5IZ1ZxFnEaeuiXyguCzVHHbL HrJaLWXIGF3EmcfUAKxiLtvGNipnMpXNZ7BfNRIPlyFwI4+O/5hSeYi9q+NvY3v+0uD1M+AcY MkcFlAorRFphe/tDFrmDjxVYHjP0nBbuRgJWM/RUi6pduFoIIqS5sQdU5ZDsGIrIvqYtzifPh qiBxmGfTwYXUI5e38Zz8OFsLFa8UkuynrUnU1bu0J+88OrBsTfqey4S+qb38yrWjWRUIH05iD 8Enx3f0E5MFDsTm5nvLiZtiD1nLdruMCuip8hDRNvEiOtLjdj/fuIl0+yl0Qth13sLtyJh6z+ 6rF2EQ1B8xdRtublL4w9N7jZvlcUj+oDr9EXxrjBy7ntvpmw0/aWALn4iaKGSzQFEy5/kyZiL OXBZ0aGpVCyT7c17hT7E4tlDYNdoaOii8VXULaDiMbJTUSBhm/lX6fbaUDiivWur9sqUfgLIJ 3qpvmum1diBlFk7gyN8m5tc0INcrzjjfH+BXDb4ZRCHbgOuC1yD0jW1CkJpmdLzm2jmVPfRjo IMKPxuMiFUkKaPQenqNhnDYLJ289vOv+9UKFyC0k2rrvXD9B+X8uaB7n28uRCOXitBKCArRpm uQwZbM4zi1pFz0Mmq2KUYw9g98wMy6DDmA7umjiW9bIPhrb47VswHELAN/zjAHDAEdNSl7yeo ajzOlUmJoZjTOBbi2V91museB05y4hRJhhU9jn/7yYthMolTbQzAkcw7PfD5JShsNCNSEzco5 kOwvT+0LGbNS9pR2cf5ZsVLg== 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:8560, ipnet:212.227.0.0/16, country:DE] X-Rspamd-Queue-Id: 4XMBmk6vvTz4YJC X-Spamd-Bar: ---- This is a multi-part message in MIME format. --------------W4b11FnXwJkWtate8VbeEWZF Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable On 06.10.2024 15:47, Warner Losh wrote: > > > On Sun, Oct 6, 2024 at 6:35=E2=80=AFAM Stefan Hegnauer > wrote: > > I have a few pc-engines APU1 appliances running in headless mode und= er > Nanobsd. Maintenance is by means of=C2=A0 direct COM port connection= . > After a recent update a few weeks back I was not able to connect > by COM > port anymore - console output and input went away after booting and > before single- or multi-user mode would start. Even re-flashing the > SDcard with a fresh image did not help. > > After some longish trials and errors it turned out that both > - commit 74b9fc7a 'amd64 GENERIC: Switch uart hints from "isa" to > "acpi"' as well as > - commit 4ba4cfaf 'acpi: Narrow workaround for broken interrupt > settings > on x86' > broke things for me. Restoring hints and setting > hw.acpi.override_isa_irq_polarity=3D1 in /boot/loader.conf.local > restored > working order. > > I agree that APU1 is EOL, however I would have expected an entry to > UPDATING for such a POLA violation. > > > Likely, but really really old gear like this is going to hit edge > cases that > developers haven't seen. The hint thing wasn't though to actually > negatively > affect any deployed hardware since it dealt with details that changed > 15 or > 20 years ago... > > Looks like the APU1 used coreboot which at the time was trailing > adaptation > of ACPI, so it makes sense... I knew that Soekris boxes had issues, > but they > are another 5 or 10 years older than the APUs and mine sadly isn't > operational. > > So I can write a better UPDATING entry, can you share with me the dmesg > from both APU1 and APU2? > > Warner > > Note that pc-engines APU2 models are not affected as the BIOS ACPI > tables contain correct UART descriptions. > > - Stefan > Warner: thanks for the quick reply. Not so really, really old in my view - the BIOS=C2=A0is from ~August 2022 (APU1). And yes, it uses coreboot: =C2=A0=C2=A0=C2=A0 PC Engines apu1 =C2=A0=C2=A0=C2=A0 coreboot build 20220822 =C2=A0=C2=A0=C2=A0 BIOS version v4.17.0.3 =C2=A0=C2=A0=C2=A0 SeaBIOS (version rel-1.16.0.1-0-g77603a32) From verbose boot, dmesg -a: - APU1, original/faulty from today: https://hegnauer.selfhost.eu/web/computing/apu1c4_3mdeb_v4_17_0_3_std.txt - APU1, fixed in loader.conf.local: https://hegnauer.selfhost.eu/web/computing/apu1c4_3mdeb_v4_17_0_3_fixed.tx= t - APU2 (has no problems): https://hegnauer.selfhost.eu/web/computing/apu2d4_3mdeb_v4_19_0_1.txt Let me know if you need additional information. - Stefan --------------W4b11FnXwJkWtate8VbeEWZF Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 06.10.2024 15:47, Warner Losh wrote:


O= n Sun, Oct 6, 2024 at 6:35=E2=80=AFAM Stefan Hegnauer <s= tefan.hegnauer@gmx.ch> wrote:
I have a few pc-engines APU1 appliances running in headless mode under
Nanobsd. Maintenance is by means of=C2=A0 direct COM port connection.
After a recent update a few weeks back I was not able to connect by COM
port anymore - console output and input went away after booting and
before single- or multi-user mode would start. Even re-flashing the
SDcard with a fresh image did not help.
After some longish trials and errors it turned out that both
- commit 74b9fc7a 'amd64 GENERIC: Switch uart hints from "isa" to
"acpi"' as well as
- commit 4ba4cfaf 'acpi: Narrow workaround for broken interrupt settings
on x86'
broke things for me. Restoring hints and setting
hw.acpi.override_isa_irq_polarity=3D1 in /boot/loader.conf.local restored
working order.
I agree that APU1 is EOL, however I would have expected an entry to
UPDATING for such a POLA violation.

Likely, but really really old gear like this is going to hit edge cases that
developers haven't seen. The hint thing wasn't though to actually negatively
affect any deployed hardware since it dealt with details that changed 15 or
20 years ago...

Looks like the APU1 used coreboot which at the time was trailing adaptation
of ACPI, so it makes sense... I knew that Soekris boxes had issues, but they
are another 5 or 10 years older than the APUs and mine sadly isn't operational.

So I can write a better UPDATING entry, can you share with me the dmesg
from both APU1 and APU2?

Warner
=C2=A0
Note that pc-engines APU2 models are not affected as the BIOS ACPI
tables contain correct UART descriptions.
- Stefan
Warner: thanks for the quick reply. Not so really, really old in my view - the BIOS=C2=A0is from ~August 2022 (APU1). And yes, it uses coreboot:
=C2=A0=C2=A0=C2=A0 PC Engines apu1
=C2=A0=C2=A0=C2=A0 coreboot build 20220822
=C2=A0=C2=A0=C2=A0 BIOS version v4.17.0.3
=C2=A0=C2=A0=C2=A0 SeaBIOS (version rel-1.16.0.1-0-g77603a32)

From verbose boot, dmesg -a:
- APU1, original/faulty from today:=C2=A0https://hegnauer.selfhost.eu/web/c= omputing/apu1c4_3mdeb_v4_17_0_3_std.txt
- APU1, fixed in loader.conf.local:=C2=A0https://hegnauer.selfhost.eu/web/c= omputing/apu1c4_3mdeb_v4_17_0_3_fixed.txt
- APU2 (has no problems): https://hegnauer.selfhost.eu/web/c= omputing/apu2d4_3mdeb_v4_19_0_1.txt

Let me know if you need additional information.

- Stefan
 --------------W4b11FnXwJkWtate8VbeEWZF-- From nobody Sun Oct 6 19:39:12 2024 X-Original-To: freebsd-stable@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 4XMCKM51ygz5YSg3 for ; Sun, 06 Oct 2024 19:39:35 +0000 (UTC) (envelope-from stefan.hegnauer@gmx.ch) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mout.gmx.net", Issuer "Telekom Security ServerID OV Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4XMCKL2xNHz4bn8 for ; Sun, 6 Oct 2024 19:39:34 +0000 (UTC) (envelope-from stefan.hegnauer@gmx.ch) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmx.ch header.s=s31663417 header.b=mpf9Gl63; spf=pass (mx1.freebsd.org: domain of stefan.hegnauer@gmx.ch designates 212.227.15.19 as permitted sender) smtp.mailfrom=stefan.hegnauer@gmx.ch; dmarc=pass (policy=quarantine) header.from=gmx.ch DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.ch; s=s31663417; t=1728243571; x=1728848371; i=stefan.hegnauer@gmx.ch; bh=+h0DecMvIHUdBA4vJGlHY+B3k3nSX+g+oi0cED+d6Lo=; h=X-UI-Sender-Class:Content-Type:Message-ID:Date:MIME-Version: Subject:From:To:Cc:References:In-Reply-To:cc: content-transfer-encoding:content-type:date:from:message-id: mime-version:reply-to:subject:to; b=mpf9Gl63r6D7rw6U3MoIlW9aWNcjQUPNNk+8e7gegUdop5Z6Kop64NKjZrHDcRfu LloL607ydawAtnaN6lR2F85vb9NrJvK92Bzf844nD302QbbdyWFgle7qHaYr54hJn O8qsGSkjC7PxeSJsJ/0mRGnv5x51gHDJTWgnQwlsAHVdbVAbOQsImd2jIg5Nm8L0+ cmwPWpcPIDk7u8pB2T1QOe/kaNnSVSE3PyVjFyk4AhCgdQYixLe1TVKZu57Uf6D7+ bBNLc6CPFzcm8/yHSlAUtVnJKxNUdm0RrYShzLDQ/vTdgAGy1uxyoIuZPqrjV+rg0 7OZiGf2/xmFmSCyqjA== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from [192.168.20.55] ([84.73.192.40]) by mail.gmx.net (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MfpOd-1tdUcc1b0D-00cG2c; Sun, 06 Oct 2024 21:39:31 +0200 Content-Type: multipart/alternative; boundary="------------7T2SWUvVFJJ1WVFzx0ond7Se" Message-ID: Date: Sun, 6 Oct 2024 21:39:12 +0200 List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-stable@freebsd.org Sender: owner-freebsd-stable@FreeBSD.org MIME-Version: 1.0 User-Agent: Betterbird (Windows) Subject: Re: APU1 bricked on stable/14 - solved From: Stefan Hegnauer To: Warner Losh Cc: freebsd-stable@freebsd.org References: Content-Language: en-US In-Reply-To: X-Provags-ID: V03:K1:bo/xikJB/4eD1pvbQy7XzwNFzSzYqqc8jxFWKWvp+8tbVe4KU95 4HwYnnoMjWsymVQs7XUSVVenv9MspSQRF24pHqG/c0izOkPXCMlmqo9NhMRI95wdWWBztzT rpMzH1FB/G44TcdpsV2Nj+NF+UQA6SIjiaF5L6Fr8fOWM6KNqEYZAJw1KmqEjtzUlY0pGu3 B9RY1lufBMHVx5aAL0MAQ== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:Wscr0rtyzj4=;beaQWT3p9mRxFQprEJU2v9Oz0L/ HKY1ZiJcy5wNt1c5Ghe27LV5AadkAruhx9W3cq51BHzFMJtBoyHkcT+4hS8yWVpPWBNRQh344 QRF2fR5iCzCPpQfljQhquyAEOU8bG2mgW2kDce7xVyUU5tCN179j+jXyAl1F87OU/OSzgQMxB IiOU0wwwX41zN5l5MIZh1unFqVpNdz0AyFBuvNNRu9+lfsKa5BHweWqz834iC8a2kzK5axvI0 KNDV3t5SxObM5m2q0MfABrrLPj0FABIAZGlwvP0T/sJ1B4EdTQIrgsE8CtrV2/ktvVCSFSiqd P6vZJU6GLMJE196h/oeujblLjfI96p7KiStdZoBm+USbvLrWAt+EeDD+QF/w7x0pq+rnOIIx/ /Y4i0RD2PNK4hGMQWeUJ/32cxQA0QttLgHHPe/POsx6fX9x5kvQzy4CypnEVsARC1NojoHqey m/Xq4Nhnx1MNSB9XY0DJdkE1x/12qAizUY5576u7xz7UUy4GMd8GchOBj2PPIfC/ZUm1bypOg 9YEGKN63KS2T/wIAcBLZCktCORiAdAWSq5CguSL5OrXxZIWGW5Y9UjC+n4gI7rZaDxbBHpB1f 3XBDupvEW/b9sR8zUu28HPdOiIqq0lIwrrXzmm2eEFtB1a7et3oRuSpDpNp3/tg80/fIxLlGF d0lIRdTX7YHc4qnw+VQwnAgNJxK7LWxIzt8dfdAGZmav8aJ/J1wuXwmTBpwBQrTr3QsuUtxcG 3o8dwkY7rshLWRbHzXrtsmkWpkRc0N7XX29/SyUaw1yHQbzYVl5lANftULmcTuvVTjj2CBHji g13SJO974XTl3uDlD3qP5FehlQnzzqYevhiE2VuMr2CdI= X-Spamd-Result: default: False [-3.87 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.88)[-0.879]; DMARC_POLICY_ALLOW(-0.50)[gmx.ch,quarantine]; R_SPF_ALLOW(-0.20)[+a:mout.gmx.net]; R_DKIM_ALLOW(-0.20)[gmx.ch:s=s31663417]; ONCE_RECEIVED(0.10)[]; RCVD_IN_DNSWL_LOW(-0.10)[212.227.15.19:from]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; XM_UA_NO_VERSION(0.01)[]; RCVD_TLS_ALL(0.00)[]; DKIM_TRACE(0.00)[gmx.ch:+]; RCPT_COUNT_TWO(0.00)[2]; TO_DN_SOME(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[gmx.ch]; MLMMJ_DEST(0.00)[freebsd-stable@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[212.227.15.19:from]; ASN(0.00)[asn:8560, ipnet:212.227.0.0/16, country:DE]; FREEMAIL_ENVFROM(0.00)[gmx.ch] X-Rspamd-Queue-Id: 4XMCKL2xNHz4bn8 X-Spamd-Bar: --- This is a multi-part message in MIME format. --------------7T2SWUvVFJJ1WVFzx0ond7Se Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable On 06.10.2024 21:14, Stefan Hegnauer wrote: > On 06.10.2024 15:47, Warner Losh wrote: >> >> >> On Sun, Oct 6, 2024 at 6:35=E2=80=AFAM Stefan Hegnauer >> wrote: >> >> I have a few pc-engines APU1 appliances running in headless mode >> under >> Nanobsd. Maintenance is by means of=C2=A0 direct COM port connectio= n. >> After a recent update a few weeks back I was not able to connect >> by COM >> port anymore - console output and input went away after booting and >> before single- or multi-user mode would start. Even re-flashing the >> SDcard with a fresh image did not help. >> >> After some longish trials and errors it turned out that both >> - commit 74b9fc7a 'amd64 GENERIC: Switch uart hints from "isa" to >> "acpi"' as well as >> - commit 4ba4cfaf 'acpi: Narrow workaround for broken interrupt >> settings >> on x86' >> broke things for me. Restoring hints and setting >> hw.acpi.override_isa_irq_polarity=3D1 in /boot/loader.conf.local >> restored >> working order. >> >> I agree that APU1 is EOL, however I would have expected an entry to >> UPDATING for such a POLA violation. >> >> >> Likely, but really really old gear like this is going to hit edge >> cases that >> developers haven't seen. The hint thing wasn't though to actually >> negatively >> affect any deployed hardware since it dealt with details that changed >> 15 or >> 20 years ago... >> >> Looks like the APU1 used coreboot which at the time was trailing >> adaptation >> of ACPI, so it makes sense... I knew that Soekris boxes had issues, >> but they >> are another 5 or 10 years older than the APUs and mine sadly isn't >> operational. >> >> So I can write a better UPDATING entry, can you share with me the dmesg >> from both APU1 and APU2? >> >> Warner >> >> Note that pc-engines APU2 models are not affected as the BIOS ACPI >> tables contain correct UART descriptions. >> >> - Stefan >> > Warner: thanks for the quick reply. Not so really, really old in my > view - the BIOS=C2=A0is from ~August 2022 (APU1). And yes, it uses coreb= oot: > =C2=A0=C2=A0=C2=A0 PC Engines apu1 > =C2=A0=C2=A0=C2=A0 coreboot build 20220822 > =C2=A0=C2=A0=C2=A0 BIOS version v4.17.0.3 > =C2=A0=C2=A0=C2=A0 SeaBIOS (version rel-1.16.0.1-0-g77603a32) > > From verbose boot, dmesg -a: > - APU1, original/faulty from today: > https://hegnauer.selfhost.eu/web/computing/apu1c4_3mdeb_v4_17_0_3_std.tx= t > - APU1, fixed in loader.conf.local: > https://hegnauer.selfhost.eu/web/computing/apu1c4_3mdeb_v4_17_0_3_fixed.= txt > - APU2 (has no problems): > https://hegnauer.selfhost.eu/web/computing/apu2d4_3mdeb_v4_19_0_1.txt > > Let me know if you need additional information. > > - Stefan For the record, APU1 is =C2=A0=C2=A0=C2=A0 root@stratum:~ # freebsd-version ; uname -a =C2=A0=C2=A0=C2=A0 14.1-STABLE =C2=A0=C2=A0=C2=A0 FreeBSD stratum.localnet 14.1-STABLE FreeBSD 14.1-STAB= LE stable/14-n269015-013d817b5393 STRATUM amd64 and APU2: =C2=A0=C2=A0=C2=A0 root@apupf:~ # freebsd-version ; uname -a =C2=A0=C2=A0=C2=A0 14.1-STABLE =C2=A0=C2=A0=C2=A0 FreeBSD apupf.localnet 14.1-STABLE FreeBSD 14.1-STABLE stable/14-n269015-013d817b5393 APUPF amd64 --------------7T2SWUvVFJJ1WVFzx0ond7Se Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 06.10.2024 21:14, Stefan Hegnauer wrote:
On 06.10.2024 15:47, Warner Losh wrote:


On Sun, Oct 6, 2024 at 6:35=E2=80=AFAM Stefan Hegnauer <stefan.hegnauer@gmx.ch> wrote:
I have a few pc-engines APU1 appliances running in headless mode under
Nanobsd. Maintenance is by means of=C2=A0 direct COM port connection.
After a recent update a few weeks back I was not able to connect by COM
port anymore - console output and input went away after booting and
before single- or multi-user mode would start. Even re-flashing the
SDcard with a fresh image did not help.
After some longish trials and errors it turned out that both
- commit 74b9fc7a 'amd64 GENERIC: Switch uart hints from "isa" to
"acpi"' as well as
- commit 4ba4cfaf 'acpi: Narrow workaround for broken interrupt settings
on x86'
broke things for me. Restoring hints and setting
hw.acpi.override_isa_irq_polarity=3D1 in /boot/loader.conf.local restored
working order.
I agree that APU1 is EOL, however I would have expected an entry to
UPDATING for such a POLA violation.

Likely, but really really old gear like this is going to hit edge cases that
developers haven't seen. The hint thing wasn't though to actually negatively
affect any deployed hardware since it dealt with details that changed 15 or
20 years ago...

Looks like the APU1 used coreboot which at the time was trailing adaptation<= /div>
of ACPI, so it makes sense... I knew that Soekris boxes had issues, but they
are another 5 or 10 years older than the APUs and mine sadly isn't operational.

So I can write a better UPDATING entry, can you share with me the dmesg
from both APU1 and APU2?<= /div>

Warner
=C2=A0
Note that pc-engines APU2 models are not affected as the BIOS ACPI
tables contain correct UART descriptions.
- Stefan
Warner: thanks for the quick reply. Not so really, really old in my view - the BIOS=C2=A0is from ~August 2022 (APU1). And yes, it uses coreboot:
=C2=A0=C2=A0=C2=A0 PC Engines apu1
=C2=A0=C2=A0=C2=A0 coreboot build 20220822
=C2=A0=C2=A0=C2=A0 BIOS version v4.17.0.3
=C2=A0=C2=A0=C2=A0 SeaBIOS (version rel-1.16.0.1-0-g77603a32)

From verbose boot, dmesg -a:
- APU1, original/faulty from today:=C2=A0https://hegnauer.selfhost.eu/web= /computing/apu1c4_3mdeb_v4_17_0_3_std.txt
- APU1, fixed in loader.conf.local:=C2=A0https://hegnauer.selfhost.eu/web= /computing/apu1c4_3mdeb_v4_17_0_3_fixed.txt
- APU2 (has no problems): https://hegnauer.selfhost.eu/web= /computing/apu2d4_3mdeb_v4_19_0_1.txt

Let me know if you need additional information.

- Stefan

For the record, APU1 is
=C2=A0=C2=A0=C2=A0 root@stratum:~ # freebsd-version ; uname -a
=C2=A0=C2=A0=C2=A0 14.1-STABLE
=C2=A0=C2=A0=C2=A0 FreeBSD stratum.localnet 14.1-STABLE FreeBSD 14.1-S= TABLE stable/14-n269015-013d817b5393 STRATUM amd64

and APU2:
=C2=A0=C2=A0=C2=A0 root@apupf:~ # freebsd-version ; uname -a
=C2=A0=C2=A0=C2=A0 14.1-STABLE
=C2=A0=C2=A0=C2=A0 FreeBSD apupf.localnet 14.1-STABLE FreeBSD 14.1-STA= BLE stable/14-n269015-013d817b5393 APUPF amd64



--------------7T2SWUvVFJJ1WVFzx0ond7Se-- From nobody Sun Oct 6 21:07:38 2024 X-Original-To: freebsd-stable@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 4XMFHD25fBz5YXtk for ; Sun, 06 Oct 2024 21:07:52 +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 4XMFHD1YR5z4sWd for ; Sun, 6 Oct 2024 21:07:52 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pj1-x1031.google.com with SMTP id 98e67ed59e1d1-2e082f2a427so2729773a91.3 for ; Sun, 06 Oct 2024 14:07:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1728248871; x=1728853671; 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=76EPMLFg137hP+dEyrCAQY2R/lfrzXIhBmsJjSVXu44=; b=Fd1Gpaq5tEvXDvB40IBrpnC9gtHQHlzq0+1cGhB9/OCzHa9u99a7UHk59Q8L/obX6V 9EKkkQYxG6n3dJVv3M2b2msZHWu0Yy0m+4hQC6tOI1O0vr3GTNesxZM3H7TStDxvTfyr HFO1IzHPrmM4m4W2i133NjdHHJ5QgSr603mV65fSZV47gkatzJ7cJqBD0sVy4eAYXXpP cR5iBiBUPw6gA9njl2ugM/P/9D798EEMW6NpU2AHvOwzOy9lG9vmzwsqPDKuMxiFwsR/ GLPwSBxMl8OXQsIY4NQvJkrPes47QSQoeLx1vU+UjWIZvtnFmgCH8V6XqjanmfbaX+76 sAqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1728248871; x=1728853671; 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=76EPMLFg137hP+dEyrCAQY2R/lfrzXIhBmsJjSVXu44=; b=umQaA9weZRmzmHH/jeulwrpe9LG1oCfPxmP50IArSE9YdeRg4JsQ1vByh4wZQAVh6J 6lVajTSqmhLQ7hV/4Qdd2Dy5nn5rTweboDkXPhHN3pgpw/fAcBwB35+7qkoxKLeK3mH6 a536+ckG/R2frJa38+ISIvTmv4UPobpImrZs7uQpZ3be+AePmA95WA+iQMFZ5SeghAY6 pWkX3CYB0+bXWPSwGWXgRYqDH4FqOa7Ph8eIrBTGWTQ2eE7XZDI0lX8nXI3xxyGb5evx MUY75uwyn3PKi+7V8aulNftOglejQA7JcGuyxTui8pxm2ScyZaWN+5ftpveFW+L5QBkO +xZg== X-Gm-Message-State: AOJu0YxH2sIUqw8vhKDKKpRmpDh3+zpJMoIGpVVuOOLx8YxeUwhgR5sg hccASpVDM3gzN6jQoq51J9XPsQqRQy/Lkae7HvTuBZ2eEJXbp+4K6QRY3lZMzW0JGZ5JVujacF+ Cm0VxUU50Vgg55gS7MtLsZx56eOGc/h5c8vQX/g== X-Google-Smtp-Source: AGHT+IExK4m8uQTHcjKBJTE58i/DI71IQe7/Jpm5N9PwKInKJrOqxEEuLUNVbL5vUtIvhiZNLjdSM4N3kj540UXm7YE= X-Received: by 2002:a17:90b:4ac4:b0:2d8:d58b:52c8 with SMTP id 98e67ed59e1d1-2e1e629ccffmr12967257a91.19.1728248870617; Sun, 06 Oct 2024 14:07:50 -0700 (PDT) List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-stable@freebsd.org Sender: owner-freebsd-stable@FreeBSD.org MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Sun, 6 Oct 2024 15:07:38 -0600 Message-ID: Subject: Re: APU1 bricked on stable/14 - solved To: Stefan Hegnauer Cc: FreeBSD-STABLE Mailing List Content-Type: multipart/alternative; boundary="00000000000004750f0623d54c89" 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:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4XMFHD1YR5z4sWd X-Spamd-Bar: ---- --00000000000004750f0623d54c89 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Oct 6, 2024, 1:14=E2=80=AFPM Stefan Hegnauer wrote: > On 06.10.2024 15:47, Warner Losh wrote: > > > > On Sun, Oct 6, 2024 at 6:35=E2=80=AFAM Stefan Hegnauer > wrote: > >> I have a few pc-engines APU1 appliances running in headless mode under >> Nanobsd. Maintenance is by means of direct COM port connection. >> After a recent update a few weeks back I was not able to connect by COM >> port anymore - console output and input went away after booting and >> before single- or multi-user mode would start. Even re-flashing the >> SDcard with a fresh image did not help. >> >> After some longish trials and errors it turned out that both >> - commit 74b9fc7a 'amd64 GENERIC: Switch uart hints from "isa" to >> "acpi"' as well as >> - commit 4ba4cfaf 'acpi: Narrow workaround for broken interrupt settings >> on x86' >> broke things for me. Restoring hints and setting >> hw.acpi.override_isa_irq_polarity=3D1 in /boot/loader.conf.local restore= d >> working order. >> >> I agree that APU1 is EOL, however I would have expected an entry to >> UPDATING for such a POLA violation. >> > > Likely, but really really old gear like this is going to hit edge cases > that > developers haven't seen. The hint thing wasn't though to actually > negatively > affect any deployed hardware since it dealt with details that changed 15 = or > 20 years ago... > > Looks like the APU1 used coreboot which at the time was trailing adaptati= on > of ACPI, so it makes sense... I knew that Soekris boxes had issues, but > they > are another 5 or 10 years older than the APUs and mine sadly isn't > operational. > > So I can write a better UPDATING entry, can you share with me the dmesg > from both APU1 and APU2? > > Warner > > >> Note that pc-engines APU2 models are not affected as the BIOS ACPI >> tables contain correct UART descriptions. >> >> - Stefan >> >> Warner: thanks for the quick reply. Not so really, really old in my view > - the BIOS is from ~August 2022 (APU1). And yes, it uses coreboot: > PC Engines apu1 > coreboot build 20220822 > BIOS version v4.17.0.3 > SeaBIOS (version rel-1.16.0.1-0-g77603a32) > Yea. ACPI started being reliable in the early 2000s, +/-. Nearly everything sonce 2010 has provided it.... Here's clearly an exception that needs special care so we can make newer hw more reliable... My comments are more to explain the regression not to try to assign blame on the hardware.. >From verbose boot, dmesg -a: > - APU1, original/faulty from today: > https://hegnauer.selfhost.eu/web/computing/apu1c4_3mdeb_v4_17_0_3_std.txt > - APU1, fixed in loader.conf.local: > https://hegnauer.selfhost.eu/web/computing/apu1c4_3mdeb_v4_17_0_3_fixed.t= xt > - APU2 (has no problems): > https://hegnauer.selfhost.eu/web/computing/apu2d4_3mdeb_v4_19_0_1.txt > Thanks. I think between the two I know what to write. Warner > Let me know if you need additional information. > > - Stefan > --00000000000004750f0623d54c89 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, Oct 6, 2024, 1:14=E2=80=AFPM Stefan Hegnauer &= lt;stefan.hegnauer@gmx.ch>= wrote:
=20 =20 =20
On 06.10.2024 15:47, Warner Losh wrote:
=20


On Sun, Oct 6, 2024 at 6:35=E2=80=AFAM Stefan Hegnauer <s= tefan.hegnauer@gmx.ch> wrote:
I have a few pc-engines APU1 appliances running in headless mode under
Nanobsd. Maintenance is by means of=C2=A0 direct COM port connection.
After a recent update a few weeks back I was not able to connect by COM
port anymore - console output and input went away after booting and
before single- or multi-user mode would start. Even re-flashing the
SDcard with a fresh image did not help.
After some longish trials and errors it turned out that both
- commit 74b9fc7a 'amd64 GENERIC: Switch uart hints from "isa" to
"acpi"' as well as
- commit 4ba4cfaf 'acpi: Narrow workaround for broken interrupt settings
on x86'
broke things for me. Restoring hints and setting
hw.acpi.override_isa_irq_polarity=3D1 in /boot/loader.conf.local restored
working order.
I agree that APU1 is EOL, however I would have expected an entry to
UPDATING for such a POLA violation.

Likely, but really really old gear like this is going to hit edge cases that
developers haven't seen. The hi= nt thing wasn't though to actually negatively
affect any deployed hardware since it dealt with details that changed 15 or
20 years ago...

Looks like the APU1 used coreboot which at the time was trailing adaptation
of ACPI, so it makes sense... I knew that Soekris boxes had issues, but they
are another 5 or 10 years older than the APUs and mine sadly isn't operational.

So I can write a better UPDATING entry, can you share with me the dmesg
from both APU1 and APU2?

Warner
=C2=A0
Note that pc-engines APU2 models are not affected as the BIOS ACPI
tables contain correct UART descriptions.
- Stefan
Warner: thanks for the quick reply. Not so really, really old in my view - the BIOS=C2=A0is from ~August 2022 (APU1). And yes, it uses coreboot:
=C2=A0=C2=A0=C2=A0 PC Engines apu1
=C2=A0=C2=A0=C2=A0 coreboot build 20220822
=C2=A0=C2=A0=C2=A0 BIOS version v4.17.0.3
=C2=A0=C2=A0=C2=A0 SeaBIOS (version rel-1.16.0.1-0-g77603a32)

Yea. ACPI started being reliable in the early 2000s, +/-. Nearly every= thing sonce 2010 has provided it....=C2=A0 Here's clearly an exception = that needs special care so we can make newer hw more reliable... My comment= s are more to explain the regression not to try to assign blame on the hard= ware..

From verbose boot, dmesg -a:
- APU1, original/faulty from today:=C2=A0https://hegnauer.selfhost.eu/web/computing/apu1c4_3mdeb= _v4_17_0_3_std.txt
- APU1, fixed in loader.conf.local:=C2=A0https://hegnauer.selfhost.eu/web/computing/apu1c4_3md= eb_v4_17_0_3_fixed.txt
- APU2 (has no problems): https://hegnauer.selfhost.eu/web/computing/apu2d4_3mdeb_v4_19_0_1.txt<= /font>

Thanks. I think between the two I know what to write.

Warner=C2=A0


Let me know if you need additional information.

- Stefan
--00000000000004750f0623d54c89-- From nobody Sun Oct 6 22:14:41 2024 X-Original-To: freebsd-stable@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 4XMGmc0tzhz5YbrC for ; Sun, 06 Oct 2024 22:14:56 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pg1-x52b.google.com (mail-pg1-x52b.google.com [IPv6:2607:f8b0:4864:20::52b]) (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 4XMGmb5WcTz42qx for ; Sun, 6 Oct 2024 22:14:55 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pg1-x52b.google.com with SMTP id 41be03b00d2f7-7ea06275ef2so331842a12.0 for ; Sun, 06 Oct 2024 15:14:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1728252894; x=1728857694; 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=b08zqj7zSzqNApIe1wIDbyLNq+bEyTSVGntmFyH02wc=; b=zQfq+3am7kDpiquXEL6LLGTDw8r+aSNIzWo2FJk+xb69e10jN2ctppP96PRiNGLJf7 OH7VGj+qxlLw2M97iehyOuVM5tbppFkAvcns8N3HykV2CRHBPsY9F7UZgMgzxbOCwISw YK4UpD6MV0Ni9DINkZPWV8kf4UDpUx6OhDKLfeHy2nx6LpAGtjoQeAbnKhDodKqRbLIg +TjHz0ZIiO8FQwyaVGFjz2MFdY2f/e2TEUyjtYcuy/d4pgqlj/igsdgKNIg97ndGc7F5 oJfMu58aOSFFnqyQmzga0pkW5+LXoQ8ejlHFf3WBDtckyrHxHMuPTe+XsrbgBvWG4mNW qo5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1728252894; x=1728857694; 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=b08zqj7zSzqNApIe1wIDbyLNq+bEyTSVGntmFyH02wc=; b=X4f2XEydwNYZ9k36Nu8t5MkdQZ+6FGII4FRTfSr1fgdz3kiomSJffC1WmnVED7jAO2 vd3h9Z/rCzvKZfK9Qf/upynxMxLPpS04iMGmmYYEUo3x8eJJ93Cf7VQRAQ6RR0MC8HGb PiKYnH2K5b0gyvbSNCG+6NkxS/x0jbAzJJ+Z+6elcskq4uhXBmU5nPExbn0K880bm+zu tvsEbkXoBIr/o4Bh2M5s4kR2arcZiw1geL4JhbKVYLDnvuHNJp+pZ746F2H9OCFxF/Yg zC/BzN4XLMxeN2Qc1LKNaauQKt0eiYweNS097ryirIdFuC+uCGbN34uC1yxTfTPn56tG MoaA== X-Forwarded-Encrypted: i=1; AJvYcCWxo9PgiI88Mf/sSi7gUstVsrUgba8KnoYgVeXBgoALekTPu7esxXOwDxvw5NOHmaBPxTuYIKEByuSewy+6xw==@freebsd.org X-Gm-Message-State: AOJu0YyxHF2AAd2yuVvEBlKTl02hYiGEhY+lw9IgN/aW1HpdbP3SuUIu yWf8pOeWD4DPVsFBKUoVzNtZLDcEpbsUDsVpRMy62MNfCUXceGRM6BO65an2MoASxcd+mfhRDk9 cLsD04Wow8AOYidx6dp1wUo9nOzfP5m39oyoszw== X-Google-Smtp-Source: AGHT+IGiTnkOH1TGYHW879TSC0Ux2rHXetWrgp/j4Dv6O6BHfbHpZ+QGdLk0wLD0TWSpYBzHdVbyW0SNEGTwk6mdcD8= X-Received: by 2002:a17:90a:c2c8:b0:2e0:9a63:9017 with SMTP id 98e67ed59e1d1-2e1e62a4136mr12502808a91.23.1728252894577; Sun, 06 Oct 2024 15:14:54 -0700 (PDT) List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-stable@freebsd.org Sender: owner-freebsd-stable@FreeBSD.org MIME-Version: 1.0 References: <86ploiwxw8.fsf@ltc.des.dev> <8745F9FB-9CC1-476C-9445-DC0A7A76165F@gmail.com> <8F8158B8-4D78-4A17-90B7-659ECB9988B5@gmail.com> <86v7y5vce8.fsf@ltc.des.dev> In-Reply-To: <86v7y5vce8.fsf@ltc.des.dev> From: Warner Losh Date: Sun, 6 Oct 2024 16:14:41 -0600 Message-ID: Subject: Re: uaudio device re-attach and persisting dev.pcm.$pcm.bitperfect sysctl To: =?UTF-8?Q?Dag=2DErling_Sm=C3=B8rgrav?= Cc: Alban Hertroys , Christos Margiolis , freebsd-stable@freebsd.org Content-Type: multipart/alternative; boundary="000000000000dd29580623d63bf6" 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:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4XMGmb5WcTz42qx X-Spamd-Bar: ---- --000000000000dd29580623d63bf6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Oct 6, 2024 at 2:55=E2=80=AFAM Dag-Erling Sm=C3=B8rgrav wrote: > Alban Hertroys writes: > > Originally I tried checking for the device using: > > test "`sysctl -n dev.pcm.${PCM}.%desc`" =3D 'Topping D90SE=E2=80= =99 > > , but that statement seems to require the double-quotes for test to > > accept it, which conflict with the double-quotes of the action > > string. I couldn=E2=80=99t find a way to escape those inner quotes. So = that=E2=80=99s > > another issue I ran into, although approaches to use the USB attach > > event for matching the dsp device to the usb device are clearly > > superior to reading out a sysctl that=E2=80=99s an effect of it. > > You realize you can just put everything in a shell script which devd > invokes, right? > That would also have the advantage of knowing which device(s) were involved, so it could be parameterized rather than being hard-coded to something that's usually true but might fail if you, for example, start playing with bluetooth headphones that may or may not be present at boot... Warner --000000000000dd29580623d63bf6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Oct 6, 2024 at 2:55=E2=80=AFA= M Dag-Erling Sm=C3=B8rgrav <des@freeb= sd.org> wrote:
Alban Hertroys <haramrae@gmail.com> writes:
> Originally I tried checking for the device using:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0test "`sysctl -n dev.pcm.${PCM}.%desc`&= quot; =3D 'Topping D90SE=E2=80=99
> , but that statement seems to require the double-quotes for test to > accept it, which conflict with the double-quotes of the action
> string. I couldn=E2=80=99t find a way to escape those inner quotes. So= that=E2=80=99s
> another issue I ran into, although approaches to use the USB attach > event for matching the dsp device to the usb device are clearly
> superior to reading out a sysctl that=E2=80=99s an effect of it.

You realize you can just put everything in a shell script which devd
invokes, right?

That would also have th= e advantage of knowing which device(s) were involved, so it
could= be parameterized rather than being hard-coded to something that's usua= lly true but
might fail if you, for example, start playing with b= luetooth headphones that may or may not
be present at boot...

Warner=C2=A0
--000000000000dd29580623d63bf6--