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: <20040213081548.K4743@cackle.proxima.alt.za> References: <20040212154846.E4743@cackle.proxima.alt.za> <7264eca72458d500639cb8fcb8c4ca79@plan9.bell-labs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <7264eca72458d500639cb8fcb8c4ca79@plan9.bell-labs.com>; from David Presotto on Thu, Feb 12, 2004 at 09:35:59AM -0500 Date: Fri, 13 Feb 2004 08:15:48 +0200 Topicbox-Message-UUID: e1bad3b0-eacc-11e9-9e20-41e7f4b1d025 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 -----