Re: Which AMD CPUs are supported -- temperature
On 2020-Feb-12 15:23:51 -0500, mike tancsa wrote: >Not sure about the older Athlon CPUs, but the 2 generations of Ryzen's I >have seem correct as well as an APU > >CPU: AMD GX-412TC SOC (998.17-MHz K8-class CPU) OTOH, I'm not confident about temperatures on my APU. The publicly available data just says that the SoC reports "a temperature on its own scale" relative to a Tctl_max which "is specified in the power and thermal data sheet" (that I have been unable to locate). Everyone seems to assume that the step size is 0.125K but I haven't found that publicly documented anywhere. The AMD Product Brief states that the maximum temperature is 90°C but using that as Tctl_max gives me temperature readings that don't look right. >And on a fanless APU > ># sysctl -a dev.cpu.0.temperature >dev.cpu.0.temperature: 62.6C > ># sysctl -a dev.amdtemp.0.core0.sensor0 >dev.amdtemp.0.core0.sensor0: 63.1C At what ambient temperature? I see a similar value from my (idle) APU3 but don't believe the (implied) ~35K junction-to-ambient difference. -- Peter Jeremy signature.asc Description: PGP signature
Re: Buildworld dying wint lldb?
Steve Kargl wrote: Anyone else see ===> usr.bin/clang/lldb (all) c++ -target x86_64-unknown-freebsd13.0 --sysroot=/usr/obj/usr/src/amd64.amd64/tmp -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin -O2 -pipe -I/usr/src/contrib/llvm-project/lldb/include -I/usr/obj/usr/src/amd64.amd64/usr.bin/clang/lldb -march=bdver2 -I/usr/src/contrib/llvm-project/clang/include -DCLANG_ENABLE_ARCMT -DCLANG_ENABLE_STATIC_ANALYZER -I/usr/src/lib/clang/include -I/usr/src/contrib/llvm-project/llvm/include -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -DHAVE_VCS_VERSION_INC -DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd13.0\" -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd13.0\" -DDEFAULT_SYSROOT=\"\" -DLLVM_TARGET_ENABLE_AARCH64 -DLLVM_TARGET_ENABLE_ARM -DLLVM_TARGET_ENABLE_MIPS -DLLVM_TARGET_ENABLE_POWERPC -DLLVM_TARGET_ENABLE_RISCV -DLLVM_TARGET_ENABLE_SPARC -DLLVM_TARGET_ENABLE_X86 -DLLVM_NATIVE_ASMPARSER=LLVMInitializeX86AsmParser -DLLVM_NATIVE_ASMPRINTER=LLVMInitializeX86AsmPrinter -DLLVM_NATIVE_DISASSEMBLER=LLVMInitializeX86Disassembler -DLLVM_ NATIVE_TARGET=LLVMInitializeX86Target -DLLVM_NATIVE_TARGETINFO=LLVMInitializeX86TargetInfo -DLLVM_NATIVE_TARGETMC=LLVMInitializeX86TargetMC -ffunction-sections -fdata-sections -gline-tables-only -Wno-format-zero-length -fstack-protector-strong -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-address-of-packed-member -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Qunused-arguments -fno-exceptions -fno-rtti -std=c++11 -stdlib=libc++ -Wno-c++11-extensions -Wl,--gc-sections -o lldb.full Driver.o /usr/obj/usr/src/amd64.amd64/lib/clang/liblldb/liblldb.a /usr/obj/usr/src/amd64.amd64/lib/clang/libclang/libclang.a /usr/obj/usr/src/amd64.amd64/lib/clang/libllvm/libllvm.a -ledit -lexecinfo -lpanel -lncursesw -lz -lpthread ld: error: undefined symbol: lldb_private::ClangModulesDeclVendor::Create(lldb_private::Target&) referenced by Target.cpp:2487 (/usr/src/contrib/llvm-project/lldb/source/Target/Target.cpp:2487) This is 'make buildworld' with an empty //usr/obj. My /etc/sr.conf has WITHOUT_TESTS="yes" WITH_LLDB="yes" Looking at src.conf(5), this is already default setting for amd64. And given that it's default, no, I'm not seeing this doing buildworld with recent checkouts. WITH_BSD_GREP="YES" WITH_LLVM_TARGET_AARCH64="NO" WITH_LLVM_TARGET_ARM="NO" WITH_LLVM_TARGET_MIPS="NO" WITH_LLVM_TARGET_POWERPC="NO" WITH_LLVM_TARGET_SPARC="NO" WITH_LLVM_TARGET_X86="YES" These settings don't do what you likely expect them to do as src.conf(5) explicitly states (and confirmed by your build log excerpt above): The values of variables are ignored regardless of their setting; even if they would be set to “FALSE” or “NO”. So you'd want the WITHOUT ones. ___ 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: Which AMD CPUs are supported -- temperature
On Thu, 13 Feb 2020 07:00:36 +0100 Andrea Venturoli m...@netfence.it said On 2020-02-12 23:17, Chris wrote: > # dmidecode -t4 | grep AMD > Manufacturer: AMD > Version: AMD Athlon(tm) II X4 630 Processor > # sysctl -a | grep tempe > dev.cpu.3.temperature: 33.5C > dev.cpu.2.temperature: 33.5C > dev.cpu.1.temperature: 33.5C > dev.cpu.0.temperature: 33.5C Also works here: > cat /var/run/dmesg.boot > ... > CPU: AMD Phenom(tm) II X4 965 Processor (3415.38-MHz K8-class CPU) > sysctl -a|grep temp > dev.cpu.3.temperature: 43.6C > dev.cpu.2.temperature: 43.6C > dev.cpu.1.temperature: 43.6C > dev.cpu.0.temperature: 43.6C > > # # # BROKEN > # dmidecode -t4 | grep AMD > Manufacturer: AuthenticAMD > Version: AMD Athlon(tm) X4 860K Quad Core Processor > # sysctl -a | grep tempe > dev.cpu.3.temperature: 13.1C > dev.cpu.2.temperature: 13.1C > dev.cpu.1.temperature: 13.1C > dev.cpu.0.temperature: 13.1C > > All but one is in the same class. But one in that same > class doesn't work. The FX class also works fine. > I'm puzzled... :( Thanks for the reply! This reminds me of my first Ryzen 2: 11.3 would not get the temperature right, but 12.1 did. If I understand correctly, AMD just gives a temperature reading in the same way on all CPUs, but different models require different adjustment to that value (with some offset and/or other calculations); see /usr/src/sys/dev/amdtemp/amdtemp.c. Heh, since I first discovered that I wasn't getting correct output, I went straight to svn.freebsd.org/head and started walking the revisions on amdtemp.c -- even many proposals -- https://reviews.freebsd.org/D9759 for example. But I've grown weary of building world && kernels in hopes of finding just the right revision. :P Perhaps this CPU needs a formula which FreeBSD's driver does not have? Of course this is a wild guess, as I have not access to the specs. This is what I gathered from reading the source && comments. I read one where "linux" suggests it starts at -28C. So if I add +28 to my current output, that puts it about where I would expect it to be. But like you say; it's all guesswork without the specs. The CPU in question returns the following in dmesg(8), in case anyone cares: AMD Athlon(tm) X4 860K Quad Core Processor (3700.07-MHz K8-class CPU) Origin="AuthenticAMD" Id=0x630f01 Family=0x15 Model=0x30 Stepping=1 Features=0x178bfbff Features2=0x3e98320b AMD Features=0x2e500800 AMD Features2=0xfebbfff,DBE,PTSC> Structured Extended Features=0x9 XSAVE Features=0x1 SVM: Features=0x1cff,PauseFilterThreshold> Revision=1, ASIDs=65536 Thanks again! --Chris bye av. ___ 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: Which AMD CPUs are supported -- temperature
On 2020-02-12 23:17, Chris wrote: # dmidecode -t4 | grep AMD Manufacturer: AMD Version: AMD Athlon(tm) II X4 630 Processor # sysctl -a | grep tempe dev.cpu.3.temperature: 33.5C dev.cpu.2.temperature: 33.5C dev.cpu.1.temperature: 33.5C dev.cpu.0.temperature: 33.5C Also works here: > cat /var/run/dmesg.boot > ... > CPU: AMD Phenom(tm) II X4 965 Processor (3415.38-MHz K8-class CPU) > sysctl -a|grep temp > dev.cpu.3.temperature: 43.6C > dev.cpu.2.temperature: 43.6C > dev.cpu.1.temperature: 43.6C > dev.cpu.0.temperature: 43.6C # # # BROKEN # dmidecode -t4 | grep AMD Manufacturer: AuthenticAMD Version: AMD Athlon(tm) X4 860K Quad Core Processor # sysctl -a | grep tempe dev.cpu.3.temperature: 13.1C dev.cpu.2.temperature: 13.1C dev.cpu.1.temperature: 13.1C dev.cpu.0.temperature: 13.1C All but one is in the same class. But one in that same class doesn't work. The FX class also works fine. I'm puzzled... :( This reminds me of my first Ryzen 2: 11.3 would not get the temperature right, but 12.1 did. If I understand correctly, AMD just gives a temperature reading in the same way on all CPUs, but different models require different adjustment to that value (with some offset and/or other calculations); see /usr/src/sys/dev/amdtemp/amdtemp.c. Perhaps this CPU needs a formula which FreeBSD's driver does not have? Of course this is a wild guess, as I have not access to the specs. bye av. ___ 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"
Buildworld dying wint lldb?
Anyone else see ===> usr.bin/clang/lldb (all) c++ -target x86_64-unknown-freebsd13.0 --sysroot=/usr/obj/usr/src/amd64.amd64/tmp -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin -O2 -pipe -I/usr/src/contrib/llvm-project/lldb/include -I/usr/obj/usr/src/amd64.amd64/usr.bin/clang/lldb -march=bdver2 -I/usr/src/contrib/llvm-project/clang/include -DCLANG_ENABLE_ARCMT -DCLANG_ENABLE_STATIC_ANALYZER -I/usr/src/lib/clang/include -I/usr/src/contrib/llvm-project/llvm/include -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -DHAVE_VCS_VERSION_INC -DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd13.0\" -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd13.0\" -DDEFAULT_SYSROOT=\"\" -DLLVM_TARGET_ENABLE_AARCH64 -DLLVM_TARGET_ENABLE_ARM -DLLVM_TARGET_ENABLE_MIPS -DLLVM_TARGET_ENABLE_POWERPC -DLLVM_TARGET_ENABLE_RISCV -DLLVM_TARGET_ENABLE_SPARC -DLLVM_TARGET_ENABLE_X86 -DLLVM_NATIVE_ASMPARSER=LLVMInitializeX86AsmParser -DLLVM_NATIVE_ASMPRINTER=LLVMInitializeX86AsmPrinter -DLLVM_NATIVE_DISASSEMBLER=LLVMInitializeX86Disassembler -DLLVM_ NATIVE_TARGET=LLVMInitializeX86Target -DLLVM_NATIVE_TARGETINFO=LLVMInitializeX86TargetInfo -DLLVM_NATIVE_TARGETMC=LLVMInitializeX86TargetMC -ffunction-sections -fdata-sections -gline-tables-only -Wno-format-zero-length -fstack-protector-strong -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-address-of-packed-member -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Qunused-arguments -fno-exceptions -fno-rtti -std=c++11 -stdlib=libc++ -Wno-c++11-extensions -Wl,--gc-sections -o lldb.full Driver.o /usr/obj/usr/src/amd64.amd64/lib/clang/liblldb/liblldb.a /usr/obj/usr/src/amd64.amd64/lib/clang/libclang/libclang.a /usr/obj/usr/src/amd64.amd64/lib/clang/libllvm/libllvm.a -ledit -lexecinfo -lpanel -lncursesw -lz -lpthread ld: error: undefined symbol: lldb_private::ClangModulesDeclVendor::Create(lldb_private::Target&) >>> referenced by Target.cpp:2487 >>> (/usr/src/contrib/llvm-project/lldb/source/Target/Target.cpp:2487) This is 'make buildworld' with an empty //usr/obj. My /etc/sr.conf has WITHOUT_TESTS="yes" WITH_LLDB="yes" WITH_BSD_GREP="YES" WITH_LLVM_TARGET_AARCH64="NO" WITH_LLVM_TARGET_ARM="NO" WITH_LLVM_TARGET_MIPS="NO" WITH_LLVM_TARGET_POWERPC="NO" WITH_LLVM_TARGET_SPARC="NO" WITH_LLVM_TARGET_X86="YES" -- Steve ___ 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: Which AMD CPUs are supported -- temperature
On Wed, 12 Feb 2020 15:23:51 -0500 mike tancsa m...@sentex.net said On 2/12/2020 1:39 PM, Chris wrote: > Hard as I try I can not get anything close to the actual temperature > of the CPUs or cores while running on FreeBSD. > Family: Athlon X4 > Manufacturer: AuthenticAMD > Not sure about the older Athlon CPUs, but the 2 generations of Ryzen's I have seem correct as well as an APU CPU: AMD GX-412TC SOC (998.17-MHz K8-class CPU) CPU: AMD Ryzen 7 3700X 8-Core Processor (3593.33-MHz K8-class CPU) CPU: AMD Ryzen 7 2700X Eight-Core Processor (3693.17-MHz Thanks for the reply, Mike. I don't know about Old v New. But where's the results from 5 AMD CPUs I have immediately at my disposal, and their reported results. 4 out of 5 work: # grep -F Ath /var/run/dmesg.boot CPU: AMD Athlon(tm) II X3 440 Processor (3013.96-MHz K8-class CPU) # sysctl -a | grep tempe dev.cpu.2.temperature: 31.5C dev.cpu.1.temperature: 31.5C dev.cpu.0.temperature: 31.5C # dmidecode -t4 | grep AMD Manufacturer: AMD Version: AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ # sysctl -a | grep tempe hw.acpi.thermal.tz0.temperature: 32.1C dev.cpu.1.temperature: 45.0C dev.cpu.0.temperature: 48.0C # dmidecode -t4 | grep AMD Manufacturer: AMD Version: AMD FX(tm)-6300 Six-Core Processor # sysctl -a | grep tempe dev.cpu.5.temperature: 30.1C dev.cpu.4.temperature: 30.1C dev.cpu.3.temperature: 30.1C dev.cpu.2.temperature: 30.1C dev.cpu.1.temperature: 30.1C dev.cpu.0.temperature: 30.1C # dmidecode -t4 | grep AMD Manufacturer: AMD Version: AMD Athlon(tm) II X4 630 Processor # sysctl -a | grep tempe dev.cpu.3.temperature: 33.5C dev.cpu.2.temperature: 33.5C dev.cpu.1.temperature: 33.5C dev.cpu.0.temperature: 33.5C # # # BROKEN # dmidecode -t4 | grep AMD Manufacturer: AuthenticAMD Version: AMD Athlon(tm) X4 860K Quad Core Processor # sysctl -a | grep tempe dev.cpu.3.temperature: 13.1C dev.cpu.2.temperature: 13.1C dev.cpu.1.temperature: 13.1C dev.cpu.0.temperature: 13.1C All but one is in the same class. But one in that same class doesn't work. The FX class also works fine. I'm puzzled... :( Thanks again! --Chris K8-class CPU) e.g. at idle # sysctl -a dev.cpu.0.temperature dev.cpu.0.temperature: 31.1C then start up # cat /dev/urandom | openssl sha256 # sysctl -a dev.cpu.0.temperature dev.cpu.0.temperature: 57.1C It agrees with what IPMI reports too from the MB # ipmitool sensor | grep "CPU Temp" CPU Temp | 31.000 | degrees C | ok | na | na | na | 93.000 | 94.000 | na And on a fanless APU # sysctl -a dev.cpu.0.temperature dev.cpu.0.temperature: 62.6C # sysctl -a dev.amdtemp.0.core0.sensor0 dev.amdtemp.0.core0.sensor0: 63.1C ---Mike ___ 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: Which AMD CPUs are supported -- temperature
On 2020-02-12 15:23, mike tancsa wrote: sysctl -a dev.cpu.0.temperature Those sort of things seem to just "not work"(tm) on older type of processors : vesta# vesta# vesta# uname -apKU FreeBSD vesta 12.1-RELEASE-p2 FreeBSD 12.1-RELEASE-p2 GENERIC amd64 amd64 1201000 1201000 vesta# sysctl -a | grep 'cpu' kern.smp.cpus: 6 kern.smp.maxcpus: 256 kern.ccpu: 0 0, 1, 2, 3, 4, 5 0, 1 0 1 2, 3 2 3 4, 5 4 5 kern.sched.cpusetsize: 32 kern.pin_pcpu_swi: 0 kern.racct.pcpu_threshold: 1 cpu HAMMER device cpufreq kern.vt.splash_cpu_duration: 10 kern.vt.splash_cpu_style: 2 kern.vt.splash_ncpu: 0 kern.vt.splash_cpu: 0 vfs.ncpurgeminvnodes: 512 net.inet.tcp.per_cpu_timers: 0 debug.cpufreq.verbose: 0 debug.cpufreq.lowest: 0 debug.acpi.cpu_unordered: 0 hw.ncpu: 6 hw.acpi.cpu.cx_lowest: C1 hw.intrs: irq0: attimer0:3 @cpu0(domain0): 0 irq1: atkbd0:1 @cpu0(domain0): 0 irq3::5 @cpu0(domain0): 0 irq4::7 @cpu0(domain0): 0 irq5::9 @cpu0(domain0): 0 irq6::11 @cpu0(domain0): 0 irq7::13 @cpu0(domain0): 0 irq8: atrtc0:15 @cpu0(domain0): 0 irq9: acpi0:17 @cpu0(domain0): 0 irq10::19 @cpu0(domain0): 0 irq11::21 @cpu0(domain0): 0 irq12::23 @cpu0(domain0): 0 irq13::25 @cpu0(domain0): 0 irq14::27 @cpu0(domain0): 0 irq15::29 @cpu0(domain0): 0 irq16: hdac1:31 @cpu0(domain0): 37 irq17: ehci0 ehci1+:33 @cpu0(domain0): 2 irq18: ohci0 ohci1*:35 @cpu0(domain0): 22 irq19: ahci0:37 @cpu0(domain0): 4704900 irq20::39 @cpu0(domain0): 0 irq21::41 @cpu0(domain0): 0 irq22::43 @cpu0(domain0): 0 irq23::45 @cpu0(domain0): 0 irq256: hpet0:t0:53 @cpu0(domain0): 0 irq257: hpet0:t1:55 @cpu0(domain0): 0 irq258: hpet0:t2:57 @cpu0(domain0): 0 irq259: hdac0:59 @cpu0(domain0): 3 irq260: xhci0:61 @cpu0(domain0): 0 irq261: re0:63 @cpu0(domain0): 2908189 dev.cpufreq.0.%parent: cpu0 dev.cpufreq.0.%pnpinfo: dev.cpufreq.0.%location: dev.cpufreq.0.%driver: cpufreq dev.cpufreq.0.%desc: dev.cpufreq.%parent: dev.hwpstate.0.%parent: cpu0 dev.acpi_perf.5.%parent: cpu5 dev.acpi_perf.4.%parent: cpu4 dev.acpi_perf.3.%parent: cpu3 dev.acpi_perf.2.%parent: cpu2 dev.acpi_perf.1.%parent: cpu1 dev.acpi_perf.0.%parent: cpu0 dev.cpu.5.cx_method: C1/hlt C2/io dev.cpu.5.cx_usage_counters: 12254878 0 dev.cpu.5.cx_usage: 100.00% 0.00% last 120487us dev.cpu.5.cx_lowest: C1 dev.cpu.5.cx_supported: C1/1/0 C2/2/100 dev.cpu.5.%parent: acpi0 dev.cpu.5.%pnpinfo: _HID=none _UID=0 dev.cpu.5.%location: handle=\_PR_.P006 dev.cpu.5.%driver: cpu dev.cpu.5.%desc: ACPI CPU dev.cpu.4.cx_method: C1/hlt C2/io dev.cpu.4.cx_usage_counters: 12019819 0 dev.cpu.4.cx_usage: 100.00% 0.00% last 2984us dev.cpu.4.cx_lowest: C1 dev.cpu.4.cx_supported: C1/1/0 C2/2/100 dev.cpu.4.%parent: acpi0 dev.cpu.4.%pnpinfo: _HID=none _UID=0 dev.cpu.4.%location: handle=\_PR_.P005 dev.cpu.4.%driver: cpu dev.cpu.4.%desc: ACPI CPU dev.cpu.3.cx_method: C1/hlt C2/io dev.cpu.3.cx_usage_counters: 12269169 0 dev.cpu.3.cx_usage: 100.00% 0.00% last 33499us dev.cpu.3.cx_lowest: C1 dev.cpu.3.cx_supported: C1/1/0 C2/2/100 dev.cpu.3.%parent: acpi0 dev.cpu.3.%pnpinfo: _HID=none _UID=0 dev.cpu.3.%location: handle=\_PR_.P004 dev.cpu.3.%driver: cpu dev.cpu.3.%desc: ACPI CPU dev.cpu.2.cx_method: C1/hlt C2/io dev.cpu.2.cx_usage_counters: 12058705 0 dev.cpu.2.cx_usage: 100.00% 0.00% last 8us dev.cpu.2.cx_lowest: C1 dev.cpu.2.cx_supported: C1/1/0 C2/2/100 dev.cpu.2.%parent: acpi0 dev.cpu.2.%pnpinfo: _HID=none _UID=0 dev.cpu.2.%location: handle=\_PR_.P003 dev.cpu.2.%driver: cpu dev.cpu.2.%desc: ACPI CPU dev.cpu.1.cx_method: C1/hlt C2/io dev.cpu.1.cx_usage_counters: 10797189 0 dev.cpu.1.cx_usage: 100.00% 0.00% last 1713us dev.cpu.1.cx_lowest: C1 dev.cpu.1.cx_supported: C1/1/0 C2/2/100 dev.cpu.1.%parent: acpi0 dev.cpu.1.%pnpinfo: _HID=none _UID=0 dev.cpu.1.%location: handle=\_PR_.P002 dev.cpu.1.%driver: cpu dev.cpu.1.%desc: ACPI CPU dev.cpu.0.cx_method: C1/hlt C2/io dev.cpu.0.cx_usage_counters: 28428935 0 dev.cpu.0.cx_usage: 100.00% 0.00% last 922us dev.cpu.0.cx_lowest: C1 dev.cpu.0.cx_supported: C1/1/0 C2/2/100 dev.cpu.0.freq_levels: 3300/13770 3000/11040 2400/7417 1800/4680 1400/3195 dev.cpu.0.freq: 1400 dev.cpu.0.%parent: acpi0 dev.cpu.0.%pnpinfo: _HID=none _UID=0 dev.cpu.0.%location: handle=\_PR_.P001 dev.cpu.0.%driver: cpu dev.cpu.0.%desc: ACPI CPU dev.cpu.%parent: security.jail.param.cpuset.id: 0 vesta# Such is life. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional ___ 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: Which AMD CPUs are supported -- temperature
On 2/12/2020 1:39 PM, Chris wrote: > Hard as I try I can not get anything close to the actual temperature > of the CPUs or cores while running on FreeBSD. > Family: Athlon X4 > Manufacturer: AuthenticAMD > Not sure about the older Athlon CPUs, but the 2 generations of Ryzen's I have seem correct as well as an APU CPU: AMD GX-412TC SOC (998.17-MHz K8-class CPU) CPU: AMD Ryzen 7 3700X 8-Core Processor (3593.33-MHz K8-class CPU) CPU: AMD Ryzen 7 2700X Eight-Core Processor (3693.17-MHz K8-class CPU) e.g. at idle # sysctl -a dev.cpu.0.temperature dev.cpu.0.temperature: 31.1C then start up # cat /dev/urandom | openssl sha256 # sysctl -a dev.cpu.0.temperature dev.cpu.0.temperature: 57.1C It agrees with what IPMI reports too from the MB # ipmitool sensor | grep "CPU Temp" CPU Temp | 31.000 | degrees C | ok | na | na | na | 93.000 | 94.000 | na And on a fanless APU # sysctl -a dev.cpu.0.temperature dev.cpu.0.temperature: 62.6C # sysctl -a dev.amdtemp.0.core0.sensor0 dev.amdtemp.0.core0.sensor0: 63.1C ---Mike ___ 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: panic: Assertion in_epoch(net_epoch_preempt) failed, r357793
On 2020-02-12 18:22, Gleb Smirnoff wrote: Hans already checked in his patch. Great! You're welcome. Glad it worked. --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"
Which AMD CPUs are supported -- temperature
Hard as I try I can not get anything close to the actual temperature of the CPUs or cores while running on FreeBSD. I assembled the following box as an intended builder for FreeBSD Install images, upgrade images, and ports development, and package builder / installer. But to no avail. I'm unwilling to put any pressure on a CPU I have no reference material on regarding the temperature. Immediately after boot I get 1.1C, and loading it with average services; the CPU is purported by FreeBSD (amdtemp) to hover between ~7-11.6C. I can be fairly sure that the CPU isn't frozen after boot, as I'm not dumping liquid nitrogen on it, or anything. :) According to specs on this CPU; I can safely run it up to 70C. At POST, the BIOS reports it around ~34-38C. But as noted above, after boot, FreeBSD reports 1.1C. Which can't be correct. What needs to be done to get the temp? I don't have this problem on any of my other AMD based boxes/servers. Detailed info on this CPU, and FreeBSD it's running: FreeBSD 12.0-CURRENT #0 r323185: amd64 Also tried on: FreeBSD 12.1-STABLE r357001 amd64 # dmidecode 3.1 Scanning /dev/mem for entry point. SMBIOS 2.8 present. Handle 0x003F, DMI type 4, 42 bytes Processor Information Socket Designation: P0 Type: Central Processor Family: Athlon X4 Manufacturer: AuthenticAMD ID: 01 0F 63 00 FF FB 8B 17 Signature: Family 21, Model 48, Stepping 1 Flags: FPU (Floating-point unit on-chip) VME (Virtual mode extension) DE (Debugging extension) PSE (Page size extension) TSC (Time stamp counter) MSR (Model specific registers) PAE (Physical address extension) MCE (Machine check exception) CX8 (CMPXCHG8 instruction supported) APIC (On-chip APIC hardware supported) SEP (Fast system call) MTRR (Memory type range registers) PGE (Page global enable) MCA (Machine check architecture) CMOV (Conditional move instruction supported) PAT (Page attribute table) PSE-36 (36-bit page size extension) CLFSH (CLFLUSH instruction supported) MMX (MMX technology supported) FXSR (FXSAVE and FXSTOR instructions supported) SSE (Streaming SIMD extensions) SSE2 (Streaming SIMD extensions 2) HTT (Multi-threading) Version: AMD Athlon(tm) X4 860K Quad Core Processor Voltage: 1.4 V External Clock: 100 MHz Max Speed: 3700 MHz Current Speed: 3700 MHz Status: Populated, Enabled Upgrade: Socket FM2 L1 Cache Handle: 0x0023 L2 Cache Handle: 0x0024 L3 Cache Handle: Not Provided Serial Number: Not Specified Asset Tag: Not Specified Part Number: Not Specified Core Count: 4 Core Enabled: 4 Thread Count: 4 Characteristics: 64-bit capable dev.cpu.3.cx_method: C1/hlt dev.cpu.3.cx_usage_counters: 63812 dev.cpu.3.cx_usage: 100.00% last 2223us dev.cpu.3.cx_lowest: C1 dev.cpu.3.cx_supported: C1/1/0 dev.cpu.3.temperature: 1.6C dev.cpu.3.%parent: acpi0 dev.cpu.3.%pnpinfo: _HID=none _UID=0 dev.cpu.3.%location: handle=\_PR_.P003 dev.cpu.3.%driver: cpu dev.cpu.3.%desc: ACPI CPU dev.cpu.2.cx_method: C1/hlt dev.cpu.2.cx_usage_counters: 14741 dev.cpu.2.cx_usage: 100.00% last 20303us dev.cpu.2.cx_lowest: C1 dev.cpu.2.cx_supported: C1/1/0 dev.cpu.2.temperature: 1.6C dev.cpu.2.%parent: acpi0 dev.cpu.2.%pnpinfo: _HID=none _UID=0 dev.cpu.2.%location: handle=\_PR_.P002 dev.cpu.2.%driver: cpu dev.cpu.2.%desc: ACPI CPU dev.cpu.1.cx_method: C1/hlt dev.cpu.1.cx_usage_counters: 13740 dev.cpu.1.cx_usage: 100.00% last 41429us dev.cpu.1.cx_lowest: C1 dev.cpu.1.cx_supported: C1/1/0 dev.cpu.1.temperature: 1.6C dev.cpu.1.%parent: acpi0 dev.cpu.1.%pnpinfo: _HID=none _UID=0 dev.cpu.1.%location: handle=\_PR_.P001 dev.cpu.1.%driver: cpu dev.cpu.1.%desc: ACPI CPU dev.cpu.0.cx_method: C1/hlt C2/io dev.cpu.0.cx_usage_counters: 36918 0 dev.cpu.0.cx_usage: 100.00% 0.00% last 3896us dev.cpu.0.cx_lowest: C1 dev.cpu.0.cx_supported: C1/1/0 C2/2/400 dev.cpu.0.freq_levels: 3700/26568 3500/22525 3000/14531 2400/8507 1700/5415 dev.cpu.0.freq: 3700 dev.cpu.0.temperature: 1.6C dev.cpu.0.%parent: acpi0 dev.cpu.0.%pnpinfo: _HID=none _UID=0 dev.cpu.0.%location: handle=\_PR_.P000 dev.cpu.0.%driver: cpu dev.cpu.0.%desc: ACPI CPU dev.cpu.%parent: dev.amdtemp.0.core0.sensor0: 11.1C dev.amdtemp.0.sensor_offset: 0 dev.amdtemp.0.%parent: hostb7 dev.amdtemp.0.%pnpinfo: dev.amdtemp.0.%location: dev.amdtemp.0.%driver: amdtemp dev.amdtemp.0.%desc: AMD CPU On-Die Thermal Sensors dev.amdtemp.%parent: dev.cpu.3.temperature: 12.5C dev.cpu.2.temperature: 12.5C dev.cpu.1.temperature: 12.5C dev.cpu.0.temperature: 12.5C Thanks again! --Chris __
Re: panic: Assertion in_epoch(net_epoch_preempt) failed, r357793
On Wed, Feb 12, 2020 at 09:18:32AM -0800, Gleb Smirnoff wrote:
T> On Wed, Feb 12, 2020 at 07:41:54PM +0300, y...@mm.st wrote:
T> y> Gleb Smirnoff wrote:
T> y> > On Wed, Feb 12, 2020 at 09:49:12AM +0300, y...@mm.st wrote:
T> y> > y> Getting the following panic after updating to r357793 (expect typos,
hand
T> y> > y> copied):
T> y> > y>
T> y> > y> panic: Assertion in_epoch(net_epoch_preempt) failed at
T> y> > y> /usr/src/sys/net/iflib.c:2762
T> y> > y>
T> y> > y> db_trace_self_wrapper()
T> y> > y> vpanic()
T> y> > y> panic()
T> y> > y> iflib_rxeof()
T> y> > y> _task_fn_rx()
T> y> > y> gtaskqueue_run_locked()
T> y> > y> gtaskqueue_thread_loop()
T> y> > y> fork_exit()
T> y> > y> fork_trampoline()
T> y> > y> --- trap 0, rip = 0, rsp = 0, rbp = 0 ---
T> y> >
T> y> > Are you running iflib as a loadable module? Your trace clearly
T> y> > has _task_fn_rx(), and Hans's patch covers _task_fn_tx(). However,
T> y> > Hans's patch helped you. So, my guess is happen just due to
T> y> > recompilation and reinstall of the module, not due to patch.
T> y>
T> y> No, it was a clean install from latest snapshot ISO, updated to that
T> y> revision using the usual {build,install}{world,kernel} procedure without
T> y> any settings in src.conf and using GENERIC conf, so iflib is builtin.
T>
T> Sorry, Hans's patch is correct. I didn't notice the alternative
T> initializer of taskqueue. Strange that this didn't pop up with
T> my igb0. Will fix in few minutes.
Hans already checked in his patch. Great!
--
Gleb Smirnoff
___
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: panic: Assertion in_epoch(net_epoch_preempt) failed, r357793
On Wed, Feb 12, 2020 at 07:41:54PM +0300, y...@mm.st wrote:
y> Gleb Smirnoff wrote:
y> > On Wed, Feb 12, 2020 at 09:49:12AM +0300, y...@mm.st wrote:
y> > y> Getting the following panic after updating to r357793 (expect typos,
hand
y> > y> copied):
y> > y>
y> > y> panic: Assertion in_epoch(net_epoch_preempt) failed at
y> > y> /usr/src/sys/net/iflib.c:2762
y> > y>
y> > y> db_trace_self_wrapper()
y> > y> vpanic()
y> > y> panic()
y> > y> iflib_rxeof()
y> > y> _task_fn_rx()
y> > y> gtaskqueue_run_locked()
y> > y> gtaskqueue_thread_loop()
y> > y> fork_exit()
y> > y> fork_trampoline()
y> > y> --- trap 0, rip = 0, rsp = 0, rbp = 0 ---
y> >
y> > Are you running iflib as a loadable module? Your trace clearly
y> > has _task_fn_rx(), and Hans's patch covers _task_fn_tx(). However,
y> > Hans's patch helped you. So, my guess is happen just due to
y> > recompilation and reinstall of the module, not due to patch.
y>
y> No, it was a clean install from latest snapshot ISO, updated to that
y> revision using the usual {build,install}{world,kernel} procedure without
y> any settings in src.conf and using GENERIC conf, so iflib is builtin.
Sorry, Hans's patch is correct. I didn't notice the alternative
initializer of taskqueue. Strange that this didn't pop up with
my igb0. Will fix in few minutes.
--
Gleb Smirnoff
___
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: panic: Assertion in_epoch(net_epoch_preempt) failed, r357793
Gleb Smirnoff wrote:
On Wed, Feb 12, 2020 at 09:49:12AM +0300, y...@mm.st wrote:
y> Getting the following panic after updating to r357793 (expect typos, hand
y> copied):
y>
y> panic: Assertion in_epoch(net_epoch_preempt) failed at
y> /usr/src/sys/net/iflib.c:2762
y>
y> db_trace_self_wrapper()
y> vpanic()
y> panic()
y> iflib_rxeof()
y> _task_fn_rx()
y> gtaskqueue_run_locked()
y> gtaskqueue_thread_loop()
y> fork_exit()
y> fork_trampoline()
y> --- trap 0, rip = 0, rsp = 0, rbp = 0 ---
Are you running iflib as a loadable module? Your trace clearly
has _task_fn_rx(), and Hans's patch covers _task_fn_tx(). However,
Hans's patch helped you. So, my guess is happen just due to
recompilation and reinstall of the module, not due to patch.
No, it was a clean install from latest snapshot ISO, updated to that
revision using the usual {build,install}{world,kernel} procedure without
any settings in src.conf and using GENERIC conf, so iflib is builtin.
___
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: panic: Assertion in_epoch(net_epoch_preempt) failed, r357793
On Wed, Feb 12, 2020 at 09:49:12AM +0300, y...@mm.st wrote: y> Getting the following panic after updating to r357793 (expect typos, hand y> copied): y> y> panic: Assertion in_epoch(net_epoch_preempt) failed at y> /usr/src/sys/net/iflib.c:2762 y> y> db_trace_self_wrapper() y> vpanic() y> panic() y> iflib_rxeof() y> _task_fn_rx() y> gtaskqueue_run_locked() y> gtaskqueue_thread_loop() y> fork_exit() y> fork_trampoline() y> --- trap 0, rip = 0, rsp = 0, rbp = 0 --- Are you running iflib as a loadable module? Your trace clearly has _task_fn_rx(), and Hans's patch covers _task_fn_tx(). However, Hans's patch helped you. So, my guess is happen just due to recompilation and reinstall of the module, not due to patch. -- Gleb Smirnoff ___ 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: hwpstate_intel hangs kernel
Hello Conrad, thanks for the information and for contributing the driver in the first place! I'll stick with the hint for now. Best regards Andreas On Tue, Feb 11, 2020 at 9:05 PM Conrad Meyer wrote: > Hi Andreas, > > No, nothing new on this front. I don't have any of this hardware nor > do I work for Intel, and nothing I see in the code or published spec > would result in hangs. I don't have more cycles to spend on this > driver. So I suggest using 'hint.hwpstate_intel.0.disabled="1"' as a > workaround indefinitely. > > On a private email with Andrey I discussed making disabled="1" the > default, and allowing users to opt in with disabled="0" (or perhaps > enabled="1", for fewer double negatives). It's not especially > satisfying, but would prevent this class of unknown issue with > hwpstate_intel(4). > > Best, > Conrad > > On Tue, Feb 11, 2020 at 11:49 AM Andreas Nilsson > wrote: > > > > Hello, > > > > any new leads on this? As of what is in git on 2020-02-05, my computer > still hangs on kernel boot on "hwpstate_intel0: on cpu0" > > > > I guess it would have been easier to debug a panic. Setting > debug.hwpstate_verbose=1 doesn't really give any difference in output. > > > > Best regards > > Andreas > > > > On Wed, Feb 5, 2020 at 2:45 PM Andreas Nilsson > wrote: > >> > >> Hello, > >> > >> I upgraded to a newer version, git 87d669d3863-c266265, and I do not > experience the random hang anymore. The machine still hangs on boot on > "hwpstate_intel0: on cpu0" unless I set > 'hint.hwpstate_intel.0.disabled="1"' in loader.conf. > >> > >> On a side note I cannot set or unset that hint from loader prompt; > >> > >> ok> set hint.hwpstate_intel.0.disabled="0" > >> ok> show > >> > >> hint.hwpstate= > >> ... > >> > >> Best regards > >> Andreas > >> > >> On Sat, Feb 1, 2020 at 11:26 PM Andreas Nilsson > wrote: > >>> > >>> Hello Conrad, > >>> > >>> thank you Andrey for bisecting! I'll try with that hint and see how it > works for me. > >>> > >>> Best regards > >>> Andreas > >>> > >>> On Sat, Feb 1, 2020, 18:18 Conrad Meyer wrote: > > Hi Andrey, > > Please try 'hint.hwpstate_intel.0.disabled="1"' as a workaround for > now. > > I think I have identified at least one problematic piece of code, > although I don't know if it's the root cause. I will go ahead and fix > that, which may not fix the hang, and also add some debug printfs that > can be enabled to help identify the real issue. > > Thanks for the report and bisect. > > Best, > Conrad > > On Sat, Feb 1, 2020 at 6:06 AM Andrey V. Elsukov > wrote: > > > > 31.01.2020 18:11, Andrey V. Elsukov пишет: > > > On 24.01.2020 19:52, Andreas Nilsson wrote: > > >> It hangs during kernel boot and the last message printed on > console is: > > >> hwpstate_intel0: on cpu0 > > > > > > Hi, > > > > > > Did you find the cause of this hang? > > > I also tried to update today from r350816 to r357330. But my > Lenovo X1 > > > Carbon 4th hangs on the same message. > > > > > > > Hi, > > > > I have bisected the bad commit, it is r357002. > > > > -- > > WBR, Andrey V. Elsukov > > > ___ 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: 13-Current not format efi partition
ср, 12 февр. 2020 г., 06:23 Thomas Mueller :
> from Andrey Fesenko:
>
> > bsdinstall script, work in 2019
>
> PARTITIONS="$DISKSLICE GPT { 512K freebsd-boot, 1M efi, auto freebsd-ufs
> / }
> #!/bin/sh -x
> # Make diskname independante
> gpart modify -l freebsd-boot -i 1 ada0
> gpart modify -l efi -i 2 ada0
> gpart modify -l root -i 3 ada0
> # Make EFI happy
> mount_msdosfs /dev/gpt/efi /media/
> mkdir -p /media/EFI/BOOT/
> cp /boot/loader.efi /media/EFI/BOOT/BOOTX86.efi
> umount /media/
>
> > FreeBSD-13.0-CURRENT-amd64-20200206-r357606-disc1.iso not format efi
> partition
>
>
> Booting by UEFI would not use or need a freebsd-boot partition.
>
freebsd-boot it's another bug :) it's create automatically, anyway
Add newfs_msdos /dev/gpt/efi fix new behavior installer, but why
>
___
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: panic: Assertion in_epoch(net_epoch_preempt) failed, r357793
On 2020-02-12 10:10, y...@mm.st wrote: Hans Petter Selasky wrote: Hi, Does the attached patch fix the issue? It seems to help, yes, at least no panic right after the boot. Let us know if this happens again. There is currently some ongoing work in this area. https://svnweb.freebsd.org/changeset/base/357800 --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: panic: Assertion in_epoch(net_epoch_preempt) failed, r357793
Hans Petter Selasky wrote: Hi, Does the attached patch fix the issue? It seems to help, yes, at least no panic right after the boot. ___ 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: panic: Assertion in_epoch(net_epoch_preempt) failed, r357793
Hi,
Does the attached patch fix the issue?
--HPS
Index: sys/net/iflib.c
===
--- sys/net/iflib.c (revision 357799)
+++ sys/net/iflib.c (working copy)
@@ -6060,6 +6060,7 @@
gtask = &ctx->ifc_txqs[qid].ift_task;
tqg = qgroup_if_io_tqg;
fn = _task_fn_tx;
+ GROUPTASK_INIT(gtask, 0, fn, q);
break;
case IFLIB_INTR_RX:
q = &ctx->ifc_rxqs[qid];
@@ -6066,6 +6067,7 @@
gtask = &ctx->ifc_rxqs[qid].ifr_task;
tqg = qgroup_if_io_tqg;
fn = _task_fn_rx;
+ NET_GROUPTASK_INIT(gtask, 0, fn, q);
break;
case IFLIB_INTR_IOV:
q = ctx;
@@ -6072,11 +6074,11 @@
gtask = &ctx->ifc_vflr_task;
tqg = qgroup_if_config_tqg;
fn = _task_fn_iov;
+ GROUPTASK_INIT(gtask, 0, fn, q);
break;
default:
panic("unknown net intr type");
}
- GROUPTASK_INIT(gtask, 0, fn, q);
if (irq != NULL) {
err = iflib_irq_set_affinity(ctx, irq, type, qid, gtask, tqg,
q, name);
@@ -6136,7 +6138,7 @@
iflib_fast_intr_rxtx, NULL, info, name);
if (err != 0)
return (err);
- GROUPTASK_INIT(gtask, 0, fn, q);
+ NET_GROUPTASK_INIT(gtask, 0, fn, q);
res = irq->ii_res;
taskqgroup_attach(tqg, gtask, q, dev, res, name);
___
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"
