Writings

Fix on system freezes due to GPU problem on ASUS ROG Strix G513M

2026-03-09T00:00:00+00:00

ASUS ROG Strix G513RM — Linux Freeze & GPU Fix</a> </h1>
Hardware </a> </h2>
Problem Diagnosis</a> </h2> Confirming BadTLP errors</a> </h3> sudo dmesg | grep -i badtlp</code></pre> Output showed repeated: nvidia 0000:01:00.0: PCIe Bus Error: severity=Correctable, type=Data Link Layer, (Receiver ID) nvidia 0000:01:00.0: [ 6] BadTLP</code></pre>Confirming GPU presence</a> </h3> lspci | grep -i nvidia # Expected: 01:00.0 VGA compatible controller: NVIDIA Corporation GA106M [GeForce RTX 3060 Mobile]</code></pre> Fix</a> </h2> Step 1: Enable NVIDIA Dynamic Power Management</a> </h3> Create /etc/modprobe.d/nvidia.conf</code>: sudo nano /etc/modprobe.d/nvidia.conf</code></pre> Add: options nvidia NVreg_DynamicPowerManagement=0x02</code></pre> This allows the driver to properly manage GPU power state, preventing the PCIe link from going unstable. Step 2: Use ACPI reboot method</a> </h3> sudo nano /etc/default/grub</code></pre> Change: GRUB_CMDLINE_LINUX_DEFAULT="quiet splash reboot=acpi"</code></pre> Then: sudo update-grub</code></pre> This forces the kernel to use ACPI reboot instead of the default method, which properly resets PCIe device states on warm reboot. Step 3: Full power cycle (once)</a> </h3> After applying the above, do a full poweroff (not reboot), wait 10 seconds, then power on. This resets the EC (Embedded Controller) state. sudo poweroff</code></pre> Verification</a> </h2> After cold boot: # No output = no errors sudo dmesg | grep -i badtlp # Should show GPU stats nvidia-smi # Should show GPU on bus lspci | grep -i nvidia</code></pre> Notes</a> </h2> Why warm reboot loses the GPU</a> </h3> The ASUS ROG G513RM firmware (EC) does not properly restore dGPU power state on warm reboot — only on cold boot. The reboot=acpi</code> parameter mitigates this in most cases. If the GPU still disappears after a warm reboot, a full power cycle (poweroff → wait → power on) always recovers it. KVM conflicts with VirtualBox</a> </h3> KVM (kvm_amd</code>) is loaded at boot. VirtualBox's vboxdrv</code> kernel module grabs a reference to KVM at load time, making it impossible to unload KVM while VirtualBox is installed. If running 64-bit VMs in VirtualBox fails with an i686 error, blacklist KVM: echo "blacklist kvm_amd" | sudo tee /etc/modprobe.d/blacklist-kvm.conf echo "blacklist kvm" | sudo tee -a /etc/modprobe.d/blacklist-kvm.conf sudo update-initramfs -u sudo reboot</code></pre>Wayland + NVIDIA</a> </h3> With the driver working correctly, GNOME Wayland session functions normally with the NVIDIA dGPU. Select "Ubuntu on Wayland" at the GDM login screen. Three-finger gestures and pinch-to-zoom work on Wayland; they do not work on X11. Armoury Crate Control Service update</a> </h3> During troubleshooting, an update for Armoury Crate Control Service was applied via MyASUS on Windows. This service manages EC firmware and hardware control on ROG laptops. It may have patched EC behavior related to dGPU power state on warm reboot, and could be partially responsible for warm reboot stability alongside reboot=acpi</code>. If warm reboot GPU loss recurs on a fresh install, check for Armoury Crate updates in Windows before assuming the Linux fix is insufficient. What does NOT work</a> </h3> Global pcie_aspm=off</code> or pcie_port_pm=off</code> kernel parameters cause the GPU to disappear from the PCIe bus entirely and require a full power cycle to recover. Do not use these.</li> </ul> Document was generated by Claude.ai/Sonnet 4.6.

