DragonFlyBSD

could you enter "trace" at the debugger prompt and paste the output (if you have to transcribe it manually, the function names should be enough for the beginning)?

cheers
simon

Hi,

here is the complete output of "trace":
---------------
db> trace
kernbase(1,c06ffacc,ff800000,a0b,50) at 0xc00eb647
_end(cb9d08c4,c4f6ec8b,81067540,ffffe5,e67f2400) at 0xc06ffa70
db>
---------------
Dirk
-----Ursprüngliche Nachricht-----
Von: DragonFly issue tracker <issues@chlamydia.fs.ei.tum.de>
Gesendet: 06.12.06 21:39:42
An: CCdrom@Web.de
Betreff: [issue397] Dragonfly 1.6 - Fatal trap 12

Simon 'corecode' Schubert <corecode@fs.ei.tum.de> added the comment:

could you enter "trace" at the debugger prompt and paste the output (if you have to transcribe it manually, the function names should be enough for the beginning)?

cheers
simon

----------
status: unread -> chatting

_______________________________________________
DragonFly issue tracker <issues@chlamydia.fs.ei.tum.de>
<http://bugs.dragonflybsd.org/issue397>
_______________________________________________

I got the very same problem, when i was trying to boot dragonfly 1.6
CD on my friend's laptop.
This is strange, because on mine it works without any problems.
(booting from the same disc)

Only difference is that when i boot with ACPI enabled, the system
"just hangs" (but this seems to be due to ACPI)
Vita

O ASCII Ribbon Campaign
/ \ -no HTML in e-mail
-no proprietary attachments in e-mail

this looks like BIOS code to me. for some reason it is mapped at 0xc00eb000, but %esi is (of course) 0xeb761. it is missing 0xc0000000 bytes :) maybe the bios needs to be mapped into a lower memory area?

cheers
simon

:Dirk König wrote:
:> Fatal trap 12: page fault while in kernel mode
:> fault virtual address = 0xeb761
:> fault code = supervisor read, page not present
:> instruction pointer = 0x8:0xc00eb647
:> stack pointer = 0x10:0xc0758a00
:> frame pointer = 0x10:0xc0758a00
:> code segment = base 0x0, limit 0xfffff, type 0x1b
:> = DPL 0, pres 1, def 32 1, gran 1
:> processor eflags = interrupt enabled, resume, IOPL = 0
:> current process = 0 (swapper)
:> current threat = pri 12
:>
:> kernel: type 12 trap, code=0
:> Stopped at 0xc00eb647: cmpb %cs:0x1(%esi),%bl
:
:this looks like BIOS code to me. for some reason it is mapped at 0xc00eb000, but %esi is (of course) 0xeb761. it is missing 0xc0000000 bytes :) maybe the bios needs to be mapped into a lower memory area?
:
:cheers
: simon

That is very odd.  It is the BIOS area.  When it makes a BIOS call the
    BIOS is limited to VM86 mode so it doesn't see the full pc, just the 
    16 bit version (and it runs segment-relative of course).

But the elfags and segment registers are not indicating that it was
    running in VM86 mode, so the kernel wasn't trying to run BIOS code
    at that time.

The failure is somewhere else and it would probably take some sleuthing
    on the kernel stack to find it.

-Matt
                    Matthew Dillon 
                    <dillon@backplane.com>

I have the latest System-Bios on my Laptop, there is no newer version available.

maybe the bios needs to be mapped into a lower memory area?

How could I do this ?

:Dirk König <CCdrom@Web.de> added the comment:
:
:I have the latest System-Bios on my Laptop, there is no newer version available.
:
:> maybe the bios needs to be mapped into a lower memory area?
:How could I do this ?
:

That has nothing to do with it.  The confusion is over the kernel's
    KVA representation of the BIOS.  The BIOS sees a VM86 segment address,
    not that high address.  It should be just fine.

I looked in the mail archives and didn't see a 'trace' from the DDB
    prompt.  That's the first step... we need to identify where it is
    crashing.

Then you need to test with and without ACPI, and if this is a SMP box
    then with and without SMP.

-Matt
                    Matthew Dillon 
                    <dillon@backplane.com>

Did this happen again? Did anyone else experience this? Can this be closed or is
it still relevant?

nobody seems to care anymore, it's 3 years old, no one has ever reported it again.
closing this.

Cheers,
Alex Hornung