[Bug 256594] AMD Ryzen CPU stutter (responsiveness lag)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256594

--- Comment #5 from cr...@rlwinm.de ---
(In reply to Jack from comment #0)
I still require the same workaround on my Ryzen 3950X system as well.

-- 
You are receiving this mail because:
You are the assignee for the bug.

Problem reports for b...@freebsd.org that need special attention

[bugzilla-noreply]

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|187015 | agpgart: Panic make_dev_credv: bad si_name (error 
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|222632 | connect(2) not available in capability mode   
Open|231810 | [build] release always fails with "mkimg: partiti 
Open|233578 | Unprivileged local user can prevent other users l 
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  
Open|179832 | manual page of mac_from_text suggests incorrect f 

43 problems total for which you should take action.

[Bug 232921] freebsd-update upgrade does not execute pwd_mkdb for ntpd

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=232921

Kubilay Kocak  changed:

   What|Removed |Added

  Flags||mfc-stable13-,
   ||mfc-stable12+

--- Comment #22 from Kubilay Kocak  ---
@Kyle Anything left in order resolve/close this issue?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 197308] Improve feedback of freebsd-update at failure of release upgrade

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197308

Graham Perrin  changed:

   What|Removed |Added

 CC||grahamper...@gmail.com

--- Comment #1 from Graham Perrin  ---
 touches upon a more recent case, 

freebsd-update -r 13.0-RELEASE upgrade


(In reply to Kalle Richter from comment #0)

> … The user should be informed about the reason for the failure …

+1

See also: bug 256143

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 229502] spurious error message when upgrading from 11.1p11 -> 11.2p0 via freebsd-update

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229502

Graham Perrin  changed:

   What|Removed |Added

 CC||grahamper...@gmail.com

--- Comment #1 from Graham Perrin  ---
If nothing like this has been observed with a more recent release of the OS,
might this bug be closed? (Overcome by events …)

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 229689] freebsd-update shouldn't add system breaking comments to config files

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229689

--- Comment #3 from Graham Perrin  ---
(In reply to Dan MacDonald from comment #0)


> … tired or in a hurry … blindly accepted …

Somewhat off-topic: 

* might oversight (blind acceptance) have been less likely if 
  something other than vi had been used? 

 was notionally in the
context of a proof-of-concept installer (see
), however the general
principle – allowing the end user to prefer ee – might extend to situations
such as those mentioned in this bug 229689.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 137228] [psm] synaptics support delays 'mouse up' events when no motion

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=137228

--- Comment #4 from Bertrand Petit  ---
(In reply to Bob Frazier from comment #3)
You are right I messed two opened tabs, the correct ID is bug #260381. I think
it is a regression, it may be related to the present report.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 229689] freebsd-update shouldn't add system breaking comments to config files

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229689

Graham Perrin  changed:

   What|Removed |Added

 CC||grahamper...@gmail.com

--- Comment #2 from Graham Perrin  ---
(In reply to Dan MacDonald from comment #0)

> … no hash sign at the beginning …

Good point. A design flaw, IMHO.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 260381] regression: moused(8), sysmouse(4) or psm(4) delays button release events by about 900ms

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260381

Bertrand Petit  changed:

   What|Removed |Added

 Attachment #230075|0   |1
is obsolete||
 Attachment #230246|text/x-csrc |text/plain
  mime type||

--- Comment #3 from Bertrand Petit  ---
Created attachment 230246
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=230246&action=edit
Source of the test command used to produce the traces in the bug report

Proper handling of mouse operation levels.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 233656] freebsd-update upgrade -r 12.0-RC2 fails on i386 / root on zfs / 12.0-RC1

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233656

Graham Perrin  changed:

   What|Removed |Added

 CC||grahamper...@gmail.com

--- Comment #1 from Graham Perrin  ---
Might this bug be closed, overcome by events? 

> … cannot figure out the curently running kernel. …

For what it's worth, I don't recall seeing any comparable report elsewhere over
the past year or so.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 260381] regression: moused(8), sysmouse(4) or psm(4) delays button release events by about 900ms

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260381

--- Comment #2 from Bertrand Petit  ---
This bug is a regression as testing the same hardware using either 11.4-RELEASE
or 12.1-RELEASE from a memstick shows mouse buttons operating as expected.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 234215] freebsd-update renders system unusable

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234215

Graham Perrin  changed:

   What|Removed |Added

 CC||grahamper...@gmail.com

