Bug #2707
closed
physical memory corruption with intel gpu 4500HD
0%
Description
When running xorg, a memory corruption happens on the physical page at 0x80000000, leading to random crash depending on where the page is mapped.
Removing this page from the physical pool used by virtual memory makes the box stable.
Files
Updated by ftigeot over 10 years ago
Nobody apparently encountered this issue on Linux so far; the driver is more suspect than the GPU itself.
Some suggestions from danvet@
- tried the usual triage with disabling rendering and stuff?
- if that doesn't indicate anything then I'd dump gtt ptes for the suspect entry
- if that doesn't help grab a linux live distro, make sure it doesn't happen and then grab register dumps with intel_reg_dumper on both linux and bsd and compare
Updated by jorisgio over 10 years ago
- Related to Bug #2709: xorg crash with X86_64_GENERIC added
Updated by jorisgio over 10 years ago
- Related to Bug #2705: panic: assertion "pv->pv_m == p" in pmap_remove_pv_pte added
Updated by jorisgio over 10 years ago
- Related to deleted (Bug #2705: panic: assertion "pv->pv_m == p" in pmap_remove_pv_pte)
Updated by jorisgio over 10 years ago
- Related to Bug #2705: panic: assertion "pv->pv_m == p" in pmap_remove_pv_pte added
Updated by profmakx about 10 years ago
The reason for this is that we do not reserve memory in the IO memory rman on bootup. I have a patch for this, but it freezes the computer on boot at the moment, so it's useless as it is. It is basically a port from FreeBSD's nexus.c on amd64.
Updated by profmakx about 10 years ago
A potential fix is available in my git repository at http://gitweb.dragonflybsd.org/~profmakx/dragonfly.git/shortlog/refs/heads/fix-rman and it will soon go into -master.
Updated by profmakx almost 10 years ago
- Status changed from New to Feedback
This should have been fixed with 97d69dfd2be7514f21a7ff7979e44e17fbb3ddb and d69e20aa8bfb20a9eeee308c09cdf56b4076e12f
Updated by liweitianux over 5 years ago
- Status changed from Feedback to Resolved
Has been resolved by profmakx.