From owner-freebsd-current@FreeBSD.ORG Mon Oct 24 19:46:26 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 27134106564A; Mon, 24 Oct 2011 19:46:26 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id DC03A8FC0A; Mon, 24 Oct 2011 19:46:25 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 77FEC46B0C; Mon, 24 Oct 2011 15:46:25 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 042D68A02F; Mon, 24 Oct 2011 15:46:25 -0400 (EDT) From: John Baldwin To: Andriy Gapon Date: Mon, 24 Oct 2011 14:23:44 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110617; KDE/4.5.5; amd64; ; ) References: <201110241133.23397.jhb@freebsd.org> <4EA59165.1000202@FreeBSD.org> In-Reply-To: <4EA59165.1000202@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201110241423.44951.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Mon, 24 Oct 2011 15:46:25 -0400 (EDT) Cc: Pavel Timofeev , freebsd-current@freebsd.org, Dennis Koegel Subject: Re: Fresh installed Freebsd 9 don't boot from hd X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 19:46:26 -0000 On Monday, October 24, 2011 12:25:09 pm Andriy Gapon wrote: > on 24/10/2011 18:33 John Baldwin said the following: > > On Monday, October 24, 2011 9:47:42 am Andriy Gapon wrote: > >> on 24/10/2011 16:41 John Baldwin said the following: > >>> On Sunday, October 23, 2011 1:57:59 pm Andriy Gapon wrote: > [snip] > >>>> I found a document that suggests a possibility of BIOS writing more bytes to the > >>>> array than its current size of 0x42: > >>>> http://www.t13.org/documents/UploadedDocuments/docs2008/e08134r1-BIOS_Enhanced_Disk_Drive_Services_4.0.pdf > >>>> > >>>> Of course, the size of the array is passed to BIOS at the start of the array and > >>>> so a _non-buggy_ BIOS should not write beyond the array, but we live in a > >>>> non-perfect world. > >>> > >>> Hmm, I think we've had to do a similar workaround in the past for a different > >>> BIOS call (SMAP maybe?). However, I do have one request, can we declare an > >>> actual structure instead of a silly char array? Then we can remove the weird > >>> casts with offsets into it, etc. Having an actual struct would be far more > >>> readable and less bug-prone. > >>> > >> > >> I am all for this. > >> Unfortunately. ENOTIME to do this properly at the moment. > > > > Ugh, it looks like in EDD 4.0 they silently expanded the path field to 16 bytes > > instead of 8 as in EDD 3.0 which is why the HP BIOS is probably writing an extra > > four bytes. > > Yes, that's exactly what I meant above, but probably wasn't clear about that. > > > Ah, so the deal is that the device path bit is variable length and the caller is > > supposed to set the length on input which we aren't doing. However, we don't > > care about the device path stuff anyway, so we can set a smaller input value. > > > > Perhaps try http://www.freebsd.org/~jhb/patches/edd_params.patch > > > > > +struct edd_params { > > + uint16_t len; > > + uint16_t flags; > > + uint32_t cylinders; > > + uint32_t heads; > > + uint32_t sectors_per_track; > > + uint64_t sectors; > > + uint32_t sector_size; > > sector_size should be uint16_t, I think. Ditto for edd_params_v3 and edd_params_v4. > sizeof(struct edd_params) should be 30, judging from the specs. Oops, yeah. > > + uint16_t edd_params_seg; > > + uint16_t edd_params_off; > > +}; > > Perhaps the structures should be declared __packed (if only just in case)? > > Also, perhaps edd_params_v3 and edd_params_v4 should inherit edd_params in some > "smarter" way to avoid verbatim duplicates. Yeah, probably so. We will probably never even use them anyway (just as we don't use edd_packet_v3 even though we could probably make use of it to avoid some bounce buffering in the loader). > Other than these issues the patch looks great! > Perhaps later we could do detailed definitions for things like interface paths for > various cases, etc. I doubt we will ever use them. -- John Baldwin