Re: freebsd 13 ryzen micro stutter

[myfreeweb]

On March 23, 2021 9:11:46 AM UTC, Michael Gmelin  wrote:
>
>
>On Mon, 22 Mar 2021 23:50:52 -0400
>monochrome  wrote:
>
>> After about 8 months of struggling to narrow this down I did another 
>> search and saw this:
>> 
>> https://www.reddit.com/r/freebsd/comments/lc8fwo/freebsd_13_vega_64_micro_stutter_in_x/
>> 
>> I haven't seen this come up here so I thought I would bring it up.
>> 
>> My story started sometime before around August last year when synergy 
>> started getting really annoying with stuttering. Pretty sure it
>> wasn't like that when I first started tracking 13-current in around
>> May 2020 (I was on 12 with scfb for a long time before that with no
>> issues), but since then I have tried to eliminate as many variables
>> as possible. First I switched to barrier instead of synergy. Shortly
>> after that I realized it was happening all the time and not just a
>> network problem, I started using foobillard to verify during tests. I
>> tried different RAM combinations, different network cards, a variety
>> of RAM timings, stripping rc.conf etc, powerd settings, also scfb,
>> with no effect. It is observable with ping -f, a dot or two appears
>> every time it glitches. It seemed much better with RC2, but now with
>> RC3 it seems to be back with a vengeance, and since its my main
>> workstation and barrier/synergy server host for several machines, it
>> is unbearable to use. Both Win10 and devuan3 on the same machine are
>> smooth with no issues. Any feedback or info would be appreciated.
>> 
>> Hardware:
>> ASRock B450M Pro4
>> Ryzen 2400G, no OC
>> 32M DDR4-2933
>> Onboard Vega GPU, drm-fbsd13-kmod
>> ___
>
>Without knowing much about the issue at hand, just a few ideas:
>
>Sysctls I would look at:
>- raising *.cx_lowest
>- different kern.eventtimer.timer

None of these should be an issue, but:

sysctl kern.sched.steal_thresh=1

For some reason with the default value of 2, I'm seeing weird stuttering in 
youtube videos, games, etc. on a 5950X system. 1 (or 0, IIRC) works fine.

>Try running with powerd disabled.

well, if you do that, don't forget to manually set the freq sysctl to the 
maximum
___
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: Issues with USB-C external monitors

[myfreeweb]

On December 1, 2020 2:00:55 PM UTC, Hans Petter Selasky  
wrote:
>On 12/1/20 2:14 PM, Ali Abdallah wrote:
>> Hello,
>> 
>> I have a T495 with a USB-C docking station with two external monitors,
>> running current to get the vega 10 amdgpu to work.
>> 
>> When the power is lost for on the USB-C dock, then the X server looses
>> all external monitors. They appear as disconnected after running xrandr
>> and I cannot figure out a way to bring them back without killing my
>> current session and start X again, but that is very annoying...
>> 
>> I tried to debug the issue and I'm pretty sure that the X server on
>> FreeBSD is not reconfiguring the drm connectors automatically.
>> 
>> Let's say I have DP-4 as external connector, when the power is lost,
>> DP-4 disappears, when the power is back, DP-4 re-appear again but in
>> unknown status.
>> 
>> $ sysctl sys.class.drm | grep DP-4
>> sys.class.drm.card0-DP-4.modes:
>> sys.class.drm.card0-DP-4.dpms: Off
>> sys.class.drm.card0-DP-4.enabled: disabled
>> sys.class.drm.card0-DP-4.status: unknown
>> 
>> Now just running a simple libdrm code to rescan the connectors:
>> 
>> __snippet__
>> res = drmModeGetResources(fd);
>> for (int i = 0; i < res->count_connectors; ++i) {
>> conn = drmModeGetConnector(fd, res->connectors[i]);

Note: you can run graphics/drm_info instead of writing custom code.

>> After running the above code, the drm stack is somehow triggered to
>> re-read the DP-4.status, which appears now to be connected, but not
>> configured.
>> 
>> $ sysctl sys.class.drm | grep DP-4
>> sys.class.drm.card0-DP-4.modes: 1920x1080
>> sys.class.drm.card0-DP-4.dpms: Off
>> sys.class.drm.card0-DP-4.enabled: disabled
>> sys.class.drm.card0-DP-4.status: connected
>> 
>> I didn't dig further to see if I can trigger the X server to re-scan drm
>> connectors and eventually remove those that vanished, and add newly
>> detected connectors. On Linux that seems to work automatically.
>> 
>> Any thoughts?

devd (really drm in the kernel) provides hotplug events (system DRM, type 
HOTPLUG).
libudev-devd translates these to UD_ACTION_HOTPLUG.
This works well with wlroots compositors at least.
How xorg does this I have no idea, as I don't use xorg.
If your xorg is built with DEVD instead of UDEV option, it shouldn't work, I 
don't recall anyone adding support for that there.
With UDEV it might work?

>There is missing code in the kernel to handle USB-C PCI express 
>attach/detach. CC'ing Scott Long.

Seems like this is about regular DisplayPort over USB-C (the USB side almost 
always handled in firmware for this on non-embedded computers).
I don't think I've ever seen a *monitor* connecting over PCIe to an existing 
GPU ;)
(in this case card0, the onboard vega)
___
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: /usr/lib/libomp.so : is there a reason that aarch64 does not have such by default?

