system frozen

[unicorn]

Why my system dead after a few minutes? Where to check the log? 10.0 RC1

[unicorn]

my system will die if I watch videos online, any clue?

[bsd-keith]

Did you check that you got a good download/check the SHA sum(?).

(I don't get anything like that with my installs.)

[J65nko]

Not a NetBSD user yet.... But how do you watch them? In a browser? Which one? Firefox? Chrome?
Pasting a dmesg, or Xorg.*log in a pastebin would allow others to help you faster.

[unicorn]

Originally Posted by bsd-keith

Did you check that you got a good download/check the SHA sum(?).

(I don't get anything like that with my installs.)

no

[unicorn]

Originally Posted by J65nko

Not a NetBSD user yet.... But how do you watch them? In a browser? Which one? Firefox? Chrome?
Pasting a dmesg, or Xorg.*log in a pastebin would allow others to help you faster.

firefox, my dmesg

[Head_on_a_Stick]

I think the X.Org log will also be useful but I would be very surprised if 7th generation Ryzen integrated graphics are supported in NetBSD. They've only just made it into the Linux DRM stack. Your posted `dmesg` output doesn't have any DRM devices listed anyway.

That being the case you're probably running the VESA driver, which might cause the crash just because it's old & crap.

I would also be surprised if FF in NetBSD offered hardware acceleration, even if it has a tick box for it.

[jmccue]

Can you ssh into the system when frozen ? Maybe it is X as opposed to the whole system.

If so, try starting port picom in your ~/.xsession (and/or .xinitrc). That prevents most X issues for me.

picom -b &

The only issue I have left on the T420 is screen tearing when the system is under a heavy load. I have a pr opened for that.

[Head_on_a_Stick]

Originally Posted by jmccue

The only issue I have left on the T420 is screen tearing when the system is under a heavy load.

You can use picom to control that:

picom --vsync -b

Also note that adding an ampersand at the end of the line is not needed if the -b flag is passed and may cause race conditions with other applications. Only add an ampersand if the command does not return the prompt when run in a terminal.

EDIT: and I doubt picom will fix anything, compositors usually just add to the problems under X.

[jmccue]

Originally Posted by Head_on_a_Stick

You can use picom to control that:

picom --vsync -b

Also note that adding an ampersand at the end of the line is not needed if the -b flag is passed and may cause race conditions with other applications. Only add an ampersand if the command does not return the prompt when run in a terminal.

EDIT: and I doubt picom will fix anything, compositors usually just add to the problems under X.

Will give that a try and post here if it helps. I actually have picom in my ~/.xsession, but will remove the '&' to see what happens

[shep]

There are also some X11 configuration options for intel graphics tearing:
intel(4)

Option "TearFree" "boolean"
Disable or enable TearFree updates. This option forces X to per-
form all rendering to a backbuffer prior to updating the actual
display. It requires an extra memory allocation the same size as
a framebuffer, the occasional extra copy, and requires Damage
tracking. Thus enabling TearFree requires more memory and is
slower (reduced throughput) and introduces a small amount of
output latency, but it should not impact input latency. However,
the update to the screen is then performed synchronously with
the vertical refresh of the display so that the entire update is
completed before the display starts its refresh. That is only
one frame is ever visible, preventing an unsightly tear between
two visible and differing frames. Note that this replicates what
the compositing manager should be doing, however TearFree will
redirect the compositor updates (and those of fullscreen games)
directly on to the scanout thus incurring no additional overhead
in the composited case. Also note that not all compositing man-
agers prevent tearing, and if the outputs are rotated, there
will still be tearing without TearFree enabled.

Default: TearFree is disabled.

[unicorn]

Originally Posted by Head_on_a_Stick

I think the X.Org log will also be useful but I would be very surprised if 7th generation Ryzen integrated graphics are supported in NetBSD. They've only just made it into the Linux DRM stack. Your posted `dmesg` output doesn't have any DRM devices listed anyway.

That being the case you're probably running the VESA driver, which might cause the crash just because it's old & crap.

I would also be surprised if FF in NetBSD offered hardware acceleration, even if it has a tick box for it.

you're right, I use wsfb

[unicorn]

picom -b &

can't open display

[Head_on_a_Stick]

Originally Posted by shep

There are also some X11 configuration options for intel graphics tearing

The amdgpu DDX driver also has that option: https://man.openbsd.org/amdgpu#Option~6

X's builtin modesetting DDX driver will have a TearFree option added soon, it's already in the development branch: https://www.phoronix.com/news/xf86-v...tting-TearFree

Originally Posted by unicorn

I use wsfb

Okay, so that's a non-accelerated driver, which will offer very poor performance and may very well be responsible for the crashes.

I think you will have to wait for NetBSD to catch up with Linux DRM support. I think the 7th generation Ryzen iGPU support was added to Linux for kernel 6.0 so look out for that in their release notes.

OpenBSD 7.4 (the latest release) uses the 6.1.28 DRM stack so that might work for you now.

FWIW I have 7th gen Ryzen in my new laptop and it runs Arch Linux beautifully, the experience is better than it was under Windows 11, even for AAA games.

EDIT: and in respect of picom, the suggestion was to add the line to your X session startup script (~/.xsession?) rather than just running it from a console screen.

EDIT2: NetBSD 10.0 RC1 has DRM support from Linux kernel 5.6, which won't work with your hardware.

[unicorn]

Originally Posted by Head_on_a_Stick

Okay, so that's a non-accelerated driver, which will offer very poor performance and may very well be responsible for the crashes.

you're absolutely right, RC1 works well with my old laptop, see dmesg. The only problem with RC1 is my keyboard and mouse occasionally lost response which is weird.