--- Comment #2 from Graham Perrin  ---
(In reply to oz42 from comment #0)

> … the 11.2 system was built from source without GSSAPI or YPCLIENT. …

Does StrictComponents relate to this use case? 



-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 260381] regression: moused(8), sysmouse(4) or psm(4) delays button release events by about 900ms

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260381

Bertrand Petit  changed:

   What|Removed |Added

Summary|sysmouse or psm delays  |regression: moused(8),
   |button release events by|sysmouse(4) or psm(4)
   |about 900ms |delays button release
   ||events by about 900ms

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 260381] sysmouse or psm delays button release events by about 900ms

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260381

Bertrand Petit  changed:

   What|Removed |Added

Version|12.2-STABLE |12.3-STABLE

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 188220] freebsd-update(8) destroys installation

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=188220

Graham Perrin  changed:

   What|Removed |Added

 CC||grahamper...@gmail.com

--- Comment #5 from Graham Perrin  ---
(In reply to David Chisnall from comment #2)

> … just something about the 9->10 transition …

Might this bug be closed, overcome by events?

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 234538] freebsd-update hangs on upgrade from 11.2p7 to 12.0 on Google Compute Engine

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234538

Graham Perrin  changed:

   What|Removed |Added

 CC||grahamper...@gmail.com

--- Comment #5 from Graham Perrin  ---
Please, is anything like this still an issue?

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 260399] freebsd-update: Downloading patches often fails repeatedly

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260399

--- Comment #8 from Graham Perrin  ---
(In reply to Some Signup from comment #7)

> … download … patches again. …

Subscribe to bug 257247. 

Then this bug 260399 might properly focus on failure to download.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 260546] nfsv4_loadattr() can pass huge sizes to malloc()

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260546

Bug ID: 260546
   Summary: nfsv4_loadattr() can pass huge sizes to malloc()
   Product: Base System
   Version: CURRENT
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Some People
  Priority: ---
 Component: kern
  Assignee: b...@freebsd.org
  Reporter: r...@lcs.mit.edu

In the NFSATTRBIT_OWNERGROUP code in nfsv4_loadattr():

NFSM_DISSECT(tl, u_int32_t *, NFSX_UNSIGNED);
j = fxdr_unsigned(int, *tl);
if (j < 0) {
error =  NFSERR_BADXDR;
goto nfsmout;
}
attrsum += (NFSX_UNSIGNED + NFSM_RNDUP(j));
if (j > NFSV4_SMALLSTR){
cp = malloc(j + 1, M_NFSSTRING, M_WAITOK);

First, a big j can cause this code to allocate a few GB of memory,
enough to cause my modest test machine to run out.

Second, the "if (j < 0)" along with the "j + 1" means that if the RPC
message contains j = 0x7fff, malloc will be called with

  (size_t)(j+1) = (size_t)(0x8000) 

which is 0x8000 if size_t is unsigned and 64 bits. This
seems to cause malloc() to never return on my machine.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 254040] AMD 5950X hyperthreading strange performance swings

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254040

--- Comment #3 from Stefan Eßer  ---
Update after booting a kernel with SCHED_4BSD:

This really appears to be a SCHED_ULE issue, as expected. With SCHED_4BSD the
results are quite homogeneous for each run:

$ t # repeated runs ...
1048576000 bytes transferred in 6.720101 secs (156035746 bytes/sec)
s048576000 bytes transferred in 7.037620 secs (148995835 bytes/sec)
1048576000 bytes transferred in 7.031251 secs (149130790 bytes/sec)
1048576000 bytes transferred in 7.032412 secs (149106159 bytes/sec)
1048576000 bytes transferred in 7.202687 secs (145581229 bytes/sec)
1048576000 bytes transferred in 6.918272 secs (151566177 bytes/sec)
1048576000 bytes transferred in 6.391244 secs (164064463 bytes/sec)
1048576000 bytes transferred in 6.686209 secs (156826683 bytes/sec)
1048576000 bytes transferred in 6.668778 secs (157236600 bytes/sec)
1048576000 bytes transferred in 6.914906 secs (151639959 bytes/sec)
1048576000 bytes transferred in 6.835760 secs (153395678 bytes/sec)
1048576000 bytes transferred in 6.755348 secs (155221619 bytes/sec)