Essentials of Computer Architecture and Assembly 2026-03-01T00:00:00+00:00 This article simplifies/skips a lot of things. It is mainly intended to make picking up assembly easier. Also, this is a write up of what I have learned and understood over the course of reading CS:APP book and doing some assembly exercises on Windows. Note: This article is work in progress. I am filling the missing sections in my free time. </div> </blockquote> Introduction</a> </h1> This guide is a mix of topics from computer architecture, operating systems, and assembly programming. CPU</a> </h1> The CPU, or Central Processing Unit, is a unit of computer hardware that executes instructions. It is the "brain" of a computer system. However, it is not much clever as brain is. What it does is just to fetch next instruction, decode it, and execute it. That's it. This is called the fetch-execute cycle. In a simple model of single CPU which executes instructions sequentially, one at a time, the CPU mainly consists of small memory, decoder, and Arithmetic Logic Unit (ALU). It is also connected to an intermediary called System Bus which connects the CPU to the other components in a computer hardware. The ALU is the unit responsible for carrying operations like addition, subtraction, multiplication, etc. The memory of CPU, called register file (or just set of registers), is the set of fastest memory elements in computer hardware which are used for storing operation results, intermediate results, addresses, or any value that fits their capacity. Analogously, if we say a CPU is a person solving a math problem, then register file (the set of registers) is a collection of scratch papers. Below is a simplified diagram. Registers</a> </h1> We can talk a lot about registers. So, what is a register? A register is a storage with a fixed capacity (in bits). It just stores plain bits. There are mainly two types of CPU registers: General Purpose and Special Registers. General Purpose Registers (GPRs) are those we are given access to, while special registers are mostly limited to the usage by the CPU. One important register is called Program Counter (or instruction pointer). It stores the address of the next instruction. In x86-64 systems, registers typically have capacity of 64 bits. Due to historical reasons, in terms of access, they are "divided" into parts: lower 64-bit, lower 32-bit and lower 16-bit. The lower 16-bit itself has upper and lower bytes. This means we can use the upper byte or lower byte -- directly. In contrast, some GPRs do not have this support of directly using the upper byte of lower 16-bit. This division gives us the ability to access/use the specified portions of registers. In other words, we can directly access parts contained in the boxes (yes, boxes). Why is this due to historical reasons? As registers had lower capacity than 64-bit in the past, hardware manufacturers modernized the processors with backward-compatibility in mind so that old programs could run on newer processors. Note, this "division" is crucial -- since we quite often use them in assembly. Below is a diagram presenting some of registers in x64 (source</a>). Instruction Set Architecture</a> </h1> The next important element is ISA, or Instruction Set Architecture. For CPUs to be useful, they need to execute instructions. I define an instruction as a set of rules that specify which operations to carry on and on what operands. The ISA provides the set of such instructions the CPU can understand and execute. This provides us with a powerful abstraction over CPU. Also, it enables us to view the execution process as sequential, executing one instruction at a time. In reality, the modern CPUs are quite sophisticated and even support executing multiple instructions simultaneously. In conclusion, ISA is the asset for us to talk to the CPU. Main Memory</a> </h1> One may note that registers are quite small and not enough for large sizes of data our computers process on daily basis. Thus, we need a larger memory, and it is called the main memory. However, compared to registers, the access time to main memory is quite slow. This is a trade off. For now, we assume that the main memory is a very large array of bytes we can address and access. In fact, this is how our programs view the memory (moer about it later). Keep in mind this assumption as it is very important in assembly. Below is a diagram depicting the memory as Post Office boxes from the book Programming From Ground up. As you can note, each box has an address (or, an identifier/label) associated with it. One question arises: how do we address memory and how much can we have of memory? The answer is what the "X" means when we say "X-bit architecture". What "X" means in "X-bit architecture"</a> </h1> Looking at the organization of registers, one may note that X-bit system mainly has registers with capacity of X bits. In other words, X-bit system can handle X-bit sized data at once. Another meaning which follows from the size of registers is how many addresses we can have for our memory locations. Using basic counting from math, we can derive that 64-bit system can address 2^64 bytes of memory. Note, this is not bits, but bytes. This is because each memory location is one byte in capacity. In the analogy of Post Office Boxes, we can have 2^64 boxes with unique addresses and each having 1 byte of capacity. If you're confused about addresses and calculation, think of addresses as "labels" to locations. So, we can label 2^X memory locations, reuslting in memory as large as 2^X * capacity_of_single_location. Subsequently, with 32 bits we can have memory as large as 2^32 * 1 byte ~= 4GB while with 64 bits theoretically we can have 16 exabytes! Main memory vs. Secondary memory Main memory: smaller, faster, and volatile (data is lost when a system goes off). Secondary memory: larger, slower, and non-volatile (data persists). As you may have noticed, the smaller is the memory, the faster it is; the larger is the memory, the slower it is (in terms of access time). This is part of the memory hierarchy. The main memory can be in form of RAM, while secondary memory can be HDD, SSD, etc. </div> </blockquote> Our model so far... Intro to Assembly</a> </h1> Remember that the CPU's main task is to fetch, decode, and execute instructions. Reminding again, the ISA of each CPU provides instructions valid for that CPU. Now, how do we write those instructions for CPUs? As you may already know, CPUs only understand 0s and 1s, which is machine-language. Nothing more. Just bit patterns + context (with context, for example, numbers may denote letters). However, as humans, it could be burdensome to talk to CPUs in plain bits. Here, the Assembly language gives us one higher level of abstraction and makes writing instructions much more readable, essentially being a wrapper over the machine language. As our instructions are based on the ISA of our machine, assembly written for different ISAs is not the same, and incompatible. Therefore, assembly is machine-dependent. In this sense, we can call assembly a machine language to distinguish from higher level languages such as C which are much more machine independent. There are many variations of assembly language, differing in syntax and some features. However, the idea is the same: just write the instructions for the CPU. I am going to use NASM syntax. In the following sections, I write about the most essential assembly concepts, but without giving full program code. Just bare plain concepts. Movement operations</a> </h1> The main operands of instructions is data. One of the most common operations we do is data movement/copy/write/read. The instruction that copies data from one source to destination in assembly is called mov</code> with the following form: mov DATASIZE dest, src</code></pre> The operation copies bytes of amount specified using DATASIZE</code> from source src</code> to dest</code>. Although this definition covers all operand forms, we will see that there is subtlety in how the process looks like depending on operand forms (the operands are dest</code> and src</code>). Since we to specify data sizes and that they are very important in other instructions too, the following section presents some of the data sizes. Common data sizes</a> </h2> Name</th> Size</th> Size (bits)</th> NASM</th></tr></thead> byte</td> 1 byte</td> 8 bits</td> op byte</td></tr> word</td> 2 bytes</td> 16 bits</td> op word</td></tr> dword</td> 2 words</td> 32 bits</td> op dword</td></tr> qword (quad word)</td> 4 words</td> 64 bits</td> op qword</td></tr> </tbody></table> Example: mov dword dest, src</code></pre> This instructions reads 4 bytes of data from src</code> and write 4 bytes to dest</code>. Operand and instruction forms</a> </h2> In assembly, there are mainly three types of operands: register</li> immediate</li> address in the program memory</li> </ul> The instructions we write are: binary -- takes 2 operands</li> unary -- takes one operand</li> </ul> The mov</code> instruction is binary. Thus, its operands are the mix of three, with some combinations disallowed. The following is the table of usage patterns. Type</th> Form</th> Value in operation</th> Meaning</th> Explanation</th></tr></thead> Immediate</td> Imm</td> Imm</td> literal value</td> -</td></tr> Register</td> r</td> R[r]</td> Value stored in register r</code></td> -</td></tr> Mem</td> [Imm]</td> M[Imm]</td> Value stored at memory address Imm</code></td> -</td></tr> Mem</td> [r]</td> M[R[r]]</td> Value stored at memory address stored in r</code>.</td> The register r</code> stores a memory address as its value. Writing [r] means that r</code> stores memory address and instructs CPU to work on data stored in that address.</td></tr> Mem</td> [r1 + r2*k + Imm]</code></td> M[R[ r1 ] + R[ r2 ] * k + Imm]</code></td> This is arithmetic involving addresses.</td> This form presents generic form for calculating address and accessing value starting at it in memory. For example, setting k</code> and Imm</code> to 0</code>, we obtain the (2) form in the table.</td></tr> </tbody></table> The following are diagrams explaining behavior of mov</code> operation involving different operand forms. Immediate to register</a> </h3> Register to register</a> </h3> Description: copies value from src</code> register to dst</code> register (note the size specifier). Note: the red underline is not accidental. This is one of the special cases which is discussed later. Memory to register</a> </h3> Suppose we have the number 1324 in the memory locations shown in the image below. Such a signed integer is typically 4 bytes. 1324 in binary: 10100101100</li> </ul> To convert to hex, group the bits of the binary value by 4 from right to left and replace each group with hex equivalent. Fill in zeros from left when number of bits in a group is not 4. 0101 0010 1100 0x5 0x2 0xC => 1324 in hex: 0x52c</code></pre> Joining them by 1 byte groups: 00000101 00101100 0x5 0x2c</code></pre> Note: '0x' just denotes that the value is in hex. Note: You might have noticed little red asterisk. The sentence it is marking describes the behavior on one subtle case of mov</code> operation. This will be discussed later. Immediate to memory</a> </h3> Register to memory</a> </h3> Special cases</a> </h2> CMP/TEST operations</a> </h1> Coming soon. Conditions/FLAGS</a> </h1> Coming soon. Conditional branching: Intro to Jumps</a> </h1> Coming soon. From Source to Binary</a> </h2> Coming soon. Object File Structure</a> </h2> Back to Jumps</a> </h2> Conditional movement operations</a> </h1> Coming soon. Into to Stack</a> </h1> Coming soon. Hardware Manager: Operating System</a> </h2> Abstracting hardware: Process</a> </h2> Abstracting Memory: Virtual Address Space</a> </h2> Back to Stack</a> </h2> Some interesting things</a> </h1> Coming soon. Resources</a> </h1> Coming soon.

