Re: [9fans] fs incompatable w/ ASUS CUSL2

Re: [9fans] fs incompatable w/ ASUS CUSL2

[Russ Cox]

Sorry, I'd zoned out in this conversation,
since I don't deal with fs stuff very often.
I tried Eric's file server and couldn't get
the file server to talk back to me after typing
"end", nor could I get anything useful over the
serial console.

Eric's tarball, I believe, is based on the
second edition code.  I started with the current
file server code from /sys/src/fs and merged the
IDE stuff in, and my serial problems went away.
I don't know what the problem was, just that it 
went away when I started over with the current fs code.

I should also mention that I too had problems while
using the p driver (disk subpartitions).  I never
did figure out what went wrong, but after a day or
two of running I rebooted my file server and there
was a postscript file in my superblock and a 
directory listing in my root file system block.
At that point I figured out my kfs problem (which
for once wasn't kfs's fault) and stopped using
the file server.  The p driver problems might
not have been in the code, though.  The machine
I was using for a file server had been discarded
by the support staff at school because it randomly
rebooted while running Linux.  It seemed to work
fine for me, except that I noticed the power
supply fan wasn't spinning.  I replaced the power
supply, but only after my superblock had morphed,
so I don't know whether the problem was with the
fs code or just hardware.  I've since been
distracted by other things and haven't gotten back
to trying with a working power supply.

Russ

Re: [9fans] fs incompatable w/ ASUS CUSL2

[Eric Dorman]

Russ Cox wrote:
> Eric's tarball, I believe, is based on the
> second edition code.  I started with the current
> file server code from /sys/src/fs and merged the
> IDE stuff in, and my serial problems went away.
> I don't know what the problem was, just that it
> went away when I started over with the current fs code.

Zounds!  I hadn't realized I'd screwed up the tarball like 
that.  That'll larn me.  That explains a few things.

--eric

Re: [9fans] fs incompatable w/ ASUS CUSL2

[Eric Dorman]

Ed Brown wrote:
> Actually,
> So did I.  The cpu and standalone kernels
> worked on the board without a glitch.  It was
> the file server kernel that had the problem.
> 
> The problem started with the uart access in
> wwvtime() and then there was something else
> which I could not identify.
> 
> "Douglas A. Gwyn" wrote:
> >
> > Strange; I put Plan 9r3 (standalone) on a CUSL2 with no problem
> > (apart from the problem with 2 sizes of floppy disks, fixed by
> > disabling the 5.25" one during installation).  I'm curious about
> > the specific problem cause.

Interesting.. the comment about uart access reminds
me of a fix Russ contacted me about when he attempted
to use my idefs stuff I posted shortly ago; he had to
change update/change/modify something/somewhere (Russ,
help me!) and his uart problems went away.  Perhaps
this is all related.

--eric

Re: [9fans] fs incompatable w/ ASUS CUSL2

[Ed Brown]

Actually,
So did I.  The cpu and standalone kernels
worked on the board without a glitch.  It was
the file server kernel that had the problem.

The problem started with the uart access in
wwvtime() and then there was something else
which I could not identify.

"Douglas A. Gwyn" wrote:
> 
> Strange; I put Plan 9r3 (standalone) on a CUSL2 with no problem
> (apart from the problem with 2 sizes of floppy disks, fixed by
> disabling the 5.25" one during installation).  I'm curious about
> the specific problem cause.

Re: [9fans] fs incompatable w/ ASUS CUSL2

[Douglas A. Gwyn]

Strange; I put Plan 9r3 (standalone) on a CUSL2 with no problem
(apart from the problem with 2 sizes of floppy disks, fixed by
disabling the 5.25" one during installation).  I'm curious about
the specific problem cause.

Re: [9fans] fs incompatable w/ ASUS CUSL2

[Eric Dorman]

Martin Harriss wrote:
> Ed Brown wrote:
> > ...
> > A long running program that accessed the
> > ide file system sdta during a dump
> > caused the file server to throw a
> > hissy.  After that point I received
> > phase errors on any files on sdta.
> > Doing a check on sdta from the file server
> > caused it to reboot.  I could get
> > the file server to reboot from a terminal
> > by doing an ls on the root of sdta or
> > an ls in the first dump of main.
> > ...
> 
> Locking not quite worked out for devata????
> 
> --Martin

Certainly possible, though when I was working on it 
and had lock synchronization problems the FS would
die with a 'lock not held' or somesuch; it's fuzzy now.
Generally the FS would die rather than do unpleasant
things to the filesystem (which is fine by me :) ).
That would only occur, however, when there were two
IDEs trying to be active simultaneously, vice the one 
Ed has; seems to me there *shouldn't* (famous last
word!) be conflicts between ide and scsi.

Glad you got it working, Ed.

--eric

Re: [9fans] fs incompatable w/ ASUS CUSL2

[Martin Harriss]

Ed Brown wrote:
> ...
> A long running program that accessed the
> ide file system sdta during a dump
> caused the file server to throw a
> hissy.  After that point I received
> phase errors on any files on sdta.
> Doing a check on sdta from the file server
> caused it to reboot.  I could get
> the file server to reboot from a terminal
> by doing an ls on the root of sdta or
> an ls in the first dump of main.
> ...

Locking not quite worked out for devata????

--Martin

[9fans] fs incompatable w/ ASUS CUSL2

[Ed Brown]

Changing my fileserver motherboard from an
ASUS CUSL2 to an ABIT VL6 fixed all of my
fileserver installation blues...almost

Word of warning...(this may be a bug or
just dumb on my part)  I initially used
an ide drive with a partition for a
pseudo worm and an uncached file system.
That is,
	config w0
	filsys main cp(w0)0.12fp(h0)0.85
	filsys dump o
	filsys tdta p(w0)12.88
	filsys sdta p(h0)85.15

My reasoning was I needed as much space
for large temporary files as possible.

A long running program that accessed the
ide file system sdta during a dump 
caused the file server to throw a
hissy.  After that point I received
phase errors on any files on sdta.  
Doing a check on sdta from the file server
caused it to reboot.  I could get
the file server to reboot from a terminal
by doing an ls on the root of sdta or
an ls in the first dump of main.

Nonetheless I have changed my file server
configuration to
	config w0
	filsys main cp(w0)0.12fh0
	filsys dump o
	filsys tdta p(w0)12.88

And have had no troubles since...
Moral of the story. KISS

On other matters, I would not have
gotten this far if it weren't for the
helpful pointers of:
Forsyth, Dorman, Harriss, and Mehat
Thank you all.