Goal
Measure the CPU temperature of my Linux Box.
Work done till now
I have installed lm-sensors to detect the temperature and below is the output of the command sensor:
root#XXXX-XX :# sensors
acpitz-virtual-0
Adapter: Virtual device
temp1: +66.0°C (crit = +255.0°C)
k10temp-pci-00c3
Adapter: PCI adapter
temp1: +65.4°C (high = +70.0°C)
(crit = +100.0°C, hyst = +99.0°C)
radeon-pci-0008
Adapter: PCI adapter
temp1: +64.0°C (crit = +120.0°C, hyst = +90.0°C)
radeon-pci-0100
Adapter: PCI adapter
temp1: N/A (crit = +120.0°C, hyst = +90.0°C)
The output of the cat /proc/cpuinfo is:
processor : 0
vendor_id : AuthenticAMD
cpu family : 21
model : 16
model name : AMD A8-4500M APU with Radeon(tm) HD Graphics
stepping : 1
microcode : 0x6001116
cpu MHz : 1400.000
cache size : 2048 KB
physical id : 0
siblings : 4
core id : 0
cpu cores : 2
apicid : 16
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
.
.
.
processor : 1
vendor_id : AuthenticAMD
cpu family : 21
model : 16
model name : AMD A8-4500M APU with Radeon(tm) HD Graphics
stepping : 1
microcode : 0x6001116
cpu MHz : 1400.000
cache size : 2048 KB
physical id : 0
siblings : 4
core id : 1
cpu cores : 2
apicid : 17
initial apicid : 1
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
processor : 2
vendor_id : AuthenticAMD
cpu family : 21
model : 16
model name : AMD A8-4500M APU with Radeon(tm) HD Graphics
stepping : 1
microcode : 0x6001116
cpu MHz : 1400.000
cache size : 2048 KB
physical id : 0
siblings : 4
core id : 2
cpu cores : 2
apicid : 18
initial apicid : 2
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
processor : 3
vendor_id : AuthenticAMD
cpu family : 21
model : 16
model name : AMD A8-4500M APU with Radeon(tm) HD Graphics
stepping : 1
microcode : 0x6001116
cpu MHz : 1400.000
cache size : 2048 KB
physical id : 0
siblings : 4
core id : 3
cpu cores : 2
apicid : 19
initial apicid : 3
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
Question
Out of the above readings from command sensor and cat /proc/cpuinfo, I am not sure which is exactly my cpu temperature in the output of sensors and what is the one to one relation between the output of both the commands (ie: which field (ie:output of sensor) matches with the field of cat /proc/cpuinfo).
Your cpu temperature is shown by the k10 sensor, but beware it is assumed to be inaccurate.
https://www.kernel.org/doc/Documentation/hwmon/k10temp
Related
I am facing an issue where the period size has been set to 128, still sometimes the polling starts late.
For this configuration, where the period size is set to 128 and rate is 16 Khz, therefore polling should occur after each 128/16 = 8 ms, but in some cases the polling occurs a bit late which causes certain issues in the application. Since, polling is triggered internally by Alsa system modules which is dependent on the configuration, kindly suggest if we are going wrong somewhere with the configuration or any similar issue anyone might have experienced. Pasting the PCM dump of my Setup below:-
APCM_DUMP_DEVICE_DETALS :-
Hardware PCM card 0 'mt2712-d1v1' device 5 subdevice 0
Its setup is:
stream : CAPTURE
access : RW_INTERLEAVED
format : S16_LE
subformat : STD
channels : 1
rate : 16000
exact rate : 16000 (16000/1)
msbits : 16
buffer_size : 512
period_size : 128
period_time : 8000
tstamp_mode : NONE
tstamp_type : MONOTONIC
period_step : 1
avail_min : 128
period_event : 0
start_threshold : 128
stop_threshold : 512
silence_threshold: 0
silence_size : 0
boundary : 4611686018427387904
appl_ptr : 0
hw_ptr : 0
APCM_DUMP_DEVICE_DETALS :-
Hardware PCM card 0 'mt2712-d1v1' device 1 subdevice 0
Its setup is:
stream : PLAYBACK
access : RW_INTERLEAVED
format : S16_LE
subformat : STD
channels : 1
rate : 16000
exact rate : 16000 (16000/1)
msbits : 16
buffer_size : 512
period_size : 128
period_time : 8000
tstamp_mode : NONE
tstamp_type : MONOTONIC
period_step : 1
avail_min : 128
period_event : 0
start_threshold : 128
stop_threshold : 512
silence_threshold: 0
silence_size : 0
boundary : 4611686018427387904
appl_ptr : 0
hw_ptr : 0
APCM_DUMP_DEVICE_DETALS :-
Hardware PCM card 0 'mt2712-d1v1' device 12 subdevice 0
Its setup is:
stream : CAPTURE
access : RW_INTERLEAVED
format : S16_LE
subformat : STD
channels : 1
rate : 16000
exact rate : 16000 (16000/1)
msbits : 16
buffer_size : 512
period_size : 128
period_time : 8000
tstamp_mode : NONE
tstamp_type : MONOTONIC
period_step : 1
avail_min : 128
period_event : 0
start_threshold : 128
stop_threshold : 512
silence_threshold: 0
silence_size : 0
boundary : 4611686018427387904
appl_ptr : 0
hw_ptr : 0
APCM_DUMP_DEVICE_DETALS :-
Hardware PCM card 0 'mt2712-d1v1' device 11 subdevice 0
Its setup is:
stream : PLAYBACK
access : RW_INTERLEAVED
format : S16_LE
subformat : STD
channels : 1
rate : 16000
exact rate : 16000 (16000/1)
msbits : 16
buffer_size : 512
period_size : 128
period_time : 8000
tstamp_mode : NONE
tstamp_type : MONOTONIC
period_step : 1
avail_min : 128
period_event : 0
start_threshold : 128
stop_threshold : 512
silence_threshold: 0
silence_size : 0
boundary : 4611686018427387904
appl_ptr : 0
hw_ptr : 0
For the issue, we tried to analyze the kernel traces, after going through the kernel traces, we found out that we were reading the entire available data (snd_pcm_avail_update) for the capture device(rather than the period_size), due to which a flag in kernel was set to 0 since it had 0 bytes available due to which it was missing the interrupt to wake up the read thread(application) in time. Once we set the pcm_read to read only the required data, the behaviour was rectified
I have a legacy device with following configuration:
Chipset Architecture : Intel NM10 express
CPU : Atom D2250 Dual Core
Volatile Memory : 1GB
CPU core : 4
USB Host controller driver : ehci-pci
When I perform any USB operation I observe increasing tasklet count linearly and if USB operation continues for a long time(approx half an hour) then tasklet count crosses a million and this seems to be very strange to me.
I read about interrupt handling mechanism used by ehci-pci which is not latest(i.e. PCI pin-based) but still the tasklet counts are so high in numbers.
I use /proc/softirqs to read tasklet count.
Any lead on this?
root#panther1:~# cat /proc/interrupts
CPU0 CPU1 CPU2 CPU3
23: 0 0 0 1411443 IO-APIC 23-fasteoi ehci_hcd:usb1, uhci_hcd:usb2
root#panther1:~# cat /proc/softirqs
CPU0 CPU1 CPU2 CPU3
HI: 7 3 13 1125529
TIMER: 2352846 2325384 2533628 2675821
NET_TX: 0 0 2 1703
NET_RX: 1161 1193 2730 51184
BLOCK: 0 0 0 0
IRQ_POLL: 0 0 0 0
TASKLET: 256 164 90 1162220
SCHED: 1078965 1015261 1155661 1207484
HRTIMER: 0 0 0 0
RCU: 1370647 1367098 1485356 1503762
I am compiling C++ source code on Nvidia Jetson nano. Some details of the processor are as follows:
cat /proc/cpuinfo
processor : 0
model name : ARMv8 Processor rev 1 (v8l)
BogoMIPS : 38.40
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x1
CPU part : 0xd07
CPU revision : 1
processor : 1
model name : ARMv8 Processor rev 1 (v8l)
BogoMIPS : 38.40
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x1
CPU part : 0xd07
CPU revision : 1
processor : 2
model name : ARMv8 Processor rev 1 (v8l)
BogoMIPS : 38.40
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x1
CPU part : 0xd07
CPU revision : 1
processor : 3
model name : ARMv8 Processor rev 1 (v8l)
BogoMIPS : 38.40
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x1
CPU part : 0xd07
CPU revision : 1
I get the following error when compiling the code;
c++: error: unrecognized command line option _-mfpu=neon_
c++: error: unrecognized command line option _-mfpu=neon_
I want to know based on the above following specifications; what flags should I set for mfpu?
For ARMv8-A profile processors the FPU and NEON are mandatory parts of the architecture (unlike ARMv7-A) so you shouldn't need a -mfpu flag to enable it.
I have a Debian machine (3.16.0-4-amd64 #1 SMP Debian 3.16.36-1+deb8u2 (2016-10-19) x86_64 GNU/Linux) on which I have some audio devices connected. The devices that are stereo works well, but I have a problem with a mono headset. When I type the command
aplay -v -D plughw:2,0 ~/piano2.wav
the device waits up to 3-4 seconds before starting to output sound. If I retype the command in the following 5 seconds, the sound is played directly, but if I wait a bit more, I have to wait 3-4 seconds again before hearing anything.
Here is the output when I run the command above :
Playing WAVE '/home/console/piano2.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo
Plug PCM: Route conversion PCM (sformat=S16_LE)
Transformation table:
0 <- 0*0.5 + 1*0.5
Its setup is:
stream : PLAYBACK
access : RW_INTERLEAVED
format : S16_LE
subformat : STD
channels : 2
rate : 48000
exact rate : 48000 (48000/1)
msbits : 16
buffer_size : 24000
period_size : 6000
period_time : 125000
tstamp_mode : NONE
period_step : 1
avail_min : 6000
period_event : 0
start_threshold : 24000
stop_threshold : 24000
silence_threshold: 0
silence_size : 0
boundary : 6755399441055744000
Slave: Rate conversion PCM (16000, sformat=S16_LE)
Converter: libspeex (builtin)
Protocol version: 10002
Its setup is:
stream : PLAYBACK
access : MMAP_INTERLEAVED
format : S16_LE
subformat : STD
channels : 1
rate : 48000
exact rate : 48000 (48000/1)
msbits : 16
buffer_size : 24000
period_size : 6000
period_time : 125000
tstamp_mode : NONE
period_step : 1
avail_min : 6000
period_event : 0
start_threshold : 24000
stop_threshold : 24000
silence_threshold: 0
silence_size : 0
boundary : 6755399441055744000
Slave: Hardware PCM card 2 'Jabra PRO 9460' device 0 subdevice 0
Its setup is:
stream : PLAYBACK
access : MMAP_INTERLEAVED
format : S16_LE
subformat : STD
channels : 1
rate : 16000
exact rate : 16000 (16000/1)
msbits : 16
buffer_size : 8000
period_size : 2000
period_time : 125000
tstamp_mode : NONE
period_step : 1
avail_min : 2000
period_event : 0
start_threshold : 8000
stop_threshold : 8000
silence_threshold: 0
silence_size : 0
boundary : 9007199254740992000
appl_ptr : 0
hw_ptr : 0
And this is my .asoundrc file :
pcm.!default {
type plug
slave {
pcm "hw:0,0"
}
}
pcm.device1 {
type plug
slave {
pcm "hw:1,0"
}
}
pcm.device2 {
type plug
slave {
pcm "hw:2,0"
}
}
pcm.device3 {
type plug
slave {
pcm "hw:3,0"
}
}
ctl.!default {
type hw
card 0
}
ctl.device1 {
type hw
card 1
}
ctl.device2 {
type hw
card 2
}
ctl.device3 {
type hw
card 3
}
Does anybody have and idea why I get such a delay when my device wakes-up ?
Thanks
This was only observed in Linux virtual machines. In /proc/cpuinfo, the physical id could be very large, exceeding the number of cpus.
For below example, 4 core systems but the physical id is 13. Also had another virtual machine, only 2 cores, but one physical id is 2.
Anyone has idea how virtual machine defines the linux physical ID?
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 45
model name : Intel(R) Xeon(R) CPU E5-2690 0 # 2.90GHz
stepping : 7
microcode : 1808
cpu MHz : 2900.040
cache size : 20480 KB
physical id : 13
siblings : 1
core id : 0
cpu cores : 1
apicid : 13
initial apicid : 13
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu de tsc msr pae cx8 sep cmov pat clflush mmx fxsr sse sse2 ss ht syscall nx lm constant_tsc rep_good unfair_spinlock pni pclmulqdq ssse3 cx16 sse4_1 sse4_2 popcnt tsc_deadline_timer aes hypervisor lahf_lm arat epb pln pts dts
bogomips : 5800.08
clflush size : 64
cache_alignment : 64
address sizes : 46 bits physical, 48 bits virtual
power management:
processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 45
model name : Intel(R) Xeon(R) CPU E5-2690 0 # 2.90GHz
stepping : 7
microcode : 1808
cpu MHz : 2900.040
cache size : 20480 KB
physical id : 13
siblings : 1
core id : 0
cpu cores : 1
apicid : 13
initial apicid : 13
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu de tsc msr pae cx8 sep cmov pat clflush mmx fxsr sse sse2 ss ht syscall nx lm constant_tsc rep_good unfair_spinlock pni pclmulqdq ssse3 cx16 sse4_1 sse4_2 popcnt tsc_deadline_timer aes hypervisor lahf_lm arat epb pln pts dts
bogomips : 5800.08
clflush size : 64
cache_alignment : 64
address sizes : 46 bits physical, 48 bits virtual
power management:
processor : 2
vendor_id : GenuineIntel
cpu family : 6
model : 45
model name : Intel(R) Xeon(R) CPU E5-2690 0 # 2.90GHz
stepping : 7
microcode : 1808
cpu MHz : 2900.040
cache size : 20480 KB
physical id : 13
siblings : 1
core id : 0
cpu cores : 1
apicid : 13
initial apicid : 13
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu de tsc msr pae cx8 sep cmov pat clflush mmx fxsr sse sse2 ss ht syscall nx lm constant_tsc rep_good unfair_spinlock pni pclmulqdq ssse3 cx16 sse4_1 sse4_2 popcnt tsc_deadline_timer aes hypervisor lahf_lm arat epb pln pts dts
bogomips : 5800.08
clflush size : 64
cache_alignment : 64
address sizes : 46 bits physical, 48 bits virtual
power management:
processor : 3
vendor_id : GenuineIntel
cpu family : 6
model : 45
model name : Intel(R) Xeon(R) CPU E5-2690 0 # 2.90GHz
stepping : 7
microcode : 1808
cpu MHz : 2900.040
cache size : 20480 KB
physical id : 13
siblings : 1
core id : 0
cpu cores : 1
apicid : 13
initial apicid : 13
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu de tsc msr pae cx8 sep cmov pat clflush mmx fxsr sse sse2 ss ht syscall nx lm constant_tsc rep_good unfair_spinlock pni pclmulqdq ssse3 cx16 sse4_1 sse4_2 popcnt tsc_deadline_timer aes hypervisor lahf_lm arat epb pln pts dts
bogomips : 5800.08
clflush size : 64
cache_alignment : 64
address sizes : 46 bits physical, 48 bits virtual
power management: