Date: Mon, 22 Oct 2018 18:43:21 -0700 From: Mark Millard <marklmi@yahoo.com> To: Warner Losh <imp@bsdimp.com>, Konstantin Belousov <kib@freebsd.org> Cc: Toomas Soome <tsoome@me.com>, FreeBSD Current <freebsd-current@freebsd.org>, FreeBSD-STABLE Mailing List <freebsd-stable@freebsd.org> Subject: Re: head -r338804 boots threadripper 1950X fine; head -r338810+ do not; -r338807 seems implicated Message-ID: <302639EA-55AA-4A41-BC03-4D48E6A09000@yahoo.com> In-Reply-To: <16BF1504-AD3B-4B5F-A728-43C2A777A082@yahoo.com> References: <79973E2B-F5C4-4E7C-B92B-1C8D4441C7D1@yahoo.com> <ACBB38EF-9A6A-40E5-AB6C-EEB9E292A919@yahoo.com> <EDBFFACB-8582-4B16-AC1A-63F8C86C9BA4@yahoo.com> <CANCZdfo=uqLn16r0FShz=WEv3Z34LbmC1gqzKabwfr3gEUXsJg@mail.gmail.com> <CANCZdfoHg8=FfuJchyPJ9qBDZBkR_7nYTWPiQedZkW4Cs1pR5A@mail.gmail.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> <CANCZdfoeb6G4VxAnYmy0=1EKNszihccO16izpF7X%2Br7GAQO7yQ@mail.gmail.com> <16BF1504-AD3B-4B5F-A728-43C2A777A082@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[I' unable to reproduce the under-Hyper-V early kernel crash for WITH_ZFS=3D (implicit) build that includes the for-loaders patch I was given to try.] On 2018-Oct-22, at 10:01 AM, Mark Millard <marklm at yahoo.com> wrote: > [I will note the the loader problem has been shown to > not be involved in the kernel problem that this > "Subject:" was originally for.] >=20 > On 2018-Oct-22, at 9:26 AM, Warner Losh <imp at sdimp.com> wrote: >=20 >> On Mon, Oct 22, 2018 at 6:39 AM Mark Millard <marklmi@yahoo.com> = wrote: >>> On 2018-Oct-22, at 4:07 AM, Toomas Soome <tsoome at me.com> wrote: >>>=20 >>>> On 22 Oct 2018, at 13:58, Mark Millard <marklmi at yahoo.com> = wrote: >>>>>=20 >>>>> On 2018-Oct-22, at 2:27 AM, Toomas Soome <tsoome at me.com> wrote: >>>>>>=20 >>>>>>> On 22 Oct 2018, at 06:30, Warner Losh <imp@bsdimp.com> wrote: >>>>>>>=20 >>>>>>> On Sun, Oct 21, 2018 at 9:28 PM Warner Losh <imp@bsdimp.com> = wrote: >>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On Sun, Oct 21, 2018 at 8:57 PM Mark Millard via freebsd-stable = < >>>>>>>> freebsd-stable@freebsd.org> wrote: >>>>>>>>=20 >>>>>>>>> [I built based on WITHOUT_ZFS=3D for other reasons. But, >>>>>>>>> after installing the build, Hyper-V based boots are >>>>>>>>> working.] >>>>>>>>>=20 >>>>>>>>> On 2018-Oct-20, at 2:09 AM, Mark Millard <marklmi at = yahoo.com> wrote: >>>>>>>>>=20 >>>>>>>>>> On 2018-Oct-20, at 1:39 AM, Mark Millard <marklmi at = yahoo.com> wrote: >>>>>>>>>> . . . >>>>>>>=20 >>>>>>=20 >>>>>> It would help to get output from loader lsdev -v command. >>>>>=20 >>>>> 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. >>>>>=20 >>>>=20 >>>> Yes, thats the root cause there. The non-zfs loader does only = *read* the boot disk, thats why the issue was not revealed there.=20 >>>>=20 >>>> 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. >>>>=20 >>>> 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 size 0 there. >>>>=20 >>>>=20 >>>=20 >>> Looks like I guessed wrong about the device >>> for "drive8". >>>=20 >>> So I unplugged the only other external >>> storage device, so the original drives >>> 0-13 become 0-11 overall. >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> I conclude that "drive8" is an empty LUN in a media >>> card reader. >>>=20 >>> I conclude that there is no sector size available for >>> any of the empty LUNs in the media reader. >>>=20 >> I think you are probably right and we're hitting some divide by 0 = error when we should just ignore the disk. >=20 > In the Hyper-V context, the loader and kernel do not > see the 4-LUN media reader at all: only drives with > normal freebsd-* style partitions and free space. > This explains why I did not see a loader problem > in that context. >=20 > So I conclude that the kernel crash under Hyper-V > associated with -r338807 is a separate issue even > though WITHOUT_ZFS=3D seems to have avoided the > crash. >=20 > My plan is to continue with the -r338807 investigation > after the loader problem is fixed in my builds. Then > I've go back to trying builds using WITH_ZFS=3D (implicit), > both native boots and Hyper-V based ones. So much for my ability to make that inference correctly: The WITH_ZFS=3D (implicit) build worked fine for booting natively and via Hyper-V when the patch to fix the loaders was included in what to build. I'm now unable to reproduce this kernel-time crash. The patch was from: https://reviews.freebsd.org/D11174 The empty LUN's in the media reader now get messages that look something like: disk8: Read 1 sector(s) from 0 to 0xffffe000 (0x8000): 0x31 early in the loader activity. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?302639EA-55AA-4A41-BC03-4D48E6A09000>