lspci # prints a list of PCI devices
grep -i 'VGA compatible controller' # filter for graphic cards
head -n 1 # limit the output to only the first line from above
awk '{print $1}' # print only the first element which is the ID of the device
Explanation Level 2:
Code:
lspci -v -s "$([LEVEL_1])" # prints details of the PCI device and uses the ID we got in level 1
grep -ie 'Memory at .* prefetchable' # filter for the line that specifies the RAM..
There are at least two types of memory that are relevant here in relation to graphics cards, "prefetchable memory" which is the output of the command in post #7, and the memory of the graphics card itself which is expressed as VRAM, or video RAM.
Usually graphics cards' RAM values are specified in VRAM, so when you buy a graphics card it can be a 1 G card, (or a 1024 Mib card), or a 2 G card etc. The memory which the command in post #7 extracts is "prefetchable" memory which is a type of memory that can be accessed by the CPU that sort of "pre-fetches" it and lodges it in the CPU cache. It loads up this memory to have it in order to improve graphics performance, sort of "getting in early" so it's available for graphics processing when there's a graphics demand being made, or a graphics card request.
Code:
[flip@flop ~]$ lspci -v -s "$(lspci | grep -i 'VGA compatible controller' | head -n 1 | awk '{print $1}')" | grep -ie 'Memory at .* prefetchable'
Memory at d0000000 (64-bit, prefetchable) [size=256M]
Memory at e0000000 (64-bit, prefetchable) [size=32M]
To find the video RAM of the graphics card itself, which is a measure of the amount of memory that the graphics card can actually use, run:
In the case of this machine, the actual memory of the graphics card is 1024 Mib, or 1 G with the prefetchable much less.
The memory in the graphics card is optimised for graphical processing, so it can be speedier than prefetchable memory. There's complexities in this in different hardware that I can't say more about, such as systems without separate or dedicated graphics cards that use the CPU for graphics functions, but those are other uses of memory than this "prefetchable versus graphics card" memory.
The glxinfo command is from the mesa-utils package, which may not actually be needed to be installed on a server, so without that package, obviously that command is irrelevant. Also it's for X rather than wayland.
Perhaps you could be kind enough to explain how grep is unstable in dmesg. I'm not familiar with this phenomenon.
The “help“ command is a bash built-in command, used to display information for bash built-in commands.
help (option) (perimeter)
-d: Display a brief description of the built in commands.
-m: Output the information of built in commands in the format of the man manual.
-o: Only output the command format of built-in commands.
The glxinfo command is from the mesa-utils package, which may not actually be needed to be installed on a server, so without that package, obviously that command is irrelevant. Also it's for X rather than wayland.
Perhaps you could be kind enough to explain how grep is unstable in dmesg. I'm not familiar with this phenomenon.
In past i often use grep against dmesg in my bash scripts. For hardware raid controller, Networkcard and so on. But the output REALY often change and this is a problem for me. But its only my own experience.
In past i often use grep against dmesg in my bash scripts. For hardware raid controller, Networkcard and so on. But the output REALY often change and this is a problem for me. But its only my own experience.
Thanks. I can see the problem you have had with the dmesg output which is in a buffer, (the "kernel ring buffer") which is a buffer of a fixed size so that when new messages are put into it, the older ones have to be removed to make room. A working system will often have new messages entering the buffer so it's a moving "target". The grep command with a fixed search term looking for a fixed item therefore couldn't be relied upon, but fortunately, it's not a problem with the grep executable.
This is a bit more than just a single command... but it's very easy to set up and use. I had trouble with internet connectivity over the summer, and I came up with this script to identify when my connection went down, and for how long. It is simply a ping sent once per minute that records date and timestamp and appends the result to a file. Then the file is later parsed using grep to identify the internet downtime from the timestamps.
Correct any reference to "username" to your own user name.
Script named ~/testnetwork.sh (copy/paste into a file and chmod +x to make executable.)
Code:
ping -c 1 google.com | while read pong; do echo "$(date): $pong"; done >> /home/username/Desktop/testnetwork.txt
The script is executed every minute from cron. Run crontab -e and add this below:
Code:
* * * * * /home/username/testnetwork.sh
Let it run all day, or for several days. The script adds 6 lines of text to the file every minute, so remember that it will generate many thousands of lines. Eventually you want to delete it and let it start over. Delete the cron job with crontab -e when you no longer need the script to run.
To find your downtime, look for "100% packet loss" in the file that is created on the desktop:
Code:
cat ~/Desktop/testnetwork.txt | grep 100%
My results look like this... these are my most recent internet failures:
Code:
$ cat ~/Desktop/testnetwork.txt | grep 100%
Thu Oct 19 04:08:11 PM CDT 2023: 1 packets transmitted, 0 received, 100% packet loss, time 0ms
Thu Oct 19 07:49:11 PM CDT 2023: 1 packets transmitted, 0 received, 100% packet loss, time 0ms
Fri Oct 20 12:00:11 PM CDT 2023: 1 packets transmitted, 0 received, 100% packet loss, time 0ms
Of course, random failures of ping like these do not indicate an internet outage. Packet collisions happen all the time and are a simple explanation for a one-off failure. But the text file will reveal exactly when an outage does occur, and it will track minute-by-minute downtime and when the service resumes. It's been very helpful for me when I argue with my ISP about service problems.
I hope someone else finds this useful. Gratitude to others for the help I found online with this. Cheers.
If you don't mind installing another package (moreutils)... you can use the ts command for a little cleaner looking script. Then ~/testnetwork.sh would look like this:
Or, if you just want your script to hang for some time but with the option to continue earlier (by pressing enter),
use the same command, but ignore the fact that a variable is actually stored with whatever value (as what it is the "read" function is doing).
.
