From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: To: 9fans@cse.psu.edu Subject: Re: [9fans] venti+fossil, the boot process, and 48-bit lba From: Charles Forsyth In-Reply-To: <20031022172953.GA834@cassie.foobarbaz.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-aeyevpjlqmzfsyvilhlzkrysyf" Date: Wed, 22 Oct 2003 18:58:56 +0100 Topicbox-Message-UUID: 77ee6c80-eacc-11e9-9e20-41e7f4b1d025 This is a multi-part message in MIME format. --upas-aeyevpjlqmzfsyvilhlzkrysyf Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit i see. i'd wondered after i'd posted whether this might be it: the kernel driver doesn't work out partitions on its own any more. the devices' partition tables are set, for instance in /bin/termrc, by disk/fdisk -p and disk/prep -p, into /dev/sd??/ctl, but that's not much help if you need the file systems to get termrc (let alone fdisk or prep), and you need the partitions to find the file system. thus, boot adds the results of its own probe to the internal copy of plan9.ini passed to the kernel, and so the partitions are defined in time for boot to find them. /sys/src/9/port/devsd.c has * Use partitions passed from boot program, * sdC0part=dos 63 123123/plan9 123123 456456 * This happens before /boot sets hostname so the * partitions will have the null-string for user. ... you could configure fdisk and prep into /boot, and have boot use them, but perhaps the easiest change for you might be to stop 9load from checking the values (temporarily) until something better is done. --upas-aeyevpjlqmzfsyvilhlzkrysyf Content-Type: message/rfc822 Content-Disposition: inline Return-path: <9fans-admin@cse.psu.edu> Received: from punt-3.mail.demon.net by mailstore for forsyth@caldo.demon.co.uk id 1ACMpD-0002iy-F8; Wed, 22 Oct 2003 17:31:12 +0000 Received: from [130.203.4.6] (helo=mail.cse.psu.edu) by punt-3.mail.demon.net with esmtp id 1ACMpD-0002iy-F8 for forsyth@caldo.demon.co.uk; Wed, 22 Oct 2003 17:31:11 +0000 Received: by mail.cse.psu.edu (CSE Mail Server, from userid 60001) id B174519AA7; Wed, 22 Oct 2003 13:31:00 -0400 (EDT) Received: from psuvax1.cse.psu.edu (psuvax1.cse.psu.edu [130.203.4.6]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id E17E6199FD; Wed, 22 Oct 2003 13:30:46 -0400 (EDT) X-Original-To: 9fans@cse.psu.edu Delivered-To: 9fans@cse.psu.edu Received: by mail.cse.psu.edu (CSE Mail Server, from userid 60001) id F3F4F19A97; Wed, 22 Oct 2003 13:30:07 -0400 (EDT) Received: from mail.foobarbaz.net (unknown [216.218.196.232]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 3919B199FD for <9fans@cse.psu.edu>; Wed, 22 Oct 2003 13:29:56 -0400 (EDT) Received: by mail.foobarbaz.net (Postfix, from userid 1000) id 3E4C266B45; Wed, 22 Oct 2003 10:29:54 -0700 (PDT) From: Christopher Nielsen To: 9fans@cse.psu.edu Subject: Re: [9fans] venti+fossil, the boot process, and 48-bit lba Message-ID: <20031022172953.GA834@cassie.foobarbaz.net> References: <20031022154323.GY834@cassie.foobarbaz.net> <2fe61d2b01e01d7db540f3315d679848@caldo.demon.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2fe61d2b01e01d7db540f3315d679848@caldo.demon.co.uk> User-Agent: Mutt/1.5.3i Sender: 9fans-admin@cse.psu.edu Errors-To: 9fans-admin@cse.psu.edu X-BeenThere: 9fans@cse.psu.edu X-Mailman-Version: 2.0.11 Precedence: bulk Reply-To: 9fans@cse.psu.edu X-Reply-To: cnielsen@pobox.com List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.cse.psu.edu> List-Archive: Date: Wed, 22 Oct 2003 10:29:53 -0700 X-Spam-Status: No, hits=-5.0 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_MUTT version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) On Wed, Oct 22, 2003 at 04:57:55PM +0100, Charles Forsyth wrote: > >>and head-scratching, it turns out that 9load doesn't know how > ... > >>As a result, when boot tries to start venti and venti > >>tries to find the arenas, it all goes to hell. > > how does 9load cause that to happen? > the thing that starts venti is a normal kernel, which > should handle 48-bit LBA. does 9load (not knowing > about them) leave the ATA in a state where the kernel > can't use 48-bits either? > > i can see that 9load not knowing 48-bit addressing wouldn't > be able to see boot/9fat partitions beyond a certain point, > or perhaps with the right geometry. one more bit of information. when 9load detects the discs, it says it can't add the partitions on the 167G drives because the boundaries are out of range. the upper end of the boundary that it prints is the upper end of 28-bit addressing. that's why i concluded it had to do with 48-bit lba. this is transcribed by hand, but it looks something like this: cannot add sdF0!plan9 [63,351646785) to disk [0,268435455): partition boundaries out of range cannot add sdF1!plan9 [63,351646785) to disk [0,268435455): partition boundaries out of range -- Christopher Nielsen "They who can give up essential liberty for temporary safety, deserve neither liberty nor safety." --Benjamin Franklin --upas-aeyevpjlqmzfsyvilhlzkrysyf--