From mboxrd@z Thu Jan 1 00:00:00 1970 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 Date: Wed, 22 Oct 2003 10:29:53 -0700 Topicbox-Message-UUID: 77d259fa-eacc-11e9-9e20-41e7f4b1d025 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