Date: Mon, 5 Mar 2012 20:35:59 +0100 From: Palle Girgensohn <girgen@pingpong.net> To: John Baldwin <jhb@freebsd.org> Cc: Palle Girgensohn <girgen@freebsd.org>, Christoph Hoffmann <christoph_hoffmann@me.com>, "freebsd-current@freebsd.org" <freebsd-current@freebsd.org> Subject: Re: gptzfsboot error using HP Smart Array P410i Controller Message-ID: <A551C90C-053F-4BB7-ADB7-35C138B9F912@pingpong.net> In-Reply-To: <201203051239.53934.jhb@freebsd.org> References: <E040B3A9-9B62-4545-ADC9-5CE3A9217024@me.com> <4F4FECA4.10504@FreeBSD.org> <B3013801-8BFF-4721-A47B-E951B7130F13@me.com> <201203051239.53934.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
5 mar 2012 kl. 18:39 skrev John Baldwin <jhb@freebsd.org>: > On Saturday, March 03, 2012 7:06:14 pm Christoph Hoffmann wrote: >> Hello, >>=20 >> I think this bug has been fix by John Baldwin (see below) after he found t= hat HP >> implemented 'e09127r3 EDD-4 Hybrid MBR boot code annex' dated >> 4 January 2010.=20 >>=20 >> Maybe John could shade some light on it? >=20 > Hmm, this fix should be in 9.0, so I don't have an explanation for why boo= ting > on 9.0 would still be broken. Ok, that's odd. I tried 9.0, it does fail, and the printf actually makes it w= ork.=20 Palle =20 >=20 >> Regards, >>=20 >> Christoph >>=20 >> Author: jhb >> Date: Wed Nov 9 18:26:19 2011 >> New Revision: 227400 >> URL:=20 >> http://svn.freebsd.org/changeset/base/227400 >>=20 >> Log: >> MFC 226748: >> - Add a new header for the x86 boot code that defines various structures= >> and constants related to the BIOS Enhanced Disk Drive Specification. >> - Use this header instead of magic numbers and various duplicate structu= re >> definitions for doing I/O. >> - Use an actual structure for the request to fetch drive parameters in >> drvsize() rather than a gross hack of a char array with some magic >> size. While here, change drvsize() to only pass the 1.1 version of >> the structure and not request device path information. If we want >> device path information you have to set the length of the device >> path information as an input (along with probably checking the actual >> EDD version to see which size one should use as the device path >> information is variable-length). This fixes data smashing problems >> from passing an EDD 3 structure to BIOSes supporting EDD 4. >>=20 >> Approved by: re (kib) >>=20 >> -- >> Christoph Hoffmann >>=20 >> On Mar 1, 2012, at 10:39 PM, Palle Girgensohn wrote: >>=20 >>> Hi! >>>=20 >>> This is still happening with FreeBSD 9.0-RELEASE, as I have just >>> discovered. The hack works like a charm, but seems kind of odd... :) >>>=20 >>> Any progress in getting a "real" fix into the repository? Any risks with= >>> the hack - is it likely to believe that it will suddenly or sporadically= >>> fail? >>>=20 >>> Cheers, >>> Palle >>>=20 >>> Christoph Hoffmann skrev: >>>> Hello Daniel, >>>>=20 >>>> Last time I checked up on the issue was on the 23rd of September, >>>> it was not fixed then. >>>> I was able to to boot from drive 0x80 after adding: >>>>=20 >>>> *** zfsboot.c.orig Fri Sep 23 18:03:26 2011 >>>> --- zfsboot.c Fri Sep 23 18:47:44 2011 >>>> *************** >>>> *** 459,464 **** >>>> --- 459,465 ---- >>>> heap_end =3D (char *) PTOV(bios_basemem); >>>> } >>>>=20 >>>> + printf("Hello! I am a hack.\n"); >>>> dsk =3D malloc(sizeof(struct dsk)); >>>> dsk->drive =3D *(uint8_t *)PTOV(ARGS); >>>> dsk->type =3D dsk->drive & DRV_HARD ? TYPE_AD : TYPE_FD; >>>>=20 >>>> I am inclined to think that this is related to the way how we compile t= his code,=20 >>>> especially when run on the following particular processor: >>>>=20 >>>> 1 Processor(s) detected, 4 total cores enabled, Hyperthreading is enabl= ed >>>> Proc 1: Intel(R) Xeon(R) CPU E5630 @ 2.53GHz >>>> QPI Speed: 5.8 GT/s. >>>>=20 >>>>=20 >>>> Regards, >>>>=20 >>>> Christoph >>>>=20 >>>>=20 >>>> On Oct 11, 2011, at 3:16 PM, Daniel Kalchev wrote: >>>>=20 >>>>> Has this issue been resolved somehow? Sane method to build gptzfsboot t= hat will run on HP's P410i? >>>>>=20 >>>>> Daniel >>>>> _______________________________________________ >>>>> freebsd-current@freebsd.org mailing list >>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-current >>>>> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.= org" >>>>=20 >>>> _______________________________________________ >>>> freebsd-current@freebsd.org mailing list >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-current >>>> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg" >>> _______________________________________________ >>> freebsd-current@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-current >>> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.or= g" >>=20 >>=20 >=20 > --=20 > John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?A551C90C-053F-4BB7-ADB7-35C138B9F912>