[myfreeweb]

On August 21, 2020 6:52:23 PM UTC, Mark Millard via freebsd-arm 
 wrote:
>My context: head ( currently at -r363590 )
>
>man src.conf is explicit that WITHOUT_OPENMP is the default for
>aarch64 (for example).
[...]
>Nothing stands out for why WITH_OPENMP is in use by default only
>for amd64, i386, and powerpc64.

Because nobody has bothered to merge https://reviews.freebsd.org/D21167
___
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: В ответ на: Re: editors/libreoffice PDF export/printing broken

[myfreeweb]

On July 4, 2020 1:12:39 PM UTC, Jesper Schmitz Mouridsen 
 wrote:
>Accidentally found on twitter
>
>Colin Percival
>@cperciva
>
>
>In case anyone else (including future-me) runs into the same problem: If 
>LibreOffice"export to PDF" produces pages without any text, set 
>"SAL_VCL_QT5_USE_CAIRO=true" in the environment. No, I have no idea why. 
>Ran into this on FreeBSD; found the fix on the Lubuntu forum.

Maybe switching the default UI backend to qt5 was a mistake ;)

gtk3 isn't really "broken", it has a relatively minor visual bug that only 
happens on FreeBSD. Maybe if it was the default, someone would be motivated 
enough to fix it.
___
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: weird Ctrl-T debug messages

[myfreeweb]

On June 27, 2020 7:04:06 AM UTC, "Hartmann, O."  wrote:
>Running poudriere on recent CURRENT with (recent) 12-STABLE and CURRENT
>jails reveals a weird behaviour recently when hitting Ctrl-T:
>
>[...]
>
>[13:37:48] [01] [00:00:00] Building databases/sqlitestudio |
>sqlitestudio-3.2.1.1002 load: 26.95  cmd: sh 99331 [piperd] 49375.18r
>0.59u 0.59s 0% 2144k #0 0x80924ace at mi_switch+0xbe
>#1 0x809781d4 at sleepq_catch_signals+0x4a4
>#2 0x80977d19 at sleepq_wait_sig+0x9
>#3 0x809241ad at _sleep+0x1ad
>#4 0x8098ae5a at pipe_read+0x43a
>#5 0x80987a85 at dofileread+0x85
>#6 0x8098766f at sys_read+0xcf
>#7 0x80d70229 at amd64_syscall+0x119
>#8 0x80d47bf0 at fast_syscall_common+0x101
>
>Is this debug fallout from /bin/sh?

Haha, no (how would /bin/sh affect all programs?)

It's kern.tty_info_kstacks now being on by default in current. It's very useful 
(not when running poudriere, but when investigating hanging programs) and I 
probably wouldn't have ever discovered it without the commit making it default.
___
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"