This diff based on changes from https://reviews.freebsd.org/D30840 for file: sbin/devd/devd.conf.5

Add var old_name to keep if_xname.

Move code down, update date.

Add "#if defined(INET) || defined(INET6)" for vars.

Update sbin/devd/devd.conf.5

Update sbin/devd/devd.conf.5

In D30175#693715, @donner wrote:

May I ask you to provide a full context diff, please?
It's much easier to review.

Done in https://reviews.freebsd.org/D25969

Yes, please use Mk.
It will be useful for https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252070 and https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252088

If all ccache deps does not inherit NO_CCACHE_DEPEND then you may get infinite recursion, because some of dep may require ccache.
I already try bootstrap without this and get: ccache->cmake->ccache->cmake.....

IMHO,
.MAKEFLAGS: NO_CCACHE_DEPEND=yes
may stop work if some port define NOPRECIOUSMAKEVARS.

This is only mixer unplug fix.

This change should fix infinite recursion: https://github.com/rozhuk-im/freebsd-ports/commit/dfe7746fb71eb1df89474f527499a1f5a768f01c

Do you try build ccache without installed ccache, cmake but with WITH_CCACHE_BUILD ?

In file included from /usr/src/contrib/elftoolchain/addr2line/addr2line.c:30:
/usr/include/capsicum_helpers.h:42:10: fatal error: 'libcasper.h' file not found
#include <libcasper.h>

^~~~~~~~~~~~~

1 error generated.

• addr2line.o ---
• [addr2line.o] Error code 1

kernel trap 22 with interrupts disabled
panic: spin locks can only use msleep_spin
cpuid = 7 time = 1569790352
KDB: stack backtrace:
#0 0xffffffff805da3fd at kdb_backtrace+0x6d
#1 0xffffffff80594fed at vpanic+0x19d
#2 0xffffffff80594e43 at panic+0x43
#3 0xffffffff8057df32 at unlock_spin+0x12
#4 0xffffffff8053f577 at _cv_wait_sig+0x127
#5 0xffffffff81d1dace at iichid_read+0x8e
#6 0xffffffff804b690a at devfs_read_f+0xda
#7 0xffffffff805f4752 at kern_readv+0x92
#8 0xffffffff805f46b4 at sys_read+0x84
#9 0xffffffff808451d8 at amd64_syscall+0x218
#10 0xffffffff80821270 at fast_syscall_common+0x101

Panic on kldload acpi_iichid in iichid_read()->cv_wait_sig().
FreeBSD 12.1 amd64 @ Asus 505z

This is alternate to kqueue EVFILT_FS, but there is no need to keep prev state from getmntinfo() and compare with new to find changes.
Also user can use shell scripts to perform additional actions.

I merge it to stable.
Sorry for noise, problem was with random - not enough entropy on first boot to unblock it. It reproduced even on 11.2 from official site.

Not sure that this works.
I try this on 11.2 and on Hyper-V gen1 system stick at ldelf loading stage on boot from zfs root.

More proper temp calculatuion based on RangeUnajusted, according to "Preliminary BIOS and Kernel Developer’s Guide (BKDG) for AMD Family 16h Models 00h-0Fh (Kabini) Processors".

In D14721#362454, @iwtcex_gmail.com wrote:

That's better. However, I still prefer lib32- approach. Mostly because it doesn't waste my time deploying chroot and compiling the same Wine components multiple times. (I also wouldn't mind 32-bit version of mesa-demos package, that would be very handy when I'm trying to diagnose 3d issues for other users on the FreeBSD forum or elsewhere. And that requires establishing some kind of packaging convention unless we want to stuff every potentially useful binary into wine-devel.)

In D14721#362413, @iwtcex_gmail.com wrote:

@rozhuk.im-gmail.com You know the chroot approach is basically unmergable, right?

http://www.netlab.linkpc.net/download/tmp/wine-devel_wow.patch
I update patch:

• now it for 3.15
• use ccache to build
• nullfs mount as ro for all things that do not required write
• add copy of /etc/resolv.conf to chroot
• add copy of /etc/make.conf to chroot
• fix staging download if wow enabled

1. unmount does not work on errors - and I lost mine: /usr/ports, /var/db/ports, distfiles. DOH!

Sorry for annoying, but may be better:

