Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 5 Mar 2012 23:55:24 +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:  <26B4F050-2C6F-41D9-A850-AD9F4B0355DA@pingpong.net>
In-Reply-To: <201203051616.12188.jhb@freebsd.org>
References:  <E040B3A9-9B62-4545-ADC9-5CE3A9217024@me.com> <201203051239.53934.jhb@freebsd.org> <A551C90C-053F-4BB7-ADB7-35C138B9F912@pingpong.net> <201203051616.12188.jhb@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help

5 mar 2012 kl. 22:16 skrev John Baldwin <jhb@freebsd.org>:

> On Monday, March 05, 2012 2:35:59 pm Palle Girgensohn wrote:
>>=20
>> 5 mar 2012 kl. 18:39 skrev John Baldwin <jhb@freebsd.org>:
>>=20
>>> 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 foun=
d that 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 b=
ooting
>>> on 9.0 would still be broken.
>>=20
>>=20
>> Ok, that's odd. I tried 9.0, it does fail, and the printf actually makes i=
t work.=20
>=20
> Can you try editing sys/boot/i386/common/drv.c and adding some additional p=
adding after
> the edd_params?  Perhaps the BIOS is assuming it always gets the full thin=
g even if
> we pass in a 1.1-sized structure.  Just try putting a edd_params_v4 struct=
ure after the
> normal one.

Yes, I'll try that. It might take a couple of days, since I'm in the a quite=
 busy the next day or two, but I will check it out.=20

Cheers,
Palle


>=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 structure=
s
>>>>   and constants related to the BIOS Enhanced Disk Drive Specification.
>>>> - Use this header instead of magic numbers and various duplicate struct=
ure
>>>>   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 wi=
th
>>>>> the hack - is it likely to believe that it will suddenly or sporadical=
ly
>>>>> 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=
 this code,=20
>>>>>> especially when run on the following particular processor:
>>>>>>=20
>>>>>> 1 Processor(s) detected, 4 total cores enabled, Hyperthreading is ena=
bled
>>>>>> 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 gptzfsboo=
t that 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@freebs=
d.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=
.org"
>>>>> _______________________________________________
>>>>> 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
>>>>=20
>>>=20
>>> --=20
>>> John Baldwin
>>=20
>=20
> --=20
> John Baldwin



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?26B4F050-2C6F-41D9-A850-AD9F4B0355DA>