[9fans] 9fs nvr file

[9fans] 9fs nvr file

[erik quanstrom]

i can't seem to properly specify the nvr file in plan9.ini for the
fs kernel.

i'm booting off cd with a 100M dos partition with plan9.nvr.
this partition was copied from my plan9 terminal.
i've tried
	sdC0!dos!plan9.nvr
	hdC0!dos!plan9.nvr
i get a panic "no device for nvram".

what am i missing?

- erik

Re: [9fans] 9fs nvr file

[erik quanstrom]

D'oh!

okay i need h0!.  sorry for the silly question.  but now i get a panic
that i'm not sure i understand.

h0: LBA 1210103200 sectors
FLAGS=10246 TRAP=e ECODE=0 CS=10 PC=801018af
  ax=0 bx=8018a048 cd=8018a048 dx=0
  si=0 di=0 bp=0
  ds=0008 es=0008 fs=0008 gs=0008
  cr0=80010011 cr2=0
  ur=8018fe71

FLAGS=282 TRAP=18 cs=10 pc=80100398
  [...]
  lastur=8018fe04

acid: src(0x801018af)
/sys/src/fs/port/devsd.c:167
 162		 * The device will be probed if it has not already been
 163		 * successfully accessed.
 164		 */
 165		qlock(&sdqlock);
 166		index = sdev->index+subno;
>167		unit = sdunit[index];
 168		if(unit == nil){
 169			if((unit = malloc(sizeof(SDunit))) == nil){
 170				qunlock(&sdqlock);
 171				return nil;
 172			}

acid: src(0x80100398)
/sys/src/fs/pc/l.s:559
 554	TEXT	splx(SB),$0
 555		MOVL	s+0(FP),AX
 556		PUSHL	AX
 557		POPFL
 558		RET
>559	
 560	TEXT	getstatus(SB),$0
 561		PUSHFL
 562		POPL	AX
 563		RET
 564	

On Tue Aug 15 14:14:50 CDT 2006, quanstro@quanstro.net wrote:
> 	sdC0!dos!plan9.nvr
> 	hdC0!dos!plan9.nvr
> i get a panic "no device for nvram".

Re: [9fans] 9fs nvr file

[geoff]

nvr syntax is different from nvram syntax.  plan9.ini(8) has the whole
story, but briefly

	hd!0!plan9.nvr

should work.  "fd" will work instead of "hd" for floppies but "sd" for
scsi is not implemented for reasons lost to history (at least in the
Unix Room).  I've considered taking a stab at it but have never been
motivated enough.

Re: [9fans] 9fs nvr file

[erik quanstrom]

okay.  9load was confusing me.  even though my syntax is still a bit off,
i think the hd!randomstring!plan9.nvr was interpreted correctly.

i dissassembled the part with the page fault dissassembled the offending
line
	unit = sdunit[index]
as
	MOVL 0x0(DX)(AX*4),AX
since ax = 0 and dx=0, i can see why this faulted.  but i have no idea why
sdunit was nil.

- erik

Re: [9fans] 9fs nvr file

[erik quanstrom]

perhaps my last reply wasn't clear.  although i have an ncr card in the machine, the
fs kernel and plan9.nvr are both in a 100M dos partition.  the partition map
is
	1) 100 mb dos partition copied from another machine with a new plan9.ini
	and a 512byte plan9.nvr added.

	2) the rest of the (60G) disk.

why can't plan9.nvr be found?  i've added some tracing, and it appears that no partitions
are added to the partition list.  

- erik

Re: [9fans] 9fs nvr file

[erik quanstrom]

i might be going off in the wrong direction, as i am unfamiliar with this code, but i
think i understand this a bit better now.  it seems that the first problem was that
$fsname/$fsname.c calls atainit.  this function returns a the head of the ata partition list
on first call, nil otherwise.  thus when sdataifc.pnp() is called by _sdinit() no partitions
are found.  the reason for this return scheme is to prevent the same partition from
being added to the list of devices twice.

i wrote a function to put into sdataifc that returns the head ptr exactly once, independent
of calls to the original pnp function.  this fixes (a term of art) the first problem.  interestingly, no
partitions are recognized, just full disks.  i believe that there are only stubs for recognizing
partitions.  perhaps someone with more knowledge could correct me.  

