[Bug 256594] AMD Ryzen CPU stutter (responsiveness lag)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256594 --- Comment #12 from simony...@gmail.com --- Actually, sorry, I just discovered this might be a different bug altogether for the following reasons: 1. I tried setting kern.sched.steal_thresh=0 as per cr...@rlwinm.de directions. There is no effect. 2. I tried the install of Release 12.4 instead and there is no more lag. However, I believe this bug affects both 13 and release 12. I will need to investigate this issue through other channels instead to avoid hijacking the thread. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 268562] bsdtar --fast-read not working when reading archive from stdin
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268562 Bug ID: 268562 Summary: bsdtar --fast-read not working when reading archive from stdin Product: Base System Version: 13.1-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: bin Assignee: b...@freebsd.org Reporter: r...@mip.xs4all.nl Steps to reproduce: A (large) TAR archive has been written to a raw disk /dev/da4. The disk (1TB) is much larger than the archive (160GB). Restoring a single file may take a long time, as tar reads all the way to the end of the archive. This can be solved with the -q option: $ tar -xzOqf /dev/da4 myfile | md5sum Result is the same, only much faster. The checksum is correct. So far so good, but when tar is in a pipeline, it is slow again: $ dd if=/dev/da4 bs=64k | tar -xzOqf - myfile | md5sum Actual result: It appears the -q option does not work when archive is stdin (-f-) This looks like a bug of the (bsd)tar program. Expected result: I expected that the tar program would exit and close its input and output after retrieval of 'myfile'. This would break the pipe to dd, and it would stop as well. Anyway, if dd is killed manually after the md5sum cpu usage has fallen to 0%, the correct result is shown. It would be nice if killing is not needed. -- You are receiving this mail because: You are the assignee for the bug.
Problem reports for b...@freebsd.org that need special attention
To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status |Bug Id | Description +---+--- New |197876 | [devfs] an error in devfs leads to data loss and New |198797 | [PATCH] Added an option to install BSDstats to bs New |202362 | ntp: restore refclocks selection (10.2-RELEASE re New |202740 | vi/ex string substitution problem when there is m New |204097 | witness_initialize() does not perform bound check New |206336 | [patch] usr.sbin/freebsd-update allow proxy confi New |209213 | UEFI Loader shows only black screen with Nvidia G New |210804 | installerconfig - using ZFS create in custom scri New |223470 | freebsd-update: Cannot identify running kernel (/ New |230620 | "install -d" issue New |235085 | [PATCH] Option to make rc.d/sysctl more verbose ( New |252123 | fetch(3): Fix wrong usage of proxy when request i Open|177821 | sysctl: Some security.jail nodes are funky, dupli Open|182466 | [headers] [patch] make self-contained Open|183618 | [panic] Dell PowerEdge R620 -- PERC H710 Mini (mf Open|192573 | Add ps(1) option: Print process start time in sec Open|194925 | [pf] [ifconfig] interface group keywords do not w Open|197921 | scheduler: Allow non-migratable threads to bind t Open|206528 | Emulex LPe 16002 FC HBA Not Recognized by oce(4) Open|206649 | cyapa(4): Add common gestures for Cypress APA I2C Open|207940 | stand/efi/boot1: Add boot partition selection Open|212608 | sockstat(1) and lsof(8) can not identity the owne Open|220246 | syslogd does not send RFC3164-conformant messages Open|221305 | Mouse cursor loss when moving cursor while loadin Open|221550 | kern.bootfile returns only /kernel on mips64 (ERL Open|221854 | makefs: Reject UFS labels that are too long to fi Open|226893 | freebsd-update: Support patchlevel argument for f Open|231810 | [build] release always fails with "mkimg: partiti Open|233578 | Unprivileged local user can prevent other users l Open|233988 | freebsd-update: Improve progress output on termin Open|236718 | system panics with message: vm_fault_hold: fault Open|237287 | moused(8) ignores button release events in virtua Open|237924 | Possible infinite loop in function empty_aux_buff Open|238183 | cam/scsi/scsi_sa.c: warnings issued by static ana Open|238486 | Possible buffer overflow bug in sc_allocate_keybo Open|238550 | Touchpad (via SMBus) not working: Synaptics (SYN1 Open|238638 | mfi: Remove unnecessary pointer printing in mfi.c Open|238837 | init: Remove P_SYSTEM flag from PID 1 to allow ea Open|241697 | i915kms: Kernel panic loading module on custom ke Open|247132 | Fix build error: use of undeclared identifier 'cp Open|248352 | mfi(4): Remove RAID map sync functionality Open|257149 | CFLAGS not passed to whole build New |260138 | TPM2 Support in bootloader / kernel in order to r New |261306 | Geli rc.d script does not support insertion of US New |267537 | contrib/nvi: Fix core dump when tags file pattern Open|179832 | manual page of mac_from_text suggests incorrect f Open|262957 | mpr(4), mps(4): change formally to formerly 47 problems total for which you should take action.
[Bug 256594] AMD Ryzen CPU stutter (responsiveness lag)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256594 --- Comment #11 from cr...@rlwinm.de --- If you're still stuck try breakout out into the loader prompt by pressing escape during the 10 second countdown in the bootloader menu. On the loader prompt type: set kern.sched.steal_thresh=0 boot To persist this you can put this line into /boot/loader.conf to apply as early as possible: kern.sched.steal_thresh="0" To apply it slightly later you can add the same line to /etc/sysctl.conf as initially reported in this thread. The stutter wasn't bad enough during installation on my personal workstation which als moonlights as a gaming rig (AMD Ryzen 9 3950X, 32GB DDR4-3600 RAM, RTX 3090 GPU). It just felt slightly off at the vt(4) console. I couldn't place it at the time. With Xorg and the Nvidia driver loaded the system was still fast when compiling etc., but felt very sluggish and lots of tearing in i3. Supposedly smooth scrolling in browsers etc. was nothing of the sort. To get a pleasant desktop experience without tearing I also had to force the Nvidia driver to use a less efficient form of composition which increased idle power consumption by ~10W, because it keeps the GPU from staying in the lowest power state even when just editing source code in urxvt and gvim. -- You are receiving this mail because: You are the assignee for the bug.