`What does NOT work</a> </h3> Global pcie_aspm=off</code> or pcie_port_pm=off</code> kernel parameters cause the GPU to disappear from the PCIe bus entirely and require a full power cycle to recover. Do not use these.</li> </ul> Document was generated by Claude.ai/Sonnet 4.6.</em></p>`

Into to Stack</a> </h1>
Coming soon.</em></p>
Hardware Manager: Operating System</a> </h2>
Abstracting hardware: Process </a> </h2>
</a> </h2>
Back to Stack </a> </h2>
Some interesting things </a> </h1>
Coming soon.</em></p>
Resources</a> </h1>
Coming soon.</em></p>

Hardware Manager: Operating System</a> </h2>
Abstracting hardware: Process </a> </h2>
</a> </h2>
Back to Stack </a> </h2>
Some interesting things </a> </h1>
Coming soon.</em></p>
Resources</a> </h1>
Coming soon.</em></p>

Abstracting hardware: Process </a> </h2>
</a> </h2>
Back to Stack </a> </h2>
Some interesting things </a> </h1>
Coming soon.</em></p>
Resources</a> </h1>
Coming soon.</em></p>

</a> </h2>
Back to Stack </a> </h2>
Some interesting things </a> </h1>
Coming soon.</em></p>
Resources</a> </h1>
Coming soon.</em></p>

Back to Stack </a> </h2>
Some interesting things </a> </h1>
Coming soon.</em></p>
Resources</a> </h1>
Coming soon.</em></p>

Some interesting things </a> </h1>
Coming soon.</em></p>
Resources</a> </h1>
Coming soon.</em></p>

Resources</a> </h1>
Coming soon.</em></p>

Writings

Fix on system freezes due to GPU problem on ASUS ROG Strix G513M

Essentials of Computer Architecture and Assembly

Writings

Fix on system freezes due to GPU problem on ASUS ROG Strix G513M

ASUS ROG Strix G513RM — Linux Freeze & GPU Fix</a> </h1> Hardware</a> </h2> Model:</strong> ASUS ROG Strix G513RM</li> CPU:</strong> AMD Ryzen (Rembrandt)</li> GPUs:</strong> AMD Radeon 680M (iGPU) + NVIDIA RTX 3060 Mobile (dGPU)</li>

Hardware</a> </h2> Model:</strong> ASUS ROG Strix G513RM</li> CPU:</strong> AMD Ryzen (Rembrandt)</li> GPUs:</strong> AMD Radeon 680M (iGPU) + NVIDIA RTX 3060 Mobile (dGPU)</li>

Essentials of Computer Architecture and Assembly