Date: Wed, 17 Mar 2021 18:52:01 +0000 (UTC) From: Kostya Berger <bergerkos@yahoo.co.uk> To: freebsd-current@freebsd.org, Unbound <unbound@tacomawireless.net> Cc: Warner Losh <imp@bsdimp.com>, Xin Li <delphij@freebsd.org>, Xin Li <delphij@delphij.net>, d@delphij.net, Jung-uk Kim <jkim@freebsd.org>, "Conrad E. Meyer" <cem@freebsd.org>, Marcel Moolenaar <marcel@freebsd.org>, Warner Losh <imp@freebsd.org>, byuu@tutanota.com, interloper255@gmail.com Subject: Re: ThinkPad: reboots after successful shutdown -p Message-ID: <1717595672.2321085.1616007121143@mail.yahoo.com> In-Reply-To: <a4b4de6825999fc7c4c98f8a77127943@tacomawireless.net> References: <b22bad03-238f-ad74-e8ce-9c02287d4cd4@delphij.net> <cde330ac-d254-fd2d-760a-cfb63c5cd058@FreeBSD.org> <CANCZdfphOpRvpaTwHGquyAqyFituoUGg3yNFQ=A=gxP2CCm=WQ@mail.gmail.com> <53e336e7-1b08-5ebf-27a2-de7ca756024c@delphij.net> <a4b4de6825999fc7c4c98f8a77127943@tacomawireless.net>
next in thread | previous in thread | raw e-mail | index | archive | help
I had it and filed a bug report. It only happens in UEFI loader and that o=
nly on one of my machines, but not the other.
With kindest regards,
Kostya Berger
On Wednesday, 17 March 2021, 19:38:57 GMT+3, Unbound <unbound@tacomawi=
reless.net> wrote: =20
=20
On 2021-03-17 00:01, Xin Li via freebsd-current wrote:
> On 3/16/21 9:45 PM, Warner Losh wrote:
>>=20
>>=20
>> On Tue, Mar 16, 2021 at 10:18 PM Xin Li <delphij@freebsd.org
>> <mailto:delphij@freebsd.org>> wrote:
>>=20
>>=C2=A0 =C2=A0 On 11/17/19 23:14, Xin Li wrote:
>>=C2=A0 =C2=A0 > Hi,
>>=C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 > I recently noticed that if I do a 'shutdown -p' from -CUR=
RENT, the
>>=C2=A0 =C2=A0 > system would shut down and seemingly powered off, then it=
would
>>=C2=A0 =C2=A0 restart
>>=C2=A0 =C2=A0 > after about 5-10 seconds.
>>=C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 > Is this a known issue?=C2=A0 Arguably this is not necessa=
rily a FreeBSD
>>=C2=A0 =C2=A0 > issue, but it seems that the Windows 10 installation does=
n't have the
>>=C2=A0 =C2=A0 > problem, so I guess there might be some difference betwee=
n our and
>>=C2=A0 =C2=A0 > Windows's shutdown sequence.
>>=20
>>=C2=A0 =C2=A0 I've found a workaround for this, for the record, setting
>>=C2=A0 =C2=A0 hw.efi.poweroff=3D0 would make the laptop to correctly shut=
down.
>>=20
>>=C2=A0 =C2=A0 However I don't see anything wrong with sys/dev/efidev/efir=
t.c's
>>=C2=A0 =C2=A0 implementation of EFI shutdown; it appears to be essentiall=
y the same=20
>> as
>>=C2=A0 =C2=A0 implemented in command_poweroff() in stand/efi/loader/main.=
c, but
>>=C2=A0 =C2=A0 'poweroff' would work just fine in loader.efi.
>>=20
>>=C2=A0 =C2=A0 Can someone familiar with the code shed me some light here?=
:-)
>>=20
>>=C2=A0 =C2=A0 It looks like what Linux did was to prefer ACPI S5, unless =
it's not
>>=C2=A0 =C2=A0 available or the system have HW_REDUCED flag in FADT, so if=
we do
>>=C2=A0 =C2=A0 something similar it would fix the issue for me, but accord=
ing to
>>=C2=A0 =C2=A0 bugs.freebsd.org/233998 <http://bugs.freebsd.org/233998>; th=
at's not
>>=C2=A0 =C2=A0 the case for at least Conor's system
>>=C2=A0 =C2=A0 (_S5 appears to be in the ACPI dump), so I think it's somet=
hing else...
>>=20
>>=20
>> For me, interrupt storm on shutdown has been the causes of issues like
>> this...
>>=20
>> Any chance you can eliminate that as a possibility?
>=20
> Hmm, that's a good question -- is there a way to tell after the screen
> was turned off?
>=20
> Before the screen was turned off, there doesn't appear to be interrupt
> storm.=C2=A0 The system was performing a typical FreeBSD shutdown procedu=
re:
> All buffers synced, showed uptime, destroyed GELI devices, spin down the
> SATA devices, shutdown the cardreader (rtsx0), detached all USB devices
> (hidraw1, hidbus, usbhid1, ubt0, uhub0), screen turned slightly red for
> a very brief period (maybe side effect of turning off the backlight),
> then goes off.
>=20
> I think most of FreeBSD drivers would turn off interrupt from the device
> before detaching, but I haven't looked into all of my devices; but from
> what I have seen on screen (captured a 60fps video and can share if that
> helps), there doesn't appear to be an interrupt storm before that.
>=20
> Cheers,
FWIW this also happened to me a few weeks ago after a fresh install.
I've since wiped the disk and repurposed the hardware. So I can't now
reproduce it. But it wasn't a laptop. So it's not isolated to them.
Sorry I can't offer anything more. I just wanted to mention this to
indicate that it's not a _too_ terribly isolated case. It was Intel
CPU/graphics. In case that says anything to anyone. If it matters,
I can get/offer more info on the hardware.
--Chris
_______________________________________________
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
=20
From owner-freebsd-current@freebsd.org Thu Mar 18 10:07:46 2021
Return-Path: <owner-freebsd-current@freebsd.org>
Delivered-To: freebsd-current@mailman.nyi.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1])
by mailman.nyi.freebsd.org (Postfix) with ESMTP id 6F89B5B6226
for <freebsd-current@mailman.nyi.freebsd.org>;
Thu, 18 Mar 2021 10:07:46 +0000 (UTC)
(envelope-from jamie@catflap.org)
Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3])
by mx1.freebsd.org (Postfix) with ESMTP id 4F1N4f1nhxz3D3J
for <freebsd-current@freebsd.org>; Thu, 18 Mar 2021 10:07:46 +0000 (UTC)
(envelope-from jamie@catflap.org)
Received: by mailman.nyi.freebsd.org (Postfix)
id 3B89C5B6315; Thu, 18 Mar 2021 10:07:46 +0000 (UTC)
Delivered-To: current@mailman.nyi.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1])
by mailman.nyi.freebsd.org (Postfix) with ESMTP id 3B3E15B5E58;
Thu, 18 Mar 2021 10:07:46 +0000 (UTC)
(envelope-from jamie@catflap.org)
Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net
[IPv6:2001:19f0:300:2185:123::1])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(Client did not present a certificate)
by mx1.freebsd.org (Postfix) with ESMTPS id 4F1N4d3Ntrz3Cq7;
Thu, 18 Mar 2021 10:07:45 +0000 (UTC)
(envelope-from jamie@catflap.org)
Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net
[104.207.135.49])
by donotpassgo.dyslexicfish.net (8.14.5/8.14.5) with ESMTP id 12IA7bmw094801
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
Thu, 18 Mar 2021 10:07:37 GMT
(envelope-from jamie@donotpassgo.dyslexicfish.net)
Received: (from jamie@localhost)
by donotpassgo.dyslexicfish.net (8.14.5/8.14.5/Submit) id 12IA7Vxg094800;
Thu, 18 Mar 2021 10:07:31 GMT (envelope-from jamie)
From: Jamie Landeg-Jones <jamie@catflap.org>
Message-Id: <202103181007.12IA7Vxg094800@donotpassgo.dyslexicfish.net>
Date: Thu, 18 Mar 2021 10:07:31 +0000
Organization: Dyslexic Fish
To: o.hartmann@walstatt.org, freebsd-current@freebsd.org
Cc: bapt@freebsd.org, imb@protected-networks.net, current@freebsd.org
Subject: Re: On 14-CURRENT: no ports options anymore?
References: <20210313201702.5f9dfa9b@hermann.fritz.box>
<25cd3ca3-edb6-8b7a-8ad5-f0737d8bd493@freebsd.org>
<509410723.637403.1615665167513@mail.yahoo.com>
<20210313210002.30ad4345@hermann.fritz.box>
<52964883-05ce-66cc-4d6f-9797746a9a62@protected-networks.net>
<20210313220301.28db1d0f@hermann.fritz.box>
In-Reply-To: <20210313220301.28db1d0f@hermann.fritz.box>
User-Agent: Heirloom mailx 12.4 7/29/08
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7
(donotpassgo.dyslexicfish.net [104.207.135.49]);
Thu, 18 Mar 2021 10:07:37 +0000 (GMT)
X-Rspamd-Queue-Id: 4F1N4d3Ntrz3Cq7
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org; dkim=none;
dmarc=pass (policy=none) header.from=catflap.org;
spf=pass (mx1.freebsd.org: domain of jamie@catflap.org designates
2001:19f0:300:2185:123::1 as permitted sender)
smtp.mailfrom=jamie@catflap.org
X-Spamd-Result: default: False [-2.70 / 15.00]; RCVD_TLS_LAST(0.00)[];
ARC_NA(0.00)[]; FREEFALL_USER(0.00)[jamie];
FROM_HAS_DN(0.00)[];
RBL_DBL_DONT_QUERY_IPS(0.00)[2001:19f0:300:2185:123::1:from];
R_SPF_ALLOW(-0.20)[+mx:dyslexicfish.net];
NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain];
TO_DN_NONE(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000];
RCPT_COUNT_FIVE(0.00)[5]; HAS_ORG_HEADER(0.00)[];
SPAMHAUS_ZRD(0.00)[2001:19f0:300:2185:123::1:from:127.0.2.255];
TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.90)[-0.903];
DMARC_POLICY_ALLOW(-0.50)[catflap.org,none];
FROM_EQ_ENVFROM(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[];
R_DKIM_NA(0.00)[];
ASN(0.00)[asn:20473, ipnet:2001:19f0::/38, country:US];
MIME_TRACE(0.00)[0:+];
MAILMAN_DEST(0.00)[current,freebsd-current];
RCVD_COUNT_TWO(0.00)[2]
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
<freebsd-current.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current/>;
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Mar 2021 10:07:46 -0000
"Hartmann, O." <o.hartmann@walstatt.org> wrote:
> On Sat, 13 Mar 2021 15:13:15 -0500
> Michael Butler via freebsd-current <freebsd-current@freebsd.org> wrote:
>
> > On 3/13/21 3:00 PM, Hartmann, O. wrote:
> > > On Sat, 13 Mar 2021 19:52:47 +0000 (UTC)
> > > Filippo Moretti via freebsd-current <freebsd-current@freebsd.org> wrote:
> > >
> > >>
> > >> I had the same problem in console modeFiippo
> > >> On Saturday, March 13, 2021, 8:33:57 PM GMT+1, Stefan Esser <se@freebsd.org>
> > >> wrote:
> > >>
> > >> Am 13.03.21 um 20:17 schrieb Hartmann, O.:
> > >>> Since I moved on to 14-CURRENT, I face a very strange behaviour when trying to set
> > >>> options via "make config" or via poudriere accordingly. I always get "===> Options
> > >>> unchanged" (when options has been already set and I'd expect a dialog menu).
> > >>> This misbehaviour is throughout ALL 14-CURRENT systems (the oldest is at FreeBSD
> > >>> 14.0-CURRENT #49 main-n245422-cecfaf9bede9: Fri Mar 12 16:08:09 CET 2021 amd64).
> >
> > I ran into something similar where dialog4ports would dump core after an
> > upgrade. Rebuilding the port (ports-mgmt/dialog4ports) solved it for me,
> >
> > imb
>
> Thanks, recompilig ports-mgmt/dialog4ports solved the problem! I was sure that after some
> ncurses changes in 14-CURRENT I've rebuilt every single port on all 14-CURRENT systems
> after that incident, bad luck.
This bit me a few years ago - in my case, the terminal type wasn't recognised. If dialog4ports
doesn't run successfully, the error is ignored by the ports scripts. This was on a new
install (hence the reason I hadn't yet installed my termcap), and it meant that before I
noticed, quite a number of ports got installed without the options I wanted.
Since then, I've patched bsd.port.mk with:
--- bsd.port.mk.orig 2017-06-06 17:38:00.000000000 +0100
+++ bsd.port.mk 2017-06-08 01:31:36.320294000 +0100
@@ -4729,8 +4729,8 @@
trap "${RM} $${TMPOPTIONSFILE}; exit 1" 1 2 3 5 10 13 15; \
${SETENV} ${D4P_ENV} ${SH} ${SCRIPTSDIR}/dialog4ports.sh $${TMPOPTIONSFILE} || { \
${RM} $${TMPOPTIONSFILE}; \
- ${ECHO_MSG} "===> Options unchanged"; \
- exit 0; \
+ ${ECHO_MSG} "===> ERROR: Options unchanged"; \
+ exit 1; \
}; \
${ECHO_CMD}; \
if [ ! -e $${TMPOPTIONSFILE} ]; then \
I never submitted this patch, because the way it was written seemed intentional. Maybe this should be reviewed?
Cheers,
Jamie
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1717595672.2321085.1616007121143>