loga4m-log

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</h1>

Hardware</h2>

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

BIOS: G513RM.327 (latest available as of March 2026)</li> </ul>

Problem</h2>
Persistent system freezes across multiple Linux distros. Root cause was the NVIDIA dGPU producing PCIe BadTLP errors (Bad Transaction Layer Packets) — corrupted communication between CPU and GPU over the PCIe bus, caused by PCIe ASPM power management dropping the link into an unstable state.
Secondary symptom: on warm reboot (not cold boot), the dGPU would disappear entirely from the PCIe bus (lspci</code> returned nothing), requiring a full power cycle to recover.
Diagnosis</h2> Confirming BadTLP errors</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</h3> lspci | grep -i nvidia # Expected: 01:00.0 VGA compatible controller: NVIDIA Corporation GA106M [GeForce RTX 3060 Mobile]</code></pre> Fix</h2> Step 1: Enable NVIDIA Dynamic Power Management</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</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)</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</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</h2> Why warm reboot loses the GPU</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</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</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</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</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 warning </div> warning </div> 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> </div> Introduction</h1> This guide is a mix of topics from computer architecture, operating systems, and assembly programming. CPU</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</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</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</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"</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! info </div> Main memory vs. Secondary memory </div> 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> </div> Our model so far... Intro to Assembly</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</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</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</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</h3> Register to register</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</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</h3> Register to memory</h3> Special cases</h2> CMP/TEST operations</h1> Coming soon. Conditions/FLAGS</h1> Coming soon. Conditional branching: Intro to Jumps</h1> Coming soon. From Source to Binary</h2> Coming soon. Object File Structure</h2> Back to Jumps</h2> Conditional movement operations</h1> Coming soon. Into to Stack</h1> Coming soon. Hardware Manager: Operating System</h2> Abstracting hardware: Process</h2> Abstracting Memory: Virtual Address Space</h2> Back to Stack</h2> Some interesting things</h1> Coming soon. Resources</h1> Coming soon. Is your abstraction worth it? 2025-08-31T00:00:00+00:00 warning </div> warning </div> I would like you warn that this is somewhat lengthy post on my experience. </div> </div> Context</h3> Currently, I am working as a backend developer in our independent project. During the development process, I observed that some queries were quite repetitive. Then, I also had to write a dedicated filtering functionality that creates chained select statements for applying all filters at once. Again, such filters turned out to be repetitive, and I was thinking about utilizable functions. Furthermore, in our DB scheme, we have tables that have a multi-language field (and thus several of it for specific languages). So, it made the filtering somehow more complicated. As I had the mindset of "utilizable functions", or tooling, or just "as I see these queries repeat, I can create functions we can use in future too" mindset, I built a whole DB tooling. Examples of this tooling</h3> def query_scalars_with_attrs( *, model, session: Session, attrs_vals: dict[str, Any], base_s: Select | None = None, filter_type: QueryTypes = QueryTypes.FILTER_EQUAL, validate: bool = True, ) -> ScalarResult: """ A helper function that applies multiple attribute filtering and queries the resultant `Select`. """ ...</code></pre> This is a top-level function that abstracts applying filters and querying. Under the hood, well, it uses.... def query_scalars( *, model, session: Session, base_s: Select | None = None, validate: bool = True ) -> ScalarResult: """ A function to apply `scalars` query on a given base_s `Select`. """ ...</code></pre> .... another abstraction just for calling session.scalars</code>! Back to the first function. It only uses the second funtion at the end of its logic, after tasks like creating select statements are done. How does it make up select statements? Well, if you remember that its job is also filtering, it uses... def select_with_filter_multi_attr( *, model, attrs_vals: dict[str, Any], base_s: Select | None = None, filter_type: QueryTypes = QueryTypes.FILTER_EQUAL, validate: bool = True ) -> Select: """ A function to apply ORM filtering functions. An ORM filtering is detected based on 'filter_type'. """ ...</code></pre> ... just another abstraction! Now, what about these functions below: def orm_filter_eq_multi_attr( *, model, base_s: Select, attrs_vals: dict[str, Any], validate: bool = True ) -> Select: """ A function to apply FILTER EQUAL in SQL. ... """ ... def orm_ilike_multi_attr( *, model, base_s: Select, attrs_vals: dict[str, Any], validate: bool = True ) -> Select: """ A function to apply ILIKE in SQL, with '%value%' format. ... """ ...</code></pre> Cringe, yeah? By the way, there's also an alternative to select_with_filter_multi_attr</code> with support for multi-lingual query.... :) But, wait, are not they doing some work? How did I decide this all was "cringe"? Well... The reality</h3> Let's compare the functions and their alternatives in SQLAlchemy. # Ex1 # WITH the abstraction author = db_tools.query_scalars_with_attrs( model=User, attrs_vals={"public_id": author_public_id}, session=self.session, ).first() # WITHOUT the abstraction author = session.scalar( select(User).filter(User.public_id == author_public_id).limit(1) )</code></pre> A whole function just for literally a line of code (in fact). # Ex2 # WITH the abstraction query_result = db_tools.query_scalars_with_attrs( model=User, attrs_vals=attrs_vals, session=self.session, filter_type=QueryTypes.ILIKE, ).first() # WITHOUT query_result = session.scalar( select(User) .where(User.name.ilike(f"%{name}%")) .where(User.surname.ilike(f"{surname}")) )</code></pre> Quite elegant raw SQLAlchemy, yeah? Here is another example... # Ex3 # WITH the abstraction orm_s = db_tools.select_with_filter_multi_attr( model=Post, attrs_vals={ "for_students": self.filters.for_students }, base_s=orm_s ) # WITHOUT orm_s = select(Post).filter(Post.for_students == self.filters.for_students)</code></pre> ... This one was just nuclear, where one would become just speechless! Consider I wanted to be consistent in my query tooling. Then, with my abstraction, I would create another layer for other developers to learn my thing. Moreover, I would restrict everyone to what my functions did, what they accepted, etc. (If we want to be consistent.) As we see from the comparisons, the core technologies (in this case SQLAlchemy) already provide very good abstractions. Actually, I was very enthusiastic when was developing this tooling. Then, after such real comparison, I was just shocked --- I was doing all the work just to remove it. The real reality vs. expectation experience. The reason I looked back and questioned what I have created</h3> Before I compared my functions and the raw SQLAlchemy abstractions, I think the reason I looked back at my tooling was that the abstraction was rigid when I moved to implement a pagination functionality. Simply, extending the functions was too much change as, crystal clear from the previous sections, the functions depended on another one by hierarchy. So, this presented, "Wait, what I have done just? Is it worth?". Besides the arguments I made for removing, you can note that these functions did too much validation. It's just an overhead (well, even though I made the validation possible to turn off). But, was this really useless? I think no. For two reasons. Multi-lingual select and basic multi-attr select</h3> After the realization, I migrated to raw SQLAlchemy select/queries. I cut my abstractions down to the database tooling and isolated it from other modules. Afterward, I started working on the filtering system. When I was implementing filtering for multi-lingual fields, I realized that multi-lingual select abstraction was worth it. The reason is that manually writing raw SQLAlchemy would create boilerplate. We can do multi-lingual filter across languages and find the best matches. The abstraction exactly does that: it creates multiple select statements. The good part is that it can automatically check specific fields using a given "root" of these fields. If you want, you can specify priority language and also if the function should return a select statement for only that language. I admit that I could eliminate that multi-field search enforcing a rule that a client must always specify the language they intend, or otherwise set a default language. Actually, the filtering system that uses this abstraction does so when calling it. Who knows, maybe there will be use of this clever function. Anyways, the abstraction is now isolated at the DB tooling level. As for multi-attr select, I made its function signature start with "_</code>", implying it is not intended for an external use. It is used by multi-lingual select function. Although I can remove, I think it is for now good since it keeps the client function becoming too much lengthy. I left another abstraction too. First, it is used by the multi-attr select function. Second, I didn't change the usage as in the Ex2. comparison in The reality</a> section. It is just for now. Now, the next reason is... The lesson</h3> I was almost devastated after realizing that I have spent at least a day working on that tooling. I had completely been driven by it and never had questioned. So, it taught a really big lesson. Here are some insights: Question your abstractions. Repeating things does not always mean to create another abstraction.</li> Don't be too much driven by enthusiasm. Try to keep rationality.</li> If you are not sure, compare your abstraction with the alternative without it.</li> </ol> Happy that I had this lesson. Thanks for reading! Zola, Kita, Netlify & Cloudflare setup -- a couple of 'Why?'s 2025-08-17T00:00:00+00:00 Why Zola?</h2> Actually, there is no need to stress over Zola, since I just wanted a blog website. I tried to create the blog in Python/Flask (with templates). However, it comes with: Setting up a database</li> Database backups</li> Deployment problems</li> Choosing a server</li> etc.</li> </ul> This obviously creates many problems for just a simle blog. Then, I had come across Static Site Generators which turned out to be a game-changer. I had started with Jekyll</a> and spent some time learning it. It required setting up gems, ruby, and so on, though I truly respect the engineering behind it. I had dropped off this progress midway. When I discovered Zola, it was something I needed: Simple</li> Fast (built with Rust)</li> No assumptions about site structure</li> Tera (very similar to Jinja2, which i used in Flask templates)</li> Quick to setup</li> </ul> So, just picked it up. Kita?</h2> I have explored available themes</a> with focus on minimal themes. The best quick matches were Kita</a> and Serene</a>, and I've chosen Kita mainly for the following reasons: Minimal</li> Organized by tags and date</li> /tags</code> page replaces category complexity</li> Reader friendly: larger font, good colors, etc.</li> Quick to tweak</li> </ul> However, I should note that Kita may not be ideal for you since it makes some assumptions about structure. Still, you can adapt it because it runs on top of Zola, but you may need to spend some time on Kita's ecosystem. Netlify?</h2> Yeah, Github Pages could be used, but Netlify was way simpler than Github Actions: link your github repo, deploy, and add your own domain, that's all. Used Zola's Netlify setup</a> docs for netlify.toml</code> file. Cloudflare?</h2> I have had my domain already connected to Cloudflare when I was using Cloudflare tunneling</a> for exposing my development project to public (kinda cheating to premium tunneling tools like ngrok). So, it was just ready and I went with it. Set up is simple: Add Netlify's suggestions on custom domain settings1</a>: Update www CNAME</code> record to the netlify app URL</li> Add ALIAS, flattened CNAME, or (I forgot the name)</code>2</a> record with Netlify's own server (it was apex-load-bala...</code>)</li> </ul> </li> Wait for changes to propagate </li> </ol> ^{1 In your provider's (in my case Cloudflare) DNS Records settings </div> ^{2 Netlify says these two are more resilient than fallback options (in my case, was A record</code>) </div> Conclusion</h2> A simple blog with fast setup, no DB, and no deployment headaches. Respect for all engineers who made Netlify, GitHub, Cloudflare, and SSGs possible!}}

