Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 21 Jun 2011 09:01:27 -0400
From:      John Baldwin <jhb@freebsd.org>
To:        Henri Hennebert <hlh@restart.be>
Cc:        freebsd-stable@freebsd.org
Subject:   Re: ZFS boot inside on the second partition inside a slice
Message-ID:  <201106210901.27338.jhb@freebsd.org>
In-Reply-To: <4E00699A.7010403@restart.be>
References:  <BANLkTi=drd8vY84_4jqDZTFK%2Bsq=n0Kx9g@mail.gmail.com> <201106200951.47449.jhb@freebsd.org> <4E00699A.7010403@restart.be>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday, June 21, 2011 5:51:22 am Henri Hennebert wrote:
> On 06/20/2011 15:51, John Baldwin wrote:
> > On Saturday, June 18, 2011 5:04:07 am Henri Hennebert wrote:
> >> On 06/17/2011 19:37, John Baldwin wrote:
> >>> On Friday, June 17, 2011 1:06:22 pm Henri Hennebert wrote:
> >>>> On 06/16/2011 19:35, John Baldwin wrote:
> >>>>> On Thursday, June 16, 2011 8:45:41 am Zhihao Yuan wrote:
> >>>>>> Exactly. The MFCed ZFSv28 is different from any patch maintained by
> >>>>>> mm@. Maybe some untested changes involved.
> >>>>>
> >>>>> Can you try reverting this change:
> >>>>>
> >>>>> Author: jhb
> >>>>> Date: Thu Apr 28 17:44:24 2011
> >>>>> New Revision: 221177
> >>>>> URL: http://svn.freebsd.org/changeset/base/221177
> >>>>>
> >>>>> Log:
> >>>>>     Due to space constraints, the UFS boot2 and boot1 use an evil hack 
where
> >>>>>     boot2 calls back into boot1 to perform disk reads.  The ZFS MBR 
boot blocks
> >>>>>     do not have the same space constraints, so remove this hack for 
ZFS.
> >>>>>     While here, remove commented out code to support C/H/S addressing 
from
> >>>>>     zfsldr.  The ZFS and GPT bootstraps always just use EDD LBA 
addressing.
> >>>>>
> >>>>>     MFC after:    2 weeks
> >>>>>
> >>>>> Modified:
> >>>>>     head/sys/boot/i386/boot2/Makefile
> >>>>>     head/sys/boot/i386/common/drv.c
> >>>>>     head/sys/boot/i386/zfsboot/Makefile
> >>>>>     head/sys/boot/i386/zfsboot/zfsldr.S
> >>>>>
> >>>> I try with this revision (221177) reverted to no avail:
> >>>> same error - 'read error'
> >>>
> >>> Hmm, ok.  No other ideas off the top of my head.
> >>>
> >> I make the same test under virtualbox and get:
> >>
> >> A critical error has occurred while running the virtual machine and the
> >> machine execution has been stopped.
> >>
> >> I attach VBox.log.
> >>
> >> PS - the message 'ZFS: supported version 28' comes from my patch:
> >>
> >> Index: sys/boot/zfs/zfsimpl.c
> >> ===================================================================
> >> --- sys/boot/zfs/zfsimpl.c	(revision 212549)
> >> +++ sys/boot/zfs/zfsimpl.c	(working copy)
> >> @@ -61,6 +61,8 @@
> >>    	STAILQ_INIT(&zfs_vdevs);
> >>    	STAILQ_INIT(&zfs_pools);
> >>
> >> +	printf("ZFS: supported version %u\n", (unsigned) SPA_VERSION);
> >> +
> >>    	zfs_temp_buf = malloc(TEMP_SIZE);
> >>    	zfs_temp_end = zfs_temp_buf + TEMP_SIZE;
> >>    	zfs_temp_ptr = zfs_temp_buf;
> >
> > Hmm, can you add printfs and narrow down where the hang happens (or which
> > reads are failing)?  The VBOX log seems to make no sense.  It shows the
> > CPU trying to call into the BIOS from within protected mode in the loader
> > but that shouldn't ever happen (note a cs of 0x2b (which is the loader's
> > %cs selector) but an eip that looks like a cs:ip of a BIOS routine).
> >
> I just try to put printf but I get only 'Read error' without any of my 
> printf.
> 
> Previously event my printf in zfs_init don't show up on the console of 
> my netbook. Under VBox it was printed.
> 
> Maybe printf is not allowed so soon in zfsboot ?

Rather, it may be that zfsldr.S is what is emitting 'Read error' and you are
not getting into the zfsboot.c code itself.  You can try this patch which
should display the error code the BIOS returns when it fails:

Index: zfsldr.S
===================================================================
--- zfsldr.S	(revision 223339)
+++ zfsldr.S	(working copy)
@@ -234,9 +234,12 @@ nread.1:	xor %ecx,%ecx			# Get
 		callw read			# Read from disk
 		lea 0x10(%bp),%sp		# Clear stack
 		jnc return			# If success, return
-		mov $msg_read,%si		# Otherwise, set the error
-						#  message and fall through to
-						#  the error routine
+		mov %ah,%al			# Format
+		mov $read_err,%di		#  error
+		call hex8			#  code
+		mov $msg_read,%si		# Set the error message and
+						#  fall through to the error
+						#  routine
 /*
  * Print out the error message pointed to by %ds:(%si) followed
  * by a prompt, wait for a keypress, and then reboot the machine.
@@ -296,12 +299,28 @@ read.1:		mov $msg_chs,%si
 		jmp error
 msg_chs:	.asciz "CHS not supported"
 
+/*
+ * Convert AL to hex, saving the result to [EDI].
+ */
+hex8:		push %ax			# Save
+		shrb $0x4,%al			# Do upper
+		call hex8.1			#  4
+		pop %ax				# Restore
+hex8.1: 	andb $0xf,%al			# Get lower 4
+		cmpb $0xa,%al			# Convert
+		sbbb $0x69,%al			#  to hex
+		das				#  digit
+		orb $0x20,%al			# To lower case
+		stosb				# Save char
+		ret				# (Recursive)
+
 /* Messages */
 
-msg_read:	.asciz "Read"
-msg_part:	.asciz "Boot"
+msg_read:	.ascii "Read error: "
+read_err:	.asciz "XX"
+msg_part:	.asciz "Boot error"
 
-prompt: 	.asciz " error\r\n"
+prompt: 	.asciz "\r\n"
 
 		.org PRT_OFF,0x90
 


-- 
John Baldwin



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201106210901.27338.jhb>