Re: Panic - ffs_valloc: dup alloc
For what (little :-) ) it's worth, I got bit by this too. Ultimately it boils down to the problem that once the on-disk file system is sufficiently broken, the journal doesn't have enough information for fsck to even detect the problem, much less fix it. (In my case the problem most likely was created by a bad bit in RAM. That particular hardware has no ECC.) It seems to me that certain UFS panics (including "dup alloc", which was the one getting me too if I remember right) should poison the journal to force a full fsck. This won't necessarily solve everything, but it would at least carry the problem detection forward from the kernel into fsck... Chris ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Panic - ffs_valloc: dup alloc
On Sat, 10 Aug 2013, Adrian Chadd wrote: On 10 August 2013 19:19, AN wrote: Hi All: I am having a major problem on current at the moment, and I could really use some help. I am at R253966 on amd64, my problem is the machine is panicing with: ffs_valloc: dup alloc I have booted into single user mode and run fsck, it reports that it has fixed the file system but I still am getting the panic. I did an svn update to 254204 and tried to buildworld and the machine panics and reboots. If I try startx the machine reboots with no message on the console. Please let me know what info to provide to troubleshoot this. Any help is greatly appreciated. Have you run it twice, so it definitely doesn't use the journal? -adrian Hi Adrian: Thanks for replying. Yes, I rebooted to single user mode and did a full fsck _without_ using the journal, it found some problems and fixed them. I rebooted and am now rebuilding world. It seems to be working now. If I have any more problems I'll report back. Thanks for the response and info. Cheers! Andy ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Panic - ffs_valloc: dup alloc
On 10 August 2013 19:19, AN wrote: > Hi All: > > I am having a major problem on current at the moment, and I could really use > some help. I am at R253966 on amd64, my problem is the machine is panicing > with: ffs_valloc: dup alloc > > I have booted into single user mode and run fsck, it reports that it has > fixed the file system but I still am getting the panic. I did an svn update > to 254204 and tried to buildworld and the machine panics and reboots. If I > try startx the machine reboots with no message on the console. Please let > me know what info to provide to troubleshoot this. Any help is greatly > appreciated. Have you run it twice, so it definitely doesn't use the journal? -adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Panic - ffs_valloc: dup alloc
Hi All: I am having a major problem on current at the moment, and I could really use some help. I am at R253966 on amd64, my problem is the machine is panicing with: ffs_valloc: dup alloc I have booted into single user mode and run fsck, it reports that it has fixed the file system but I still am getting the panic. I did an svn update to 254204 and tried to buildworld and the machine panics and reboots. If I try startx the machine reboots with no message on the console. Please let me know what info to provide to troubleshoot this. Any help is greatly appreciated. Thanks in advance. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: PANIC: "ffs_valloc: dup alloc" on boot
That's ok, a more aggressive fsck-from-a-rescue-disk strategy managed to clean things up. J Anderson On 6 October 2011 15:58, Benjamin Kaduk wrote: > On Thu, 6 Oct 2011, Jonathan Anderson wrote: > >> On 5 October 2011 23:50, Jonathan Anderson wrote: >>> >>> I was about to upgrade my build VM from BETA2 to BETA3, but I can't >>> seem to boot BETA2 any more: I get a "ffs_valloc: dup alloc" panic on >>> boot, every time. fsck runs and says, "ok, I've cleaned things up for >>> you", but then later on, when trying to update motd, FFS dies. >> >> Here are two screenshots: fsck succeeding and the relevant backtrace. > > Mailman seems to have stripped them. > > -Ben Kaduk > -- Jonathan Anderson jonat...@freebsd.org http://freebsd.org/~jonathan/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: PANIC: "ffs_valloc: dup alloc" on boot
On 5 October 2011 23:50, Jonathan Anderson wrote: > I was about to upgrade my build VM from BETA2 to BETA3, but I can't > seem to boot BETA2 any more: I get a "ffs_valloc: dup alloc" panic on > boot, every time. fsck runs and says, "ok, I've cleaned things up for > you", but then later on, when trying to update motd, FFS dies. Here are two screenshots: fsck succeeding and the relevant backtrace. Jon -- Jonathan Anderson jonat...@freebsd.org http://freebsd.org/~jonathan/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
PANIC: "ffs_valloc: dup alloc" on boot
I was about to upgrade my build VM from BETA2 to BETA3, but I can't seem to boot BETA2 any more: I get a "ffs_valloc: dup alloc" panic on boot, every time. fsck runs and says, "ok, I've cleaned things up for you", but then later on, when trying to update motd, FFS dies. Unfortunately, this is the VM that I normally use to run kgdb against other VMs, so my normal debugging setup does not apply. I'll see if this hotel will let me download an ISO so that I can install a fresh VM for debugging... Jon -- Jonathan Anderson jonat...@freebsd.org http://freebsd.org/~jonathan/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic: ffs_valloc: dup alloc
On 02Aug11 08:08, Callum Gibson wrote: }I have an i386 -current from late Jul 18 which is running in VirtualBox }(on 8.X amd64 host). After a VM reset I seem to have hit a SUJ-related issue. }On boot the system produced a "panic: ffs_valloc: dup alloc". Stack trace }below (sorry had to do this as a screenshot - I don't know if you can dump }text any other way): Someone just let me know there is a cache setting in VirtualBox's storage configuration which I probably need to unset called "use host I/O cache". I think this is the cause of the issue. Sorry for the noise. C -- Callum Gibson @ home http://members.optusnet.com.au/callumgibson/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
panic: ffs_valloc: dup alloc
Hi, I have an i386 -current from late Jul 18 which is running in VirtualBox (on 8.X amd64 host). After a VM reset I seem to have hit a SUJ-related issue. On boot the system produced a "panic: ffs_valloc: dup alloc". Stack trace below (sorry had to do this as a screenshot - I don't know if you can dump text any other way): I took a snapshot with it sitting in DDB but I'm not sure what other information would be helpful to the FS-meisters. I can even make the whole snapshot available if someone wants it if you let me know which bits and pieces are required from the .VirtualBox directory. I booted into single user to fsck / and asked to use the journal and it found no issues. Them ee-fscking without using the journal found an unref file and some other errors. After that the system could boot normally. C -- Callum Gibson @ home http://members.optusnet.com.au/callumgibson/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
-current panic: ffs_valloc: dup alloc
Hi,
On a newly installed 20030729-CURRENT system, the system panic'd
during a pkg_add. Note the mode/inum/fs at the end of the Fetch line.
# pkg_add -r zsh
Fetching
ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-current/Latest/zsh.tbz...mode =
0177560, inum = 48, fs
= /var
panic: ffs_valloc: dup alloc
Debugger("panic")
Stopped at Debugger+0x54: xchgl %ebx,in_Debugger.0
db> t
Debugger(c052dc4b,c05f0440,c053fc70,e6a22888,100) at Debugger+0x54
panic(c053fc70,ff70,30,cb1438d4,8124) at panic+0xd5
ffs_valloc(cb3f37fc,8124,cb285c80,e6a228e0,40) at ffs_valloc+0x175
ufs_makeinode(8124,cb3f37fc,e6a22bec,e6a22c00,a02) at ufs_makeinode+0x69
ufs_create(e6a22a68,e6a22b24,c039115e,e6a22a68,e6a22a64) at ufs_create+0x39
ufs_vnoperate(e6a22a68,e6a22a64,2,0,caa87d10) at ufs_vnoperate+0x18
vn_open_cred(e6a22bd8,e6a22cd8,124,cb285c80,4) at vn_open_cred+0x19e
vn_open(e6a22bd8,e6a22cd8,124,4,c05f3810) at vn_open+0x30
kern_open(caa87d10,80de050,0,a02,124) at kern_open+0x144
open(caa87d10,e6a22d10,c0548bdf,3ee,3) at open+0x30
syscall(2f,2f,2f,80de060,a01) at syscall+0x273
Xint0x80_syscall() at Xint0x80_syscall+0x1d
--- syscall (5, FreeBSD ELF32, open), eip = 0x80623bf, esp = 0xbfbff9cc, ebp =
0xbfbffbb8 ---
I have the system on a serial console, so if I can provide any useful info
in the next few hours please let me know. dual xeon/4G/Generic kernel/all
disks on aac0.
Thanks!
-John
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: panic: ffs_valloc: dup alloc (with bt + contents of some structures)
On Thu, 29 Aug 2002 12:05:25 +0200,
Alexander Leidinger <[EMAIL PROTECTED]> said:
Alexander> After booting the system up xdm didn't showed up and there was no
Alexander> possibility to login on the console, so I breaked into ddb and send a
Alexander> "kill 1" to xdm. Nothing happened so I again breaked into ddb and did a
Alexander> "kill 1 1". Nothing happened again, so I decided to do a +
Alexander> (several times) -> boom.
Alexander> ---snip---
Alexander> panic: ffs_valloc: dup alloc
Alexander> panic: from debugger
Alexander> Uptime: 4m9s
Alexander> pfs_vncache_unload(): 1 entries remaining
Alexander> [...]
Alexander> #7 0xc025573c in kdb_trap (type=3, code=0, regs=0xd1d707cc)
Alexander> at ../../../i386/i386/db_interface.c:161
Alexander> #8 0xc0262e8a in trap (frame=
Alexander> {tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = -1033800768, tf_esi =
256, tf_ebp = -774436848, tf_isp = -774436872, tf_ebx = 0, tf_edx = -1071016644,
tf_ecx = -1070913265, tf_eax = -1070913281, tf_trapno = 3, tf_err = 0, tf_eip =
-1071293992, tf_cs = 8, tf_eflags = 582, tf_esp = -1070958431, tf_ss = -774436824})
Alexander> at ../../../i386/i386/trap.c:606
Alexander> #9 0xc02569f8 in calltrap () at {standard input}:98
Alexander> #10 0xc019ae06 in panic (fmt=0x0) at ../../../kern/kern_shutdown.c:480
Alexander> #11 0xc020be9b in ffs_valloc () at ../../../ufs/ffs/ffs_alloc.c:871
(snip)
I can reproduce that panic by extracting an archive of the Solaris
source code (74.5MB approximately) into a filesystem on a swap-backed
md(4) with softupdates. Except that the caller of ffs_valloc() is
usually ufs_mkdir() in my case, ffs_nodealloccg() sometimes returns an
inode with a nonzero i_mode.
A filesystem without softupdates produces no panics, with or without
async.
--
Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
panic: ffs_valloc: dup alloc (with bt + contents of some structures)
Hi,
-current as of around "Mon Aug 26 18:39:00 CEST".
After booting the system up xdm didn't showed up and there was no
possibility to login on the console, so I breaked into ddb and send a
"kill 1" to xdm. Nothing happened so I again breaked into ddb and did a
"kill 1 1". Nothing happened again, so I decided to do a +
(several times) -> boom.
---snip---
panic: ffs_valloc: dup alloc
panic: from debugger
Uptime: 4m9s
pfs_vncache_unload(): 1 entries remaining
[...]
#7 0xc025573c in kdb_trap (type=3, code=0, regs=0xd1d707cc)
at ../../../i386/i386/db_interface.c:161
#8 0xc0262e8a in trap (frame=
{tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = -1033800768, tf_esi = 256, tf_ebp
= -774436848, tf_isp = -774436872, tf_ebx = 0, tf_edx = -1071016644, tf_ecx =
-1070913265, tf_eax = -1070913281, tf_trapno = 3, tf_err = 0, tf_eip = -1071293992,
tf_cs = 8, tf_eflags = 582, tf_esp = -1070958431, tf_ss = -774436824})
at ../../../i386/i386/trap.c:606
#9 0xc02569f8 in calltrap () at {standard input}:98
#10 0xc019ae06 in panic (fmt=0x0) at ../../../kern/kern_shutdown.c:480
#11 0xc020be9b in ffs_valloc () at ../../../ufs/ffs/ffs_alloc.c:871
#12 0xc022bff6 in ufs_makeinode (mode=33200, dvp=0xc27af818, vpp=0xd1d70c14,
cnp=0xd1d70c28) at ../../../ufs/ufs/ufs_vnops.c:2333
#13 0xc02293bc in ufs_create (ap=0xd1d70a6c)
at ../../../ufs/ufs/ufs_vnops.c:197
#14 0xc022c3bb in ufs_vnoperate (ap=0x1) at ../../../ufs/ufs/ufs_vnops.c:2770
#15 0xc01de2ea in vn_open_cred (ndp=0xd1d70c00, flagp=0xd1d70b64, cmode=432,
cred=0xc2c0f500) at vnode_if.h:114
#16 0xc01de168 in vn_open (ndp=0x104, flagp=0xd1d70b64, cmode=432)
at ../../../kern/vfs_vnops.c:91
#17 0xc01d95a3 in open (td=0xc26173c0, uap=0xd1d70d14)
at ../../../kern/vfs_syscalls.c:641
#18 0xc0263873 in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 136207248, tf_esi = 132, tf_ebp =
136207912, tf_isp = -774435468, tf_ebx = 673750516, tf_edx = 25, tf_ecx = 0, tf_eax =
5, tf_trapno = 0, tf_err = 2, tf_eip = 674051851, tf_cs = 31, tf_eflags = 518, tf_esp
= 136207164, tf_ss = 47}) at ../../../i386/i386/trap.c:1051
#19 0xc0256a4d in Xint0x80_syscall () at {standard input}:140
(kgdb) up 12
(kgdb) list
2328#endif
2329*vpp = NULL;
2330if ((mode & IFMT) == 0)
2331mode |= IFREG;
2332
2333error = UFS_VALLOC(dvp, mode, cnp->cn_cred, &tvp);
2334if (error)
2335return (error);
2336ip = VTOI(tvp);
2337ip->i_gid = pdir->i_gid;
(kgdb) print *dvp
$2 = {v_interlock = {mtx_object = {lo_class = 0xc02f6400,
lo_name = 0xc029f49b "vnode interlock",
lo_type = 0xc029f49b "vnode interlock", lo_flags = 196608, lo_list = {
tqe_next = 0x0, tqe_prev = 0x0}, lo_witness = 0x0}, mtx_lock = 4,
mtx_recurse = 0, mtx_blocked = {tqh_first = 0x0, tqh_last = 0xc27af83c},
mtx_contested = {le_next = 0x0, le_prev = 0x0}, mtx_acqtime = 0,
mtx_filename = 0x0, mtx_lineno = 0}, v_iflag = 512, v_usecount = 1,
v_writecount = 0, v_numoutput = 0, v_vxproc = 0x0, v_holdcnt = 2,
v_vflag = 9, v_id = 74, v_mount = 0xc260b600, v_op = 0xc261ba00,
v_freelist = {tqe_next = 0x0, tqe_prev = 0xc26fd2bc}, v_nmntvnodes = {
tqe_next = 0xc27af6f0, tqe_prev = 0xc260b618}, v_cleanblkhd = {
tqh_first = 0x0, tqh_last = 0xc27af894}, v_cleanblkroot = 0x0,
v_dirtyblkhd = {tqh_first = 0xc7775f58, tqh_last = 0xc7775fe4},
v_dirtyblkroot = 0xc7775f58, v_synclist = {le_next = 0x0,
le_prev = 0xc261f0d8}, v_type = VDIR, v_un = {vu_mountedhere = 0x0,
vu_socket = 0x0, vu_spec = {vu_specinfo = 0x0, vu_specnext = {
sle_next = 0x0}}, vu_fifoinfo = 0x0}, v_lastw = 0, v_cstart = 0,
v_lasta = 0, v_clen = 0, v_object = 0xc08386a4, v_lock = {
lk_interlock = 0xc031a4fc, lk_flags = 1088, lk_sharecount = 0,
lk_waitcount = 0, lk_exclusivecount = 1, lk_prio = 72,
lk_wmesg = 0xc02aa4b7 "inode", lk_timo = 6, lk_lockholder = 368},
v_vnlock = 0xc27af8e0, v_tag = VT_UFS, v_data = 0xc27acc00, v_cache_src = {
lh_first = 0xc2c27700}, v_cache_dst = {tqh_first = 0x0,
tqh_last = 0xc27af910}, v_dd = 0xc27af818, v_ddid = 0, v_pollinfo = 0x0,
v_label = {l_flags = 0, l_perpolicy = {{l_ptr = 0x0, l_long = 0}, {
l_ptr = 0x0, l_long = 0}, {l_ptr = 0x0, l_long = 0}, {l_ptr = 0x0,
l_long = 0}}}, v_cachedfs = 24322, v_cachedid = 2}
(kgdb) print mode
$3 = 33200
(kgdb) print *cnp
$5 = {cn_nameiop = 1, cn_flags = 52236, cn_thread = 0xc26173c0,
cn_cred = 0xc2c0f500, cn_pnbuf = 0xc2c28000 "/tmp/uthread.dump.368.132",
cn_nameptr = 0xc2c28005 "uthread.dump.368.132", cn_namelen = 20,
cn_consume = 0}
(kgdb) print *cnp->cn_cred
$6 = {cr_ref = 5, cr_uid = 88, cr_ruid = 88, cr_svuid = 88, cr_ngroups = 2,
cr_groups = {88, 88, 0 }, cr_rgid = 88, cr_svgid = 88,
cr_uidinfo = 0xc25eb900, cr
Re: panic: ffs_valloc: dup alloc
: :Hi, : :-current from Sep 23. : :After a hard power off (because the system hung while switching from X :to a virtual console) I got a panic while rebooting (background fsck :enabled): Disable background fsck. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
panic: ffs_valloc: dup alloc
Hi,
-current from Sep 23.
After a hard power off (because the system hung while switching from X
to a virtual console) I got a panic while rebooting (background fsck
enabled):
---snip---
IdlePTD 4775936
initial pcb at 2bdf00
panicstr: from debugger
panic messages:
---
panic: ffs_valloc: dup alloc
panic: from debugger
Uptime: 46s
[...]
#0 dumpsys () at ../../../kern/kern_shutdown.c:488
488 if (!dodump)
(kgdb) bt
#0 dumpsys () at ../../../kern/kern_shutdown.c:488
#1 0xc0190315 in boot (howto=260) at ../../../kern/kern_shutdown.c:331
#2 0xc019073a in panic (fmt=0xc025af1e "from debugger")
at ../../../kern/kern_shutdown.c:628
#3 0xc0131311 in db_panic (addr=-1071463363, have_addr=0, count=-1,
modif=0xd1128650 "") at ../../../ddb/db_command.c:443
#4 0xc01312b0 in db_command (last_cmdp=0xc02972a4, cmd_table=0xc02970e4,
aux_cmd_tablep=0xc0290ef8, aux_cmd_tablep_end=0xc0290efc)
at ../../../ddb/db_command.c:341
#5 0xc013137b in db_command_loop () at ../../../ddb/db_command.c:465
#6 0xc0133683 in db_trap (type=3, code=0) at ../../../ddb/db_trap.c:72
#7 0xc022c1c8 in kdb_trap (type=3, code=0, regs=0xd1128744)
at ../../../i386/i386/db_interface.c:167
#8 0xc02391d0 in trap (frame={tf_fs = 24, tf_es = 16, tf_ds = 16,
tf_edi = 256, tf_esi = -1071139455, tf_ebp = -787314800,
tf_isp = -787314832, tf_ebx = 514, tf_edx = -1072983408, tf_ecx = 32,
tf_eax = 18, tf_trapno = 3, tf_err = 0, tf_eip = -1071463363, tf_cs = 8,
tf_eflags = 70, tf_esp = -1071094177, tf_ss = -1071181765})
at ../../../i386/i386/trap.c:565
#9 0xc022c43d in Debugger (msg=0xc027103b "panic") at machine/cpufunc.h:63
#10 0xc0190731 in panic (fmt=0xc027b581 "ffs_valloc: dup alloc")
at ../../../kern/kern_shutdown.c:617
#11 0xc01efd2e in ffs_valloc (pvp=0xd0675680, mode=33024, cred=0xc0e60c00,
vpp=0xd11287fc) at ../../../ufs/ffs/ffs_alloc.c:624
#12 0xc0208143 in ufs_makeinode (mode=33024, dvp=0xd0675680, vpp=0xd1128a7c,
cnp=0xd1128a90) at ../../../ufs/ufs/ufs_vnops.c:2246
#13 0xc0205993 in ufs_create (ap=0xd11289e8)
at ../../../ufs/ufs/ufs_vnops.c:199
#14 0xc02084a4 in ufs_vnoperate (ap=0xd11289e8)
at ../../../ufs/ufs/ufs_vnops.c:2640
#15 0xc01f4177 in ffs_snapshot (mp=0xc186e800,
snapfile=0x80b3680 "/big/.fsck_snapshot") at vnode_if.h:90
#16 0xc01fcfa8 in ffs_mount (mp=0xc186e800, path=0xc19d4d80 "/big",
data=0xbfbffc98 "\2006\013\b%x\005\b\030;\013\b\035", ndp=0xd1128c1c,
td=0xd10eb404) at ../../../ufs/ffs/ffs_vfsops.c:282
#17 0xc01c84a6 in vfs_mount (td=0xd10eb404, fstype=0xc18f4e80 "ffs",
fspath=0xc19d4d80 "/big", fsflags=0, fsdata=0xbfbffc98)
at ../../../kern/vfs_syscalls.c:346
#18 0xc01c7e77 in mount (td=0xd10eb404, uap=0xd1128d20)
at ../../../kern/vfs_syscalls.c:139
#19 0xc0239c78 in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
tf_edi = 134967884, tf_esi = 134952576, tf_ebp = -1077936888,
tf_isp = -787313292, tf_ebx = 134967974, tf_edx = 134967808,
tf_ecx = -1077937324, tf_eax = 21, tf_trapno = 12, tf_err = 2,
tf_eip = 134559072, tf_cs = 31, tf_eflags = 518, tf_esp = -1077937172,
tf_ss = 47}) at ../../../i386/i386/trap.c:1122
#20 0xc022d26d in syscall_with_err_pushed ()
#21 0x804c409 in ?? ()
#22 0x8048133 in ?? ()
---snip---
Bye,
Alexander.
--
Actually, Microsoft is sort of a mixture between the Borg and the Ferengi.
http://www.Leidinger.net Alexander @ Leidinger.net
GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: can't get into single user mode - panic: ffs_valloc: dup alloc
On 10 Oct, Michael Lucas wrote: >> > > I hit the space bar, type in 'boot -s' and it goes through all the >> > > normal start up procedures, sets up the networking, etc ... >> >> 'boot -s' don't work for me, I use 'boot /boot/kernel/kernel -s' instead. > > You're right. It's off to doc-land for this, I suppose. No, it was a bug in /boot/loader.4th(?) and it's fixed since 1-2 days. You are reading your cvs-all mail? Bye, Alexander. -- If Bill Gates had a dime for every time a Windows box crashed... ...Oh, wait a minute, he already does. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = 7423 F3E6 3A7E B334 A9CC B10A 1F5F 130A A638 6E7E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: can't get into single user mode - panic: ffs_valloc: dup alloc
On Tue, Oct 10, 2000 at 09:50:05PM +0400, Igor Timkin wrote: > > > I hit the space bar, type in 'boot -s' and it goes through all the > > > normal start up procedures, sets up the networking, etc ... > > 'boot -s' don't work for me, I use 'boot /boot/kernel/kernel -s' instead. You're right. It's off to doc-land for this, I suppose. Although shouldn't BOOT_SINGLE still work? ==ml -- Michael Lucas [EMAIL PROTECTED] http://www.blackhelicopters.org/~mwlucas/ Big Scary Daemons: http://www.oreillynet.com/pub/q/Big_Scary_Daemons To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: can't get into single user mode - panic: ffs_valloc: dup alloc
On Tue, Oct 10, 2000 at 01:22:55PM -0400, Michael Lucas wrote: > I'm experiencing this on a -current from sources supped on Oct 03. > > turtledawn~;uname -a > FreeBSD turtledawn.blackhelicopters.org 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Tue Oct >3 10:58:59 EDT 2000 >[EMAIL PROTECTED]:/usr/obj/usr/src/sys/TURTLEDAWN i386 > turtledawn~; Here: FreeBSD fonix.hos.u-szeged.hu 5.0-CURRENT FreeBSD 5.0-CURRENT #23: Tue Oct 10 13 :05:58 CEST 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/FONIX i386 and I have just checked (by rebooting) that 'boot -s' indeed works. > System is a Toshiba Satellite 2210 CDT. More info on request. OK, so this is a laptop, right? Mine is a desktop machine. May be relevant or maybe not. Another datapoint: I always do a full make world before building a new kernel (because I only need a new kernel at that time.) Maybe you should try with recent sources? (Well, I had to upgrade anyway, because I got a cool panic on each shutdown due to an ufs_extattr related bug that was fixed today... -- Regards: Szilveszter ADAM Szeged University Szeged Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: can't get into single user mode - panic: ffs_valloc: dup alloc
> > I hit the space bar, type in 'boot -s' and it goes through all the > > normal start up procedures, sets up the networking, etc ... 'boot -s' don't work for me, I use 'boot /boot/kernel/kernel -s' instead. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: can't get into single user mode - panic: ffs_valloc: dup alloc
On Tue, 10 Oct 2000, Szilveszter Adam wrote: > On Tue, Oct 10, 2000 at 02:06:24PM -0300, The Hermit Hacker wrote: > > On Tue, 10 Oct 2000, Michael Lucas wrote: > > > > > It's not just you. I just assumed I had done something wrong. > > > > > > Hitting ^C during bootup fsck gets me a single-user prompt. > > > > ah, good, that got me back up and running, thanks :) > > What system are you expriencing this on? -current as of two days ago ... am just rebuilding based on todays sources now ... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: can't get into single user mode - panic: ffs_valloc: dup alloc
On Tue, Oct 10, 2000 at 07:13:49PM +0200, Szilveszter Adam wrote: > On Tue, Oct 10, 2000 at 02:06:24PM -0300, The Hermit Hacker wrote: > > On Tue, 10 Oct 2000, Michael Lucas wrote: > > > > > It's not just you. I just assumed I had done something wrong. > > > > > > Hitting ^C during bootup fsck gets me a single-user prompt. > > > > ah, good, that got me back up and running, thanks :) > > What system are you expriencing this on? > > I have rebuilt this beast today and had no such probs... "boot -s" works fine. I'm experiencing this on a -current from sources supped on Oct 03. turtledawn~;uname -a FreeBSD turtledawn.blackhelicopters.org 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Tue Oct 3 10:58:59 EDT 2000 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/TURTLEDAWN i386 turtledawn~; The first line on /usr/sup/src-all/checkouts.cvs:. F 5 970574708 (I forget how to get the date out of this, but surely the brainy sorts out there remember how...) System is a Toshiba Satellite 2210 CDT. More info on request. ==ml -- Michael Lucas [EMAIL PROTECTED] http://www.blackhelicopters.org/~mwlucas/ Big Scary Daemons: http://www.oreillynet.com/pub/q/Big_Scary_Daemons To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: can't get into single user mode - panic: ffs_valloc: dup alloc
On Tue, Oct 10, 2000 at 02:06:24PM -0300, The Hermit Hacker wrote: > On Tue, 10 Oct 2000, Michael Lucas wrote: > > > It's not just you. I just assumed I had done something wrong. > > > > Hitting ^C during bootup fsck gets me a single-user prompt. > > ah, good, that got me back up and running, thanks :) What system are you expriencing this on? I have rebuilt this beast today and had no such probs... "boot -s" works fine. -- Regards: Szilveszter ADAM Szeged University Szeged Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: can't get into single user mode - panic: ffs_valloc: dup alloc
On Tue, 10 Oct 2000, Michael Lucas wrote:
> It's not just you. I just assumed I had done something wrong.
>
> Hitting ^C during bootup fsck gets me a single-user prompt.
ah, good, that got me back up and running, thanks :)
>
> On Mon, Oct 09, 2000 at 10:01:11PM -0400, Marc G. Fournier wrote:
> >
> > morning all ...
> >
> > Well, I swear I have to be missing something here that is going to
> > make me slap my forehead, but I can't get into single user mode :(
> >
> > I hit the space bar, type in 'boot -s' and it goes through all the
> > normal start up procedures, sets up the networking, etc ...
> >
> > The reason I'm trying to get into single user mode is cause I
> > can't get into multi-user without it doing:
> >
> > =====
> > Recovering vi editor sessions
> > mode = 0100600, inum = 729, fs = /tmp
> > panic: ffs_valloc: dup alloc
> > cpuid = 0; lapic.id =
> > Debugger("panic")
> >
> > CPU0 stopping CPUs: 0x0002... stopped
> >
> >
> > and a trace of:
> >
> > Debugger() @ +0x38
> > panic() @ +0xa0
> > ffs_valloc()@ +0xf5
> > ufs_makeinode() @ +0x5a
> > ufs_create()@ +0x28
> > ufs_vnoperate() @ +0x15
> >
> > Marc G. Fournier [EMAIL PROTECTED]
> > Systems Administrator @ hub.org
> > scrappy@{postgresql|isc}.org ICQ#7615664
> >
> >
> >
> > To Unsubscribe: send mail to [EMAIL PROTECTED]
> > with "unsubscribe freebsd-current" in the body of the message
>
> --
> Michael Lucas
> [EMAIL PROTECTED]
> http://www.blackhelicopters.org/~mwlucas/
> Big Scary Daemons: http://www.oreillynet.com/pub/q/Big_Scary_Daemons
>
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: can't get into single user mode - panic: ffs_valloc: dup alloc
It's not just you. I just assumed I had done something wrong.
Hitting ^C during bootup fsck gets me a single-user prompt.
On Mon, Oct 09, 2000 at 10:01:11PM -0400, Marc G. Fournier wrote:
>
> morning all ...
>
> Well, I swear I have to be missing something here that is going to
> make me slap my forehead, but I can't get into single user mode :(
>
> I hit the space bar, type in 'boot -s' and it goes through all the
> normal start up procedures, sets up the networking, etc ...
>
> The reason I'm trying to get into single user mode is cause I
> can't get into multi-user without it doing:
>
> =
> Recovering vi editor sessions
> mode = 0100600, inum = 729, fs = /tmp
> panic: ffs_valloc: dup alloc
> cpuid = 0; lapic.id =
> Debugger("panic")
>
> CPU0 stopping CPUs: 0x0002... stopped
>
>
> and a trace of:
>
> Debugger()@ +0x38
> panic() @ +0xa0
> ffs_valloc() @ +0xf5
> ufs_makeinode() @ +0x5a
> ufs_create() @ +0x28
> ufs_vnoperate() @ +0x15
>
> Marc G. Fournier [EMAIL PROTECTED]
> Systems Administrator @ hub.org
> scrappy@{postgresql|isc}.org ICQ#7615664
>
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
--
Michael Lucas
[EMAIL PROTECTED]
http://www.blackhelicopters.org/~mwlucas/
Big Scary Daemons: http://www.oreillynet.com/pub/q/Big_Scary_Daemons
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: can't get into single user mode - panic: ffs_valloc: dup alloc
On Mon, 9 Oct 2000, Robert Watson wrote: > On Mon, 9 Oct 2000, Marc G. Fournier wrote: > > > Well, I swear I have to be missing something here that is going to > > make me slap my forehead, but I can't get into single user mode :( > > > > I hit the space bar, type in 'boot -s' and it goes through all the > > normal start up procedures, sets up the networking, etc ... > > > > The reason I'm trying to get into single user mode is cause I > > can't get into multi-user without it doing: > > That's interesting -- this morning, I hit a ffs_valloc: dup alloc panic > following a buildworld. I assumed it was to do with my local ACL patches, > although I have been unable to find a bug that could trigger it. I'm > wondering if this isn't some sort of locking issue in VFS. I managed to > trigger it in ufs_mkdir(), as I introduced a potentially location for > blocking where previously none existed, suggesting that perhaps some UFS > code is playing fast and loose with vnode locks. This panic is > generated when FFS tries to recycle a vnode, but discovers it has a > non-zero mode, indicating that it is in use elsewhere in the system, > which should never happen. > > BTW, do you have FFS_EXTATTR enabled? not that I've enabled ... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: can't get into single user mode - panic: ffs_valloc: dup alloc
On Mon, 9 Oct 2000, Marc G. Fournier wrote: > Well, I swear I have to be missing something here that is going to > make me slap my forehead, but I can't get into single user mode :( > > I hit the space bar, type in 'boot -s' and it goes through all the > normal start up procedures, sets up the networking, etc ... > > The reason I'm trying to get into single user mode is cause I > can't get into multi-user without it doing: That's interesting -- this morning, I hit a ffs_valloc: dup alloc panic following a buildworld. I assumed it was to do with my local ACL patches, although I have been unable to find a bug that could trigger it. I'm wondering if this isn't some sort of locking issue in VFS. I managed to trigger it in ufs_mkdir(), as I introduced a potentially location for blocking where previously none existed, suggesting that perhaps some UFS code is playing fast and loose with vnode locks. This panic is generated when FFS tries to recycle a vnode, but discovers it has a non-zero mode, indicating that it is in use elsewhere in the system, which should never happen. BTW, do you have FFS_EXTATTR enabled? Anyhow, I'm going to see if I can get it to be reproduceable here. Robert N M Watson [EMAIL PROTECTED] http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
can't get into single user mode - panic: ffs_valloc: dup alloc
morning all ...
Well, I swear I have to be missing something here that is going to
make me slap my forehead, but I can't get into single user mode :(
I hit the space bar, type in 'boot -s' and it goes through all the
normal start up procedures, sets up the networking, etc ...
The reason I'm trying to get into single user mode is cause I
can't get into multi-user without it doing:
=
Recovering vi editor sessions
mode = 0100600, inum = 729, fs = /tmp
panic: ffs_valloc: dup alloc
cpuid = 0; lapic.id =
Debugger("panic")
CPU0 stopping CPUs: 0x0002... stopped
and a trace of:
Debugger() @ +0x38
panic() @ +0xa0
ffs_valloc()@ +0xf5
ufs_makeinode() @ +0x5a
ufs_create()@ +0x28
ufs_vnoperate() @ +0x15
Marc G. Fournier [EMAIL PROTECTED]
Systems Administrator @ hub.org
scrappy@{postgresql|isc}.org ICQ#7615664
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Possible Vinum RAID-5 problems? (was: panic: ffs_valloc: dup alloc)
:> Wait a sec... softupdates does not depend on write ordering. :> Softupdates issues all non-conflicting writes in parallel and :> doesn't care what order they are written to the disk. When :> those complete, softupdates will then followup with all the :> writes that depend on the original set. : :Hmm. Maybe I've misunderstood, then. It was my understanding that :soft updates writes metadata with WRITE_ORDERED set, and thus avoids :having to explicitly wait for completion. It's the WRITE_ORDERED that :Vinum doesn't handle correctly. On a single disk, it's just a :question of not sorting around a WRITE_ORDERED request. Vinum will :keep the WRITE_ORDERED on a single disk, but it won't ensure that a :request for the same volume, but which is destined for a different :disk, will not be written until after all components of a prior :WRITE_ORDERED request for that volume. : :Greg Softupdates does not use bowrite(). In fact, the only place anyone uses bowrite() is in the UFS directory code, and if softupdates is turned on even those few bowrite()s are turned *OFF*. Softupdates is very strict in how it issues I/O. There are two cases. In the normal case softupdates does not issue dependant I/O until the I/O associated with the dependancy itself completes. In the second case, where the kernel forces a buffer to be flushed, softupdates will issue I/O on a non-dependant version of the buffer and then redirty the buffer with the dependant data. -Matt Matthew Dillon <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Possible Vinum RAID-5 problems? (was: panic: ffs_valloc: dup alloc)
On Friday, 19 May 2000 at 12:43:28 -0700, Matthew Dillon wrote: > >> Greg Lehey wrote: >>> >>> As far as soft updates goes, basically it's incompatible with Vinum, >>> since there's currently no way of ensuring the sequence of writes >>> across a number of disks. I'm thinking of ways of doing it, but they >>> will cause significant loss in performance. There should be no >>> problems as long as there isn't a crash, of course :-) >> >> Do you mean that softupdates is entirely incompatible with Vinum, or >> just incompatible with Vinum's RAID5? > > Wait a sec... softupdates does not depend on write ordering. > Softupdates issues all non-conflicting writes in parallel and > doesn't care what order they are written to the disk. When > those complete, softupdates will then followup with all the > writes that depend on the original set. Hmm. Maybe I've misunderstood, then. It was my understanding that soft updates writes metadata with WRITE_ORDERED set, and thus avoids having to explicitly wait for completion. It's the WRITE_ORDERED that Vinum doesn't handle correctly. On a single disk, it's just a question of not sorting around a WRITE_ORDERED request. Vinum will keep the WRITE_ORDERED on a single disk, but it won't ensure that a request for the same volume, but which is destined for a different disk, will not be written until after all components of a prior WRITE_ORDERED request for that volume. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Possible Vinum RAID-5 problems? (was: panic: ffs_valloc: dup alloc)
:Greg Lehey wrote: :> :> As far as soft updates goes, basically it's incompatible with Vinum, :> since there's currently no way of ensuring the sequence of writes :> across a number of disks. I'm thinking of ways of doing it, but they :> will cause significant loss in performance. There should be no :> problems as long as there isn't a crash, of course :-) : :Do you mean that softupdates is entirely incompatible with Vinum, or :just incompatible with Vinum's RAID5? : :Matt Wait a sec... softupdates does not depend on write ordering. Softupdates issues all non-conflicting writes in parallel and doesn't care what order they are written to the disk. When those complete, softupdates will then followup with all the writes that depend on the original set. -Matt Matthew Dillon <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Possible Vinum RAID-5 problems? (was: panic: ffs_valloc: dup alloc)
Greg Lehey wrote: > > As far as soft updates goes, basically it's incompatible with Vinum, > since there's currently no way of ensuring the sequence of writes > across a number of disks. I'm thinking of ways of doing it, but they > will cause significant loss in performance. There should be no > problems as long as there isn't a crash, of course :-) Do you mean that softupdates is entirely incompatible with Vinum, or just incompatible with Vinum's RAID5? Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Possible Vinum RAID-5 problems? (was: panic: ffs_valloc: dup alloc)
On Fri, May 19, 2000 at 06:20:44PM +0930, Greg Lehey wrote: > I only stumbled on this thread by accident. If you have problems > which involve Vinum, please copy me, and I may have input. Ok, thanks. Wasn't at all sure vinum had anything to do with this crash (and I still don't know if it has), so I didn't want to "Cry Wolf" :-) . > On Friday, 19 May 2000 at 7:55:37 +0200, Bernd Walter wrote: > > On Fri, May 19, 2000 at 06:24:39AM +0200, Niels Chr. Bank-Pedersen wrote: > >> On Fri, May 19, 2000 at 12:01:59AM +0200, Bernd Walter wrote: > >>> On Thu, May 18, 2000 at 11:43:58PM +0200, Niels Chr. Bank-Pedersen wrote: > On Thu, May 18, 2000 at 11:21:51PM +0200, Bernd Walter wrote: > > Does vinum list saying that one subdisk of your R5 volume is down? > > 5 subdisks: > S raid5.p0.s0 State: upPO:0 B Size: 4133 MB > S raid5.p0.s1 State: upPO: 768 kB Size: 4133 MB > S raid5.p0.s2 State: upPO: 1536 kB Size: 4133 MB > S raid5.p0.s3 State: upPO: 2304 kB Size: 4133 MB > S raid5.p0.s4 State: upPO: 3072 kB Size: 4133 MB > > - But since my first attempt to initialize the plex crashed the > box while only da5se1 was missing, I did a "verify media" from > the SCSI ctrl. BIOS, and did find errors. They were all successfully > remapped, though. > >>> > >>> I thought about a parity corrpution bug that there was in history. > >>> But as all drives are up and they are freshly initialized there are 2 > >>> arguments why your problems should be different. > >>> Maybe one drive crashed and the system paniced before vinum was able to update > >>> the state database on the drives. > >>> Did you saw anything unusual on the console before the panic message? > >> > >> > >> - after obliterating the vinum configuration I created the volume > >> without da5, and I have now successfully copied 250+MB to the filesystem. > >> > >> I would have thought that hardware errors like this could be handled > >> in a slightly more controlled manner, though. > > > > At this moment there is no sign of a hardware error. > > The panic itself means that the filessytem allocated a block which > > already was allocated. Usually it means that the data on the drive > > got corrupted while mounted. > > > > You should be carefully testing the volume before copying important > > data to it. In my expirience I can say that using softupdates > > stresses the I/O system much more than the standard way so it makes > > sense to test with softupdates. This is a scratch box used primarily for testing -current, so I don't have anything important on it. Which is good, 'cause as you suspected, it *did* crash again after a while. This time it was, among other things, nfs-serving a buildworld from another filesystem at the time of the crash, so I'm not too sure what triggered it this time (I only got the trace, not any of the messages from the panic): db> trace Debugger(c0245ca3) at Debugger+0x35 panic(c0253e00,c3853a40,c1259500,c3853a40,0) at panic+0x70 handle_written_inodeblock(c1259500,c3853a40) at handle_written_inodeblock+0x2b8 softdep_disk_write_complete(c3853a40) at softdep_disk_write_complete+0x6a bufdone(c3853a40,c0264ab8,c0128558,c3853a40,c0f78400) at bufdone+0x7e bufdonebio(c3853a40) at bufdonebio+0xe dadone(c0f6c680,c0f78400,c073a9a0,4200,) at dadone+0x210 camisr(c0282290,c0264b0c,c021e4e0,4200,c022e8f6) at camisr+0x1eb swi_cambio(4200,c022e8f6,c022e41f,4200,c0ec3800) at swi_cambio+0xd splz_swi(c073a9a0,0,10,10,10) at splz_swi+0x14 Xresume9() at Xresume9+0x2b --- interrupt, eip = 0xc0227a96, esp = 0xc0264b54, ebp = 0 --- default_halt() at default_halt+0x2 db> > I recently fixed a number of problems in RAID-5. Can you give me > details of the problems you've been having, and the date of the sup? > Since this is -CURRENT, I assume that's the version of the system too. It is - sources from ~3 days ago, so I believe I have all your latest fixes. > As far as soft updates goes, basically it's incompatible with Vinum, > since there's currently no way of ensuring the sequence of writes > across a number of disks. I'm thinking of ways of doing it, but they > will cause significant loss in performance. There should be no > problems as long as there isn't a crash, of course :-) I wasn't aware of the incompatibility issues, so all my vinum volumes were running with SU until a few minutes ago :-) I have turned SU off on this R5 volume now as well, but the above trace happened, with SU turned on. > Greg /Niels Chr. -- Niels Christian Bank-Pedersen, NCB1-RIPE. Network Manager, Tele Danmark NET, IP-section. "Hey, are any of you guys out there actually *using* RFC 2549?" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Possible Vinum RAID-5 problems? (was: panic: ffs_valloc: dup alloc)
I only stumbled on this thread by accident. If you have problems which involve Vinum, please copy me, and I may have input. On Friday, 19 May 2000 at 7:55:37 +0200, Bernd Walter wrote: > On Fri, May 19, 2000 at 06:24:39AM +0200, Niels Chr. Bank-Pedersen wrote: >> On Fri, May 19, 2000 at 12:01:59AM +0200, Bernd Walter wrote: >>> On Thu, May 18, 2000 at 11:43:58PM +0200, Niels Chr. Bank-Pedersen wrote: On Thu, May 18, 2000 at 11:21:51PM +0200, Bernd Walter wrote: > Does vinum list saying that one subdisk of your R5 volume is down? 5 subdisks: S raid5.p0.s0 State: up PO:0 B Size: 4133 MB S raid5.p0.s1 State: up PO: 768 kB Size: 4133 MB S raid5.p0.s2 State: up PO: 1536 kB Size: 4133 MB S raid5.p0.s3 State: up PO: 2304 kB Size: 4133 MB S raid5.p0.s4 State: up PO: 3072 kB Size: 4133 MB - But since my first attempt to initialize the plex crashed the box while only da5se1 was missing, I did a "verify media" from the SCSI ctrl. BIOS, and did find errors. They were all successfully remapped, though. >>> >>> I thought about a parity corrpution bug that there was in history. >>> But as all drives are up and they are freshly initialized there are 2 >>> arguments why your problems should be different. >>> Maybe one drive crashed and the system paniced before vinum was able to update >>> the state database on the drives. >>> Did you saw anything unusual on the console before the panic message? >> >> >> - after obliterating the vinum configuration I created the volume >> without da5, and I have now successfully copied 250+MB to the filesystem. >> >> I would have thought that hardware errors like this could be handled >> in a slightly more controlled manner, though. > > At this moment there is no sign of a hardware error. > The panic itself means that the filessytem allocated a block which > already was allocated. Usually it means that the data on the drive > got corrupted while mounted. > > You should be carefully testing the volume before copying important > data to it. In my expirience I can say that using softupdates > stresses the I/O system much more than the standard way so it makes > sense to test with softupdates. I recently fixed a number of problems in RAID-5. Can you give me details of the problems you've been having, and the date of the sup? Since this is -CURRENT, I assume that's the version of the system too. As far as soft updates goes, basically it's incompatible with Vinum, since there's currently no way of ensuring the sequence of writes across a number of disks. I'm thinking of ways of doing it, but they will cause significant loss in performance. There should be no problems as long as there isn't a crash, of course :-) Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: ffs_valloc: dup alloc
On Fri, May 19, 2000 at 06:24:39AM +0200, Niels Chr. Bank-Pedersen wrote: > On Fri, May 19, 2000 at 12:01:59AM +0200, Bernd Walter wrote: > > On Thu, May 18, 2000 at 11:43:58PM +0200, Niels Chr. Bank-Pedersen wrote: > > > On Thu, May 18, 2000 at 11:21:51PM +0200, Bernd Walter wrote: > > > > Does vinum list saying that one subdisk of your R5 volume is down? > > > > > > 5 subdisks: > > > S raid5.p0.s0 State: up PO:0 B Size: 4133 MB > > > S raid5.p0.s1 State: up PO: 768 kB Size: 4133 MB > > > S raid5.p0.s2 State: up PO: 1536 kB Size: 4133 MB > > > S raid5.p0.s3 State: up PO: 2304 kB Size: 4133 MB > > > S raid5.p0.s4 State: up PO: 3072 kB Size: 4133 MB > > > > > > - But since my first attempt to initialize the plex crashed the > > > box while only da5se1 was missing, I did a "verify media" from > > > the SCSI ctrl. BIOS, and did find errors. They were all successfully > > > remapped, though. > > > > I thought about a parity corrpution bug that there was in history. > > But as all drives are up and they are freshly initialized there are 2 > > arguments why your problems should be different. > > Maybe one drive crashed and the system paniced before vinum was able to update > > the state database on the drives. > > Did you saw anything unusual on the console before the panic message? > > It seems to be a hardware problem with da5. After the latest > crash, I had the following in dmesg: > > (da5:ahc4:0:2:0): SYNCHRONIZE CACHE. CDB: 35 0 0 0 0 0 0 0 0 0 > (da5:ahc4:0:2:0): NO SENSE That's harmless - it only means that your drive doesn't understood the sync-cache command which is to flush the drives write-cache to the media. If there wasn't anything else then there's no reason to beleave that something went wrong with one of your drives. > - after obliterating the vinum configuration I created the volume > without da5, and I have now successfully copied 250+MB to the filesystem. > > I would have thought that hardware errors like this could be handled > in a slightly more controlled manner, though. At this moment there is no sign of a hardware error. The panic itself means that the filessytem allocated a block which already was allocated. Usually it means that the data on the drive got corrupted while mounted. You should be carefully testing the volume before copying important data to it. In my expirience I can say that using softupdates stresses the I/O system much more than the standard way so it makes sense to test with softupdates. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: ffs_valloc: dup alloc
On Fri, May 19, 2000 at 12:01:59AM +0200, Bernd Walter wrote: > On Thu, May 18, 2000 at 11:43:58PM +0200, Niels Chr. Bank-Pedersen wrote: > > On Thu, May 18, 2000 at 11:21:51PM +0200, Bernd Walter wrote: > > > Does vinum list saying that one subdisk of your R5 volume is down? > > > > 5 subdisks: > > S raid5.p0.s0 State: up PO:0 B Size: 4133 MB > > S raid5.p0.s1 State: up PO: 768 kB Size: 4133 MB > > S raid5.p0.s2 State: up PO: 1536 kB Size: 4133 MB > > S raid5.p0.s3 State: up PO: 2304 kB Size: 4133 MB > > S raid5.p0.s4 State: up PO: 3072 kB Size: 4133 MB > > > > - But since my first attempt to initialize the plex crashed the > > box while only da5se1 was missing, I did a "verify media" from > > the SCSI ctrl. BIOS, and did find errors. They were all successfully > > remapped, though. > > I thought about a parity corrpution bug that there was in history. > But as all drives are up and they are freshly initialized there are 2 > arguments why your problems should be different. > Maybe one drive crashed and the system paniced before vinum was able to update > the state database on the drives. > Did you saw anything unusual on the console before the panic message? It seems to be a hardware problem with da5. After the latest crash, I had the following in dmesg: (da5:ahc4:0:2:0): SYNCHRONIZE CACHE. CDB: 35 0 0 0 0 0 0 0 0 0 (da5:ahc4:0:2:0): NO SENSE - after obliterating the vinum configuration I created the volume without da5, and I have now successfully copied 250+MB to the filesystem. I would have thought that hardware errors like this could be handled in a slightly more controlled manner, though. > B.Walter COSMO-Project http://www.cosmo-project.de Once again, thanks for your time. /Niels Chr. -- Niels Christian Bank-Pedersen, NCB1-RIPE. Network Manager, Tele Danmark NET, IP-section. "Hey, are any of you guys out there actually *using* RFC 2549?" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: ffs_valloc: dup alloc
On Thu, May 18, 2000 at 11:43:58PM +0200, Niels Chr. Bank-Pedersen wrote: > On Thu, May 18, 2000 at 11:21:51PM +0200, Bernd Walter wrote: > > Does vinum list saying that one subdisk of your R5 volume is down? > > 5 subdisks: > S raid5.p0.s0 State: up PO:0 B Size: 4133 MB > S raid5.p0.s1 State: up PO: 768 kB Size: 4133 MB > S raid5.p0.s2 State: up PO: 1536 kB Size: 4133 MB > S raid5.p0.s3 State: up PO: 2304 kB Size: 4133 MB > S raid5.p0.s4 State: up PO: 3072 kB Size: 4133 MB > > - But since my first attempt to initialize the plex crashed the > box while only da5se1 was missing, I did a "verify media" from > the SCSI ctrl. BIOS, and did find errors. They were all successfully > remapped, though. I thought about a parity corrpution bug that there was in history. But as all drives are up and they are freshly initialized there are 2 arguments why your problems should be different. Maybe one drive crashed and the system paniced before vinum was able to update the state database on the drives. Did you saw anything unusual on the console before the panic message? > > Are you using softupdates? > > Yup. I am unable to try without SU right now (well, I could, but if it > doesnt work, my foot will be blown of), but I'll try that later when I > get home. It's only of interesst if it was/is enabled on the volume in question and not if it is compiled into the kernel. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: ffs_valloc: dup alloc
On Thu, May 18, 2000 at 11:21:51PM +0200, Bernd Walter wrote:
> On Thu, May 18, 2000 at 04:13:43PM +0200, Niels Chr. Bank-Pedersen wrote:
> > Hi,
> >
> > On a -current box, sources approx. 2½ days old, I'm
> > having problems using a vinum raid5 volume - usually
> > the box freezes totally when trying to use the filesystem
> > (mkdir xxx; cd xxx -> crash), but last time it dropped
> > to the debugger:
> >
> > mode = 040755, inum = 25344, fs = /raid5
> > panic: ffs_valloc: dup alloc
> > Debugger("panic")
> > Stopped at Debugger+0x35: movb$0,in_Debugger.390
> > db> trace
> > Debugger(c0245ca3) at Debugger+0x35
> > panic(c0252541,c0252520,41ed,6300,c109e0d4) at panic+0x70
> > ffs_valloc(c9e7e300,41ed,c1171400,c9e69d08,c9e69e70) at ffs_valloc+0xf8
> > ufs_mkdir(c9e69e70,c9e69f2c,c018d272,c9e69e70,c9e2c8e0) at ufs_mkdir+0x82
> > ufs_vnoperate(c9e69e70,c9e2c8e0,2,c9e69f80,c02651e0) at ufs_vnoperate+0x15
> > mkdir(c9e2c8e0,c9e69f80,bfbffc1c,1,1ff) at mkdir+0x162
> > syscall2(2f,2f,2f,1ff,1) at syscall2+0x1f1
> > Xint0x80_syscall() at Xint0x80_syscall+0x28
> > db>
> >
> > I had one crash on my first attempt initialising the volume,
> > but was able to newfs without any problems after initializing
> > succeeded on the second attempt.
> >
> > Anybody able to see what could be happening here?
> > (dmesg below, and dump/kernel.debug available)
>
> I don't know what Greg thinks about but I beleave that the dup alloc is not
> the reason itself.
> Does vinum list saying that one subdisk of your R5 volume is down?
No:
5 drives:
D raid5-00 State: up Device /dev/da1s1e Avail: 0/4133 MB (0%)
D raid5-01 State: up Device /dev/da3s1e Avail: 0/4133 MB (0%)
D raid5-02 State: up Device /dev/da5s1e Avail: 0/4133 MB (0%)
D raid5-03 State: up Device /dev/da6s1e Avail: 0/4133 MB (0%)
D raid5-04 State: up Device /dev/da7s1e Avail: 0/4133 MB (0%)
1 volumes:
V raid5 State: up Plexes: 1 Size: 16 GB
1 plexes:
P raid5.p0 R5 State: up Subdisks: 5 Size: 16 GB
5 subdisks:
S raid5.p0.s0 State: up PO:0 B Size: 4133 MB
S raid5.p0.s1 State: up PO: 768 kB Size: 4133 MB
S raid5.p0.s2 State: up PO: 1536 kB Size: 4133 MB
S raid5.p0.s3 State: up PO: 2304 kB Size: 4133 MB
S raid5.p0.s4 State: up PO: 3072 kB Size: 4133 MB
- But since my first attempt to initialize the plex crashed the
box while only da5se1 was missing, I did a "verify media" from
the SCSI ctrl. BIOS, and did find errors. They were all successfully
remapped, though.
> If yes with which version did you last initialized the plex?
Newly created plex, so that would be the currently installed version.
> Are you using softupdates?
Yup. I am unable to try without SU right now (well, I could, but if it
doesnt work, my foot will be blown of), but I'll try that later when I
get home.
> B.Walter COSMO-Project http://www.cosmo-project.de
Thnx.
/Niels Chr.
--
Niels Christian Bank-Pedersen, NCB1-RIPE.
Network Manager, Tele Danmark NET, IP-section.
"Hey, are any of you guys out there actually *using* RFC 2549?"
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: panic: ffs_valloc: dup alloc
On Thu, May 18, 2000 at 04:13:43PM +0200, Niels Chr. Bank-Pedersen wrote:
> Hi,
>
> On a -current box, sources approx. 2½ days old, I'm
> having problems using a vinum raid5 volume - usually
> the box freezes totally when trying to use the filesystem
> (mkdir xxx; cd xxx -> crash), but last time it dropped
> to the debugger:
>
> mode = 040755, inum = 25344, fs = /raid5
> panic: ffs_valloc: dup alloc
> Debugger("panic")
> Stopped at Debugger+0x35: movb$0,in_Debugger.390
> db> trace
> Debugger(c0245ca3) at Debugger+0x35
> panic(c0252541,c0252520,41ed,6300,c109e0d4) at panic+0x70
> ffs_valloc(c9e7e300,41ed,c1171400,c9e69d08,c9e69e70) at ffs_valloc+0xf8
> ufs_mkdir(c9e69e70,c9e69f2c,c018d272,c9e69e70,c9e2c8e0) at ufs_mkdir+0x82
> ufs_vnoperate(c9e69e70,c9e2c8e0,2,c9e69f80,c02651e0) at ufs_vnoperate+0x15
> mkdir(c9e2c8e0,c9e69f80,bfbffc1c,1,1ff) at mkdir+0x162
> syscall2(2f,2f,2f,1ff,1) at syscall2+0x1f1
> Xint0x80_syscall() at Xint0x80_syscall+0x28
> db>
>
> I had one crash on my first attempt initialising the volume,
> but was able to newfs without any problems after initializing
> succeeded on the second attempt.
>
> Anybody able to see what could be happening here?
> (dmesg below, and dump/kernel.debug available)
I don't know what Greg thinks about but I beleave that the dup alloc is not
the reason itself.
Does vinum list saying that one subdisk of your R5 volume is down?
If yes with which version did you last initialized the plex?
Are you using softupdates?
--
B.Walter COSMO-Project http://www.cosmo-project.de
[EMAIL PROTECTED] Usergroup[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
panic: ffs_valloc: dup alloc
Hi,
On a -current box, sources approx. 2½ days old, I'm
having problems using a vinum raid5 volume - usually
the box freezes totally when trying to use the filesystem
(mkdir xxx; cd xxx -> crash), but last time it dropped
to the debugger:
mode = 040755, inum = 25344, fs = /raid5
panic: ffs_valloc: dup alloc
Debugger("panic")
Stopped at Debugger+0x35: movb$0,in_Debugger.390
db> trace
Debugger(c0245ca3) at Debugger+0x35
panic(c0252541,c0252520,41ed,6300,c109e0d4) at panic+0x70
ffs_valloc(c9e7e300,41ed,c1171400,c9e69d08,c9e69e70) at ffs_valloc+0xf8
ufs_mkdir(c9e69e70,c9e69f2c,c018d272,c9e69e70,c9e2c8e0) at ufs_mkdir+0x82
ufs_vnoperate(c9e69e70,c9e2c8e0,2,c9e69f80,c02651e0) at ufs_vnoperate+0x15
mkdir(c9e2c8e0,c9e69f80,bfbffc1c,1,1ff) at mkdir+0x162
syscall2(2f,2f,2f,1ff,1) at syscall2+0x1f1
Xint0x80_syscall() at Xint0x80_syscall+0x28
db>
I had one crash on my first attempt initialising the volume,
but was able to newfs without any problems after initializing
succeeded on the second attempt.
Anybody able to see what could be happening here?
(dmesg below, and dump/kernel.debug available)
/Niels Chr.
Copyright (c) 1992-2000 The FreeBSD Project.
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
FreeBSD 5.0-CURRENT #0: Wed May 17 03:59:29 CEST 2000
[EMAIL PROTECTED]:/usr/src/sys/compile/MAIL
Timecounter "i8254" frequency 1193182 Hz
Timecounter "TSC" frequency 166194046 Hz
CPU: Pentium/P54C (166.19-MHz 586-class CPU)
Origin = "GenuineIntel" Id = 0x52c Stepping = 12
Features=0x1bf
real memory = 134217728 (131072K bytes)
avail memory = 127438848 (124452K bytes)
Preloaded elf kernel "kernel" at 0xc02e9000.
npx0: on motherboard
npx0: INT 16 interface
pcib0: on motherboard
pci0: on pcib0
isab0: at device 7.0 on pci0
isa0: on isab0
pci0: at 7.1
pcib1: at device 9.0 on pci0
pci1: on pcib1
ahc0: port 0xd800-0xd8ff mem 0xf900-0xf9000fff
irq 9 at device 4.0 on pci1
ahc0: aic7870 Wide Channel A, SCSI Id=7, 16/255 SCBs
ahc1: port 0xd400-0xd4ff mem
0xfb00-0xfb1f,0xf880-0xf8800fff irq 11 at device 5.0 on pci1
RAID functionality unsupported
device_probe_and_attach: ahc1 attach returned 6
ahc2: port 0xd000-0xd0ff mem 0xf800-0xf8000fff
irq 9 at device 8.0 on pci1
ahc2: aic7870 Wide Channel B, SCSI Id=7, 16/255 SCBs
ahc3: port 0xc800-0xc8ff mem 0xf780-0xf7800fff
irq 9 at device 12.0 on pci1
ahc3: aic7870 Wide Channel C, SCSI Id=7, 16/255 SCBs
pci0: at 10.0 irq 12
ahc4: port 0xb800-0xb8ff mem 0xf680-0xf6800fff
irq 10 at device 11.0 on pci0
ahc4: aic7880 Single Channel A, SCSI Id=7, 16/255 SCBs
xl0: <3Com 3c905-TX Fast Etherlink XL> port 0xb400-0xb43f irq 11 at device 12.0 on pci0
xl0: Ethernet address: 00:10:4b:3d:d2:79
miibus0: on xl0
nsphy0: on miibus0
nsphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0
fdc0: FIFO enabled, 8 bytes threshold
fd0: <1440-KB 3.5" drive> on fdc0 drive 0
atkbdc0: at port 0x60,0x64 on isa0
atkbd0: irq 1 on atkbdc0
vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0
sc0: on isa0
sc0: VGA <16 virtual consoles, flags=0x0>
sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0
sio0: type 16550A, console
sio1 at port 0x2f8-0x2ff irq 3 on isa0
sio1: type 16550A
ppc0: This ppc chipset does not support the extended I/O port range...no problem
ppc0: at port 0x378-0x37b irq 7 drq 1 on isa0
ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode
ppc0: FIFO with 16/16/15 bytes threshold
lpt0: on ppbus0
lpt0: Interrupt-driven port
unknown: can't assign resources
unknown: can't assign resources
unknown: can't assign resources
unknown: can't assign resources
unknown0: at iomem
0-0x9,0x10-0x7ff,0xe8000-0xf,0xfffe-0x on isa0
unknown: can't assign resources
unknown1: at port 0x40-0x43 irq 0 on isa0
unknown2: at port 0x70-0x71 irq 8 on isa0
unknown: can't assign resources
npxisa0: at port 0xf0 irq 13 on isa0
unknown3: at port 0-0xf,0x80-0x90,0x94-0x9f,0xc0-0xde drq 4 on isa0
unknown4: at port 0x61 on isa0
unknown5: at port 0xcf8-0xcff,0x4d0-0x4d1 on isa0
Waiting 5 seconds for SCSI devices to settle
ahc4:A:6: refuses synchronous negotiation. Using asynchronous transfers
ahc4:A:6: refuses synchronous negotiation. Using asynchronous transfers
sa0 at ahc4 bus 0 target 6 lun 0
sa0: Removable Sequential Access SCSI-2 device
sa0: 3.300MB/s transfers
da7 at ahc4 bus 0 target 4 lun 0
da7: Fixed Direct Access SCSI-2 device
da7: 10.000MB/s transfers (10.000MHz, offset 15)
da7: 4134MB (8467200 512 byte sectors: 255H 63S/T 527C)
da6 at ahc4 bus 0 target 3 lun 0
da6: Fixed Direct Access SCSI-2 device
da6: 10.000MB/s transfers (10.000MHz, offset 15)
da6: 4134MB (8467200 512 byte sectors: 255H 63S/T 527C)
da5 at ahc4 bus 0 target 2 lun 0
da5: Fixed Direct
