From owner-freebsd-stable@freebsd.org Sun Jan 28 01:41:10 2018 Return-Path: Delivered-To: freebsd-stable@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 403B2ED10F1 for ; Sun, 28 Jan 2018 01:41:10 +0000 (UTC) (envelope-from peter@hda3.com) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CF32984EFF for ; Sun, 28 Jan 2018 01:41:09 +0000 (UTC) (envelope-from peter@hda3.com) Received: by mail-qt0-x22e.google.com with SMTP id d8so8752410qtm.0 for ; Sat, 27 Jan 2018 17:41:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hda3-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RRLaHgcfqEy5lDM+zVWBhDvklSZYd02MVGdY+NeHDv8=; b=f31HX086nQrFdxPHMkAKuHgehygnmno5IEqxO1PxYeRylqrVFq6GVLG9ptapeV2c/l Vz37NCR72AsD9A4aZVZf14l9FO7kUXI+ffFtqjY6Gxlweid8ClCblh7bP5Xr96cUTJOf pht8uGP9lsaixL9tXS1JKy0g7LVJ/uktiCM0BZq8qnpOamuLnojv2MqUyielXZxyBqqB NKgMVTc16cIepEsG/eUZPmL1kjd/aWe9/Kwy3ckkMvyToQYMMzsiLQ4LVAL8T/bODmoU qgUa8j2lhFpjo0sbZVP3lYdHA18dX2dFiTBDjMVW2Q1nt5Z0F2NvdIxZo1ih537Q/ckR U1PQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=RRLaHgcfqEy5lDM+zVWBhDvklSZYd02MVGdY+NeHDv8=; b=J6CEO1pmSvQjjSuPyJSqmFXzaNYy0whiRWBbdIy+JcWZmFmDxHfKRe8WI+N2/Cw+xd ekvZ1F/SxEkqnkVABIpNhPaMfN2SRIbu1Kafkg8gPaFqf7qU8BmwkuRB2DwPxnmDGbhD 9hGlh+dKNnbphGCXR8Hvnr4a+otNfIlIlNGCKmEzKgeVZjRiaV1MOo+oJ2pO7PX7xv0J WZHyiaqKCoDCJrpz8BrKDkzWwf9Qpb/UOn/otmSiRUx/G3H8OLyuI/Je2D7mvlQZvA4c ZTRIBEV6k0MmM0J6OFCI+bO8QbUs7rBZvHi6ns3AQWHBtCI/1HQGLOmsX/IGzLK+nBLv 5BGg== X-Gm-Message-State: AKwxytfLKTMazEcI7qUJhqDTfK1QLfCX+JwRjrh4TzvqAnK0FWyGGqCW eS6Y153gFD9zo7qUHLKqNXZYLFoqz+oMQRqfYer46g== X-Google-Smtp-Source: AH8x225kcKA50aRMzlcSJihAd4FyUvpwV0lZCJKg4wvKkoRZH9V14z8EBgS8fEcVXiKND+ILa25iF5lQ8FpfINH0KtY= X-Received: by 10.200.23.66 with SMTP id u2mr31266037qtk.294.1517103669025; Sat, 27 Jan 2018 17:41:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.39.83 with HTTP; Sat, 27 Jan 2018 17:41:08 -0800 (PST) Received: by 10.140.39.83 with HTTP; Sat, 27 Jan 2018 17:41:08 -0800 (PST) In-Reply-To: References: <8e842dec-ade7-37d1-6bd8-856ea1a827ca@sentex.net> <3b625072-dfb3-6b4f-494d-7fe1b2fa554c@ingresso.co.uk> <2c6ce4dd-f43c-7c40-abc2-732d6f8996ec@sentex.net> <795dbb79-3c18-d967-98b9-5d09a740dbfe@sentex.net> <9b769e4e-b098-b294-0bce-8bb1c42e8a59@rootautomation.com> From: Peter Moody Date: Sat, 27 Jan 2018 17:41:08 -0800 Message-ID: Subject: Re: Ryzen issues on FreeBSD ? To: Nimrod Levy Cc: Mike Tancsa , FreeBSD-STABLE Mailing List , Ryan Root Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jan 2018 01:41:10 -0000 Whelp, I replaced the r5 1600x with an r7 1700 (au 1734) and I'm now getting minutes of uptime before I hard crash. With smt, without, with c states, without, with opcache, without. No difference. I'm going to try a completely different motherboard next. I think Amazon is starting to dislike me. On Jan 21, 2018 11:05 AM, "Peter Moody" wrote: > hm, so i've got nearly 3 days of uptime with smt disabled. > unfortunately this means that my otherwise '12' cores is actually only > '6'. I'm also getting occasional segfaults compiling go programs. > > should I just RMA this beast again? > > On Sun, Jan 21, 2018 at 5:25 AM, Nimrod Levy wrote: > > almost 2 days uptime with a lower memory clock. still holding my breath, > > but this seems promising. > > > > > > > > On Fri, Jan 19, 2018 at 4:02 PM Nimrod Levy wrote: > > > >> I can try lowering my memory clock and see what happens. I'm a little > >> skeptical because I have been able to run memtest with no errors for > some > >> time. I'm glad to give anything a try... > >> > >> > >> On Fri, Jan 19, 2018 at 3:49 PM Mike Tancsa wrote: > >> > >>> On 1/19/2018 3:23 PM, Ryan Root wrote: > >>> > This looks like the QVL list for your MB -> > >>> > > >>> http://download.gigabyte.us/FileList/Memory/mb_memory_ga- > ax370-Gaming5.pdf > >>> > >>> Its an Asus MB, but the memory I have is in the above PDF list > >>> > >>> I dont see CT16G4DFD824A, but I do see other crucial products with > >>> slower clock speeds. Right now I do have it set to 2133 where as it was > >>> 2400 before. > >>> > >>> ---Mike > >>> > >>> > >>> > > >>> > > >>> > On 1/19/2018 12:13 PM, Mike Tancsa wrote: > >>> >> Drag :( I have mine disabled as well as lowering the RAM freq to > 2100 > >>> >> from 2400. For me the hangs are infrequent. Its only been a day > and a > >>> >> half, so not sure if its gone or I have been "lucky"... Either ways, > >>> >> this platform feels way too fragile to deploy on anything :( > >>> >> > >>> >> ---Mike > >>> >> > >>> >> On 1/19/2018 3:08 PM, Nimrod Levy wrote: > >>> >>> Looks like disabling the C- states in the bios didn't change > >>> anything. > >>> >>> > >>> >>> On Wed, Jan 17, 2018 at 9:22 PM Nimrod Levy >>> >>> > wrote: > >>> >>> > >>> >>> That looks promising. I just found that seeing in the bios and > >>> >>> disabled it. I'll see how it runs. > >>> >>> > >>> >>> Thanks > >>> >>> > >>> >>> > >>> >>> On Wed, Jan 17, 2018, 18:38 Don Lewis >>> >>> > wrote: > >>> >>> > >>> >>> On 17 Jan, Nimrod Levy wrote: > >>> >>> > I'm running 11-STABLE from 12/9. amdtemp works for me. > It > >>> >>> also has the > >>> >>> > systl indicating that it it has the shared page fix. I'm > >>> >>> pretty sure I've > >>> >>> > seen the lockups since then. I'll update to the latest > >>> STABLE > >>> >>> and see > >>> >>> > what happens. > >>> >>> > > >>> >>> > One weird thing about my experience is that if I keep > >>> >>> something running > >>> >>> > continuously like the distributed.net < > >>> http://distributed.net> > >>> >>> client on 6 of 12 possible threads, > >>> >>> > it keeps the system up for MUCH longer than without. > This > >>> is > >>> >>> a home server > >>> >>> > and very lightly loaded (one could argue insanely > >>> overpowered > >>> >>> for the use > >>> >>> > case). > >>> >>> > >>> >>> This sounds like the problem with the deep Cx states that > has > >>> been > >>> >>> reported by numerous Linux users. I think some motherboard > >>> >>> brands are > >>> >>> more likely to have the problem. See: > >>> >>> > >>> http://forum.asrock.com/forum_posts.asp?TID=5963&title= > taichi-x370-with-ubuntu-idle-lock-ups-idle-freeze > >>> >>> > >>> >>> -- > >>> >>> > >>> >>> -- > >>> >>> Nimrod > >>> >>> > >>> >>> > >>> >>> > >>> >>> -- > >>> >>> > >>> >>> -- > >>> >>> Nimrod > >>> >>> > >>> >> > >>> > > >>> > > >>> > _______________________________________________ > >>> > freebsd-stable@freebsd.org mailing list > >>> > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > >>> > To unsubscribe, send any mail to " > >>> freebsd-stable-unsubscribe@freebsd.org" > >>> > > >>> > > >>> > >>> > >>> -- > >>> ------------------- > >>> Mike Tancsa, tel +1 519 651 3400 <(519)%20651-3400> > >>> Sentex Communications, mike@sentex.net > >>> Providing Internet services since 1994 www.sentex.net > >>> Cambridge, Ontario Canada http://www.tancsa.com/ > >>> _______________________________________________ > >>> freebsd-stable@freebsd.org mailing list > >>> https://lists.freebsd.org/mailman/listinfo/freebsd-stable > >>> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@ > freebsd.org" > >>> > >> > >> > >> -- > >> > >> -- > >> Nimrod > >> > > > > > > -- > > > > -- > > Nimrod > > _______________________________________________ > > freebsd-stable@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org > " > From owner-freebsd-stable@freebsd.org Sun Jan 28 02:20:03 2018 Return-Path: Delivered-To: freebsd-stable@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 8B569ED2B6A for ; Sun, 28 Jan 2018 02:20:03 +0000 (UTC) (envelope-from nimrod@nimrod.is-a-geek.net) Received: from mail-yb0-x235.google.com (mail-yb0-x235.google.com [IPv6:2607:f8b0:4002:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2335C864BF for ; Sun, 28 Jan 2018 02:20:02 +0000 (UTC) (envelope-from nimrod@nimrod.is-a-geek.net) Received: by mail-yb0-x235.google.com with SMTP id p83so1566663yba.4 for ; Sat, 27 Jan 2018 18:20:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6ru8Q2GE5NG6s0V65QCmPSCdCacrwtoc1NSA+D6vcCk=; b=R/P+IL0bE8NKMoMkT/unJH1OEJ/OawJZ1ziQ2WGcwpOneurkmYYEQY5dN5BA9rK64G 2o/P/ukpIu7Qyepv/c9X5W7YWUNSaGCLROuNp2fxLebdfH+u5mulGOZvaFVECeS+uCMF 49a+dpWy3fBPsBot+vcIFcva7sKF6x320LDukMUAZ7SuzxdRQzHdywjUB3hCO3k9ChWN Lnmcm2TpX6zkqds/kCk8LIZkqhUqa9DzXYECyT6YipvwXFjUSGya9ytFfTew6h2b+cmF zkafotfu3D/fibsn3N3H2+aW8erZaBeyAlHPtDBeefJX4l17U8aP3W079zu6dPwXz/Yh Z0lQ== 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=6ru8Q2GE5NG6s0V65QCmPSCdCacrwtoc1NSA+D6vcCk=; b=ghYIXnj7ktbXeK98heQIV6dKLGbcACrlh8plxju+T4tIlFzZSDA6u/ia/go8ceWAte 6qB3Az1HeugkDMf+YcYaBt3pOIHtqt/YFlNQyk9hKA03o6WjXUMvw2Z3oKtdBCxR82HE OqUyEP3O2iNXUlCdricrL3F9r6Qc80tPVN+WGUzBQ2MApuhRUzXZ6tayNpzADW4y7Oae 4DYmsx+Oj16M3Sb6uULOomgIk8G9n0V/EWr54IljsNaXypflyQY7Ba6ILBOEdKk6GZr6 eYz6wjkDXRtJqOaqSKVYwJ2Jqjx/fyNNurSMMSxME1zHpXOrCvGzEnYELr76Paosqw5t mi2w== X-Gm-Message-State: AKwxytfLXEERwSmQ/ZUFgxPxW+KWqOJhbLn94VRcHjFrF/5bfmkhrwQY hCKTRTANJANm/TLbkjwzSBd+JNG9OXOpMoBw3HXHsA== X-Google-Smtp-Source: AH8x224uoYla+XzzYxtumtz0isNutnElJ+HF+H3pss4f9lZ0zGf2oUg3eUtobq3RClQVTGH3Gu3sFLDKk7m5tzx0svo= X-Received: by 10.37.9.5 with SMTP id 5mr14983903ybj.101.1517106001934; Sat, 27 Jan 2018 18:20:01 -0800 (PST) MIME-Version: 1.0 References: <8e842dec-ade7-37d1-6bd8-856ea1a827ca@sentex.net> <3b625072-dfb3-6b4f-494d-7fe1b2fa554c@ingresso.co.uk> <2c6ce4dd-f43c-7c40-abc2-732d6f8996ec@sentex.net> <795dbb79-3c18-d967-98b9-5d09a740dbfe@sentex.net> <9b769e4e-b098-b294-0bce-8bb1c42e8a59@rootautomation.com> In-Reply-To: From: Nimrod Levy Date: Sun, 28 Jan 2018 02:19:50 +0000 Message-ID: Subject: Re: Ryzen issues on FreeBSD ? To: Peter Moody Cc: Mike Tancsa , FreeBSD-STABLE Mailing List , Ryan Root Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jan 2018 02:20:03 -0000 I'm about ready to have a party. My Ryzen 5 1600 has been up for over 8 days so far after changing the memory to a slower speed. System load hovers around .3 On Sat, Jan 27, 2018 at 8:41 PM Peter Moody wrote: > Whelp, I replaced the r5 1600x with an r7 1700 (au 1734) and I'm now > getting minutes of uptime before I hard crash. With smt, without, with c > states, without, with opcache, without. No difference. > > I'm going to try a completely different motherboard next. I think Amazon > is starting to dislike me. > > On Jan 21, 2018 11:05 AM, "Peter Moody" wrote: > >> hm, so i've got nearly 3 days of uptime with smt disabled. >> unfortunately this means that my otherwise '12' cores is actually only >> '6'. I'm also getting occasional segfaults compiling go programs. >> >> should I just RMA this beast again? >> >> On Sun, Jan 21, 2018 at 5:25 AM, Nimrod Levy wrote: >> > almost 2 days uptime with a lower memory clock. still holding my breath, >> > but this seems promising. >> > >> > >> > >> > On Fri, Jan 19, 2018 at 4:02 PM Nimrod Levy wrote: >> > >> >> I can try lowering my memory clock and see what happens. I'm a little >> >> skeptical because I have been able to run memtest with no errors for >> some >> >> time. I'm glad to give anything a try... >> >> >> >> >> >> On Fri, Jan 19, 2018 at 3:49 PM Mike Tancsa wrote: >> >> >> >>> On 1/19/2018 3:23 PM, Ryan Root wrote: >> >>> > This looks like the QVL list for your MB -> >> >>> > >> >>> >> http://download.gigabyte.us/FileList/Memory/mb_memory_ga-ax370-Gaming5.pdf >> >>> >> >>> Its an Asus MB, but the memory I have is in the above PDF list >> >>> >> >>> I dont see CT16G4DFD824A, but I do see other crucial products with >> >>> slower clock speeds. Right now I do have it set to 2133 where as it >> was >> >>> 2400 before. >> >>> >> >>> ---Mike >> >>> >> >>> >> >>> > >> >>> > >> >>> > On 1/19/2018 12:13 PM, Mike Tancsa wrote: >> >>> >> Drag :( I have mine disabled as well as lowering the RAM freq to >> 2100 >> >>> >> from 2400. For me the hangs are infrequent. Its only been a day >> and a >> >>> >> half, so not sure if its gone or I have been "lucky"... Either >> ways, >> >>> >> this platform feels way too fragile to deploy on anything :( >> >>> >> >> >>> >> ---Mike >> >>> >> >> >>> >> On 1/19/2018 3:08 PM, Nimrod Levy wrote: >> >>> >>> Looks like disabling the C- states in the bios didn't change >> >>> anything. >> >>> >>> >> >>> >>> On Wed, Jan 17, 2018 at 9:22 PM Nimrod Levy > >>> >>> > wrote: >> >>> >>> >> >>> >>> That looks promising. I just found that seeing in the bios and >> >>> >>> disabled it. I'll see how it runs. >> >>> >>> >> >>> >>> Thanks >> >>> >>> >> >>> >>> >> >>> >>> On Wed, Jan 17, 2018, 18:38 Don Lewis > >>> >>> > wrote: >> >>> >>> >> >>> >>> On 17 Jan, Nimrod Levy wrote: >> >>> >>> > I'm running 11-STABLE from 12/9. amdtemp works for >> me. It >> >>> >>> also has the >> >>> >>> > systl indicating that it it has the shared page fix. I'm >> >>> >>> pretty sure I've >> >>> >>> > seen the lockups since then. I'll update to the latest >> >>> STABLE >> >>> >>> and see >> >>> >>> > what happens. >> >>> >>> > >> >>> >>> > One weird thing about my experience is that if I keep >> >>> >>> something running >> >>> >>> > continuously like the distributed.net < >> >>> http://distributed.net> >> >>> >>> client on 6 of 12 possible threads, >> >>> >>> > it keeps the system up for MUCH longer than without. >> This >> >>> is >> >>> >>> a home server >> >>> >>> > and very lightly loaded (one could argue insanely >> >>> overpowered >> >>> >>> for the use >> >>> >>> > case). >> >>> >>> >> >>> >>> This sounds like the problem with the deep Cx states that >> has >> >>> been >> >>> >>> reported by numerous Linux users. I think some >> motherboard >> >>> >>> brands are >> >>> >>> more likely to have the problem. See: >> >>> >>> >> >>> >> http://forum.asrock.com/forum_posts.asp?TID=5963&title=taichi-x370-with-ubuntu-idle-lock-ups-idle-freeze >> >>> >>> >> >>> >>> -- >> >>> >>> >> >>> >>> -- >> >>> >>> Nimrod >> >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> -- >> >>> >>> >> >>> >>> -- >> >>> >>> Nimrod >> >>> >>> >> >>> >> >> >>> > >> >>> > >> >>> > _______________________________________________ >> >>> > freebsd-stable@freebsd.org mailing list >> >>> > https://lists.freebsd.org/mailman/listinfo/freebsd-stable >> >>> > To unsubscribe, send any mail to " >> >>> freebsd-stable-unsubscribe@freebsd.org" >> >>> > >> >>> > >> >>> >> >>> >> >>> -- >> >>> ------------------- >> >>> Mike Tancsa, tel +1 519 651 3400 <(519)%20651-3400> >> >>> Sentex Communications, mike@sentex.net >> >>> Providing Internet services since 1994 www.sentex.net >> >>> Cambridge, Ontario Canada http://www.tancsa.com/ >> >>> _______________________________________________ >> >>> freebsd-stable@freebsd.org mailing list >> >>> https://lists.freebsd.org/mailman/listinfo/freebsd-stable >> >>> To unsubscribe, send any mail to " >> freebsd-stable-unsubscribe@freebsd.org" >> >>> >> >> >> >> >> >> -- >> >> >> >> -- >> >> Nimrod >> >> >> > >> > >> > -- >> > >> > -- >> > Nimrod >> > _______________________________________________ >> > freebsd-stable@freebsd.org mailing list >> > https://lists.freebsd.org/mailman/listinfo/freebsd-stable >> > To unsubscribe, send any mail to " >> freebsd-stable-unsubscribe@freebsd.org" >> > -- -- Nimrod From owner-freebsd-stable@freebsd.org Sun Jan 28 03:10:32 2018 Return-Path: Delivered-To: freebsd-stable@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 98790ED474B for ; Sun, 28 Jan 2018 03:10:32 +0000 (UTC) (envelope-from peter@hda3.com) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 36501682FE for ; Sun, 28 Jan 2018 03:10:32 +0000 (UTC) (envelope-from peter@hda3.com) Received: by mail-qt0-x234.google.com with SMTP id a27so8877140qtd.1 for ; Sat, 27 Jan 2018 19:10:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hda3-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=c4B8ynfDP4Fv5e1sHZ65WoQiHix+c8ubDK/r2NekE08=; b=qjV7r5ZVhLjPyLXyzRWQbHYpNHeITSm4VzzFITSJGSbLGvDxDTEWKwOTYbfMNOPGDn YFJPKXwrXOQT7NqX8L8fhjtk9TCAF363+wkTq23S+P9nOjEfAfi2xBmvL4ukaU+qr7Cb 8+CRH3TL3D4p4T/yHw7wdpaW5lVMIL2ox3uU5VU3hOE+GUlxZzI5kGCwE2IM8p9YYDRz Ew/PGa/udKdeJOGRwaJZJU98kHcVKJkdqGS/nsuaIbHpjR5UuJXuXcm+iFzJ4lx3I7po oone0t+1ah/uSHwJeSK0bLyo5tMGJmoatxAYS9OUReWe0ISXOfHrfiMf2AOdbs1EtI2C A9Ww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=c4B8ynfDP4Fv5e1sHZ65WoQiHix+c8ubDK/r2NekE08=; b=IeHlZUSeqq7gVavyNvuXd35i185LEz9+j/ZimtoZhmQYIjTx7tDir/Htpp47UdL3RA CoCf8QJwg2YIQMo4GkRjRzg6La6erqs1o0hW31K25A7zkenmZsRbLDEKQdq+6lZS0I6E LCFiChZXLScOixtyiSaAzhJESEETgj4ZbKtuVkvGLErG+JaMdXagGz8Ww3/EeKpkEuS4 sBMWJyCWo1uCaV/12Sbpor6beC1+Ei0iKPX90TAQFAem5fF2MCYP4/ThroenUDSgqkTN kvWPRhm4qTAZXK9ysIdWW0ekR6jxCOtCCYY42TPiMDk+hAk7qs03miEGS8izUL9MrtUs +mnA== X-Gm-Message-State: AKwxyterhcwAId6vduiIWrB5+9a27GCRrU7BrOVv6TtCm8jfd+Ccd6aw UTrOwD/M5IOQx2WcErqx1r7XmZzMIoa4zZKDxvz3Zw== X-Google-Smtp-Source: AH8x224r4j9rbvxIFVzQT2BFNx0y37ppflBSSrFBb1rEJZf3X71jvVl/4hOTOitLg6kEgRwIA8WykULbLb5j9WzQuCs= X-Received: by 10.237.38.71 with SMTP id z65mr30193032qtc.248.1517109031656; Sat, 27 Jan 2018 19:10:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.39.83 with HTTP; Sat, 27 Jan 2018 19:10:31 -0800 (PST) Received: by 10.140.39.83 with HTTP; Sat, 27 Jan 2018 19:10:31 -0800 (PST) In-Reply-To: References: <8e842dec-ade7-37d1-6bd8-856ea1a827ca@sentex.net> <3b625072-dfb3-6b4f-494d-7fe1b2fa554c@ingresso.co.uk> <2c6ce4dd-f43c-7c40-abc2-732d6f8996ec@sentex.net> <795dbb79-3c18-d967-98b9-5d09a740dbfe@sentex.net> <9b769e4e-b098-b294-0bce-8bb1c42e8a59@rootautomation.com> From: Peter Moody Date: Sat, 27 Jan 2018 19:10:31 -0800 Message-ID: Subject: Re: Ryzen issues on FreeBSD ? To: Nimrod Levy Cc: Mike Tancsa , FreeBSD-STABLE Mailing List , Ryan Root Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jan 2018 03:10:32 -0000 On Jan 27, 2018 6:20 PM, "Nimrod Levy" wrote: I'm about ready to have a party. My Ryzen 5 1600 has been up for over 8 days so far after changing the memory to a slower speed. System load hovers around .3 I couldn't find an easy way to down-speed my memory in the bios :( On Sat, Jan 27, 2018 at 8:41 PM Peter Moody wrote: > Whelp, I replaced the r5 1600x with an r7 1700 (au 1734) and I'm now > getting minutes of uptime before I hard crash. With smt, without, with c > states, without, with opcache, without. No difference. > > I'm going to try a completely different motherboard next. I think Amazon > is starting to dislike me. > > On Jan 21, 2018 11:05 AM, "Peter Moody" wrote: > >> hm, so i've got nearly 3 days of uptime with smt disabled. >> unfortunately this means that my otherwise '12' cores is actually only >> '6'. I'm also getting occasional segfaults compiling go programs. >> >> should I just RMA this beast again? >> >> On Sun, Jan 21, 2018 at 5:25 AM, Nimrod Levy wrote: >> > almost 2 days uptime with a lower memory clock. still holding my breath, >> > but this seems promising. >> > >> > >> > >> > On Fri, Jan 19, 2018 at 4:02 PM Nimrod Levy wrote: >> > >> >> I can try lowering my memory clock and see what happens. I'm a little >> >> skeptical because I have been able to run memtest with no errors for >> some >> >> time. I'm glad to give anything a try... >> >> >> >> >> >> On Fri, Jan 19, 2018 at 3:49 PM Mike Tancsa wrote: >> >> >> >>> On 1/19/2018 3:23 PM, Ryan Root wrote: >> >>> > This looks like the QVL list for your MB -> >> >>> > >> >>> http://download.gigabyte.us/FileList/Memory/mb_memory_ga- >> ax370-Gaming5.pdf >> >>> >> >>> Its an Asus MB, but the memory I have is in the above PDF list >> >>> >> >>> I dont see CT16G4DFD824A, but I do see other crucial products with >> >>> slower clock speeds. Right now I do have it set to 2133 where as it >> was >> >>> 2400 before. >> >>> >> >>> ---Mike >> >>> >> >>> >> >>> > >> >>> > >> >>> > On 1/19/2018 12:13 PM, Mike Tancsa wrote: >> >>> >> Drag :( I have mine disabled as well as lowering the RAM freq to >> 2100 >> >>> >> from 2400. For me the hangs are infrequent. Its only been a day >> and a >> >>> >> half, so not sure if its gone or I have been "lucky"... Either >> ways, >> >>> >> this platform feels way too fragile to deploy on anything :( >> >>> >> >> >>> >> ---Mike >> >>> >> >> >>> >> On 1/19/2018 3:08 PM, Nimrod Levy wrote: >> >>> >>> Looks like disabling the C- states in the bios didn't change >> >>> anything. >> >>> >>> >> >>> >>> On Wed, Jan 17, 2018 at 9:22 PM Nimrod Levy > >>> >>> > wrote: >> >>> >>> >> >>> >>> That looks promising. I just found that seeing in the bios and >> >>> >>> disabled it. I'll see how it runs. >> >>> >>> >> >>> >>> Thanks >> >>> >>> >> >>> >>> >> >>> >>> On Wed, Jan 17, 2018, 18:38 Don Lewis > >>> >>> > wrote: >> >>> >>> >> >>> >>> On 17 Jan, Nimrod Levy wrote: >> >>> >>> > I'm running 11-STABLE from 12/9. amdtemp works for >> me. It >> >>> >>> also has the >> >>> >>> > systl indicating that it it has the shared page fix. I'm >> >>> >>> pretty sure I've >> >>> >>> > seen the lockups since then. I'll update to the latest >> >>> STABLE >> >>> >>> and see >> >>> >>> > what happens. >> >>> >>> > >> >>> >>> > One weird thing about my experience is that if I keep >> >>> >>> something running >> >>> >>> > continuously like the distributed.net < >> >>> http://distributed.net> >> >>> >>> client on 6 of 12 possible threads, >> >>> >>> > it keeps the system up for MUCH longer than without. >> This >> >>> is >> >>> >>> a home server >> >>> >>> > and very lightly loaded (one could argue insanely >> >>> overpowered >> >>> >>> for the use >> >>> >>> > case). >> >>> >>> >> >>> >>> This sounds like the problem with the deep Cx states that >> has >> >>> been >> >>> >>> reported by numerous Linux users. I think some >> motherboard >> >>> >>> brands are >> >>> >>> more likely to have the problem. See: >> >>> >>> >> >>> http://forum.asrock.com/forum_posts.asp?TID=5963&title= >> taichi-x370-with-ubuntu-idle-lock-ups-idle-freeze >> >>> >>> >> >>> >>> -- >> >>> >>> >> >>> >>> -- >> >>> >>> Nimrod >> >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> -- >> >>> >>> >> >>> >>> -- >> >>> >>> Nimrod >> >>> >>> >> >>> >> >> >>> > >> >>> > >> >>> > _______________________________________________ >> >>> > freebsd-stable@freebsd.org mailing list >> >>> > https://lists.freebsd.org/mailman/listinfo/freebsd-stable >> >>> > To unsubscribe, send any mail to " >> >>> freebsd-stable-unsubscribe@freebsd.org" >> >>> > >> >>> > >> >>> >> >>> >> >>> -- >> >>> ------------------- >> >>> Mike Tancsa, tel +1 519 651 3400 <(519)%20651-3400> >> >>> Sentex Communications, mike@sentex.net >> >>> Providing Internet services since 1994 www.sentex.net >> >>> Cambridge, Ontario Canada http://www.tancsa.com/ >> >>> _______________________________________________ >> >>> freebsd-stable@freebsd.org mailing list >> >>> https://lists.freebsd.org/mailman/listinfo/freebsd-stable >> >>> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@ >> freebsd.org" >> >>> >> >> >> >> >> >> -- >> >> >> >> -- >> >> Nimrod >> >> >> > >> > >> > -- >> > >> > -- >> > Nimrod >> > _______________________________________________ >> > freebsd-stable@freebsd.org mailing list >> > https://lists.freebsd.org/mailman/listinfo/freebsd-stable >> > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@ >> freebsd.org" >> > -- -- Nimrod From owner-freebsd-stable@freebsd.org Sun Jan 28 07:04:33 2018 Return-Path: Delivered-To: freebsd-stable@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 1F2C4EDCA98 for ; Sun, 28 Jan 2018 07:04:33 +0000 (UTC) (envelope-from bennett@sdf.org) Received: from mx.sdf.org (mx.sdf.org [205.166.94.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ol.sdf.org", Issuer "ol.sdf.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 92F256EED8; Sun, 28 Jan 2018 07:04:32 +0000 (UTC) (envelope-from bennett@sdf.org) Received: from sdf.org (IDENT:bennett@sdf.lonestar.org [205.166.94.15]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id w0S73d55012257 (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits) verified NO); Sun, 28 Jan 2018 07:03:39 GMT Received: (from bennett@localhost) by sdf.org (8.15.2/8.12.8/Submit) id w0S73cUh025725; Sun, 28 Jan 2018 01:03:38 -0600 (CST) From: Scott Bennett Message-Id: <201801280703.w0S73cUh025725@sdf.org> Date: Sun, 28 Jan 2018 01:03:38 -0600 To: ian@freebsd.org, Holger.Kipp@alogis.com, bennett@sdf.org Subject: Re: why does buildworld fail on stable/11 ? Cc: tech-lists@zyxst.net, freebsd-stable@freebsd.org, dim@FreeBSD.org References: <201801240851.w0O8pnDl008705@sdf.org> <0A86F03E-DB69-4DD0-B67B-E9BFBE3DC739@FreeBSD.org> <1516811808.42536.173.camel@freebsd.org> <201801250625.w0P6Pukm014218@sdf.org> <1516893199.42536.223.camel@freebsd.org> <201801260804.w0Q84t2f018882@sdf.org> <054FD748-B28B-4573-BF50-2E77D8C3C793@alogis.com> <1516984397.42536.245.camel@freebsd.org> In-Reply-To: <1516984397.42536.245.camel@freebsd.org> User-Agent: Heirloom mailx 12.5 6/20/10 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jan 2018 07:04:33 -0000 Ian Lepore wrote: > On Fri, 2018-01-26 at 09:52 +0000, Holger Kipp wrote: > > Dear Scott, > > > > Am 26.01.2018 um 09:07 schrieb Scott Bennett >: > > > > cd /usr/src; PATH=/sbin:/bin:/usr/sbin:/usr/bin MAKE_CMD=make /usr/obj/usr/src/make.amd64/bmake -m /usr/src/share/mk -f Makefile.inc1 TARGET=amd64 TARGET_ARCH=amd64 MK_META_MODE=no cleandir > > bmake: illegal argument to d option -- p > > usage: make [-BPSXeiknpqrstv] [-C directory] [-D variable] > > [-d flags] [-E variable] [-f makefile] [-I directory] > > [-j max_jobs] [-m directory] [-V variable] > > [variable=value] [target ...] > > *** Error code 2 > > > > Stop. > > make: stopped in /usr/src > > hellas# exit > > exit > > > > Script done on Fri Jan 26 01:33:18 2018 > > > > > > ?????????????????????????????????Scott Bennett, Comm. ASMELG, CFIAG > > > > This sound similar to an issue with make in 2013: > > > > 20130613: > > Some people report the following error after the switch to bmake: > > > > make: illegal option -- J > > usage: make [-BPSXeiknpqrstv] [-C directory] [-D variable] > > ... > > *** [buildworld] Error code 2 > > > > this likely due to an old instance of make in > > ${MAKEPATH} (${MAKEOBJDIRPREFIX}${.CURDIR}/make.${MACHINE}) > > which src/Makefile will use that blindly, if it exists, so if > > you see the above error: > > > > rm -rf `make -V MAKEPATH` > > > > should resolve it. > > > > Can you check if you have an older version of make in your makepath and delete / rename it? > > > > Yep, it's definitely running a bad old version of make, and the thought > that it's using /usr/obj/usr/src/make.amd64/bmake even though it's not Aack!! "make buildworld" doesn't kill that?? Wow. Why does it get missed by buildworld (or cleanworld, if that's what buildworld uses)? Should that get a PR? That program must have been sitting there for several *years*. The irony here is that I have long treated /usr/obj as disposable (i.e., I don't normally bother to back it up anywhere) because a) a "make buildworld buildkernel" will recreate all of it, and b) both of those targets include huge sequences of deletions that wipe out all existing versions of stuff that they will create. Or so I have thought until now. Apparently, the handbook needs to be updated to reflect the need to /bin/rm -rf /usr/obj/usr (or use newfs) before each buildworld just for safety's sake. > up to date fits the symptoms. ?I'm a bit confused by the "rm -rf" Yes, it certainly does. A quick newfs of the device where I keep /usr/obj, and it seems to work perfectly now. I'm almost certain that this same obsolete binary was what put a sudden halt to my updates of 10.3-STABLE back in early October 2016, as well. > command at the end... when I do make -V MAKEPATH I get nothing, so the > rm command would just be an error -- since that's from UPDATING in > 2013, I'm thinking it may be out of date advice now. > > I think the right fix here is probably "rm -rf /usr/obj/*" followed by > a make buildworld. > Well, in this case, /usr/obj is a mount point for a UFS2 file system, so it's less messy and much faster just to newfs it and mount it again. Anyway, thanks ever so much to Holger Kipp and Ian Lepore for finding the problem, and thanks also to everyone else who tried. The buildworld (complete with ccache) has completed, and right now a kernel (GENERIC except for SCHED_4BSD instead of the wretched SCHED_ULE) is busily being built. Then I will try a much more customized kernel, but I no longer expect any serious obstacles, thanks entirely to the help I got here on this list. Scott Bennett, Comm. ASMELG, CFIAG ********************************************************************** * Internet: bennett at sdf.org *xor* bennett at freeshell.org * *--------------------------------------------------------------------* * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * * -- Gov. John Hancock, New York Journal, 28 January 1790 * ********************************************************************** From owner-freebsd-stable@freebsd.org Sun Jan 28 16:05:57 2018 Return-Path: Delivered-To: freebsd-stable@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 422E1ECF7D7 for ; Sun, 28 Jan 2018 16:05:57 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D8B47839D8 for ; Sun, 28 Jan 2018 16:05:56 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from coleburn.home.andric.com (coleburn.home.andric.com [192.168.0.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 40C61EFEA; Sun, 28 Jan 2018 17:05:55 +0100 (CET) From: Dimitry Andric Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_F0028242-B705-458D-93D7-A2930ED772FD"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: i386 with 4GB RAM: less than 2GB available on A2SAV (Intel Atom E3940) Date: Sun, 28 Jan 2018 17:05:54 +0100 In-Reply-To: <20180128145703.GA80724@bali> Cc: freebsd-stable@freebsd.org To: Andre Albsmeier References: <20180128145703.GA80724@bali> X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jan 2018 16:05:57 -0000 --Apple-Mail=_F0028242-B705-458D-93D7-A2930ED772FD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 28 Jan 2018, at 15:57, Andre Albsmeier = wrote: > I have a lot of machines running with 4 GB physical RAM and, for > some reasons, I still have to use a 32 bits OS. >=20 > All of them show something between 3 and 3.5 GB of RAM available > in dmesg but the brand new Supermicro A2SAV really shocked me: >=20 > FreeBSD 11.1-STABLE #0: Mon Jan 15 06:57:10 CET 2018 > ... > real memory =3D 4294967296 (4096 MB) > avail memory =3D 1939558400 (1849 MB) > ... >=20 > So do people have any ideas how I might get a bit closer to at least > 3 GB? I assume there are no FreeBSD knobs which might help but hope > dies last... This is a common problem on i386. Most likely some ranges are reserved for I/O mappings, such as video cards. If you boot with -v, I think the kernel prints an overview of the physical ram chunks available? I don't know of any other way to get such an overview. Another option is to try PAE, but I have no idea how stable that is... -Dimitry --Apple-Mail=_F0028242-B705-458D-93D7-A2930ED772FD Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.2 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCWm304gAKCRCwXqMKLiCW o7yMAKDVrmxIEzH+TqDgiVERycLOorYS8QCg/3Rq0YoZ7cKbrTdBbsLGGB6O1P8= =DpaO -----END PGP SIGNATURE----- --Apple-Mail=_F0028242-B705-458D-93D7-A2930ED772FD-- From owner-freebsd-stable@freebsd.org Sun Jan 28 15:50:18 2018 Return-Path: Delivered-To: freebsd-stable@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 33242ECE073 for ; Sun, 28 Jan 2018 15:50:18 +0000 (UTC) (envelope-from petefrench@ingresso.co.uk) Received: from constantine.ingresso.co.uk (unknown [IPv6:2a02:b90:3002:411::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CB88D82AEA for ; Sun, 28 Jan 2018 15:50:17 +0000 (UTC) (envelope-from petefrench@ingresso.co.uk) Received: from [2a02:b90:3002:411::6] (helo=dilbert.ingresso.co.uk) by constantine.ingresso.co.uk with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89 (FreeBSD)) (envelope-from ) id 1efpDh-000FEP-Ih; Sun, 28 Jan 2018 15:50:13 +0000 Received: from petefrench by dilbert.ingresso.co.uk with local (Exim 4.90 (FreeBSD)) (envelope-from ) id 1efpDh-000CgU-Ft; Sun, 28 Jan 2018 15:50:13 +0000 To: freebsd@hda3.com, nimrodl@gmail.com Subject: Re: Ryzen issues on FreeBSD ? Cc: freebsd-stable@freebsd.org, rroot@rootautomation.com In-Reply-To: Message-Id: From: Pete French Date: Sun, 28 Jan 2018 15:50:13 +0000 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jan 2018 15:50:18 -0000 >> I'm about ready to have a party. My Ryzen 5 1600 has been up for over 8 >> days so far after changing the memory to a slower speed. System load >> hovers around .3 > > I couldn't find an easy way to down-speed my memory in the bios :( Out of interest, what motherboards are people using ? I still havent built my test system, desite being the OP in the thread, but I have an MSI B350 Tomahawk as the test board. Sadly, I think the length and contnet of this thread has answered one of my original questions though, what was whether or not it is safe to go ahead and order Epyc boards for the data centre. I am not prepared to gamble on that right now when people on the desktop have had so many issue. -pete. From owner-freebsd-stable@freebsd.org Sun Jan 28 16:00:41 2018 Return-Path: Delivered-To: freebsd-stable@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 4BA80ECEFB5 for ; Sun, 28 Jan 2018 16:00:41 +0000 (UTC) (envelope-from nimrod@nimrod.is-a-geek.net) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DFBF88348F for ; Sun, 28 Jan 2018 16:00:40 +0000 (UTC) (envelope-from nimrod@nimrod.is-a-geek.net) Received: by mail-yw0-x22e.google.com with SMTP id m84so1862415ywd.5 for ; Sun, 28 Jan 2018 08:00:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NBfhFJ6aMp7W43bANJVmNygAGLFCkItIE7uHI6co0Cg=; b=Wa4CfJOpJz+t7JaflWlS5GAXUJMefSk4WrcJWu6iFzpL4x7hfgbL8H+NJxCPsVgehp smaD8RmNdpFALCUPZ78xE4z8Ef+OaJ9gqxiJ7YkuJhhZNMj7TC2R7zw7mL9MtA9sGQ7A 2Y7ti0+RxCMCDYr/6l1hVEv14ekOwfaRBDAqSvLW8l6nYdIFhsU3d1NGtu6YDWTGgZcW VmrVdN6rF5YUJMRf5Kje8+v6bpkmjYcU7jeWE89wjex/TypZMUW8WjzfDhHbaThitQHT O0yoZASVxlXx9PbFULOdLaH7sDI94ymFg34w6awrCMTCqqCWUuGj/YjS6YIWSBwWmMbX eT0g== 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=NBfhFJ6aMp7W43bANJVmNygAGLFCkItIE7uHI6co0Cg=; b=Jd40JUVBI1mEVM51NSKmZxAQw3b2PCPXYI5GSZ6fsOsgV2Z2bDLndP/4Md++tUl8JX 11jIz08SBgi9jarEd5AmQet0yBUKlxwd7iN2QGExAkxqAUwk6gaMgwFI/GqdAKNZkCXp DqdATjO2EbpT+ztQ4Fw1WMqDsQOTx69PbBs9BjVxMijHKA350NanCe7DxEOXwomZWsre pSHi5PMRvJ0N8JiFIYNPRPsrD9/lWcNv87PC5wEzZSfn2E5psNiA3BOwuql2beaSooN8 Kmu4xColj5QopLRTOeGmEvCpJBFa8Spn0L7tx/LmNPMSCw6JVzpiflp8UK9nalOScOeR V28A== X-Gm-Message-State: AKwxytcX8X69Ry/jhc6fg9RJrfHLXd42w6mk6kYgDzdhF2L2gSlly6Ah DR07JOYpiPuTuj29Yc7snGAa4RVNP233EVtjKULhCckT X-Google-Smtp-Source: AH8x226/3mBg5D8IJBiels1u9hPYSfyzpjHZZOEuO+DdCnPkQBl/wyPfKcnO/CF1wJjQJ/XbzTdafp3qVDt6Udih4ZI= X-Received: by 10.13.227.198 with SMTP id m189mr15573997ywe.506.1517155239703; Sun, 28 Jan 2018 08:00:39 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Nimrod Levy Date: Sun, 28 Jan 2018 16:00:29 +0000 Message-ID: Subject: Re: Ryzen issues on FreeBSD ? To: Pete French Cc: freebsd@hda3.com, freebsd-stable@freebsd.org, rroot@rootautomation.com Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jan 2018 16:00:41 -0000 I have the Asus prime B350-plus https://www.asus.com/us/Motherboards/PRIME-B350-PLUS/ On Sun, Jan 28, 2018 at 10:50 AM Pete French wrote: > >> I'm about ready to have a party. My Ryzen 5 1600 has been up for over 8 > >> days so far after changing the memory to a slower speed. System load > >> hovers around .3 > > > > I couldn't find an easy way to down-speed my memory in the bios :( > > Out of interest, what motherboards are people using ? I still havent > built my test system, desite being the OP in the thread, but I have > an MSI B350 Tomahawk as the test board. > > Sadly, I think the length and contnet of this thread has answered one > of my original questions though, what was whether or not it is safe to > go ahead and order Epyc boards for the data centre. I am not prepared > to gamble on that right now when people on the desktop have had so many > issue. > > -pete. > > -- -- Nimrod From owner-freebsd-stable@freebsd.org Sun Jan 28 15:03:35 2018 Return-Path: Delivered-To: freebsd-stable@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 B9B7EECB3A9 for ; Sun, 28 Jan 2018 15:03:35 +0000 (UTC) (envelope-from Andre.Albsmeier@siemens.com) Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "goliath.siemens.de", Issuer "Siemens Issuing CA Internet Server 2017" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2B9238061D for ; Sun, 28 Jan 2018 15:03:34 +0000 (UTC) (envelope-from Andre.Albsmeier@siemens.com) Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by goliath.siemens.de (8.15.2/8.15.2) with ESMTPS id w0SEv3mG001083 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Sun, 28 Jan 2018 15:57:04 +0100 Received: from curry.mchp.siemens.de (curry.mchp.siemens.de [139.25.40.130]) by mail2.siemens.de (8.15.2/8.15.2) with ESMTP id w0SEv3bM015941 for ; Sun, 28 Jan 2018 15:57:03 +0100 Received: (from user@localhost) by curry.mchp.siemens.de (8.15.2/8.15.2) id w0SEv3UO018040; Date: Sun, 28 Jan 2018 15:57:03 +0100 From: Andre Albsmeier To: freebsd-stable@freebsd.org Cc: Andre.Albsmeier@siemens.com Subject: i386 with 4GB RAM: less than 2GB available on A2SAV (Intel Atom E3940) Message-ID: <20180128145703.GA80724@bali> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.7.2 (2016-11-26) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jan 2018 15:03:35 -0000 I have a lot of machines running with 4 GB physical RAM and, for some reasons, I still have to use a 32 bits OS. All of them show something between 3 and 3.5 GB of RAM available in dmesg but the brand new Supermicro A2SAV really shocked me: FreeBSD 11.1-STABLE #0: Mon Jan 15 06:57:10 CET 2018 ... real memory = 4294967296 (4096 MB) avail memory = 1939558400 (1849 MB) ... So do people have any ideas how I might get a bit closer to at least 3 GB? I assume there are no FreeBSD knobs which might help but hope dies last... From owner-freebsd-stable@freebsd.org Sun Jan 28 15:51:29 2018 Return-Path: Delivered-To: freebsd-stable@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 32F06ECE152 for ; Sun, 28 Jan 2018 15:51:29 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [78.47.246.247]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B11B482BA2 for ; Sun, 28 Jan 2018 15:51:28 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id w0SFpFX5057124 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 28 Jan 2018 16:51:16 +0100 (CET) (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: Andre.Albsmeier@siemens.com Received: from [10.58.0.4] ([10.58.0.4]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id w0SFpARF048089 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 28 Jan 2018 22:51:10 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: i386 with 4GB RAM: less than 2GB available on A2SAV (Intel Atom E3940) To: Andre Albsmeier , freebsd-stable@freebsd.org References: <20180128145703.GA80724@bali> From: Eugene Grosbein Message-ID: <5A6DF168.3010902@grosbein.net> Date: Sun, 28 Jan 2018 22:51:04 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <20180128145703.GA80724@bali> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=2.2 required=5.0 tests=BAYES_00, LOCAL_FROM, RDNS_NONE autolearn=no autolearn_force=no version=3.4.1 X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 1.9 RDNS_NONE Delivered to internal network by a host with no rDNS * 2.6 LOCAL_FROM From my domains X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on hz.grosbein.net X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jan 2018 15:51:29 -0000 28.01.2018 21:57, Andre Albsmeier wrote: > I have a lot of machines running with 4 GB physical RAM and, for > some reasons, I still have to use a 32 bits OS. > > All of them show something between 3 and 3.5 GB of RAM available > in dmesg but the brand new Supermicro A2SAV really shocked me: > > FreeBSD 11.1-STABLE #0: Mon Jan 15 06:57:10 CET 2018 > ... > real memory = 4294967296 (4096 MB) > avail memory = 1939558400 (1849 MB) > ... > > So do people have any ideas how I might get a bit closer to at least > 3 GB? I assume there are no FreeBSD knobs which might help but hope > dies last... First, try to decrease amount of RAM dedicated to integrated video, if any (BIOS Setup). Also, I'd like to know reasons that made you stick to 32 bit OS as we have pretty good support for 32 bit applications running under 64 bit system. From owner-freebsd-stable@freebsd.org Sun Jan 28 16:32:46 2018 Return-Path: Delivered-To: freebsd-stable@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 5053FED155D for ; Sun, 28 Jan 2018 16:32:46 +0000 (UTC) (envelope-from mike@karels.net) Received: from mail.karels.net (mail.karels.net [216.160.39.52]) by mx1.freebsd.org (Postfix) with ESMTP id CFF0E84CA0; Sun, 28 Jan 2018 16:32:45 +0000 (UTC) (envelope-from mike@karels.net) Received: from mail.karels.net (localhost [127.0.0.1]) by mail.karels.net (8.15.2/8.15.2) with ESMTP id w0SGWiui055204; Sun, 28 Jan 2018 10:32:44 -0600 (CST) (envelope-from mike@karels.net) Message-Id: <201801281632.w0SGWiui055204@mail.karels.net> To: Dimitry Andric cc: Andre Albsmeier , freebsd-stable@freebsd.org From: Mike Karels Reply-to: mike@karels.net Subject: Re: i386 with 4GB RAM: less than 2GB available on A2SAV (Intel Atom E3940) In-reply-to: Your message of Sun, 28 Jan 2018 17:05:54 +0100. MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <55202.1517157164.1@mail.karels.net> Date: Sun, 28 Jan 2018 10:32:44 -0600 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jan 2018 16:32:46 -0000 > On 28 Jan 2018, at 15:57, Andre Albsmeier = > wrote: > > I have a lot of machines running with 4 GB physical RAM and, for > > some reasons, I still have to use a 32 bits OS. > >=20 > > All of them show something between 3 and 3.5 GB of RAM available > > in dmesg but the brand new Supermicro A2SAV really shocked me: > >=20 > > FreeBSD 11.1-STABLE #0: Mon Jan 15 06:57:10 CET 2018 > > ... > > real memory =3D 4294967296 (4096 MB) > > avail memory =3D 1939558400 (1849 MB) > > ... > >=20 > > So do people have any ideas how I might get a bit closer to at least > > 3 GB? I assume there are no FreeBSD knobs which might help but hope > > dies last... > This is a common problem on i386. Most likely some ranges are reserved > for I/O mappings, such as video cards. If you boot with -v, I think the > kernel prints an overview of the physical ram chunks available? I don't > know of any other way to get such an overview. > Another option is to try PAE, but I have no idea how stable that is... > -Dimitry I suspect that the unavailable RAM has been mapped above 4 GB by the BIOS. About PAE: at $JOB, we have a FreeBSD 8.2 system that has been running PAE reliably since 8.2 was new. Also, we ship amd64 systems that run mostly 32-bit binaries, which works well. Mike From owner-freebsd-stable@freebsd.org Sun Jan 28 20:28:51 2018 Return-Path: Delivered-To: freebsd-stable@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 84D46EDD672 for ; Sun, 28 Jan 2018 20:28:51 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from mx2.catspoiler.org (mx2.catspoiler.org [IPv6:2607:f740:16::d18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "amnesiac", Issuer "amnesiac" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 194396D1C4 for ; Sun, 28 Jan 2018 20:28:51 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org ([76.212.85.177]) by mx2.catspoiler.org (8.15.2/8.15.2) with ESMTPS id w0SKTIHl013980 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Sun, 28 Jan 2018 20:29:20 GMT (envelope-from truckman@FreeBSD.org) Received: from mousie.catspoiler.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.15.2/8.15.2) with ESMTPS id w0SK8qcG096633 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 28 Jan 2018 12:28:41 -0800 (PST) (envelope-from truckman@FreeBSD.org) Date: Sun, 28 Jan 2018 12:28:41 -0800 (PST) From: Don Lewis Subject: Re: Ryzen issues on FreeBSD ? To: Pete French cc: freebsd@hda3.com, nimrodl@gmail.com, freebsd-stable@freebsd.org, rroot@rootautomation.com In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=us-ascii Content-Disposition: INLINE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jan 2018 20:28:51 -0000 On 28 Jan, Pete French wrote: >>> I'm about ready to have a party. My Ryzen 5 1600 has been up for over 8 >>> days so far after changing the memory to a slower speed. System load >>> hovers around .3 >> >> I couldn't find an easy way to down-speed my memory in the bios :( > > Out of interest, what motherboards are people using ? I still havent > built my test system, desite being the OP in the thread, but I have > an MSI B350 Tomahawk as the test board. Gigabyte AX370 Gaming 5. I'd be wary of the B350 boards with the higher TDP eight core Ryzen CPUs since the VRMs on the cheaper boards tend to have less robust VRM designs. Personally I won't put together a system without ECC RAM both for overall reliability and also the fact that the error reporting will immediately flag (or eliminate) RAM issues when the system is unstable. That pretty much confined my motherboard choices to the higher end X370 motherboards. I think only ASRock makes a B350 motherboard with ECC support. There's no reason that ECC support couldn't be universal other than product differentiation so that the motherboard manufacturers can collect more $$$ from anyone who cares about this feature. From owner-freebsd-stable@freebsd.org Sun Jan 28 21:01:28 2018 Return-Path: Delivered-To: freebsd-stable@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 1B333EDEE8B for ; Sun, 28 Jan 2018 21:01:28 +0000 (UTC) (envelope-from peter@hda3.com) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EF21F6E47D for ; Sun, 28 Jan 2018 21:01:26 +0000 (UTC) (envelope-from peter@hda3.com) Received: by mail-qt0-x236.google.com with SMTP id x27so10326581qtm.12 for ; Sun, 28 Jan 2018 13:01:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hda3-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=WH7+Seqrzc887ABWuL4EN3RIwigIX5Ko13uLepq/hz4=; b=S8TKdOYIXQ+scYevcLC/eLqRnHCdhFDpqPWeSKCAIg12IJRYHBJg+XZiGZca/sOoJl Gi0MEQfzMxHUpuDFIdkTxFl2QLHCRNEi2pCKO/9W0e+oDjoT5QXqI7TNBzMExFbT5HZ9 vZW68rQVYI//cfQa/mcoFQ4iQHFWEuzFHeE/gt7nj00G8dU7uGN2ff8wMaYvfH3dQkCm LSkjZGf4mPZAsyVttYKgvpQmEt5ChKzevt8S8qaVI3yz33za8px3ypbkqms4tZqiqhJ+ 4KuBmRUgStGvn7+1qSUXL9xtPCGP5pwo1U6FyYog5VkvzQivSCy2L1+EXRWBUkCVIJPr y25Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=WH7+Seqrzc887ABWuL4EN3RIwigIX5Ko13uLepq/hz4=; b=Q8l9d0XRAIS15BjIQYUCLKCcAJwAiVIqwW1vVBu1DXQLaOHt970S9xC6GqoG4QEtok ask0ckFche4rM20FKfB/DOdXni+n9DM2Eyop0+tC0qCv6f4DOKOfqIxCxtvJZxo0wRyn 2O7d0QN8my4VruRSkiNDsSENQD6jkOme0IUL/KKW2+dYd8Ym0tIYpSV07l45CVCa3V92 eUH66Gpsb0mhCWw4W0FM5nAY3I3asmvCw6JS2scG2BzPcin8rlNs7kb6onhju4Fo+1MB Ki/+aoEz/ZYKkmGGSI4pBvdswmYLexvybr2VGAgeyqCVmiXe6GIoDGTDqSn97mSnWuan t+Qg== X-Gm-Message-State: AKwxytfGRLWi4m9l5b4LUeWAlcRcopgNK9s7z+bwicHHIpgncOuDG5Tz wucOqDFNH14KWEuwH2VMeUV8EJknmUgXKVgU4tPxbw== X-Google-Smtp-Source: AH8x225lHcN+BvVI02Whk3Ol1k9wUoPppgxZEMYGxyhGq03VN/FxuMDP/JylFc2a6TXbftUJMicwZ2O4J/jQ/+aaL9w= X-Received: by 10.200.23.66 with SMTP id u2mr35140214qtk.294.1517173285973; Sun, 28 Jan 2018 13:01:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.39.83 with HTTP; Sun, 28 Jan 2018 13:01:05 -0800 (PST) In-Reply-To: References: From: Peter Moody Date: Sun, 28 Jan 2018 13:01:05 -0800 Message-ID: Subject: Re: Ryzen issues on FreeBSD ? To: Don Lewis Cc: Pete French , FreeBSD-STABLE Mailing List , Ryan Root , Nimrod Levy Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jan 2018 21:01:28 -0000 > Gigabyte AX370 Gaming 5. all of issues so far have been on a pair of asrock ab350's. But I've got an msi x370 coming early next week. From owner-freebsd-stable@freebsd.org Sun Jan 28 21:23:35 2018 Return-Path: Delivered-To: freebsd-stable@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 406B9EDFE98 for ; Sun, 28 Jan 2018 21:23:35 +0000 (UTC) (envelope-from petefrench@ingresso.co.uk) Received: from constantine.ingresso.co.uk (unknown [IPv6:2a02:b90:3002:411::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D42D86F47D; Sun, 28 Jan 2018 21:23:34 +0000 (UTC) (envelope-from petefrench@ingresso.co.uk) Received: from cpc73666-dals20-2-0-cust303.20-2.cable.virginm.net ([82.47.237.48] helo=foula.drayhouse.twisted.org.uk) by constantine.ingresso.co.uk with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89 (FreeBSD)) (envelope-from ) id 1efuQF-000Gla-6h; Sun, 28 Jan 2018 21:23:31 +0000 Subject: Re: Ryzen issues on FreeBSD ? To: Don Lewis Cc: freebsd@hda3.com, nimrodl@gmail.com, freebsd-stable@freebsd.org, rroot@rootautomation.com References: From: Pete French Message-ID: Date: Sun, 28 Jan 2018 21:23:30 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jan 2018 21:23:35 -0000 On 28/01/2018 20:28, Don Lewis wrote: > I'd be wary of the B350 boards with the higher TDP eight core Ryzen CPUs > since the VRMs on the cheaper boards tend to have less robust VRM > designs. Gah! Yes, I forgot that.originally sec'd the board for a smaller Ryzen, then though "what the hell" and got the 1700 without going back and checking that kind of stuff. Hmm, shall swap for a different one if I can. Thanks for poining that out. -pete. [kicking himself...] From owner-freebsd-stable@freebsd.org Mon Jan 29 00:11:51 2018 Return-Path: Delivered-To: freebsd-stable@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 B8436EC6DFA for ; Mon, 29 Jan 2018 00:11:51 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from mx2.catspoiler.org (mx2.catspoiler.org [IPv6:2607:f740:16::d18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "amnesiac", Issuer "amnesiac" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 5126975420 for ; Mon, 29 Jan 2018 00:11:51 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org ([76.212.85.177]) by mx2.catspoiler.org (8.15.2/8.15.2) with ESMTPS id w0T0CJRk014551 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 29 Jan 2018 00:12:20 GMT (envelope-from truckman@FreeBSD.org) Received: from mousie.catspoiler.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.15.2/8.15.2) with ESMTPS id w0T0BfY9005315 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 28 Jan 2018 16:11:42 -0800 (PST) (envelope-from truckman@FreeBSD.org) Date: Sun, 28 Jan 2018 16:11:36 -0800 (PST) From: Don Lewis Subject: Re: Ryzen issues on FreeBSD ? To: Pete French cc: freebsd@hda3.com, nimrodl@gmail.com, freebsd-stable@freebsd.org, rroot@rootautomation.com In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=us-ascii Content-Disposition: INLINE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jan 2018 00:11:51 -0000 On 28 Jan, Pete French wrote: > > > On 28/01/2018 20:28, Don Lewis wrote: >> I'd be wary of the B350 boards with the higher TDP eight core Ryzen CPUs >> since the VRMs on the cheaper boards tend to have less robust VRM >> designs. > > Gah! Yes, I forgot that.originally sec'd the board for a smaller Ryzen, > then though "what the hell" and got the 1700 without going back and > checking that kind of stuff. Hmm, shall swap for a different one if I > can. Thanks for poining that out. I started off with a Gigabyte AB350 Gaming for my 1700X back when there was enough ambiguity about ECC support to give me hope that it would work. Everything seemed to work other than ECC and the problems caused by my buggy CPU and the shared page issue, but the VRM temps in the BIOS were really high (and I had no way to monitor that under load). When I upgraded to get working ECC, I also looked at reviews about VRM quality. From owner-freebsd-stable@freebsd.org Mon Jan 29 00:25:40 2018 Return-Path: Delivered-To: freebsd-stable@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 3C218EC7DB1 for ; Mon, 29 Jan 2018 00:25:40 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from mx2.catspoiler.org (mx2.catspoiler.org [IPv6:2607:f740:16::d18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "amnesiac", Issuer "amnesiac" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C21897607A for ; Mon, 29 Jan 2018 00:25:39 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org ([76.212.85.177]) by mx2.catspoiler.org (8.15.2/8.15.2) with ESMTPS id w0T0Q82Z014590 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 29 Jan 2018 00:26:09 GMT (envelope-from truckman@FreeBSD.org) Received: from mousie.catspoiler.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.15.2/8.15.2) with ESMTPS id w0T0BfYC005315 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 28 Jan 2018 16:25:31 -0800 (PST) (envelope-from truckman@FreeBSD.org) Date: Sun, 28 Jan 2018 16:25:31 -0800 (PST) From: Don Lewis Subject: Re: Ryzen issues on FreeBSD ? To: Peter Moody cc: Nimrod Levy , FreeBSD-STABLE Mailing List , Ryan Root In-Reply-To: Message-ID: References: <8e842dec-ade7-37d1-6bd8-856ea1a827ca@sentex.net> <3b625072-dfb3-6b4f-494d-7fe1b2fa554c@ingresso.co.uk> <2c6ce4dd-f43c-7c40-abc2-732d6f8996ec@sentex.net> <795dbb79-3c18-d967-98b9-5d09a740dbfe@sentex.net> <9b769e4e-b098-b294-0bce-8bb1c42e8a59@rootautomation.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=us-ascii Content-Disposition: INLINE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jan 2018 00:25:40 -0000 On 27 Jan, Peter Moody wrote: > Whelp, I replaced the r5 1600x with an r7 1700 (au 1734) and I'm now > getting minutes of uptime before I hard crash. With smt, without, with c > states, without, with opcache, without. No difference. Check the temperatures. Maybe the heat sink isn't making good contact after the CPU replacement. From owner-freebsd-stable@freebsd.org Mon Jan 29 00:41:21 2018 Return-Path: Delivered-To: freebsd-stable@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 2EAA1EC8D77 for ; Mon, 29 Jan 2018 00:41:21 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from mx2.catspoiler.org (mx2.catspoiler.org [IPv6:2607:f740:16::d18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "amnesiac", Issuer "amnesiac" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B707D768E5; Mon, 29 Jan 2018 00:41:20 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org ([76.212.85.177]) by mx2.catspoiler.org (8.15.2/8.15.2) with ESMTPS id w0T0fmdi014628 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 29 Jan 2018 00:41:50 GMT (envelope-from truckman@FreeBSD.org) Received: from mousie.catspoiler.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.15.2/8.15.2) with ESMTPS id w0T0BfYF005315 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 28 Jan 2018 16:41:12 -0800 (PST) (envelope-from truckman@FreeBSD.org) Date: Sun, 28 Jan 2018 16:41:11 -0800 (PST) From: Don Lewis Subject: Re: Ryzen issues on FreeBSD ? To: Mike Tancsa cc: Peter Moody , Pete French , freebsd-stable@freebsd.org, Andriy Gapon In-Reply-To: <55913e41-3a8a-9a4d-6862-e09a3d0f4d55@sentex.net> Message-ID: References: <8e842dec-ade7-37d1-6bd8-856ea1a827ca@sentex.net> <9b769e4e-b098-b294-0bce-8bb1c42e8a59@rootautomation.com> <730eb882-1c6a-afb7-0ada-396db44fb34b@ingresso.co.uk> <8b882970-4d5d-2a96-4dac-779cab07b9ae@sentex.net> <343acf99-3e9e-093a-7390-c142396c2985@sentex.net> <3dd9a61b-511d-db2e-80ca-cbc9a4b65f92@sentex.net> <55913e41-3a8a-9a4d-6862-e09a3d0f4d55@sentex.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=us-ascii Content-Disposition: INLINE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jan 2018 00:41:21 -0000 On 27 Jan, Mike Tancsa wrote: > On 1/27/2018 3:23 AM, Don Lewis wrote: >> >> I just ran into this for this first time with samba46. I kicked of a >> ports build this evening before leaving for several hours. When I >> returned, samba46 had failed with a build runaway. I just tried again >> and I see python stuck in the usem state. This is what I see with >> procstat -k: > > Hmmm, is this indicative of a processor bug or a FreeBSD bug or its > indeterminate at this point ? My suspicion is a FreeBSD bug, probably a locking / race issue. I know that we've had to make some tweeks to our code for AMD CPUs, like this: ------------------------------------------------------------------------ r321608 | kib | 2017-07-27 01:37:07 -0700 (Thu, 27 Jul 2017) | 9 lines Use MFENCE to serialize RDTSC on non-Intel CPUs. Kernel already used the stronger barrier instruction for AMDs, correct the userspace fast gettimeofday() implementation as well. I did go back and look at the build runaways that I've occasionally seen on my AMD FX-8320E package builder. I haven't seen the python issue there, but have seen gmake get stuck in a sleeping state with a bunch of zombie offspring. From owner-freebsd-stable@freebsd.org Mon Jan 29 15:19:57 2018 Return-Path: Delivered-To: freebsd-stable@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 2F4D6ECC9C4 for ; Mon, 29 Jan 2018 15:19:57 +0000 (UTC) (envelope-from eric@vangyzen.net) Received: from smtp.vangyzen.net (hotblack.vangyzen.net [199.48.133.146]) by mx1.freebsd.org (Postfix) with ESMTP id CFB2677C38 for ; Mon, 29 Jan 2018 15:19:55 +0000 (UTC) (envelope-from eric@vangyzen.net) Received: from sweettea.beer.town (unknown [76.164.8.130]) by smtp.vangyzen.net (Postfix) with ESMTPSA id 099045646E for ; Mon, 29 Jan 2018 09:13:02 -0600 (CST) Subject: Re: i386 with 4GB RAM: less than 2GB available on A2SAV (Intel Atom E3940) To: freebsd-stable@freebsd.org References: <20180128145703.GA80724@bali> From: Eric van Gyzen Message-ID: Date: Mon, 29 Jan 2018 09:12:59 -0600 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jan 2018 15:19:57 -0000 On 01/28/2018 10:05, Dimitry Andric wrote: > On 28 Jan 2018, at 15:57, Andre Albsmeier wrote: >> I have a lot of machines running with 4 GB physical RAM and, for >> some reasons, I still have to use a 32 bits OS. >> >> All of them show something between 3 and 3.5 GB of RAM available >> in dmesg but the brand new Supermicro A2SAV really shocked me: >> >> FreeBSD 11.1-STABLE #0: Mon Jan 15 06:57:10 CET 2018 >> ... >> real memory = 4294967296 (4096 MB) >> avail memory = 1939558400 (1849 MB) >> ... >> >> So do people have any ideas how I might get a bit closer to at least >> 3 GB? I assume there are no FreeBSD knobs which might help but hope >> dies last... > > This is a common problem on i386. Most likely some ranges are reserved > for I/O mappings, such as video cards. If you boot with -v, I think the > kernel prints an overview of the physical ram chunks available? I don't > know of any other way to get such an overview. sysctl machdep.smap on BIOS, machdep.efi_map on UEFI. Eric From owner-freebsd-stable@freebsd.org Tue Jan 30 06:59:42 2018 Return-Path: Delivered-To: freebsd-stable@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 67247EDDD60 for ; Tue, 30 Jan 2018 06:59:42 +0000 (UTC) (envelope-from Andre.Albsmeier@siemens.com) Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "goliath.siemens.de", Issuer "Siemens Issuing CA Internet Server 2017" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D50DA7EB55 for ; Tue, 30 Jan 2018 06:59:41 +0000 (UTC) (envelope-from Andre.Albsmeier@siemens.com) Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by goliath.siemens.de (8.15.2/8.15.2) with ESMTPS id w0U6xXOV017506 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 30 Jan 2018 07:59:33 +0100 Received: from curry.mchp.siemens.de (curry.mchp.siemens.de [139.25.40.130]) by mail2.siemens.de (8.15.2/8.15.2) with ESMTP id w0U6xXpP004360; Tue, 30 Jan 2018 07:59:33 +0100 Received: (from user@localhost) by curry.mchp.siemens.de (8.15.2/8.15.2) id w0U6xXkA032479; Date: Tue, 30 Jan 2018 07:59:31 +0100 From: Andre Albsmeier To: Eugene Grosbein Cc: Andre Albsmeier , freebsd-stable@freebsd.org Subject: Re: i386 with 4GB RAM: less than 2GB available on A2SAV (Intel Atom E3940) Message-ID: <20180130065931.GA43711@bali> References: <20180128145703.GA80724@bali> <5A6DF168.3010902@grosbein.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5A6DF168.3010902@grosbein.net> User-Agent: Mutt/1.7.2 (2016-11-26) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jan 2018 06:59:42 -0000 On Sun, 28-Jan-2018 at 22:51:04 +0700, Eugene Grosbein wrote: > 28.01.2018 21:57, Andre Albsmeier wrote: > > > I have a lot of machines running with 4 GB physical RAM and, for > > some reasons, I still have to use a 32 bits OS. > > > > All of them show something between 3 and 3.5 GB of RAM available > > in dmesg but the brand new Supermicro A2SAV really shocked me: > > > > FreeBSD 11.1-STABLE #0: Mon Jan 15 06:57:10 CET 2018 > > ... > > real memory = 4294967296 (4096 MB) > > avail memory = 1939558400 (1849 MB) > > ... > > > > So do people have any ideas how I might get a bit closer to at least > > 3 GB? I assume there are no FreeBSD knobs which might help but hope > > dies last... > > First, try to decrease amount of RAM dedicated to integrated video, if any (BIOS Setup). Done that. I have set everything as small as possible but this didn't help. After a BIOS upgrade, I found the promising option MAX TOLUD which was set to 2GB. I changed it to 3GB but nothing changed. > > Also, I'd like to know reasons that made you stick to 32 bit OS > as we have pretty good support for 32 bit applications running under 64 bit system. I (still) have 32 bit machines and don't want to maintain 2 userlands. Each machine has its own kernel but userland (updated via nfs) must remain 32 bit. Or is it possible to boot a 64 bit kernel and have everything else in 32 bit? From owner-freebsd-stable@freebsd.org Tue Jan 30 07:07:04 2018 Return-Path: Delivered-To: freebsd-stable@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 3279EEDE4FA for ; Tue, 30 Jan 2018 07:07:04 +0000 (UTC) (envelope-from Andre.Albsmeier@siemens.com) Received: from david.siemens.de (david.siemens.de [192.35.17.14]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "david.siemens.de", Issuer "Siemens Issuing CA Internet Server 2017" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A207C7F1B5; Tue, 30 Jan 2018 07:07:03 +0000 (UTC) (envelope-from Andre.Albsmeier@siemens.com) Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by david.siemens.de (8.15.2/8.15.2) with ESMTPS id w0U70I2u009477 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 30 Jan 2018 08:00:18 +0100 Received: from curry.mchp.siemens.de (curry.mchp.siemens.de [139.25.40.130]) by mail3.siemens.de (8.15.2/8.15.2) with ESMTP id w0U70Ich001181; Tue, 30 Jan 2018 08:00:18 +0100 Received: (from user@localhost) by curry.mchp.siemens.de (8.15.2/8.15.2) id w0U70Ilr032504; Date: Tue, 30 Jan 2018 08:00:18 +0100 From: Andre Albsmeier To: Dimitry Andric Cc: Andre Albsmeier , freebsd-stable@freebsd.org Subject: Re: i386 with 4GB RAM: less than 2GB available on A2SAV (Intel Atom E3940) Message-ID: <20180130070018.GA43715@bali> References: <20180128145703.GA80724@bali> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.2 (2016-11-26) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jan 2018 07:07:04 -0000 On Sun, 28-Jan-2018 at 17:05:54 +0100, Dimitry Andric wrote: > On 28 Jan 2018, at 15:57, Andre Albsmeier wrote: > > I have a lot of machines running with 4 GB physical RAM and, for > > some reasons, I still have to use a 32 bits OS. > > > > All of them show something between 3 and 3.5 GB of RAM available > > in dmesg but the brand new Supermicro A2SAV really shocked me: > > > > FreeBSD 11.1-STABLE #0: Mon Jan 15 06:57:10 CET 2018 > > ... > > real memory = 4294967296 (4096 MB) > > avail memory = 1939558400 (1849 MB) > > ... > > > > So do people have any ideas how I might get a bit closer to at least > > 3 GB? I assume there are no FreeBSD knobs which might help but hope > > dies last... > > This is a common problem on i386. Most likely some ranges are reserved > for I/O mappings, such as video cards. If you boot with -v, I think the > kernel prints an overview of the physical ram chunks available? I don't Yes, it does: real memory = 4294967296 (4096 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009afff, 630784 bytes (154 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000000c28000 - 0x000000001fffffff, 524124160 bytes (127960 pages) 0x0000000022151000 - 0x0000000075733fff, 1398681600 bytes (341475 pages) 0x000000007998e000 - 0x0000000079a5efff, 856064 bytes (209 pages) 0x000000007a151000 - 0x000000007a4bffff, 3600384 bytes (879 pages) 0x000000007a4eb000 - 0x000000007aae2fff, 6258688 bytes (1528 pages) 0x000000007aae5000 - 0x000000007afeffff, 5287936 bytes (1291 pages) avail memory = 1939800064 (1849 MB) -Andre > know of any other way to get such an overview. > > Another option is to try PAE, but I have no idea how stable that is... > > -Dimitry > -- Win98: useless extension to a minor patch release for 32-bit extensions and a graphical shell for a 16-bit patch to an 8-bit operating system originally coded for a 4-bit microprocessor, written by a 2-bit company that can't stand for 1 bit of competition. From owner-freebsd-stable@freebsd.org Tue Jan 30 07:11:29 2018 Return-Path: Delivered-To: freebsd-stable@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 D31F9EDE936 for ; Tue, 30 Jan 2018 07:11:29 +0000 (UTC) (envelope-from Andre.Albsmeier@siemens.com) Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "goliath.siemens.de", Issuer "Siemens Issuing CA Internet Server 2017" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3330A7F556; Tue, 30 Jan 2018 07:11:28 +0000 (UTC) (envelope-from Andre.Albsmeier@siemens.com) Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by goliath.siemens.de (8.15.2/8.15.2) with ESMTPS id w0U7BQET031924 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 30 Jan 2018 08:11:26 +0100 Received: from curry.mchp.siemens.de (curry.mchp.siemens.de [139.25.40.130]) by mail2.siemens.de (8.15.2/8.15.2) with ESMTP id w0U7BOl8004256; Tue, 30 Jan 2018 08:11:25 +0100 Received: (from user@localhost) by curry.mchp.siemens.de (8.15.2/8.15.2) id w0U7BOLi032571; Date: Tue, 30 Jan 2018 08:11:23 +0100 From: Andre Albsmeier To: Mike Karels Cc: Dimitry Andric , Andre Albsmeier , freebsd-stable@freebsd.org Subject: Re: i386 with 4GB RAM: less than 2GB available on A2SAV (Intel Atom E3940) Message-ID: <20180130071123.GB43715@bali> References: <201801281632.w0SGWiui055204@mail.karels.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201801281632.w0SGWiui055204@mail.karels.net> User-Agent: Mutt/1.7.2 (2016-11-26) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jan 2018 07:11:30 -0000 On Sun, 28-Jan-2018 at 10:32:44 -0600, Mike Karels wrote: > > On 28 Jan 2018, at 15:57, Andre Albsmeier = > > wrote: > > > I have a lot of machines running with 4 GB physical RAM and, for > > > some reasons, I still have to use a 32 bits OS. > > >=20 > > > All of them show something between 3 and 3.5 GB of RAM available > > > in dmesg but the brand new Supermicro A2SAV really shocked me: > > >=20 > > > FreeBSD 11.1-STABLE #0: Mon Jan 15 06:57:10 CET 2018 > > > ... > > > real memory =3D 4294967296 (4096 MB) > > > avail memory =3D 1939558400 (1849 MB) > > > ... > > >=20 > > > So do people have any ideas how I might get a bit closer to at least > > > 3 GB? I assume there are no FreeBSD knobs which might help but hope > > > dies last... > > > This is a common problem on i386. Most likely some ranges are reserved > > for I/O mappings, such as video cards. If you boot with -v, I think the > > kernel prints an overview of the physical ram chunks available? I don't > > know of any other way to get such an overview. > > > Another option is to try PAE, but I have no idea how stable that is... > > > -Dimitry > > I suspect that the unavailable RAM has been mapped above 4 GB by the BIOS. > > About PAE: at $JOB, we have a FreeBSD 8.2 system that has been running > PAE reliably since 8.2 was new. Also, we ship amd64 systems that run > mostly 32-bit binaries, which works well. But can the entire userland be 32 bit only? Maybe I'll try the PAE thing... -Andre From owner-freebsd-stable@freebsd.org Tue Jan 30 12:42:54 2018 Return-Path: Delivered-To: freebsd-stable@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 AC37BEC813B for ; Tue, 30 Jan 2018 12:42:54 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [78.47.246.247]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2DE7A6AF50 for ; Tue, 30 Jan 2018 12:42:53 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id w0UCgZfs076055 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 30 Jan 2018 13:42:36 +0100 (CET) (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: Andre.Albsmeier@siemens.com Received: from eg.sd.rdtc.ru (eugen@localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTP id w0UCgSqQ022452; Tue, 30 Jan 2018 19:42:28 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: i386 with 4GB RAM: less than 2GB available on A2SAV (Intel Atom E3940) To: Andre Albsmeier References: <20180128145703.GA80724@bali> <5A6DF168.3010902@grosbein.net> <20180130065931.GA43711@bali> Cc: freebsd-stable@freebsd.org From: Eugene Grosbein X-Enigmail-Draft-Status: N1110 Message-ID: <5A706834.8030405@grosbein.net> Date: Tue, 30 Jan 2018 19:42:28 +0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <20180130065931.GA43711@bali> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=2.2 required=5.0 tests=BAYES_00, LOCAL_FROM, RDNS_NONE, T_DATE_IN_FUTURE_96_Q autolearn=no autolearn_force=no version=3.4.1 X-Spam-Report: * 0.0 T_DATE_IN_FUTURE_96_Q Date: is 4 days to 4 months after Received: * date * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 2.6 LOCAL_FROM From my domains * 1.9 RDNS_NONE Delivered to internal network by a host with no rDNS X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on hz.grosbein.net X-Spam-Level: ** X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jan 2018 12:42:54 -0000 On 30.01.2018 13:59, Andre Albsmeier wrote: >> Also, I'd like to know reasons that made you stick to 32 bit OS >> as we have pretty good support for 32 bit applications running under 64 bit system. > > I (still) have 32 bit machines and don't want to maintain 2 userlands. > Each machine has its own kernel but userland (updated via nfs) must > remain 32 bit. > > Or is it possible to boot a 64 bit kernel and have everything else in > 32 bit? I have not tried "everything else in 32 bit", there may be some rough edges dealing with run-time linker but you can try. /sbin/init is statically linked and it should work with kernel having option COMPAT_FREEBSD32. /bin/sh may be OK too provided /libexec/ld-elf32.so.1 is in place. You should really consider switching to 64 bit kernel for such hardware. From owner-freebsd-stable@freebsd.org Tue Jan 30 13:14:49 2018 Return-Path: Delivered-To: freebsd-stable@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 C045BEC9A15 for ; Tue, 30 Jan 2018 13:14:49 +0000 (UTC) (envelope-from bsam@passap.ru) Received: from forward106o.mail.yandex.net (forward106o.mail.yandex.net [37.140.190.187]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Yandex CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 516636BF7B for ; Tue, 30 Jan 2018 13:14:48 +0000 (UTC) (envelope-from bsam@passap.ru) Received: from mxback6g.mail.yandex.net (mxback6g.mail.yandex.net [IPv6:2a02:6b8:0:1472:2741:0:8b7:167]) by forward106o.mail.yandex.net (Yandex) with ESMTP id 9D55D7843CB for ; Tue, 30 Jan 2018 16:14:40 +0300 (MSK) Received: from smtp2o.mail.yandex.net (smtp2o.mail.yandex.net [2a02:6b8:0:1a2d::26]) by mxback6g.mail.yandex.net (nwsmtp/Yandex) with ESMTP id KEFHfJhldf-Ee2WfdY3; Tue, 30 Jan 2018 16:14:40 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=passap.ru; s=mail; t=1517318080; bh=KI9uOlBHbRx7Xy3fgXxsJEa9MM664hABPJtMvRrvFg8=; h=Subject:To:References:From:Message-ID:Date:In-Reply-To; b=DOjv4PCJ9J3vE+x/39ZbYa+WhJbofFtCROrX/ITE/keGikwRsrzKsmNsXUA1MUJiO smK6Ifj4sATjcjitvHSbB/xNj09U83eocuGkfSkpGHz3OhGl6/EkQNmdBo60Sr+fnS +RC6UPwSqbtTyKfI7vQW7vYa85UKI1hwgmwQbO8I= Received: by smtp2o.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id Mse51k6fy7-Ed2S3OaW; Tue, 30 Jan 2018 16:14:39 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client certificate not present) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=passap.ru; s=mail; t=1517318079; bh=KI9uOlBHbRx7Xy3fgXxsJEa9MM664hABPJtMvRrvFg8=; h=Subject:To:References:From:Message-ID:Date:In-Reply-To; b=kMcvHFIMvfuUIMJBipFKsj9rng8UeAhiSWBsgwrkyEjSxiT7zC4sVHdVP8cum39Eb rhawXCXs7WhVBRufGvk2NZPt52OdbHyJB/y+p7SiSd1o4qkuFBlhGFAhIJ2CEuE616 iQ/qhwFxb4BgfYQZ3+JlLNCPniOtXn9WL3mEgDdc= Authentication-Results: smtp2o.mail.yandex.net; dkim=pass header.i=@passap.ru Subject: Re: i386 with 4GB RAM: less than 2GB available on A2SAV (Intel Atom E3940) To: freebsd-stable@freebsd.org References: <20180128145703.GA80724@bali> <5A6DF168.3010902@grosbein.net> <20180130065931.GA43711@bali> From: Boris Samorodov Message-ID: <850c9f7e-be71-6f96-36a5-393d5b19f002@passap.ru> Date: Tue, 30 Jan 2018 16:14:39 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <20180130065931.GA43711@bali> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jan 2018 13:14:49 -0000 30.01.2018 09:59, Andre Albsmeier пишет: > After a BIOS upgrade, Did you try to reset BIOS to default settings? A BIOS upgrade is the right time to try this. > I found the promising option > > MAX TOLUD > > which was set to 2GB. I changed it to 3GB but nothing changed. Hm, TOLUD is Top Of Lower Usable Dram. That memory is often used for GPU (minering). I'd say that you may be interested in *decreasing* it as it is effectively memory that is not used by an OS. There may be an AUTO choice to try as well. -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-stable@freebsd.org Tue Jan 30 13:33:02 2018 Return-Path: Delivered-To: freebsd-stable@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 C2098ECA78E for ; Tue, 30 Jan 2018 13:33:02 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48B396C928 for ; Tue, 30 Jan 2018 13:33:02 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 1C0B91D1FA for ; Tue, 30 Jan 2018 13:33:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w0UDX0ua071482 for ; Tue, 30 Jan 2018 13:33:00 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w0UDX0am071481 for freebsd-stable@FreeBSD.org; Tue, 30 Jan 2018 13:33:00 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-stable@FreeBSD.org Subject: [Bug 221146] [ixgbe] Problem with second laggport Date: Tue, 30 Jan 2018 13:32:57 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.1-STABLE X-Bugzilla-Keywords: IntelNetworking, regression X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: pv@efficientip.com X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: mfc-stable11? X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jan 2018 13:33:03 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D221146 Peter Vanek changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |pv@efficientip.com --- Comment #22 from Peter Vanek --- Hello, I would like to add little piece to this as well. We can reproduce same issue with driver 3.2.12-k=20 Jan 30 12:59:18 localhost ix0: port 0xecc0-0xecdf mem 0xd9d00000-0xd9dfffff,0xd9ff8000-0xd9ffbfff irq 40 at device 0.0 numa-domai= n 0 on pci2 having lagg1 lagg1: flags=3D8843 metric 0 mtu 15= 00 =20=20=20=20=20=20=20 options=3De407b9 ether a0:36:9f:3e:57:18 inet 61.0.0.24 netmask 0xff000000 broadcast 61.255.255.255 nd6 options=3D29 media: Ethernet autoselect status: active groups: lagg laggproto failover lagghash l2,l3,l4 laggport: ix0 flags=3D5 laggport: ix1 flags=3D0<> we use simple script to reproduce this: # more a.sh #!/bin/sh while true; do ifconfig $1 down echo next $1 ifconfig $1 up #sleep 1 done # sh a.sh ix0 After about 30-50 loops, we can find ix0 interface with flag UP, but with '= no carrier' status ix0: flags=3D8843 metric 0 mtu 1500 =20=20=20=20=20=20=20 options=3D9400b8 ether a0:36:9f:3e:57:18 hwaddr a0:36:9f:3e:57:18 nd6 options=3D29 media: Ethernet autoselect status: no carrier plugged: SFP/SFP+/SFP28 10G Base-SR (LC) vendor: OEM PN: SFP-10G-SR SN: IN140317016 DATE: 2014-03-20 module temperature: 30.60 C Voltage: 3.29 Volts RX: 0.38 mW (-4.10 dBm) TX: 0.41 mW (-3.85 dBm) SFF8472 DUMP (0xA0 0..127 range): 03 04 07 10 00 00 50 FF 00 00 00 06 67 02 00 00 08 03 00 1E 4F 45 4D 20 20 20 20 20 20 20 20 20 20 20 20 20 00 00 1B 21 53 46 50 2D 31 30 47 2D 53 52 20 20 20 20 20 20 41 20 20 20 03 52 00 BA 00 3A 00 00 49 4E 31 34 30 33 31 37 30 31 36 20 20 20 20 20 31 34 30 33 32 30 20 20 68 FA 03 07 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Same result is done also when netmap is not involved; script will take ix0 = down too # ifconfig ix0 ix0: flags=3D8843 metric 0 mtu 1500 =20=20=20=20=20=20=20 options=3De407b9 ether a0:36:9f:3e:57:18 hwaddr a0:36:9f:3e:57:18 nd6 options=3D29 media: Ethernet autoselect status: no carrier FYI, we do temporary downgrade of driver to 3.1.13-k where issue is not present. If I can help with any additional testing, let me know. Best Regards, Peter --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-stable@freebsd.org Tue Jan 30 13:54:49 2018 Return-Path: Delivered-To: freebsd-stable@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 5FE2BECB9DC for ; Tue, 30 Jan 2018 13:54:49 +0000 (UTC) (envelope-from mike@karels.net) Received: from mail.karels.net (mail.karels.net [216.160.39.52]) by mx1.freebsd.org (Postfix) with ESMTP id E57B76D807 for ; Tue, 30 Jan 2018 13:54:48 +0000 (UTC) (envelope-from mike@karels.net) Received: from mail.karels.net (localhost [127.0.0.1]) by mail.karels.net (8.15.2/8.15.2) with ESMTP id w0UDsfeG062401; Tue, 30 Jan 2018 07:54:41 -0600 (CST) (envelope-from mike@karels.net) Message-Id: <201801301354.w0UDsfeG062401@mail.karels.net> To: Eugene Grosbein cc: Andre Albsmeier , freebsd-stable@freebsd.org From: Mike Karels Reply-to: mike@karels.net Subject: Re: i386 with 4GB RAM: less than 2GB available on A2SAV (Intel Atom E3940) In-reply-to: Your message of Tue, 30 Jan 2018 19:42:28 +0700. <5A706834.8030405@grosbein.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <62399.1517320481.1@mail.karels.net> Content-Transfer-Encoding: quoted-printable Date: Tue, 30 Jan 2018 07:54:41 -0600 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jan 2018 13:54:49 -0000 > On 30.01.2018 13:59, Andre Albsmeier wrote: > >> Also, I'd like to know reasons that made you stick to 32 bit OS > >> as we have pretty good support for 32 bit applications running under = 64 bit system. > > = > > I (still) have 32 bit machines and don't want to maintain 2 userlands. > > Each machine has its own kernel but userland (updated via nfs) must > > remain 32 bit. > > = > > Or is it possible to boot a 64 bit kernel and have everything else in > > 32 bit? > I have not tried "everything else in 32 bit", there may be some rough ed= ges > dealing with run-time linker but you can try. > /sbin/init is statically linked and it should work with kernel having op= tion COMPAT_FREEBSD32. > /bin/sh may be OK too provided /libexec/ld-elf32.so.1 is in place. > You should really consider switching to 64 bit kernel for such hardware. You definitely cannot run all of userland in 32-bit mode. There are many sysadin programs that have incompatible syscall interfaces, starting with mount, ifconfig, ps, route, netstat, etc (probably 50 total). Unless they were all statically linked, you would have to install the 64-bit shared libraries, moving the 32-bit libraries to /lib32 and /usr/lib32, and switching around /libexec/ld-elf*. Or, if you really want the userland to be the same, you could use a PAE kernel. Mike From owner-freebsd-stable@freebsd.org Tue Jan 30 14:09:48 2018 Return-Path: Delivered-To: freebsd-stable@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 20823ECC6E5 for ; Tue, 30 Jan 2018 14:09:48 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7CA526E06B; Tue, 30 Jan 2018 14:09:47 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-lf0-x235.google.com with SMTP id t79so15542182lfe.3; Tue, 30 Jan 2018 06:09:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=wuwaQ1H1EnycfXCkceomtW0yy5OUW5+LJ8KJPOdmVVE=; b=jL+rGZcNrwmc9HOGIRYs1bVnAf/a/ldN6jlzMfyprUpELChtk0j98tSboPqGc47Jb1 W3feYNo4SzJDXzZzINTLskRUNbp4C7W6BEU+VGJq4JTIiZh7WuWVaad8Wrl7o5WMNJWv m8JaLsdy66hUTSvTOFd2MnQ1SueR3s87/WitgIpnNGH/ViFdsBa+6QQtoqMg1WMfjrQI /YERomMHK3SHIRHC1EPL+AaZDYy7aYBT7EXQrLmzsnl8q5KNVAPkYOXFf3QTCB1y8tMb IAuIECadVyB8YBNplszzCP2AQW6rgkAsHXHspV9QOC1+891jYUihAt5VBVX+Bppa8RbD SDEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=wuwaQ1H1EnycfXCkceomtW0yy5OUW5+LJ8KJPOdmVVE=; b=f5/2FACFIqXYoLmlnS/ZAPobWm+/azfeRaJD+5dYkzksjdWBe4nz+vDuDS6LWkurBY w9lkTk42QRINxKed7ya9FMlH4DkjmoHCk3RKw+DBEOy6Pi7RHmTbTY0cv+8mu1eurhS5 7RFkaiR7UHK2kW/oGa5OECeGCBub3rD3c7c5McQ5Tww8fKnFbj9iQOfnVN2CNVZL1pjG eeAInWT55rXy7p6DCc3O5nwxLmih6zCeoEr5OxTqymB2RDbs+L/4SgfWenxFhc8rwMs+ 6GePOKYiLt096s1DnLzuITTy34jVuqG075P0Etu4hTFFuAObYIdbj+iXiSJ3PV3WB4s4 rdGw== X-Gm-Message-State: AKwxyteUIKNAQjgJb2GQ9r2jzqYYGqJAoYns1j8pW4Up4BdeVr8QtZDM bQM0mx0mqRp1CclRypByK0rHM7EptLBtP0WnvfE= X-Google-Smtp-Source: AH8x226QBr7gLDCG6I8Yu6xk8024fVEAxby5nDRNdlMmE/tZPffOUSDrxGzoFDGHskQnLh0lZsGOeClEp8kFo71D470= X-Received: by 10.46.115.9 with SMTP id o9mr4863224ljc.89.1517321385078; Tue, 30 Jan 2018 06:09:45 -0800 (PST) MIME-Version: 1.0 Sender: asomers@gmail.com Received: by 10.179.87.131 with HTTP; Tue, 30 Jan 2018 06:09:44 -0800 (PST) In-Reply-To: <20180130071123.GB43715@bali> References: <201801281632.w0SGWiui055204@mail.karels.net> <20180130071123.GB43715@bali> From: Alan Somers Date: Tue, 30 Jan 2018 07:09:44 -0700 X-Google-Sender-Auth: 5dwAOg0ewoyFBATL6IauwoevyhQ Message-ID: Subject: Re: i386 with 4GB RAM: less than 2GB available on A2SAV (Intel Atom E3940) To: Andre Albsmeier Cc: Mike Karels , FreeBSD , Dimitry Andric Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jan 2018 14:09:48 -0000 On Tue, Jan 30, 2018 at 12:11 AM, Andre Albsmeier < Andre.Albsmeier@siemens.com> wrote: > On Sun, 28-Jan-2018 at 10:32:44 -0600, Mike Karels wrote: > > > On 28 Jan 2018, at 15:57, Andre Albsmeier > = > > > wrote: > > > > I have a lot of machines running with 4 GB physical RAM and, for > > > > some reasons, I still have to use a 32 bits OS. > > > >=20 > > > > All of them show something between 3 and 3.5 GB of RAM available > > > > in dmesg but the brand new Supermicro A2SAV really shocked me: > > > >=20 > > > > FreeBSD 11.1-STABLE #0: Mon Jan 15 06:57:10 CET 2018 > > > > ... > > > > real memory =3D 4294967296 (4096 MB) > > > > avail memory =3D 1939558400 (1849 MB) > > > > ... > > > >=20 > > > > So do people have any ideas how I might get a bit closer to at least > > > > 3 GB? I assume there are no FreeBSD knobs which might help but hope > > > > dies last... > > > > > This is a common problem on i386. Most likely some ranges are reserved > > > for I/O mappings, such as video cards. If you boot with -v, I think > the > > > kernel prints an overview of the physical ram chunks available? I > don't > > > know of any other way to get such an overview. > > > > > Another option is to try PAE, but I have no idea how stable that is... > > > > > -Dimitry > > > > I suspect that the unavailable RAM has been mapped above 4 GB by the > BIOS. > > > > About PAE: at $JOB, we have a FreeBSD 8.2 system that has been running > > PAE reliably since 8.2 was new. Also, we ship amd64 systems that run > > mostly 32-bit binaries, which works well. > > But can the entire userland be 32 bit only? > Sure. I do this with jails. It's no problem to have a 32-bit jail on a 64-bit kernel. Kernel modules would be an issue, though. If you need any, you'll have to find a way for the 64-bit machines to find 64-bit kernel modules. > > Maybe I'll try the PAE thing... > From owner-freebsd-stable@freebsd.org Tue Jan 30 14:21:07 2018 Return-Path: Delivered-To: freebsd-stable@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 1A69AECCFAA for ; Tue, 30 Jan 2018 14:21:07 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8706A6E88B for ; Tue, 30 Jan 2018 14:21:06 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id w0UEKtXC018961 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 30 Jan 2018 16:20:58 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua w0UEKtXC018961 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id w0UEKtCp018960; Tue, 30 Jan 2018 16:20:55 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 30 Jan 2018 16:20:55 +0200 From: Konstantin Belousov To: Mike Karels Cc: Eugene Grosbein , freebsd-stable@freebsd.org, Andre Albsmeier Subject: Re: i386 with 4GB RAM: less than 2GB available on A2SAV (Intel Atom E3940) Message-ID: <20180130142055.GG97752@kib.kiev.ua> References: <5A706834.8030405@grosbein.net> <201801301354.w0UDsfeG062401@mail.karels.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201801301354.w0UDsfeG062401@mail.karels.net> User-Agent: Mutt/1.9.2 (2017-12-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jan 2018 14:21:07 -0000 On Tue, Jan 30, 2018 at 07:54:41AM -0600, Mike Karels wrote: > > On 30.01.2018 13:59, Andre Albsmeier wrote: > > > >> Also, I'd like to know reasons that made you stick to 32 bit OS > > >> as we have pretty good support for 32 bit applications running under 64 bit system. > > > > > > I (still) have 32 bit machines and don't want to maintain 2 userlands. > > > Each machine has its own kernel but userland (updated via nfs) must > > > remain 32 bit. > > > > > > Or is it possible to boot a 64 bit kernel and have everything else in > > > 32 bit? > > > I have not tried "everything else in 32 bit", there may be some rough edges > > dealing with run-time linker but you can try. > > > /sbin/init is statically linked and it should work with kernel having option COMPAT_FREEBSD32. > > /bin/sh may be OK too provided /libexec/ld-elf32.so.1 is in place. > > > You should really consider switching to 64 bit kernel for such hardware. > > You definitely cannot run all of userland in 32-bit mode. There are many > sysadin programs that have incompatible syscall interfaces, starting with > mount, ifconfig, ps, route, netstat, etc (probably 50 total). Unless they > were all statically linked, you would have to install the 64-bit shared > libraries, moving the 32-bit libraries to /lib32 and /usr/lib32, and > switching around /libexec/ld-elf*. ps(8) compatibility for compat32 is nearly perfect, mount (in its nmount syscall variant) also works. There is no issue with /libexec/ld-elf.so.1 being 32bit, whatever rumors whoever tried to spread. Yes, networking administrative interfaces are not functional for compat32. This precludes both ifconfig(8) and route(8) from operating. Also, firewall management tools, for all three FreeBSD firewalls, can only work with matching kernel. > > Or, if you really want the userland to be the same, you could use a PAE > kernel. > > Mike > _______________________________________________ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@freebsd.org Tue Jan 30 14:55:26 2018 Return-Path: Delivered-To: freebsd-stable@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 C96C2ECF2A8 for ; Tue, 30 Jan 2018 14:55:26 +0000 (UTC) (envelope-from jennifer.anderson@natural-web-gradation.com) Received: from vpa.prc.mefound.com (vpa.prc.mefound.com [212.237.22.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4B3D4701C2 for ; Tue, 30 Jan 2018 14:55:25 +0000 (UTC) (envelope-from jennifer.anderson@natural-web-gradation.com) Received: from WS99 (unknown [106.215.89.48]) by vpa.prc.mefound.com (Postfix) with ESMTPA id 0489145F92 for ; Tue, 30 Jan 2018 15:55:22 +0100 (CET) From: "Jennifer Anderson" To: Subject: Improve the web presence of your business Date: Tue, 30 Jan 2018 20:25:04 +0530 Message-ID: MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdOZml0s+xbjlAFkR0u1I2tSQ++YRQ== Content-Language: en-us Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jan 2018 14:55:27 -0000 Greetings, Let's work together! We are a trusted digital marketing agency for more than 10 years, our team of 200+ marketing gurus has served over 4000 clients. Our unique "Pay-for-performance" model attracts customers from all geographies of the world, and we are proud to cater to the needs of every type of business belonging to varied industries, scales, and regions. We do "Pay-For-Performance SEO" service, Pay only when we rank your keywords on Top searches. - FREE website analysis report - No monthly fee / No contractual payout - Dedicated 24*7 support - Only one time set up fee Our results 'Talk' Get your website evaluated NOW, Just reply to this email with your contact details along with your requirement and we will call you back. Thanks & Regards, Jennifer Anderson Marketing Manager Head Office: San Jose, CA 95120 Disclaimer: We are not spamming. We are using this domain for marketing. If you are interested and want to know about us, just reply to this email. If we have offended you by sending this to you by mistake, we apologize. Please reply "NO" or "Unsubscribe" to this email if not interested, so that we shall add you to our "Do Not Contact Again" list. We strictly adhere to United States Federal Laws of Anti-spamming - CAN-SPAM Act of 2003. From owner-freebsd-stable@freebsd.org Tue Jan 30 17:04:44 2018 Return-Path: Delivered-To: freebsd-stable@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 2048CED6300 for ; Tue, 30 Jan 2018 17:04:44 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BB21C76900; Tue, 30 Jan 2018 17:04:43 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id B1AE55A9F12; Tue, 30 Jan 2018 17:04:37 +0000 (UTC) Date: Tue, 30 Jan 2018 17:04:37 +0000 From: Brooks Davis To: Alan Somers Cc: Andre Albsmeier , Dimitry Andric , FreeBSD , Mike Karels Subject: Re: i386 with 4GB RAM: less than 2GB available on A2SAV (Intel Atom E3940) Message-ID: <20180130170437.GA26561@spindle.one-eyed-alien.net> References: <201801281632.w0SGWiui055204@mail.karels.net> <20180130071123.GB43715@bali> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="azLHFNyN32YCQGCU" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jan 2018 17:04:44 -0000 --azLHFNyN32YCQGCU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 30, 2018 at 07:09:44AM -0700, Alan Somers wrote: > On Tue, Jan 30, 2018 at 12:11 AM, Andre Albsmeier < > Andre.Albsmeier@siemens.com> wrote: >=20 > > On Sun, 28-Jan-2018 at 10:32:44 -0600, Mike Karels wrote: > > > > On 28 Jan 2018, at 15:57, Andre Albsmeier > > =3D > > > > wrote: > > > > > I have a lot of machines running with 4 GB physical RAM and, for > > > > > some reasons, I still have to use a 32 bits OS. > > > > >=3D20 > > > > > All of them show something between 3 and 3.5 GB of RAM available > > > > > in dmesg but the brand new Supermicro A2SAV really shocked me: > > > > >=3D20 > > > > > FreeBSD 11.1-STABLE #0: Mon Jan 15 06:57:10 CET 2018 > > > > > ... > > > > > real memory =3D3D 4294967296 (4096 MB) > > > > > avail memory =3D3D 1939558400 (1849 MB) > > > > > ... > > > > >=3D20 > > > > > So do people have any ideas how I might get a bit closer to at le= ast > > > > > 3 GB? I assume there are no FreeBSD knobs which might help but ho= pe > > > > > dies last... > > > > > > > This is a common problem on i386. Most likely some ranges are rese= rved > > > > for I/O mappings, such as video cards. If you boot with -v, I think > > the > > > > kernel prints an overview of the physical ram chunks available? I > > don't > > > > know of any other way to get such an overview. > > > > > > > Another option is to try PAE, but I have no idea how stable that is= =2E.. > > > > > > > -Dimitry > > > > > > I suspect that the unavailable RAM has been mapped above 4 GB by the > > BIOS. > > > > > > About PAE: at $JOB, we have a FreeBSD 8.2 system that has been running > > > PAE reliably since 8.2 was new. Also, we ship amd64 systems that run > > > mostly 32-bit binaries, which works well. > > > > But can the entire userland be 32 bit only? >=20 > Sure. I do this with jails. It's no problem to have a 32-bit jail on a > 64-bit kernel. Kernel modules would be an issue, though. If you need an= y, > you'll have to find a way for the 64-bit machines to find 64-bit kernel > modules. There are some deficiencies in the management space[0], but it should generally work. Where it doesn't it's a bug and usually not too hard to fix. -- Brooks [0] e.g. https://reviews.freebsd.org/D13459 --azLHFNyN32YCQGCU Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJacKWlAAoJEKzQXbSebgfAGu8H/RpfnHfm28hs9HAaA3gE1AMY q5ZoHZNmn3dwgvIAUaf+eo3jaskXQ3jJyLePj0XI58UIEPWuf7tW+mMGYiNYW3u1 BZDP7vxns6KbwJdkRqIcVR/nT9NYyCY//if05mKwKaY2Plp0fkEIgY2La/Stl9jP toNaB5jJ/1NdX9/gwc29XoSy42Bt5muhMZ45yj/h6GZdkMbb7NfyDURNQBWJO4jw h4/W8aSmfeT3JKw5ZCPw6mPUVhVth9V9qB0B6aFftPw6+K+O/r2h0dFFf4wQoXAY CbaT4TBZ4egPFnPqUHEYXfBWVPrKLgFu0l6o44bTeoUtICn9xPI3RLy6ateKAiU= =wILe -----END PGP SIGNATURE----- --azLHFNyN32YCQGCU-- From owner-freebsd-stable@freebsd.org Tue Jan 30 19:51:41 2018 Return-Path: Delivered-To: freebsd-stable@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 E5C17EDED66 for ; Tue, 30 Jan 2018 19:51:40 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [IPv6:2607:f3e0:80:80::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "smarthost.sentex.ca", Issuer "smarthost.sentex.ca" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 5B61C7E050; Tue, 30 Jan 2018 19:51:40 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (lava.sentex.ca [IPv6:2607:f3e0:0:5::11]) by smarthost2.sentex.ca (8.15.2/8.15.2) with ESMTPS id w0UJpdEc029084 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 30 Jan 2018 14:51:39 -0500 (EST) (envelope-from mike@sentex.net) Received: from [192.168.43.26] (saphire3.sentex.net [192.168.43.26]) by lava.sentex.ca (8.15.2/8.15.2) with ESMTP id w0UJpbPT010426; Tue, 30 Jan 2018 14:51:37 -0500 (EST) (envelope-from mike@sentex.net) Subject: Re: Ryzen issues on FreeBSD ? To: Don Lewis Cc: Peter Moody , Pete French , freebsd-stable@freebsd.org, Andriy Gapon References: <8e842dec-ade7-37d1-6bd8-856ea1a827ca@sentex.net> <9b769e4e-b098-b294-0bce-8bb1c42e8a59@rootautomation.com> <730eb882-1c6a-afb7-0ada-396db44fb34b@ingresso.co.uk> <8b882970-4d5d-2a96-4dac-779cab07b9ae@sentex.net> <343acf99-3e9e-093a-7390-c142396c2985@sentex.net> <3dd9a61b-511d-db2e-80ca-cbc9a4b65f92@sentex.net> <55913e41-3a8a-9a4d-6862-e09a3d0f4d55@sentex.net> From: Mike Tancsa Organization: Sentex Communications Message-ID: <5e48bbc2-e872-46bd-eece-25acbb180f77@sentex.net> Date: Tue, 30 Jan 2018 14:51:36 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.78 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jan 2018 19:51:41 -0000 On 1/28/2018 7:41 PM, Don Lewis wrote: > > My suspicion is a FreeBSD bug, probably a locking / race issue. I know > that we've had to make some tweeks to our code for AMD CPUs, like this: OK, I got back the CPUs from AMD (fast turn around!) And sadly, I am still able to hang the compile in about the same place. However, if I set hw.lower_amd64_sharedpage=0 it seems to hang in a different way. CTRL+t shows load: 0.43 cmd: python2.7 15736 [umtxn] 165.00r 14.46u 6.65s 0% 233600k make[1]: Working in: /usr/ports/net/samba47 make: Working in: /usr/ports/net/samba47 # procstat -t 15736 PID TID COMM TDNAME CPU PRI STATE WCHAN 15736 100855 python2.7 - -1 152 sleep usem 15736 100956 python2.7 - -1 124 sleep umtxn 15736 100957 python2.7 - -1 126 sleep umtxn 15736 100958 python2.7 - -1 124 sleep umtxn 15736 100959 python2.7 - -1 127 sleep umtxn 15736 100960 python2.7 - -1 126 sleep umtxn 15736 100961 python2.7 - -1 126 sleep umtxn 15736 100962 python2.7 - -1 126 sleep umtxn 15736 100963 python2.7 - -1 126 sleep umtxn 15736 100964 python2.7 - -1 127 sleep umtxn 15736 100965 python2.7 - -1 126 sleep umtxn 15736 100966 python2.7 - -1 126 sleep umtxn 15736 100967 python2.7 - -1 126 sleep umtxn # procstat -kk 15736 PID TID COMM TDNAME KSTACK 15736 100855 python2.7 - mi_switch+0xf5 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231 umtxq_sleep+0x143 do_sem2_wait+0x68a __umtx_op_sem2_wait+0x4b amd64_syscall+0xa48 fast_syscall_common+0xfc 15736 100956 python2.7 - mi_switch+0xf5 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231 umtxq_sleep+0x143 do_lock_umutex+0x885 __umtx_op_wait_umutex+0x48 amd64_syscall+0xa48 fast_syscall_common+0xfc 15736 100957 python2.7 - mi_switch+0xf5 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231 umtxq_sleep+0x143 do_lock_umutex+0x885 __umtx_op_wait_umutex+0x48 amd64_syscall+0xa48 fast_syscall_common+0xfc 15736 100958 python2.7 - mi_switch+0xf5 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231 umtxq_sleep+0x143 do_lock_umutex+0x885 __umtx_op_wait_umutex+0x48 amd64_syscall+0xa48 fast_syscall_common+0xfc 15736 100959 python2.7 - mi_switch+0xf5 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231 umtxq_sleep+0x143 do_lock_umutex+0x885 __umtx_op_wait_umutex+0x48 amd64_syscall+0xa48 fast_syscall_common+0xfc 15736 100960 python2.7 - mi_switch+0xf5 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231 umtxq_sleep+0x143 do_lock_umutex+0x885 __umtx_op_wait_umutex+0x48 amd64_syscall+0xa48 fast_syscall_common+0xfc 15736 100961 python2.7 - mi_switch+0xf5 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231 umtxq_sleep+0x143 do_lock_umutex+0x885 __umtx_op_wait_umutex+0x48 amd64_syscall+0xa48 fast_syscall_common+0xfc 15736 100962 python2.7 - mi_switch+0xf5 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231 umtxq_sleep+0x143 do_lock_umutex+0x885 __umtx_op_wait_umutex+0x48 amd64_syscall+0xa48 fast_syscall_common+0xfc 15736 100963 python2.7 - mi_switch+0xf5 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231 umtxq_sleep+0x143 do_lock_umutex+0x885 __umtx_op_wait_umutex+0x48 amd64_syscall+0xa48 fast_syscall_common+0xfc 15736 100964 python2.7 - mi_switch+0xf5 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231 umtxq_sleep+0x143 do_lock_umutex+0x885 __umtx_op_wait_umutex+0x48 amd64_syscall+0xa48 fast_syscall_common+0xfc 15736 100965 python2.7 - mi_switch+0xf5 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231 umtxq_sleep+0x143 do_lock_umutex+0x885 __umtx_op_wait_umutex+0x48 amd64_syscall+0xa48 fast_syscall_common+0xfc 15736 100966 python2.7 - mi_switch+0xf5 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231 umtxq_sleep+0x143 do_lock_umutex+0x885 __umtx_op_wait_umutex+0x48 amd64_syscall+0xa48 fast_syscall_common+0xfc 15736 100967 python2.7 - mi_switch+0xf5 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231 umtxq_sleep+0x143 do_lock_umutex+0x885 __umtx_op_wait_umutex+0x48 amd64_syscall+0xa48 fast_syscall_common+0xfc If I kill the make, reboot and just type make, it completes after the reboot. If after the reboot, I do an rm -R work, it will hang again. With the default of hw.lower_amd64_sharedpage: 1 post reboot, CTRL+T shows load: 2.73 cmd: python2.7 15703 [usem] 40.92r 12.34u 3.45s 0% 233640k make[1]: Working in: /usr/ports/net/samba47 make: Working in: /usr/ports/net/samba47 root@amdtestr12:/home/mdtancsa # procstat -kk 15703 PID TID COMM TDNAME KSTACK 15703 100824 python2.7 - mi_switch+0xf5 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231 umtxq_sleep+0x143 do_sem2_wait+0x68a __umtx_op_sem2_wait+0x4b amd64_syscall+0xa48 fast_syscall_common+0xfc 15703 100956 python2.7 - mi_switch+0xf5 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231 umtxq_sleep+0x143 do_sem2_wait+0x68a __umtx_op_sem2_wait+0x4b amd64_syscall+0xa48 fast_syscall_common+0xfc 15703 100957 python2.7 - mi_switch+0xf5 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231 umtxq_sleep+0x143 do_sem2_wait+0x68a __umtx_op_sem2_wait+0x4b amd64_syscall+0xa48 fast_syscall_common+0xfc 15703 100958 python2.7 - mi_switch+0xf5 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231 umtxq_sleep+0x143 do_sem2_wait+0x68a __umtx_op_sem2_wait+0x4b amd64_syscall+0xa48 fast_syscall_common+0xfc 15703 100959 python2.7 - mi_switch+0xf5 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231 umtxq_sleep+0x143 do_sem2_wait+0x68a __umtx_op_sem2_wait+0x4b amd64_syscall+0xa48 fast_syscall_common+0xfc 15703 100960 python2.7 - mi_switch+0xf5 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231 umtxq_sleep+0x143 do_sem2_wait+0x68a __umtx_op_sem2_wait+0x4b amd64_syscall+0xa48 fast_syscall_common+0xfc 15703 100961 python2.7 - mi_switch+0xf5 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231 umtxq_sleep+0x143 do_sem2_wait+0x68a __umtx_op_sem2_wait+0x4b amd64_syscall+0xa48 fast_syscall_common+0xfc 15703 100962 python2.7 - mi_switch+0xf5 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231 umtxq_sleep+0x143 do_sem2_wait+0x68a __umtx_op_sem2_wait+0x4b amd64_syscall+0xa48 fast_syscall_common+0xfc 15703 100963 python2.7 - mi_switch+0xf5 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231 umtxq_sleep+0x143 do_sem2_wait+0x68a __umtx_op_sem2_wait+0x4b amd64_syscall+0xa48 fast_syscall_common+0xfc 15703 100964 python2.7 - mi_switch+0xf5 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231 umtxq_sleep+0x143 do_sem2_wait+0x68a __umtx_op_sem2_wait+0x4b amd64_syscall+0xa48 fast_syscall_common+0xfc 15703 100965 python2.7 - mi_switch+0xf5 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231 umtxq_sleep+0x143 do_lock_umutex+0x885 __umtx_op_wait_umutex+0x48 amd64_syscall+0xa48 fast_syscall_common+0xfc 15703 100966 python2.7 - mi_switch+0xf5 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231 umtxq_sleep+0x143 do_sem2_wait+0x68a __umtx_op_sem2_wait+0x4b amd64_syscall+0xa48 fast_syscall_common+0xfc 15703 100967 python2.7 - mi_switch+0xf5 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231 umtxq_sleep+0x143 do_sem2_wait+0x68a __umtx_op_sem2_wait+0x4b amd64_syscall+0xa48 fast_syscall_common+0xfc root@amdtestr12:/home/mdtancsa # procstat -t 15703 PID TID COMM TDNAME CPU PRI STATE WCHAN 15703 100824 python2.7 - -1 152 sleep usem 15703 100956 python2.7 - -1 125 sleep usem 15703 100957 python2.7 - -1 127 sleep usem 15703 100958 python2.7 - -1 125 sleep usem 15703 100959 python2.7 - -1 125 sleep usem 15703 100960 python2.7 - -1 126 sleep usem 15703 100961 python2.7 - -1 126 sleep usem 15703 100962 python2.7 - -1 126 sleep usem 15703 100963 python2.7 - -1 126 sleep usem 15703 100964 python2.7 - -1 126 sleep usem 15703 100965 python2.7 - -1 126 sleep umtxn 15703 100966 python2.7 - -1 126 sleep usem 15703 100967 python2.7 - -1 125 sleep usem root@amdtestr12:/home/mdtancsa # ---Mike > > ------------------------------------------------------------------------ > r321608 | kib | 2017-07-27 01:37:07 -0700 (Thu, 27 Jul 2017) | 9 lines > > Use MFENCE to serialize RDTSC on non-Intel CPUs. > > Kernel already used the stronger barrier instruction for AMDs, correct > the userspace fast gettimeofday() implementation as well. > > > > I did go back and look at the build runaways that I've occasionally seen > on my AMD FX-8320E package builder. I haven't seen the python issue > there, but have seen gmake get stuck in a sleeping state with a bunch of > zombie offspring. > > -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada From owner-freebsd-stable@freebsd.org Tue Jan 30 21:36:17 2018 Return-Path: Delivered-To: freebsd-stable@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 1176DEE4C17 for ; Tue, 30 Jan 2018 21:36:17 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [IPv6:2607:f3e0:80:80::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "smarthost.sentex.ca", Issuer "smarthost.sentex.ca" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8F39582EB4; Tue, 30 Jan 2018 21:36:16 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (lava.sentex.ca [IPv6:2607:f3e0:0:5::11]) by smarthost2.sentex.ca (8.15.2/8.15.2) with ESMTPS id w0ULaF4t050679 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 30 Jan 2018 16:36:15 -0500 (EST) (envelope-from mike@sentex.net) Received: from [192.168.43.26] (saphire3.sentex.ca [192.168.43.26]) by lava.sentex.ca (8.15.2/8.15.2) with ESMTP id w0ULaDpJ010640; Tue, 30 Jan 2018 16:36:13 -0500 (EST) (envelope-from mike@sentex.net) Subject: Re: Ryzen issues on FreeBSD ? (with sort of workaround) From: Mike Tancsa To: Don Lewis Cc: freebsd-stable@freebsd.org, Andriy Gapon , Peter Moody , Pete French References: <8e842dec-ade7-37d1-6bd8-856ea1a827ca@sentex.net> <9b769e4e-b098-b294-0bce-8bb1c42e8a59@rootautomation.com> <730eb882-1c6a-afb7-0ada-396db44fb34b@ingresso.co.uk> <8b882970-4d5d-2a96-4dac-779cab07b9ae@sentex.net> <343acf99-3e9e-093a-7390-c142396c2985@sentex.net> <3dd9a61b-511d-db2e-80ca-cbc9a4b65f92@sentex.net> <55913e41-3a8a-9a4d-6862-e09a3d0f4d55@sentex.net> <5e48bbc2-e872-46bd-eece-25acbb180f77@sentex.net> Organization: Sentex Communications Message-ID: Date: Tue, 30 Jan 2018 16:36:12 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <5e48bbc2-e872-46bd-eece-25acbb180f77@sentex.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.78 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jan 2018 21:36:17 -0000 On 1/30/2018 2:51 PM, Mike Tancsa wrote: > > And sadly, I am still able to hang the compile in about the same place. > However, if I set OK, here is a sort of work around. If I have the box a little more busy, I can avoid whatever deadlock is going on. In another console I have cat /dev/urandom | sha256 running while the build runs ... and I can compile net/samba47 from scratch without the compile hanging. This problem also happens on HEAD from today. Should I start a new thread on freebsd-current ? Or just file a bug report ? The compile worked 4/4 ---Mike > > hw.lower_amd64_sharedpage=0 > > it seems to hang in a different way. CTRL+t shows > > load: 0.43 cmd: python2.7 15736 [umtxn] 165.00r 14.46u 6.65s 0% 233600k > make[1]: Working in: /usr/ports/net/samba47 > make: Working in: /usr/ports/net/samba47 > > > # procstat -t 15736 > PID TID COMM TDNAME CPU PRI STATE > WCHAN > 15736 100855 python2.7 - -1 152 sleep > usem > 15736 100956 python2.7 - -1 124 sleep > umtxn > 15736 100957 python2.7 - -1 126 sleep > umtxn > 15736 100958 python2.7 - -1 124 sleep > umtxn > 15736 100959 python2.7 - -1 127 sleep > umtxn > 15736 100960 python2.7 - -1 126 sleep > umtxn > 15736 100961 python2.7 - -1 126 sleep > umtxn > 15736 100962 python2.7 - -1 126 sleep > umtxn > 15736 100963 python2.7 - -1 126 sleep > umtxn > 15736 100964 python2.7 - -1 127 sleep > umtxn > 15736 100965 python2.7 - -1 126 sleep > umtxn > 15736 100966 python2.7 - -1 126 sleep > umtxn > 15736 100967 python2.7 - -1 126 sleep > umtxn > > # procstat -kk 15736 > PID TID COMM TDNAME KSTACK > > 15736 100855 python2.7 - mi_switch+0xf5 > sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231 > umtxq_sleep+0x143 do_sem2_wait+0x68a __umtx_op_sem2_wait+0x4b > amd64_syscall+0xa48 fast_syscall_common+0xfc > 15736 100956 python2.7 - mi_switch+0xf5 > sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231 > umtxq_sleep+0x143 do_lock_umutex+0x885 __umtx_op_wait_umutex+0x48 > amd64_syscall+0xa48 fast_syscall_common+0xfc > 15736 100957 python2.7 - mi_switch+0xf5 > sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231 > umtxq_sleep+0x143 do_lock_umutex+0x885 __umtx_op_wait_umutex+0x48 > amd64_syscall+0xa48 fast_syscall_common+0xfc > 15736 100958 python2.7 - mi_switch+0xf5 > sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231 > umtxq_sleep+0x143 do_lock_umutex+0x885 __umtx_op_wait_umutex+0x48 > amd64_syscall+0xa48 fast_syscall_common+0xfc > 15736 100959 python2.7 - mi_switch+0xf5 > sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231 > umtxq_sleep+0x143 do_lock_umutex+0x885 __umtx_op_wait_umutex+0x48 > amd64_syscall+0xa48 fast_syscall_common+0xfc > 15736 100960 python2.7 - mi_switch+0xf5 > sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231 > umtxq_sleep+0x143 do_lock_umutex+0x885 __umtx_op_wait_umutex+0x48 > amd64_syscall+0xa48 fast_syscall_common+0xfc > 15736 100961 python2.7 - mi_switch+0xf5 > sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231 > umtxq_sleep+0x143 do_lock_umutex+0x885 __umtx_op_wait_umutex+0x48 > amd64_syscall+0xa48 fast_syscall_common+0xfc > 15736 100962 python2.7 - mi_switch+0xf5 > sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231 > umtxq_sleep+0x143 do_lock_umutex+0x885 __umtx_op_wait_umutex+0x48 > amd64_syscall+0xa48 fast_syscall_common+0xfc > 15736 100963 python2.7 - mi_switch+0xf5 > sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231 > umtxq_sleep+0x143 do_lock_umutex+0x885 __umtx_op_wait_umutex+0x48 > amd64_syscall+0xa48 fast_syscall_common+0xfc > 15736 100964 python2.7 - mi_switch+0xf5 > sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231 > umtxq_sleep+0x143 do_lock_umutex+0x885 __umtx_op_wait_umutex+0x48 > amd64_syscall+0xa48 fast_syscall_common+0xfc > 15736 100965 python2.7 - mi_switch+0xf5 > sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231 > umtxq_sleep+0x143 do_lock_umutex+0x885 __umtx_op_wait_umutex+0x48 > amd64_syscall+0xa48 fast_syscall_common+0xfc > 15736 100966 python2.7 - mi_switch+0xf5 > sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231 > umtxq_sleep+0x143 do_lock_umutex+0x885 __umtx_op_wait_umutex+0x48 > amd64_syscall+0xa48 fast_syscall_common+0xfc > 15736 100967 python2.7 - mi_switch+0xf5 > sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231 > umtxq_sleep+0x143 do_lock_umutex+0x885 __umtx_op_wait_umutex+0x48 > amd64_syscall+0xa48 fast_syscall_common+0xfc > > If I kill the make, reboot and just type make, it completes after the > reboot. If after the reboot, I do an rm -R work, it will hang again. > With the default of > hw.lower_amd64_sharedpage: 1 > post reboot, > > CTRL+T shows > load: 2.73 cmd: python2.7 15703 [usem] 40.92r 12.34u 3.45s 0% 233640k > make[1]: Working in: /usr/ports/net/samba47 > make: Working in: /usr/ports/net/samba47 > > > > root@amdtestr12:/home/mdtancsa # procstat -kk 15703 > PID TID COMM TDNAME KSTACK > > 15703 100824 python2.7 - mi_switch+0xf5 > sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231 > umtxq_sleep+0x143 do_sem2_wait+0x68a __umtx_op_sem2_wait+0x4b > amd64_syscall+0xa48 fast_syscall_common+0xfc > 15703 100956 python2.7 - mi_switch+0xf5 > sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231 > umtxq_sleep+0x143 do_sem2_wait+0x68a __umtx_op_sem2_wait+0x4b > amd64_syscall+0xa48 fast_syscall_common+0xfc > 15703 100957 python2.7 - mi_switch+0xf5 > sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231 > umtxq_sleep+0x143 do_sem2_wait+0x68a __umtx_op_sem2_wait+0x4b > amd64_syscall+0xa48 fast_syscall_common+0xfc > 15703 100958 python2.7 - mi_switch+0xf5 > sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231 > umtxq_sleep+0x143 do_sem2_wait+0x68a __umtx_op_sem2_wait+0x4b > amd64_syscall+0xa48 fast_syscall_common+0xfc > 15703 100959 python2.7 - mi_switch+0xf5 > sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231 > umtxq_sleep+0x143 do_sem2_wait+0x68a __umtx_op_sem2_wait+0x4b > amd64_syscall+0xa48 fast_syscall_common+0xfc > 15703 100960 python2.7 - mi_switch+0xf5 > sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231 > umtxq_sleep+0x143 do_sem2_wait+0x68a __umtx_op_sem2_wait+0x4b > amd64_syscall+0xa48 fast_syscall_common+0xfc > 15703 100961 python2.7 - mi_switch+0xf5 > sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231 > umtxq_sleep+0x143 do_sem2_wait+0x68a __umtx_op_sem2_wait+0x4b > amd64_syscall+0xa48 fast_syscall_common+0xfc > 15703 100962 python2.7 - mi_switch+0xf5 > sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231 > umtxq_sleep+0x143 do_sem2_wait+0x68a __umtx_op_sem2_wait+0x4b > amd64_syscall+0xa48 fast_syscall_common+0xfc > 15703 100963 python2.7 - mi_switch+0xf5 > sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231 > umtxq_sleep+0x143 do_sem2_wait+0x68a __umtx_op_sem2_wait+0x4b > amd64_syscall+0xa48 fast_syscall_common+0xfc > 15703 100964 python2.7 - mi_switch+0xf5 > sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231 > umtxq_sleep+0x143 do_sem2_wait+0x68a __umtx_op_sem2_wait+0x4b > amd64_syscall+0xa48 fast_syscall_common+0xfc > 15703 100965 python2.7 - mi_switch+0xf5 > sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231 > umtxq_sleep+0x143 do_lock_umutex+0x885 __umtx_op_wait_umutex+0x48 > amd64_syscall+0xa48 fast_syscall_common+0xfc > 15703 100966 python2.7 - mi_switch+0xf5 > sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231 > umtxq_sleep+0x143 do_sem2_wait+0x68a __umtx_op_sem2_wait+0x4b > amd64_syscall+0xa48 fast_syscall_common+0xfc > 15703 100967 python2.7 - mi_switch+0xf5 > sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231 > umtxq_sleep+0x143 do_sem2_wait+0x68a __umtx_op_sem2_wait+0x4b > amd64_syscall+0xa48 fast_syscall_common+0xfc > root@amdtestr12:/home/mdtancsa # procstat -t 15703 > PID TID COMM TDNAME CPU PRI STATE > WCHAN > 15703 100824 python2.7 - -1 152 sleep > usem > 15703 100956 python2.7 - -1 125 sleep > usem > 15703 100957 python2.7 - -1 127 sleep > usem > 15703 100958 python2.7 - -1 125 sleep > usem > 15703 100959 python2.7 - -1 125 sleep > usem > 15703 100960 python2.7 - -1 126 sleep > usem > 15703 100961 python2.7 - -1 126 sleep > usem > 15703 100962 python2.7 - -1 126 sleep > usem > 15703 100963 python2.7 - -1 126 sleep > usem > 15703 100964 python2.7 - -1 126 sleep > usem > 15703 100965 python2.7 - -1 126 sleep > umtxn > 15703 100966 python2.7 - -1 126 sleep > usem > 15703 100967 python2.7 - -1 125 sleep > usem > root@amdtestr12:/home/mdtancsa # > > > ---Mike > > >> >> ------------------------------------------------------------------------ >> r321608 | kib | 2017-07-27 01:37:07 -0700 (Thu, 27 Jul 2017) | 9 lines >> >> Use MFENCE to serialize RDTSC on non-Intel CPUs. >> >> Kernel already used the stronger barrier instruction for AMDs, correct >> the userspace fast gettimeofday() implementation as well. >> >> >> >> I did go back and look at the build runaways that I've occasionally seen >> on my AMD FX-8320E package builder. I haven't seen the python issue >> there, but have seen gmake get stuck in a sleeping state with a bunch of >> zombie offspring. >> >> > > -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada From owner-freebsd-stable@freebsd.org Tue Jan 30 22:24:05 2018 Return-Path: Delivered-To: freebsd-stable@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 D6C15EC2FBB for ; Tue, 30 Jan 2018 22:24:04 +0000 (UTC) (envelope-from nimrod@nimrod.is-a-geek.net) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6F07285162 for ; Tue, 30 Jan 2018 22:24:04 +0000 (UTC) (envelope-from nimrod@nimrod.is-a-geek.net) Received: by mail-yw0-x22f.google.com with SMTP id u17so6007571ywg.9 for ; Tue, 30 Jan 2018 14:24:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Lg9t26lKv23kPUykXIW0ZPGpDdjm2j0QhJ4XWpVG2LA=; b=A52fJxi1cbKiUr/L0y0Ctv5L57hIWaBM6b6reDPJMIJPZ8/dBe5PIWYhJXH6+Qz68t 7AgktldY79WHs0idBj+F8+VAFikKPwReuz/8ONz1pjhMpEnCUP7YlH1z0XhOcbu5RJR7 SNYBnrvTYBgX8UZXh4cBCi8OQydqB6FHK+jA+WFZT4dKJJ+ZbmiQGbkiFPxYVfUPKkS0 wnb/I0Y6PLILMe1XFuCKWegoHQRzN69PpnJ/4jNrw03pvkWIEv52WafPrBA9uBEMuLCe zefNw+AiZK/KmB+FFiqEK66lRO0SrXexkZLAcODjJPhUDcPqbgEEZxUX3qaOOkyT52vM P7ew== 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=Lg9t26lKv23kPUykXIW0ZPGpDdjm2j0QhJ4XWpVG2LA=; b=iATFoscc6H7kEypSIGTQba2uYDQW1zRA6ixb+ANd5mlA1KZTZ6oTBNwC5nu5t+xUvq IhF99zRBCpH5OLV9LU67AL5S1C3Y9yV9w+mLBsg5elvps65wpJtZmWUyQcobb2qoh6qn QyZ4cV+3DLNnGuW7xPCTkSSy4xJIPjI76tA6JA5nQJQns+g6yy5Xw1FHqZZ/oxWGrND0 f+HckRVfJ22ZALnw2FRfQir7t0zoWvvfqoRwCspjm5ua3x851DYefNk2lju9hHMhsRTZ PEWs8sOviptaUiXlPZo2jigYyD5GYfrUDBEJnC0411vwV4/YaHXt6pTHKVATYwb8bHsK eaRQ== X-Gm-Message-State: AKwxytfjvbeFOHhU+RWwjcwIMtiB9oFTkORJcNofPJR76lTepbW582Ik cdkap+pyxg7M9DXCFV48DguvtgkUbXfgyONPll7TEg== X-Google-Smtp-Source: AH8x226EnW3IdrNum+Pnub8qVfhjd0DNIX01qjPW8KKgQ8J541KtOt7CFMOcCeqWwZTc62tuwHQD+uYBLy8XYUyXdCw= X-Received: by 10.37.9.5 with SMTP id 5mr21836710ybj.101.1517351043290; Tue, 30 Jan 2018 14:24:03 -0800 (PST) MIME-Version: 1.0 References: <8e842dec-ade7-37d1-6bd8-856ea1a827ca@sentex.net> <9b769e4e-b098-b294-0bce-8bb1c42e8a59@rootautomation.com> <730eb882-1c6a-afb7-0ada-396db44fb34b@ingresso.co.uk> <8b882970-4d5d-2a96-4dac-779cab07b9ae@sentex.net> <343acf99-3e9e-093a-7390-c142396c2985@sentex.net> <3dd9a61b-511d-db2e-80ca-cbc9a4b65f92@sentex.net> <55913e41-3a8a-9a4d-6862-e09a3d0f4d55@sentex.net> <5e48bbc2-e872-46bd-eece-25acbb180f77@sentex.net> In-Reply-To: From: Nimrod Levy Date: Tue, 30 Jan 2018 22:23:52 +0000 Message-ID: Subject: Re: Ryzen issues on FreeBSD ? (with sort of workaround) To: Mike Tancsa Cc: Don Lewis , freebsd-stable@freebsd.org, Peter Moody , Andriy Gapon , Pete French Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jan 2018 22:24:05 -0000 That's really strange. I never saw those kinds of deadlocks, but I did notice that if I kept the cpu busy using distributed.net I could keep the full system lockups away for at least a week if not longer. Not to keep harping on it, but what worked for me was lowering the memory speed. I'm at 11 days of uptime so far without anything running the cpu. Before the change it would lock up anywhere from an hour to a day. On Tue, Jan 30, 2018 at 4:39 PM Mike Tancsa wrote: > On 1/30/2018 2:51 PM, Mike Tancsa wrote: > > > > And sadly, I am still able to hang the compile in about the same place. > > However, if I set > > > OK, here is a sort of work around. If I have the box a little more busy, > I can avoid whatever deadlock is going on. In another console I have > cat /dev/urandom | sha256 > running while the build runs > > ... and I can compile net/samba47 from scratch without the compile > hanging. This problem also happens on HEAD from today. Should I start > a new thread on freebsd-current ? Or just file a bug report ? > The compile worked 4/4 > > ---Mike > > > > > > > > > > > > > > hw.lower_amd64_sharedpage=0 > > > > it seems to hang in a different way. CTRL+t shows > > > > load: 0.43 cmd: python2.7 15736 [umtxn] 165.00r 14.46u 6.65s 0% 233600k > > make[1]: Working in: /usr/ports/net/samba47 > > make: Working in: /usr/ports/net/samba47 > > > > > > # procstat -t 15736 > > PID TID COMM TDNAME CPU PRI STATE > > WCHAN > > 15736 100855 python2.7 - -1 152 sleep > > usem > > 15736 100956 python2.7 - -1 124 sleep > > umtxn > > 15736 100957 python2.7 - -1 126 sleep > > umtxn > > 15736 100958 python2.7 - -1 124 sleep > > umtxn > > 15736 100959 python2.7 - -1 127 sleep > > umtxn > > 15736 100960 python2.7 - -1 126 sleep > > umtxn > > 15736 100961 python2.7 - -1 126 sleep > > umtxn > > 15736 100962 python2.7 - -1 126 sleep > > umtxn > > 15736 100963 python2.7 - -1 126 sleep > > umtxn > > 15736 100964 python2.7 - -1 127 sleep > > umtxn > > 15736 100965 python2.7 - -1 126 sleep > > umtxn > > 15736 100966 python2.7 - -1 126 sleep > > umtxn > > 15736 100967 python2.7 - -1 126 sleep > > umtxn > > > > # procstat -kk 15736 > > PID TID COMM TDNAME KSTACK > > > > 15736 100855 python2.7 - mi_switch+0xf5 > > sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231 > > umtxq_sleep+0x143 do_sem2_wait+0x68a __umtx_op_sem2_wait+0x4b > > amd64_syscall+0xa48 fast_syscall_common+0xfc > > 15736 100956 python2.7 - mi_switch+0xf5 > > sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231 > > umtxq_sleep+0x143 do_lock_umutex+0x885 __umtx_op_wait_umutex+0x48 > > amd64_syscall+0xa48 fast_syscall_common+0xfc > > 15736 100957 python2.7 - mi_switch+0xf5 > > sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231 > > umtxq_sleep+0x143 do_lock_umutex+0x885 __umtx_op_wait_umutex+0x48 > > amd64_syscall+0xa48 fast_syscall_common+0xfc > > 15736 100958 python2.7 - mi_switch+0xf5 > > sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231 > > umtxq_sleep+0x143 do_lock_umutex+0x885 __umtx_op_wait_umutex+0x48 > > amd64_syscall+0xa48 fast_syscall_common+0xfc > > 15736 100959 python2.7 - mi_switch+0xf5 > > sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231 > > umtxq_sleep+0x143 do_lock_umutex+0x885 __umtx_op_wait_umutex+0x48 > > amd64_syscall+0xa48 fast_syscall_common+0xfc > > 15736 100960 python2.7 - mi_switch+0xf5 > > sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231 > > umtxq_sleep+0x143 do_lock_umutex+0x885 __umtx_op_wait_umutex+0x48 > > amd64_syscall+0xa48 fast_syscall_common+0xfc > > 15736 100961 python2.7 - mi_switch+0xf5 > > sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231 > > umtxq_sleep+0x143 do_lock_umutex+0x885 __umtx_op_wait_umutex+0x48 > > amd64_syscall+0xa48 fast_syscall_common+0xfc > > 15736 100962 python2.7 - mi_switch+0xf5 > > sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231 > > umtxq_sleep+0x143 do_lock_umutex+0x885 __umtx_op_wait_umutex+0x48 > > amd64_syscall+0xa48 fast_syscall_common+0xfc > > 15736 100963 python2.7 - mi_switch+0xf5 > > sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231 > > umtxq_sleep+0x143 do_lock_umutex+0x885 __umtx_op_wait_umutex+0x48 > > amd64_syscall+0xa48 fast_syscall_common+0xfc > > 15736 100964 python2.7 - mi_switch+0xf5 > > sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231 > > umtxq_sleep+0x143 do_lock_umutex+0x885 __umtx_op_wait_umutex+0x48 > > amd64_syscall+0xa48 fast_syscall_common+0xfc > > 15736 100965 python2.7 - mi_switch+0xf5 > > sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231 > > umtxq_sleep+0x143 do_lock_umutex+0x885 __umtx_op_wait_umutex+0x48 > > amd64_syscall+0xa48 fast_syscall_common+0xfc > > 15736 100966 python2.7 - mi_switch+0xf5 > > sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231 > > umtxq_sleep+0x143 do_lock_umutex+0x885 __umtx_op_wait_umutex+0x48 > > amd64_syscall+0xa48 fast_syscall_common+0xfc > > 15736 100967 python2.7 - mi_switch+0xf5 > > sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231 > > umtxq_sleep+0x143 do_lock_umutex+0x885 __umtx_op_wait_umutex+0x48 > > amd64_syscall+0xa48 fast_syscall_common+0xfc > > > > If I kill the make, reboot and just type make, it completes after the > > reboot. If after the reboot, I do an rm -R work, it will hang again. > > With the default of > > hw.lower_amd64_sharedpage: 1 > > post reboot, > > > > CTRL+T shows > > load: 2.73 cmd: python2.7 15703 [usem] 40.92r 12.34u 3.45s 0% 233640k > > make[1]: Working in: /usr/ports/net/samba47 > > make: Working in: /usr/ports/net/samba47 > > > > > > > > root@amdtestr12:/home/mdtancsa # procstat -kk 15703 > > PID TID COMM TDNAME KSTACK > > > > 15703 100824 python2.7 - mi_switch+0xf5 > > sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231 > > umtxq_sleep+0x143 do_sem2_wait+0x68a __umtx_op_sem2_wait+0x4b > > amd64_syscall+0xa48 fast_syscall_common+0xfc > > 15703 100956 python2.7 - mi_switch+0xf5 > > sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231 > > umtxq_sleep+0x143 do_sem2_wait+0x68a __umtx_op_sem2_wait+0x4b > > amd64_syscall+0xa48 fast_syscall_common+0xfc > > 15703 100957 python2.7 - mi_switch+0xf5 > > sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231 > > umtxq_sleep+0x143 do_sem2_wait+0x68a __umtx_op_sem2_wait+0x4b > > amd64_syscall+0xa48 fast_syscall_common+0xfc > > 15703 100958 python2.7 - mi_switch+0xf5 > > sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231 > > umtxq_sleep+0x143 do_sem2_wait+0x68a __umtx_op_sem2_wait+0x4b > > amd64_syscall+0xa48 fast_syscall_common+0xfc > > 15703 100959 python2.7 - mi_switch+0xf5 > > sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231 > > umtxq_sleep+0x143 do_sem2_wait+0x68a __umtx_op_sem2_wait+0x4b > > amd64_syscall+0xa48 fast_syscall_common+0xfc > > 15703 100960 python2.7 - mi_switch+0xf5 > > sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231 > > umtxq_sleep+0x143 do_sem2_wait+0x68a __umtx_op_sem2_wait+0x4b > > amd64_syscall+0xa48 fast_syscall_common+0xfc > > 15703 100961 python2.7 - mi_switch+0xf5 > > sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231 > > umtxq_sleep+0x143 do_sem2_wait+0x68a __umtx_op_sem2_wait+0x4b > > amd64_syscall+0xa48 fast_syscall_common+0xfc > > 15703 100962 python2.7 - mi_switch+0xf5 > > sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231 > > umtxq_sleep+0x143 do_sem2_wait+0x68a __umtx_op_sem2_wait+0x4b > > amd64_syscall+0xa48 fast_syscall_common+0xfc > > 15703 100963 python2.7 - mi_switch+0xf5 > > sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231 > > umtxq_sleep+0x143 do_sem2_wait+0x68a __umtx_op_sem2_wait+0x4b > > amd64_syscall+0xa48 fast_syscall_common+0xfc > > 15703 100964 python2.7 - mi_switch+0xf5 > > sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231 > > umtxq_sleep+0x143 do_sem2_wait+0x68a __umtx_op_sem2_wait+0x4b > > amd64_syscall+0xa48 fast_syscall_common+0xfc > > 15703 100965 python2.7 - mi_switch+0xf5 > > sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231 > > umtxq_sleep+0x143 do_lock_umutex+0x885 __umtx_op_wait_umutex+0x48 > > amd64_syscall+0xa48 fast_syscall_common+0xfc > > 15703 100966 python2.7 - mi_switch+0xf5 > > sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231 > > umtxq_sleep+0x143 do_sem2_wait+0x68a __umtx_op_sem2_wait+0x4b > > amd64_syscall+0xa48 fast_syscall_common+0xfc > > 15703 100967 python2.7 - mi_switch+0xf5 > > sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x231 > > umtxq_sleep+0x143 do_sem2_wait+0x68a __umtx_op_sem2_wait+0x4b > > amd64_syscall+0xa48 fast_syscall_common+0xfc > > root@amdtestr12:/home/mdtancsa # procstat -t 15703 > > PID TID COMM TDNAME CPU PRI STATE > > WCHAN > > 15703 100824 python2.7 - -1 152 sleep > > usem > > 15703 100956 python2.7 - -1 125 sleep > > usem > > 15703 100957 python2.7 - -1 127 sleep > > usem > > 15703 100958 python2.7 - -1 125 sleep > > usem > > 15703 100959 python2.7 - -1 125 sleep > > usem > > 15703 100960 python2.7 - -1 126 sleep > > usem > > 15703 100961 python2.7 - -1 126 sleep > > usem > > 15703 100962 python2.7 - -1 126 sleep > > usem > > 15703 100963 python2.7 - -1 126 sleep > > usem > > 15703 100964 python2.7 - -1 126 sleep > > usem > > 15703 100965 python2.7 - -1 126 sleep > > umtxn > > 15703 100966 python2.7 - -1 126 sleep > > usem > > 15703 100967 python2.7 - -1 125 sleep > > usem > > root@amdtestr12:/home/mdtancsa # > > > > > > ---Mike > > > > > >> > >> ------------------------------------------------------------------------ > >> r321608 | kib | 2017-07-27 01:37:07 -0700 (Thu, 27 Jul 2017) | 9 lines > >> > >> Use MFENCE to serialize RDTSC on non-Intel CPUs. > >> > >> Kernel already used the stronger barrier instruction for AMDs, correct > >> the userspace fast gettimeofday() implementation as well. > >> > >> > >> > >> I did go back and look at the build runaways that I've occasionally seen > >> on my AMD FX-8320E package builder. I haven't seen the python issue > >> there, but have seen gmake get stuck in a sleeping state with a bunch of > >> zombie offspring. > >> > >> > > > > > > > -- > ------------------- > Mike Tancsa, tel +1 519 651 3400 <(519)%20651-3400> > Sentex Communications, mike@sentex.net > Providing Internet services since 1994 www.sentex.net > Cambridge, Ontario Canada > _______________________________________________ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > -- -- Nimrod From owner-freebsd-stable@freebsd.org Wed Jan 31 00:37:28 2018 Return-Path: Delivered-To: freebsd-stable@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 A767AECC496 for ; Wed, 31 Jan 2018 00:37:28 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from mx2.catspoiler.org (mx2.catspoiler.org [IPv6:2607:f740:16::d18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "amnesiac", Issuer "amnesiac" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 43FDC6A0BA; Wed, 31 Jan 2018 00:37:28 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org ([76.212.85.177]) by mx2.catspoiler.org (8.15.2/8.15.2) with ESMTPS id w0V0bviu021864 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 31 Jan 2018 00:37:59 GMT (envelope-from truckman@FreeBSD.org) Received: from mousie.catspoiler.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.15.2/8.15.2) with ESMTPS id w0V0ReuQ007979 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Jan 2018 16:37:20 -0800 (PST) (envelope-from truckman@FreeBSD.org) Date: Tue, 30 Jan 2018 16:37:19 -0800 (PST) From: Don Lewis Subject: Re: Ryzen issues on FreeBSD ? (with sort of workaround) To: Mike Tancsa cc: freebsd-stable@freebsd.org, Andriy Gapon , Peter Moody , Pete French In-Reply-To: Message-ID: References: <8e842dec-ade7-37d1-6bd8-856ea1a827ca@sentex.net> <9b769e4e-b098-b294-0bce-8bb1c42e8a59@rootautomation.com> <730eb882-1c6a-afb7-0ada-396db44fb34b@ingresso.co.uk> <8b882970-4d5d-2a96-4dac-779cab07b9ae@sentex.net> <343acf99-3e9e-093a-7390-c142396c2985@sentex.net> <3dd9a61b-511d-db2e-80ca-cbc9a4b65f92@sentex.net> <55913e41-3a8a-9a4d-6862-e09a3d0f4d55@sentex.net> <5e48bbc2-e872-46bd-eece-25acbb180f77@sentex.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=us-ascii Content-Disposition: INLINE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jan 2018 00:37:28 -0000 On 30 Jan, Mike Tancsa wrote: > On 1/30/2018 2:51 PM, Mike Tancsa wrote: >> >> And sadly, I am still able to hang the compile in about the same place. >> However, if I set > > > OK, here is a sort of work around. If I have the box a little more busy, > I can avoid whatever deadlock is going on. In another console I have > cat /dev/urandom | sha256 > running while the build runs Interesting ... > ... and I can compile net/samba47 from scratch without the compile > hanging. This problem also happens on HEAD from today. Should I start > a new thread on freebsd-current ? Or just file a bug report ? > The compile worked 4/4 I'd file a PR to capture all the information in one place and drop a pointer on freebsd-current. From owner-freebsd-stable@freebsd.org Wed Jan 31 00:48:32 2018 Return-Path: Delivered-To: freebsd-stable@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 8C144ECD179 for ; Wed, 31 Jan 2018 00:48:32 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [IPv6:2607:f3e0:80:80::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "smarthost.sentex.ca", Issuer "smarthost.sentex.ca" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 13B306A79D; Wed, 31 Jan 2018 00:48:32 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (lava.sentex.ca [IPv6:2607:f3e0:0:5::11]) by smarthost2.sentex.ca (8.15.2/8.15.2) with ESMTPS id w0V0mV3e082242 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 30 Jan 2018 19:48:31 -0500 (EST) (envelope-from mike@sentex.net) Received: from [192.168.43.26] (saphire3.sentex.ca [192.168.43.26]) by lava.sentex.ca (8.15.2/8.15.2) with ESMTP id w0V0mSPX011020; Tue, 30 Jan 2018 19:48:28 -0500 (EST) (envelope-from mike@sentex.net) Subject: Re: Ryzen issues on FreeBSD ? (with sort of workaround) To: Nimrod Levy Cc: Don Lewis , freebsd-stable@freebsd.org, Peter Moody , Andriy Gapon , Pete French References: <8e842dec-ade7-37d1-6bd8-856ea1a827ca@sentex.net> <730eb882-1c6a-afb7-0ada-396db44fb34b@ingresso.co.uk> <8b882970-4d5d-2a96-4dac-779cab07b9ae@sentex.net> <343acf99-3e9e-093a-7390-c142396c2985@sentex.net> <3dd9a61b-511d-db2e-80ca-cbc9a4b65f92@sentex.net> <55913e41-3a8a-9a4d-6862-e09a3d0f4d55@sentex.net> <5e48bbc2-e872-46bd-eece-25acbb180f77@sentex.net> From: Mike Tancsa Organization: Sentex Communications Message-ID: Date: Tue, 30 Jan 2018 19:48:30 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.78 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jan 2018 00:48:32 -0000 On 1/30/2018 5:23 PM, Nimrod Levy wrote: > That's really strange. I never saw those kinds of deadlocks, but I did > notice that if I kept the cpu busy using distributed.net > I could keep the full system lockups away for > at least a week if not longer. > > Not to keep harping on it, but what worked for me was lowering the > memory speed. I'm at 11 days of uptime so far without anything running > the cpu. Before the change it would lock up anywhere from an hour to a day. > Spoke too soon. After a dozen loops, the process has hung again. Note, this is not the box locking up, just the compile. I do have memory at a lower speed too. -- 2133 instead of the default 2400 I also just tried upgrading to the latest HEAD with a generic kernel and same / similar lockups although procstat -kk gives some odd results root@amdtestr12:/home/mdtancsa # procstat -kk 6067 PID TID COMM TDNAME KSTACK 6067 100865 python2.7 - ??+0 ??+0 ??+0 ??+0 ??+0 ??+0 ??+0 ??+0 ??+0 ??+0 6067 100900 python2.7 - ??+0 ??+0 ??+0 ??+0 ??+0 ??+0 ??+0 ??+0 ??+0 ??+0 6067 100901 python2.7 - ??+0 ??+0 ??+0 ??+0 ??+0 ??+0 ??+0 ??+0 ??+0 ??+0 6067 100902 python2.7 - ??+0 ??+0 ??+0 ??+0 ??+0 ??+0 ??+0 ??+0 ??+0 ??+0 6067 100903 python2.7 - ??+0 ??+0 ??+0 ??+0 ??+0 ??+0 ??+0 ??+0 ??+0 ??+0 6067 100904 python2.7 - ??+0 ??+0 ??+0 ??+0 ??+0 ??+0 ??+0 ??+0 ??+0 ??+0 6067 100905 python2.7 - ??+0 ??+0 ??+0 ??+0 ??+0 ??+0 ??+0 ??+0 ??+0 ??+0 6067 100906 python2.7 - ??+0 ??+0 ??+0 ??+0 ??+0 ??+0 ??+0 ??+0 ??+0 ??+0 6067 100907 python2.7 - ??+0 ??+0 ??+0 ??+0 ??+0 ??+0 ??+0 ??+0 ??+0 ??+0 6067 100908 python2.7 - ??+0 ??+0 ??+0 ??+0 ??+0 ??+0 ??+0 ??+0 ??+0 ??+0 6067 100909 python2.7 - ??+0 ??+0 ??+0 ??+0 ??+0 ??+0 ??+0 ??+0 ??+0 ??+0 6067 100910 python2.7 - ??+0 ??+0 ??+0 ??+0 ??+0 ??+0 ??+0 ??+0 ??+0 ??+0 6067 100911 python2.7 - ??+0 ??+0 ??+0 ??+0 ??+0 ??+0 ??+0 ??+0 ??+0 ??+0 root@amdtestr12:/home/mdtancsa # procstat -t 6067 PID TID COMM TDNAME CPU PRI STATE WCHAN 6067 100865 python2.7 - -1 152 sleep usem 6067 100900 python2.7 - -1 152 sleep umtxn 6067 100901 python2.7 - -1 152 sleep umtxn 6067 100902 python2.7 - -1 152 sleep umtxn 6067 100903 python2.7 - -1 152 sleep umtxn 6067 100904 python2.7 - -1 152 sleep umtxn 6067 100905 python2.7 - -1 152 sleep umtxn 6067 100906 python2.7 - -1 152 sleep umtxn 6067 100907 python2.7 - -1 152 sleep umtxn 6067 100908 python2.7 - -1 152 sleep umtxn 6067 100909 python2.7 - -1 152 sleep umtxn 6067 100910 python2.7 - -1 152 sleep umtxn 6067 100911 python2.7 - -1 152 sleep umtxn root@amdtestr12:/home/mdtancsa # -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada From owner-freebsd-stable@freebsd.org Wed Jan 31 00:59:07 2018 Return-Path: Delivered-To: freebsd-stable@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 BC354ECDCA2 for ; Wed, 31 Jan 2018 00:59:07 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from mx2.catspoiler.org (mx2.catspoiler.org [IPv6:2607:f740:16::d18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "amnesiac", Issuer "amnesiac" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 599E46AE96; Wed, 31 Jan 2018 00:59:07 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org ([76.212.85.177]) by mx2.catspoiler.org (8.15.2/8.15.2) with ESMTPS id w0V0xbPC021902 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 31 Jan 2018 00:59:38 GMT (envelope-from truckman@FreeBSD.org) Received: from mousie.catspoiler.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.15.2/8.15.2) with ESMTPS id w0V0ReuT007979 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Jan 2018 16:58:59 -0800 (PST) (envelope-from truckman@FreeBSD.org) Date: Tue, 30 Jan 2018 16:58:59 -0800 (PST) From: Don Lewis Subject: Re: Ryzen issues on FreeBSD ? (with sort of workaround) To: Mike Tancsa cc: Nimrod Levy , freebsd-stable@freebsd.org, Peter Moody , Andriy Gapon , Pete French In-Reply-To: Message-ID: References: <8e842dec-ade7-37d1-6bd8-856ea1a827ca@sentex.net> <730eb882-1c6a-afb7-0ada-396db44fb34b@ingresso.co.uk> <8b882970-4d5d-2a96-4dac-779cab07b9ae@sentex.net> <343acf99-3e9e-093a-7390-c142396c2985@sentex.net> <3dd9a61b-511d-db2e-80ca-cbc9a4b65f92@sentex.net> <55913e41-3a8a-9a4d-6862-e09a3d0f4d55@sentex.net> <5e48bbc2-e872-46bd-eece-25acbb180f77@sentex.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=us-ascii Content-Disposition: INLINE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jan 2018 00:59:08 -0000 On 30 Jan, Mike Tancsa wrote: > On 1/30/2018 5:23 PM, Nimrod Levy wrote: >> That's really strange. I never saw those kinds of deadlocks, but I did >> notice that if I kept the cpu busy using distributed.net >> I could keep the full system lockups away for >> at least a week if not longer. >> >> Not to keep harping on it, but what worked for me was lowering the >> memory speed. I'm at 11 days of uptime so far without anything running >> the cpu. Before the change it would lock up anywhere from an hour to a day. >> > Spoke too soon. After a dozen loops, the process has hung again. Note, > this is not the box locking up, just the compile. I do have memory at a > lower speed too. -- 2133 instead of the default 2400 I suspect the problem is a race condition that causes a wakeup to be lost. Adding load changes the timing enough to avoid the problem most of the time. > I also just tried upgrading to the latest HEAD with a generic kernel and > same / similar lockups although procstat -kk gives some odd results > > > root@amdtestr12:/home/mdtancsa # procstat -kk 6067 > PID TID COMM TDNAME KSTACK > > 6067 100865 python2.7 - ??+0 ??+0 ??+0 ??+0 > ??+0 ??+0 ??+0 ??+0 ??+0 ??+0 > 6067 100900 python2.7 - ??+0 ??+0 ??+0 ??+0 > ??+0 ??+0 ??+0 ??+0 ??+0 ??+0 > 6067 100901 python2.7 - ??+0 ??+0 ??+0 ??+0 > ??+0 ??+0 ??+0 ??+0 ??+0 ??+0 > 6067 100902 python2.7 - ??+0 ??+0 ??+0 ??+0 > ??+0 ??+0 ??+0 ??+0 ??+0 ??+0 > 6067 100903 python2.7 - ??+0 ??+0 ??+0 ??+0 > ??+0 ??+0 ??+0 ??+0 ??+0 ??+0 > 6067 100904 python2.7 - ??+0 ??+0 ??+0 ??+0 > ??+0 ??+0 ??+0 ??+0 ??+0 ??+0 > 6067 100905 python2.7 - ??+0 ??+0 ??+0 ??+0 > ??+0 ??+0 ??+0 ??+0 ??+0 ??+0 > 6067 100906 python2.7 - ??+0 ??+0 ??+0 ??+0 > ??+0 ??+0 ??+0 ??+0 ??+0 ??+0 > 6067 100907 python2.7 - ??+0 ??+0 ??+0 ??+0 > ??+0 ??+0 ??+0 ??+0 ??+0 ??+0 > 6067 100908 python2.7 - ??+0 ??+0 ??+0 ??+0 > ??+0 ??+0 ??+0 ??+0 ??+0 ??+0 > 6067 100909 python2.7 - ??+0 ??+0 ??+0 ??+0 > ??+0 ??+0 ??+0 ??+0 ??+0 ??+0 > 6067 100910 python2.7 - ??+0 ??+0 ??+0 ??+0 > ??+0 ??+0 ??+0 ??+0 ??+0 ??+0 > 6067 100911 python2.7 - ??+0 ??+0 ??+0 ??+0 > ??+0 ??+0 ??+0 ??+0 ??+0 ??+0 Strange ... kernel vs. world mismatch? Some other new regression in HEAD? From owner-freebsd-stable@freebsd.org Wed Jan 31 01:45:34 2018 Return-Path: Delivered-To: freebsd-stable@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 3A524ED0722 for ; Wed, 31 Jan 2018 01:45:34 +0000 (UTC) (envelope-from rroot@rootautomation.com) Received: from mail.4fast.net (mail.4fast.net [209.232.198.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.4fast.net", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A60CD6C9D1 for ; Wed, 31 Jan 2018 01:45:33 +0000 (UTC) (envelope-from rroot@rootautomation.com) Received: (qmail 50285 invoked by uid 89); 31 Jan 2018 01:36:16 -0000 Received: by simscan 1.4.0 ppid: 50074, pid: 50221, t: 0.4364s scanners: clamav: 0.99.2/m:58/d:24271 Received: from 69-36-196-169.cot.net (HELO ?192.168.0.156?) (rroot@rootautomation.com@69.36.196.169) by mail.4fast.net with ESMTPA; 31 Jan 2018 01:36:15 -0000 SavedFromEmail: rroot@rootautomation.com Date: Tue, 30 Jan 2018 17:36:12 -0800 Subject: Re: Ryzen issues on FreeBSD ? (with sort of workaround) In-Reply-To: Importance: normal From: Ryan Root To: Don Lewis , Mike Tancsa Cc: Pete French , freebsd-stable@freebsd.org, Andriy Gapon , Peter Moody , Nimrod Levy MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jan 2018 01:45:34 -0000 SWYgeW91IHdhbnQgdG8gdXNlIGFuIG9wZXJhdGluZyBzeXN0ZW0gdGhhdCB0YWtlcyBhZHZhbnRh Z2Ugb2YgQ1BVIHRvIG1lbW9yeSBvcHRpbWl6YXRpb25zIHdpdGhvdXQgdGFraW5nIHN0ZXBzIGJh Y2t3YXJkcyB5b3UgaGF2ZSB0byBwYXkgYSBwcmljZS4KCgpTZW50IGZyb20gbXkgVmVyaXpvbiwg U2Ftc3VuZyBHYWxheHkgc21hcnRwaG9uZQotLS0tLS0tLSBPcmlnaW5hbCBtZXNzYWdlIC0tLS0t LS0tRnJvbTogRG9uIExld2lzIDx0cnVja21hbkBGcmVlQlNELm9yZz4gRGF0ZTogMS8zMC8xOCAg NDo1OCBQTSAgKEdNVC0wODowMCkgVG86IE1pa2UgVGFuY3NhIDxtaWtlQHNlbnRleC5uZXQ+IENj OiBQZXRlIEZyZW5jaCA8cGV0ZWZyZW5jaEBpbmdyZXNzby5jby51az4sIGZyZWVic2Qtc3RhYmxl QGZyZWVic2Qub3JnLCBBbmRyaXkgR2Fwb24gPGF2Z0BmcmVlYnNkLm9yZz4sIFBldGVyIE1vb2R5 IDxmcmVlYnNkQGhkYTMuY29tPiwgTmltcm9kIExldnkgPG5pbXJvZGxAZ21haWwuY29tPiBTdWJq ZWN0OiBSZTogUnl6ZW4gaXNzdWVzIG9uIEZyZWVCU0QgPyAod2l0aCBzb3J0IG9mIHdvcmthcm91 bmQpIApPbiAzMCBKYW4sIE1pa2UgVGFuY3NhIHdyb3RlOgo+IE9uIDEvMzAvMjAxOCA1OjIzIFBN LCBOaW1yb2QgTGV2eSB3cm90ZToKPj4gVGhhdCdzIHJlYWxseSBzdHJhbmdlLiBJIG5ldmVyIHNh dyB0aG9zZSBraW5kcyBvZiBkZWFkbG9ja3MsIGJ1dCBJIGRpZAo+PiBub3RpY2UgdGhhdCBpZiBJ IGtlcHQgdGhlIGNwdSBidXN5IHVzaW5nIGRpc3RyaWJ1dGVkLm5ldAo+PiA8aHR0cDovL2Rpc3Ry aWJ1dGVkLm5ldD4gSSBjb3VsZCBrZWVwIHRoZSBmdWxsIHN5c3RlbSBsb2NrdXBzIGF3YXkgZm9y Cj4+IGF0IGxlYXN0IGEgd2VlayBpZiBub3QgbG9uZ2VyLgo+PiAKPj4gTm90IHRvIGtlZXAgaGFy cGluZyBvbiBpdCwgYnV0IHdoYXQgd29ya2VkIGZvciBtZSB3YXMgbG93ZXJpbmcgdGhlCj4+IG1l bW9yeSBzcGVlZC4gSSdtIGF0IDExIGRheXMgb2YgdXB0aW1lIHNvIGZhciB3aXRob3V0IGFueXRo aW5nIHJ1bm5pbmcKPj4gdGhlIGNwdS4gQmVmb3JlIHRoZSBjaGFuZ2UgaXQgd291bGQgbG9jayB1 cCBhbnl3aGVyZSBmcm9tIGFuIGhvdXIgdG8gYSBkYXkuCj4+IAo+IFNwb2tlIHRvbyBzb29uLiBB ZnRlciBhIGRvemVuIGxvb3BzLCB0aGUgcHJvY2VzcyBoYXMgaHVuZyBhZ2Fpbi7CoCBOb3RlLAo+ IHRoaXMgaXMgbm90IHRoZSBib3ggbG9ja2luZyB1cCwganVzdCB0aGUgY29tcGlsZS7CoCBJIGRv IGhhdmUgbWVtb3J5IGF0IGEKPiBsb3dlciBzcGVlZCB0b28uIC0tIDIxMzMgaW5zdGVhZCBvZiB0 aGUgZGVmYXVsdCAyNDAwCgpJIHN1c3BlY3QgdGhlIHByb2JsZW0gaXMgYSByYWNlIGNvbmRpdGlv biB0aGF0IGNhdXNlcyBhIHdha2V1cCB0byBiZQpsb3N0LsKgIEFkZGluZyBsb2FkIGNoYW5nZXMg dGhlIHRpbWluZyBlbm91Z2ggdG8gYXZvaWQgdGhlIHByb2JsZW0gbW9zdApvZiB0aGUgdGltZS4K Cj4gSSBhbHNvIGp1c3QgdHJpZWQgdXBncmFkaW5nIHRvIHRoZSBsYXRlc3QgSEVBRCB3aXRoIGEg Z2VuZXJpYyBrZXJuZWwgYW5kCj4gc2FtZSAvIHNpbWlsYXIgbG9ja3VwcyBhbHRob3VnaCBwcm9j c3RhdCAta2sgZ2l2ZXMgc29tZSBvZGQgcmVzdWx0cwo+IAo+IAo+IHJvb3RAYW1kdGVzdHIxMjov aG9tZS9tZHRhbmNzYSAjIHByb2NzdGF0IC1rayA2MDY3Cj7CoMKgIFBJRMKgwqDCoCBUSUQgQ09N TcKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBURE5BTUXCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoCBLU1RBQ0sKPiAKPsKgIDYwNjcgMTAwODY1IHB5dGhvbjIuN8KgwqDCoMKgwqDCoMKg wqDCoMKgIC3CoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgPz8rMCA/PyswID8/ KzAgPz8rMAo+ID8/KzAgPz8rMCA/PyswID8/KzAgPz8rMCA/PyswCj7CoCA2MDY3IDEwMDkwMCBw eXRob24yLjfCoMKgwqDCoMKgwqDCoMKgwqDCoCAtwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgID8/KzAgPz8rMCA/PyswID8/KzAKPiA/PyswID8/KzAgPz8rMCA/PyswID8/KzAg Pz8rMAo+wqAgNjA2NyAxMDA5MDEgcHl0aG9uMi43wqDCoMKgwqDCoMKgwqDCoMKgwqAgLcKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA/PyswID8/KzAgPz8rMCA/PyswCj4gPz8r MCA/PyswID8/KzAgPz8rMCA/PyswID8/KzAKPsKgIDYwNjcgMTAwOTAyIHB5dGhvbjIuN8KgwqDC oMKgwqDCoMKgwqDCoMKgIC3CoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgPz8r MCA/PyswID8/KzAgPz8rMAo+ID8/KzAgPz8rMCA/PyswID8/KzAgPz8rMCA/PyswCj7CoCA2MDY3 IDEwMDkwMyBweXRob24yLjfCoMKgwqDCoMKgwqDCoMKgwqDCoCAtwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgID8/KzAgPz8rMCA/PyswID8/KzAKPiA/PyswID8/KzAgPz8rMCA/ PyswID8/KzAgPz8rMAo+wqAgNjA2NyAxMDA5MDQgcHl0aG9uMi43wqDCoMKgwqDCoMKgwqDCoMKg wqAgLcKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA/PyswID8/KzAgPz8rMCA/ PyswCj4gPz8rMCA/PyswID8/KzAgPz8rMCA/PyswID8/KzAKPsKgIDYwNjcgMTAwOTA1IHB5dGhv bjIuN8KgwqDCoMKgwqDCoMKgwqDCoMKgIC3CoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqAgPz8rMCA/PyswID8/KzAgPz8rMAo+ID8/KzAgPz8rMCA/PyswID8/KzAgPz8rMCA/Pysw Cj7CoCA2MDY3IDEwMDkwNiBweXRob24yLjfCoMKgwqDCoMKgwqDCoMKgwqDCoCAtwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgID8/KzAgPz8rMCA/PyswID8/KzAKPiA/PyswID8/ KzAgPz8rMCA/PyswID8/KzAgPz8rMAo+wqAgNjA2NyAxMDA5MDcgcHl0aG9uMi43wqDCoMKgwqDC oMKgwqDCoMKgwqAgLcKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA/PyswID8/ KzAgPz8rMCA/PyswCj4gPz8rMCA/PyswID8/KzAgPz8rMCA/PyswID8/KzAKPsKgIDYwNjcgMTAw OTA4IHB5dGhvbjIuN8KgwqDCoMKgwqDCoMKgwqDCoMKgIC3CoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqAgPz8rMCA/PyswID8/KzAgPz8rMAo+ID8/KzAgPz8rMCA/PyswID8/KzAg Pz8rMCA/PyswCj7CoCA2MDY3IDEwMDkwOSBweXRob24yLjfCoMKgwqDCoMKgwqDCoMKgwqDCoCAt wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgID8/KzAgPz8rMCA/PyswID8/KzAK PiA/PyswID8/KzAgPz8rMCA/PyswID8/KzAgPz8rMAo+wqAgNjA2NyAxMDA5MTAgcHl0aG9uMi43 wqDCoMKgwqDCoMKgwqDCoMKgwqAgLcKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oCA/PyswID8/KzAgPz8rMCA/PyswCj4gPz8rMCA/PyswID8/KzAgPz8rMCA/PyswID8/KzAKPsKg IDYwNjcgMTAwOTExIHB5dGhvbjIuN8KgwqDCoMKgwqDCoMKgwqDCoMKgIC3CoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgPz8rMCA/PyswID8/KzAgPz8rMAo+ID8/KzAgPz8rMCA/ PyswID8/KzAgPz8rMCA/PyswCgpTdHJhbmdlIC4uLiBrZXJuZWwgdnMuIHdvcmxkIG1pc21hdGNo P8KgIFNvbWUgb3RoZXIgbmV3IHJlZ3Jlc3Npb24gaW4KSEVBRD8KCgpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpmcmVlYnNkLXN0YWJsZUBmcmVlYnNkLm9y ZyBtYWlsaW5nIGxpc3QKaHR0cHM6Ly9saXN0cy5mcmVlYnNkLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2ZyZWVic2Qtc3RhYmxlClRvIHVuc3Vic2NyaWJlLCBzZW5kIGFueSBtYWlsIHRvICJmcmVlYnNk LXN0YWJsZS11bnN1YnNjcmliZUBmcmVlYnNkLm9yZyIK From owner-freebsd-stable@freebsd.org Wed Jan 31 13:34:04 2018 Return-Path: Delivered-To: freebsd-stable@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 789D8ECB792 for ; Wed, 31 Jan 2018 13:34:04 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [78.47.246.247]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E7EAD83C14; Wed, 31 Jan 2018 13:34:03 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id w0VDXjX4087340 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 31 Jan 2018 14:33:46 +0100 (CET) (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: mike@sentex.net Received: from [10.58.0.4] ([10.58.0.4]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id w0VDXc6Q044846 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 31 Jan 2018 20:33:38 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: Ryzen issues on FreeBSD ? (with sort of workaround) To: Mike Tancsa , Don Lewis References: <8e842dec-ade7-37d1-6bd8-856ea1a827ca@sentex.net> <9b769e4e-b098-b294-0bce-8bb1c42e8a59@rootautomation.com> <730eb882-1c6a-afb7-0ada-396db44fb34b@ingresso.co.uk> <8b882970-4d5d-2a96-4dac-779cab07b9ae@sentex.net> <343acf99-3e9e-093a-7390-c142396c2985@sentex.net> <3dd9a61b-511d-db2e-80ca-cbc9a4b65f92@sentex.net> <55913e41-3a8a-9a4d-6862-e09a3d0f4d55@sentex.net> <5e48bbc2-e872-46bd-eece-25acbb180f77@sentex.net> Cc: freebsd-stable@freebsd.org, Peter Moody , Andriy Gapon , Pete French From: Eugene Grosbein Message-ID: <5A71C5AE.6020202@grosbein.net> Date: Wed, 31 Jan 2018 20:33:34 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=2.2 required=5.0 tests=BAYES_00, LOCAL_FROM, RDNS_NONE autolearn=no autolearn_force=no version=3.4.1 X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 2.6 LOCAL_FROM From my domains * 1.9 RDNS_NONE Delivered to internal network by a host with no rDNS X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on hz.grosbein.net X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jan 2018 13:34:04 -0000 31.01.2018 4:36, Mike Tancsa пишет: > On 1/30/2018 2:51 PM, Mike Tancsa wrote: >> >> And sadly, I am still able to hang the compile in about the same place. >> However, if I set > > > OK, here is a sort of work around. If I have the box a little more busy, > I can avoid whatever deadlock is going on. In another console I have > cat /dev/urandom | sha256 > running while the build runs > > ... and I can compile net/samba47 from scratch without the compile > hanging. This problem also happens on HEAD from today. Should I start > a new thread on freebsd-current ? Or just file a bug report ? > The compile worked 4/4 That's really strange. Could you try to do "sysctl kern.eventtimer.periodic=1" and re-do the test without extra load? From owner-freebsd-stable@freebsd.org Wed Jan 31 13:38:38 2018 Return-Path: Delivered-To: freebsd-stable@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 563F3ECBB1B for ; Wed, 31 Jan 2018 13:38:38 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [IPv6:2607:f3e0:80:80::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "smarthost.sentex.ca", Issuer "smarthost.sentex.ca" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 836C383FAA; Wed, 31 Jan 2018 13:38:36 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (lava.sentex.ca [IPv6:2607:f3e0:0:5::11]) by smarthost2.sentex.ca (8.15.2/8.15.2) with ESMTPS id w0VDcZZp007871 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 31 Jan 2018 08:38:36 -0500 (EST) (envelope-from mike@sentex.net) Received: from [192.168.43.26] (saphire3.sentex.net [192.168.43.26]) by lava.sentex.ca (8.15.2/8.15.2) with ESMTP id w0VDcYiS014106; Wed, 31 Jan 2018 08:38:34 -0500 (EST) (envelope-from mike@sentex.net) Subject: Re: Ryzen issues on FreeBSD ? (with sort of workaround) To: Eugene Grosbein , Don Lewis Cc: freebsd-stable@freebsd.org, Pete French References: <8e842dec-ade7-37d1-6bd8-856ea1a827ca@sentex.net> <9b769e4e-b098-b294-0bce-8bb1c42e8a59@rootautomation.com> <730eb882-1c6a-afb7-0ada-396db44fb34b@ingresso.co.uk> <8b882970-4d5d-2a96-4dac-779cab07b9ae@sentex.net> <343acf99-3e9e-093a-7390-c142396c2985@sentex.net> <3dd9a61b-511d-db2e-80ca-cbc9a4b65f92@sentex.net> <55913e41-3a8a-9a4d-6862-e09a3d0f4d55@sentex.net> <5e48bbc2-e872-46bd-eece-25acbb180f77@sentex.net> <5A71C5AE.6020202@grosbein.net> From: Mike Tancsa Organization: Sentex Communications Message-ID: <83cc86a3-e8f9-14e4-14fd-05133417f135@sentex.net> Date: Wed, 31 Jan 2018 08:38:34 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <5A71C5AE.6020202@grosbein.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.78 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jan 2018 13:38:38 -0000 On 1/31/2018 8:33 AM, Eugene Grosbein wrote: > 31.01.2018 4:36, Mike Tancsa пишет: >> On 1/30/2018 2:51 PM, Mike Tancsa wrote: >>> >>> And sadly, I am still able to hang the compile in about the same place. >>> However, if I set >> >> >> OK, here is a sort of work around. If I have the box a little more busy, >> I can avoid whatever deadlock is going on. In another console I have >> cat /dev/urandom | sha256 >> running while the build runs >> >> ... and I can compile net/samba47 from scratch without the compile >> hanging. This problem also happens on HEAD from today. Should I start >> a new thread on freebsd-current ? Or just file a bug report ? >> The compile worked 4/4 > > That's really strange. Could you try to do "sysctl kern.eventtimer.periodic=1" > and re-do the test without extra load? Thanks for the suggestion! I actually upgraded the box to HEAD last night and will try there since the problem is there too. I just created a bug report and started a thread in freebsd-current and will follow up there with your test. ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada From owner-freebsd-stable@freebsd.org Wed Jan 31 21:58:55 2018 Return-Path: Delivered-To: freebsd-stable@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 CA2A8EE4593 for ; Wed, 31 Jan 2018 21:58:55 +0000 (UTC) (envelope-from torfinn.ingolfsen@getmail.no) Received: from ryder.getmail.no (ryder.getmail.no [84.210.184.14]) by mx1.freebsd.org (Postfix) with ESMTP id 5F7357AF3A for ; Wed, 31 Jan 2018 21:58:55 +0000 (UTC) (envelope-from torfinn.ingolfsen@getmail.no) Received: from localhost (localhost [127.0.0.1]) by ryder.getmail.no (Postfix) with ESMTP id 08D7F62C0B for ; Wed, 31 Jan 2018 22:58:52 +0100 (CET) Received: from ryder.getmail.no ([127.0.0.1]) by localhost (ryder.get.c.bitbit.net [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id nuzp_FjYq5Mf for ; Wed, 31 Jan 2018 22:58:51 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by ryder.getmail.no (Postfix) with ESMTP id 5CC9062C0C for ; Wed, 31 Jan 2018 22:58:51 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.9.2 ryder.getmail.no 5CC9062C0C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=getmail.no; s=8A9C8B4C-D727-11E2-8095-B6466E6B3FA2; t=1517435931; bh=cdlNZmlIC3OmIbHdVo+J3xVHOAhqwcIZSHF/Xvdf8Js=; h=Date:From:To:Subject:Message-Id:Mime-Version:Content-Type: Content-Transfer-Encoding; b=oRpVuYpnBu+kUMXmFmaPEpqb0trHXrAarJ59MVMauAuGFp8PuqJ3D61HTAPcvsSt7 PjZIKZQuiBIcKxZgqPMR5IJ2beDBheoP1juslU7IUcep2Ok2+vapuBPDiWdj4xlydf Df82FQoaJtkivbhD1bWQ3XpCyaUS6JadqioPmoAY= X-Virus-Scanned: amavisd-new at ryder.getmail.no Received: from ryder.getmail.no ([127.0.0.1]) by localhost (ryder.get.c.bitbit.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 73-QYEsaLS8c for ; Wed, 31 Jan 2018 22:58:51 +0100 (CET) Received: from kg-core1.kg4.no (cm-84.209.39.108.getinternet.no [84.209.39.108]) by ryder.getmail.no (Postfix) with ESMTPSA id 1734C62C0B for ; Wed, 31 Jan 2018 22:58:51 +0100 (CET) Date: Wed, 31 Jan 2018 22:58:50 +0100 From: Torfinn Ingolfsen To: freebsd-stable@freebsd.org Subject: FreeBSD 11.1-release - verbose boot causes the machine to restart Message-Id: <20180131225850.948723deedfe2cafd808c709@getmail.no> X-Mailer: Sylpheed 3.6.0 (GTK+ 2.24.31; amd64-portbld-freebsd10.3) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jan 2018 21:58:56 -0000 Ok, this I haven't seen before. I just installed FreeBSD 11.1-release on a quite new machine[1]. The machine is an ASRock BeeBox-S 7100U, a quite "normal" NUC-form machine with a i3-7100U (Kaby Lake) and an internal SSD. Installation went great (I only had to manually copy /boot/boot1.efi to the correct EFI partition. Yes - there are other operating systems on the internal SSD), and the machine boots and works normally. However, if I select verbose boot from the boot menu, the kernel starts spitting out kernel messages and after a while the machine restarts. Afterwards (after a normal boot) there is no sign of this unusal activity either in dmesg output, /var/log/messages or /var/crash. Is this something developers want to know more about? If so, pointers on howe to debug this further is appreciated. Details (including dmesg outpuyt from a normal boot) on the FreeBSD page[2] of this machine. References: 1) https://sites.google.com/site/tingox/asrock_beebox-s_7100u 2) https://sites.google.com/site/tingox/asrock_beebox-s_7100u_fbsd -- Torfinn Ingolfsen From owner-freebsd-stable@freebsd.org Wed Jan 31 22:41:56 2018 Return-Path: Delivered-To: freebsd-stable@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 CCED1EE6653 for ; Wed, 31 Jan 2018 22:41:56 +0000 (UTC) (envelope-from amvandemore@gmail.com) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5F4B87CC73 for ; Wed, 31 Jan 2018 22:41:56 +0000 (UTC) (envelope-from amvandemore@gmail.com) Received: by mail-io0-x232.google.com with SMTP id 25so16976225ioj.9 for ; Wed, 31 Jan 2018 14:41:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9ikPtZA00BDalIJo7B7asMo/JamBbS7wxAsKtbJMr+8=; b=n9ELSsQ4KPS8tMjvghqHuT/PULVbBMGCUxBIGFNAjkYtDktT7KJpQ8XNuIBYgeC8AG pmBlI3gAjx+EUG/LMKYVru0d3O5rie+9wG2zH6nAN21rc5MPVgegWCZKNPPVmUHgT6ZX BUjeR9sDJtKoBkmmAO4/kjRZf3tef4V43P4PaQTHipnTzqzsHx246xfLWv5mNW0qW03a ohjdvMgA5pxAjf03O+0+gSPrilx+J5twy8Bpa+AKJkmke4fSB5vvCtpEg82Z87iJVJBu AYGjQGvnuUu0dRIHNxvsqnJl+vOclgjz0UA/kuoN/8zRJsSdDakpZMAVia14+Btf361q 0+QQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9ikPtZA00BDalIJo7B7asMo/JamBbS7wxAsKtbJMr+8=; b=qfk3vXrXGj2uGZ51dIzImLB/vQmwzBvjfntGQqwWRUKvIUjZFcayp4+WLhJ6UYVgYC 4RfbP0pOUwD0NUnOt6VZ+pAFzYSTEHPwqz+OIC63XgJL9+KmwYfScCD/wmh+JPQiAbFW uZKsX5xmreye/L0HgoBcYdcFtzoFx34KEUP6lUIFguxhFe01W4X+0gHU8Hhh7NCt/OJq RdWt1ju7InGRybLkYyyjmFYkiHw7J5WFy6FM4YkQH0Y7ubtYI2v9INJVwmTPHHGycqNk FdvrCHkUAAGB3gwyaDCzhAGL0Q0BMOSWGPmtMHHjXfKOGW9Ml0lxd8GjkbFSV/U4VOEs YxXQ== X-Gm-Message-State: AKwxytfIZD5RDt16eMV4dbpMCZBe+wtTVbXi/QcjH3oslyq2ozUb60Lb nUfqbvdyw8883m4XQSO7Kju3HMPji/4Ac16k4wA= X-Google-Smtp-Source: AH8x224MUAj36kwXCuZVxe2wks0q/BbTvGS0zu+suu8DSJwknlTnk68xBeHdQVDDX3gF+vUwP9AjBaK/D2w5oItInFo= X-Received: by 10.107.140.207 with SMTP id o198mr35215616iod.175.1517438515821; Wed, 31 Jan 2018 14:41:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.2.156.70 with HTTP; Wed, 31 Jan 2018 14:41:55 -0800 (PST) In-Reply-To: <20180131225850.948723deedfe2cafd808c709@getmail.no> References: <20180131225850.948723deedfe2cafd808c709@getmail.no> From: Adam Vande More Date: Wed, 31 Jan 2018 16:41:55 -0600 Message-ID: Subject: Re: FreeBSD 11.1-release - verbose boot causes the machine to restart To: Torfinn Ingolfsen Cc: "freebsd-stable@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jan 2018 22:41:57 -0000 On Wed, Jan 31, 2018 at 3:58 PM, Torfinn Ingolfsen < torfinn.ingolfsen@getmail.no> wrote: > Ok, this I haven't seen before. > I just installed FreeBSD 11.1-release on a quite new machine[1]. The > machine is an ASRock BeeBox-S 7100U, a quite "normal" NUC-form machine with > a i3-7100U (Kaby Lake) and an internal SSD. > Installation went great (I only had to manually copy /boot/boot1.efi to > the correct EFI partition. Yes - there are other operating systems on the > internal SSD), and the machine boots and works normally. > > However, if I select verbose boot from the boot menu, the kernel starts > spitting out kernel messages and after a while the machine restarts. > Afterwards (after a normal boot) there is no sign of this unusal activity > either in dmesg output, /var/log/messages or /var/crash. > > Is this something developers want to know more about? If so, pointers on > howe to debug this further is appreciated. > Details (including dmesg outpuyt from a normal boot) on the FreeBSD > page[2] of this machine. > > References: > 1) https://sites.google.com/site/tingox/asrock_beebox-s_7100u > 2) https://sites.google.com/site/tingox/asrock_beebox-s_7100u_fbsd > > Is it a panic reboot? If so you can try setting the loader or sysctl option to not reboot after panic or drop to debugger option. -- Adam From owner-freebsd-stable@freebsd.org Thu Feb 1 18:41:18 2018 Return-Path: Delivered-To: freebsd-stable@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 47E13EE4574 for ; Thu, 1 Feb 2018 18:41:18 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CB84A7CAF8; Thu, 1 Feb 2018 18:41:17 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-io0-x234.google.com with SMTP id z6so20241369iob.11; Thu, 01 Feb 2018 10:41:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=y7P4VPCizoov/VEYl0by52Vjnz2jwJssv7njS9uNfS4=; b=D+AJbXavZ49wIVSRtF4VAqhomuyrePc7VhnliSEcRrlAuSCNQyUT76a576ySM/I460 3KE1PlcmaQzMt3DpmyEN5GjytKdsZQypVlhNgUh+9vzB3lFu5Qsas8aYXXrm83DSPrk4 tADiABEkqCiVimp8aEfruQC+YDlol/3b6fJxrfFEDrzIi15FSZUeHPdWyiuRcb0R3H3I LBkYdow3ubwnRgdJFe5/psc6qvZv67B6F8Feoz/5rBKCHXC0nX7P6x1P74Ii5vvvU6yR D6TIJthmIjmEA04Cg3fx06Xk93mgzPp3oPE6v9s5qP9XlbuLD9pCb+VDQt1MNwuMY5RG jAKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=y7P4VPCizoov/VEYl0by52Vjnz2jwJssv7njS9uNfS4=; b=BydqiMgbaqWIfQhMCw3yPgojkIql8scciljaQAN/pvoMoB1RNBVQEbuUCHNaxE18Ln 6m2flGkdk4cnPPQnRmwsQpc+A84jgGTDnjo3nTbra01ZDINfcvbABj461FVm5E60NSqk SGjk+Z6aSdS1u5gyWJ3of5te8iLXZgqzZgou4KkkwszIQUSUzTh4xuJIWhUustnj9THz lbI1rsa9LPZK+OPJ4mVjKq/4z6zygYpM+zMHnBv8f3Y6e7ZNqxK3qZKI4XoNX93RzM2M KNTycGBOsDbpMDpCvdT6ZhG8pmyBo7TwSli1qZcNm/PF7kE1nbQyp0Krxgk94UDlgu84 /Hlg== X-Gm-Message-State: AKwxytfvSnmhSk9LYIuh/UPcNh+6E58E6UdB+kBVcEMG3Cb+kgE64pCq tqykYv90ZmhP+JJ3p1qBODs+WMm+OPWQolyiFMU= X-Google-Smtp-Source: AH8x226tjvwS4bCE9d7ZNEFSNM3CoQPmEN8ox/+EWQmb9OPDOVN/b7mbEI5Bygz0sjXCi9H+9PkiM+MuFRiNSXPKlEM= X-Received: by 10.107.173.225 with SMTP id m94mr39446158ioo.36.1517510477235; Thu, 01 Feb 2018 10:41:17 -0800 (PST) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.152.9 with HTTP; Thu, 1 Feb 2018 10:40:56 -0800 (PST) In-Reply-To: References: <8e842dec-ade7-37d1-6bd8-856ea1a827ca@sentex.net> <730eb882-1c6a-afb7-0ada-396db44fb34b@ingresso.co.uk> <8b882970-4d5d-2a96-4dac-779cab07b9ae@sentex.net> <343acf99-3e9e-093a-7390-c142396c2985@sentex.net> <3dd9a61b-511d-db2e-80ca-cbc9a4b65f92@sentex.net> <55913e41-3a8a-9a4d-6862-e09a3d0f4d55@sentex.net> <5e48bbc2-e872-46bd-eece-25acbb180f77@sentex.net> From: Ed Maste Date: Thu, 1 Feb 2018 13:40:56 -0500 X-Google-Sender-Auth: LNJ_eh46CzwQTyb5TCiITm135E8 Message-ID: Subject: Re: Ryzen issues on FreeBSD ? (with sort of workaround) To: Mike Tancsa Cc: Nimrod Levy , Don Lewis , freebsd-stable stable , Andriy Gapon , Peter Moody , Pete French Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Feb 2018 18:41:18 -0000 On 30 January 2018 at 19:48, Mike Tancsa wrote: >> > I also just tried upgrading to the latest HEAD with a generic kernel and > same / similar lockups although procstat -kk gives some odd results > > > root@amdtestr12:/home/mdtancsa # procstat -kk 6067 > PID TID COMM TDNAME KSTACK > > 6067 100865 python2.7 - ??+0 ??+0 ??+0 ??+0 > ??+0 ??+0 ??+0 ??+0 ??+0 ??+0 I think this part is due to the broken loader change in r328536. Kernel symbol loading is broken, and this in particular isn't related to Ryzen issues. From owner-freebsd-stable@freebsd.org Thu Feb 1 18:49:21 2018 Return-Path: Delivered-To: freebsd-stable@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 1CDF7EE4DED for ; Thu, 1 Feb 2018 18:49:21 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [IPv6:2607:f3e0:80:80::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "smarthost.sentex.ca", Issuer "smarthost.sentex.ca" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8C1B57D140; Thu, 1 Feb 2018 18:49:20 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (lava.sentex.ca [IPv6:2607:f3e0:0:5::11]) by smarthost2.sentex.ca (8.15.2/8.15.2) with ESMTPS id w11InJA6017983 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 1 Feb 2018 13:49:20 -0500 (EST) (envelope-from mike@sentex.net) Received: from [192.168.43.26] (saphire3.sentex.ca [192.168.43.26]) by lava.sentex.ca (8.15.2/8.15.2) with ESMTP id w11InHc9025488; Thu, 1 Feb 2018 13:49:17 -0500 (EST) (envelope-from mike@sentex.net) Subject: Re: Ryzen issues on FreeBSD ? (with sort of workaround) To: Ed Maste Cc: Nimrod Levy , Don Lewis , freebsd-stable stable , Andriy Gapon , Peter Moody , Pete French References: <8e842dec-ade7-37d1-6bd8-856ea1a827ca@sentex.net> <730eb882-1c6a-afb7-0ada-396db44fb34b@ingresso.co.uk> <8b882970-4d5d-2a96-4dac-779cab07b9ae@sentex.net> <343acf99-3e9e-093a-7390-c142396c2985@sentex.net> <3dd9a61b-511d-db2e-80ca-cbc9a4b65f92@sentex.net> <55913e41-3a8a-9a4d-6862-e09a3d0f4d55@sentex.net> <5e48bbc2-e872-46bd-eece-25acbb180f77@sentex.net> From: Mike Tancsa Organization: Sentex Communications Message-ID: <38a14576-2dbd-a1ba-791c-197351d091c0@sentex.net> Date: Thu, 1 Feb 2018 13:49:17 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.78 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Feb 2018 18:49:21 -0000 On 2/1/2018 1:40 PM, Ed Maste wrote: >> root@amdtestr12:/home/mdtancsa # procstat -kk 6067 >> PID TID COMM TDNAME KSTACK >> >> 6067 100865 python2.7 - ??+0 ??+0 ??+0 ??+0 >> ??+0 ??+0 ??+0 ??+0 ??+0 ??+0 > > I think this part is due to the broken loader change in r328536. > Kernel symbol loading is broken, and this in particular isn't related > to Ryzen issues. Just for the archives, after a buildworld to a newer rev of the source tree, all was good :) ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 x203 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada From owner-freebsd-stable@freebsd.org Thu Feb 1 18:51:08 2018 Return-Path: Delivered-To: freebsd-stable@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 45E4EEE4F66 for ; Thu, 1 Feb 2018 18:51:08 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [IPv6:2607:f3e0:80:80::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "smarthost.sentex.ca", Issuer "smarthost.sentex.ca" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D5BD17D2BB; Thu, 1 Feb 2018 18:51:07 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (lava.sentex.ca [IPv6:2607:f3e0:0:5::11]) by smarthost2.sentex.ca (8.15.2/8.15.2) with ESMTPS id w11Ip7ln018372 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 1 Feb 2018 13:51:07 -0500 (EST) (envelope-from mike@sentex.net) Received: from [192.168.43.26] (saphire3.sentex.ca [192.168.43.26]) by lava.sentex.ca (8.15.2/8.15.2) with ESMTP id w11Ip4nB025493; Thu, 1 Feb 2018 13:51:05 -0500 (EST) (envelope-from mike@sentex.net) Subject: Re: Ryzen issues on FreeBSD ? (with sort of workaround) From: Mike Tancsa To: Ed Maste Cc: freebsd-stable stable , Nimrod Levy , Don Lewis , Andriy Gapon , Pete French , Peter Moody References: <8e842dec-ade7-37d1-6bd8-856ea1a827ca@sentex.net> <730eb882-1c6a-afb7-0ada-396db44fb34b@ingresso.co.uk> <8b882970-4d5d-2a96-4dac-779cab07b9ae@sentex.net> <343acf99-3e9e-093a-7390-c142396c2985@sentex.net> <3dd9a61b-511d-db2e-80ca-cbc9a4b65f92@sentex.net> <55913e41-3a8a-9a4d-6862-e09a3d0f4d55@sentex.net> <5e48bbc2-e872-46bd-eece-25acbb180f77@sentex.net> <38a14576-2dbd-a1ba-791c-197351d091c0@sentex.net> Organization: Sentex Communications Message-ID: Date: Thu, 1 Feb 2018 13:51:05 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <38a14576-2dbd-a1ba-791c-197351d091c0@sentex.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.78 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Feb 2018 18:51:08 -0000 On 2/1/2018 1:49 PM, Mike Tancsa wrote: > On 2/1/2018 1:40 PM, Ed Maste wrote: >>> root@amdtestr12:/home/mdtancsa # procstat -kk 6067 >>> PID TID COMM TDNAME KSTACK >>> >>> 6067 100865 python2.7 - ??+0 ??+0 ??+0 ??+0 >>> ??+0 ??+0 ??+0 ??+0 ??+0 ??+0 >> >> I think this part is due to the broken loader change in r328536. >> Kernel symbol loading is broken, and this in particular isn't related >> to Ryzen issues. > > Just for the archives, after a buildworld to a newer rev of the source > tree, all was good :) Ugh, to clarify, all was good with the procstat issue. ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 x203 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada From owner-freebsd-stable@freebsd.org Fri Feb 2 12:56:44 2018 Return-Path: Delivered-To: freebsd-stable@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 A2E92ED7E46 for ; Fri, 2 Feb 2018 12:56:44 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 36CD66A5D6 for ; Fri, 2 Feb 2018 12:56:43 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from bach.cs.huji.ac.il ([132.65.80.20]) by kabab.cs.huji.ac.il with esmtp id 1ehak0-000CQ3-1z for freebsd-stable@freebsd.org; Fri, 02 Feb 2018 14:46:52 +0200 From: Daniel Braniss Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: panic when loading mlxen Message-Id: <83F78F7E-4DC2-41F5-837A-CB728D67B1E3@cs.huji.ac.il> Date: Fri, 2 Feb 2018 14:46:51 +0200 To: freebsd-stable X-Mailer: Apple Mail (2.3445.5.20) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Feb 2018 12:56:44 -0000 with latest stable (r328769) when I have mlxen_load=3D=E2=80=9CYES=E2=80=9D in my loader.conf it panics: KDB: debugger backends: ddbsize 0x4638 at 0x22d6000 = f KDB: current backend: ddb Copyright (c) 1992-2018 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 11.1-STABLE #18: Fri Feb 2 10:46:12 IST 2018 danny@pe-44:/home/obj/pe-44/net/rnd/r+d/stable/11/sys/HUJI amd64 FreeBSD clang version 5.0.1 (tags/RELEASE_501/final 320880) (based on = LLVM 5.0.1) VT(vga): resolution 640x480 CPU: Intel(R) Xeon(R) CPU E5507 @ 2.27GHz (2261.04-MHz = K8-class CPU) Origin=3D"GenuineIntel" Id=3D0x106a5 Family=3D0x6 Model=3D0x1a = Stepping=3D5 = Features=3D0xbfebfbff = Features2=3D0x9ce3bd AMD Features=3D0x28100800 AMD Features2=3D0x1 VT-x: PAT,HLT,MTF,PAUSE,EPT,VPID TSC: P-state invariant, performance statistics real memory =3D 25769803776 (24576 MB) avail memory =3D 24931561472 (23776 MB) Event timer "LAPIC" quality 100 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs FreeBSD/SMP: 2 package(s) x 4 core(s) ioapic1: Changing APIC ID to 1 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 32-55 on motherboard Fatal trap 12: page fault while in kernel mode cpuid =3D 0; apic id =3D 10 fault virtual address =3D 0x1818 fault code =3D supervisor write data, page not present instruction pointer =3D 0x20:0xffffffff80ad427f stack pointer =3D 0x28:0xffffffff822e3be0 frame pointer =3D 0x28:0xffffffff822e3c30 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags =3D interrupt enabled, resume, IOPL =3D 0 current process =3D 0 (swapper) [ thread pid 0 tid 100000 ] Stopped at taskqgroup_attach_cpu+0x4f: lock cmpxchgq = %r12,(%rdi)= From owner-freebsd-stable@freebsd.org Fri Feb 2 17:17:35 2018 Return-Path: Delivered-To: freebsd-stable@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 7E107EE4C98 for ; Fri, 2 Feb 2018 17:17:35 +0000 (UTC) (envelope-from torfinn.ingolfsen@getmail.no) Received: from lamora.getmail.no (lamora.getmail.no [84.210.184.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0FE50757CE for ; Fri, 2 Feb 2018 17:17:34 +0000 (UTC) (envelope-from torfinn.ingolfsen@getmail.no) Received: from localhost (localhost [127.0.0.1]) by lamora.getmail.no (Postfix) with ESMTP id 4313A600B5 for ; Fri, 2 Feb 2018 18:17:24 +0100 (CET) Received: from lamora.getmail.no ([127.0.0.1]) by localhost (lamora.get.c.bitbit.net [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 9gGSEfeV9cga for ; Fri, 2 Feb 2018 18:17:23 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by lamora.getmail.no (Postfix) with ESMTP id CA3CC600B6 for ; Fri, 2 Feb 2018 18:17:23 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.9.2 lamora.getmail.no CA3CC600B6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=getmail.no; s=8A9C8B4C-D727-11E2-8095-B6466E6B3FA2; t=1517591843; bh=lLkugE0sYltnjLSNIY0GCfDR3AcTD2SZ0+3eyfRaaWk=; h=Date:From:To:Subject:Message-Id:Mime-Version:Content-Type: Content-Transfer-Encoding; b=2LC0mZ2j+a/UhDcABurKQy5rkM6/MdtOSWfKXf25lZVbc5270u7ZyktNDs8awcUuj TvmvVP3ElIIGci1fqla3go/Pk8m3mz3egRgZuQ64VAH2BlJQoWcXkUH8lYy/f+FUyB x8//h0EoBjkvL3bPmlyq1mAXpssl7qtYNiqBw38E= X-Virus-Scanned: amavisd-new at lamora.get.c.bitbit.net Received: from lamora.getmail.no ([127.0.0.1]) by localhost (lamora.get.c.bitbit.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id t_KlAA4jwjdt for ; Fri, 2 Feb 2018 18:17:23 +0100 (CET) Received: from kg-core1.kg4.no (cm-84.209.39.108.getinternet.no [84.209.39.108]) by lamora.getmail.no (Postfix) with ESMTPSA id A13EC600B5 for ; Fri, 2 Feb 2018 18:17:23 +0100 (CET) Date: Fri, 2 Feb 2018 18:17:23 +0100 From: Torfinn Ingolfsen To: freebsd-stable@freebsd.org Subject: Re: FreeBSD 11.1-release - verbose boot causes the machine to restart Message-Id: <20180202181723.768ccdc4991fbe15394159d1@getmail.no> In-Reply-To: References: <20180131225850.948723deedfe2cafd808c709@getmail.no> X-Mailer: Sylpheed 3.6.0 (GTK+ 2.24.31; amd64-portbld-freebsd10.3) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Feb 2018 17:17:35 -0000 On Wed, 31 Jan 2018 16:41:55 -0600 Adam Vande More wrote: > On Wed, Jan 31, 2018 at 3:58 PM, Torfinn Ingolfsen < > torfinn.ingolfsen@getmail.no> wrote: > > > Ok, this I haven't seen before. > > I just installed FreeBSD 11.1-release on a quite new machine[1]. The > > machine is an ASRock BeeBox-S 7100U, a quite "normal" NUC-form machine with > > a i3-7100U (Kaby Lake) and an internal SSD. > > Installation went great (I only had to manually copy /boot/boot1.efi to > > the correct EFI partition. Yes - there are other operating systems on the > > internal SSD), and the machine boots and works normally. > > > > However, if I select verbose boot from the boot menu, the kernel starts > > spitting out kernel messages and after a while the machine restarts. > > Afterwards (after a normal boot) there is no sign of this unusal activity > > either in dmesg output, /var/log/messages or /var/crash. > > > > Is this something developers want to know more about? If so, pointers on > > howe to debug this further is appreciated. > > Details (including dmesg outpuyt from a normal boot) on the FreeBSD > > page[2] of this machine. > > > > References: > > 1) https://sites.google.com/site/tingox/asrock_beebox-s_7100u > > 2) https://sites.google.com/site/tingox/asrock_beebox-s_7100u_fbsd > > > > > Is it a panic reboot? I don't think so - there are no indications of that. -- Torfinn Ingolfsen From owner-freebsd-stable@freebsd.org Fri Feb 2 18:47:10 2018 Return-Path: Delivered-To: freebsd-stable@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 918A3EE907F for ; Fri, 2 Feb 2018 18:47:10 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: from mail-ot0-x241.google.com (mail-ot0-x241.google.com [IPv6:2607:f8b0:4003:c0f::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B52C57A1B1 for ; Fri, 2 Feb 2018 18:47:09 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: by mail-ot0-x241.google.com with SMTP id d9so21228521oth.6 for ; Fri, 02 Feb 2018 10:47:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=qP3dufBVmn2f3p6X1SAzZtkyav8Frj5mbTgZ5CDfpL0=; b=nuQufhGRig3se+YFRTMTi9gXnhFaOQCdayyB9SIbqVDPVkItT4slrc6Rh63zMpzxcP EXZbCkE86xZaxzd57f1A1bybPWBwccUWlFxSdTOmSBcaOZ4BJhd3AKv4dWpIQ0O8ENTQ qZfACYDr6ktULvamK4P1L0FXEybHQW/mEP0qYw4jeTDzAKxDbT3DCU1JX3/C9ZiA26cq 6oecwXHUfCGxIhJtZPdGixZZYAnV4wYkOxuWdjYV62+wKngM9o0L5aoT1zct/wG7exSw 09V5pvxwDkXlxtCmnX8LCmxAkEqDBqXoniDzBNJgO5AOp1aUIx9ypy2nZHYqY2OzuQPo QuGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=qP3dufBVmn2f3p6X1SAzZtkyav8Frj5mbTgZ5CDfpL0=; b=qg9rNLfwo/M1HnDNMzPfVRKJPg8+V5uyteHwfz48ywOMWnf3BZKxhFA2VGNgMtioQ3 W0+/XCocTnocOwJVhHETNM54AK3KY4ay8DK+1rLTme2zgyAASBQ+roRaMPSa9S3cVTLt EhHfWdMvzgpDIZNUaItmWKowPO6BiGDO0HP7vmjVWsh6c06SusvKo5LUvthitCaqYnKF XQfqMf9ZZrVY7OUbNjGW4yn80+qqZwOl62NZteMI4dGS5Ong2aKZ+2uMrPLtmkbmpO0I eQ21RTHPn6tb0w4dzRURvLNd1wvdU5FELPKLoT8TuxP3r6ZQdm74i5eVCGszr/lgGu3+ ByVQ== X-Gm-Message-State: AKwxytdVs99r2gVmHt9qC53+jOk+njHkQ/dhCZGpSYQdvtCtR73uLshi 6gCJ3yN6/G3DnUdTkSfof+tz9CJ16DrVLrJ/eR8= X-Google-Smtp-Source: AH8x224ZNTaPPmdNcxUVR3H6Pjry27JfaxHlzGlnwr4U55c6oTx/tYyGxvyhrsdnKtnCAxVnsmF8mQKxIPfLUwdjnrQ= X-Received: by 10.157.96.15 with SMTP id h15mr6954607otj.267.1517597228839; Fri, 02 Feb 2018 10:47:08 -0800 (PST) MIME-Version: 1.0 Sender: kmacybsd@gmail.com Received: by 10.157.71.2 with HTTP; Fri, 2 Feb 2018 10:47:08 -0800 (PST) In-Reply-To: <83F78F7E-4DC2-41F5-837A-CB728D67B1E3@cs.huji.ac.il> References: <83F78F7E-4DC2-41F5-837A-CB728D67B1E3@cs.huji.ac.il> From: "K. Macy" Date: Fri, 2 Feb 2018 10:47:08 -0800 X-Google-Sender-Auth: lnP-Y67-81Q-cA-_jad_qxazDoA Message-ID: Subject: Re: panic when loading mlxen To: Daniel Braniss Cc: freebsd-stable Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Feb 2018 18:47:10 -0000 That's odd since it doesn't use any of taskqgroup stuff. I take it you can't get a core? Also, why are you loading it in loader.conf (slower) as opposed to rc.conf? -M On Fri, Feb 2, 2018 at 4:46 AM, Daniel Braniss wrote: > with latest stable (r328769) when I have > mlxen_load=3D=E2=80=9CYES=E2=80=9D > in my loader.conf it panics: > > KDB: debugger backends: ddbsize 0x4638 at 0x22d6000 = f > KDB: current backend: ddb > Copyright (c) 1992-2018 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 11.1-STABLE #18: Fri Feb 2 10:46:12 IST 2018 > danny@pe-44:/home/obj/pe-44/net/rnd/r+d/stable/11/sys/HUJI amd64 > FreeBSD clang version 5.0.1 (tags/RELEASE_501/final 320880) (based on LLV= M 5.0.1) > VT(vga): resolution 640x480 > CPU: Intel(R) Xeon(R) CPU E5507 @ 2.27GHz (2261.04-MHz K8-clas= s CPU) > Origin=3D"GenuineIntel" Id=3D0x106a5 Family=3D0x6 Model=3D0x1a Stepp= ing=3D5 > Features=3D0xbfebfbff > Features2=3D0x9ce3bd > AMD Features=3D0x28100800 > AMD Features2=3D0x1 > VT-x: PAT,HLT,MTF,PAUSE,EPT,VPID > TSC: P-state invariant, performance statistics > real memory =3D 25769803776 (24576 MB) > avail memory =3D 24931561472 (23776 MB) > Event timer "LAPIC" quality 100 > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs > FreeBSD/SMP: 2 package(s) x 4 core(s) > ioapic1: Changing APIC ID to 1 > ioapic0 irqs 0-23 on motherboard > ioapic1 irqs 32-55 on motherboard > > > Fatal trap 12: page fault while in kernel mode > cpuid =3D 0; apic id =3D 10 > fault virtual address =3D 0x1818 > fault code =3D supervisor write data, page not present > instruction pointer =3D 0x20:0xffffffff80ad427f > stack pointer =3D 0x28:0xffffffff822e3be0 > frame pointer =3D 0x28:0xffffffff822e3c30 > code segment =3D base 0x0, limit 0xfffff, type 0x1b > =3D DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags =3D interrupt enabled, resume, IOPL =3D 0 > current process =3D 0 (swapper) > [ thread pid 0 tid 100000 ] > Stopped at taskqgroup_attach_cpu+0x4f: lock cmpxchgq %r12,(%rd= i) > _______________________________________________ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@freebsd.org Sat Feb 3 07:38:02 2018 Return-Path: Delivered-To: freebsd-stable@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 3763CEC9B10 for ; Sat, 3 Feb 2018 07:38:02 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BF03779B40 for ; Sat, 3 Feb 2018 07:38:01 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from imac.bk.cs.huji.ac.il ([132.65.179.42]) by kabab.cs.huji.ac.il with esmtp id 1ehsOd-000Aci-Tc for freebsd-stable@freebsd.org; Sat, 03 Feb 2018 09:37:59 +0200 From: Daniel Braniss Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: random 11.1 boot panic Message-Id: <3FD5CEA0-A8AA-40D6-998D-ACF536516565@cs.huji.ac.il> Date: Sat, 3 Feb 2018 09:37:59 +0200 To: freebsd-stable X-Mailer: Apple Mail (2.3445.5.20) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Feb 2018 07:38:02 -0000 this has been happening randomly for some time now, =E2=80=A6 cd0: Attempt to query device size failed: NOT READY, Medium not present = - tray ] Stopped at vga_bitblt_one_text_pixels_block+0x13e: movl = (%rax,%r13,4),%d db> bt Tracing pid 4 tid 100042 td 0xfffff8000a4f2620 vga_bitblt_one_text_pixels_block() at = vga_bitblt_one_text_pixels_block+0x13e/fr0 vga_bitblt_text() at vga_bitblt_text+0xc0/frame 0xfffffe05d950f160 vt_flush() at vt_flush+0x38f/frame 0xfffffe05d950f1b0 termcn_cnputc() at termcn_cnputc+0xbe/frame 0xfffffe05d950f1e0 cnputc() at cnputc+0x181/frame 0xfffffe05d950f210 cnputs() at cnputs+0x78/frame 0xfffffe05d950f230 putchar() at putchar+0x14d/frame 0xfffffe05d950f2b0 kvprintf() at kvprintf+0x113d/frame 0xfffffe05d950f3b0 vprintf() at vprintf+0x84/frame 0xfffffe05d950f500 printf() at printf+0x43/frame 0xfffffe05d950f560 cddone() at cddone+0x210/frame 0xfffffe05d950fb20 xpt_done_process() at xpt_done_process+0x697/frame 0xfffffe05d950fb60 xpt_done_td() at xpt_done_td+0x196/frame 0xfffffe05d950fbb0 fork_exit() at fork_exit+0x82/frame 0xfffffe05d950fbf0 fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe05d950fbf0 --- trap 0, rip =3D 0, rsp =3D 0, rbp =3D 0 --- db> danny From owner-freebsd-stable@freebsd.org Sat Feb 3 07:34:50 2018 Return-Path: Delivered-To: freebsd-stable@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 B8C7BEC9900 for ; Sat, 3 Feb 2018 07:34:50 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4AF86799F0; Sat, 3 Feb 2018 07:34:49 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from imac.bk.cs.huji.ac.il ([132.65.179.42]) by kabab.cs.huji.ac.il with esmtp id 1ehsLU-0009yy-Mz; Sat, 03 Feb 2018 09:34:44 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: panic when loading mlxen From: Daniel Braniss In-Reply-To: Date: Sat, 3 Feb 2018 09:34:44 +0200 Cc: freebsd-stable , Hans Petter Selasky Content-Transfer-Encoding: quoted-printable Message-Id: <0D15BA02-5E39-4E04-84E1-3BF6D62065C1@cs.huji.ac.il> References: <83F78F7E-4DC2-41F5-837A-CB728D67B1E3@cs.huji.ac.il> To: "K. Macy" X-Mailer: Apple Mail (2.3445.5.20) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Feb 2018 07:34:50 -0000 > On 2 Feb 2018, at 20:47, K. Macy wrote: >=20 > That's odd since it doesn't use any of taskqgroup stuff. I take it you > can't get a core? no core but some more info: db> bt Tracing pid 0 tid 100000 td 0xffffffff81e0e500 taskqgroup_attach_cpu() at taskqgroup_attach_cpu+0x4f/frame = 0xffffffff822e4c30 tasklet_subsystem_init() at tasklet_subsystem_init+0xde/frame = 0xffffffff822e4c90 mi_startup() at mi_startup+0x9c/frame 0xffffffff822e4cb0 btext() at btext+0x2c >=20 > Also, why are you loading it in loader.conf (slower) as opposed to = rc.conf? sometimes it=E2=80=99s booted diskless, and the driver is needed early. and btw, this box doesn=E2=80=99t even have a mellanox card. > -M >=20 >=20 >=20 > On Fri, Feb 2, 2018 at 4:46 AM, Daniel Braniss = wrote: >> with latest stable (r328769) when I have >> mlxen_load=3D=E2=80=9CYES=E2=80=9D >> in my loader.conf it panics: >>=20 >> KDB: debugger backends: ddbsize 0x4638 at 0x22d6000 = f >> KDB: current backend: ddb >> Copyright (c) 1992-2018 The FreeBSD Project. >> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, = 1994 >> The Regents of the University of California. All rights = reserved. >> FreeBSD is a registered trademark of The FreeBSD Foundation. >> FreeBSD 11.1-STABLE #18: Fri Feb 2 10:46:12 IST 2018 >> danny@pe-44:/home/obj/pe-44/net/rnd/r+d/stable/11/sys/HUJI amd64 >> FreeBSD clang version 5.0.1 (tags/RELEASE_501/final 320880) (based on = LLVM 5.0.1) >> VT(vga): resolution 640x480 >> CPU: Intel(R) Xeon(R) CPU E5507 @ 2.27GHz (2261.04-MHz = K8-class CPU) >> Origin=3D"GenuineIntel" Id=3D0x106a5 Family=3D0x6 Model=3D0x1a = Stepping=3D5 >> = Features=3D0xbfebfbff >> = Features2=3D0x9ce3bd >> AMD Features=3D0x28100800 >> AMD Features2=3D0x1 >> VT-x: PAT,HLT,MTF,PAUSE,EPT,VPID >> TSC: P-state invariant, performance statistics >> real memory =3D 25769803776 (24576 MB) >> avail memory =3D 24931561472 (23776 MB) >> Event timer "LAPIC" quality 100 >> ACPI APIC Table: >> FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs >> FreeBSD/SMP: 2 package(s) x 4 core(s) >> ioapic1: Changing APIC ID to 1 >> ioapic0 irqs 0-23 on motherboard >> ioapic1 irqs 32-55 on motherboard >>=20 >>=20 >> Fatal trap 12: page fault while in kernel mode >> cpuid =3D 0; apic id =3D 10 >> fault virtual address =3D 0x1818 >> fault code =3D supervisor write data, page not present >> instruction pointer =3D 0x20:0xffffffff80ad427f >> stack pointer =3D 0x28:0xffffffff822e3be0 >> frame pointer =3D 0x28:0xffffffff822e3c30 >> code segment =3D base 0x0, limit 0xfffff, type 0x1b >> =3D DPL 0, pres 1, long 1, def32 0, gran 1 >> processor eflags =3D interrupt enabled, resume, IOPL =3D 0 >> current process =3D 0 (swapper) >> [ thread pid 0 tid 100000 ] >> Stopped at taskqgroup_attach_cpu+0x4f: lock cmpxchgq = %r12,(%rdi) >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to = "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@freebsd.org Sat Feb 3 09:37:48 2018 Return-Path: Delivered-To: freebsd-stable@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 305A0ED2045 for ; Sat, 3 Feb 2018 09:37:48 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [88.99.82.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B675C7E2D8; Sat, 3 Feb 2018 09:37:47 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [62.141.128.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 3AC1E26009E; Sat, 3 Feb 2018 10:37:40 +0100 (CET) Subject: Re: panic when loading mlxen To: Daniel Braniss , "K. Macy" Cc: freebsd-stable References: <83F78F7E-4DC2-41F5-837A-CB728D67B1E3@cs.huji.ac.il> <0D15BA02-5E39-4E04-84E1-3BF6D62065C1@cs.huji.ac.il> From: Hans Petter Selasky Message-ID: <673e43f8-4cc8-5c66-86f3-6b9dfd6b4a76@selasky.org> Date: Sat, 3 Feb 2018 10:34:46 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <0D15BA02-5E39-4E04-84E1-3BF6D62065C1@cs.huji.ac.il> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Feb 2018 09:37:48 -0000 On 02/03/18 08:34, Daniel Braniss wrote: > > >> On 2 Feb 2018, at 20:47, K. Macy wrote: >> >> That's odd since it doesn't use any of taskqgroup stuff. I take it you >> can't get a core? > > no core but some more info: > db> bt > Tracing pid 0 tid 100000 td 0xffffffff81e0e500 > taskqgroup_attach_cpu() at taskqgroup_attach_cpu+0x4f/frame 0xffffffff822e4c30 > tasklet_subsystem_init() at tasklet_subsystem_init+0xde/frame 0xffffffff822e4c90 > mi_startup() at mi_startup+0x9c/frame 0xffffffff822e4cb0 > btext() at btext+0x2c > >> >> Also, why are you loading it in loader.conf (slower) as opposed to rc.conf? > sometimes it’s booted diskless, and the driver is needed early. > and btw, this box doesn’t even have a mellanox card. > > >> -M >> >> >> >> On Fri, Feb 2, 2018 at 4:46 AM, Daniel Braniss wrote: >>> with latest stable (r328769) when I have >>> mlxen_load=“YES” >>> in my loader.conf it panics: >>> >>> KDB: debugger backends: ddbsize 0x4638 at 0x22d6000 f >>> KDB: current backend: ddb >>> Copyright (c) 1992-2018 The FreeBSD Project. >>> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 >>> The Regents of the University of California. All rights reserved. >>> FreeBSD is a registered trademark of The FreeBSD Foundation. >>> FreeBSD 11.1-STABLE #18: Fri Feb 2 10:46:12 IST 2018 >>> danny@pe-44:/home/obj/pe-44/net/rnd/r+d/stable/11/sys/HUJI amd64 >>> FreeBSD clang version 5.0.1 (tags/RELEASE_501/final 320880) (based on LLVM 5.0.1) >>> VT(vga): resolution 640x480 >>> CPU: Intel(R) Xeon(R) CPU E5507 @ 2.27GHz (2261.04-MHz K8-class CPU) >>> Origin="GenuineIntel" Id=0x106a5 Family=0x6 Model=0x1a Stepping=5 >>> Features=0xbfebfbff >>> Features2=0x9ce3bd >>> AMD Features=0x28100800 >>> AMD Features2=0x1 >>> VT-x: PAT,HLT,MTF,PAUSE,EPT,VPID >>> TSC: P-state invariant, performance statistics >>> real memory = 25769803776 (24576 MB) >>> avail memory = 24931561472 (23776 MB) >>> Event timer "LAPIC" quality 100 >>> ACPI APIC Table: >>> FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs >>> FreeBSD/SMP: 2 package(s) x 4 core(s) >>> ioapic1: Changing APIC ID to 1 >>> ioapic0 irqs 0-23 on motherboard >>> ioapic1 irqs 32-55 on motherboard >>> >>> >>> Fatal trap 12: page fault while in kernel mode >>> cpuid = 0; apic id = 10 >>> fault virtual address = 0x1818 >>> fault code = supervisor write data, page not present >>> instruction pointer = 0x20:0xffffffff80ad427f >>> stack pointer = 0x28:0xffffffff822e3be0 >>> frame pointer = 0x28:0xffffffff822e3c30 >>> code segment = base 0x0, limit 0xfffff, type 0x1b >>> = DPL 0, pres 1, long 1, def32 0, gran 1 >>> processor eflags = interrupt enabled, resume, IOPL = 0 >>> current process = 0 (swapper) >>> [ thread pid 0 tid 100000 ] >>> Stopped at taskqgroup_attach_cpu+0x4f: lock cmpxchgq %r12,(%rdi) Hi, It should work if you "kldload mlxen" after boot or add it to kld_list in /etc/rc.conf. Looks like I have one more combination to test after the LinuxKPI upgrade in 11-stable. Thanks for notifying me. --HPS From owner-freebsd-stable@freebsd.org Sat Feb 3 09:49:27 2018 Return-Path: Delivered-To: freebsd-stable@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 DD799ED3734 for ; Sat, 3 Feb 2018 09:49:26 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 534D57ED6E; Sat, 3 Feb 2018 09:49:26 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from imac.bk.cs.huji.ac.il ([132.65.179.42]) by kabab.cs.huji.ac.il with esmtp id 1ehuRl-000LOW-J5; Sat, 03 Feb 2018 11:49:21 +0200 From: Daniel Braniss Message-Id: <379899AB-07D0-4CFC-8490-6D9146E736AC@cs.huji.ac.il> Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: panic when loading mlxen Date: Sat, 3 Feb 2018 11:49:21 +0200 In-Reply-To: <673e43f8-4cc8-5c66-86f3-6b9dfd6b4a76@selasky.org> Cc: "K. Macy" , freebsd-stable To: Hans Petter Selasky References: <83F78F7E-4DC2-41F5-837A-CB728D67B1E3@cs.huji.ac.il> <0D15BA02-5E39-4E04-84E1-3BF6D62065C1@cs.huji.ac.il> <673e43f8-4cc8-5c66-86f3-6b9dfd6b4a76@selasky.org> X-Mailer: Apple Mail (2.3445.5.20) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Feb 2018 09:49:27 -0000 > On 3 Feb 2018, at 11:34, Hans Petter Selasky wrote: >=20 > On 02/03/18 08:34, Daniel Braniss wrote: >>> On 2 Feb 2018, at 20:47, K. Macy wrote: >>>=20 >>> That's odd since it doesn't use any of taskqgroup stuff. I take it = you >>> can't get a core? >> no core but some more info: >> db> bt >> Tracing pid 0 tid 100000 td 0xffffffff81e0e500 >> taskqgroup_attach_cpu() at taskqgroup_attach_cpu+0x4f/frame = 0xffffffff822e4c30 >> tasklet_subsystem_init() at tasklet_subsystem_init+0xde/frame = 0xffffffff822e4c90 >> mi_startup() at mi_startup+0x9c/frame 0xffffffff822e4cb0 >> btext() at btext+0x2c >>>=20 >>> Also, why are you loading it in loader.conf (slower) as opposed to = rc.conf? >> sometimes it=E2=80=99s booted diskless, and the driver is needed = early. >> and btw, this box doesn=E2=80=99t even have a mellanox card. >>> -M >>>=20 >>>=20 >>>=20 >>> On Fri, Feb 2, 2018 at 4:46 AM, Daniel Braniss = wrote: >>>> with latest stable (r328769) when I have >>>> mlxen_load=3D=E2=80=9CYES=E2=80=9D >>>> in my loader.conf it panics: >>>>=20 >>>> KDB: debugger backends: ddbsize 0x4638 at 0x22d6000 = f >>>> KDB: current backend: ddb >>>> Copyright (c) 1992-2018 The FreeBSD Project. >>>> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, = 1994 >>>> The Regents of the University of California. All rights = reserved. >>>> FreeBSD is a registered trademark of The FreeBSD Foundation. >>>> FreeBSD 11.1-STABLE #18: Fri Feb 2 10:46:12 IST 2018 >>>> danny@pe-44:/home/obj/pe-44/net/rnd/r+d/stable/11/sys/HUJI amd64 >>>> FreeBSD clang version 5.0.1 (tags/RELEASE_501/final 320880) (based = on LLVM 5.0.1) >>>> VT(vga): resolution 640x480 >>>> CPU: Intel(R) Xeon(R) CPU E5507 @ 2.27GHz (2261.04-MHz = K8-class CPU) >>>> Origin=3D"GenuineIntel" Id=3D0x106a5 Family=3D0x6 Model=3D0x1a = Stepping=3D5 >>>> = Features=3D0xbfebfbff >>>> = Features2=3D0x9ce3bd >>>> AMD Features=3D0x28100800 >>>> AMD Features2=3D0x1 >>>> VT-x: PAT,HLT,MTF,PAUSE,EPT,VPID >>>> TSC: P-state invariant, performance statistics >>>> real memory =3D 25769803776 (24576 MB) >>>> avail memory =3D 24931561472 (23776 MB) >>>> Event timer "LAPIC" quality 100 >>>> ACPI APIC Table: >>>> FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs >>>> FreeBSD/SMP: 2 package(s) x 4 core(s) >>>> ioapic1: Changing APIC ID to 1 >>>> ioapic0 irqs 0-23 on motherboard >>>> ioapic1 irqs 32-55 on motherboard >>>>=20 >>>>=20 >>>> Fatal trap 12: page fault while in kernel mode >>>> cpuid =3D 0; apic id =3D 10 >>>> fault virtual address =3D 0x1818 >>>> fault code =3D supervisor write data, page not present >>>> instruction pointer =3D 0x20:0xffffffff80ad427f >>>> stack pointer =3D 0x28:0xffffffff822e3be0 >>>> frame pointer =3D 0x28:0xffffffff822e3c30 >>>> code segment =3D base 0x0, limit 0xfffff, type 0x1b >>>> =3D DPL 0, pres 1, long 1, def32 0, gran 1 >>>> processor eflags =3D interrupt enabled, resume, IOPL =3D 0 >>>> current process =3D 0 (swapper) >>>> [ thread pid 0 tid 100000 ] >>>> Stopped at taskqgroup_attach_cpu+0x4f: lock cmpxchgq = %r12,(%rdi) >=20 > Hi, >=20 > It should work if you "kldload mlxen" after boot or add it to kld_list = in /etc/rc.conf. Looks like I have one more combination to test after = the LinuxKPI upgrade in 11-stable. Thanks for notifying me. >=20 Hi, it=E2=80=99s ok, i don=E2=80=99t need it yet, I was just surprised that = a simple upgrade got the panic. let me know if you need me to test. thanks, danny From owner-freebsd-stable@freebsd.org Sat Feb 3 10:19:30 2018 Return-Path: Delivered-To: freebsd-stable@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 266F4ED7287 for ; Sat, 3 Feb 2018 10:19:30 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [88.99.82.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BA7D27FFF4; Sat, 3 Feb 2018 10:19:29 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [62.141.128.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 5F35526009E; Sat, 3 Feb 2018 11:19:28 +0100 (CET) Subject: Re: panic when loading mlxen To: Daniel Braniss Cc: "K. Macy" , freebsd-stable References: <83F78F7E-4DC2-41F5-837A-CB728D67B1E3@cs.huji.ac.il> <0D15BA02-5E39-4E04-84E1-3BF6D62065C1@cs.huji.ac.il> <673e43f8-4cc8-5c66-86f3-6b9dfd6b4a76@selasky.org> <379899AB-07D0-4CFC-8490-6D9146E736AC@cs.huji.ac.il> From: Hans Petter Selasky Message-ID: <394efefe-2c09-eb97-6f75-5b408cda102f@selasky.org> Date: Sat, 3 Feb 2018 11:16:35 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <379899AB-07D0-4CFC-8490-6D9146E736AC@cs.huji.ac.il> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Feb 2018 10:19:30 -0000 Hi, I think Alexander came ahead of me: https://svnweb.freebsd.org/base?view=revision&revision=328805 Can you try r328805 ? --HPS From owner-freebsd-stable@freebsd.org Sat Feb 3 11:41:53 2018 Return-Path: Delivered-To: freebsd-stable@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 150D8EDEA69 for ; Sat, 3 Feb 2018 11:41:53 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9BFC784067; Sat, 3 Feb 2018 11:41:52 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from imac.bk.cs.huji.ac.il ([132.65.179.42]) by kabab.cs.huji.ac.il with esmtp id 1ehwCZ-0005SC-9C; Sat, 03 Feb 2018 13:41:47 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: panic when loading mlxen From: Daniel Braniss In-Reply-To: <394efefe-2c09-eb97-6f75-5b408cda102f@selasky.org> Date: Sat, 3 Feb 2018 13:41:47 +0200 Cc: "K. Macy" , freebsd-stable Content-Transfer-Encoding: quoted-printable Message-Id: References: <83F78F7E-4DC2-41F5-837A-CB728D67B1E3@cs.huji.ac.il> <0D15BA02-5E39-4E04-84E1-3BF6D62065C1@cs.huji.ac.il> <673e43f8-4cc8-5c66-86f3-6b9dfd6b4a76@selasky.org> <379899AB-07D0-4CFC-8490-6D9146E736AC@cs.huji.ac.il> <394efefe-2c09-eb97-6f75-5b408cda102f@selasky.org> To: Hans Petter Selasky X-Mailer: Apple Mail (2.3445.5.20) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Feb 2018 11:41:53 -0000 > On 3 Feb 2018, at 12:16, Hans Petter Selasky wrote: >=20 > Hi, >=20 > I think Alexander came ahead of me: >=20 > https://svnweb.freebsd.org/base?view=3Drevision&revision=3D328805 >=20 > Can you try r328805 ? >=20 > --HPS yup, it works, well it doesn=E2=80=99t panic. thanks danny From owner-freebsd-stable@freebsd.org Sat Feb 3 21:14:27 2018 Return-Path: Delivered-To: freebsd-stable@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 02B7DEED3CA for ; Sat, 3 Feb 2018 21:14:26 +0000 (UTC) (envelope-from mvoorhis@mcvau.net) Received: from atom.mcvau.net (2600-6c64-627f-e4f4-5054-00ff-fe0a-d781.dhcp6.chtrptr.net [IPv6:2600:6c64:627f:e4f4:5054:ff:fe0a:d781]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "atomvm.mcvau.net", Issuer "atomvm.mcvau.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 91B437B636 for ; Sat, 3 Feb 2018 21:14:26 +0000 (UTC) (envelope-from mvoorhis@mcvau.net) Received: from [192.168.2.66] (mcvx1c.mcvau.net [192.168.2.66]) (authenticated bits=0) by atom.mcvau.net (8.15.2/8.15.2) with ESMTPSA id w13LE2iX007721 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sat, 3 Feb 2018 16:14:25 -0500 (EST) (envelope-from mvoorhis@mcvau.net) Cc: mvoorhis@mcvau.net From: Michael Voorhis Subject: 50 percent swap used, but "ps auxww" output shows no processes swapped out To: freebsd-stable@freebsd.org Message-ID: Date: Sat, 3 Feb 2018 16:14:02 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=1.8 required=5.0 tests=ALL_TRUSTED,BAYES_50, RATWR8_MESSID, T_RP_MATCHES_RCVD autolearn=no autolearn_force=no version=3.4.1 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on atom.mcvau.net X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Feb 2018 21:14:27 -0000 Hi all, I've got an amd64 system running 11.1-STABLE r325027, with something like 20G of swap. "swapinfo" shows that half the swap is used. So of course I'm curious to know which processes have been swapped out. I'm not using any "tmpfs" filesystems; no ZFS, no huge amounts of wired-down memory. The system's got 16 processors and 128G of RAM. "ps auxww" output shows *no* processes that are swapped out (2nd character in "STAT" field is "W"). Not a single one. The only process with a W in the stat field at all is the "[intr]" kernel thread. What is using the swapspace? Please educate me. Thanks, --MCV. From owner-freebsd-stable@freebsd.org Sat Feb 3 21:18:53 2018 Return-Path: Delivered-To: freebsd-stable@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 172B0EED895 for ; Sat, 3 Feb 2018 21:18:53 +0000 (UTC) (envelope-from allbery.b@gmail.com) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A4F927B92F for ; Sat, 3 Feb 2018 21:18:52 +0000 (UTC) (envelope-from allbery.b@gmail.com) Received: by mail-qt0-x234.google.com with SMTP id c2so35209919qtn.9 for ; Sat, 03 Feb 2018 13:18:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=kUeMN3bwduJF30x6mfOJ3bXTj0Ywu/Wh1VX241BKxuo=; b=Bc1ptP5xUX6yVSp12519PSuTkg4Vtd6mf/JCgqYs37eqB2GNvuS5jJ8Smgaad1WU23 Xempj+JFvpD3kKhnFHRJStdtJzgqt4Czre+oMGDl0+TInTY2d6WLdg51DgLqFG4y0A0j SutIgq1G6jmvASDuQfQs6YXbln6YcNpuVHlxrD5CPoIfEwIzDn3xoHI3PUGKg3f59a3T s+sQmhmaMNwnSceieGhsxLW9VR9A5cNqqi6axbgXQ6CKAiqmBlHhAm5gA0R2Z14rBo2N DHYRjUbi8cJaJZz03rypd18uDaZw/Bnjoo2aUZuMQUUbrJBdww+znC8sSS+d9Qol5qNe 7qXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=kUeMN3bwduJF30x6mfOJ3bXTj0Ywu/Wh1VX241BKxuo=; b=kjIYul5ick6HZJ9kaMNZ92bd3QMXdvNlwRVU6BUMCIn3r2kxTeteAkTnqA1CbEe40y rOjMaWo5YupP5z9e7Jw9p3jJhGapT0fN3wb53v5nG/fvNUe7QW2ydKxWiqfGkoLqd88j 8tsUrDpr/PrHhJnv9Z88UE/+Dbv9X2WP+qdLa/UnecP4RPS08S/L9AHnfwv83rSGPK8d pkoo1NsjpQl+SbVxiLzXIiwuEDOXGS/g/CqtU3HtcCmLdfypUjRd6gOdXZPi41GTx6aq 7UHEzNoYgHjPJjPyF4JKFNO9qixopzrwvUSViQAG/LE/PMHkqKhjJQ64QntZluLH1xVJ lG1w== X-Gm-Message-State: AKwxytfagrOJft0HGDqM/JK8/VgEmHxcuAmQXmdhXQDPDSj+nBdfqKEC MfLfiSmcPB8sJAo1W0uoT2BOBHor9rsJs5x5Qe8= X-Google-Smtp-Source: AH8x225R9tWG4UkT7V6EkZoVzrl3uMA7qaaEIFEYqPRm799Ab/3HVpuzek4BN5SUByvLhZYz4wWce8A5/gRAzZzqcMk= X-Received: by 10.200.59.65 with SMTP id r1mr26785817qtf.18.1517692732201; Sat, 03 Feb 2018 13:18:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.36.185 with HTTP; Sat, 3 Feb 2018 13:18:51 -0800 (PST) In-Reply-To: References: From: Brandon Allbery Date: Sat, 3 Feb 2018 16:18:51 -0500 Message-ID: Subject: Re: 50 percent swap used, but "ps auxww" output shows no processes swapped out To: Michael Voorhis Cc: freebsd-stable Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Feb 2018 21:18:53 -0000 Swapping whole processes out is not really a thing any more. Individual pages are paged to/from memory; if a memory page has no backing file, it will be allocated a block in swap space as its backing storage. (I'm not sure "W" status even means swap; I thought whole-process swapping wasn't even supported any more.) On Sat, Feb 3, 2018 at 4:14 PM, Michael Voorhis wrote: > Hi all, > > I've got an amd64 system running 11.1-STABLE r325027, with something > like 20G of swap. "swapinfo" shows that half the swap is used. > > So of course I'm curious to know which processes have been swapped > out. I'm not using any "tmpfs" filesystems; no ZFS, no huge amounts of > wired-down memory. The system's got 16 processors and 128G of RAM. "ps > auxww" output shows *no* processes that are swapped out (2nd character > in "STAT" field is "W"). Not a single one. The only process with a W in > the stat field at all is the "[intr]" kernel thread. > > What is using the swapspace? > > Please educate me. > > Thanks, > > --MCV. > _______________________________________________ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net From owner-freebsd-stable@freebsd.org Sat Feb 3 21:54:31 2018 Return-Path: Delivered-To: freebsd-stable@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 56B61EEFBAD for ; Sat, 3 Feb 2018 21:54:31 +0000 (UTC) (envelope-from mvoorhis@mcvau.net) Received: from atom.mcvau.net (2600-6c64-627f-e4f4-5054-00ff-fe0a-d781.dhcp6.chtrptr.net [IPv6:2600:6c64:627f:e4f4:5054:ff:fe0a:d781]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "atomvm.mcvau.net", Issuer "atomvm.mcvau.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id DBA817CE26 for ; Sat, 3 Feb 2018 21:54:30 +0000 (UTC) (envelope-from mvoorhis@mcvau.net) Received: from [192.168.2.66] (mcvx1c.mcvau.net [192.168.2.66]) (authenticated bits=0) by atom.mcvau.net (8.15.2/8.15.2) with ESMTPSA id w13LsN1P090631 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Sat, 3 Feb 2018 16:54:25 -0500 (EST) (envelope-from mvoorhis@mcvau.net) Cc: freebsd-stable Subject: Re: 50 percent swap used, but "ps auxww" output shows no processes swapped out References: From: Michael Voorhis Message-ID: <0ab4cffd-fad4-3a54-e8bd-559ffbca9a9d@mcvau.net> Date: Sat, 3 Feb 2018 16:54:23 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=2.8 required=5.0 tests=ALL_TRUSTED,BAYES_50, MISSING_HEADERS,RATWR8_MESSID,T_RP_MATCHES_RCVD autolearn=no autolearn_force=no version=3.4.1 X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on atom.mcvau.net X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Feb 2018 21:54:31 -0000 On 02/03/2018 04:18 PM, Brandon Allbery wrote: > Swapping whole processes out is not really a thing any more. > Individual pages are paged to/from memory; if a memory page has no > backing file, it will be allocated a block in swap space as its > backing storage. Is there a method to determine what swap contents are connected to, if looking at processes is no longer "a thing"? I have great confidence in the wonderful FreeBSD documentation, but I find nothing (quickly) in the manual pages. > (I'm not sure "W" status even means swap; I thought whole-process > swapping wasn't even supported any more.) The manpage for ps(1), (which I'm sure you're aware of!) describes the "state" field and its multiple characters and their meanings... that's what I used for reference. "W" as 1st character means "idle interrupt thread [of the kernel]." Subsequent W characters imply swapped-out processes. In subsequent characters a W indicates that a PID is swapped out. Thanks for your reply, --MCV. From owner-freebsd-stable@freebsd.org Sat Feb 3 22:02:18 2018 Return-Path: Delivered-To: freebsd-stable@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 CC27EEF03D2 for ; Sat, 3 Feb 2018 22:02:18 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [78.47.246.247]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4E51B7D4CE for ; Sat, 3 Feb 2018 22:02:17 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id w13M24Td029593 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 3 Feb 2018 23:02:05 +0100 (CET) (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: allbery.b@gmail.com Received: from [10.58.0.4] ([10.58.0.4]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id w13M20DP020247 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 4 Feb 2018 05:02:00 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: 50 percent swap used, but "ps auxww" output shows no processes swapped out To: Brandon Allbery , Michael Voorhis References: Cc: freebsd-stable From: Eugene Grosbein Message-ID: <5A763153.8000406@grosbein.net> Date: Sun, 4 Feb 2018 05:01:55 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=2.2 required=5.0 tests=BAYES_00, LOCAL_FROM, RDNS_NONE autolearn=no autolearn_force=no version=3.4.1 X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 1.9 RDNS_NONE Delivered to internal network by a host with no rDNS * 2.6 LOCAL_FROM From my domains X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on hz.grosbein.net X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Feb 2018 22:02:19 -0000 04.02.2018 4:18, Brandon Allbery wrote: > (I'm not sure "W" status even means swap; I thought whole-process swapping > wasn't even supported any more.) Kernel may decide to swap out entire processes if vm.swap_enabled=1 (default) and its free page pool heavily stressed or system was configured by administrator to swap out idle processes proactively using vm.swap_idle_enabled=1 (not default). From owner-freebsd-stable@freebsd.org Sat Feb 3 22:09:59 2018 Return-Path: Delivered-To: freebsd-stable@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 42DBBEF0BC6 for ; Sat, 3 Feb 2018 22:09:59 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) Received: from sonic305-4.consmr.mail.bf2.yahoo.com (sonic305-4.consmr.mail.bf2.yahoo.com [74.6.133.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E0E8E7D931 for ; Sat, 3 Feb 2018 22:09:58 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) X-YMail-OSG: 6p.RC9MVM1mgRPWuT.49vRpoGLxxE.auwmlVTx9rE4BK0sUpkOBqTDSu81yoKCM HI0MGxgyUVYMFp3TcoRYjoDOwS3b.gFDBFgohHQV9c2Fx6UasNW1BIQ6eDVMH6NLIsjVIn8TrnPF Pxkb0G5bmt2fR8h9e2CrDagNpJylhGxLQR9EpZoIvmh6gu5FkcJEwccvUlZkYwkR591CGFTzbrE4 vqJBETplXikIwJtojnYEScTbC1mtkg55xXhQjh1KwO6bSREou50Vh.80TKORnmLFh7zLvcaUWynD RrOCuWoTj8q99SZPaiILYsyX4S4PnAB8oACk0BOVNh.vN.9DerF_8L_bYil9LTI9p52t8H11vFor W_X.KOnUOUsniwI.Eh1MSdIe64_KU_brLp1obwtUy62RCSZGwnXWUVgLm8g9bzZ3l25oAkFeqt3T t8y99ZdctZ0lAtG8SokeKW_iC3A7UhZ1pgddxEf3DluSuCFWryj.34jGzcIWABy62eKPR Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.bf2.yahoo.com with HTTP; Sat, 3 Feb 2018 22:09:58 +0000 Received: from smtpgate102.mail.bf1.yahoo.com (EHLO [192.168.1.25]) ([72.30.28.113]) by smtp405.mail.bf1.yahoo.com (JAMES SMTP Server ) with ESMTPA ID 35e4c7477b0057b032515b55c84ba93b for ; Sat, 03 Feb 2018 22:09:54 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: 50 percent swap used, but "ps auxww" output shows no processes swapped out Message-Id: <4AF9AE33-887E-43F3-8885-B8EF37185407@yahoo.com> Date: Sat, 3 Feb 2018 14:09:53 -0800 To: FreeBSD-STABLE Mailing List X-Mailer: Apple Mail (2.3445.5.20) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Feb 2018 22:09:59 -0000 Brandon Allbery allbery.b at gmail.com wrote on Sat Feb 3 21:18:53 UTC 2018 : > Swapping whole processes out is not really a thing any more. = Individual > pages are paged to/from memory; if a memory page has no backing file, = it > will be allocated a block in swap space as its backing storage. >=20 > (I'm not sure "W" status even means swap; I thought whole-process = swapping > wasn't even supported any more.) =46rom what I've seen on the lists there is a technical distinction made between "kernel stacks for the process no longer memory resident" (swapped out) and other pages for the process having paged to disk and not being resident. But many tools do not seem to present that point of view and still reflect an older view in the terminology used, including in documentation. One has to interpret what one is shown as I understand. As an example, top can show RES being zero despite the kernel stacks for the process not having been moved to disk. RES zero might not mean what one might expect about "swapped out". I do not know if a W after the first letter in state (STAT) for "ps auxww" track the kernel-stacks' resident-vs-not status for the process or not. (Matching your not sure status.) > On Sat, Feb 3, 2018 at 4:14 PM, Michael Voorhis wrote: >=20 > > Hi all, > > > > I've got an amd64 system running 11.1-STABLE r325027, with something > > like 20G of swap. "swapinfo" shows that half the swap is used. > > > > So of course I'm curious to know which processes have been swapped > > out. I'm not using any "tmpfs" filesystems; no ZFS, no huge amounts = of > > wired-down memory. The system's got 16 processors and 128G of RAM. = "ps > > auxww" output shows *no* processes that are swapped out (2nd = character > > in "STAT" field is "W"). Not a single one. The only process with a W = in > > the stat field at all is the "[intr]" kernel thread. > > > > What is using the swapspace The so-called swapspace is really the paging/swap-space with most of the use being paging typically. (As Brandon indicated.) Once a page is paged out, if the process sticks around but does not use or free the page, the page likely stays paged-out. (I'm guessing some at the intended results for default tuning --and that you probably are using default tuning.) So the in-use swapspace is likely from one or more existing processes that did page-outs earlier. (Expect my descriptions to be over simplified, but hopefully pointing in the right general direction.) > > Please educate me. > > =3D=3D=3D Mark Millard marklmi at yahoo.com ( markmi at dsl-only.net is going away in 2018-Feb, late) From owner-freebsd-stable@freebsd.org Sat Feb 3 22:32:08 2018 Return-Path: Delivered-To: freebsd-stable@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 263A5EC876C for ; Sat, 3 Feb 2018 22:32:08 +0000 (UTC) (envelope-from allbery.b@gmail.com) Received: from mail-qt0-x243.google.com (mail-qt0-x243.google.com [IPv6:2607:f8b0:400d:c0d::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B4C2A7EAA7 for ; Sat, 3 Feb 2018 22:32:07 +0000 (UTC) (envelope-from allbery.b@gmail.com) Received: by mail-qt0-x243.google.com with SMTP id h4so7607660qtn.13 for ; Sat, 03 Feb 2018 14:32:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jA2cscF9zPYVzFtecx1mp80pK4ugnvcScCJQHog7qaY=; b=vKK95BDqALcdnzXfiy5EhclJ/3UMKNFRNkpEtxGArm/s4XgQN2pqqxdU9dzZuoRYt7 6voIzXTiR0WrQSktIAD59X6Lr7vI+tRITHGIKpI4hO4hcp95tFT5PCODbd1kl/seBLtD b3vqSdwaT8Xe7u26HH8yyFQQJV8qQhdsjds9rcqxtWcA9L7HG4ReAXf9QN0qwzrFMjRe F6RH/pzyvM37dCH2TthDt4gZ404/123GWv6ZoUTHitX9MSHR0W7rFhNCaIShuh7lgd60 fVXnJKtWFQqxLTk7fwX7AEQncHNW/yNoWvhML0l2q2urJuhHSXpuG0U578JOLvyTJbNZ tJuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jA2cscF9zPYVzFtecx1mp80pK4ugnvcScCJQHog7qaY=; b=nkAg2Gg6PC9xY1y+M4O7sHElnINjLCS6JLYM5j+tB+y0DNPF2Ga6Dcxo6o9IexhJE6 TL7SVD2TvBieHN4zEE30RWrwydVyUYIKrLlHKbectATa2KnIlttIiCQCJbDB6Jhy40u7 LKIYv7UXXR2iyPsLQNLbavY5QUz2Xmak60VY3et8eqtho7wAVVLyED2j7RhsMHxrNCpn 1ef4h7EQMWLHlhNdRaHq6vF4CCm4gB2mu+SA0tIcvOGW30NhcHSWGCEs79a1vMMhnLKu q5d/xwDHpi4SrWAiXwN9wen+4kWqFBODBiwZBEEgOlRikXIGwirmQNaFLhG39ihQ5l1G Pk8A== X-Gm-Message-State: AKwxytfmhgfAeVUbLv+9+4HpBuWB4VRvGrZZyobGgrBI78BS4ZOXv+vJ +3Rq+R/l+WuXl+v4ZBEOEqbH/rsNjmoQCC4L4/cr1A== X-Google-Smtp-Source: AH8x225PpmldZgV0rqJeBZAFEAAIfFE/kl3nxXC+I3UtAvtwc3f26unsf/pHzI6PVSkPsAQhZf6WBJREFXof0RH2ANQ= X-Received: by 10.200.40.73 with SMTP id 9mr25096650qtr.285.1517697127342; Sat, 03 Feb 2018 14:32:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.36.185 with HTTP; Sat, 3 Feb 2018 14:32:06 -0800 (PST) In-Reply-To: <4AF9AE33-887E-43F3-8885-B8EF37185407@yahoo.com> References: <4AF9AE33-887E-43F3-8885-B8EF37185407@yahoo.com> From: Brandon Allbery Date: Sat, 3 Feb 2018 17:32:06 -0500 Message-ID: Subject: Re: 50 percent swap used, but "ps auxww" output shows no processes swapped out To: Mark Millard Cc: FreeBSD-STABLE Mailing List Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Feb 2018 22:32:08 -0000 Also worth noting is that likely candidates for such pageouts include long-lived daemons that are only needed, or which only need certain pages, during startup/shutdown. So evicting only those pages to swap allows optimal use of memory that would otherwise be wasted unnecessarily. Studying demand paging and unified page management is worth the effort. Modern OSes, including Windows, make heavy use of this to optimize memory usage --- but it means that old-style notions of process memory usage will leave you wondering how the numbers make any sense. (I see this quite a lot; most people still seem to think the basic unit of memory management is a process, not a memory page, despite unified page management being over a decade old and basic demand paging going back to 4BSD days.) On Sat, Feb 3, 2018 at 5:09 PM, Mark Millard via freebsd-stable < freebsd-stable@freebsd.org> wrote: > Brandon Allbery allbery.b at gmail.com wrote on > Sat Feb 3 21:18:53 UTC 2018 : > > > Swapping whole processes out is not really a thing any more. Individual > > pages are paged to/from memory; if a memory page has no backing file, it > > will be allocated a block in swap space as its backing storage. > > > > (I'm not sure "W" status even means swap; I thought whole-process > swapping > > wasn't even supported any more.) > > From what I've seen on the lists there is a technical distinction > made between "kernel stacks for the process no longer memory resident" > (swapped out) and other pages for the process having paged to disk and > not being resident. > > But many tools do not seem to present that point of view and still > reflect an older view in the terminology used, including in > documentation. One has to interpret what one is shown as I understand. > > As an example, top can show RES being zero despite the kernel stacks > for the process not having been moved to disk. RES zero might not > mean what one might expect about "swapped out". > > I do not know if a W after the first letter in state (STAT) for > "ps auxww" track the kernel-stacks' resident-vs-not status for the > process or not. (Matching your not sure status.) > > > > On Sat, Feb 3, 2018 at 4:14 PM, Michael Voorhis > wrote: > > > > > Hi all, > > > > > > I've got an amd64 system running 11.1-STABLE r325027, with something > > > like 20G of swap. "swapinfo" shows that half the swap is used. > > > > > > So of course I'm curious to know which processes have been swapped > > > out. I'm not using any "tmpfs" filesystems; no ZFS, no huge amounts of > > > wired-down memory. The system's got 16 processors and 128G of RAM. "ps > > > auxww" output shows *no* processes that are swapped out (2nd character > > > in "STAT" field is "W"). Not a single one. The only process with a W in > > > the stat field at all is the "[intr]" kernel thread. > > > > > > What is using the swapspace > > The so-called swapspace is really the paging/swap-space with > most of the use being paging typically. (As Brandon indicated.) > > Once a page is paged out, if the process sticks around but > does not use or free the page, the page likely stays > paged-out. (I'm guessing some at the intended results for > default tuning --and that you probably are using default > tuning.) So the in-use swapspace is likely from one or > more existing processes that did page-outs earlier. > > (Expect my descriptions to be over simplified, but hopefully > pointing in the right general direction.) > > > > Please educate me. > > > > > > === > Mark Millard > marklmi at yahoo.com > ( markmi at dsl-only.net is > going away in 2018-Feb, late) > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net From owner-freebsd-stable@freebsd.org Sat Feb 3 22:38:23 2018 Return-Path: Delivered-To: freebsd-stable@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 9933CEC8FEB for ; Sat, 3 Feb 2018 22:38:23 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [78.47.246.247]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 1A16D7EF4B for ; Sat, 3 Feb 2018 22:38:22 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id w13McF1n029886 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 3 Feb 2018 23:38:15 +0100 (CET) (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: marklmi26-fbsd@yahoo.com Received: from [10.58.0.4] ([10.58.0.4]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id w13McCTt030504 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 4 Feb 2018 05:38:12 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: 50 percent swap used, but "ps auxww" output shows no processes swapped out To: Mark Millard , FreeBSD-STABLE Mailing List References: <4AF9AE33-887E-43F3-8885-B8EF37185407@yahoo.com> From: Eugene Grosbein Message-ID: <5A7639CE.1070103@grosbein.net> Date: Sun, 4 Feb 2018 05:38:06 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <4AF9AE33-887E-43F3-8885-B8EF37185407@yahoo.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=2.2 required=5.0 tests=BAYES_00, LOCAL_FROM, RDNS_NONE autolearn=no autolearn_force=no version=3.4.1 X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 1.9 RDNS_NONE Delivered to internal network by a host with no rDNS * 2.6 LOCAL_FROM From my domains X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on hz.grosbein.net X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Feb 2018 22:38:23 -0000 04.02.2018 5:09, Mark Millard via freebsd-stable wrote: > I do not know if a W after the first letter in state (STAT) for > "ps auxww" track the kernel-stacks' resident-vs-not status for the > process or not. (Matching your not sure status.) A process has specific flag P_INMEM that is normally 1 but is cleader by a kernel when "swapout" procedure is executed for a process. Such process cannot get CPU time etc. top shows process name like "" instead of just "name" in that case. From owner-freebsd-stable@freebsd.org Sat Feb 3 22:44:33 2018 Return-Path: Delivered-To: freebsd-stable@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 566E7EC99A1 for ; Sat, 3 Feb 2018 22:44:33 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [78.47.246.247]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C59317F5E2 for ; Sat, 3 Feb 2018 22:44:32 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id w13MiP1K029951 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 3 Feb 2018 23:44:26 +0100 (CET) (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: allbery.b@gmail.com Received: from [10.58.0.4] ([10.58.0.4]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id w13MiMN8032273 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 4 Feb 2018 05:44:22 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: 50 percent swap used, but "ps auxww" output shows no processes swapped out To: Brandon Allbery , Mark Millard References: <4AF9AE33-887E-43F3-8885-B8EF37185407@yahoo.com> Cc: FreeBSD-STABLE Mailing List From: Eugene Grosbein Message-ID: <5A763B41.2070700@grosbein.net> Date: Sun, 4 Feb 2018 05:44:17 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=2.2 required=5.0 tests=BAYES_00, LOCAL_FROM, RDNS_NONE autolearn=no autolearn_force=no version=3.4.1 X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 1.9 RDNS_NONE Delivered to internal network by a host with no rDNS * 2.6 LOCAL_FROM From my domains X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on hz.grosbein.net X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Feb 2018 22:44:33 -0000 04.02.2018 5:32, Brandon Allbery wrote: > Also worth noting is that likely candidates for such pageouts include > long-lived daemons that are only needed, or which only need certain pages, > during startup/shutdown. So evicting only those pages to swap allows > optimal use of memory that would otherwise be wasted unnecessarily. > > Studying demand paging and unified page management is worth the effort. > Modern OSes, including Windows, make heavy use of this to optimize memory > usage --- but it means that old-style notions of process memory usage will > leave you wondering how the numbers make any sense. (I see this quite a > lot; most people still seem to think the basic unit of memory management is > a process, not a memory page, despite unified page management being over a > decade old and basic demand paging going back to 4BSD days.) FreeBSD kernel does not try to "swapout" even long-lived sleeping daemons as a whole when it needs some free pages. Even if it needs to free more pages by paging out some of them, it tries to minimize such I/O operations by default and writes only minimal necessary amount of pages keeping the rest intact, when vm.swap_idle_enabled=0. From owner-freebsd-stable@freebsd.org Sat Feb 3 22:49:00 2018 Return-Path: Delivered-To: freebsd-stable@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 4885DEC9F6C for ; Sat, 3 Feb 2018 22:49:00 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [78.47.246.247]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C3C367F7E7 for ; Sat, 3 Feb 2018 22:48:59 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id w13MmrSc030030 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 3 Feb 2018 23:48:53 +0100 (CET) (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: mvoorhis@mcvau.net Received: from [10.58.0.4] ([10.58.0.4]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id w13MmjP6033529 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 4 Feb 2018 05:48:45 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: 50 percent swap used, but "ps auxww" output shows no processes swapped out To: Michael Voorhis , freebsd-stable@freebsd.org References: From: Eugene Grosbein Message-ID: <5A763C48.5020907@grosbein.net> Date: Sun, 4 Feb 2018 05:48:40 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=2.2 required=5.0 tests=BAYES_00, LOCAL_FROM, RDNS_NONE autolearn=no autolearn_force=no version=3.4.1 X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 1.9 RDNS_NONE Delivered to internal network by a host with no rDNS * 2.6 LOCAL_FROM From my domains X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on hz.grosbein.net X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Feb 2018 22:49:00 -0000 04.02.2018 4:14, Michael Voorhis wrote: > I've got an amd64 system running 11.1-STABLE r325027, with something > like 20G of swap. "swapinfo" shows that half the swap is used. > > So of course I'm curious to know which processes have been swapped > out. I'm not using any "tmpfs" filesystems; no ZFS, no huge amounts of > wired-down memory. The system's got 16 processors and 128G of RAM. "ps > auxww" output shows *no* processes that are swapped out (2nd character > in "STAT" field is "W"). Not a single one. The only process with a W in > the stat field at all is the "[intr]" kernel thread. > > What is using the swapspace? These 10G may be just several pages of several processes. Please show output of "top -ores -d1". From owner-freebsd-stable@freebsd.org Sat Feb 3 23:42:51 2018 Return-Path: Delivered-To: freebsd-stable@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 2384EED2822 for ; Sat, 3 Feb 2018 23:42:51 +0000 (UTC) (envelope-from mvoorhis@mcvau.net) Received: from atom.mcvau.net (2600-6c64-627f-e4f4-5054-00ff-fe0a-d781.dhcp6.chtrptr.net [IPv6:2600:6c64:627f:e4f4:5054:ff:fe0a:d781]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "atomvm.mcvau.net", Issuer "atomvm.mcvau.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A081881679 for ; Sat, 3 Feb 2018 23:42:50 +0000 (UTC) (envelope-from mvoorhis@mcvau.net) Received: from [192.168.2.66] (mcvx1c.mcvau.net [192.168.2.66]) (authenticated bits=0) by atom.mcvau.net (8.15.2/8.15.2) with ESMTPSA id w13Ngg3o087718 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sat, 3 Feb 2018 18:42:45 -0500 (EST) (envelope-from mvoorhis@mcvau.net) Cc: Michael C Voorhis Subject: Re: 50 percent swap used, but "ps auxww" output shows no processes swapped out To: freebsd-stable@freebsd.org References: <5A763C48.5020907@grosbein.net> From: Michael Voorhis Message-ID: <798bb18f-cdd6-f30a-5f21-832032a15d52@mcvau.net> Date: Sat, 3 Feb 2018 18:42:42 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <5A763C48.5020907@grosbein.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=1.1 required=5.0 tests=ALL_TRUSTED,BAYES_20, RATWR8_MESSID,TW_JS,TW_PG,T_RP_MATCHES_RCVD autolearn=no autolearn_force=no version=3.4.1 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on atom.mcvau.net X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Feb 2018 23:42:51 -0000 On 02/03/2018 05:48 PM, Eugene Grosbein wrote: > These 10G may be just several pages of several processes. > Please show output of "top -ores -d1". This just shows a bunch of hungry postgres processes (see below). In response to your slightly-earlier email, swap_enabled is set (its default) and swap_idle_enabled is NOT set. No swap-related sysctl's are set in /etc/sysctl.conf. 1 frame of your requested "top" output, sorted as specified: > last pid: 47195; load averages: 0.17, 0.37, 0.44 up 99+20:40:41 18:37:07 > 369 processes: 1 running, 368 sleeping > CPU: 0.2% user, 0.0% nice, 0.2% system, 0.0% interrupt, 99.7% idle > Mem: 6989M Active, 79G Inact, 27G Laundry, 10G Wired, 1568M Buf, 1680M Free > Swap: 21G Total, 11G Used, 10G Free, 50% Inuse > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND > 61839 pgsql 1 21 0 32665M 31349M select 13 3:13 0.00% postgres > 59354 pgsql 1 20 0 32659M 26625M select 12 288:57 0.00% postgres > 40354 pgsql 1 20 0 32660M 26182M select 12 220:15 0.00% postgres > 24708 pgsql 1 20 0 32659M 26144M select 3 204:14 0.00% postgres > 37664 pgsql 1 20 0 32649M 25967M select 12 48:55 0.00% postgres > 56094 pgsql 1 25 0 32659M 25734M select 5 189:00 0.00% postgres > 57255 pgsql 1 20 0 32661M 25414M select 6 143:53 0.00% postgres > 38662 pgsql 1 20 0 32659M 23669M select 1 229:03 0.00% postgres > 48035 pgsql 1 20 0 32663M 22195M select 3 149:13 0.00% postgres > 66831 pgsql 1 20 0 32659M 21944M select 2 61:00 0.13% postgres > 45832 pgsql 1 20 0 32659M 21427M select 4 158:26 0.00% postgres > 56976 pgsql 1 20 0 32661M 14110M select 1 56:26 0.00% postgres > 26207 pgsql 1 20 0 32659M 11620M select 8 34:21 0.00% postgres > 383 www 64 20 0 34010M 8860M nanslp 14 11:26 0.11% jsvc > 44067 pgsql 1 20 0 32659M 6194M select 11 15:16 0.00% postgres > 31431 pgsql 1 20 0 32661M 4928M select 15 15:41 0.00% postgres > 34641 pgsql 1 20 0 32650M 2383M select 14 2:04 0.00% postgres> [...]