From owner-freebsd-current@freebsd.org Mon Oct 22 16:26:37 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A969B1037812 for ; Mon, 22 Oct 2018 16:26:36 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ua1-x936.google.com (mail-ua1-x936.google.com [IPv6:2607:f8b0:4864:20::936]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4098F82E20 for ; Mon, 22 Oct 2018 16:26:36 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-ua1-x936.google.com with SMTP id m18so10187048uaq.2 for ; Mon, 22 Oct 2018 09:26:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3jLHZnuVsyGnFbCHnV1R2lxzjTZ/hPnraRgZQVp1bCc=; b=vJysLy1SMgSRkKnbYwfhoGy1INLZ1GkISHpfTmlNMdB3frJhOe9sz6N9cV/6wSGe7/ cEoTvAvC4FeTZf0l0i7Fsari6Hg7Hsd9BUkXWVuVs9dSlNHp5lMS1GAAxxoUJVJxpBbZ +uyxhO2lFnjgB4w8LQEEcqN685V88b776FiS7gyCdvHQ7gts5c62vW5dqYKNaNuZedUE DlJJ/qymTPNScnnKAbp6UzqSJMY95OIOpNSIE5yOGVKwbr/ykYuGDyfibPpKsjsixC58 mWK0qwuHBKX5wLfL4h6xSu4VUE8PEMUBq+/Mr59+vgMh68FPZdC+YR9+H5UYZY3gAq/2 JpKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3jLHZnuVsyGnFbCHnV1R2lxzjTZ/hPnraRgZQVp1bCc=; b=hDq2DUd1CBhYxJa3VUUrhSGays7gkJWq3eXjmSzcabXHsHkYMSDd3vsimdIOmo6sps 5wBPI9nZ400EYBxReOr3/bmpoLDyeMKt5IIMHRm5GYNSYUHDCR5ScxZIhDPFzmhXcdGC 7sZl93IgMScd2Uo3WICUy0JS3IYruim31XjKa0TpHMBpglmIKw684e/yr9zq7LlWT42y pLPFHiuYxdMi+WczFd4S80xxEIeNM9v4jaV051CZ+/Voeo/0decKu+yqcVoHzOpvmKzQ apEc32x8vvstiH+OFCmO+RqsJop/pYi4s9XdusqI7MlGl27974+/JU2vony4UeGBqPxx 7LoA== X-Gm-Message-State: ABuFfoigJxlLNi0zq+ztNaBrMZUmcZu4Y6MxYYxD62M+td4edtpTiJcZ s+Oq1OAiAo9z61Q/7pk95wTclp402U5Wlf3Dg8yPAg== X-Google-Smtp-Source: ACcGV60yZOoYwEZQ4zUIlMefVNPWacJ672/LwGVvso5LaIY+v5eKKwHXiEOS+BasZJcIIBAHT3DKwrETFsSOHYmMsRE= X-Received: by 2002:ab0:a97:: with SMTP id d23mr20230823uak.39.1540225595474; Mon, 22 Oct 2018 09:26:35 -0700 (PDT) MIME-Version: 1.0 References: <79973E2B-F5C4-4E7C-B92B-1C8D4441C7D1@yahoo.com> <3CA4C94F-A062-44FE-B507-948A6F88C83D@me.com> <085BCA2B-4451-406C-9CEE-57D8B8008201@yahoo.com> <9AEF5EB3-C393-44D1-9BD4-D0E59FE97CCE@me.com> <08B26F92-F1F5-4F51-8DC4-EDDC6DD493B2@yahoo.com> In-Reply-To: <08B26F92-F1F5-4F51-8DC4-EDDC6DD493B2@yahoo.com> From: Warner Losh Date: Mon, 22 Oct 2018 10:26:23 -0600 Message-ID: Subject: Re: head -r338804 boots threadripper 1950X fine; head -r338810+ do not; -r338807 seems implicated To: Mark Millard Cc: Toomas Soome , Konstantin Belousov , FreeBSD Current , FreeBSD-STABLE Mailing List Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 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, 22 Oct 2018 16:26:37 -0000 On Mon, Oct 22, 2018 at 6:39 AM Mark Millard wrote: > On 2018-Oct-22, at 4:07 AM, Toomas Soome wrote: > > > On 22 Oct 2018, at 13:58, Mark Millard wrote: > >> > >> On 2018-Oct-22, at 2:27 AM, Toomas Soome wrote: > >>> > >>>> On 22 Oct 2018, at 06:30, Warner Losh wrote: > >>>> > >>>> On Sun, Oct 21, 2018 at 9:28 PM Warner Losh wrote: > >>>> > >>>>> > >>>>> > >>>>> On Sun, Oct 21, 2018 at 8:57 PM Mark Millard via freebsd-stable < > >>>>> freebsd-stable@freebsd.org> wrote: > >>>>> > >>>>>> [I built based on WITHOUT_ZFS=3D for other reasons. But, > >>>>>> after installing the build, Hyper-V based boots are > >>>>>> working.] > >>>>>> > >>>>>> On 2018-Oct-20, at 2:09 AM, Mark Millard > wrote: > >>>>>> > >>>>>>> On 2018-Oct-20, at 1:39 AM, Mark Millard > wrote: > >>>>>>> . . . > >>>> > >>> > >>> It would help to get output from loader lsdev -v command. > >> > >> That turned out to be very interesting: The non-ZFS loader > >> crashes during the listing, during disk8, which shows a > >> x0 instead of a x512. > >> > > > > Yes, thats the root cause there. The non-zfs loader does only *read* th= e > boot disk, thats why the issue was not revealed there. > > > > It would help to identify the sector size for that disk, at least from > OS, so we can compare with what we can get from INT13. > > > > I have pretty good idea what to look there, but I am afraid we need to > run few tests with you to understand why that disk is reporting sector si= ze > 0 there. > > > > > > Looks like I guessed wrong about the device > for "drive8". > > So I unplugged the only other external > storage device, so the original drives > 0-13 become 0-11 overall. > > The machine has a multi-LUN media card reader with > no cards plugged in. It is built-in rather than > one that I plugged into a port. It has 4 LUN's. > > So 8+4=3D12 and drives 0-7 show up with media before > it tries any of the 4 LUN's with no card in place. > > I conclude that "drive8" is an empty LUN in a media > card reader. > > I conclude that there is no sector size available for > any of the empty LUNs in the media reader. > I think you are probably right and we're hitting some divide by 0 error when we should just ignore the disk. Warner > > > > > >> Hand transcribed from pictures: > >> > >> OK lsdev -v > >> disk devices > >> disk0: BIOS drive C (937703088 x 512): > >> disk0p1: FreeBSD boot 512K > >> disk0p2: FreeBSD UFS 356G > >> disk0p3: FreeBSD swap 15G > >> disp0p4: FreeBSD swap 76G > >> disk1: BIOS drive D (16514064 x 512): > >> disk1s1: Linux 2048KB > >> disk1s2: Unknown 952GB > >> disk2: BIOS drive E (16514064 x 512): > >> disk2p1: Unknown 128MB > >> disk3: BIOS drive F (16514064 x 512): > >> disk3p1: Unknown 128MB > >> disk4: BIOS drive G (16434495 x 512): > >> disk2p1: Unknown 128MB > >> disk4p2: DOS/Windwos 1716GB > >> disk5: BIOS drive H (16434495 x 512): > >> disk5p1: FreeBSD boot 512K > >> disk5p2: FreeBSD UFS 176G > >> disk5p3: FreeBSD swap 193G > >> disp5p4: FreeBSD swap 15G > >> disk6: BIOS drive I (16434495 x 512): > >> disk6p1: Unknown 499MB > >> disk6p2: EFI 99MB > >> disk6p3: Unknown 16MB > >> disp6p4: DOS/Windows 886G > >> dis7: BIOS drive H (16434495 x 512): > >> disk7p1: FreeBSD boot 512K > >> disk7p2: FreeBSD UFS 953G > >> disk8: BIOS drive K (262144 x 0): > >> > >> int=3D00000000 err=3D00000000 efl=3D00010246 eip=3D000286bd > >> eax=3D00000000 ebx=3D72b50430 ecx=3D00000000 edx=3D00000000 > >> esi=3D00000000 edi=3D00092080 ebp=3D00091eec esp=3D00091ea8 > >> cs=3D002b ds=3D0033 es=3D0033 fs=3D0033 gs=3D0033 ss=3D0033 > >> cs:eip=3Df7 f1 89 c1 85 d2 0f 85-d8 01 00 00 6a 05 58 85 > >> f6 0f 88 75 01 00 00 89-cb c1 fb 1f 89 ca 03 55 > >> ss:esp=3D09 00 00 00 00 00 00 00-0a 00 00 00 02 00 00 00 > >> 00 00 00 00 00 00 00 00-78 1f 09 00 33 45 04 00 > >> BTX halted > >> > >> I expect that "disk8" is what gpart show -p > >> from a native boot showed as: > >> > >> =3D> 1 60062499 da1 MBR (29G) > >> 1 31 - free - (16K) > >> 32 60062468 da1s1 fat32lba (29G) > >> > >> (That gpart show -p output is in another of the > >> list messages.) > >> > >>> Also if you could test boot loader with UEFI - for example get to > loader prompt via usb/cd boot and then get the same lsdev -v output. > >> > >> Still true given the above crash? Or, going the > >> other way, should "drive8" be left as it is in > >> order to be sure to do this test with the drive > >> present? > >> > >> If I do this test later, it will take a bit to > >> get media to do it with. (It is about 4AM in the > >> morning and I've yet to get to sleep.) > >> > >> Note: I've never tried a UEFI based boot of FreeBSD > >> on this machine (but the Windows 10 Pro x64 is EFI > >> based). The only FreeBSD context using a EFI partition > >> to boot that I have used is on an arm aarch64 > >> Cortex-A57 system. > >> > >>> I would be interested to see the sector size information and if the > UEFI loader does also have issues. > >> > >> Understood. > >> > >>> If it does, I=E2=80=99d like to see the outputs from commands: > >> > >>> zpool status > >>> zpool import > >> > >> Independent of the UEFI test . . . > >> > >> I do have a -r331924 head version on another one > >> of the devices and can native-boot that. It still > >> has its ZFS software (but a default loader without > >> ZFS). > >> > >> Trying from that context, hand transcribed: > >> > >> # zpool status > >> ZFS filesystem version: 5 > >> ZFS storage pool version: features support (5000) > >> no pools available > >> # zpool import > >> # > >> > >> [That was based on the old (default) loader being > >> a non-ZFS one.] > > > > > > =3D=3D=3D > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) > >