1. rename it to amdsb
2. add SMU
3. add amdsmn_is_avail(), amdsmu_is_avail()
4. may be some staff from amdsbwd
5. may be whole amd_ecc_inject

In D12217#253766, @avg wrote:

@rozhuk.im-gmail.com
SMN can and will be used for far more things than just the temperature reading. A lot of registers has been moved behind SMN. Having SMN interface in a separate module is just a good software design.
Your arguments so far sound irrational.

Regarding your note on the Linux change -- yes, they added SMN to the existing driver, but that's because they already had a driver to provide structured access to various things in the AMD "northbridge" and that's because Linux tinkers with hardware insides far more than FreeBSD does.
This change is the step in the same direction, not away from it.
E.g. I wish I was smart enough to create AMD "southbridge" driver at the time when I was writing amdsbwd driver. Without that driver the dependencies between amdsbwd, intpm and the proposed apuled drivers are much poorer than they would be with it.

In D12217#253706, @mjoras wrote:

In D12217#253705, @rozhuk.im-gmail.com wrote:

Now, no one needs an amdsmn.
If some module in future will use SMN then it will be easy to share this code into module.

That's true, but what's so offensive about having another module? Why do we need to wait for abundant reasons to have logical code separation as opposed to copy paste code sharing?

In D12217#253696, @cem wrote:

In D12217#253695, @rozhuk.im-gmail.com wrote:

That is all what module do. Same for write.
8 lines.
One consumer - amdtemp.
No perspective to get more consumers.
Unknown perspective to be supported in hardware in future.

So what?

My point is: while only amdtemp uses amdsmn on few CPUs - no need to have amdsmn as module, let it be a part of amdtemp.

Why is that better? What is bad about the separate module?

In D12217#253620, @avg wrote:

Why do you think that there is any direct relation between SMU and Miscellaneous registers in family 15h and SMN in family 17h?
SMN is a completely new thing in family 17h (or so it seems), the only similarity between SMU and SMN is "SM" :-)
Family 17h is a big step from families 10h - 16h and even between those families there were incompatible changes in PCI register definitions (I know that for sure about registers that describe DRAM configuration).

Given the lack of documentation we can resort -- again! -- to using Linux commits by AMD employees as a guidance.
For example, https://patchwork.kernel.org/patch/9432511/

In D12217#253586, @truckman wrote:

In D12217#253500, @rozhuk.im-gmail.com wrote:

family = CPUID_TO_FAMILY(cpu_id);

What about systems with multiple and different CPUs?
That is why amdtemp reads:

cpuid = pci_read_config(dev, AMDTEMP_CPUID, 4);

That register does not appear to exist on Ryzen. It is not mentioned in the Processor Programming Reference (PPR) for AMD Family 17 Model 01h, Revision B1 Processors. When I previously tested your patch, I searched all of config space and didn't find any registers with contents that matched what what I expect to see there.

I don't believe that populating a multi-socket system with non-identical CPU chips is supported.

In D12217#253572, @cem wrote:

In D12217#253500, @rozhuk.im-gmail.com wrote:

For 15h model 60-6f
D0F0x60 Miscellaneous Index
D0F0x64 Miscellaneous Index Data
...
D0F0xB8 SMU Index Address
D0F0xBC SMU Index Data

Is amdsmn required as additional device?

I don't understand the question.

add Ryzen specific SMU registers.

This is potentially possible in server segment.
I this this is reason why amdtemp read CPUID via PCI and try to not use global cpu_id and local do_cpuid().
Linux gays in k10temp.c: k10temp_is_visible() uses only info that read from target device.

For 15h model 60-6f
D0F0x60 Miscellaneous Index
D0F0x64 Miscellaneous Index Data
...
D0F0xB8 SMU Index Address
D0F0xBC SMU Index Data

Add support Bristol Ridge, possible Ryzen - need check
Remove TSI reading methods

Is it have same effect:

Thank you.

No.
How I can check mem use after free and how turn on mem debug?

I m waiting for documentation from AMD to Ryzen CPU, looks like 17h have new interfaces.

In D9759#204651, @cy wrote:

Will there be man page updates?

Since revision 310051 sysctl_add_oid have +1 param, add macro to handle it.

I have some AMD: E350, 5350, APU 6800, Phenom II X4 955 - test OK.

Style update.
CTASSERT() removed.

I will fix style a bi later.

Style corrections.