On Sun, Jun 16, 2002 at 07:41:21PM +0200, Oliver Lehmann wrote:
> On Sun, 16 Jun 2002 19:21:10 +0200
> Bernd Walter <ticso(at)cicely5.cicely.de> wrote:
>
>
> > Das geht mit DDB_BREAK_TO_DEBUGGER und CTRL-ALT-ESC auf der Console.
> > Der DDB, den du ja schon drin hast sollte dann einen Prompt liefern,
> > auf welchem du dann mit panic einen solchen incl. Crashdump auslöst.
>
> Sorry, aber wo steht das? ;)
>
> Nungut, hatte gerade beim erneuten make -j4 world wieder n absturz, und
> nun auch n dump...
>
>
> root(at)nudel olivleh1> cd /
> root(at)nudel /> gdb -k kernel /var/crash/vmcore.0
> GNU gdb 4.18 (FreeBSD)
> Copyright 1998 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you
> are
> welcome to change it and/or distribute copies of it under certain
> conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB. Type "show warranty" for
> details.
> This GDB was configured as "i386-unknown-freebsd"...
> (no debugging symbols found)...
> SMP 2 cpus
> IdlePTD at phsyical address 0x0038d000
> initial pcb at physical address 0x002f2060
> panicstr: from debugger
> panic messages:
> ---
> Fatal trap 12: page fault while in kernel mode
> mp_lock = 00000002; cpuid = 0; lapic.id = 00000000
> fault virtual address = 0xbfefa600
> fault code = supervisor read, page not present
> instruction pointer = 0x8:0xc027723b
> stack pointer = 0x10:0xcdd4cecc
> frame pointer = 0x10:0xcdd4cedc
> code segment = base 0x0, limit 0xfffff, type 0x1b
> = DPL 0, pres 1, def32 1, gran 1
> processor eflags = interrupt enabled, resume, IOPL = 0
> current process = 36476 (tsort)
> interrupt mask = net bio cam <- SMP: XXX
> panic: from debugger
> mp_lock = 00000004; cpuid = 0; lapic.id = 00000000
> boot() called on cpu#0
>
> syncing disks... 163 12 2 2 2 2 2 2 2 7
> done
> Uptime: 35m5s
[...]
> Kann ich jetzt davon ausgehen das es doch am ram liegt?
> Leider hab ich das alte compile dir vom kernel nicht mehr...
Bei derart unterschiedlichen Meldungen durchaus denkbar.
Einer der Gründe, warum ich hier fast keinen Rechner ohne ECC RAM oder
zumindestenz Parity habe.
Ein kaputter Prozessor ist auch nicht unmöglich.
AMD-k6 sind z.B. beliebt dafür kurzzeitige Übertemperatur dauerhaft
übelzunehmen - andere können aber selbstverständlich auch kaputgehen.
-- B.Walter COSMO-Project http://www.cosmo-project.de ticso(at)cicely.de Usergroup info(at)cosmo-project.de To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org with "unsubscribe de-bsd-questions" in the body of the messageReceived on Sun 16 Jun 2002 - 20:46:15 CEST