9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: "Anthony Sorace" <anothy@gmail.com>
To: "Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu>
Subject: [9fans] cwfs(4) failing: phase error after recover or suicide after normal startup
Date: Tue, 18 Sep 2007 18:28:14 -0400	[thread overview]
Message-ID: <509071940709181528h29854b52jf1856b5bbfde7259@mail.gmail.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 1987 bytes --]

Having played around with cwfs for a week or so now, I'm trying to use
it to migrate my old kenfs. The relevant config line is 'filsys main
cw4f[w<0-3>]'; w4 no longer works. I've gotten w0-3 hooked up to my
cpu server and have created a devmap mapping w4 to a 30GB disk file
(the original w4 disk was slightly larger than that).

Starting up cwfs with -f (and other appropriate invocations) seems to
work fine; I give it the config, it reports the correct mapping, and I
end the conversation with 'recover main' and 'end'. The recover seems
to work fine - it reports the block numbers of a few hundred dumps -
but the process ends with this (I have CHAT(cp) always return true):
	next dump at Wed Sep 19 05:00:00 2007
	c_session 0
	c_attach 0
		fid = 1
		uid = adm
		arg = main
	fworm: read 1400715
		error: phase error -- directory entry not allocated
	panic: FID1 attach to root
	halted at Tue Sep 18 14:16:07 2007.
That phase error is Ealloc in 9p1.c^f_attach.

If I omit the -f from cwfs's invocation after doing the recover, I get
this, instead:
	next dump at Wed Sep 19 05:00:00 2007
	c_session 0
	c_attach 0
		fid = 1
		uid = adm
		arg = main
	cwfs:10685: suicide: sys: trap: divide error pc=0x000131cd
PC there points to /sys/src/cmd/cwfs/cw.c:562 - cwio(); I've got acid
traces in, but I don't see anything obviously wrong (no
divide-by-zero, h->msize is positive, &c).

In this case, only the first cwfs proc has suicided; the rest are
running along, getting 9p requests (although not managing to actually
do anything with them).

I'm going to do more tracing after dinner or tomorrow, but I'm
reasonably stumped at this point. Any pointers or other help is
greatly appreciated. Particularly intriguing is why the behavior
differs, when the first case successfully completes the recover and
moves on. Attached is a summary of an acid debugging run on the
suicided process from the second form, should anyone want to take a
look.

[-- Attachment #2: cwfs.acid.txt --]
[-- Type: text/plain, Size: 2366 bytes --]

: sophia; acid 10685
/proc/10685/text:386 plan 9 executable

/sys/lib/acid/port
/sys/lib/acid/386
acid: lstk()
cwio(dev=0x16f408,addr=0x0,buf=0x8250cc0,opcode=0x8)+0x98 /sys/src/cmd/cwfs/cw.c:562
	cw=0x85fb188
	cb=0xbfd750
	h=0x80a8cc0
	a1=0x25dd9
	bn=0xbfd750
	a2=0x34000001
	max=0x0
	newmax=0x1
	p=0xbfd750
	b=0x20267
	c=0x375bc
	state=0x1
	p1=0x25dd9
	p2=0xbfd750
cwread(dev=0x16f408,b=0x0,c=0x8250cc0)+0x28 /sys/src/cmd/cwfs/cw.c:496
devread(c=0x8250cc0,b=0x0,d=0x16f408)+0x1b6 /sys/src/cmd/cwfs/sub.c:988
	e=0x29743
getbuf(d=0x16f408,addr=0x0,flag=0x1)+0x1de /sys/src/cmd/cwfs/iobuf.c:109
	hp=0xb5a258
	p=0xbffbc0
f_attach(cp=0x85fad28,in=0xdfffebcc,ou=0xdfffeb30)+0x29b /sys/src/cmd/cwfs/9p1.c:241
	p=0x0
	f=0x1762e0
	fs=0x4d3b0
	raddr=0x0
	d=0x202af
fcall9p1(in=0xdfffebcc,ou=0xdfffeb30,cp=0x85fad28)+0x95 /sys/src/cmd/cwfs/console.c:21
	t=0x56
con_attach(fid=0x1,uid=0x4058f,arg=0x1734e8)+0x84 /sys/src/cmd/cwfs/console.c:48
	in=0x1ec56
	ou=0x1ea57
cmd_cfs(argc=0x1,argv=0xdfffeca8)+0x70 /sys/src/cmd/cwfs/con.c:618
	name=0x40571
	fs=0x4d3b0
cmd_exec(arg=0x401a0)+0xdc /sys/src/cmd/cwfs/con.c:118
	line=0x736663
	argv=0xdfffecd4
	argc=0x1
	i=0x1
consserve()+0x3d /sys/src/cmd/cwfs/con.c:20
	i=0x29d0
main(argv=0xdfffef88,argc=0x1)+0x2b0 /sys/src/cmd/cwfs/main.c:331
	nets=0x1
	_argc=0x6d
	_args=0x3fd64
	ann=0x0
	i=0xf
_main+0x31 /sys/src/libc/386/main9.s:16
acid: print(pcfile(0x000131cd))
/sys/src/cmd/cwfs/cw.c
acid: print(pcline(0x000131cd))
562
acid: include("/sys/src/cmd/cwfs/arkive/cw.acid")
acid: cwio:dev
	type	0x08
	init	0xf4
	link	0x00000000
	dlink	0x08250cc0
	private	0x00000008
	size	582328845860864
_10_ {
_2_ wren {
	ctrl	1504264
	targ	0
	lun	136645824
	mapped	11903580
	file	0x00029845
	fd	12581824
	sddir	0x00029743
	sddata	0x0001841f
}
_3_ cat {
	first	0x0016f408
	last	0x00000000
	ndev	136645824
}
_4_ cw {
	c	0x0016f408
	w	0x00000000
	ro	0x08250cc0
}
_5_ j {
	j	0x0016f408
	m	0x00000000
}
_6_ ro {
	parent	0x0016f408
}
_7_ fw {
	fw	0x0016f408
}
_8_ part {
	d	0x0016f408
	base	0
	size	136645824
}
_9_ swab {
	d	0x0016f408
}
}

acid: cwio:h
	maddr	134909120
	msize	12572496
	caddr	12572496
	csize	155097
	fsize	12572496
	wsize	77718
	wmax	1504264
	sbaddr	0
	cwraddr	136645824
	roraddr	8
	toytime	0
	time	135584

acid: cwio:addr
0xdfffea60
acid: cwio:bn
0xdfffea38

acid: rc("cat /dev/text > /mnt/term/Users/anthony/Desktop/cwfs.acid.txt")

             reply	other threads:[~2007-09-18 22:28 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-18 22:28 Anthony Sorace [this message]
2007-09-18 23:13 ` erik quanstrom
2007-09-20 23:13   ` Anthony Sorace
2007-09-21  0:03     ` [9fans] cwfs(4) failing: phase error after recover or suicide erik quanstrom
2007-09-21  1:53       ` Anthony Sorace
2007-09-21  2:00         ` erik quanstrom
2007-09-21  3:10           ` Anthony Sorace
2007-09-21  3:39             ` erik quanstrom

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=509071940709181528h29854b52jf1856b5bbfde7259@mail.gmail.com \
    --to=anothy@gmail.com \
    --cc=9fans@cse.psu.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).