On 08/01/11 19:40, Otto Moerbeek wrote:
On Mon, Aug 01, 2011 at 05:49:29PM +0200, Elmar Bschorer wrote:

On 07/30/11 07:41, Philip Guenther wrote:
On Fri, Jul 29, 2011 at 2:58 AM, [B&G-Consulting] Elmar Bschorer
<[email protected]>   wrote:
I've just tried snapshot version (5.0beta - 27 Jul). I wanted to test bigmem
with qemu and kqemu.

When I tried to load the kqemu module (pkg_add
ftp://mirror/pub/OpenBSD/snapshots/packages/amd64/) my system freezes:

kqemu: kqemu version 0x000103000 loaded, max locked mem=2026212kB
uvm_fault(0xfffffe816acf0380, 0x0, 0, 1) ->   e
kernel: page fault trap, code=0
Stopped at namei+0x1c: movq 0x20(%r14),%rax
ddb{1}>

I set securitylevel to -1

Is this a bug or did I miss something?
Need dmesg?

Need trace and ps.  "show registers" would also be nice.

I uploaded ktrace and ps to:
http://www.bugconsulting.de/OpenBSD/
(it's too big to post)

show registers? don't know how to run that :-(
If you would give me a hint plz...

Philip wants the commands entered at the ddb prompt (the kernel debugger).

So enter trace, ps and show registers at that prompt and record the
output. See http://www.openbsd.org/report.html for some hints.

        -Otto

As I already mentioned in my first post - my systems freezes right away, when I try to load the module :-( therefore I cant run trace, ps, show registers etc :-(

Any other chance to get debug information? ktrace has already be done and can be downloaded.

To get things done... I could update to newest snapshot and try it again!?

Cheers
Elmar



Elmar


(We really should fix kernel page faults to go through panic(), so
that they get the same
---
RUN AT LEAST 'trace' AND 'ps' AND INCLUDE OUTPUT WHEN REPORTING THIS PANIC!
DO NOT EVEN BOTHER REPORTING THIS WITHOUT INCLUDING THAT INFORMATION!
---
message that other panics get.)

One possibility is that the nameidata structure that's passed to
namei() changed a few weeks ago as part of the addition of the *at()
functions, so if the call to that originated from inside the loaded
module then it has zero chance of working unless the package was built
against a system that was on the same side of the transition as the
kernel you're running.  That would be consistent with the fault you
show, though it could be other issues.


Philip Guenther

Reply via email to