however this still fails to boot because (back in $fsname/$fsname.c) otherinit() and dosfs
do not seem to have a mechanism for selecting the proper device.  i believe that dosinit()
is catching the second device first (that is, the cdrom).  it appears that dosinit() knows about
dos partitions, so it doesn't appear that partitioning problems are to blame.

would an LLBA disk have a signature that would confuse it?

- erik

Re: [9fans] 9fs nvr file

[geoff]

The file server is unaware of normal Plan 9 partitions.  The DOS code
has some minimal awareness of fdisk partitions, but in general you
should use whole disks or the `p' device to subdivide them.  The DOS
code only knows how to read FAT 12 and FAT 16 file systems.  If you
want to see what's happening in the DOS code, change the definition of
`chatty' at /sys/src/fs/pc/dosfs.c:16 to

#define chatty 1

and build and boot a new kernel.

The nvr/DOS code is a little different than the usual block I/O code
in the file server.  nvrdevs[] in /sys/src/fs/fs64/9fsfs64.c (or
whatever it's called for your file server) contains different entry
points than the usual ones.

Re: [9fans] 9fs nvr file

[erik quanstrom]

thanks.

the dos code had enough to find the partition.  however, i forgot to
mark the partition active.  D'oh!  i found this by defining chatty.
i'm just using the partition to boot.  

i messed something up though, the /adm/users didn't exist after
i finished configuration mode. users default gave an error.
newuser created only the new user, none of the required defaults.

- erik

Re: [9fans] 9fs nvr file

[geoff]

>From memory, I think I usually do

	cfs main		# or whatever you called yours
	allow
	create /adm adm sys 775 d
	create /adm/users adm sys 664
	users default

then connect as bootes (cpu -a netkey, 9fs <newfs>), copy my real
/adm/users into the new file system, make any other desirable
adjustments (cd /n/<newfs>; chmod 775 .; chgrp sys .) and then back on
the file server console, do

	disallow
	users

and maybe

	dump

Re: [9fans] 9fs nvr file

[erik quanstrom]

how can i do this without a working auth server?

- erik

Re: [9fans] 9fs nvr file

[geoff]

I don't know, offhand, but if you haven't got an auth server then
presumably you don't have an existing /adm/users, so you could
modify my instructions to

	cfs main		# or whatever you called yours
	allow
	create /adm adm sys 775 d
	create /adm/users adm sys 664
	users default

then connect as anybody (9fs <newfs>), make any other desirable
adjustments (cd /n/<newfs>; chmod 775 .; chgrp sys .) and then back on
the file server console, do

	disallow
	# create accounts as necessary with newuser
	dump

Re: [9fans] 9fs nvr file

[erik quanstrom]

thanks for the suggestion.  what i did instead was

	flag noauth

which does what i need to do.  i don't have a suitable machine to run
the auth server on.

i can think of two possible ways of solving this.  either run fossil+auth
on the fs machine or run authsrv on a linux box under p9p.  unfortunately,
i can't boot the distribution from cd on that machine.  there's some 440gx
problem that reboots the machine without warning about the time rio
should start. this was using yesterday's iso.  a bit older distribution failed
from the ide drive as the symbios driver took umbrage over a message
from the card.

oh, and p9p doesn't have authsrv.

i really need to get my act together and cobble together a single-board pc
with a cf drive to run the auth server on. ☺

- erik

p.s.  if you'd be interested in the patch that allows nvr access to a partition.
(preferablly the one you booted from.), i'll submit that.  it's a few lines.  though
they aren't particularly attractive.

one last question: why does the worm writer starve for data rythmically when dumping?
the read/write cycle is about 1.5-2 seconds.  did i configure something wrong?

Re: [9fans] 9fs nvr file

[geoff]

Right, I'd forgotten about noauth.

Sure, send in the nvr patch and I'll look at it.

I think the worm writer is trying to avoid monopolising the jukebox so
that others can use it while the dump is running.  Of course, if you
have a large magnetic disk cache, this is unlikely to be an issue.  If
you're really lucky, your working set of data will fit in the file
server's RAM.

Re: [9fans] 9fs nvr file

[erik quanstrom]

the machine has 512MB of memory.  so most of the working set should fit.
(unless i run linux.)

using the fs instead of a local fossil, i go from 12 second to 13 seconds for
compiling the fs kernel and making an iso.  i believe that most of this is due
to poor ethernet performance -- probablly attributable to the linksys wireless
"router".

i wonder if there's a way to use all of the available i/o with a magnetic disk
while allowing for media switching latency on a real worm?

thanks!

- erik