Skip site navigation (1)Skip section navigation (2) 
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>
index | next in thread | previous in thread | raw e-mail 

 I had it and filed a bug report. It only happens in UEFI loader and that only 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@tacomawireless.net> wrote:  
 
 On 2021-03-17 00:01, Xin Li via freebsd-current wrote:
> On 3/16/21 9:45 PM, Warner Losh wrote:
>> 
>> 
>> On Tue, Mar 16, 2021 at 10:18 PM Xin Li <delphij@freebsd.org
>> <mailto:delphij@freebsd.org>> wrote:
>> 
>>    On 11/17/19 23:14, Xin Li wrote:
>>    > Hi,
>>    >
>>    > I recently noticed that if I do a 'shutdown -p' from -CURRENT, the
>>    > system would shut down and seemingly powered off, then it would
>>    restart
>>    > after about 5-10 seconds.
>>    >
>>    > Is this a known issue?  Arguably this is not necessarily a FreeBSD
>>    > issue, but it seems that the Windows 10 installation doesn't have the
>>    > problem, so I guess there might be some difference between our and
>>    > Windows's shutdown sequence.
>> 
>>    I've found a workaround for this, for the record, setting
>>    hw.efi.poweroff=0 would make the laptop to correctly shutdown.
>> 
>>    However I don't see anything wrong with sys/dev/efidev/efirt.c's
>>    implementation of EFI shutdown; it appears to be essentially the same 
>> as
>>    implemented in command_poweroff() in stand/efi/loader/main.c, but
>>    'poweroff' would work just fine in loader.efi.
>> 
>>    Can someone familiar with the code shed me some light here? :-)
>> 
>>    It looks like what Linux did was to prefer ACPI S5, unless it's not
>>    available or the system have HW_REDUCED flag in FADT, so if we do
>>    something similar it would fix the issue for me, but according to
>>    bugs.freebsd.org/233998 <http://bugs.freebsd.org/233998>; that's not
>>    the case for at least Conor's system
>>    (_S5 appears to be in the ACPI dump), so I think it's something else...
>> 
>> 
>> For me, interrupt storm on shutdown has been the causes of issues like
>> this...
>> 
>> Any chance you can eliminate that as a possibility?
> 
> Hmm, that's a good question -- is there a way to tell after the screen
> was turned off?
> 
> Before the screen was turned off, there doesn't appear to be interrupt
> storm.  The system was performing a typical FreeBSD shutdown procedure:
> 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.
> 
> 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.
> 
> 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"
  
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%6 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Êtflap.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
home | help

Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1717595672.2321085.1616007121143>