Date: Thu, 10 Oct 2002 23:01:24 +0200 From: Bernd Walter <ticso@cicely8.cicely.de> To: Poul-Henning Kamp <phk@critter.freebsd.dk> Cc: ticso@cicely.de, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: booting UFS2 on alpha (was: cvs commit: src/sys/boot/common ufsread.c) Message-ID: <20021010210124.GV17920@cicely8.cicely.de> In-Reply-To: <20021009195233.GQ17920@cicely8.cicely.de> References: <20021009174457.GP17920@cicely8.cicely.de> <11046.1034186034@critter.freebsd.dk> <20021009195233.GQ17920@cicely8.cicely.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Oct 09, 2002 at 09:52:34PM +0200, Bernd Walter wrote: > On Wed, Oct 09, 2002 at 07:53:54PM +0200, Poul-Henning Kamp wrote: > > In message <20021009174457.GP17920@cicely8.cicely.de>, Bernd Walter writes: > > >On Tue, Oct 08, 2002 at 08:46:45AM -0700, Poul-Henning Kamp wrote: > > >> phk 2002/10/08 08:46:45 PDT > > >> > > >> Modified files: > > >> sys/boot/common ufsread.c > > >> Log: > > >> It seems that the only problem with UFS2 booting on i386 is the 64bit > > >> divide/remainder calls. For reasons not resolved, compiling the > > >> relevant routines from libkern into boot2 results in stack corruption. > > >> > > >> Do the simple thing: Don't use 64bit divide/remainder operations. > > >> > > >> Sponsored by: DARPA & NAI Labs > > > > > >Are there any known show stoppers to try booting an UFS2 partition > > >on alpha? > > > > Not that I know of. I don't know how the bootcode arrangement is > > on alpha, much less what size the UFS2 code results in. I pressume > > you could give your 'a' partition a start of something like 64k if > > it larger than the default space, whatever that is. We have 7.5k on alpha and still 204 bytes left. > The original UFS1+2 boot code did boot UFS1. > If it's not much bigger than before it should still fit. > I'll have to do a buildworld before I can try to boot an UFS2 partition > and recheck that it still boots an UFS1 partition. [52]cicely10# disklabel -B da2 pid 464 (disklabel): unaligned access: va=0x120045b84 pc=0x1200013b8 ra=0x12000137c op=stq pid 464 (disklabel): unaligned access: va=0x120045b8c pc=0x1200013c0 ra=0x12000137c op=stq pid 464 (disklabel): unaligned access: va=0x120045b94 pc=0x1200013c4 ra=0x12000137c op=stq pid 464 (disklabel): unaligned access: va=0x1200459a4 pc=0x120000d28 ra=0x120000d0c op=ldq pid 464 (disklabel): unaligned access: va=0x1200459ac pc=0x120000d28 ra=0x120000d0c op=ldq pid 464 (disklabel): unaligned access: va=0x1200459b4 pc=0x120000d28 ra=0x120000d0c op=ldq pid 464 (disklabel): unaligned access: va=0x1200459bc pc=0x120000d28 ra=0x120000d0c op=ldq pid 464 (disklabel): unaligned access: va=0x1200459c4 pc=0x120000d28 ra=0x120000d0c op=ldq pid 464 (disklabel): unaligned access: va=0x1200459cc pc=0x120000d28 ra=0x120000d0c op=ldq pid 464 (disklabel): unaligned access: va=0x1200459d4 pc=0x120000d28 ra=0x120000d0c op=ldq pid 464 (disklabel): unaligned access: va=0x1200459dc pc=0x120000d28 ra=0x120000d0c op=ldq [...] I still can boot my old UFS1 partition from da1 after disklabel -B da1 with UFS1+2 /boot/boot1 and comparing the installed bootblocks seemed to show an updated version. I can produce gdb traces for anyone who wants to look at this. And I was able to sucessfully boot an UFS2 partition. It should be save to remove the UFS1_ONLY define for alpha. But I had many troubles with disklabel creating a bootable disk. finaly I copied the label via dd from another disk to boot. [60]cicely10# disklabel -rw da2 auto disklabel: ioctl DIOCSDINFO: open partition would move or shrink Exit 1 This happened after I dd'ed sector 0 from another disk and tried to update the disklabel to the real geometry. Needless to say that da2 was complely unused. At least the dd was enough for SRM to believe in a valid bootblock. [56]cicely10# dd if=/dev/zero count=10 bs=8192 of=/dev/da2 [57]cicely10# disklabel -Brw da2 auto pid 465 (disklabel): unaligned access: va=0x1200459a4 pc=0x120000d28 ra=0x120000d0c op=ldq pid 465 (disklabel): unaligned access: va=0x1200459ac pc=0x120000d28 ra=0x120000d0c op=ldq pid 465 (disklabel): unaligned access: va=0x1200459b4 pc=0x120000d28 ra=0x120000d0c op=ldq pid 465 (disklabel): unaligned access: va=0x1200459bc pc=0x120000d28 ra=0x120000d0c op=ldq [58]cicely10# disklabel -e da2 (setup a: as 4.2BSD) [59]cicely10# newfs /dev/da2a [...] >>>boot dka400 (boot dka400.4.0.6.0 -flags 0) block 0 of dka400.4.0.6.0 is not a valid boot block bootstrap failure This one is my biggest problem. SRM doesn't accept the disklabel. Once I dd the first 512 bytes from an old disk SRM is happy. I compared them with hexdump, but wasn't able to find the reason. -- B.Walter COSMO-Project http://www.cosmo-project.de ticso@cicely.de Usergroup info@cosmo-project.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021010210124.GV17920>