Re: [9fans] Strange boot behaviour

[Lucio De Re <lucio@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 -----