Re: Getting started with ktls

[Rick Macklem]

J. wrote:
>On Tue, Mar 16, 2021 at 11:46:27PM +, Rick Macklem wrote:
>>Well, if you do "sysctl -a | fgrep kern.ipc.tls.stats" and it is working,
>>you should see the count for at least one of the "crypts" ticking up.
>>If they are all zero, it isn't working. That might depend on the apps
>>or setup and does not necessarily indicate broken.
>
>OK. it's "not working" by those criteria on the stable/13 rpi4.
>This one has mutt (imaps) and lynx (https) installed. mutt appears to
>use tlsv1.3 to connect with my email provider.
I know that the receive direction only works for TLS1.2. Not sure
about the xmit direction?

Make sure you've done the following:
 ktls_ocf - is loaded
these sysctls are set to 1
kern.ipc.tls.enable
kern.ipc.mb_use_ext_pgs

Beyond that, it will take someone more knowledgible to figure
out if it can work for these apps?
(To be honest, for userspace applications I'm not sure there is
 any advantage to using KTLS unless you have specialized
 hardware.

rick

>Trying the nfs-over-tls should definitely test it. When it works, the
>data on the wire after the first couple of Null RPCs is encrypted.
>Also, if you start the daemons with "-v",

This is what i'll try once buildworld etc completes on the main/14 rpi4.
--
J.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: 13.0-RC2 / 14-CURRENT: Processes getting stuck in vlruwk state

[Yamagi Burmeister]

This time poudriere came to an end:

  % sysctl vfs.highest_numvnodes
  vfs.highest_numvnodes: 500976

On Wed, 17 Mar 2021 18:55:43 +0100
Mateusz Guzik  wrote:

> Thanks, I'm going to have to ponder a little bit.
> 
> In the meantime can you apply this:
> https://people.freebsd.org/~mjg/maxvnodes.diff
> 
> Once you boot, tweak maxvnodes:
> sysctl kern.maxvnodes=1049226
> 
> Run poudriere. Once it finishes, inspect sysctl vfs.highest_numvnodes
> 
> On 3/17/21, Yamagi  wrote:
> > Hi Mateusz,
> > the sysctl output after about 10 minutes into the problem is attached.
> > In case that its stripped by Mailman a copy can be found here:
> > https://deponie.yamagi.org/temp/sysctl_vlruwk.txt.xz
> >
> > Regards,
> > Yamagi
> >
> > On Wed, 17 Mar 2021 15:57:59 +0100
> > Mateusz Guzik  wrote:
> >
> >> Can you reproduce the problem and run obtain "sysctl -a"?
> >>
> >> In general, there is a vnode limit which is probably too small. The
> >> reclamation mechanism is deficient in that it will eventually inject
> >> an arbitrary pause.
> >>
> >> On 3/17/21, Yamagi  wrote:
> >> > Hi,
> >> > me and some other users in the ##bsdforen.de IRC channel have the
> >> > problem that during Poudriere runs processes getting stuck in the
> >> > 'vlruwk' state.
> >> >
> >> > For me it's fairly reproduceable. The problems begin about 20 to 25
> >> > minutes after I've started poudriere. At first only some ccache
> >> > processes hang in the 'vlruwk' state, after another 2 to 3 minutes
> >> > nearly everything hangs and the total CPU load drops to about 5%.
> >> > When I stop poudriere with ctrl-c it takes another 3 to 5 minutes
> >> > until the system recovers.
> >> >
> >> > First the setup:
> >> > * poudriere runs in a bhyve vm on zvol. The host is a 12.2-RELEASE-p2.
> >> >   The zvol has a 8k blocksize, the guests partition are aligned to 8k.
> >> >   The guest has only zpool, the pool was created with ashift=13. The
> >> >   vm has 16 E5-2620 and 16 gigabytes RAM assigned to it.
> >> > * poudriere is configured with ccache and ALLOW_MAKE_JOBS=yes. Removing
> >> >   either of these options lowers the probability of the problem to show
> >> >   up significantly.
> >> >
> >> > I've tried several git revisions starting with 14-CURRENT at
> >> > 54ac6f721efccdba5a09aa9f38be0a1c4ef6cf14 in the hope that I can find at
> >> > least one known to be good revision. No chance, even a kernel build
> >> > from 0932ee9fa0d82b2998993b649f9fa4cc95ba77d6 (Wed Sep 2 19:18:27 2020
> >> > +) has the problem. The problem isn't reproduceable with
> >> > 12.2-RELEASE.
> >> >
> >> > The kernel stack ('procstat -kk') of a hanging process is:
> >> > mi_switch+0x155 sleepq_switch+0x109 sleepq_catch_signals+0x3f1
> >> > sleepq_wait_sig+0x9 _sleep+0x2aa kern_wait6+0x482 sys_wait4+0x7d
> >> > amd64_syscall+0x140 fast_syscall_common+0xf8
> >> >
> >> > The kernel stack of vnlru is changing, even while the processes are
> >> > hanging:
> >> > * mi_switch+0x155 sleepq_switch+0x109 sleepq_timedwait+0x4b
> >> > _sleep+0x29b vnlru_proc+0xa05 fork_exit+0x80 fork_trampoline+0xe
> >> > * fork_exit+0x80 fork_trampoline+0xe
> >> >
> >> > Since vnlru is accumulating CPU time it looks like it's doing at least
> >> > something. As an educated guess I would say that vn_alloc_hard() is
> >> > waiting a long time or even forever to allocate new vnodes.
> >> >
> >> > I can provide more information, I just need to know what.
> >> >
> >> >
> >> > Regards,
> >> > Yamagi
> >> >
> >> > --
> >> > Homepage: https://www.yamagi.org
> >> > Github:   https://github.com/yamagi
> >> > GPG:  0x1D502515
> >> >
> >>
> >>
> >> --
> >> Mateusz Guzik 
> >
> >
> > --
> > Homepage: https://www.yamagi.org
> > Github:   https://github.com/yamagi
> > GPG:  0x1D502515
> >
> 
> 
> -- 
> Mateusz Guzik 


-- 
Homepage: https://www.yamagi.org
Github:   https://github.com/yamagi
GPG:  0x1D502515


pgp7jQmC27DZa.pgp
Description: PGP signature

Re: 13.0-RC2 / 14-CURRENT: Processes getting stuck in vlruwk state

[Mateusz Guzik]

Thanks, I'm going to have to ponder a little bit.

In the meantime can you apply this:
https://people.freebsd.org/~mjg/maxvnodes.diff

Once you boot, tweak maxvnodes:
sysctl kern.maxvnodes=1049226

Run poudriere. Once it finishes, inspect sysctl vfs.highest_numvnodes

On 3/17/21, Yamagi  wrote:
> Hi Mateusz,
> the sysctl output after about 10 minutes into the problem is attached.
> In case that its stripped by Mailman a copy can be found here:
> https://deponie.yamagi.org/temp/sysctl_vlruwk.txt.xz
>
> Regards,
> Yamagi
>
> On Wed, 17 Mar 2021 15:57:59 +0100
> Mateusz Guzik  wrote:
>
>> Can you reproduce the problem and run obtain "sysctl -a"?
>>
>> In general, there is a vnode limit which is probably too small. The
>> reclamation mechanism is deficient in that it will eventually inject
>> an arbitrary pause.
>>
>> On 3/17/21, Yamagi  wrote:
>> > Hi,
>> > me and some other users in the ##bsdforen.de IRC channel have the
>> > problem that during Poudriere runs processes getting stuck in the
>> > 'vlruwk' state.
>> >
>> > For me it's fairly reproduceable. The problems begin about 20 to 25
>> > minutes after I've started poudriere. At first only some ccache
>> > processes hang in the 'vlruwk' state, after another 2 to 3 minutes
>> > nearly everything hangs and the total CPU load drops to about 5%.
>> > When I stop poudriere with ctrl-c it takes another 3 to 5 minutes
>> > until the system recovers.
>> >
>> > First the setup:
>> > * poudriere runs in a bhyve vm on zvol. The host is a 12.2-RELEASE-p2.
>> >   The zvol has a 8k blocksize, the guests partition are aligned to 8k.
>> >   The guest has only zpool, the pool was created with ashift=13. The
>> >   vm has 16 E5-2620 and 16 gigabytes RAM assigned to it.
>> > * poudriere is configured with ccache and ALLOW_MAKE_JOBS=yes. Removing
>> >   either of these options lowers the probability of the problem to show
>> >   up significantly.
>> >
>> > I've tried several git revisions starting with 14-CURRENT at
>> > 54ac6f721efccdba5a09aa9f38be0a1c4ef6cf14 in the hope that I can find at
>> > least one known to be good revision. No chance, even a kernel build
>> > from 0932ee9fa0d82b2998993b649f9fa4cc95ba77d6 (Wed Sep 2 19:18:27 2020
>> > +) has the problem. The problem isn't reproduceable with
>> > 12.2-RELEASE.
>> >
>> > The kernel stack ('procstat -kk') of a hanging process is:
>> > mi_switch+0x155 sleepq_switch+0x109 sleepq_catch_signals+0x3f1
>> > sleepq_wait_sig+0x9 _sleep+0x2aa kern_wait6+0x482 sys_wait4+0x7d
>> > amd64_syscall+0x140 fast_syscall_common+0xf8
>> >
>> > The kernel stack of vnlru is changing, even while the processes are
>> > hanging:
>> > * mi_switch+0x155 sleepq_switch+0x109 sleepq_timedwait+0x4b
>> > _sleep+0x29b vnlru_proc+0xa05 fork_exit+0x80 fork_trampoline+0xe
>> > * fork_exit+0x80 fork_trampoline+0xe
>> >
>> > Since vnlru is accumulating CPU time it looks like it's doing at least
>> > something. As an educated guess I would say that vn_alloc_hard() is
>> > waiting a long time or even forever to allocate new vnodes.
>> >
>> > I can provide more information, I just need to know what.
>> >
>> >
>> > Regards,
>> > Yamagi
>> >
>> > --
>> > Homepage: https://www.yamagi.org
>> > Github:   https://github.com/yamagi
>> > GPG:  0x1D502515
>> >
>>
>>
>> --
>> Mateusz Guzik 
>
>
> --
> Homepage: https://www.yamagi.org
> Github:   https://github.com/yamagi
> GPG:  0x1D502515
>


-- 
Mateusz Guzik 
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [FreeBSD-Announce] CORE Team Office Hours

[FreeBSD Core Team Secretary]

Hi Everyone,

Unfortunately due to a daylight saving time-related mixup we would like to 
reschedule this Office Hours in the coming weeks and will update in the mailing 
list.

We apologies for keeping your schedule busy. Looking forward to see you in the 
coming weeks.

Regards,
Moin (bofh), with core-secretary@ hat on

> On 23 Feb, 2021, at 02:31, FreeBSD Core Team Secretary 
>  wrote:
> 
> Hi,
> 
> Following on from the effort in 2019, The FreeBSD team is arranging another 
> Community Survey to help shape the future of The FreeBSD Project. The purpose 
> of this survey is to collect quantitative data from the public in order to 
> help guide the project’s priorities and efforts. Similar  surveys have been 
> conducted twice by the FreeBSD Project and we are preparing for our third.
> 
> Before publishing the next survey the Core Team welcomes you to attend for a 
> Virtual Town Hall meeting to share some of the insights of the 2020 Community 
> Survey, and seek advice on how the next survey should be conducted. The 
> virtual Town Hall will take place on the 17th of March 2021, at 18:00 hours 
> GMT/UTC. See https://wiki.freebsd.org/OfficeHours for details on how to join 
> either a live stream to watch, or an interactive meeting to participate.
> 
> If time permits the Core Team may be able to answer questions related to the 
> survey process.. If you have any specific questions that you would like 
> answered during the session you can send an email to core@ ahead of the 
> meeting which the Core Team will try to address.
> 
> Thanks! We look forward to meeting you.
> 
> Regards,
> Moin (bofh), with core-secretary@ hat on
> 



signature.asc
Description: Message signed with OpenPGP

Re: ThinkPad: reboots after successful shutdown -p

[Unbound]

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 mailto:delp...@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  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-unsubscr...@freebsd.org"

Re: Getting started with ktls

[tech-lists]

On Tue, Mar 16, 2021 at 11:46:27PM +, Rick Macklem wrote:


Well, if you do "sysctl -a | fgrep kern.ipc.tls.stats" and it is working,
you should see the count for at least one of the "crypts" ticking up.
If they are all zero, it isn't working. That might depend on the apps
or setup and does not necessarily indicate broken.


OK. it's "not working" by those criteria on the stable/13 rpi4. 
This one has mutt (imaps) and lynx (https) installed. mutt appears to
use tlsv1.3 to connect with my email provider. 


Trying the nfs-over-tls should definitely test it. When it works, the
data on the wire after the first couple of Null RPCs is encrypted.
Also, if you start the daemons with "-v", 


This is what i'll try once buildworld etc completes on the main/14 rpi4.
--
J.


signature.asc
Description: PGP signature

Re: Getting started with ktls

[tech-lists]

On Sun, Mar 14, 2021 at 08:55:18PM +, Rick Macklem wrote:


If you want to try NFS-over-TLS, see this:
https://people.freebsd.org/~rmacklem/nfs-over-tls-setup.txt

Please let us know if you try it, rick


Hi,

I'm going to try this with 2x rpi4 machines, client on stable/13 and
server on main/14. both have zfs.

--
J.


signature.asc
Description: PGP signature

Re: Problem building x11/nvidia-driver; ref. n245494-6827435548d2

[Chris]

On 2021-03-17 05:18, Gary Jennejohn wrote:

On Wed, 17 Mar 2021 05:08:50 -0700
David Wolfskill  wrote:


My laptop is currently running main-n245489-15b82e00a164; after updating
sources to n245498-096a84721670, I am performing a source-based update.

A simialr update on my build machine (which is headless, and thus does
not use anything related to X11) was successful.

The laptop is set up to rebuild x11/nvidia-driver when the kernel
is updated.

The buildkernel step on it fails with:

...
awk -f /usr/src/sys/conf/kmod_syms.awk nvidia-modeset.ko  export_syms | 
xargs -J% objcopy % nvidia-modeset.ko

===> lib (all)
===> lib/libglvnd (all)
...
===> x11/driver (all)
===> x11/extension (all)
===> doc (all)
make[6]: "/usr/share/mk/bsd.man.mk" line 53: Malformed conditional 
(${MK_MANSPLITPKG} == "no")

make[6]: Fatal errors encountered -- cannot continue
make[6]: stopped in 
/common/S4/obj/usr/src/amd64.amd64/sys/CANARY/common/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86_64-460.56/doc

*** Error code 1

Stop.


On reviewing the list of files changed in 15b82e00a164..096a84721670, I
note a couple of promising-looking candidates:

 share/mk/bsd.opts.mk|   1 +
 share/mk/src.opts.mk|   1 -

Reviewing the commit log for share/mk/bsd.opts.mk, I see that the most
recent entry is:

| commit 6827435548d257c672f934db5c6ff01012d96995
| Author: Jung-uk Kim 
| Date:   Tue Mar 16 14:16:10 2021 -0400
|
| pkgbase: Fix building out-of-tree manual pages
|
| c7e6cb9e08d6 introduced MK_MANSPLITPKG but it was not available for
| building out-of-tree manual pages.  For example, x11/nvidia-driver 
fails

| with the following error:
|
| ===> doc (all)
| make[3]: "/usr/share/mk/bsd.man.mk" line 53: Malformed conditional 
(${MK_MANSPLITPKG} == "no")

| make[3]: Fatal errors encountered -- cannot continue
|
| Move the definition from src.opts.mk to bsd.opts.mk to make it 
visible.


which looks ... apropos.

Indeed, it appears that the n245494-6827435548d2 change was intended to
fix the issue that I am now just seeing.

But I readily confess that I have neither familairity nor expertise
with share/mk/* (and that delving into it reminds me of "You are
in a mazy twist of passages, all different")

So...  help?  What do I need to do to be able to build the kernel now?

(E.g., if I need to just skip building x11/nvidia-driver once, get
everything installed, then build "normally" (with x11/nvidia-driver)
-- that's fine; I just need a clue.)



For me trying to build nvidia-driver along with the kernel always fails
miserably.

+1 for me too. I didn't _used_ to have this problem. But when I hit it.
I simply modified my procedure (as you), and never looked back.



My tree is at 096a8472167..c96151d3350  main.

Building the kernel on its own followed by building nvidia-driver in
the ports tree worked for me with no problems (but I didn't install
either one of them yet).

--Chris
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: 13.0-RC2 / 14-CURRENT: Processes getting stuck in vlruwk state

[Yamagi]

Hi Mateusz,
the sysctl output after about 10 minutes into the problem is attached.
In case that its stripped by Mailman a copy can be found here:
https://deponie.yamagi.org/temp/sysctl_vlruwk.txt.xz

Regards,
Yamagi

On Wed, 17 Mar 2021 15:57:59 +0100
Mateusz Guzik  wrote:

> Can you reproduce the problem and run obtain "sysctl -a"?
> 
> In general, there is a vnode limit which is probably too small. The
> reclamation mechanism is deficient in that it will eventually inject
> an arbitrary pause.
> 
> On 3/17/21, Yamagi  wrote:
> > Hi,
> > me and some other users in the ##bsdforen.de IRC channel have the
> > problem that during Poudriere runs processes getting stuck in the
> > 'vlruwk' state.
> >
> > For me it's fairly reproduceable. The problems begin about 20 to 25
> > minutes after I've started poudriere. At first only some ccache
> > processes hang in the 'vlruwk' state, after another 2 to 3 minutes
> > nearly everything hangs and the total CPU load drops to about 5%.
> > When I stop poudriere with ctrl-c it takes another 3 to 5 minutes
> > until the system recovers.
> >
> > First the setup:
> > * poudriere runs in a bhyve vm on zvol. The host is a 12.2-RELEASE-p2.
> >   The zvol has a 8k blocksize, the guests partition are aligned to 8k.
> >   The guest has only zpool, the pool was created with ashift=13. The
> >   vm has 16 E5-2620 and 16 gigabytes RAM assigned to it.
> > * poudriere is configured with ccache and ALLOW_MAKE_JOBS=yes. Removing
> >   either of these options lowers the probability of the problem to show
> >   up significantly.
> >
> > I've tried several git revisions starting with 14-CURRENT at
> > 54ac6f721efccdba5a09aa9f38be0a1c4ef6cf14 in the hope that I can find at
> > least one known to be good revision. No chance, even a kernel build
> > from 0932ee9fa0d82b2998993b649f9fa4cc95ba77d6 (Wed Sep 2 19:18:27 2020
> > +) has the problem. The problem isn't reproduceable with
> > 12.2-RELEASE.
> >
> > The kernel stack ('procstat -kk') of a hanging process is:
> > mi_switch+0x155 sleepq_switch+0x109 sleepq_catch_signals+0x3f1
> > sleepq_wait_sig+0x9 _sleep+0x2aa kern_wait6+0x482 sys_wait4+0x7d
> > amd64_syscall+0x140 fast_syscall_common+0xf8
> >
> > The kernel stack of vnlru is changing, even while the processes are
> > hanging:
> > * mi_switch+0x155 sleepq_switch+0x109 sleepq_timedwait+0x4b
> > _sleep+0x29b vnlru_proc+0xa05 fork_exit+0x80 fork_trampoline+0xe
> > * fork_exit+0x80 fork_trampoline+0xe
> >
> > Since vnlru is accumulating CPU time it looks like it's doing at least
> > something. As an educated guess I would say that vn_alloc_hard() is
> > waiting a long time or even forever to allocate new vnodes.
> >
> > I can provide more information, I just need to know what.
> >
> >
> > Regards,
> > Yamagi
> >
> > --
> > Homepage: https://www.yamagi.org
> > Github:   https://github.com/yamagi
> > GPG:  0x1D502515
> >
> 
> 
> -- 
> Mateusz Guzik 


-- 
Homepage: https://www.yamagi.org
Github:   https://github.com/yamagi
GPG:  0x1D502515


pgp_AnzseGMlt.pgp
Description: PGP signature

Re: ThinkPad: reboots after successful shutdown -p

[Chris]

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 mailto:delp...@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  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

P.S. Sorry about my last response. My MUA seems to be acting up this AM. :/
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: 13.0-RC2 / 14-CURRENT: Processes getting stuck in vlruwk state

[Mateusz Guzik]

Can you reproduce the problem and run obtain "sysctl -a"?

In general, there is a vnode limit which is probably too small. The
reclamation mechanism is deficient in that it will eventually inject
an arbitrary pause.

On 3/17/21, Yamagi  wrote:
> Hi,
> me and some other users in the ##bsdforen.de IRC channel have the
> problem that during Poudriere runs processes getting stuck in the
> 'vlruwk' state.
>
> For me it's fairly reproduceable. The problems begin about 20 to 25
> minutes after I've started poudriere. At first only some ccache
> processes hang in the 'vlruwk' state, after another 2 to 3 minutes
> nearly everything hangs and the total CPU load drops to about 5%.
> When I stop poudriere with ctrl-c it takes another 3 to 5 minutes
> until the system recovers.
>
> First the setup:
> * poudriere runs in a bhyve vm on zvol. The host is a 12.2-RELEASE-p2.
>   The zvol has a 8k blocksize, the guests partition are aligned to 8k.
>   The guest has only zpool, the pool was created with ashift=13. The
>   vm has 16 E5-2620 and 16 gigabytes RAM assigned to it.
> * poudriere is configured with ccache and ALLOW_MAKE_JOBS=yes. Removing
>   either of these options lowers the probability of the problem to show
>   up significantly.
>
> I've tried several git revisions starting with 14-CURRENT at
> 54ac6f721efccdba5a09aa9f38be0a1c4ef6cf14 in the hope that I can find at
> least one known to be good revision. No chance, even a kernel build
> from 0932ee9fa0d82b2998993b649f9fa4cc95ba77d6 (Wed Sep 2 19:18:27 2020
> +) has the problem. The problem isn't reproduceable with
> 12.2-RELEASE.
>
> The kernel stack ('procstat -kk') of a hanging process is:
> mi_switch+0x155 sleepq_switch+0x109 sleepq_catch_signals+0x3f1
> sleepq_wait_sig+0x9 _sleep+0x2aa kern_wait6+0x482 sys_wait4+0x7d
> amd64_syscall+0x140 fast_syscall_common+0xf8
>
> The kernel stack of vnlru is changing, even while the processes are
> hanging:
> * mi_switch+0x155 sleepq_switch+0x109 sleepq_timedwait+0x4b
> _sleep+0x29b vnlru_proc+0xa05 fork_exit+0x80 fork_trampoline+0xe
> * fork_exit+0x80 fork_trampoline+0xe
>
> Since vnlru is accumulating CPU time it looks like it's doing at least
> something. As an educated guess I would say that vn_alloc_hard() is
> waiting a long time or even forever to allocate new vnodes.
>
> I can provide more information, I just need to know what.
>
>
> Regards,
> Yamagi
>
> --
> Homepage: https://www.yamagi.org
> Github:   https://github.com/yamagi
> GPG:  0x1D502515
>


-- 
Mateusz Guzik 
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: ThinkPad: reboots after successful shutdown -p

[Rob Belics]

> 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.

Check to see if your ThinkPad has Wake On Lan set on. This is what happens
to me when I forget to turn that off.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Problem building x11/nvidia-driver; ref. n245494-6827435548d2

[Tomoaki AOKI]

On Wed, 17 Mar 2021 05:08:50 -0700
David Wolfskill  wrote:

> My laptop is currently running main-n245489-15b82e00a164; after updating
> sources to n245498-096a84721670, I am performing a source-based update.
> 
> A simialr update on my build machine (which is headless, and thus does
> not use anything related to X11) was successful.
> 
> The laptop is set up to rebuild x11/nvidia-driver when the kernel
> is updated.
> 
> The buildkernel step on it fails with:
> 
> ...
> awk -f /usr/src/sys/conf/kmod_syms.awk nvidia-modeset.ko  export_syms | xargs 
> -J% objcopy % nvidia-modeset.ko
> ===> lib (all)
> ===> lib/libglvnd (all)
> ...
> ===> x11/driver (all)
> ===> x11/extension (all)
> ===> doc (all)
> make[6]: "/usr/share/mk/bsd.man.mk" line 53: Malformed conditional 
> (${MK_MANSPLITPKG} == "no")
> make[6]: Fatal errors encountered -- cannot continue
> make[6]: stopped in 
> /common/S4/obj/usr/src/amd64.amd64/sys/CANARY/common/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86_64-460.56/doc
> *** Error code 1
> 
> Stop.
> 
> 
> On reviewing the list of files changed in 15b82e00a164..096a84721670, I
> note a couple of promising-looking candidates:
> 
>  share/mk/bsd.opts.mk|   1 +
>  share/mk/src.opts.mk|   1 -
> 
> Reviewing the commit log for share/mk/bsd.opts.mk, I see that the most
> recent entry is:
> 
> | commit 6827435548d257c672f934db5c6ff01012d96995
> | Author: Jung-uk Kim 
> | Date:   Tue Mar 16 14:16:10 2021 -0400
> | 
> | pkgbase: Fix building out-of-tree manual pages
> | 
> | c7e6cb9e08d6 introduced MK_MANSPLITPKG but it was not available for
> | building out-of-tree manual pages.  For example, x11/nvidia-driver fails
> | with the following error:
> | 
> | ===> doc (all)
> | make[3]: "/usr/share/mk/bsd.man.mk" line 53: Malformed conditional 
> (${MK_MANSPLITPKG} == "no")
> | make[3]: Fatal errors encountered -- cannot continue
> | 
> | Move the definition from src.opts.mk to bsd.opts.mk to make it visible.
> 
> which looks ... apropos.
> 
> Indeed, it appears that the n245494-6827435548d2 change was intended to
> fix the issue that I am now just seeing.
> 
> But I readily confess that I have neither familairity nor expertise
> with share/mk/* (and that delving into it reminds me of "You are
> in a mazy twist of passages, all different")
> 
> So...  help?  What do I need to do to be able to build the kernel now?
> 
> (E.g., if I need to just skip building x11/nvidia-driver once, get
> everything installed, then build "normally" (with x11/nvidia-driver)
> -- that's fine; I just need a clue.)
> 
> Thanks.
> 
> Peace,
> david
> -- 
> David H. Wolfskill  da...@catwhisker.org
> That broadly-popular "American Rescue Plan" (stimulus/COVID relrief)?
> Ever Republican vote in Congress was against it.
> 
> See https://www.catwhisker.org/~david/publickey.gpg for my public key.

Hi.

Once world whichever between git c7e6cb9e08d6 and 0b373f26bea1 is
installed, nvidia-driver SHOULD ALWAYS FAIL until world after git
6827435548d2 is installed.

This is the primary reason why I don't like/don't use current
PORTS_MODULES approach. (Not all modules are mandatory to boot.)

Building PORTS_MODULES would be better having separate target,
something like buildportsmodules/installportsmodules and do NOT block
buildkernel/installkernel.

With the approach, buildportsmodules/installportsmodules may depend on
buildkernel/installkernel.

Regards.


-- 
Tomoaki AOKI
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

13.0-RC2 / 14-CURRENT: Processes getting stuck in vlruwk state

[Yamagi]

Hi,
me and some other users in the ##bsdforen.de IRC channel have the
problem that during Poudriere runs processes getting stuck in the
'vlruwk' state.

For me it's fairly reproduceable. The problems begin about 20 to 25
minutes after I've started poudriere. At first only some ccache
processes hang in the 'vlruwk' state, after another 2 to 3 minutes
nearly everything hangs and the total CPU load drops to about 5%.
When I stop poudriere with ctrl-c it takes another 3 to 5 minutes
until the system recovers.

First the setup:
* poudriere runs in a bhyve vm on zvol. The host is a 12.2-RELEASE-p2.
  The zvol has a 8k blocksize, the guests partition are aligned to 8k.
  The guest has only zpool, the pool was created with ashift=13. The
  vm has 16 E5-2620 and 16 gigabytes RAM assigned to it.
* poudriere is configured with ccache and ALLOW_MAKE_JOBS=yes. Removing
  either of these options lowers the probability of the problem to show
  up significantly.

I've tried several git revisions starting with 14-CURRENT at
54ac6f721efccdba5a09aa9f38be0a1c4ef6cf14 in the hope that I can find at
least one known to be good revision. No chance, even a kernel build
from 0932ee9fa0d82b2998993b649f9fa4cc95ba77d6 (Wed Sep 2 19:18:27 2020
+) has the problem. The problem isn't reproduceable with
12.2-RELEASE.

The kernel stack ('procstat -kk') of a hanging process is:
mi_switch+0x155 sleepq_switch+0x109 sleepq_catch_signals+0x3f1
sleepq_wait_sig+0x9 _sleep+0x2aa kern_wait6+0x482 sys_wait4+0x7d
amd64_syscall+0x140 fast_syscall_common+0xf8

The kernel stack of vnlru is changing, even while the processes are
hanging:
* mi_switch+0x155 sleepq_switch+0x109 sleepq_timedwait+0x4b
_sleep+0x29b vnlru_proc+0xa05 fork_exit+0x80 fork_trampoline+0xe
* fork_exit+0x80 fork_trampoline+0xe

Since vnlru is accumulating CPU time it looks like it's doing at least
something. As an educated guess I would say that vn_alloc_hard() is
waiting a long time or even forever to allocate new vnodes.

I can provide more information, I just need to know what.


Regards,
Yamagi

-- 
Homepage: https://www.yamagi.org
Github:   https://github.com/yamagi
GPG:  0x1D502515


pgpysmCSnldjz.pgp
Description: PGP signature

Re: Problem building x11/nvidia-driver; ref. n245494-6827435548d2

[David Wolfskill]

On Wed, Mar 17, 2021 at 02:11:48PM +0100, Gary Jennejohn wrote:
> ...
> Well, I have obj under my home directory and do all my builds as a
> normal user rather than as root.  I suspect that's why it always fails
> for me.  Root owns /usr/src and /usr/ports.

Hmm... I won't claim a causal relationship, but note that our approaches
differ.  And a bit of variety is a Good Thing. :-)

In my case, I own /usr/src, but do the builds as root (via "sudo").  The
owner for ports is the user I set up to maintain my repository mirrors;
I update installed ports (or install/delete ports) as root.

> But I don't rebuild the driver until the kldload fails at boot time. 
> I'd guess that > 90% of kernel changes do not impact the driver's
> functionality.

Probably, though that number is likely higher in head than in one of the
stable/* branches.  And the driver itself gets an update on occasion.

> -- 
> Gary Jennejohn

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
That broadly-popular "American Rescue Plan" (stimulus/COVID relrief)?
Ever Republican vote in Congress was against it.

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Problem building x11/nvidia-driver; ref. n245494-6827435548d2

[Gary Jennejohn]

On Wed, 17 Mar 2021 05:33:14 -0700
David Wolfskill  wrote:

> On Wed, Mar 17, 2021 at 01:18:37PM +0100, Gary Jennejohn wrote:
> > On Wed, 17 Mar 2021 05:08:50 -0700
> > David Wolfskill  wrote:
> > ...   
> > > Indeed, it appears that the n245494-6827435548d2 change was intended to
> > > fix the issue that I am now just seeing.
> > >  ...
> > > So...  help?  What do I need to do to be able to build the kernel now?
> > > 
> > > (E.g., if I need to just skip building x11/nvidia-driver once, get
> > > everything installed, then build "normally" (with x11/nvidia-driver)
> > > -- that's fine; I just need a clue.)
> > >   
> > 
> > For me trying to build nvidia-driver along with the kernel always fails
> > miserably.  
> 
> Huh.  That has not been my experience: I have
> 
> PORTS_MODULES+=x11/nvidia-driver
> 
> in /etc/src.conf, and it almost always Just Works.  (I'm tracking head,
> stable/12, and (now) stable/13 daily, so that's quite a number of
> build/installs.)
> 

Well, I have obj under my home directory and do all my builds as a
normal user rather than as root.  I suspect that's why it always fails
for me.  Root owns /usr/src and /usr/ports.

But I don't rebuild the driver until the kldload fails at boot time. 
I'd guess that > 90% of kernel changes do not impact the driver's
functionality.

-- 
Gary Jennejohn
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Problem building x11/nvidia-driver; ref. n245494-6827435548d2

[David Wolfskill]

On Wed, Mar 17, 2021 at 01:18:37PM +0100, Gary Jennejohn wrote:
> On Wed, 17 Mar 2021 05:08:50 -0700
> David Wolfskill  wrote:
> ... 
> > Indeed, it appears that the n245494-6827435548d2 change was intended to
> > fix the issue that I am now just seeing.
> >  ...
> > So...  help?  What do I need to do to be able to build the kernel now?
> > 
> > (E.g., if I need to just skip building x11/nvidia-driver once, get
> > everything installed, then build "normally" (with x11/nvidia-driver)
> > -- that's fine; I just need a clue.)
> > 
> 
> For me trying to build nvidia-driver along with the kernel always fails
> miserably.

Huh.  That has not been my experience: I have

PORTS_MODULES+=x11/nvidia-driver

in /etc/src.conf, and it almost always Just Works.  (I'm tracking head,
stable/12, and (now) stable/13 daily, so that's quite a number of
build/installs.)

> My tree is at 096a8472167..c96151d3350  main.
> 
> Building the kernel on its own followed by building nvidia-driver in
> the ports tree worked for me with no problems (but I didn't install
> either one of them yet).
> 

I did go ahead and comment out the above-quoted /etc/src.conf line,
re-started hte build/install (which worked without incident).

I have restored the

PORTS_MODULES+=x11/nvidia-driver

line in /etc/src.conf, and I'm rebuilding again.

I suspect that I could merely have copied (installed) the updated
share/mk/* files... but it's my perception that there are some exposed
sharp edges there. :-}

OK; the rebuild that includes x11/nvidia-driver appears to have
succeeded, so that appears to be *a* way to address it.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
That broadly-popular "American Rescue Plan" (stimulus/COVID relrief)?
Ever Republican vote in Congress was against it.

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Problem building x11/nvidia-driver; ref. n245494-6827435548d2

[Gary Jennejohn]

On Wed, 17 Mar 2021 05:08:50 -0700
David Wolfskill  wrote:

> My laptop is currently running main-n245489-15b82e00a164; after updating
> sources to n245498-096a84721670, I am performing a source-based update.
> 
> A simialr update on my build machine (which is headless, and thus does
> not use anything related to X11) was successful.
> 
> The laptop is set up to rebuild x11/nvidia-driver when the kernel
> is updated.
> 
> The buildkernel step on it fails with:
> 
> ...
> awk -f /usr/src/sys/conf/kmod_syms.awk nvidia-modeset.ko  export_syms | xargs 
> -J% objcopy % nvidia-modeset.ko
> ===> lib (all)
> ===> lib/libglvnd (all)  
> ...
> ===> x11/driver (all)
> ===> x11/extension (all)
> ===> doc (all)  
> make[6]: "/usr/share/mk/bsd.man.mk" line 53: Malformed conditional 
> (${MK_MANSPLITPKG} == "no")
> make[6]: Fatal errors encountered -- cannot continue
> make[6]: stopped in 
> /common/S4/obj/usr/src/amd64.amd64/sys/CANARY/common/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86_64-460.56/doc
> *** Error code 1
> 
> Stop.
> 
> 
> On reviewing the list of files changed in 15b82e00a164..096a84721670, I
> note a couple of promising-looking candidates:
> 
>  share/mk/bsd.opts.mk|   1 +
>  share/mk/src.opts.mk|   1 -
> 
> Reviewing the commit log for share/mk/bsd.opts.mk, I see that the most
> recent entry is:
> 
> | commit 6827435548d257c672f934db5c6ff01012d96995
> | Author: Jung-uk Kim 
> | Date:   Tue Mar 16 14:16:10 2021 -0400
> | 
> | pkgbase: Fix building out-of-tree manual pages
> | 
> | c7e6cb9e08d6 introduced MK_MANSPLITPKG but it was not available for
> | building out-of-tree manual pages.  For example, x11/nvidia-driver fails
> | with the following error:
> | 
> | ===> doc (all)
> | make[3]: "/usr/share/mk/bsd.man.mk" line 53: Malformed conditional 
> (${MK_MANSPLITPKG} == "no")
> | make[3]: Fatal errors encountered -- cannot continue
> | 
> | Move the definition from src.opts.mk to bsd.opts.mk to make it visible.
> 
> which looks ... apropos.
> 
> Indeed, it appears that the n245494-6827435548d2 change was intended to
> fix the issue that I am now just seeing.
> 
> But I readily confess that I have neither familairity nor expertise
> with share/mk/* (and that delving into it reminds me of "You are
> in a mazy twist of passages, all different")
> 
> So...  help?  What do I need to do to be able to build the kernel now?
> 
> (E.g., if I need to just skip building x11/nvidia-driver once, get
> everything installed, then build "normally" (with x11/nvidia-driver)
> -- that's fine; I just need a clue.)
> 

For me trying to build nvidia-driver along with the kernel always fails
miserably.

My tree is at 096a8472167..c96151d3350  main.

Building the kernel on its own followed by building nvidia-driver in
the ports tree worked for me with no problems (but I didn't install
either one of them yet).

-- 
Gary Jennejohn
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Problem building x11/nvidia-driver; ref. n245494-6827435548d2

[David Wolfskill]

My laptop is currently running main-n245489-15b82e00a164; after updating
sources to n245498-096a84721670, I am performing a source-based update.

A simialr update on my build machine (which is headless, and thus does
not use anything related to X11) was successful.

The laptop is set up to rebuild x11/nvidia-driver when the kernel
is updated.

The buildkernel step on it fails with:

...
awk -f /usr/src/sys/conf/kmod_syms.awk nvidia-modeset.ko  export_syms | xargs 
-J% objcopy % nvidia-modeset.ko
===> lib (all)
===> lib/libglvnd (all)
...
===> x11/driver (all)
===> x11/extension (all)
===> doc (all)
make[6]: "/usr/share/mk/bsd.man.mk" line 53: Malformed conditional 
(${MK_MANSPLITPKG} == "no")
make[6]: Fatal errors encountered -- cannot continue
make[6]: stopped in 
/common/S4/obj/usr/src/amd64.amd64/sys/CANARY/common/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86_64-460.56/doc
*** Error code 1

Stop.


On reviewing the list of files changed in 15b82e00a164..096a84721670, I
note a couple of promising-looking candidates:

 share/mk/bsd.opts.mk|   1 +
 share/mk/src.opts.mk|   1 -

Reviewing the commit log for share/mk/bsd.opts.mk, I see that the most
recent entry is:

| commit 6827435548d257c672f934db5c6ff01012d96995
| Author: Jung-uk Kim 
| Date:   Tue Mar 16 14:16:10 2021 -0400
| 
| pkgbase: Fix building out-of-tree manual pages
| 
| c7e6cb9e08d6 introduced MK_MANSPLITPKG but it was not available for
| building out-of-tree manual pages.  For example, x11/nvidia-driver fails
| with the following error:
| 
| ===> doc (all)
| make[3]: "/usr/share/mk/bsd.man.mk" line 53: Malformed conditional 
(${MK_MANSPLITPKG} == "no")
| make[3]: Fatal errors encountered -- cannot continue
| 
| Move the definition from src.opts.mk to bsd.opts.mk to make it visible.

which looks ... apropos.

Indeed, it appears that the n245494-6827435548d2 change was intended to
fix the issue that I am now just seeing.

But I readily confess that I have neither familairity nor expertise
with share/mk/* (and that delving into it reminds me of "You are
in a mazy twist of passages, all different")

So...  help?  What do I need to do to be able to build the kernel now?

(E.g., if I need to just skip building x11/nvidia-driver once, get
everything installed, then build "normally" (with x11/nvidia-driver)
-- that's fine; I just need a clue.)

Thanks.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
That broadly-popular "American Rescue Plan" (stimulus/COVID relrief)?
Ever Republican vote in Congress was against it.

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: ThinkPad: reboots after successful shutdown -p

[Tomoaki AOKI]

On Wed, 17 Mar 2021 00:01:49 -0700
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  > > 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  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,
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> 

Hi.

Unclear if it's related or not, but my ThinkPad P52 often refuses
keyboard input on loader.efi and boot1.efi (boot1.efi as bootx64.efi).

In such cases, I need (typically) one or more power cycle to go into
single user mode with updated kernel (for installword).

Also experienced unintended auto-reboot-after-poweroff on P52, but only
once, currently.

I suspect some hardware with no FreeBSD driver can trigger interrupt
storm because of the lack of proper initialization and detach.

IIRC, my old ThinkPad T420 didn't have the problem.
So possibly UEFI firmware issue.

Regards.

-- 
Tomoaki AOKI
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: ThinkPad: reboots after successful shutdown -p

[Xin Li via freebsd-current]

On 3/16/21 9:45 PM, Warner Losh wrote:
> 
> 
> On Tue, Mar 16, 2021 at 10:18 PM Xin Li  > 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  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,
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"