$ t 4
1048576000 bytes transferred in 7.574533 secs (138434415 bytes/sec)
1048576000 bytes transferred in 7.776473 secs (134839540 bytes/sec)
1048576000 bytes transferred in 7.839487 secs (133755689 bytes/sec)
1048576000 bytes transferred in 7.856730 secs (133462132 bytes/sec)
$ t 4
1048576000 bytes transferred in 7.481412 secs (140157499 bytes/sec)
1048576000 bytes transferred in 7.557077 secs (138754182 bytes/sec)
1048576000 bytes transferred in 7.676920 secs (136588110 bytes/sec)
1048576000 bytes transferred in 8.040430 secs (130412922 bytes/sec)
$ t 4
1048576000 bytes transferred in 7.484386 secs (140101810 bytes/sec)
1048576000 bytes transferred in 7.581198 secs (138312698 bytes/sec)
1048576000 bytes transferred in 7.710614 secs (135991248 bytes/sec)
1048576000 bytes transferred in 7.736921 secs (135528856 bytes/sec)

$ t 16
1048576000 bytes transferred in 9.879846 secs (106132833 bytes/sec)
1048576000 bytes transferred in 10.087562 secs (103947418 bytes/sec)
1048576000 bytes transferred in 10.232516 secs (102474894 bytes/sec)
1048576000 bytes transferred in 10.237664 secs (102423370 bytes/sec)
1048576000 bytes transferred in 10.320563 secs (101600658 bytes/sec)
1048576000 bytes transferred in 10.375758 secs (101060179 bytes/sec)
1048576000 bytes transferred in 10.443859 secs (100401199 bytes/sec)
1048576000 bytes transferred in 10.481844 secs (100037355 bytes/sec)
1048576000 bytes transferred in 10.494019 secs (99921294 bytes/sec)
1048576000 bytes transferred in 10.510178 secs (99767674 bytes/sec)
1048576000 bytes transferred in 10.559435 secs (99302286 bytes/sec)
1048576000 bytes transferred in 10.638978 secs (98559840 bytes/sec)
1048576000 bytes transferred in 10.678294 secs (98196963 bytes/sec)
1048576000 bytes transferred in 10.808183 secs (97016860 bytes/sec)
1048576000 bytes transferred in 11.084706 secs (94596647 bytes/sec)
1048576000 bytes transferred in 11.231343 secs (93361587 bytes/sec)

Seems that my BIOS settings were not optimal during the tests documented in
Comment 2. After loading "Optimal Default" settings and re-activation of the
energy efficiency options I do get the following sysctl output now:

$ sysctl dev.cpu.0
dev.cpu.0.temperature: 29,6C
dev.cpu.0.cx_method: C1/hlt C2/io
dev.cpu.0.cx_usage_counters: 180 70723
dev.cpu.0.cx_usage: 0.25% 99.74% last 9261us
dev.cpu.0.cx_lowest: C8
dev.cpu.0.cx_supported: C1/1/1 C2/2/18
dev.cpu.0.freq_levels: 3400/3740 2800/2800 2200/1980
dev.cpu.0.freq: 3400
dev.cpu.0.%parent: acpi0
dev.cpu.0.%pnpinfo: _HID=ACPI0007 _UID=0 _CID=none
dev.cpu.0.%location: handle=\_SB_.PLTF.C000
dev.cpu.0.%driver: cpu
dev.cpu.0.%desc: ACPI CPU

Anyway, after another reboot back to SCHED_ULE and repeating the tests with new
BIOS settings I see:

$ t 1 # multiple runs again ...
1048576000 bytes transferred in 7.640816 secs (137233502 bytes/sec)
1048576000 bytes transferred in 6.225996 secs (168418995 bytes/sec)
1048576000 bytes transferred in 4.852763 secs (216078118 bytes/sec)
1048576000 bytes transferred in 4.832574 secs (216980866 bytes/sec)
1048576000 bytes transferred in 4.819031 secs (217590617 bytes/sec)

$ t 4
1048576000 bytes transferred in 4.956440 secs (211558309 bytes/sec)
1048576000 bytes transferred in 7.634614 secs (137344998 bytes/sec)
1048576000 bytes transferred in 7.788965 secs (134623280 bytes/sec)
1048576000 bytes transferred in 7.819442 secs (134098574 bytes/sec)
$ t 4
1048576000 bytes transferred in 4.853663 secs (216038083 bytes/sec)
1048576000 bytes transferred in 4.857143 secs (215883287 bytes/sec)
1048576000 bytes transferred in 7.721846 secs (135793430 bytes/sec)
1048576000 bytes transferred in 7.792580 secs (134560821 bytes/sec)
$ t 4
1048576000 bytes transferred in 4.908570 secs (213621479 bytes/sec)
1048576000 bytes transferred in 7.742029 secs (135439433 bytes/sec)
1048576000 bytes transferred in 7.784341 secs (134703245 bytes/sec)
1048576000 bytes t

