On Saturday, March 03, 2012 7:06:14 pm Christoph Hoffmann wrote: > Hello, > > I think this bug has been fix by John Baldwin (see below) after he found that HP > implemented 'e09127r3 EDD-4 Hybrid MBR boot code annex' dated > 4 January 2010. > > Maybe John could shade some light on it? Hmm, this fix should be in 9.0, so I don't have an explanation for why booting on 9.0 would still be broken. > Regards, > > Christoph > > Author: jhb > Date: Wed Nov 9 18:26:19 2011 > New Revision: 227400 > URL: > http://svn.freebsd.org/changeset/base/227400 > > 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 structure > 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. > > Approved by: re (kib) > > -- > Christoph Hoffmann > > On Mar 1, 2012, at 10:39 PM, Palle Girgensohn wrote: > > > Hi! > > > > 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... :) > > > > 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? > > > > Cheers, > > Palle > > > > Christoph Hoffmann skrev: > >> Hello Daniel, > >> > >> 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: > >> > >> *** 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 = (char *) PTOV(bios_basemem); > >> } > >> > >> + printf("Hello! I am a hack.\n"); > >> dsk = malloc(sizeof(struct dsk)); > >> dsk->drive = *(uint8_t *)PTOV(ARGS); > >> dsk->type = dsk->drive & DRV_HARD ? TYPE_AD : TYPE_FD; > >> > >> I am inclined to think that this is related to the way how we compile this code, > >> especially when run on the following particular processor: > >> > >> 1 Processor(s) detected, 4 total cores enabled, Hyperthreading is enabled > >> Proc 1: Intel(R) Xeon(R) CPU E5630 _at_ 2.53GHz > >> QPI Speed: 5.8 GT/s. > >> > >> > >> Regards, > >> > >> Christoph > >> > >> > >> On Oct 11, 2011, at 3:16 PM, Daniel Kalchev wrote: > >> > >>> Has this issue been resolved somehow? Sane method to build gptzfsboot that will run on HP's P410i? > >>> > >>> Daniel > >>> _______________________________________________ > >>> freebsd-current_at_freebsd.org mailing list > >>> http://lists.freebsd.org/mailman/listinfo/freebsd-current > >>> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org" > >> > >> _______________________________________________ > >> freebsd-current_at_freebsd.org mailing list > >> http://lists.freebsd.org/mailman/listinfo/freebsd-current > >> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org" > > _______________________________________________ > > freebsd-current_at_freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org" > > -- John BaldwinReceived on Mon Mar 05 2012 - 16:44:58 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:24 UTC