From owner-freebsd-hackers@freebsd.org Tue Aug 2 13:36:25 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EDB55BAC58E for ; Tue, 2 Aug 2016 13:36:25 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citapm.icyb.net.ua (citapm.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 4D8041966 for ; Tue, 2 Aug 2016 13:36:24 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citapm.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id QAA11993 for ; Tue, 02 Aug 2016 16:36:22 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1bUZrq-000Ljf-JD for freebsd-hackers@freebsd.org; Tue, 02 Aug 2016 16:36:22 +0300 To: "freebsd-hackers@freebsd.org" From: Andriy Gapon Subject: on BIOS problems with disks larger than 2 TB Message-ID: <6cec427b-4df1-50f0-3014-a96e5f8210f5@FreeBSD.org> Date: Tue, 2 Aug 2016 16:35:23 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2016 13:36:26 -0000 There are some BIOSes out there that do not properly support disks larger than 2TB and cause boot problems if there is any data required for boot at offsets larger than 2 TB (TiB, rather). The most typical victim is the ZFS boot if a boot pool includes disk areas beyond 2TB, because a kernel, or zfsloader or any configuration files required by the loader may end up in those "inaccessible" areas. It's obvious why 2TiB is a magic value here: 2^32 * 512 = 2^41 = 2 * 2^40 So the problem seems to happen when an LBA is treated as a 32-bit integer (unsigned). I happen to own one of affected systems and I have done some more investigation. As far as I can see, the only actual problem in my case is that a disk size in 512b sectors is reported modulo 2^32 by INT 13h AH=48h. If I "fix up" the parameter, then everything else (i.e. actual data reads) seems to work just fine after that. I suspect that a large subclass of other problematic systems may have exactly the same problem. Does anyone have an idea about how we could auto-detect and and auto-correct that problem? Would that be worth the trouble at all? Given the gradual de-orbiting of BIOS systems. -- Andriy Gapon