`Conclusion</h2> A simple blog with fast setup, no DB, and no deployment headaches. Respect for all engineers who made Netlify, GitHub, Cloudflare, and SSGs possible!</p>`

loga4m-log

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

ASUS ROG Strix G513RM — Linux Freeze & GPU Fix</h1>

Diagnosis</h2>

Fix</h2>

Notes</h2>

Wayland + NVIDIA</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.</p>

`What does NOT work</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>`

Essentials of Computer Architecture and Assembly

Register to register</h3>
Description:</strong> copies value from `src</code> register to dst</code> register (note the size specifier).</p>`
`</p>`
`Note:</strong> the red underline is not accidental. This is one of the special cases which is discussed later.</p>`

Register to memory</h3>

Special cases</h2>

CMP/TEST operations</h1>
Coming soon.</em></p>

Back to Jumps</h2>

Conditional movement operations</h1>
Coming soon.</em></p>

Abstracting hardware: Process</h2>

Abstracting Memory: Virtual Address Space</h2>

Back to Stack</h2>

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

Is your abstraction worth it?

Zola, Kita, Netlify & Cloudflare setup -- a couple of 'Why?'s

loga4m-log

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

ASUS ROG Strix G513RM — Linux Freeze & GPU Fix</h1>

Diagnosis</h2>

