Bug #2707

physical memory corruption with intel gpu 4500HD

Added by jorisgio 3 months ago. Updated 2 months ago.

Status:NewStart date:08/09/2014
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:-
Target version:-

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.

0001-vm-exclude-the-physical-page-at-address-0x80000000.patch Magnifier (723 Bytes) jorisgio, 08/09/2014 07:39 AM

pciconf.txt Magnifier (5.52 KB) jorisgio, 08/09/2014 07:40 AM

dmesg.txt Magnifier (11.9 KB) jorisgio, 08/09/2014 07:40 AM


Related issues

Related to Bug #2709: xorg crash with X86_64_GENERIC Closed 08/13/2014
Related to Bug #2705: panic: assertion "pv->pv_m == p" in pmap_remove_pv_pte Closed 08/08/2014

History

#1 Updated by ftigeot 3 months 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

#2 Updated by jorisgio 3 months ago

  • Related to Bug #2709: xorg crash with X86_64_GENERIC added

#3 Updated by jorisgio 3 months ago

  • Related to Bug #2705: panic: assertion "pv->pv_m == p" in pmap_remove_pv_pte added

#4 Updated by jorisgio 3 months ago

  • Related to deleted (Bug #2705: panic: assertion "pv->pv_m == p" in pmap_remove_pv_pte)

#5 Updated by jorisgio 3 months ago

  • Related to Bug #2705: panic: assertion "pv->pv_m == p" in pmap_remove_pv_pte added

#6 Updated by profmakx 2 months 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.

#7 Updated by profmakx 2 months 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.

Also available in: Atom PDF