[Bug 248715] dhclient: prepend domain-name-servers in dhclient.conf 'replaces' dhcpd provided value

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248715

Dmitry Afanasiev  changed:

   What|Removed |Added

 Resolution|--- |Not A Bug
 Status|Open|Closed

--- Comment #4 from Dmitry Afanasiev  ---
Okey, use resolvconf.conf to prepend nameservers + resolv_conf_local_only="NO"
is a good solution.
Thanks You!

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 254040] AMD 5950X hyperthreading strange performance swings

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254040

Stefan Eßer  changed:

   What|Removed |Added

 CC||s...@freebsd.org

--- Comment #2 from Stefan Eßer  ---
Interesting result, which I could reproduce.
But I'd be very surprised if this was connected to bug 256594.

I have performed a few tests on -CURRENT, with different numbers of processes
running in parallel:

$ t () { 
for i in $(jot ${1:-1});
do
dd if=/dev/zero bs=1M count=1000 | bzip2 - | wc > /dev/null &
done 2>&1 | grep transferred;
wait
}

$ t 4
1048576000 bytes transferred in 5.601800 secs (18718 bytes/sec)
1048576000 bytes transferred in 5.649712 secs (185598117 bytes/sec)
1048576000 bytes transferred in 5.695707 secs (184099356 bytes/sec)
1048576000 bytes transferred in 9.145955 secs (114649153 bytes/sec)
$ t 4
1048576000 bytes transferred in 5.615530 secs (186727884 bytes/sec)
1048576000 bytes transferred in 6.000599 secs (174745209 bytes/sec)
1048576000 bytes transferred in 8.281161 secs (126621862 bytes/sec)
1048576000 bytes transferred in 8.982560 secs (116734646 bytes/sec)
$ t 4
1048576000 bytes transferred in 5.597056 secs (187344204 bytes/sec)
1048576000 bytes transferred in 8.940248 secs (117287131 bytes/sec)
1048576000 bytes transferred in 8.962013 secs (117002282 bytes/sec)
1048576000 bytes transferred in 8.975112 secs (116831521 bytes/sec)

There are only two typical throughput value ranges: 175 to 188 MB/s and 115 to
125 MB/s (in powers of 10, not 2). This is roughly a factor of 3/2 ...

$ t 16
1048576000 bytes transferred in 7.537053 secs (139122806 bytes/sec)
1048576000 bytes transferred in 7.643938 secs (137177468 bytes/sec)
1048576000 bytes transferred in 7.658221 secs (136921619 bytes/sec)
1048576000 bytes transferred in 7.676633 secs (136593217 bytes/sec)
1048576000 bytes transferred in 7.684927 secs (136445807 bytes/sec)
1048576000 bytes transferred in 7.692365 secs (136313868 bytes/sec)
1048576000 bytes transferred in 7.785566 secs (134682056 bytes/sec)
1048576000 bytes transferred in 7.869853 secs (133239594 bytes/sec)
1048576000 bytes transferred in 7.887814 secs (132936190 bytes/sec)
1048576000 bytes transferred in 7.902913 secs (132682214 bytes/sec)
1048576000 bytes transferred in 7.901557 secs (132704990 bytes/sec)
1048576000 bytes transferred in 7.918014 secs (132429169 bytes/sec)
1048576000 bytes transferred in 7.964384 secs (131658150 bytes/sec)
1048576000 bytes transferred in 7.973078 secs (131514575 bytes/sec)
1048576000 bytes transferred in 7.992037 secs (131202601 bytes/sec)
1048576000 bytes transferred in 8.074766 secs (129858370 bytes/sec)

Now all results are between 130 and 140 MB/s. And this outcome is stable over
multiple runs.

