[9fans] Strange boot behaviour

[9fans] Strange boot behaviour

[Lucio De Re]

Given:

sd53c8xx: SYM53C1010 rev. 0x01 intr=5 command=2300007
sd53c8xx: SYM53C1010 rev. 0x01 intr=10 command=2300007
sd53c8xx: bios scntl3(70) stest2(00)
sd53c8xx: bios scntl3(70) stest2(00)
ether#0: elnk3: port 0x300 irq 11: 00A0244026C9
Unknown boot device: sd00!9fat!9pcf
Boot devices: fd0 ether0
boot from: ether0!/386/9pcf.gz
tickle (192.96.32.69!67): /386/9pcf.gz
gz...874346 => 867828+1146820+108996=2123644
entry: 80100020
Plan 9
apicbase 0xFEE00100
cpu0: 501MHz GenuineIntel Celeron (cpuid: AX 0x0665 DX 0x183F9FF)
ELCR: 1420
#l0: elnk3: 10Mbps port 0x300 irq 11: 00A0244026C9
sd53c8xx: SYM53C1010 rev. 0x01 intr=5 command=2300007
sd53c8xx: SYM53C1010 rev. 0x01 intr=10 command=2300007
#U/usb0: uhci: port 0xE400 irq 10
19287 free pages, 77148K bytes, 309148K swap
root is from (tcp, il, local)[local!#S/sd00/fossil]:
user[none]: glenda
sd53c8xx: bios scntl3(00) stest2(00)
boot: can't connect to file server: '#S/sd00/fossil' does not exist
panic: boot process died: unknown
pdumpstack
anic: boot process died: unknown
ktrace /kernel/path 801serialoq 1758 printed 1770
06978 8000a63c
estackx 8000a8f0
8000a5dc=801067ab 8000a5e4=801ae986 8000a610=8013a6ca 8000a624=80106978
8000a638=80106978 8000a63c=801067af 8000a644=8013a94c 8000a690=801c8960
8000a694=801c89c9 8000a6a4=801c8d4d 8000a6ac=801c8c17 8000a6b8=801c8960
8000a6c4=801c99b1 8000a6d4=801c8b92 8000a6fc=801ca19a 8000a708=8019f282
8000a710=8019f282 8000a718=801b760a 8000a724=801ca50c 8000a730=801aee18
8000a738=801aee64 8000a73c=8019f557 8000a74c=801a9000 8000a758=801a1a79
8000a76c=801abc67 8000a790=801c8b92 8000a7b8=801ca19a 8000a7c8=801b66ca
8000a7d4=801b760a 8000a7d8=801b6ff2 8000a7e8=801b7136 8000a7f4=801b760a
8000a7f8=80307950 8000a7fc=8023431c 8000a800=801c7357 8000a804=8000a820
8000a808=24cdc88c 8000a80c=00000002 8000a810=00001605 8000a814=00000000
8000a818=80300d58 8000a81c=00000000 8000a820=24cdde91 8000a824=00000002
8000a828=805ee480 8000a82c=801b20e9 8000a830=8010603b 8000a834=802ec71c
8000a838=7fffefe8 8000a83c=801c6529 8000a840=00000007 8000a844=00001605
8000a848=00000000 8000a84c=805ee480 8000a850=00001605 8000a854=00000000
8000a858=00000000 8000a85c=7fffefc8 8000a860=802ea978 8000a864=00000000
8000a868=80106d88 8000a86c=80307274 8000a870=00000023 8000a874=00000200
8000a878=7fffefcc 8000a87c=0000001b 8000a880=801027ff 8000a884=00000008
8000a888=8019eead 8000a88c=00000000 8000a890=ffffffff 8000a894=7fffed5c
8000a898=00000000 8000a89c=80100a1e 8000a8a0=8000a8a4 8000a8a4=7fffed5c
8000a8a8=00000000 8000a8ac=00000000 8000a8b0=8000a8c4 8000a8b4=00000000
8000a8b8=ffffffff 8000a8bc=00000001 8000a8c0=00000008 8000a8c4=0000001b
8000a8c8=0000001b 8000a8cc=0000001b 8000a8d0=0000001b 8000a8d4=00000040
8000a8d8=80100569 8000a8dc=00006d96 8000a8e0=00000023 8000a8e4=00000286
8000a8e8=7fffed5c 8000a8ec=0000001b
cpu0: exiting

There are a few questions.

1.  Why does 9load not pick up #S/sd00 as a valid boot location?  It
only offers fd0 and ether0 as options.  Is the missing #S/
significant?  If so, then the installation is faulty.

2.  Why does the fossil kernel 9pcf.gz not find #S/sd00/fossil?  It
was created by the installation procedure and 9pcdisk.gz is aware of
it.  Hm, a missing "disk"?

Note that I have added the PCI IDs for the SCSI controller card to
sd53c8xx.c and this was OK for the installation process.

Lastly, 9loaddebug differs from 9load only in the absence of a -H3
load option and two hash out commands.  It doesn't work, either,
unless the -H3 is entered, in which case it is not different from
9load.  Is it worth keeping?

Suggestions on what I must do to get over this hurdle?  I will try
fossil loaded manually over 9pcdisk.gz, but I'm not sure what I'll
learn from there.

++L

Re: [9fans] Strange boot behaviour

[David Presotto]

On Thu Feb 12 08:50:42 EST 2004, lucio@proxima.alt.za wrote:

> 1.  Why does 9load not pick up #S/sd00 as a valid boot location?  It
> only offers fd0 and ether0 as options.  Is the missing #S/
> significant?  If so, then the installation is faulty.

The #S isn't a problem.  9load doesn't know about # stuff.
Whatever is wrong, this isn't it.

>
> 2.  Why does the fossil kernel 9pcf.gz not find #S/sd00/fossil?  It
> was created by the installation procedure and 9pcdisk.gz is aware of
> it.  Hm, a missing "disk"?

So, if you load a 9pcf and a 9pcdisk both built from the same sources,
one can see #S/sd00/fossil and the other can't?  That should be
impossible.  I have no idea why that would be.

>
> Note that I have added the PCI IDs for the SCSI controller card to
> sd53c8xx.c and this was OK for the installation process.
>

I take it that this:
	sd53c8xx: SYM53C1010 rev. 0x01 intr=5 command=2300007
is your disk.  If so, both the 9pcf kernel and 9load found it.  They
just didn't find the partitions.  Can you boot 9pcf off of a
network file server and see if you can look at the device at
all?  Maybe its not sd00?  What partitions do you see.

This would be the easiest way to figure it all out.

> Lastly, 9loaddebug differs from 9load only in the absence of a -H3
> load option and two hash out commands.  It doesn't work, either,
> unless the -H3 is entered, in which case it is not different from
> 9load.  Is it worth keeping?
>

It's there so we have something to run acid over that is in a format
acid understands.  Acid doesn't do well with the -H3 format.

[9fans] seeking for the truth

[rog]

i was caught up short just now when i tried to reverse
some lines in acme by selecting them and executing "|tail -r".

it didn't work.
the reason?

/sys/src/cmd/tail.c:94: 	seekable = seek(file,0L,0) == 0;

the seek() is succeeding, even though standard input
isn't actually seekable.

the trouble is, it can't do anything else.

we don't see this problem much because of the special case hack for
"#|" in sseek(), but the tail code is a common hack, and an insidious
one.  there are loads of special files around that don't allow
seeking, and many programs that require files that are seekable (diff
being the age-old example).

surely a better solution is possible?  in general, a fileserver knows
whether its files are seekable or not, because it determines how to
interpret the seek offset.

why not add a new bit to the file attributes, say DMNOSEEK (and
associated QTNOSEEK)?  if set, it would indicate that file offsets
when reading and writing the file will be ignored.  0x2 seems to be
available.

then the above line from tail.c could work, and finally it would be
possible to write programs that know definitively whether they are
able to seek on a particular file or not, rather than failing
strangely sometime later.

the amount of code involved would be tiny, and as far as i can see
it would be completely backwardly compatible.

thoughts?

Re: [9fans] seeking for the truth

[David Presotto]

> seeking, and many programs that require files that are seekable (diff
> being the age-old example).

except diff doesn't seek the files it is comparing, only its temps...

> surely a better solution is possible?  in general, a fileserver knows
> whether its files are seekable or not, because it determines how to
> interpret the seek offset.

Fixing all the programs that seek without checking might also be nice.

> why not add a new bit to the file attributes, say DMNOSEEK (and
> associated QTNOSEEK)?  if set, it would indicate that file offsets
> when reading and writing the file will be ignored.  0x2 seems to be
> available.

Maybe, need a few days to think about it.  I'm vaguely disturbed by it
but don't know why.  Perhaps because 9p2000 has no concept of seek and
having a bit that talks about it seems odd.  Then again that's true of the
exec permission bit also...

Re: [9fans] seeking for the truth

[rog]

presotto:
> except diff doesn't seek the files it is comparing, only its temps...

actually, diff only makes temp files if it thinks it has to,
which is why diff <{gunzip<x.gz} <{gunzip<y.gz} didn't work
(actually i think the checks are a bit more rigorous now).

> Maybe, need a few days to think about it.  I'm vaguely disturbed by it
> but don't know why.  Perhaps because 9p2000 has no concept of seek and
> having a bit that talks about it seems odd.  Then again that's true of the
> exec permission bit also...

could call it "QTIGNORESOFFSETS" but i couldn't think of anything
in that line that was snappy enough.

rob:
> i can't get excited about this.  you used the word 'hack'
> yourself to describe the result.

it's a hack now. it wouldn't be if there was some system support
for it.

Re: [9fans] seeking for the truth

[Dave Lukes]

Definite plus vote from me.
Nugatory seeks have annoyed me ever since 6th Ed.

Also,
if anything out there _is_ seek()ing without checking the result,
then either it's broke anyway,
or it knows it can safely ignore the result.
So, off the top of my head, I don't see compatibility as an issue.

Obviously this would need some more looking at,
and a pile of "grep seek ..."s, but it sounds like a plan to me ...

	Dave.

On Thu, 2004-02-12 at 16:16, rog@vitanuova.com wrote:
> i was caught up short just now when i tried to reverse
> some lines in acme by selecting them and executing "|tail -r".
>
> it didn't work.
> the reason?
>
> /sys/src/cmd/tail.c:94: 	seekable = seek(file,0L,0) == 0;
>
> the seek() is succeeding, even though standard input
> isn't actually seekable.
>
> the trouble is, it can't do anything else.
>
> we don't see this problem much because of the special case hack for
> "#|" in sseek(), but the tail code is a common hack, and an insidious
> one.  there are loads of special files around that don't allow
> seeking, and many programs that require files that are seekable (diff
> being the age-old example).
>
> surely a better solution is possible?  in general, a fileserver knows
> whether its files are seekable or not, because it determines how to
> interpret the seek offset.
>
> why not add a new bit to the file attributes, say DMNOSEEK (and
> associated QTNOSEEK)?  if set, it would indicate that file offsets
> when reading and writing the file will be ignored.  0x2 seems to be
> available.
>
> then the above line from tail.c could work, and finally it would be
> possible to write programs that know definitively whether they are
> able to seek on a particular file or not, rather than failing
> strangely sometime later.
>
> the amount of code involved would be tiny, and as far as i can see
> it would be completely backwardly compatible.
>
> thoughts?
>

Re: [9fans] seeking for the truth

[Rob Pike]

dave's right. there's no seek concept in 9P, only offsets.

i can't get excited about this.  you used the word 'hack'
yourself to describe the result.

here's a fix:

	|cat|tail -r

-rob

Re: [9fans] seeking for the truth

[Fco.J.Ballesteros]

> here's a fix:
>
> 	|cat|tail -r

But this shows a non-uniform behaviour.
I'd expect
	|tail -r
to be exactly like
	|cat|tail -r
but for the buffering involved.

I'm not sure about the real fix. My first attempt would
be to ban out seek; although I know that's not feasible in Plan 9...

Re: [9fans] seeking for the truth

[Charles Forsyth]

i'm not enthusiastic about having to change nearly every file server.
status files will be seekable but most synthetic ones won't.
some synthetic files will never be seekable in tail's sense because
they have no end, but they do interpret offsets, so are they QTSEEK or not?

isn't tail's seek an optimisation to avoid reading the file to the end?
unseekable synthetic files typically are length 0 (because they have
no particular length), or tiny (pipes have a hack that stat shows what's in them)
so change the test to declare seekable only if the file is big enough
to warrant it.  one hack deserves another.  then we can get back
to trying to get a version of ghostscript that doesn't blow up on
recent pdf/ps.

Re: [9fans] seeking for the truth

[Charles Forsyth]

>>so change the test to declare seekable only if the file is big enough
>>to warrant it.  one hack deserves another.  then we can get back

simpler might be: seekable = seek(fd, 0, 2) > 0;

Re: [9fans] seeking for the truth

[rob pike, esq.]

> simpler might be: seekable = seek(fd, 0, 2) > 0;

now you're talking.

-rob

Re: [9fans] seeking for the truth

[Charles Forsyth]

i ought to have pointed out that in some applications the
pointer needs to be restored after the seek(,2) test; i knew that
at the time, but it made the general case a bit less pretty!
tail does more messing about than i remembered.

Re: [9fans] seeking for the truth

[rog]

> > simpler might be: seekable = seek(fd, 0, 2) > 0;
>
> now you're talking.

pity it doesn't work on /net/tcp/0/data.

but i always thought that using the file size for "amount of unbuffered data"
was a nasty thing to do... does anything actually use that property?

Re: [9fans] seeking for the truth

[David Presotto]

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

It's true of qio files in general, including pipes.

I've used it often to know how much I can read without blocking.

[-- Attachment #2: Type: message/rfc822, Size: 1977 bytes --]

From: rog@vitanuova.com
To: 9fans@cse.psu.edu
Subject: Re: [9fans] seeking for the truth
Date: Thu, 12 Feb 2004 18:10:18 0000
Message-ID: <3b828656ea8bbad209d8a8a91f883860@vitanuova.com>

> > simpler might be: seekable = seek(fd, 0, 2) > 0;
>
> now you're talking.

pity it doesn't work on /net/tcp/0/data.

but i always thought that using the file size for "amount of unbuffered data"
was a nasty thing to do... does anything actually use that property?

Re: [9fans] seeking for the truth

[Fco.J.Ballesteros]

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

I'd say this is a fundamental problem.
seek has sense for files that are always there.
But, as you said, many of your files are made
on demand, and the seek concept does not
apply well for them.

Isn't just enough to try to keep the seeking programs
to a bare minimum?

[-- Attachment #2: Type: message/rfc822, Size: 2423 bytes --]

From: Charles Forsyth <forsyth@terzarima.net>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] seeking for the truth
Date: Thu, 12 Feb 2004 17:17:59 0000
Message-ID: <c2f71f0dc611079cbba4d0909fc1afff@terzarima.net>

i'm not enthusiastic about having to change nearly every file server.
status files will be seekable but most synthetic ones won't.
some synthetic files will never be seekable in tail's sense because
they have no end, but they do interpret offsets, so are they QTSEEK or not?

isn't tail's seek an optimisation to avoid reading the file to the end?
unseekable synthetic files typically are length 0 (because they have
no particular length), or tiny (pipes have a hack that stat shows what's in them)
so change the test to declare seekable only if the file is big enough
to warrant it.  one hack deserves another.  then we can get back
to trying to get a version of ghostscript that doesn't blow up on
recent pdf/ps.

Re: [9fans] seeking for the truth

[Dave Lukes]

> unseekable synthetic files typically are length 0 (because they have
> no particular length), or tiny (pipes have a hack that stat shows what's in them)

The man is, as usual, correct:
I had my mind too far into a un*x model of files/devices/pipes only.
My apologies.

> so change the test to declare seekable only if the file is big enough
> to warrant it.
:-))

>   one hack deserves another.  then we can get back
> to trying to get a version of ghostscript that doesn't blow up on
> recent pdf/ps.

Amen.
	Dave.

Re: [9fans] seeking for the truth

[boyd, rounin]

> thoughts?

seeking on pipes doesn't scale.

adding more junk to support special cases is a bad idea.

Re: [9fans] Strange boot behaviour

[Lucio De Re]

On Thu, Feb 12, 2004 at 09:35:59AM -0500, David Presotto wrote:
>
> On Thu Feb 12 08:50:42 EST 2004, lucio@proxima.alt.za wrote:
>
> > 1.  Why does 9load not pick up #S/sd00 as a valid boot location?  It
> > only offers fd0 and ether0 as options.  Is the missing #S/
> > significant?  If so, then the installation is faulty.
>
> The #S isn't a problem.  9load doesn't know about # stuff.
> Whatever is wrong, this isn't it.
>
There is no 9pcf in 9fat, but the error message suggests that the
"device" is unknown.  New trace below.
> >
> > 2.  Why does the fossil kernel 9pcf.gz not find #S/sd00/fossil?  It
> > was created by the installation procedure and 9pcdisk.gz is aware of
> > it.  Hm, a missing "disk"?
>
> So, if you load a 9pcf and a 9pcdisk both built from the same sources,
> one can see #S/sd00/fossil and the other can't?  That should be
> impossible.  I have no idea why that would be.
>
It isn't impossible, unless I'm misreading the new trace (appended
below).  It is extremely unlikely that the 9pcdisk and 9pcf kernels
are significantly different because of something I did and I suppose
supplying sources etc won't really help unless I supply the hardware
too :-(
>
> I take it that this:
> 	sd53c8xx: SYM53C1010 rev. 0x01 intr=5 command=2300007

and the next one, I'm not sure which one was used.  Maybe there's a
problem with a twin controller?

> is your disk.  If so, both the 9pcf kernel and 9load found it.  They
> just didn't find the partitions.  Can you boot 9pcf off of a
> network file server and see if you can look at the device at
> all?  Maybe its not sd00?  What partitions do you see.
>
9pcf is loaded off the network, it turned out to be the easiest route.
But I think you're asking something else, really.

> This would be the easiest way to figure it all out.
>
> > Lastly, 9loaddebug differs from 9load only in the absence of a -H3
> > load option and two hash out commands.  It doesn't work, either,
> > unless the -H3 is entered, in which case it is not different from
> > 9load.  Is it worth keeping?
> >
>
> It's there so we have something to run acid over that is in a format
> acid understands.  Acid doesn't do well with the -H3 format.

That explains.  I was hoping it was a version with debug enabled, but
that's not applicable.  I'll do some homework.

Here is the new boot trace, using 9pcdisk.gz instead of 9pcf.gz,
annotated:

----- cut here -----
sd53c8xx: SYM53C1010 rev. 0x01 intr=5 command=2300007
sd53c8xx: SYM53C1010 rev. 0x01 intr=10 command=2300007
sd53c8xx: bios scntl3(70) stest2(00)
sd53c8xx: bios scntl3(70) stest2(00)
ether#0: elnk3: port 0x300 irq 11: 00A0244026C9
Unknown boot device: sd00!9fat!9pcf
^^^^^^^ I can put 9pcf on 9fat, if it helps
Boot devices: fd0 ether0
boot from: ether0!/386/9pcdisk.gz
           ^^^^^^^^^^^^^^^^^^^^^^ note network boot
tickle (192.96.32.69!67): /386/9pcdisk.gz
gz...729520 => 867796+818960+108996=1795752
entry: 80100020
Plan 9
apicbase 0xFEE00100
cpu0: 501MHz GenuineIntel Celeron (cpuid: AX 0x0665 DX 0x183F9FF)
ELCR: 1420
#l0: elnk3: 10Mbps port 0x300 irq 11: 00A0244026C9
sd53c8xx: SYM53C1010 rev. 0x01 intr=5 command=2300007
sd53c8xx: SYM53C1010 rev. 0x01 intr=10 command=2300007
#U/usb0: uhci: port 0xE400 irq 10
19335 free pages, 77340K bytes, 309340K swap
root is from (tcp, il, local)[local!#S/sd00/fossil]: il
^^^^^^^^^^^^                                         ^^ and network FS
user[none]: glenda
sd53c8xx: bios scntl3(00) stest2(00)
sd53c8xx: bios scntl3(00) stest2(00)
version...
!Adding key: dom=proxima.alt.za proto=p9sk1
user[glenda]:
password:
!
time...
init: starting /bin/rc
dossrv: serving #s/dos
9660srv 68: serving /srv/9660
----- cut here -----

Re: [9fans] Strange boot behaviour

[Lucio De Re]

On Fri, Feb 13, 2004 at 08:15:48AM +0200, Lucio De Re wrote:
>
> On Thu, Feb 12, 2004 at 09:35:59AM -0500, David Presotto wrote:
> >
> > So, if you load a 9pcf and a 9pcdisk both built from the same sources,
> > one can see #S/sd00/fossil and the other can't?  That should be
> > impossible.  I have no idea why that would be.
> >
> It isn't impossible, unless I'm misreading the new trace (appended
> below).  It is extremely unlikely that the 9pcdisk and 9pcf kernels
> are significantly different because of something I did and I suppose
> supplying sources etc won't really help unless I supply the hardware
> too :-(
> >
For the record, running fossil on top of a network loaded 9pcdisk
(with the necessary tweaks to recognise the SCSI controller - added
below unless I forget), seems just fine.  Not that I've done anything
extraordinary with it, not a Venti in sight, for example.

I just want the machine to be self-contained and running a CPU
kernel, so I still need a solution to my problem.  My feeling is
that somehow the partition information is not being read correctly,
but there isn't any obvious reason for it.

If no one has a better suggestion, I'll try to add debugging
information to 9load and the various kernels and watch what happens,
over the weekend.

++L

Re: [9fans] Strange boot behaviour

[David Presotto]

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

You had two problems:

1) 9load told you

	Unknown boot device: sd00!9fat!9pcf

   i.e., it wasn't seeing the 9fat partition.

2) your booted kernel could not start from the partition

	root is from (tcp, il, local)[local!#S/sd00/fossil]:
	user[none]: glenda
	sd53c8xx: bios scntl3(00) stest2(00)
	boot: can't connect to file server: '#S/sd00/fossil' does not exist

All I suggested was that you boot 9pcf off of the net, connect to a root
file system on another machine, and then start from there to debug
your problem, i.e., see if you could then see '#S/sd00/fossil' etc.

You clearly did all the nice booting as your carets indicate:

boot from: ether0!/386/9pcdisk.gz
           ^^^^^^^^^^^^^^^^^^^^^^ note network boot
...
root is from (tcp, il, local)[local!#S/sd00/fossil]: il
^^^^^^^^^^^^                                         ^^ and network FS

However you never got to the important part, i.e., to figure out
why 9pcf couldn't see your disk.  Why did you boot 9pcdisk instead
of a 9pcf?  We need to find out why 9pcf won't find your disk.  Booting
a kernel you already know works won't get you anywhere closer to the
problem.  You need to get a 9pcf working on your machine and then start
trying to figure out what is wrong.

[-- Attachment #2: Type: message/rfc822, Size: 6149 bytes --]

From: Lucio De Re <lucio@proxima.alt.za>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Strange boot behaviour
Date: Fri, 13 Feb 2004 08:15:48 +0200
Message-ID: <20040213081548.K4743@cackle.proxima.alt.za>

On Thu, Feb 12, 2004 at 09:35:59AM -0500, David Presotto wrote:
>
> On Thu Feb 12 08:50:42 EST 2004, lucio@proxima.alt.za wrote:
>
> > 1.  Why does 9load not pick up #S/sd00 as a valid boot location?  It
> > only offers fd0 and ether0 as options.  Is the missing #S/
> > significant?  If so, then the installation is faulty.
>
> The #S isn't a problem.  9load doesn't know about # stuff.
> Whatever is wrong, this isn't it.
>
There is no 9pcf in 9fat, but the error message suggests that the
"device" is unknown.  New trace below.
> >
> > 2.  Why does the fossil kernel 9pcf.gz not find #S/sd00/fossil?  It
> > was created by the installation procedure and 9pcdisk.gz is aware of
> > it.  Hm, a missing "disk"?
>
> So, if you load a 9pcf and a 9pcdisk both built from the same sources,
> one can see #S/sd00/fossil and the other can't?  That should be
> impossible.  I have no idea why that would be.
>
It isn't impossible, unless I'm misreading the new trace (appended
below).  It is extremely unlikely that the 9pcdisk and 9pcf kernels
are significantly different because of something I did and I suppose
supplying sources etc won't really help unless I supply the hardware
too :-(
>
> I take it that this:
> 	sd53c8xx: SYM53C1010 rev. 0x01 intr=5 command=2300007

and the next one, I'm not sure which one was used.  Maybe there's a
problem with a twin controller?

> is your disk.  If so, both the 9pcf kernel and 9load found it.  They
> just didn't find the partitions.  Can you boot 9pcf off of a
> network file server and see if you can look at the device at
> all?  Maybe its not sd00?  What partitions do you see.
>
9pcf is loaded off the network, it turned out to be the easiest route.
But I think you're asking something else, really.

> This would be the easiest way to figure it all out.
>
> > Lastly, 9loaddebug differs from 9load only in the absence of a -H3
> > load option and two hash out commands.  It doesn't work, either,
> > unless the -H3 is entered, in which case it is not different from
> > 9load.  Is it worth keeping?
> >
>
> It's there so we have something to run acid over that is in a format
> acid understands.  Acid doesn't do well with the -H3 format.

That explains.  I was hoping it was a version with debug enabled, but
that's not applicable.  I'll do some homework.

Here is the new boot trace, using 9pcdisk.gz instead of 9pcf.gz,
annotated:

----- cut here -----
sd53c8xx: SYM53C1010 rev. 0x01 intr=5 command=2300007
sd53c8xx: SYM53C1010 rev. 0x01 intr=10 command=2300007
sd53c8xx: bios scntl3(70) stest2(00)
sd53c8xx: bios scntl3(70) stest2(00)
ether#0: elnk3: port 0x300 irq 11: 00A0244026C9
Unknown boot device: sd00!9fat!9pcf
^^^^^^^ I can put 9pcf on 9fat, if it helps
Boot devices: fd0 ether0
boot from: ether0!/386/9pcdisk.gz
           ^^^^^^^^^^^^^^^^^^^^^^ note network boot
tickle (192.96.32.69!67): /386/9pcdisk.gz
gz...729520 => 867796+818960+108996=1795752
entry: 80100020
Plan 9
apicbase 0xFEE00100
cpu0: 501MHz GenuineIntel Celeron (cpuid: AX 0x0665 DX 0x183F9FF)
ELCR: 1420
#l0: elnk3: 10Mbps port 0x300 irq 11: 00A0244026C9
sd53c8xx: SYM53C1010 rev. 0x01 intr=5 command=2300007
sd53c8xx: SYM53C1010 rev. 0x01 intr=10 command=2300007
#U/usb0: uhci: port 0xE400 irq 10
19335 free pages, 77340K bytes, 309340K swap
root is from (tcp, il, local)[local!#S/sd00/fossil]: il
^^^^^^^^^^^^                                         ^^ and network FS
user[none]: glenda
sd53c8xx: bios scntl3(00) stest2(00)
sd53c8xx: bios scntl3(00) stest2(00)
version...
!Adding key: dom=proxima.alt.za proto=p9sk1
user[glenda]:
password:
!
time...
init: starting /bin/rc
dossrv: serving #s/dos
9660srv 68: serving /srv/9660
----- cut here -----

Re: [9fans] Strange boot behaviour

[Lucio De Re]

On Sat, Feb 14, 2004 at 04:49:16PM -0500, David Presotto wrote:
>
> However you never got to the important part, i.e., to figure out
> why 9pcf couldn't see your disk.  Why did you boot 9pcdisk instead
> of a 9pcf?  We need to find out why 9pcf won't find your disk.  Booting
Because I had already booted 9pcf in the previous trial, the one I
first mailed off.  Sorry, I should have repeated the details.  I did
mention in my second message that my fist try had used net booting.

> a kernel you already know works won't get you anywhere closer to the
> problem.  You need to get a 9pcf working on your machine and then start
> trying to figure out what is wrong.

Point taken.  I will repeat some of the experiments, I was hoping to
get to them over the weekend, I'll have to do it today.

++L

Re: [9fans] Strange boot behaviour

[Lucio De Re]

On Sat, Feb 14, 2004 at 04:49:16PM -0500, David Presotto wrote:
>
> All I suggested was that you boot 9pcf off of the net, connect to a root
> file system on another machine, and then start from there to debug
> your problem, i.e., see if you could then see '#S/sd00/fossil' etc.
>
I did miss something: "connect to a root file system on another
machine".  Will do now...

++L

Re: [9fans] Strange boot behaviour

[Lucio De Re]

On Mon, Feb 16, 2004 at 08:39:26AM +0200, Lucio De Re wrote:
> On Sat, Feb 14, 2004 at 04:49:16PM -0500, David Presotto wrote:
> >
> > All I suggested was that you boot 9pcf off of the net, connect to a root
> > file system on another machine, and then start from there to debug
> > your problem, i.e., see if you could then see '#S/sd00/fossil' etc.
> >
> I did miss something: "connect to a root file system on another
> machine".  Will do now...
>
I missed something even more obvious:

	boot from: ether0!/386/9pcf.gz
	tickle (192.96.32.69!67): /386/9pcf.gz
	gz...
	874346 => 867828+1146820+108996=2123644
	entry: 80100020

	Plan 9
	apicbase 0xFEE00100
	cpu0: 501MHz GenuineIntel Celeron (cpuid: AX 0x0665 DX 0x183F9FF)
	ELCR: 1420
	#l0: elnk3: 10Mbps port 0x300 irq 11: 00A0244026C9
	sd53c8xx: SYM53C1010 rev. 0x01 intr=5 command=2300007
	sd53c8xx: SYM53C1010 rev. 0x01 intr=10 command=2300007
	#U/usb0: uhci: port 0xE400 irq 10
	19287 free pages, 77148K bytes, 309148K swap
	root is from (tcp, il, local)[local!#S/sd00/fossil]: local
					    ^^^^^^^^ this is OK
	user[none]: lucio
	sd53c8xx: bios scntl3(00) stest2(00)
	sd53c8xx: bios scntl3(00) stest2(00)
	bopanic: boot process died: unknown
	ot: can't connect to file server: '#S/sdC0/' file does not exist
					   ^^^^^^^^ this I overlooked
	pdumpstack
	anic: boot process died: unknown

So I built a new kernel using pccpuf (my eventual target) with a
modified boot line as /386/9pccpufs.gz.

The effect was different, but disappointing:

	boot from: ether0!/386/9pccpufs.gz
	tickle (192.96.32.69!67): /386/9pccpufs.gz
	gz...870094 => 864947+1145560+142496=2153003
	entry: 80100020

	Plan 9
	apicbase 0xFEE00100
	cpu0: 501MHz GenuineIntel Celeron (cpuid: AX 0x0665 DX 0x183F9FF)
	ELCR: 1420
	#l0: elnk3: 10Mbps port 0x300 irq 11: 00A0244026C9
	sd53c8xx: SYM53C1010 rev. 0x01 intr=5 command=2300007
	sd53c8xx: SYM53C1010 rev. 0x01 intr=10 command=2300007
	#U/usb0: uhci: port 0xE400 irq 10
	22495 free pages, 89980K bytes, 729980K swap
	root is from (tcp, il, local)[local!#S/sd00/fossil]:
	sd53c8xx: bios scntl3(00) stest2(00)
	sd53c8xx: bios scntl3(00) stest2(00)
	can't read nvram: i/o error
	authid: proxima
	authdom: proxima.alt.za
	secstore key:
	password: password:
	can't write key to nvram: fd out of range or not open

Now it no longer complains about #S/sd00, but it still can't find
the partitions.  Wasn't there some mail about setting up the
partitions early, a while back?  I missed the importance of that
thread at the time, I'll refresh my memory right now.

Well, it looks to me like I need some adjustments to 9load to
identify the partitions on a SCSI disk, as (a) 9load itself fails
to find the partition table (but prep/fdisk succeed) and (b) that
would explain why 9pcf gets similarly lost.

I'll use Russ's part.c of 8 Nov '03 to do some testing.

++L

Re: [9fans] Strange boot behaviour

[Lucio De Re]

On Mon, Feb 16, 2004 at 11:22:12AM +0200, Lucio De Re wrote:
>
> On Mon, Feb 16, 2004 at 08:39:26AM +0200, Lucio De Re wrote:
>
> Well, it looks to me like I need some adjustments to 9load to
> identify the partitions on a SCSI disk, as (a) 9load itself fails
> to find the partition table (but prep/fdisk succeed) and (b) that
> would explain why 9pcf gets similarly lost.
>
Sorry to leave you all on tenterhooks <grin>...

I was offline yesterday, just beofer sending off a long, probably
off-topic comment about progress of some description.

It turned out that the SCSI subsystem needed tweaking.  I still don't
know why, but the most significant change was in:

/n/dump/2004/0216/sys/src/boot/pc/sdscsi.c:71 a /sys/src/boot/pc/sdscsi.c:72,75
>if(r->sense[12] == 0x04 && (r->sense[13] == 0x02 || r->sense[13] == 0x01)){
>	status = SDok;
> 	break;
>}

(leading spaces removed for readability).  This was adapted from
/sys/src/9/pc/sdscsi.c where the test reads:
>if(r->sense[12] == 0x04 && r->sense[13] == 0x02){

Having fixed this, I have a Venti-less Fossil.  While we're on the
subject of SCSI, the following changes to sd53c8xx.c are advantageous:

sd53c8xx.c:1825 c /n/dump/2004/0212/sys/src/boot/pc/sd53c8xx.c:1818
< 	KPRINT("sd53c8xx: bios scntl3(%.2x) stest2(%.2x)\n", c->bios.scntl3, c->bios.stest2);
---
> 	print("sd53c8xx: bios scntl3(%.2x) stest2(%.2x)\n", c->bios.scntl3, c->bios.stest2);
sd53c8xx.c:1851 d /n/dump/2004/0212/sys/src/boot/pc/sd53c8xx.c:1843
< #define SYM_1011_DID	0x0021
sd53c8xx.c:1871 d /n/dump/2004/0212/sys/src/boot/pc/sd53c8xx.c:1862
< { SYM_1011_DID,   0xff, "SYM53C1010",	Burst128, 16, 64, Prefetch|LocalRAM|BigFifo|Wide|Ultra|Ultra2 },

The first part silences an annoying debug statement (Nigel Roles
may disagree, still...), the latter allows me to use the KOUWELL
"PCI to Dual Channel Unltra 3 SCSI Card" that uses a slightly newer
SYM53C1010 controller.  To be precise the identification seems to
be SYM53C1010-66 if someone wants/needs to be pedantic.

Analogous changes apply to /sys/src/9/pc/sd53c8xx.c.  There is a
discrepancy between the 9/pc and boot/pc versions that may or may not be significant,
drop me a line if you want the details.

Then, to finish off, Fossil.  I seem to have screwed up my
installation by mismatching fossil binaries.  I don't recall the exact
details, but I definitely had different executables in /boot/fossil
and /386/bin/fossil/fossil.  By the time I copied /boot/fossil into
the /386/bin/fossil directory, I think some damage was already done.

I'm not sure if I'll be able to fix it, either, as what is probably a
third version of fossil/flchk (sigh!) reports:

	squiggle# fossil/flchk -f /dev/sd00/fossil
	cacheLocalData: addr=80992 type got 0 exp 8: tag got 76c04b7a exp 1
	fsOpen error
	fatal error: could not open file system: block label mismatch

I don't think I have enough time now to investigate further.  I do
wonder, though, if problems with "snap -a" might have the same
origin.

I certainly did report flchk failures a long time ago, immediately
after a manual snap -a and the reason I didn't pursue it at the
time was because the manual warns one against taking such failures
seriously when fossil is active.  That warning needs rewording as
it encourages one to expect the worse whether fossil is running or
not.

++L

Re: [9fans] seeking for the truth

[David Presotto]

I can't find anything that currently uses on the length of
stream files, just debugging stuff I have.  I'ld be willing to
get rid of the length, though its helped me many times
debugging things especially with IP.

Re: [9fans] seeking for the truth

[rog]

> I'ld be willing to
> get rid of the length, though its helped me many times
> debugging things especially with IP.

wouldn't it be more appropriate to have it available
in another file (e.g. status)?

Re: [9fans] seeking for the truth

[David Presotto]

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

The problem is that the file isn't always there, as in pipes.

[-- Attachment #2: Type: message/rfc822, Size: 1919 bytes --]

From: rog@vitanuova.com
To: 9fans@cse.psu.edu
Subject: Re: [9fans] seeking for the truth
Date: Thu, 12 Feb 2004 18:30:14 0000
Message-ID: <c901327c41d26f44589e429d49ed219a@vitanuova.com>

> I'ld be willing to
> get rid of the length, though its helped me many times
> debugging things especially with IP.

wouldn't it be more appropriate to have it available
in another file (e.g. status)?

Re: [9fans] seeking for the truth

[boyd, rounin]

> wouldn't it be more appropriate to have it available
> in another file (e.g. status)?

no, we already have the length and i think it should
indicate the amount of readable data (like a real
file) on pipes and network connections and other
'synthetic' files, if that information is available.

Re: [9fans] seeking for the truth

[Scott Schwartz]

On Thu, Feb 12, 2004 at 01:19:51PM -0500, David Presotto wrote:
> I can't find anything that currently uses on the length of
> stream files, just debugging stuff I have.  I'ld be willing to
> get rid of the length, though its helped me many times
> debugging things especially with IP.

I'm not sure I like getting rid of it;  I feel like buffers ought to
have a cheap way to ask how full they are.

Re: [9fans] seeking for the truth

[rog]

> I'm not sure I like getting rid of it;  I feel like buffers ought to
> have a cheap way to ask how full they are.

stat is no cheaper than read.

and since we have fd2path, it's not too difficult to work out where to
find the information (for /net at any rate), even if you only have a
file descriptor.

Re: [9fans] seeking for the truth

[boyd, rounin]

> > I'm not sure I like getting rid of it;  I feel like buffers ought to
> > have a cheap way to ask how full they are.
>
> stat is no cheaper than read.

ls -l and others use stat, not read.

Re: [9fans] seeking for the truth

[David Presotto]

OK.  Pipes, uarts, and tcp data files now stat as 0 length.  I'll probably
change the stats files for uarts and tcp to show how much is really there
for debuggering.