9ssfs and 9sscpu

9ssfs and 9sscpu

[Steve_Kilbane]

More info...
> I'll see if I can find out why wreninit() manages
> to break things afterwards

dr->mult evalutes to zero, so there's a division by zero trap.

9ssfs and 9sscpu

[Steve_Kilbane]

Back in December, I mentioned I was having problems getting 9ssfs to
scribble on a disk. I've had a deeper look, and I'm still baffled, but I can
at least give a little more detail. The physical setup is a 16MB SLC with
three 207MB Sun disks attached (SCSI targets 1-3).

wreninit() calls scsidrive(), calls probe(), calls scsiio(). For ids 0-6,
there's a delay of 60 seconds, then scsiio() returns 0. Id 7 is skipped.
scsidrive() returns something which wreninit() thinks is valid, so
it goes ahead, there's another delay, and then a kernel panic.

I know nothing about SCSI drivers, but two things strike me. The
first is that the disks are fine (they were in use under SunOS until
I swiped them), so I guess the probe shouldn't be reaching its
timeout limit, but it is. The second is that wreninit() still gets something
valid back. probe() seems to default to the drive being ready, unless
it gets definite notification otherwise.

I could only see one mention of boddles for fs, and that was for the
PC-specific stuff. I'll see if I can find out why wreninit() manages
to break things afterwards, but I'd be grateful for any suggestions - 
I'm pretty much clutching at straws in the dark here, to mix a
metaphore or two.

steve

9ssfs and 9sscpu

[forsyth]

>>auth server list the auth server's address as 0.0.0.0.  Just give it
>>its real ip address and let it time out.
there's a trick that usually works more quickly.  use 0.1.0.0 .
don't ask; see the code.

9ssfs and 9sscpu

[Scott]

Steve_Kilbane@cegelecproj.co.uk (Steve_Kilbane) writes:
| 9sscpu problem:

There were a number of sparcstation related bugs in the cdrom release,
like the missing entry from ndb, and a bug in wrkey.  The fixes should
be included in the boddles, but until you apply them authentication
won't work.  One unfixed (I think) problem is that you cannot have the
auth server list the auth server's address as 0.0.0.0.  Just give it
its real ip address and let it time out.

| For some reason, the authid in the nvram was already all zeroes, with
| a checksum of 9, which gets it through the checks. The console device
| doesn't like you writing empty strings to #c/hostowner, though.

Did you run wrkey before installing the fix?  One way to clean out
misinformation in eeprom is to boot sunos and run "cat /dev/zero
/dev/eeprom".

9ssfs and 9sscpu

[Steve_Kilbane]

9sscpu problem:
For some reason, the authid in the nvram was already all zeroes, with
a checksum of 9, which gets it through the checks. The console device
doesn't like you writing empty strings to #c/hostowner, though.
Don't know whether I was just unlucky, or I'd put a null password
in there at some time in the past (can you?). It's failing on the mount now,
which, as forsyth suggested in email, is probably because I don't have
the right information in the u9fs's files.

Sudden thought: I've been alternating 9ss and 9ssfs on this machine -
is 9ss clearing the authid?

steve

9ssfs and 9sscpu

[Steve_Kilbane]

After a long hiatus, I've finally got another chance to try to get my system
up and running. I've got one ss2 and two SLCs that I can play with, off
and on, plus another ss2 u9fs server. But no PCs, so I'm fumbling around
a bit here.

Trying to boot 9ssfs on an SLC fails. After entering the config: info for
a single 207MB SCSI disk [I was going to copy stuff onto it manually...],
I get a panic. The disk config was simply:

config w3
filsys main w3
ream main
end

It does:
sysinit
	devinit D6.0.3.0
for a reasonable length of time (about ten minutes), and then the screen fills
with a stack trace, and the messages:
1156 stack used out of 4000
panic: kernel trap: trap: unaligned address pc=0xe0031d44

Not to worry, I thought, I'll forego the fs for now, and use the u9fs machine
instead. It's the auth server I'm worried about, anyway.

I tried following Will Rose's instructions [2 Nov], but booting 9sscpu
doesn't seem to work. On the SLC, all I get is:

session...boot: mount: unknown user or group

...regardless of what I give it for the auth server's address. Incidentally,
9ss still boots ok, using u9fs, auth server 0.0.0.0 and user none.

Attempting to boot 9sscpu on the ss2 is more worrying. As soon as I enter
a response for the auth server prompt, I get:

boot: #c/hostowner: bad arg in system call

which seems to be specific enough to nail it down to
/sys/src/9/boot/key.c:72. However, looking at this file, it seems to me that
I should have also received a "bad authentication id" message, and
prompts for password, authid and authdom, but none of this appears.

I'm not too worried about getting the fs going just yet, but I would like to
be able to get a cpu server up and running. Any suggestions?

steve