$ t 32
1048576000 bytes transferred in 11.279196 secs (92965495 bytes/sec)
1048576000 bytes transferred in 11.343222 secs (92440755 bytes/sec)
1048576000 bytes transferred in 11.345478 secs (92422376 bytes/sec)
1048576000 bytes transferred in 11.422671 secs (91797797 bytes/sec)
1048576000 bytes transferred in 11.522082 secs (91005777 bytes/sec)
1048576000 bytes transferred in 11.757213 secs (89185763 bytes/sec)
1048576000 bytes transferred in 11.796787 secs (6578 bytes/sec)
1048576000 bytes transferred in 11.787529 secs (88956389 bytes/sec)
1048576000 bytes transferred in 11.830471 secs (88633499 bytes/sec)
1048576000 bytes transferred in 11.866944 secs (88361080 bytes/sec)
1048576000 bytes transferred in 11.901904 secs (88101537 bytes/sec)
1048576000 bytes transferred in 11.956605 secs (87698475 bytes/sec)
1048576000 bytes transferred in 11.952918 secs (87725524 bytes/sec)
1048576000 bytes transferred in 11.955508 secs (87706519 bytes/sec)
1048576000 bytes transferred in 11.961946 secs (87659316 bytes/sec)
1048576000 bytes transferred in 11.992837 secs (87433521 bytes/sec)
1048576000 bytes transferred in 12.017736 secs (87252376 bytes/sec)
1048576000 bytes transferred in 12.023212 secs (87212632 bytes/sec)
1048576000 bytes transferred in 12.014854 secs (87273302 bytes/sec)
1048576000 bytes transferred in 12.054915 secs (86983277 bytes/sec)
1048576000 bytes transferred in 12.149618 secs (86305266 bytes/sec)
1048576000 bytes transferred in 12.179530 secs (86093302 bytes/sec)
1048576000 bytes transferred in 12.260039 secs (85527952 bytes/sec)
1048576000 bytes transferred in 12.261602 secs (85517046 bytes/sec)
1048576000 bytes transferred in 12.260685 secs (85523445 bytes/sec)
1048576000 bytes transferred in 12.386748 secs (84653048 bytes/sec)
1048576000 bytes transferred in 12.415505 secs (84456972 bytes/sec)
1048576000 bytes transferred in 12.487385 secs (83970822 bytes/sec)
1048576000 bytes transferred in 12.527210 secs (83703871 bytes/sec)
1048576000 bytes transferred in 12.602776 secs (83201986 bytes/sec)
1048576000 bytes transferred in 12.618314 secs (83099532 bytes/sec)
1048576000 bytes tra

[Bug 260539] inp_next() NULL inp dereference?

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260539

Bug ID: 260539
   Summary: inp_next() NULL inp dereference?
   Product: Base System
   Version: CURRENT
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Some People
  Priority: ---
 Component: kern
  Assignee: b...@freebsd.org
  Reporter: r...@lcs.mit.edu

In inp_next(), in this for-loop:

if (ii->inp == NULL) {  /* First call. */
smr_enter(ipi->ipi_smr);
/* This is unrolled CK_LIST_FOREACH(). */
for (inp = II_LIST_FIRST(ipi, hash);
inp != NULL;
inp = II_LIST_NEXT(inp, hash)) {
if (match != NULL && (match)(inp, ctx) == false)
continue;
if (__predict_true(inp_smr_lock(inp, lock)))
break;
else {
smr_enter(ipi->ipi_smr);
MPASS(inp != II_LIST_FIRST(ipi, hash));
inp = II_LIST_FIRST(ipi, hash);
}
}

I wonder if the last "inp = II_LIST_FIRST(ipi, hash)" ought to be
followed by "if(inp == NULL) break", since it will be immediately
followed by the for-loop's II_LIST_NEXT().

I bring this up because I've seen a kernel page fault in the
for-loop's II_LIST_NEXT due to a NULL inp. However, I cannot reproduce
it. It occured at a time when the kernel was killing processes due to
low memory.

FreeBSD  14.0-CURRENT FreeBSD 14.0-CURRENT #165
main-n250912-e4746deeda02-dirty: Sat Dec 18 05:12:30 EST 2021
rtm@xxx:/usr/obj/usr/rtm/symbsd/src/riscv.riscv64/sys/RTM  riscv

panic: Fatal page fault at 0xffc0003a6750: 0x0001b8
--- exception 13, tval = 0x1b8
ck_pr_md_load_ptr() at ck_pr_md_load_ptr+0x14
inp_next() at inp_next+0x206
tcp_drain() at tcp_drain+0xcc
mb_reclaim() at mb_reclaim+0x78
vm_pageout_lowmem() at vm_pageout_lowmem+0xf8
vm_pageout_worker() at vm_pageout_worker+0x1ba
vm_pageout() at vm_pageout+0x1ce
fork_exit() at fork_exit+0x80
fork_trampoline() at fork_trampoline+0xa

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 254040] AMD 5950X hyperthreading strange performance swings

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254040

--- Comment #1 from Andriy Gapon  ---
Do you think that this is the same issue as bug 256594?
Also, did you try disabling PBO (Precision Boost Overdrive) as opposed to CPB?

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 256594] AMD Ryzen CPU stutter (responsiveness lag)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256594

--- Comment #4 from Andriy Gapon  ---
On my setup, also with a Zen 3 CPU,  machdep.idle=mwait seems to improve the
situation.

-- 
You are receiving this mail because:
You are the assignee for the bug.