I would like to know if there is any way to enable a specific feature in the CPU, if that feature is not given in the BIOS. For example, i have Xeon E5-2680 V2, according to the data sheet this processor supports NTB on PCIe Port3a. But this NTB option in not given in the BIOS of HP Z420 workstation.
I want to know if there is a possible way to change this PPD register given at page 138 of pdf.
Thank you
Below command did the job.
sudo setpci -H 1 -s 3 4d.B=02
Related
I'm on a system with multiple NVIDIA GPUs. One or more of them may - or may not - be used to drive a physical monitor. In my compute work, I want to avoid using that one (or more).
How can I, programmatically, check which GPUs are used for display?
If there's no robust way of doing that, I'll settle for getting those GPUs which are used by an Xorg process (which is what nvidia-smi gives me on the command-line)
In case you want to use the same process, you can check the NVML API functions nvmlDeviceGetDisplayActive and nvmlDeviceGetDisplayMode.
Specifically,
nvmlReturn_t nvmlDeviceGetDisplayMode ( nvmlDevice_t device, nvmlEnableState_t* display ) can be used to detect if a physical display is connected to a device.
nvmlReturn_t nvmlDeviceGetDisplayActive ( nvmlDevice_t device, nvmlEnableState_t* isActive ) can be used to check if X server is attached to a device, it can be possible that an X server is running, without an attached physical display.
Link to documentation
Try the following on a terminal
nvidia-smi --format=csv --query-gpu=index,display_mode,display_active
For more information check the nvidia-smi documentation and nvidia-smi --help-query-gpu
I start to explore in the area of computer architecture. There are 2 questions about ISA that confuse me.
As far as I know, there are different kinds of ISA such as ARM, MIPS, 80x86, etc. I wonder whether a CPU can only specifically read one kind of ISA. For example, can a processor read both 80x86 and MIPS.
If a CPU is unique to an ISA, how can I check which ISA my PC processor is using? Can I find it out manually?
Thank you
All the CPU/MCU's I know of support just single instruction set.
There is capability of loading microcode to some of the newer architectures that may allow to change the instruction set behavior to some point bot strongly doubt it you can change the instruction set with it. Instruction set and internal CPU/MCU circuitry are strongly dependent. Making universal CPU with changeable instruction set is possible (for example with FPGA) but would be very slow in comparison to direct DIE encoded CPU. With similar technology of Die the clock speed would be may be just few MHz.
Some architectures like i80x86 supports modes that can switch to different kind of operation (16/32/64 bit,real,protected) but its hard to say it is different instruction set or just subset of the same thing ...(matter of perspective)
detection of instruction set.
This is madness. Yes it is possible to detect which type of instruction set you have via program but all the CPU/MCU's have different pinout, interfaces, architectures and are not interchangeable (even in the same architecture class) so you detecting instruction set is meaningless as you alredy know the architecture you are doing the wiring for ...
Anyway the detection would work like this:
have set of test programs of each supported instruction set/architecture that will set specific memory or IO to predefined state if working properly
have watch dog cycling between all the detections and stop on first valid result.
Yes, each type of CPU is unique to an instruction set. The instruction set for ARM will not work with x86, SPARC, etc. There may be some overlap by coincidence, but programs are not compatible between architectures.
Depending on your operating system, there are commands you can run to see this information. For unix/Linux, uname -a will show you what architecture you're running, as well as dmidecode. For Windows OS's, right-clicking on My Computer and selecting Properties should show you your architecture.
For example (Windows 7):
For Linux (I know, it's a super-old distro!):
$ uname -a
Linux hostname 2.6.35-22-generic #33-Ubuntu SMP Sun Sep 19 20:32:27 UTC 2010 x86_64 GNU/Linux
(In this example, the architecture is x86_64), which is 64-bit Intel or AMD. To tell for sure, you can run dmidecode as I mentioned earlier:
~# dmidecode |grep -i proc
Processor Information
Type: Central Processor
Version: AMD Opteron(tm) Processor 154
Processor Information
Type: Central Processor
Version: AMD Opteron(tm) Processor 154
It can actually read any instruction set if the support is implemented. Most of the CPUs nowadays support two/three instructions set that only slightly differ because of 32-bit/64-bit addressing.
x86 supports 16-bit, 32-bit and 64-bit instructions set, ARM support 32-bit, 64-bit, for both Thumb and Thumb-2, etc. Similarly for MIPS for example.
Original Transmeta I believe was flexible about it and supposed to transcompile any instruction set into internal set and run it natively. However it failed and nowadays there is nothing similar to it.
Anyway, once you run application, it's bound to specific instruction set in its header so it can't change it during the runtime. Well, ARM is exception to that - it's able to switch between full and Thumb versions but they are just different encoding for the same...
For the second part - either in your OS GUI or you can usually read it - in Linux by reading /proc/cpuinfo, on Windows in the environment variable PROCESSOR_ARCHITECTURE.
Setup and observation
I have a PC equipped with an Intel i350 T2 NIC where I would like to capture on both interfaces simultaneously using tcpdump. Both interfaces are connected to a 100mbit HUB (sic!) which forwards various traffic from an external traffic source to both interfaces at the "same time", so I can measure the difference of the timestamps done by the respective ethernet MACs.
Capturing simultaneously with:
user#rt:~$ sudo tcpdump -j adapter --time-stamp-precision nano -B 1048576 -i eth2 -w test_eth2.pcap
user#rt:~$ sudo tcpdump -j adapter --time-stamp-precision nano -B 1048576 -i eth3 -w test_eth3.pcap
After that I merge the two files together to compare the timestamps:
user#rt:~$ mergecap -F nseclibpcap -w merged.pcap test_eth2.pcap test_eth3.pcap
Wireshark then shows me, that for a few packets I get a timestamp diff of the duplicate frames of around 20-40nsec (which is nice and sufficient for my application!).
But there are also lots of frames which show a difference of up to tens of microseconds when comparing the respective duplicates.
Environment
user#rt:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 15.04
Release: 15.04
Codename: vivid
user#rt:~$ uname -r
3.19.0-28-generic
user#rt:~$ lscpu | grep "Model name"
Model name: Intel(R) Core(TM) i7-4790 CPU # 3.60GHz
Questions
How/Who does the syncing of the adapter clock to CLOCK_REALTIME (I presume)
How often does this syncing occur.
Is there some room for tweaking without too much effort?
Is it possible to use e.g. phc2sys to sync all adapter clocks to CLOCK_REALTIME?
Would (4) interfere with the mechanisms done by (1)?
THX for help or pointing out my mistakes!
From a quick glance at igb_ethtool.c your NIC indeed seems to be capable of hardware timestamping. The jitter you observe (20-40ns) is just in the range of the expected PHY jitter from synchronizing to the Ethernet clock. (For 100Mbit the clock is 25MHz or 40ns.)
So far looking great, thanks to Intel. Not many NICs/drivers have this capability.
Now the bad part: I doubt anything is syncing CLOCK_REALTIME to the NIC adapter clock at the moment. The clocks are probably free-running at a slightly different frequencies. Those oscillators are usually specified at 50ppm, typical drifts will be around 5ppm, which means they will drift apart by ~5us every second, varying with room temperature. Keep that in mind when using the nanosecond precision. If your system uses NTP you may even see NTP drift adjustments happening.
But the good news is that you probably don't need to synchronize them, unless you really want absolute timestamps. The main reason why your NIC supports hardware timestamping at all is probably to support IEEE1588 PTP (precision time protocol). If you need absolute time with sub-microsecond precision, you should look look at this protocol and/or buy a GPS receiver.
If you just need relative timestamps, you could try -j adapter_unsynced instead of -j adapter, or maybe you could try to stop NTP from trying to drift-correct your system clock. If all this fails, you could try to start linuxptp, which may have the capbability to properly sync NIC and system time even if you don't have a PTP network.
And finally... you are using a HUB, which means Ethernet is running in half-duplex mode, which means... collisions. Unless your NIC is absolutely quiet. I guess in theory this shouldn't matter because you observe the same collisions in both NICs, and frames aren't delayed or queued differently depending on which path they take. But since half-duplex is so rare these days it may be that NIC timestamping support wasn't implemented with that in mind. Typical bugs in such implementations are e.g. returning the timestamp of the previous frames instead of the current one.
Chapter 7.9 of the Intel i350 Datasheet may help you with your 3rd question. It provides the set of PTP registers you can configure in the igb driver.
http://www.intel.com/content/dam/www/public/us/en/documents/datasheets/ethernet-controller-i350-datasheet.pdf
Is it possible to use kstat to get information about which processes have which ports open? I've looked into how lsof does it and apparently they read volatile kernel memory, which kstat seems to give access to (please correct me if I'm wrong).
I was just wondering if anyone knows how to filter kstat to display information about which processes a port has open. Perhaps which module should I look at?
On Solaris 11.2, you can use netstat -u to obtain that information. Per the man page:
–u
Lists the user, process id, and the program which originally
created the network endpoint or controls it now.
On earlier versions of Solaris, there's no easy way - you can use pfiles to some degree, but its utility in identifying sockets is limited.
Also see What process is listening on a certain port on Solaris?
No, kstat doesn't store process level information. Moreover, kstat doesn't give access to volatile kernel memory but only to specific kernel statistics.
Finally, you shouldn't have started a new question instead of following up here.
Need to create a script to check to see if the kernel is in PAE mode or not. Surely, it is not enough to just check if the /proc/cpuinfo flags have this 'pae' setting.
We must know if the PAE mechanism has actually been not only implemented, but activated as well.
Because the PAE kernel is now the new default, and that if you need a non-PAE kernel, one has to make another kernel nowadays.
In other word, how do we tell if a kernel is non-PAE on a CPU having PAE (is one of two possible conditions to test for).
Other is, how to tell if a kernel is PAE on a CPU having no PAE-support.
And there's no way to tell if CONFIG_HIGHMEM or CONFIG_PAE kernel configuration option was used in a typical secured kernel.
Usually, CONFIG_PAE can be discovered in your /boot/config-*, like this:
$ cat /boot/config-$(uname -r) | grep PAE
CONFIG_X86_PAE=y
Do you not have access to the that file?
One way is to read the CR4 register and look at bit 5. It will be 1 for PAE and 0 for no PAE. You can read that register in some code running in the kernel (e.g. a kernel driver). You may be able to write a tiny driver for this purpose. It shouldn't be very complicated.