Date: Wed, 17 Mar 2021 08:33:33 -0700 From: Unbound <unbound@tacomawireless.net> To: freebsd-current@freebsd.org 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: <a4b4de6825999fc7c4c98f8a77127943@tacomawireless.net> In-Reply-To: <53e336e7-1b08-5ebf-27a2-de7ca756024c@delphij.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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?a4b4de6825999fc7c4c98f8a77127943>