Re: [9fans] Strange boot behaviour

[Lucio De Re <lucio@proxima.alt.za>]

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