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 <mike at sentex.net> 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 <nimrodl at gmail.com > >>> <mailto:nimrodl at gmail.com>> 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 <truckman at freebsd.org > >>> <mailto:truckman at freebsd.org>> 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 at freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > > To unsubscribe, send any mail to "freebsd-stable-unsubscribe at freebsd.org > " > > > > > > > -- > ------------------- > Mike Tancsa, tel +1 519 651 3400 <(519)%20651-3400> > Sentex Communications, mike at sentex.net > Providing Internet services since 1994 www.sentex.net > Cambridge, Ontario Canada http://www.tancsa.com/ > _______________________________________________ > freebsd-stable at freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe at freebsd.org" >-- -- Nimrod
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 <nimrodl at gmail.com> 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 <mike at sentex.net> 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 <nimrodl at gmail.com >> >>> <mailto:nimrodl at gmail.com>> 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 <truckman at freebsd.org >> >>> <mailto:truckman at freebsd.org>> 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 at freebsd.org mailing list >> > https://lists.freebsd.org/mailman/listinfo/freebsd-stable >> > To unsubscribe, send any mail to " >> freebsd-stable-unsubscribe at freebsd.org" >> > >> > >> >> >> -- >> ------------------- >> Mike Tancsa, tel +1 519 651 3400 <(519)%20651-3400> >> Sentex Communications, mike at sentex.net >> Providing Internet services since 1994 www.sentex.net >> Cambridge, Ontario Canada http://www.tancsa.com/ >> _______________________________________________ >> freebsd-stable at freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe at freebsd.org" >> > > > -- > > -- > Nimrod >-- -- Nimrod
Changing the memory speed from 2400 to 2133 in the BIOS has given me 4.5 days of uptime so far. The memory is supposed to be 2400. I'm still confused, but I'll accept the result On Fri, Jan 19, 2018 at 4:02 PM Nimrod Levy <nimrodl at gmail.com> 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 <mike at sentex.net> 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 <nimrodl at gmail.com >> >>> <mailto:nimrodl at gmail.com>> 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 <truckman at freebsd.org >> >>> <mailto:truckman at freebsd.org>> 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 at freebsd.org mailing list >> > https://lists.freebsd.org/mailman/listinfo/freebsd-stable >> > To unsubscribe, send any mail to " >> freebsd-stable-unsubscribe at freebsd.org" >> > >> > >> >> >> -- >> ------------------- >> Mike Tancsa, tel +1 519 651 3400 <(519)%20651-3400> >> Sentex Communications, mike at sentex.net >> Providing Internet services since 1994 www.sentex.net >> Cambridge, Ontario Canada http://www.tancsa.com/ >> _______________________________________________ >> freebsd-stable at freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe at freebsd.org" >> > > > -- > > -- > Nimrod >-- -- Nimrod