Date: Wed, 23 Sep 2009 17:02:24 +0200 (CEST) From: Alexander Best <alexbestms@math.uni-muenster.de> To: <freebsd-questions@FreeBSD.org> Subject: some issues with 9-CURRENT Message-ID: <permail-20090923150224f0889e8400002aa0-a_best01@message-id.uni-muenster.de>
next in thread | raw e-mail | index | archive | help
hi there,
i've stumbled over some issues running 9-CURRENT i386 (r197427) and would like
to ask if these are in fact problems/bugs or the way things are meant to work.
isssue 1:
when booting into single user mode / (dev/label/rootfs) gets mounted
read-only. when doing `fsck /dev/label/rootfs` problems can be solved because
fsck has write access to the drive due to it being mounted read-only.
however if i do `mount -r -o noatime /dev/label/usr /usr` and run `fsck
/dev/label/usr` fsck isn't able to gain write access.
issue 2:
after issueing the following commands in single user mode:
`mount -r -o noatime /dev/label/rootfs /usr`
`umount /usr`
`cd /usr && ls`
i got the following panic:
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address = 0xdeadc112
fault code = supervisor read, page not present
instruction pointer = 0x20:0xc05c4301
stack pointer = 0x28:0xe7e2f82c
frame pointer = 0x28:0xe7e2f854
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 = 29 (ls)
panic: from debugger
cpuid = 0
KDB: stack backtrace:
Uptime: 1m44s
Physical memory: 2034 MB
Dumping 74 MB: 59 43 27 11
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:245
#1 0xc063dc47 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:416
#2 0xc063e06c in panic (fmt=Could not find the frame base for "panic".
) at /usr/src/sys/kern/kern_shutdown.c:579
#3 0xc046e537 in db_panic (addr=Could not find the frame base for "db_panic".
) at /usr/src/sys/ddb/db_command.c:478
#4 0xc046e474 in db_command (last_cmdp=0xc093c5bc, cmd_table=0x0, dopager=1)
at /usr/src/sys/ddb/db_command.c:445
#5 0xc046e5a8 in db_command_loop () at /usr/src/sys/ddb/db_command.c:498
#6 0xc0470db2 in db_trap (type=12, code=0) at /usr/src/sys/ddb/db_main.c:229
#7 0xc067583e in kdb_trap (type=12, code=0, tf=0xe7e2f7ec) at
/usr/src/sys/kern/subr_kdb.c:535
#8 0xc084787f in trap_fatal (frame=0xe7e2f7ec, eva=3735929106) at
/usr/src/sys/i386/i386/trap.c:929
#9 0xc0847468 in trap_pfault (frame=0xe7e2f7ec, usermode=0, eva=3735929106)
at /usr/src/sys/i386/i386/trap.c:851
#10 0xc0846e2a in trap (frame=0xe7e2f7ec) at /usr/src/sys/i386/i386/trap.c:533
#11 0xc0821d8b in calltrap () at /usr/src/sys/i386/i386/exception.s:165
#12 0xc05c4301 in g_io_request (bp=0xc7e25688, cp=0xc7e2b780) at
/usr/src/sys/geom/geom_io.c:425
#13 0xc05cb165 in g_vfs_strategy (bo=0xc7b37a5c, bp=0xd94eaa54) at
/usr/src/sys/geom/geom_vfs.c:130
#14 0xc07c4516 in ffs_geom_strategy (bo=0xc7b37a5c, bp=0xd94eaa54) at
/usr/src/sys/ufs/ffs/ffs_vfsops.c:1954
#15 0xc07d731a in ufs_strategy (ap=0xe7e2f910) at
/usr/src/sys/ufs/ufs/ufs_vnops.c:2040
#16 0xc0858c78 in VOP_STRATEGY_APV (vop=0xc09249e0, a=0xe7e2f910) at
vnode_if.c:2171
#17 0xc06d706e in VOP_STRATEGY (vp=0xc7b376b8, bp=0xd94eaa54) at
vnode_if.h:940
#18 0xc06d6fff in bufstrategy (bo=0xc7b377ac, bp=0xd94eaa54) at
/usr/src/sys/kern/vfs_bio.c:3926
#19 0xc06cff97 in bstrategy (bp=0xd94eaa54) at buf.h:397
#20 0xc06d00b5 in breadn (vp=0xc7b376b8, blkno=0, size=2048, rablkno=0x0,
rabsize=0x0, cnt=0, cred=0x0, bpp=0xe7e2fa7c) at
/usr/src/sys/kern/vfs_bio.c:813
#21 0xc06cfd4c in bread (vp=0xc7b376b8, blkno=0, size=2048, cred=0x0,
bpp=0xe7e2fa7c) at /usr/src/sys/kern/vfs_bio.c:748
#22 0xc07c5449 in ffs_read (ap=0xe7e2fac4) at
/usr/src/sys/ufs/ffs/ffs_vnops.c:526
#23 0xc0856a34 in VOP_READ_APV (vop=0xc09244e0, a=0xe7e2fac4) at
vnode_if.c:887
#24 0xc07d70ea in VOP_READ (vp=0xc7b376b8, uio=0xe7e2fbf4, ioflag=0,
cred=0xc7558480) at vnode_if.h:384
#25 0xc07d6da1 in ufs_readdir (ap=0xe7e2fbb4) at
/usr/src/sys/ufs/ufs/ufs_vnops.c:1903
#26 0xc0858224 in VOP_READDIR_APV (vop=0xc09249e0, a=0xe7e2fbb4) at
vnode_if.c:1737
#27 0xc06fdfe6 in VOP_READDIR (vp=0xc7b376b8, uio=0xe7e2fbf4, cred=0xc7558480,
eofflag=0xe7e2fc28, ncookies=0x0, cookies=0x0) at vnode_if.h:758
#28 0xc06fde0b in kern_getdirentries (td=0xc7eff690, fd=5, buf=0x28218000
<Address 0x28218000 out of bounds>, count=4096, basep=0xe7e2fc64) at
/usr/src/sys/kern/vfs_syscalls.c:4103
#29 0xc06fdbf6 in getdirentries (td=0xc7eff690, uap=0xe7e2fce8) at
/usr/src/sys/kern/vfs_syscalls.c:4051
#30 0xc0847d06 in syscall (frame=0xe7e2fd38) at
/usr/src/sys/i386/i386/trap.c:1078
#31 0xc0821df0 in Xint0x80_syscall () at
/usr/src/sys/i386/i386/exception.s:261
#32 0x00000033 in ?? ()
Previous frame inner to this frame (corrupt stack?)
issue 3:
is it normal that fsck in background mode is ~ 400 % slower than in foreground
mode? running fsck in single user mode takes ~ 4 minutes. if however the fs is
marked dirty and get's fsck'ed in the background running multi user mode
fsck'ing takes ~ 20 minutes. this is of course without any hdd or cpu
intensive apps running.
thx for reading.
alex
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?permail-20090923150224f0889e8400002aa0-a_best01>