From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lucio De Re To: 9fans@cse.psu.edu Subject: Re: [9fans] Strange boot behaviour Message-ID: <20040217172026.A18955@cackle.proxima.alt.za> References: <20040213081548.K4743@cackle.proxima.alt.za> <20040216083925.A10067@cackle.proxima.alt.za> <20040216112211.A10644@cackle.proxima.alt.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <20040216112211.A10644@cackle.proxima.alt.za>; from Lucio De Re on Mon, Feb 16, 2004 at 11:22:12AM +0200 Date: Tue, 17 Feb 2004 17:20:27 +0200 Topicbox-Message-UUID: e899c6a0-eacc-11e9-9e20-41e7f4b1d025 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 ... 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