Re: Can not boot kernel from Mar 10 07:22 UTC

From: John Baldwin <jhb_at_freebsd.org>
Date: Fri, 10 Mar 2006 08:59:48 -0500
On Friday 10 March 2006 05:38, Peter Holm wrote:
> 
> GDB: no debug ports present
> KDB: debugger backends: ddb
> KDB: current backend: ddb
> Copyright (c) 1992-2006 The FreeBSD Project.
> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
> 	The Regents of the University of California. All rights reserved.
> FreeBSD 7.0-CURRENT #1: Fri Mar 10 08:43:30 CET 2006
>     pho_at_current.osted.lan:/usr/src/sys/i386/compile/PHO
> WARNING: WITNESS option enabled, expect reduced performance.
> ACPI APIC Table: <A M I  OEMAPIC >
> Timecounter "i8254" frequency 1193182 Hz quality 0
> CPU: Intel(R) Celeron(R) CPU 1.80GHz (1799.14-MHz 686-class CPU)
>   Origin = "GenuineIntel"  Id = 0xf13  Stepping = 3
>   Features=0x3febfbff<FPU,VME,DE,...,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM>
> real memory  = 267583488 (255 MB)
> avail memory = 252137472 (240 MB)
> :
> ad0: 76319MB <Seagate ST380011A 3.06> at ata0-master UDMA100
> acd0: DMA limited to UDMA33, controller found non-ATA66 cable
> acd0: CDROM <SONY CD-ROM CDU5261/C200SNS> at ata1-master UDMA33
> Trying to mount root from ufs:/dev/ad0s1a
> 
> 
> Fatal trap 12: page fault while in kernel mode
> cpuid = 0; apic id = 00
> fault virtual address	= 0x2
> fault code		= supervisor write, page not present
> instruction pointer	= 0x20:0xc07887f7
> stack pointer	        = 0x28:0xcbf617d4
> frame pointer	        = 0x28:0xcbf618bc
> 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		= 1 (swapper)
> [thread pid 1 tid 100007 ]
> Stopped at      ffs_balloc_ufs2+0x8f:   movl    $0,0(%edi)
> db> where
> Tracing pid 1 tid 100007 td 0xc21bd360
> ffs_balloc_ufs2(c23f3a28,0,0,0,cbf618f8) at ffs_balloc_ufs2+0x8f
> ufsdirhash_build(c23f9dec) at ufsdirhash_build+0x3c4
> ufs_lookup(cbf619f8,c23f3a28,cbf61c28,cbf61a34,c06b3af2) at ufs_lookup+0xf9
> VOP_CACHEDLOOKUP_APV(c093a3e0,cbf619f8) at VOP_CACHEDLOOKUP_APV+0x9b
> vfs_cache_lookup(cbf61a94,c23f3a28,0,cbf61ab0,c06b7ce6) at vfs_cache_lookup+0xb2
> VOP_LOOKUP_APV(c093a3e0,cbf61a94) at VOP_LOOKUP_APV+0x87
> lookup(cbf61c00,3,0,c21bd360,c068a77d) at lookup+0x402
> namei(cbf61c00,9,0,0,0) at namei+0x382
> do_execve(c21bd360,cbf61c90,0,cbf61c90,bfbffff2) at do_execve+0x159
> kern_execve(c21bd360,cbf61c90,0) at kern_execve+0x7c
> execve(c21bd360,cbf61cf0,bfbfffe4,bfbffff2,bfbfffe8,bfbffffd,...) at execve+0x2f
> start_init(0,cbf61d38) at start_init+0x20b
> fork_exit(c063bc9c,0,cbf61d38) at fork_exit+0xa4
> fork_trampoline() at fork_trampoline+0x8
> --- trap 0x1, eip = 0, esp = 0xcbf61d6c, ebp = 0 ---
> db> reset

Is there a missing frame or something?  It doesn't look like
ufsdirhash_build() ever calls UFS_BALLOC() (which would end up being
a call to ffs_balloc_ufs2()).

-- 
John Baldwin <jhb_at_FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org
Received on Sat Mar 11 2006 - 00:24:43 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:53 UTC