`halt -p` causes error

[sw2wolf]

After `halt -p`, i get the following output:

intel drm0: gpu hung !
/etc/rc.shutdown in progress ...
/etc/rc.shutdown complete .
syncing disks ... done
uvm_fault(0xd0a047a0,0xd5b24000,0,1) -> e
kernel: page fault trap,aue=0 stopping at i915_gem_evict_inactive +0x2d:
   mov 0x6c(%ebx), %edx
ddb>

After rebooting the box, the system seems ok. What do those message mean ?

Thanks!

[jggimi]

A UVM is a region of virtual memory. See uvm(9), which includes a description of the fields in the uvm_fault message.

The "page fault trap" is typically caused by a request for a page of virtual memory (page fault) which is invalid. The kernel cannot continue operating, and panics with the message you see on screen.

The "ddb>" prompt comes from the ddb(4) kernel debugger, allowing you to obtain information such as a "trace" -- showing recent process flow of the kernel, and "ps", showing all processes and their states at the time of the panic.

Please see FAQ 2.4 on bug reporting -- a page fault trap is actually used in the example problem within.

Please see the crash(8) man page for information on how to understand what you can do to obtain more information for problem reporting, or even doing your own diagnostics.

[jggimi]

I noticed just now I didn't touch on this message:

intel drm0: gpu hung !

DRM refers to Direct Rendering Manager. A GPU is a Graphical Processing Unit. I assume that this message was produced by the intel(4) driver, or perhaps the drm(4) driver. As noted below, I don't have access to the source code at the moment to check.

---

As additional information, the "i915" referenced in the page fault trap panic message refers to an Intel Graphics Media Accelerator (GMA) family of chipsets used in embedded video on motherboards.

The "i915_gem_evict_inactive" is a symbol within driver source code. Googling just for that I discovered that there is a common page fault trap of doom produced by the Intel video drivers.

I don't have access to source code at the moment to be able to direct you to the specific module; download a 5.1-release tarball from <your local mirror>/pub/OpenBSD/5.1/xenocara.tar.gz if you are interested.

[sw2wolf]

thanks for all your information. I will study it later.

[jggimi]

Oops. The problem is not in an X11 driver, it is in the kernel. I searched the Xenocara code base and did not find the symbol. Of course. Had it been in X11, X would have crashed. The kernel crashed, and sure enough, the module making the bad virtual memory reference is sys/dev/pci/drm/i915_drv.c.

The kernel source code is in the same directory at your local mirror, in sys.tar.gz, if you'd like to take a look at it.

[jggimi]

There is the possibility that a fix is available with -current today, and will be part of 5.2-release, expected on or about 1 November 2012.

You could test this by installing or upgrading a -current snapshot. Be sure to back up your system, upgrades are one-way, you will not be able to downgrade.

revision 1.121
date: 2012/05/21 20:14:18;  author: kettenis;  state: Exp;  lines: +4 -1
Always clear out the inactive list and make sure everything is unbound in
i915_gem_idle().  If we don't do that we end up with stale entries on the
inactive list which will panic the kernel the next time we use the list.

Fixes restarting X on Sandy Bridge.

[sw2wolf]

I will wait for 5.2 release! thanks!