Re: freebsd 13 ryzen micro stutter
On 27/03/2021 12:54, Santiago Martinez wrote: > Hi, i have the same output as @Nils B. If i run with steal =2 and dtrace the > micro stutter doesn't happen but as soon as i stop the dtrace script it the > stutters come back again. It seems that DTrace creates some extra CPU load that masks the problem. So, I guess that DTrace produced traces won't have many clues, if any at all. I wonder if KTR tracing would be better in this respect. -- Andriy Gapon ___ 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 13 ryzen micro stutter
Hi Alastair and Hans, I just realized that my email went out blank. i did some further testing with the mentioned patch and I still have stutter, less often but more pronounced. I went back an set "kern.sched.steal_thresh=1" and that completely clears it, and machine works more smoothly. Santi On 3/31/21 10:35 AM, Alastair Hogge wrote: On 2021-03-28 16:09, Hans Petter Selasky wrote: On 3/27/21 11:54 AM, Santiago Martinez wrote: Hi, i have the same output as @Nils B. If i run with steal =2 and dtrace the micro stutter doesn't happen but as soon as i stop the dtrace script it the stutters come back again. Here is a patch which you can try. Not sure if it helps. https://reviews.freebsd.org/D29467 Thanks Hans, this reduces jitter somewhat, but it still noticeable in Quake2. I left kern.sched.steal_thresh at 1. To good health, Alastair. ___ 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" ___ 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 13 ryzen micro stutter
OP here, I've been running with kern.sched.steal_thresh=1 with no stutter since it was originally suggested. I tried these instead and I get stutter, maybe a little less but its definitely back. On 4/3/21 1:23 AM, Rozhuk Ivan wrote: I have no micro stutter with default kern.sched.steal_thresh=2, but I have set: kern.sched.balance=0# Enables the long-term load balancer kern.sched.balance_interval=1000# Average period in stathz ticks to run the long-term balancer kern.sched.affinity=1 # Number of hz ticks to keep thread affinity for ___ 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 13 ryzen micro stutter
On Wed, 31 Mar 2021 02:35:25 -0700 Alastair Hogge wrote: > On 2021-03-28 16:09, Hans Petter Selasky wrote: > > On 3/27/21 11:54 AM, Santiago Martinez wrote: > >> Hi, i have the same output as @Nils B. If i run with steal =2 and > >> dtrace the micro stutter doesn't happen but as soon as i stop the > >> dtrace script it the stutters come back again. > > > > Here is a patch which you can try. Not sure if it helps. > > https://reviews.freebsd.org/D29467 > > Thanks Hans, this reduces jitter somewhat, but it still noticeable in > Quake2. I left kern.sched.steal_thresh at 1. > I have no micro stutter with default kern.sched.steal_thresh=2, but I have set: kern.sched.balance=0# Enables the long-term load balancer kern.sched.balance_interval=1000# Average period in stathz ticks to run the long-term balancer kern.sched.affinity=1 # Number of hz ticks to keep thread affinity for ___ 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 13 ryzen micro stutter
___ 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 13 ryzen micro stutter
On 2021-03-28 16:09, Hans Petter Selasky wrote: > On 3/27/21 11:54 AM, Santiago Martinez wrote: >> Hi, i have the same output as @Nils B. If i run with steal =2 and dtrace the >> micro stutter doesn't happen but as soon as i stop the dtrace script it the >> stutters come back again. >> > > Here is a patch which you can try. Not sure if it helps. > https://reviews.freebsd.org/D29467 Thanks Hans, this reduces jitter somewhat, but it still noticeable in Quake2. I left kern.sched.steal_thresh at 1. To good health, Alastair. ___ 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 13 ryzen micro stutter
On 3/27/21 11:54 AM, Santiago Martinez wrote: Hi, i have the same output as @Nils B. If i run with steal =2 and dtrace the micro stutter doesn't happen but as soon as i stop the dtrace script it the stutters come back again. Here is a patch which you can try. Not sure if it helps. https://reviews.freebsd.org/D29467 --HPS ___ 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 13 ryzen micro stutter
Hi, i have the same output as @Nils B. If i run with steal =2 and dtrace the micro stutter doesn't happen but as soon as i stop the dtrace script it the stutters come back again. Santi On 3/27/21 10:39 AM, Santiago Martinez wrote: Hi there, my pause are not that often ( with steal_thresh=2) , maybe is around 30 secs or so. If i set the thresh to 1 or 0 they go away. Now im trying with =2 and schedgraph.d. Santi On 3/25/21 10:04 AM, Alastair Hogge wrote: On 2021-03-23 17:34, myfreeweb wrote: 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. I have noticed this too, firefox exhibits the issue frequently, however I have found it most noticeable in games/dhewm3[0] or Yamagi Quake 2[1]. There is a distinct pause every 3 or 4 seconds where the simulation advances significantly. Thanks for the kern.sched.steal_thresh pointer that has sorted the issue out for now. $ dmesg | egrep '(CPU:|avail memory)' CPU: AMD Ryzen 9 3950X 16-Core Processor (3500.02-MHz K8-class CPU) avail memory = 66779394048 (63685 MB) With an AMD NAVI 8GiB GPU, the host should be able to play either game well enuf, Quake 2 came out in 1997 and Doom 3 2004. I am sure Quake 2 used to play without issues on my old AMD bulldozer. 0: https://www.freshports.org/games/dhewm3/ 1: https://github.com/yquake2/yquake2 ___ 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" ___ 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 13 ryzen micro stutter
Hi there, my pause are not that often ( with steal_thresh=2) , maybe is around 30 secs or so. If i set the thresh to 1 or 0 they go away. Now im trying with =2 and schedgraph.d. Santi On 3/25/21 10:04 AM, Alastair Hogge wrote: On 2021-03-23 17:34, myfreeweb wrote: 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. I have noticed this too, firefox exhibits the issue frequently, however I have found it most noticeable in games/dhewm3[0] or Yamagi Quake 2[1]. There is a distinct pause every 3 or 4 seconds where the simulation advances significantly. Thanks for the kern.sched.steal_thresh pointer that has sorted the issue out for now. $ dmesg | egrep '(CPU:|avail memory)' CPU: AMD Ryzen 9 3950X 16-Core Processor (3500.02-MHz K8-class CPU) avail memory = 66779394048 (63685 MB) With an AMD NAVI 8GiB GPU, the host should be able to play either game well enuf, Quake 2 came out in 1997 and Doom 3 2004. I am sure Quake 2 used to play without issues on my old AMD bulldozer. 0: https://www.freshports.org/games/dhewm3/ 1: https://github.com/yquake2/yquake2 ___ 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" ___ 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 13 ryzen micro stutter
On 25.03.21 16:31, Andriy Gapon wrote: [...] There are some tools in tools/sched/ directory. schedgraph.py can be used for visual inspection of scheduling traces collected using KTR. The file has instructions on how to collect them. Alternatively, schedgraph.d can be used to collect such traces. If anyone affected can gather a short sample that captures the problem, then there might be someone who would be willing to look at them. what should I tell? I've set "kern.sched.steal_thresh: 0 -> 2" and reliably got that micro-suttering back while watching YouTube videos (tearing test i.e.). Then I loaded kernel modules "dtrace.ko" and "dtraceall.ko" and ran ./schedgraph.d > /tmp/sched.out The micro-stuttering immediately went away while above DTrace-script was running. So it seems that the light load of the running DTrace-script was enough to eliminate any micro-stutterings. I've uploaded resulting .ktr- and .out-files (for both steal_thresh=2/0) here: kern.sched.steal_thresh=2 - http://156.67.189.93:9080/sched.steal2.txz kern.sched.steal_thresh=0 - http://156.67.189.93:9080/sched.steal0.txz Haven't tried your mentioned first KTR-variant yet... Thanks and BR, Nils ___ 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 13 ryzen micro stutter
On 23/03/2021 16:54, Nils B. wrote: > Hi, > > On 23.03.21 10:34, myfreeweb wrote: >> 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. > > yes, finally... Using a Ryzen 1700, Asrock AB350 Pro4 and Radeon RX460 and > got that > awful micro stuttering all the time; not only under FreeBSD 13.0-ALPHA3 now, > but > also > under FreeBSD 12-STABLE in the past. > > Occurences were during listening to music using MPV (one-second-*krk*-loops); > watching > YouTube videos (video hangs for a second but audio continues) and often simply > during > mouse movements where even MouseKeyPress- and MouseKeyRelease-events just > didn't > reach > the system at all. > > Setting > > kern.sched.steal_thresh=0 > > eliminates these micro stutterings in the whole system. > > > I also would really, really like to know the reason why this parameter has > such an > impact... It's been a long time since I looked at that corner of the code. I think that in theory there should not be any difference between steal_thresh of zero, one and two. For a thread to be stolen there should be at least one thread that's runnable, but not running. That also should imply that there is a a thread that's currently running. So, values equal or less than two should mean the same thing. The only practical difference I can think of is a situation where a processor has a runnable thread but does not "realize" it, so the processor stays idle when it actually has work to do. If such a thread is not stolen then it may take some time for the processor to actually start running it. If it's stolen then the thread may start executing sooner on a different processor that was about to become idle. That's just a hypothesis though. If it's correct, then there can be a number of explanations. From a problem with inter-processor communication (e.g., related to mwait) to a slow wakeup of a core from a deep idle state to a problem with interrupt delivery. There are some tools in tools/sched/ directory. schedgraph.py can be used for visual inspection of scheduling traces collected using KTR. The file has instructions on how to collect them. Alternatively, schedgraph.d can be used to collect such traces. If anyone affected can gather a short sample that captures the problem, then there might be someone who would be willing to look at them. -- Andriy Gapon ___ 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 13 ryzen micro stutter
On 2021-03-23 17:34, myfreeweb wrote: > 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. I have noticed this too, firefox exhibits the issue frequently, however I have found it most noticeable in games/dhewm3[0] or Yamagi Quake 2[1]. There is a distinct pause every 3 or 4 seconds where the simulation advances significantly. Thanks for the kern.sched.steal_thresh pointer that has sorted the issue out for now. $ dmesg | egrep '(CPU:|avail memory)' CPU: AMD Ryzen 9 3950X 16-Core Processor (3500.02-MHz K8-class CPU) avail memory = 66779394048 (63685 MB) With an AMD NAVI 8GiB GPU, the host should be able to play either game well enuf, Quake 2 came out in 1997 and Doom 3 2004. I am sure Quake 2 used to play without issues on my old AMD bulldozer. 0: https://www.freshports.org/games/dhewm3/ 1: https://github.com/yquake2/yquake2 ___ 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 13 ryzen micro stutter
Hi, On 23.03.21 10:34, myfreeweb wrote: 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. yes, finally... Using a Ryzen 1700, Asrock AB350 Pro4 and Radeon RX460 and got that awful micro stuttering all the time; not only under FreeBSD 13.0-ALPHA3 now, but also under FreeBSD 12-STABLE in the past. Occurences were during listening to music using MPV (one-second-*krk*-loops); watching YouTube videos (video hangs for a second but audio continues) and often simply during mouse movements where even MouseKeyPress- and MouseKeyRelease-events just didn't reach the system at all. Setting kern.sched.steal_thresh=0 eliminates these micro stutterings in the whole system. I also would really, really like to know the reason why this parameter has such an impact... Many thanks for the hint and BR, Nils ___ 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 13 ryzen micro stutter
This also work great on my ryzen7, still don't understand why... The difference is quite noticeable, no more micro stutter, that i was used to it ( i have tried changing most parameter on sched but not the steal). Can somebody with understanding on ULE explain (in human language) why this make such a difference even when the cpu are without any load... Thanks in advance. Santi On 3/23/21 9:34 AM, myfreeweb wrote: sysctl kern.sched.steal_thresh=1 ___ 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 13 ryzen micro stutter
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: freebsd 13 ryzen micro stutter
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 Try running with powerd disabled. Try disabling acpi_thermal (debug.acpi.disabled="thermal") as stated in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234455#c9 Certainly someone else has better ideas though. Best, Michael -- Michael Gmelin ___ 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"