Fix</h2>

Notes</h2>

Wayland + NVIDIA</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.</p>

What does NOT work</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>

Essentials of Computer Architecture and Assembly

Register to register</h3> Description:</strong> copies value from src</code> register to dst</code> register (note the size specifier).</p> </p> Note:</strong> the red underline is not accidental. This is one of the special cases which is discussed later.</p>

Register to memory</h3>

Special cases</h2>

CMP/TEST operations</h1> Coming soon.</em></p>

Back to Jumps</h2>

Conditional movement operations</h1> Coming soon.</em></p>

Abstracting hardware: Process</h2>

Abstracting Memory: Virtual Address Space</h2>

Back to Stack</h2>

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

Is your abstraction worth it?

Zola, Kita, Netlify & Cloudflare setup -- a couple of 'Why?'s

Why Zola?</h2> Actually, there is no need to stress over Zola, since I just wanted a blog website. I tried to create the blog in Python/Flask (with templates). However, it comes with:</p>

Conclusion</h2> A simple blog with fast setup, no DB, and no deployment headaches. Respect for all engineers who made Netlify, GitHub, Cloudflare, and SSGs possible!</p>

Wayland + NVIDIA</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.</p>

`What does NOT work</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>`

Register to register</h3>
Description:</strong> copies value from `src</code> register to dst</code> register (note the size specifier).</p>`
`</p>`
`Note:</strong> the red underline is not accidental. This is one of the special cases which is discussed later.</p>`

CMP/TEST operations</h1>
Coming soon.</em></p>

Conditional movement operations</h1>
Coming soon.</em></p>

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

`Conclusion</h2> A simple blog with fast setup, no DB, and no deployment headaches. Respect for all engineers who made Netlify, GitHub, Cloudflare, and SSGs possible!</p>`