subject:"\[Bug 219399\] System panics after several hours of 14\-threads\-compilation orgies using poudriere on AMD Ryzen..."

[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

2022-01-30 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399

tomasjerrii  changed:

   What|Removed |Added

 CC||tomasjer...@gmail.com

--- Comment #295 from tomasjerrii  ---
https://www.brandsnbehind.com

Chennai's most trusted ad Agency & Digital Marketing Company. We are based in
Chennai & We provide a complete range of marketing & branding services.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

2021-06-29 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399

--- Comment #294 from SF  ---
Since 2017 i did find out that the cause of this seemed to be simply the
missing of an temperature sensor value: 60°C+ seemed to cause it to me.

My Ryzen could be surprisingly bug free since 2017, no need to buy a new one.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

2021-06-29 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399

karthikbsd  changed:

   What|Removed |Added

 CC||karthik.gan...@gmail.com

--- Comment #293 from karthikbsd  ---
EasemyGST is a cloud-based gst billing software for enterprises. It has a
complete tax management feature that helps in generating gst invoices and file
GST returns. This gst filing software enables efficient accounting and tax
management along with the below features.

https://www.infobrez.com/GST-software
https://www.infobrez.com/GST-software

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

2020-09-18 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399

Armaan Mitchell  changed:

   What|Removed |Added

 CC||nasreenbibi...@gmail.com

--- Comment #292 from Armaan Mitchell  ---
A commit references this bug:

Author: truckman
Date: Wed Aug  2 01:43:36 UTC 2017
New revision: 321899
URL: https://thecoachtrainingacademy.com

Log:
  Lower the amd64 shared page, which contains the signal trampoline,
  from the top of user memory to one page lower on machines with the
  Ryzen (AMD Family 17h) CPU.  This pushes ps_strings and the stack
  down by one page as well.  On Ryzen there is some sort of interaction
  between code running at the top of user memory address space and
  interrupts that can cause FreeBSD to either hang or silently reset.
  This sounds similar to the problem found with DragonFly BSD that
  was fixed with this commit:
   
https://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/b48dd28447fc8ef62fbc963accd301557fd9ac20
  but our signal trampoline location was already lower than the address
  that DragonFly moved their signal trampoline to.  It also does not
  appear to be related to SMT as described here:
   
https://www.phoronix.com/forums/forum/hardware/processors-memory/955368-some-ryzen-linux-users-are-facing-issues-with-heavy-compilation-loads?p=955498#post955498

"Hi, Matt Dillon here. Yes, I did find what I believe to be a
 hardware issue with Ryzen related to concurrent operations. In a
 nutshell, for any given hyperthread pair, if one hyperthread is
 in a cpu-bound loop of any kind (can be in user mode), and the
 other hyperthread is returning from an interrupt via IRETQ, the
 hyperthread issuing the IRETQ can stall indefinitely until the
 other hyperthread with the cpu-bound loop pauses (aka HLT until
 next interrupt). After this situation occurs, the system appears
 to destabilize. The situation does not occur if the cpu-bound
 loop is on a different core than the core doing the IRETQ. The
 %rip the IRETQ returns to (e.g. userland %rip address) matters a
 *LOT*. The problem occurs more often with high %rip addresses
 such as near the top of the user stack, which is where DragonFly's
 signal trampoline traditionally resides. So a user program taking
 a signal on one thread while another thread is cpu-bound can cause
 this behavior. Changing the location of the signal trampoline
 makes it more difficult to reproduce the problem. I have not
 been because the able to completely mitigate it. When a cpu-thread
 stalls in this manner it appears to stall INSIDE the microcode
 for IRETQ. It doesn't make it to the return pc, and the cpu thread
 cannot take any IPIs or other hardware interrupts while in this
 state."
  since the system instability has been observed on FreeBSD with SMT
  disabled.  Interrupts to appear to play a factor since running a
  signal-intensive process on the first CPU core, which handles most
  of the interrupts on my machine, is far more likely to trigger the
  problem than running such a process on any other core.

  Also lower sv_maxuser to prevent a malicious user from using mmap()
  to load and execute code in the top page of user memory that was made
  available when the shared page was moved down.

  Make the same changes to the 64-bit Linux emulator.

  PR:   219399
  Reported by:  n...@renzel.net
  Reviewed by:  kib
  Reviewed by:  dchagin (previous version)
  Tested by:n...@renzel.net (earlier version)
  MFC after:2 weeks
  Differential Revision:https://reviews.freebsd.org/D11780

Changes:
  head/sys/amd64/amd64/elf_machdep.c
  head/sys/amd64/amd64/initcpu.c
  head/sys/amd64/include/md_var.h
  head/sys/amd64/linux/linux_sysvec.c

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

2020-08-19 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399

Missa Jones  changed:

   What|Removed |Added

 CC||alinamah...@gmail.com

--- Comment #291 from Missa Jones  ---
root@asbach:/var/crash/#kgdb7121 /boot/kernel/kernel /var/crash/vmcore.3
GNU gdb (GDB) 7.12.1 [GDB v7.12.1 for FreeBSD]
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-portbld-freebsd11.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /boot/kernel/kernel...Reading symbols from
/usr/lib/debug//boot/kernel/kernel.debug...done.
done.
Reading symbols from /boot/kernel/kernel...Reading symbols from
/usr/lib/debug//boot/kernel/kernel.debug...done.
done.
Reading symbols from /boot/kernel/zfs.ko...Reading symbols from
/usr/lib/debug//boot/kernel/zfs.ko.debug...done.
done.
Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from
/usr/lib/debug//boot/kernel/opensolaris.ko.debug...done.
done.
Reading symbols from /boot/kernel/vmm.ko...Reading symbols from
/usr/lib/debug//boot/kernel/vmm.ko.debug...done.
done.
Reading symbols from /boot/kernel/ums.ko...Reading symbols from
/usr/lib/debug//boot/kernel/ums.ko.debug...done.
done.
Reading symbols from /boot/kernel/pflog.ko...Reading symbols from
/usr/lib/debug//boot/kernel/pflog.ko.debug...done.
done.
Reading symbols from /boot/kernel/pf.ko...Reading symbols from
/usr/lib/debug//boot/kernel/pf.ko.debug...done.
done.
Reading symbols from /boot/kernel/linux.ko...Reading symbols from
/usr/lib/debug//boot/kernel/linux.ko.debug...done.
done.
Reading symbols from /boot/kernel/linux_common.ko...Reading symbols from
/usr/lib/debug//boot/kernel/linux_common.ko.debug...done.
done.
Reading symbols from /boot/kernel/linux64.ko...Reading symbols from
/usr/lib/debug//boot/kernel/linux64.ko.debug...done.
done.
Reading symbols from /boot/modules/nvidia.ko...(no debugging symbols
found)...done.
Reading symbols from /boot/kernel/nullfs.ko...Reading symbols from
/usr/lib/debug//boot/kernel/nullfs.ko.debug...done.
done.
Reading symbols from /boot/kernel/linprocfs.ko...Reading symbols from
/usr/lib/debug//boot/kernel/linprocfs.ko.debug...done.
done.
Reading symbols from /boot/kernel/tmpfs.ko...Reading symbols from
/usr/lib/debug//boot/kernel/tmpfs.ko.debug...done.
done.
Reading symbols from /boot/kernel/fdescfs.ko...Reading symbols from
/usr/lib/debug//boot/kernel/fdescfs.ko.debug...done.
done.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

2020-08-12 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399

Richard Zilinski  changed:

   What|Removed |Added

 CC||armaangujja...@gmail.com

--- Comment #290 from Richard Zilinski  ---
root@asbach:/var/crash/#kgdb7121 /boot/kernel/kernel /var/crash/vmcore.3
GNU gdb (GDB) 7.12.1 [GDB v7.12.1 for FreeBSD]
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-portbld-freebsd11.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /boot/kernel/kernel...Reading symbols from
/usr/lib/debug//boot/kernel/kernel.debug...done.
done.
Reading symbols from /boot/kernel/kernel...Reading symbols from
/usr/lib/debug//boot/kernel/kernel.debug...done.
done.
Reading symbols from /boot/kernel/zfs.ko...Reading symbols from
/usr/lib/debug//boot/kernel/zfs.ko.debug...done.
done.
Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from
/usr/lib/debug//boot/kernel/opensolaris.ko.debug...done.
done.
Reading symbols from /boot/kernel/vmm.ko...Reading symbols from
/usr/lib/debug//boot/kernel/vmm.ko.debug...done.
done.
Reading symbols from /boot/kernel/ums.ko...Reading symbols from
/usr/lib/debug//boot/kernel/ums.ko.debug...done.
done.
Reading symbols from /boot/kernel/pflog.ko...Reading symbols from
/usr/lib/debug//boot/kernel/pflog.ko.debug...done.
done.
Reading symbols from /boot/kernel/pf.ko...Reading symbols from
/usr/lib/debug//boot/kernel/pf.ko.debug...done.
done.
Reading symbols from /boot/kernel/linux.ko...Reading symbols from
/usr/lib/debug//boot/kernel/linux.ko.debug...done.
done.
Reading symbols from /boot/kernel/linux_common.ko...Reading symbols from
/usr/lib/debug//boot/kernel/linux_common.ko.debug...done.
done.
Reading symbols from /boot/kernel/linux64.ko...Reading symbols from
/usr/lib/debug//boot/kernel/linux64.ko.debug...done.
done.
Reading symbols from /boot/modules/nvidia.ko...(no debugging symbols
found)...done.
Reading symbols from /boot/kernel/nullfs.ko...Reading symbols from
/usr/lib/debug//boot/kernel/nullfs.ko.debug...done.
done.
Reading symbols from /boot/kernel/linprocfs.ko...Reading symbols from
/usr/lib/debug//boot/kernel/linprocfs.ko.debug...done.
done.
Reading symbols from /boot/kernel/tmpfs.ko...Reading symbols from
/usr/lib/debug//boot/kernel/tmpfs.ko.debug...done.
done.
Reading symbols from /boot/kernel/fdescfs.ko...Reading symbols from
/usr/lib/debug//boot/kernel/fdescfs.ko.debug...done.
done.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

2020-07-31 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399

jerometaylor  changed:

   What|Removed |Added

 CC||romanmiller...@gmail.com

--- Comment #289 from jerometaylor  ---
root@asbach:/var/crash/#kgdb7121 /boot/kernel/kernel /var/crash/vmcore.3
GNU gdb (GDB) 7.12.1 [GDB v7.12.1 for FreeBSD]
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-portbld-freebsd11.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /boot/kernel/kernel...Reading symbols from
/usr/lib/debug//boot/kernel/kernel.debug...done.
done.
Reading symbols from /boot/kernel/kernel...Reading symbols from
/usr/lib/debug//boot/kernel/kernel.debug...done.
done.
Reading symbols from /boot/kernel/zfs.ko...Reading symbols from
/usr/lib/debug//boot/kernel/zfs.ko.debug...done.
done.
Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from
/usr/lib/debug//boot/kernel/opensolaris.ko.debug...done.
done.
Reading symbols from /boot/kernel/vmm.ko...Reading symbols from
/usr/lib/debug//boot/kernel/vmm.ko.debug...done.
done.
Reading symbols from /boot/kernel/ums.ko...Reading symbols from
/usr/lib/debug//boot/kernel/ums.ko.debug...done.
done.
Reading symbols from /boot/kernel/pflog.ko...Reading symbols from
/usr/lib/debug//boot/kernel/pflog.ko.debug...done.
done.
Reading symbols from /boot/kernel/pf.ko...Reading symbols from
/usr/lib/debug//boot/kernel/pf.ko.debug...done.
done.
Reading symbols from /boot/kernel/linux.ko...Reading symbols from
/usr/lib/debug//boot/kernel/linux.ko.debug...done.
done.
Reading symbols from /boot/kernel/linux_common.ko...Reading symbols from
/usr/lib/debug//boot/kernel/linux_common.ko.debug...done.
done.
Reading symbols from /boot/kernel/linux64.ko...Reading symbols from
/usr/lib/debug//boot/kernel/linux64.ko.debug...done.
done.
Reading symbols from /boot/modules/nvidia.ko...(no debugging symbols
found)...done.
Reading symbols from /boot/kernel/nullfs.ko...Reading symbols from
/usr/lib/debug//boot/kernel/nullfs.ko.debug...done.
done.
Reading symbols from /boot/kernel/linprocfs.ko...Reading symbols from
/usr/lib/debug//boot/kernel/linprocfs.ko.debug...done.
done.
Reading symbols from /boot/kernel/tmpfs.ko...Reading symbols from
/usr/lib/debug//boot/kernel/tmpfs.ko.debug...done.
done.
Reading symbols from /boot/kernel/fdescfs.ko...Reading symbols from
/usr/lib/debug//boot/kernel/fdescfs.ko.debug...done.
done.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

2020-07-30 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399

Mubashra Ameen  changed:

   What|Removed |Added

 CC||mubashraamee...@gmail.com

--- Comment #288 from Mubashra Ameen  ---
root@asbach:/var/crash/#kgdb7121 /boot/kernel/kernel /var/crash/vmcore.3
GNU gdb (GDB) 7.12.1 [GDB v7.12.1 for FreeBSD]
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-portbld-freebsd11.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /boot/kernel/kernel...Reading symbols from
/usr/lib/debug//boot/kernel/kernel.debug...done.
done.
Reading symbols from /boot/kernel/kernel...Reading symbols from
/usr/lib/debug//boot/kernel/kernel.debug...done.
done.
Reading symbols from /boot/kernel/zfs.ko...Reading symbols from
/usr/lib/debug//boot/kernel/zfs.ko.debug...done.
done.
Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from
/usr/lib/debug//boot/kernel/opensolaris.ko.debug...done.
done.
Reading symbols from /boot/kernel/vmm.ko...Reading symbols from
/usr/lib/debug//boot/kernel/vmm.ko.debug...done.
done.
Reading symbols from /boot/kernel/ums.ko...Reading symbols from
/usr/lib/debug//boot/kernel/ums.ko.debug...done.
done.
Reading symbols from /boot/kernel/pflog.ko...Reading symbols from
/usr/lib/debug//boot/kernel/pflog.ko.debug...done.
done.
Reading symbols from /boot/kernel/pf.ko...Reading symbols from
/usr/lib/debug//boot/kernel/pf.ko.debug...done.
done.
Reading symbols from /boot/kernel/linux.ko...Reading symbols from
/usr/lib/debug//boot/kernel/linux.ko.debug...done.
done.
Reading symbols from /boot/kernel/linux_common.ko...Reading symbols from
/usr/lib/debug//boot/kernel/linux_common.ko.debug...done.
done.
Reading symbols from /boot/kernel/linux64.ko...Reading symbols from
/usr/lib/debug//boot/kernel/linux64.ko.debug...done.
done.
Reading symbols from /boot/modules/nvidia.ko...(no debugging symbols
found)...done.
Reading symbols from /boot/kernel/nullfs.ko...Reading symbols from
/usr/lib/debug//boot/kernel/nullfs.ko.debug...done.
done.
Reading symbols from /boot/kernel/linprocfs.ko...Reading symbols from
/usr/lib/debug//boot/kernel/linprocfs.ko.debug...done.
done.
Reading symbols from /boot/kernel/tmpfs.ko...Reading symbols from
/usr/lib/debug//boot/kernel/tmpfs.ko.debug...done.
done.
Reading symbols from /boot/kernel/fdescfs.ko...Reading symbols from
/usr/lib/debug//boot/kernel/fdescfs.ko.debug...done.
done.
No thread selected.
(kgdb) info threads
No threads.


I'm using KDE all the time; and when the crash happens the screen garbles a
little bit, and after a while my system reboots - please give me some more time
to build a DDB-enabled kernel and switch to the VT console


when the crash happens the screen garbles a little bit, and after a while my
system reboots - please give me some more time to build a DDB-enabled kernel
and switch to the VT console

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

2020-06-01 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399

John  changed:

   What|Removed |Added

 CC||kabukimas...@gmail.com

--- Comment #287 from John  ---
root@asbach:/var/crash/#kgdb7121 /boot/kernel/kernel /var/crash/vmcore.3
GNU gdb (GDB) 7.12.1 [GDB v7.12.1 for FreeBSD]
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-portbld-freebsd11.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /boot/kernel/kernel...Reading symbols from
/usr/lib/debug//boot/kernel/kernel.debug...done.
done.
Reading symbols from /boot/kernel/kernel...Reading symbols from
/usr/lib/debug//boot/kernel/kernel.debug...done.
done.
Reading symbols from /boot/kernel/zfs.ko...Reading symbols from
/usr/lib/debug//boot/kernel/zfs.ko.debug...done.
done.
Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from
/usr/lib/debug//boot/kernel/opensolaris.ko.debug...done.
done.
Reading symbols from /boot/kernel/vmm.ko...Reading symbols from
/usr/lib/debug//boot/kernel/vmm.ko.debug...done.
done.
Reading symbols from /boot/kernel/ums.ko...Reading symbols from
/usr/lib/debug//boot/kernel/ums.ko.debug...done.
done.
Reading symbols from /boot/kernel/pflog.ko...Reading symbols from
/usr/lib/debug//boot/kernel/pflog.ko.debug...done.
done.
Reading symbols from /boot/kernel/pf.ko...Reading symbols from
/usr/lib/debug//boot/kernel/pf.ko.debug...done.
done.
Reading symbols from /boot/kernel/linux.ko...Reading symbols from
/usr/lib/debug//boot/kernel/linux.ko.debug...done.
done.
Reading symbols from /boot/kernel/linux_common.ko...Reading symbols from
/usr/lib/debug//boot/kernel/linux_common.ko.debug...done.
done.
Reading symbols from /boot/kernel/linux64.ko...Reading symbols from
/usr/lib/debug//boot/kernel/linux64.ko.debug...done.
done.
Reading symbols from /boot/modules/nvidia.ko...(no debugging symbols
found)...done.
Reading symbols from /boot/kernel/nullfs.ko...Reading symbols from
/usr/lib/debug//boot/kernel/nullfs.ko.debug...done.
done.
Reading symbols from /boot/kernel/linprocfs.ko...Reading symbols from
/usr/lib/debug//boot/kernel/linprocfs.ko.debug...done.
done.
Reading symbols from /boot/kernel/tmpfs.ko...Reading symbols from
/usr/lib/debug//boot/kernel/tmpfs.ko.debug...done.
done.
Reading symbols from /boot/kernel/fdescfs.ko...Reading symbols from
/usr/lib/debug//boot/kernel/fdescfs.ko.debug...done.
done.
No thread selected.
(kgdb) info threads
No threads.


I'm using KDE all the time; and when the crash happens the screen garbles a
little bit, and after a while my system reboots - please give me some more time
to build a DDB-enabled kernel and switch to the VT console


when the crash happens the screen garbles a little bit, and after a while my
system reboots - please give me some more time to build a DDB-enabled kernel
and switch to the VT console

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

2019-11-04 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399

--- Comment #286 from georgiadeeds  ---
Every morning is a charming celebration of the new freedom that life has to
offer. If you are in a positive structure of mind and today yourself with a
strong approach in the morning than you are expected to have a productive and
well-managed day.

Getting yourself into an animated and motivated state of mind in the morning
can have a deep shock on your life. The following quotes will not only give you
a Superb laugh but will also help you to start your day the right way.
More To Find good articles Visit https://quoteen.com/

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

2019-11-04 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399

georgiadeeds  changed:

   What|Removed |Added

 CC||georgiadee...@gmail.com

--- Comment #285 from georgiadeeds  ---
There are numerous sorts of issues, and not every one of them ought to incite
an issue report. Obviously, no one is perfect, and there will be times when
what seems to be a bug in a program is..
You can find Related info here...https://dapper.reviews/

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

2019-11-03 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399

Victor B. Kuntz  changed:

   What|Removed |Added

 CC||saamhoc...@gmail.com

--- Comment #284 from Victor B. Kuntz  ---
Thanks For Sharing i hope This type Of Post I Reach on You Web Page.




Regards:https://instapotbuy.com

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

2019-09-21 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399

Mark  changed:

   What|Removed |Added

 CC||siyal7...@gmail.com

--- Comment #283 from Mark  ---
Dear Team,
AMD eventually admitted that there is a "performance marginality" issue and has
been doing warranty replacements for customers who run into this problem. 
Sometimes they request that the customer perform some experiments with various
voltage and other settings before approving the replacement, but I don't recall
seeing any success stories from that.
Source: https://instapotbuy.com/

Thanks

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

2019-05-18 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399

Atif Aslam  changed:

   What|Removed |Added

 CC||isongsoundtr...@gmail.com

--- Comment #282 from Atif Aslam  ---
I hope she stays healthy https://isongsoundtrack.com/ fine and prettier.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

2019-05-16 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399

--- Comment #281 from Sara Taylor  ---
root@asbach:/var/crash/#kgdb7121 /boot/kernel/kernel /var/crash/vmcore.3
GNU gdb (GDB) 7.12.1 [GDB v7.12.1 for FreeBSD]
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-portbld-freebsd11.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /boot/kernel/kernel...Reading symbols from
/usr/lib/debug//boot/kernel/kernel.debug...done.
done.
Reading symbols from /boot/kernel/kernel...Reading symbols from
/usr/lib/debug//boot/kernel/kernel.debug...done.
done.
Reading symbols from /boot/kernel/zfs.ko...Reading symbols from
/usr/lib/debug//boot/kernel/zfs.ko.debug...done.
done.
Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from
/usr/lib/debug//boot/kernel/opensolaris.ko.debug...done.
done.
Reading symbols from /boot/kernel/vmm.ko...Reading symbols from
/usr/lib/debug//boot/kernel/vmm.ko.debug...done.
done.
Reading symbols from /boot/kernel/ums.ko...Reading symbols from
/usr/lib/debug//boot/kernel/ums.ko.debug...done.
done.
Reading symbols from /boot/kernel/pflog.ko...Reading symbols from
/usr/lib/debug//boot/kernel/pflog.ko.debug...done.
done.
Reading symbols from /boot/kernel/pf.ko...Reading symbols from
/usr/lib/debug//boot/kernel/pf.ko.debug...done.
done.
Reading symbols from /boot/kernel/linux.ko...Reading symbols from
/usr/lib/debug//boot/kernel/linux.ko.debug...done.
done.
Reading symbols from /boot/kernel/linux_common.ko...Reading symbols from
/usr/lib/debug//boot/kernel/linux_common.ko.debug...done.
done.
Reading symbols from /boot/kernel/linux64.ko...Reading symbols from
/usr/lib/debug//boot/kernel/linux64.ko.debug...done.
done.
Reading symbols from /boot/modules/nvidia.ko...(no debugging symbols
found)...done.
Reading symbols from /boot/kernel/nullfs.ko...Reading symbols from
/usr/lib/debug//boot/kernel/nullfs.ko.debug...done.
done.
Reading symbols from /boot/kernel/linprocfs.ko...Reading symbols from
/usr/lib/debug//boot/kernel/linprocfs.ko.debug...done.
done.
Reading symbols from /boot/kernel/tmpfs.ko...Reading symbols from
/usr/lib/debug//boot/kernel/tmpfs.ko.debug...done.
done.
Reading symbols from /boot/kernel/fdescfs.ko...Reading symbols from
/usr/lib/debug//boot/kernel/fdescfs.ko.debug...done.
done.
No thread selected.
(kgdb) info threads
No threads.


I'm using KDE all the time; and when the crash happens the screen garbles a
little bit, and after a while my system reboots - please give me some more time
to build a DDB-enabled kernel and switch to the VT console


when the crash happens the screen garbles a little bit, and after a while my
system reboots - please give me some more time to build a DDB-enabled kernel
and switch to the VT console

-
It seems related to the Nvidia driver. So I removed the Nvida card and inserted
an AMD Radeon card instead. The non-mini crash dump is usable neither with
"kgbd" nor "kgdb7121" - both complain about "cannot read KPML4phys". At the
moment I'm running a poudriere bulk build again...

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

2019-04-24 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399

--- Comment #280 from Sara Taylor  ---
root@asbach:/var/crash/#kgdb7121 /boot/kernel/kernel /var/crash/vmcore.3
GNU gdb (GDB) 7.12.1 [GDB v7.12.1 for FreeBSD]
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-portbld-freebsd11.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /boot/kernel/kernel...Reading symbols from
/usr/lib/debug//boot/kernel/kernel.debug...done.
done.
Reading symbols from /boot/kernel/kernel...Reading symbols from
/usr/lib/debug//boot/kernel/kernel.debug...done.
done.
Reading symbols from /boot/kernel/zfs.ko...Reading symbols from
/usr/lib/debug//boot/kernel/zfs.ko.debug...done.
done.
Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from
/usr/lib/debug//boot/kernel/opensolaris.ko.debug...done.
done.
Reading symbols from /boot/kernel/vmm.ko...Reading symbols from
/usr/lib/debug//boot/kernel/vmm.ko.debug...done.
done.
Reading symbols from /boot/kernel/ums.ko...Reading symbols from
/usr/lib/debug//boot/kernel/ums.ko.debug...done.
done.
Reading symbols from /boot/kernel/pflog.ko...Reading symbols from
/usr/lib/debug//boot/kernel/pflog.ko.debug...done.
done.
Reading symbols from /boot/kernel/pf.ko...Reading symbols from
/usr/lib/debug//boot/kernel/pf.ko.debug...done.
done.
Reading symbols from /boot/kernel/linux.ko...Reading symbols from
/usr/lib/debug//boot/kernel/linux.ko.debug...done.
done.
Reading symbols from /boot/kernel/linux_common.ko...Reading symbols from
/usr/lib/debug//boot/kernel/linux_common.ko.debug...done.
done.
Reading symbols from /boot/kernel/linux64.ko...Reading symbols from
/usr/lib/debug//boot/kernel/linux64.ko.debug...done.
done.
Reading symbols from /boot/modules/nvidia.ko...(no debugging symbols
found)...done.
Reading symbols from /boot/kernel/nullfs.ko...Reading symbols from
/usr/lib/debug//boot/kernel/nullfs.ko.debug...done.
done.
Reading symbols from /boot/kernel/linprocfs.ko...Reading symbols from
/usr/lib/debug//boot/kernel/linprocfs.ko.debug...done.
done.
Reading symbols from /boot/kernel/tmpfs.ko...Reading symbols from
/usr/lib/debug//boot/kernel/tmpfs.ko.debug...done.
done.
Reading symbols from /boot/kernel/fdescfs.ko...Reading symbols from
/usr/lib/debug//boot/kernel/fdescfs.ko.debug...done.
done.
No thread selected.
(kgdb) info threads
No threads.


I'm using KDE all the time; and when the crash happens the screen garbles a
little bit, and after a while my system reboots - please give me some more time
to build a DDB-enabled kernel and switch to the VT console


when the crash happens the screen garbles a little bit, and after a while my
system reboots - please give me some more time to build a DDB-enabled kernel
and switch to the VT console

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

2018-12-12 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399

--- Comment #279 from Sara Taylor  ---
root@asbach:/var/crash/#kgdb7121 /boot/kernel/kernel /var/crash/vmcore.3
GNU gdb (GDB) 7.12.1 [GDB v7.12.1 for FreeBSD]
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-portbld-freebsd11.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /boot/kernel/kernel...Reading symbols from
/usr/lib/debug//boot/kernel/kernel.debug...done.
done.
Reading symbols from /boot/kernel/kernel...Reading symbols from
/usr/lib/debug//boot/kernel/kernel.debug...done.
done.
Reading symbols from /boot/kernel/zfs.ko...Reading symbols from
/usr/lib/debug//boot/kernel/zfs.ko.debug...done.
done.
Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from
/usr/lib/debug//boot/kernel/opensolaris.ko.debug...done.
done.
Reading symbols from /boot/kernel/vmm.ko...Reading symbols from
/usr/lib/debug//boot/kernel/vmm.ko.debug...done.
done.
Reading symbols from /boot/kernel/ums.ko...Reading symbols from
/usr/lib/debug//boot/kernel/ums.ko.debug...done.
done.
Reading symbols from /boot/kernel/pflog.ko...Reading symbols from
/usr/lib/debug//boot/kernel/pflog.ko.debug...done.
done.
Reading symbols from /boot/kernel/pf.ko...Reading symbols from
/usr/lib/debug//boot/kernel/pf.ko.debug...done.
done.
Reading symbols from /boot/kernel/linux.ko...Reading symbols from
/usr/lib/debug//boot/kernel/linux.ko.debug...done.
done.
Reading symbols from /boot/kernel/linux_common.ko...Reading symbols from
/usr/lib/debug//boot/kernel/linux_common.ko.debug...done.
done.
Reading symbols from /boot/kernel/linux64.ko...Reading symbols from
/usr/lib/debug//boot/kernel/linux64.ko.debug...done.
done.
Reading symbols from /boot/modules/nvidia.ko...(no debugging symbols
found)...done.
Reading symbols from /boot/kernel/nullfs.ko...Reading symbols from
/usr/lib/debug//boot/kernel/nullfs.ko.debug...done.
done.
Reading symbols from /boot/kernel/linprocfs.ko...Reading symbols from
/usr/lib/debug//boot/kernel/linprocfs.ko.debug...done.
done.
Reading symbols from /boot/kernel/tmpfs.ko...Reading symbols from
/usr/lib/debug//boot/kernel/tmpfs.ko.debug...done.
done.
Reading symbols from /boot/kernel/fdescfs.ko...Reading symbols from
/usr/lib/debug//boot/kernel/fdescfs.ko.debug...done.
done.
No thread selected.
(kgdb) info threads
No threads.


hey! when i am going to reboot my system the bug is clear but when i again
login and start my system the bug will still appear. Whats happening with me.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

2018-12-11 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399

--- Comment #278 from Sara Taylor  ---
root@asbach:/var/crash/#kgdb7121 /boot/kernel/kernel /var/crash/vmcore.3
GNU gdb (GDB) 7.12.1 [GDB v7.12.1 for FreeBSD]
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-portbld-freebsd11.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /boot/kernel/kernel...Reading symbols from
/usr/lib/debug//boot/kernel/kernel.debug...done.
done.
Reading symbols from /boot/kernel/kernel...Reading symbols from
/usr/lib/debug//boot/kernel/kernel.debug...done.
done.
Reading symbols from /boot/kernel/zfs.ko...Reading symbols from
/usr/lib/debug//boot/kernel/zfs.ko.debug...done.
done.
Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from
/usr/lib/debug//boot/kernel/opensolaris.ko.debug...done.
done.
Reading symbols from /boot/kernel/vmm.ko...Reading symbols from
/usr/lib/debug//boot/kernel/vmm.ko.debug...done.
done.
Reading symbols from /boot/kernel/ums.ko...Reading symbols from
/usr/lib/debug//boot/kernel/ums.ko.debug...done.
done.
Reading symbols from /boot/kernel/pflog.ko...Reading symbols from
/usr/lib/debug//boot/kernel/pflog.ko.debug...done.
done.
Reading symbols from /boot/kernel/pf.ko...Reading symbols from
/usr/lib/debug//boot/kernel/pf.ko.debug...done.
done.
Reading symbols from /boot/kernel/linux.ko...Reading symbols from
/usr/lib/debug//boot/kernel/linux.ko.debug...done.
done.
Reading symbols from /boot/kernel/linux_common.ko...Reading symbols from
/usr/lib/debug//boot/kernel/linux_common.ko.debug...done.
done.
Reading symbols from /boot/kernel/linux64.ko...Reading symbols from
/usr/lib/debug//boot/kernel/linux64.ko.debug...done.
done.
Reading symbols from /boot/modules/nvidia.ko...(no debugging symbols
found)...done.
Reading symbols from /boot/kernel/nullfs.ko...Reading symbols from
/usr/lib/debug//boot/kernel/nullfs.ko.debug...done.
done.
Reading symbols from /boot/kernel/linprocfs.ko...Reading symbols from
/usr/lib/debug//boot/kernel/linprocfs.ko.debug...done.
done.
Reading symbols from /boot/kernel/tmpfs.ko...Reading symbols from
/usr/lib/debug//boot/kernel/tmpfs.ko.debug...done.
done.
Reading symbols from /boot/kernel/fdescfs.ko...Reading symbols from
/usr/lib/debug//boot/kernel/fdescfs.ko.debug...done.
done.
No thread selected.
(kgdb) info threads
No threads.


When the crash happens the screen garbles a little bit, and after a while my
system reboots - please give me some more time to build a DDB-enabled kernel
and switch to the VT console

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

2018-12-11 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399

--- Comment #277 from Sara Taylor  ---
(In reply to Nils Beyer from comment #5)

when the crash happens the screen garbles a little bit, and after a while my
system reboots - please give me some more time to build a DDB-enabled kernel
and switch to the VT console

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

2018-11-26 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399

--- Comment #276 from SF  ---
Do you use ipfw? It's caused by ipfw, after removing some lines within ipfw it
doesn't crash anymore. There is some specific commands you shouldn't use.

e.x.:
don't use "ipfw table" commands

https://forums.freebsd.org/threads/ipfw-kernel-panic-solution.65907/#post-388275

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

2018-11-26 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399

Sara Taylor  changed:

   What|Removed |Added

 CC||dragongame...@gmail.com

--- Comment #275 from Sara Taylor  ---
root@asbach:/var/crash/#kgdb7121 /boot/kernel/kernel /var/crash/vmcore.3
GNU gdb (GDB) 7.12.1 [GDB v7.12.1 for FreeBSD]
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-portbld-freebsd11.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /boot/kernel/kernel...Reading symbols from
/usr/lib/debug//boot/kernel/kernel.debug...done.
done.
Reading symbols from /boot/kernel/kernel...Reading symbols from
/usr/lib/debug//boot/kernel/kernel.debug...done.
done.
Reading symbols from /boot/kernel/zfs.ko...Reading symbols from
/usr/lib/debug//boot/kernel/zfs.ko.debug...done.
done.
Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from
/usr/lib/debug//boot/kernel/opensolaris.ko.debug...done.
done.
Reading symbols from /boot/kernel/vmm.ko...Reading symbols from
/usr/lib/debug//boot/kernel/vmm.ko.debug...done.
done.
Reading symbols from /boot/kernel/ums.ko...Reading symbols from
/usr/lib/debug//boot/kernel/ums.ko.debug...done.
done.
Reading symbols from /boot/kernel/pflog.ko...Reading symbols from
/usr/lib/debug//boot/kernel/pflog.ko.debug...done.
done.
Reading symbols from /boot/kernel/pf.ko...Reading symbols from
/usr/lib/debug//boot/kernel/pf.ko.debug...done.
done.
Reading symbols from /boot/kernel/linux.ko...Reading symbols from
/usr/lib/debug//boot/kernel/linux.ko.debug...done.
done.
Reading symbols from /boot/kernel/linux_common.ko...Reading symbols from
/usr/lib/debug//boot/kernel/linux_common.ko.debug...done.
done.
Reading symbols from /boot/kernel/linux64.ko...Reading symbols from
/usr/lib/debug//boot/kernel/linux64.ko.debug...done.
done.
Reading symbols from /boot/modules/nvidia.ko...(no debugging symbols
found)...done.
Reading symbols from /boot/kernel/nullfs.ko...Reading symbols from
/usr/lib/debug//boot/kernel/nullfs.ko.debug...done.
done.
Reading symbols from /boot/kernel/linprocfs.ko...Reading symbols from
/usr/lib/debug//boot/kernel/linprocfs.ko.debug...done.
done.
Reading symbols from /boot/kernel/tmpfs.ko...Reading symbols from
/usr/lib/debug//boot/kernel/tmpfs.ko.debug...done.
done.
Reading symbols from /boot/kernel/fdescfs.ko...Reading symbols from
/usr/lib/debug//boot/kernel/fdescfs.ko.debug...done.
done.
No thread selected.
(kgdb) info threads
No threads.


I'm using KDE all the time; and when the crash happens the screen garbles a
little bit, and after a while my system reboots - please give me some more time
to build a DDB-enabled kernel and switch to the VT console

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

2017-12-16 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399

vali gholami  changed:

   What|Removed |Added

 CC||tablosazi.fara...@gmail.com

--- Comment #274 from vali gholami  ---
http://00014.ir http://1-flymusic.ir http://8y8.ir http://abanshargh.ir
http://akstoaks.ir http://alibaba-fans.ir http://alvand-ads.ir
http://amingames.ir http://amlake-pasargad.ir http://androidsystem.ir
http://arax24.ir http://arax724.ir http://armanhardware.ir http://arsisgame.ir
http://asanban.ir http://asanbaran.ir http://asgas.ir http://ashanews.ir
http://asl-ic.ir http://astakala.ir http://atromarket.ir http://azarpajang.ir
http://bahartent.ir http://bartarresins.ir http://bazigaranesahne.ir
http://bermudasystem.ir http://buyclockfantasy.ir http://cs8.ir http://d77.ir
http://dresskade.ir http://drhesabisch.ir http://editexpert.ir
http://eemenshop.ir http://ehsa30.ir http://elameharighearjmand.ir
http://e-larestan.ir http://elsku.ir http://emadcenter.ir http://eta90.ir
http://far30sms.ir http://fixpost.ir http://fsbigroup.ir http://gemgem.ir
http://glutenfree.ir http://group-software.ir http://harim-pak.ir
http://hdserial.ir http://healthplanner.ir http://homana-nikooei.ir
http://honardorcheh.ir http://honarshiraz.ir http://hsplaser.ir http://insat.ir
http://iranitb.ir http://iranvmag.ir http://irboiler.ir http://isuntrade.ir
http://ithandmade.ir http://jahantest1.ir http://karevanhayeqadir.ir
http://kashmarsalam.ir http://kconf.ir http://kore2iran.ir http://kosar-kala.ir
http://mahdidevotees.ir http://marjaehamayesh.ir http://mgolden.ir
http://mhosein.ir http://mohsenmirzazadeh.ir http://myalibabamusic.ir
http://nama94.ir http://nettrick.ir http://niaze-rooz.ir http://noaradecor.ir
http://nod32-pass.ir http://novindpfile.ir http://n-vasegh.ir http://parlpd.ir
http://photoselfi.ir http://pooyawood.ir http://roofbam.ir http://saadatedu.ir
http://saba-gostar.ir http://sadafwood.ir http://sadcover.ir http://s-amini.ir
http://sarebanekavir.ir http://sazmansokhan.ir http://shafaghgostaran.ir
http://shandizasansor.ir http://sh-iranshahr.ir http://sms7000.ir
http://sogandmusic.ir http://steelfood.ir http://sticker1.ir
http://technoguard.ir http://tegolestan.ir http://telegramup.ir
http://torbat24.ir http://trustech.ir http://turkmenili.ir http://vray4max.ir
http://winsoftware.ir http://www.3hf.ir http://www.4drupal.ir
http://www.arazinet.ir http://www.arianagame.ir http://www.clickbartar.ir
http://www.maxstoreco.ir http://www.daryabchat.ir http://www.eset-ir.ir
http://www.marketstudies.ir http://www.raadmehr.ir http://www.rcmb.ir
http://www.shahinmag.ir http://www.starfam.ir http://www.steel-industrial.ir
http://www.suqr.ir http://www.tajervenizi.ir http://www.zarrindesign.ir
http://yahoo-shop.ir
 http://appsray.ir
http://rayit.ir http://webonyan.ir http://raypress.ir http://webbonyan.ir
http://gameray.ir http://egameweb.ir http://webiweb.ir http://raystore.ir
http://raysecurity.ir http://webegame.ir http://rayananews.ir http://webitt.ir
http://alsafir.ir http://www.fun30t.ir http://www.adrh.ir http://2funsara.ir
http://www.saesamane.ir http://themefars.ir http://irhip.ir
http://www.sharj25.ir http://maraghehee.ir http://mathpub.ir
http://seminar-learning.ir http://shahrekord-ads.ir http://mobchat.ir
http://www.nativeiran.ir http://www.water-iut.ir http://www.irancnco.ir
http://itlovers.ir http://www.shamimemahneshan.ir http://kootool.ir
http://www.waghe-e.ir http://www.ncema.ir http://hamayeshmehr.ir
http://baranclip.ir http://darab-ads.ir http://nooreravand.ir
http://www.bonarazadegantaziyeh.ir http://www.sorkhaabi.ir
http://janjalynews.ir http://fastcamp.ir http://www.sekeh337.ir
http://www.iqc13.ir http://www.aliarm.ir http://www.malakbanoo.ir
http://www.pt30.ir http://www.rianco.ir http://www.tex-one.ir
http://www.facialmask.ir http://takestan-ads.ir http://www.shervinpardaz.ir
http://www.weecharge.ir http://hamedan-music.ir http://www.2pmusic.ir
http://www.memarydownload.ir http://www.sayeh66.ir http://www.tobuy.ir
http://www.isfahancycling.ir http://tehran-investment.ir
http://neginemahvelat.ir http://www.iran-night.ir http://soft2015.ir
http://2roos.ir http://elschool.ir http://www.chahkor.ir http://naubahar.ir
http://majidshakeri.ir http://www.smsjadid.ir http://www.mountainguides.ir
http://nice-sms.ir http://aeoiconf.ir http://www.mathrde.ir http://bizir.ir
http://nafis-co.ir http://rbt-pishvaz.ir http://hashtagco.ir
http://www.mdcorp.ir http://mubonit.ir http://storeha.ir
http://www.faraghat-kh.ir http://www.ilamph.ir http://fatemyeh-ravand.ir
http://www.alifr.ir http://oxindata.ir http://biofa.ir http://sinababaei.ir
http://zarinfa.ir http://www.hyppercom.ir http://www.dlall.ir
http://www.arse3.ir http://www.polkanhaml.ir http://sportingshop.ir

[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

2017-10-10 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399

--- Comment #273 from SF  ---
I've read of people who fixed it by doing similiar things like you did, someone
printed himself an case for an aircooler with an 3d-printer to improve cooling
on his ryzen-motherboard.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

2017-10-09 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399

--- Comment #272 from rozhuk...@gmail.com ---
(In reply to Lars Viklund from comment #263)

I was have near issue with black screen/reboot after disk activity on asrock
taichi even with BristolRidge CPU. (Gamming X and AB350M Pro4 was not
affected.)
After I change thermal pad on chipset and clean(!!!)=remove all "oil" around
chipset - looks like all fixed.
On VRM I do same, but later, after tests that show that no more reboots/black
screen on disk+network activity.
Same "oil" leaked thermal pads was on asrock gamming X.
ASRock AB350M Pro4 - does not have thermal pad on chipset, and on VRM thermal
pad looks OK, but I change it (1mm -> 0,5mm).

In my case I use rsync to upload few files (total 120gb), and system
reboots/hangs after 30-50gb (system have 32GB RAM).

My be there was some PCI errors that FreeBSD cant/does not handle, and may be
linux handle it, some how, in last versions. I do not test linux.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

2017-10-09 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399

--- Comment #271 from SF  ---
I doubt you did truely ready any of my posts. All details are in there leading
to the conclusion that the powersupply of at least all low-budget mainboards up
to x370 chipset for ryzen-systems is faulty.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

2017-10-09 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399

--- Comment #270 from Mark Millard  ---
(In reply to SF from comment #269)

> Isn't it exactly what i sayed? The motherboard is causing this.

Assuming that is a reply to my comment 268:

It was just example evidence with a simple context
with little opportunity for confounding issues
to be involved.

It does certainly support the expectation that some
aspect(s) of the motherboard make the difference
for the behavior. Strongly so in my view.

So, in effect, I gave evidence supporting that view.

It is not detailed enough material to provide
evidence about what aspects of the motherboard
made the difference. So does it not contradict
any more detailed material about how
motherboards can contribute to the behavior.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

2017-10-09 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399

--- Comment #269 from SF  ---
Isn't it exactly what i sayed? The motherboard is causing this.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

2017-10-09 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399

--- Comment #268 from Mark Millard  ---
Just an FYI example about the hangups:

I'm aware of one example of someone with a
Ryzen 7 that was not having any of the hangup
problems until a BIOS update problem caused
a motherboard replacement (with the same
type of motherboard).

Same CPU, same low end video card, same memory,
same power supply, same pair of M.2 NVMe SSDs,
nothing else added or removed: just the
motherboard change.

And the result was a fairly rare example of the
hangup problem: screen goes blank, lights on
usb keyboard and mouse go off, ethernet
communication stops. But the motherboard
lights keep on updating like normal. Examples
include it happening while the system is
basically idle from a user point of view.

The context was a Windows 10 Pro installation,
not FreeBSD.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

2017-10-09 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399

--- Comment #267 from Mark Millard  ---
(In reply to SF from comment #262)

> Will building of ghc stop if there is any error? I just put into an loop.

A ghc build will stop with something like a bus error
when it fails.

So if your loop structure notices and stops as well
then your overall process should stop as well.

It would be important that the prior build be
cleaned out before the next build (not reused).

It would also be appropriate to know what
version of FreeBSD the test is run under.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

2017-10-09 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399

--- Comment #266 from SF  ---
Nvm, i quitted this bug a while ago because you people are weakminded out of my
view. The solution i told you is exactly the solution for all kinds of problems
people suffering so far, as i told you before iam hardwaredeveloper and i know
what iam talking about. It's nonsense to me continuing talking to people like
you like its always, i dont need people like you to solve my problems. Keep
making making yourself ridiculous.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

2017-10-09 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399

--- Comment #265 from Lars Viklund  ---
(In reply to SF from comment #264)
Dear SF,
I've read every single comment in this bug, and as I say (if you read my
thread) I've tried adjusting settings both according to AMD's advice and yours.

There is no boost, and there is no powerd, and running FOUR different brands of
memory at speeds between 2133 and 3200 have no measurable change in results.

I don't doubt that you've stabilized your machine. I doubt that your technique
is as universally applicable as you claim it to be.

While I know you mean good, the way you interact with the community makes
everyone, including me, just want to go away.

In my case, I've got the Linux escape hatch, but I'd rather drill deep and
figure out if there's something missing on the FreeBSD side of things.

If this is out of line and your behaviour is fine, I'll be happy to be told by
actual FreeBSD people to stop, and I'll go away.

I'm writing this in the belief that you're inadvertently hurting this
investigation, and I hope you take this to heart to consider that your theory
may not be complete.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

2017-10-09 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399

--- Comment #264 from SF  ---
No, read my recent posts. Thats the error i have with my machine, screen
turning off and only some stuff inside the pc running. I call it simply a
crash, whats happening during running the system is sometimes short time
freezes and other kind of distortions. You can solve this by doing what i did
like described within my posts.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

2017-10-09 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399

--- Comment #263 from Lars Viklund  ---
Let me go on a tangent with my experience since April of Ryzen:

I've had both kinds of AMD problem with my Ryzen 1700 across two ASUS
motherboards, the PRIME B350M-A and the PRIME X370-PRO.

It may help to clear up the discussion with that there are indeed distinct
problems that AMD seems to address when you contact their RMA/support.

The first kind is the popular one, with segfaulting GCC builds. That was
resolved for me by going from a 1709PGT to a 1728SUS CPU via a RMA process, in
which the AMD person considered the stock cooler and case organization
sufficient.

The second kind is the one where the machine simply freezes after a hour or
more, not traceable to load patterns.

The symptoms for that have been described earlier in this bug and are that all
activity ceases in the machine - NIC stops, screen turns off, no trace of any
panics over display or network. Only thing alive is fans and the RGB lighting.

In my case, the only knob in firmware that had any effect was disabling SMT
completely (note, not restricting core pairs). This changed the machine from
being hanging after sinking around 2.2T of data onto ZFS over 10 gigabit
networking (mlx4en) in about 1h20min, to being usable as a stable NAS for
weeks.

In my second interaction with AMD, they directly directed me to disable all
forms of power saving, particularly C-states like C6. As my firmware doesn't
have that particular knob anymore, I could not fully comply and the machine
remains unstable in SMT configuration with FreeBSD. For SF's sake, no amount of
load levelling, poll frequency, voltage bumps, or other knobs have any effect,
to the degree that they make sense to tune. While horrible VRM evidently may be
one cause for problems, this seems to be a wider issue.

I should note that I'm running the commit that moves the top page of memory,
and have also modified it to have a larger gap, as others have done in this
bug, and the sigtramp tool reports that I seem to have applied it properly.
Instability remains.

Now, to the interesting part of the story... a bleeding edge Arch Linux (kernel
4.13.3) is rock solid on the same hardware and same configuration. 

The only aberration that it demonstrates is kernel log entries that AMD's IOMMU
may not quite be up to snuff, which I've ignored as the machine seems to work
and I only need the GPU for console.

> [Thu Oct  5 23:04:13 2017] nouveau :21:00.0: AMD-Vi: Event logged 
> [IO_PAGE_FAULT domain=0x000b address=0x flags=0x]
> [Thu Oct  5 23:04:13 2017] nouveau :21:00.0: AMD-Vi: Event logged 
> [IO_PAGE_FAULT domain=0x000b address=0x0080 flags=0x]
> [Thu Oct  5 23:04:13 2017] nouveau :21:00.0: AMD-Vi: Event logged 
> [IO_PAGE_FAULT domain=0x000b address=0x0180 flags=0x]

Could it be an interaction with the NVidia card or other hardware in a
non-primary PCIe slot? Could it be that the IOMMU on these chipsets is so
broken that the OS needs workarounds or ignoring it completely?

I've got no clue, but I offer this data and these points to ponder.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

2017-10-09 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399

--- Comment #262 from SF  ---
Will building of ghc stop if there is any error? I just put into an loop.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

2017-10-09 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399

--- Comment #261 from SF  ---
The difference between low budget moterboards and enthusiast-boards are the
switching frequency and better power-supply in general, the cheap bords only
have a low frequency and manually settings doesnt get you much higher. The
frequency on some high cost boards was much more of double then of all the
boards up to x370 chipset. This is where you will see the most difference in
stabilizing your system. Cooling also affects it much. Disabling cores will do
nothing, i have programs that crash running only on one single core and i have
programs that never crash the system running on all cores. Disbaling boost and
reducing cpu-frequency is the only thing that helps.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

2017-10-09 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399

--- Comment #260 from Don Lewis  ---
(In reply to Mark Millard from comment #257)
I'm not convinced that the ghc problem is entirely a Ryzen hardware problem.

The first thing I did after I received my replacement CPU was to rerun
poudriere, and ghc failed as usual.  Then there was a recent commit that I
wanted to test, so I upgraded to the latest version of 12.0-CURRENT.  I've run
poudriere twice since then, and ghc has successfully built both times.

I'm planning on doing some bisection tests to try to track down what seems to
have fixed the problem, but this could take a while.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

2017-10-09 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399

--- Comment #259 from Don Lewis  ---
(In reply to SF from comment #256)
Neither of my AM4 boards have a VRM frequency adjustment, and none of my large
collection of non-AM4 boards have it either.  I think this feature is pretty
rare.

The highest temperature that I observed in my testing was about 62 C, and that
was  only on very hot afternoons in an un-airconditioned room.  We only
recently got temperature monitoring working in FreeBSD for Ryzen, so I don't
know what the CPU temperature was in my early testing, but the room temperature
was probably 10C lower on my overnight tests and it didn't seem to make any
difference.  Disabling all but two cores in the BIOS also didn't make the
errors go away.  That should have reduced power consumption and heat
dissipation to something like 25W.  Reducing the CPU and RAM clock frequencies
also did not help.  Forcing the cooling fans to run at full speed full time
also did not help.  The default fan curve never cranked up the fan speed this
high.  This doesn't look like a thermal or voltage regulation issue to me.

The only thing that really seemed to improve the results that I was seeing was
tweaking the scheduler to limit the migration of threads between cores, and the
effect was not at all subtle.

The AMD Community Forum thread that I cited has posts from a large number of
Linux users who were experiencing the random segfault problem.  Many of them
worked with AMD customer support who suggested trying a number of different
things (mostly voltage tweaks, disabling SMT, disabling OPCACHE, etc.) that
really didn't seem to solve the problem.  At best they reduced the frequency of
the errors.  AMD does now say that there is a "performance marginality" issue
and has been doing warranty replacements of CPUs for users who have this
problem and generally people who have gotten replacement CPUs have been happy
with the results.  I don't think AMD would be spending the money to do this if
the problem could be fixed with a motherboard BIOS upgrade that would tweak the
default VRM settings.  Apparently AMD is now able to screen for this problem
because they also stated that Threadripper is not affected and it uses two of
the Ryzen die (with the same stepping as the Ryzen CPU chips).

In my case, I just received a warranty CPU replacement.  The random compiler
segfaults are now gone.  The only info that I had to send AMD was my CPU part
and serial numbers, a description of my hardware (PSU, RAM, motherboard, BIOS
revision, etc.), a photo of the BIOS screen showing voltages and temperatures,
and a photo of my case interior so they could look for any potential cooling
problems.  Based on that, they approved an RMA and sent me a replacement CPU. 
It doesn't look like they thought that any BIOS tuning tweaks would be worth
trying.  I still see some random build failures, but I see the same sorts of
failures on my AMD FX-8320E.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

2017-10-09 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399

--- Comment #258 from Don Lewis  ---
(In reply to Mark Millard from comment #255)
I never got panics.  Instead, my machine would either blank the video (text
console, not running Xorg) and hang, or would silently reboot.  Building
openjdk7 was a fairly reliable trigger.  Moving the shared page was a 100% fix
for that problem.

I still don't fully understand the problem.  The signal trampoline location
should have been far enough away from the boundary for the instruction
prefetcher to stop before hitting the boundary ...

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

2017-10-08 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399

--- Comment #257 from Mark Millard  ---
(In reply to SF from comment #256)

My guess is that "system crashed" in
"one system crashed and the other didn't" is
referring to panics and shutdowns but not
to individual programs that get SIGSEGV
or other such per-process behavior.

If that is right: I never had the problem
to begin with. I would have had to change
things to cause the problem before I could
get rid of it. I had no reason to want to
create a problem that I did not have.

Basically my context was not a good test
case for such. (And I ran out of time
with the system anyway.)


I'd still like to learn how many times
in a row you can rebuild lang/ghc
without any per-process failures. (Not
intending more than a few such tries
if it seems reliable about building.)

Of course you may not want to do or
report such. But I'd be curious if
you did.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

2017-10-08 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399

--- Comment #256 from SF  ---
Noone of you did try changing the cpu-switching frequency and setting load line
balancing. I did try alot of stuff with cooling and all kinds of
power-settings, cooling was the first thing i recognised signifcant improvents
like other people did. The second thing was cpu-switching frequency, load line
balancing also marginally affects it. You will recognise the difference
switching from low to extreme. Increasing soc-voltage did marginally improve it
but cpu-voltage always seemed to worsen it. Deactivating boost did a huge
improvement and reducing the cpu-frequency(not switching frequency) did
completely stabilize it. I dont know whats wrong with you people but i
previously sayed that there was someone with 2 exactly the same ryzen system,
one system crashed and the other didn't. The one system had watercooling and
the other system had aircooling, the system with aircooling crashed. I did read
of people which sayed that low budgeg motherboards are keep crashing with ryzen
systems because the power supply of them is faulty, its up to x370 chipsets.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

2017-10-08 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399

--- Comment #255 from Mark Millard  ---
(In reply to SF from comment #254)

Just reporting a distinct example. . .

The Ryzen 1800X system that I had access to
for a time had water-based cooling that kept
it under 47 degC even during hot summer days
with no air conditioning but doing builds.
(Clearly not true of any days getting near
that temperature in the first place. But it
gives a clue as to effectiveness.) The
power supply was also good. There was only
a basic, low power video card present.

That did not stop the SIGSEGV's, missing
temporary files, having lang/ghc almost
always fail to build, etc. Although, in
general, I seemed to get them somewhat
less often than some folks seemed to be
reporting --other than lang/ghc nearly
always failing fairly rapidly.

[Side question: Have you tested your
ability to repeatedly rebuild lang/ghc
from scratch? It was by far the most
reliable failure that I found (that
was a normal activity).]

But I never observed the panics in normal
operation, not even before the page-avoidance
change was made. However, I was using 64-bit
FreeBSD via Hyper-V with Windows 10 Pro as the
boot OS. That might have caused automatic
avoidance of the problematical page.
(I also did a little VirtualBox activity
instead of Hyper-V activity.)

I tended to assign FreeBSD access to
14 hw-threads in Hyper-V, leaving 2
avoided for Windows 10 Pro availability.

For the vast majority of things I'd left
the BIOS at defaults. For example,
no voltage changes of any kind --nor
CPU frequency changes. AMD Cool' n'
Quiet disabled, SVM Mode Enabled, Core
C6 state disabled. 2nd memory profile
used as-is. 2133 MT/s resulted. (It
was not overclocking-style RAM.) And
that is about it for adjustments.

I no longer have access to that system.
So that has limited what I managed to
explore. It will probably be a month or
so before I've access to a Ryzen system
of some kind again. (A BIOS update
failure also cut into the time I had
on the Ryzen system: motherboard
replacement.)

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

2017-10-08 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399

--- Comment #254 from SF  ---
Buy a better cooler, ensure your system stays below 60°C under all
circumstances. Watercooling should completely negate all your misbehavior like
previously sayed, everything i found out was correct. Yesterday i had a single
crash but it was almost gone, i think it was caused because of the +voltage
settings which are unnecessary. All settings i did are done to make sure that
the mainboard isn't overheating.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

2017-10-07 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399

--- Comment #253 from Don Lewis  ---
(In reply to Nils Beyer from comment #248)
I finally had a chance to install my new CPU.  Temperatures under load are
generally in the upper 40s as opposed to the lower 60s, but the weather has
changed and maybe 8C of the difference is due to room temperature.

No crashes/hangs/panics, but I do still have some port build anomalies that
I'll discuss in the other PR.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

2017-10-07 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399

--- Comment #252 from Don Lewis  ---
(In reply to SF from comment #250)
This mega-thread https://community.amd.com/thread/215773?start=0=0 on
AMD Community Forum is full of Linux users who are experiencing random
segfaults when doing parallel compiles.  Lots of experiments with different
voltage settings, RAM timing settings, and tweaking of other BIOS knobs.

AMD eventually admitted that there is a "performance marginality" issue and has
been doing warranty replacements for customers who run into this problem. 
Sometimes they request that the customer perform some experiments with various
voltage and other settings before approving the replacement, but I don't recall
seeing any success stories from that.

AMD was apparently manually screening some of the replacement CPUs before
shipping them, as evidenced by one of the seals on the replacement CPU being
cut and traces of thermal compound on the CPU.  At least in some cases AMD
performed testing with hardware identical to the the customer's.

The system crashes and hangs that I and many other FreeBSD users was caused by
the behavior of the instruction prefetch hardware near the maximum possible
user address 0x7fff.  This problem affected both FreeBSD and
DragonflyBSD.  I don't know about the other BSDs.  We implemented an acceptable
workaround in r321899.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

2017-10-06 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399

--- Comment #251 from rozhuk...@gmail.com ---
Well, I try all that you describe:
- change power-supply
- decrease freq
- turn off boost
- tune LLC
- many other thing in different combinations

But I found that after I remove oil from thermal pad around chipset - fix
strange reboots that happen even with BristolRidge, and not happen on other my
am4 mobos with BristolRidge.
http://forum.asrock.com/forum_posts.asp?TID=4593=37459=x370-taichi-goes-blank-code-00#37459

I remember about some strange work PCI-E on 1700x, but I RMA it and now with
BristolRidge and 1300x (1725) I dont see these issues.
Im not sure is it was because oil around chipset or because something wrong
with 1700x.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

2017-10-06 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399

--- Comment #250 from SF  ---
While you were on the search for a softwarefault i found out was is causing it
months before and did finally find a solution. You didn't even try it, noone
did and i told it much more then one time.

It is caused by the power-supply of the mainboard! My pc is not crashing
anymore, all i did is cpu-load-line balancing to low, turn off the boost
function, optimized power phase control, cpu switching frequency to 350,
disable epu, +0,12 cpuvoltage, +0,12 socvoltage and not cranking up the
ram-frequency too much. If its still unstable you have to reduce your
cpu-frequency down to 3000mhz or 2800mhz, iam having absolutely no crashes
anymore. The solution is very complicated but it works and its exactly what i
sayed from beginning...

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

2017-10-05 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399

--- Comment #249 from rozhuk...@gmail.com ---
(In reply to Nils Beyer from comment #247)

http://forum.ixbt.com/post.cgi?id=attach:9:68823:5110:1.jpg
(on photo my asrock taichi, and some sort of oil from thermal pad)

17A2 - some constant, date on next line.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

2017-10-05 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399

--- Comment #248 from Nils Beyer  ---
(In reply to Don Lewis from comment #246)

yes, temperature is around 51°C - 52°C under load. A couple of degrees cooler
than my old CPU...

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

2017-10-05 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399

--- Comment #247 from Nils Beyer  ---
(In reply to rozhuk.im from comment #245)

> What is your chipset date?

no idea.


> See after: 17A2.

what does "17A2" mean?


> Example: 
> http://www.pcdiy.com.tw/assets/images/768/8a89458610…8c293db902ab.jpeg

link is broken/incomplete...

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

2017-10-03 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399

--- Comment #246 from Don Lewis  ---
(In reply to Nils Beyer from comment #240)
Does the CPU core temperature look OK?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

2017-10-03 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399

--- Comment #245 from rozhuk...@gmail.com ---
What is your chipset date?

See after: 17A2.
Example: http://www.pcdiy.com.tw/assets/images/768/8a89458610…8c293db902ab.jpeg

Mine:
X370 Taichi - 1629 - Freeze/reboot
AB350M Pro4 - 1649 - OK
Fatal1ty X370 Gaming X - 1646 - OK

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

2017-10-03 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399

--- Comment #244 from Don Lewis  ---
My original CPU had a 1708SUT date code.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

2017-10-03 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399

--- Comment #243 from Don Lewis  ---
The shared page relocation (r321899 in HEAD) fixed the hanging/crashing problem
for me, but I still had the random SIGBUS/SIGSEGV problem when running parallel
compiles.  I RMAed my old CPU the Friday before last.  The replacement with
date code 1733SUS was delivered yesterday.  I hope to install it laster today.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

2017-10-03 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399

--- Comment #242 from Nils Beyer  ---
(In reply to rozhuk.im from comment #241)

"UA 1730SUS"

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

2017-10-03 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399

--- Comment #241 from rozhuk...@gmail.com ---
(In reply to Nils Beyer from comment #240)

Is your CPU newer than 25 week?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

2017-10-03 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399

--- Comment #240 from Nils Beyer  ---
(In reply to rozhuk.im from comment #239)

nope, still freezes with black screen and fans still running. Even without
having poudriere builds running. Haven't contacted AMD tech support about that
yet because I haven't gotten any MCA messages yet, so it probably is not a
hardware issue anymore.

AGESA 1.0.0.6b doesn't help at all though.

Haven't played around with voltages/frequencies yet...

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

2017-10-02 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399

--- Comment #239 from rozhuk...@gmail.com ---
Any news?
Is ryzen work ok now?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

2017-09-07 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399

--- Comment #238 from Nils Beyer  ---
(In reply to Don Lewis from comment #237)

okay, just for fun I increased the dead zone of the user page:
--
Index: sys/amd64/amd64/elf_machdep.c
=== 
--- sys/amd64/amd64/elf_machdep.c   (revision 323186)   
+++ sys/amd64/amd64/elf_machdep.c   (working copy)  
@@ -88,10 +88,10 @@ 
 amd64_lower_shared_page(struct sysentvec *sv)  
 {  
if (hw_lower_amd64_sharedpage != 0) {   
-   sv->sv_maxuser -= PAGE_SIZE;
-   sv->sv_shared_page_base -= PAGE_SIZE;   
-   sv->sv_usrstack -= PAGE_SIZE;   
-   sv->sv_psstrings -= PAGE_SIZE;  
+   sv->sv_maxuser -= (128 * PAGE_SIZE);
+   sv->sv_shared_page_base -= (128 * PAGE_SIZE);   
+   sv->sv_usrstack -= (128 * PAGE_SIZE);   
+   sv->sv_psstrings -= (128 * PAGE_SIZE);  
}   
 }
[...]
root@asbach:/home/nbe/#./sigtramp ^M
8
-1 12 0x7ff7f190 8
--

let's see if that changes anything...

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

2017-09-07 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399

--- Comment #237 from Don Lewis  ---
(In reply to Nils Beyer from comment #236)
We now leave the boundary page unmapped, which is supposed to cure the problem
according to what AMD says.  That's why the "program to cause Ryzen hang/reboot
on tweaked FreeBSD by executing code in high memory" is no longer to map that
page and use it for evil purposes.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

2017-09-07 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399

--- Comment #236 from Nils Beyer  ---
(In reply to Don Lewis from comment #235)

> Yeah, I'd get in touch with AMD.  I suspect that you'll have to go through 
> some hardware troubleshooting again.

I haven't gotten any MCA messages yet with the new CPU - so it makes me believe
that it's more a software problem now.

I'd rather bother AMD support again only if I'm strongly sure that there really
is a hardware problem - and the MCA messages are one strong indicator for me.

Maybe the user page needs to shifted even further down:

   
https://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/11ba7f73d6e534d54da55d5c4a1ac1553cc62b45

How do I do that on FreeBSD?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

2017-09-07 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399

--- Comment #228 from Nils Beyer  ---
(In reply to Nils Beyer from comment #225)

Froze again - black screen, fans still running...

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

2017-09-07 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399

--- Comment #235 from Don Lewis  ---
You'll need the linux kmods for doing a full poudriere run I believe.  The
lower bits really don't matter.  The important thing is staying below
0x7000.

I think the only thing that AGESA 1.0.0.6b buys you is better RAM compatibility
and speed.

Yeah, I'd get in touch with AMD.  I suspect that you'll have to go through some
hardware troubleshooting again.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

2017-09-07 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399

--- Comment #233 from Don Lewis  ---
(In reply to Nils Beyer from comment #232)
Yeah that should be ok.  I get this:
8
-1 12 0x7fffe000 8

As long as the third value ends with fexxx then you have the shared page
fix.   There is some strange reason that it took me a long time to
figure out that causes the least significant bits to change, maybe
whether linux emulation is loaded ...

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

2017-09-07 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399

--- Comment #231 from Nils Beyer  ---
(In reply to Don Lewis from comment #229)

can only guess:
---
root@asbach:/usr/local/poudriere/data/logs/bulk/11_1-default/2017-09-05_16h59m32s/logs/#ls
-larTt | tail -10^M
-rw-r--r--  3 root  wheel   7565 Sep  7 03:48:40 2017 wordplay-7.22_1.log
-rw-r--r--  3 root  wheel   6285 Sep  7 03:48:40 2017 powder-115_3.log
-rw-r--r--  3 root  wheel   6173 Sep  7 03:48:40 2017 amtterm-1.4.log
-rw-r--r--  3 root  wheel    Sep  7 03:48:40 2017 rubygem-fpm-1.9.2.log
drwxr-xr-x  2 root  wheel   8055 Sep  7 03:48:40 2017 errors
-rw-r--r--  3 root  wheel   7754 Sep  7 03:48:41 2017
ru-stardict-mueller7-2.4.2.log
-rw-r--r--  3 root  wheel  361443781 Sep  7 03:48:41 2017
copperspice-1.3.2_3.log
drwxr-xr-x  3 root  wheel  25649 Sep  7 03:48:41 2017 .
-rw-r--r--  3 root  wheel 22 Sep  7 03:48:41 2017 xwit-3.4_3.log
-rw-r--r--  3 root  wheel   4821 Sep  7 03:48:41 2017 zen-cart-1.3.9h_2.log
---

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

2017-09-07 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399

--- Comment #229 from Don Lewis  ---
(In reply to Nils Beyer from comment #228)
That really sounds like the share page problem ...

Do you know what was building at the time?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

2017-09-07 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399

--- Comment #234 from Nils Beyer  ---
(In reply to Don Lewis from comment #233)

"linux" and "linux64" modules are indeed loaded:

root@asbach:/root/#kldstat
Id Refs AddressSize Name
 1   35 0x8020 1f49f00  kernel
 21 0x8214b000 31ca00   zfs.ko
 32 0x82468000 cc20 opensolaris.ko
 41 0x82b11000 ac15 linprocfs.ko
 51 0x82b1c000 7bb1 linux_common.ko
 61 0x82b24000 ba42 tmpfs.ko
 71 0x82b3 3653 ums.ko
 81 0x82b34000 2a22 pflog.ko
 91 0x82b37000 3551dpf.ko
121 0x82bef000 66b8 nullfs.ko
131 0x82bf6000 5c6d fdescfs.ko
141 0x82b6d000 1d7c amdtemp.ko
151 0x82b6f000 ed0  amdsmn.ko


So, should I try without them?

There's still no AGESA 1.0.0.6b for my board. Shall I wait until that?

Or should I contact AMD support again that the replacement doesn't work either?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

2017-09-07 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399

--- Comment #232 from Nils Beyer  ---
(In reply to Don Lewis from comment #230)

--
root@asbach:/home/nbe/#./sigtramp^M
8
-1 12 0x7fffe190 8
--

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

2017-09-07 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399

--- Comment #230 from Don Lewis  ---
Created attachment 186143
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=186143=edit
program to print the address of the signal trampoline

Compile and run this program.  What is its output?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

2017-09-06 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399

--- Comment #227 from rozhuk...@gmail.com ---
(In reply to Nils Beyer from comment #226)

Now I use Bristol Ridge, it not affected by AGESA, IMHO.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

2017-09-05 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399

--- Comment #226 from Nils Beyer  ---
(In reply to rozhuk.im from comment #224)

that's very strange. You're running AGESA 1.0.0.6b on the Fatal1ty, right? Do
you run that on the Taichi, too? The AB350M Pro4 and the AB350 Pro4 still don't
have AGESA 1.0.0.6b available, so maybe that makes a difference; I don't know.

There still is no official Check-My-Ryzen-Tool from AMD, so it's all
speculations...

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

2017-09-05 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399

--- Comment #225 from Nils Beyer  ---
(In reply to Nils Beyer from comment #223)

well, it froze again - black screen, fans still running. But, because I cannot
remember whether I had that user page shift patch still active or not, I've
upgraded to 12-CURRENT and restarted the poudriere build from scratch.

The positive thing is that the new CPU is 5°C cooler than my old one - so
that's something... ;-)

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

2017-09-04 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399

--- Comment #224 from rozhuk...@gmail.com ---
I get money back for my Ryzen, and now looking for >1725 in local markets.

I try with A10-9700 on Taichi and get reboot on rsync upload 100gb file, just
like with ryzen.

A10-9700 on ASRock AB350M Pro4 and on ASRock Fatal1ty X370 Gaming X - ok, but
once on AB350M Pro4 system freeze (until I press reset) after rsync upload test
on firefox (with many tabs) exit. I cant reproduce this.

mpv youtube + game - ok on both mobos. (Ryzen + taichi = freeze/reboot)
Also I got no strange wine apps crashes with this CPU/MoBos.

Now Im not sure is problem was in my Ryzen.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

2017-09-03 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399

--- Comment #222 from Don Lewis  ---
(In reply to rozhuk.im from comment #221)
I have, works great.

It doesn't take into account the 20C offset on the 1x00X parts, so you'll have
to manually set the offset or remember to do mental math.

After subtracting the offset, I can see that my 1700X is running just above 60C
under load.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

2017-09-03 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399

--- Comment #221 from rozhuk...@gmail.com ---
Offtop: can some one with Ryzen test amdtemp: https://reviews.freebsd.org/D9759
?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

2017-08-23 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399

--- Comment #220 from rozhuk...@gmail.com ---
The is some statistic that most problems happen with CPU manufactured before
week 26:
https://www.reddit.com/r/Amd/comments/6ubmd1/ryzen_compilation_segfaults_positive_rma/
https://docs.google.com/spreadsheets/d/1pp6SKqvERxBKJupIVTp2_FMNRYmtxgP14ZekMReQVM4/htmlview

Where: UA1725SUS: 17=2017 year, 25=week.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

2017-08-16 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399

--- Comment #219 from commit-h...@freebsd.org ---
A commit references this bug:

Author: truckman
Date: Wed Aug 16 07:59:58 UTC 2017
New revision: 322569
URL: https://svnweb.freebsd.org/changeset/base/322569

Log:
  MFC r321899

  Lower the amd64 shared page, which contains the signal trampoline,
  from the top of user memory to one page lower on machines with the
  Ryzen (AMD Family 17h) CPU.  This pushes ps_strings and the stack
  down by one page as well.  On Ryzen there is some sort of interaction
  between code running at the top of user memory address space and
  interrupts that can cause FreeBSD to either hang or silently reset.
  This sounds similar to the problem found with DragonFly BSD that
  was fixed with this commit:
   
https://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/b48dd28447fc8ef62fbc963accd301557fd9ac20
  but our signal trampoline location was already lower than the address
  that DragonFly moved their signal trampoline to.  It also does not
  appear to be related to SMT as described here:
   
https://www.phoronix.com/forums/forum/hardware/processors-memory/955368-some-ryzen-linux-users-are-facing-issues-with-heavy-compilation-loads?p=955498#post955498

"Hi, Matt Dillon here. Yes, I did find what I believe to be a
 hardware issue with Ryzen related to concurrent operations. In a
 nutshell, for any given hyperthread pair, if one hyperthread is
 in a cpu-bound loop of any kind (can be in user mode), and the
 other hyperthread is returning from an interrupt via IRETQ, the
 hyperthread issuing the IRETQ can stall indefinitely until the
 other hyperthread with the cpu-bound loop pauses (aka HLT until
 next interrupt). After this situation occurs, the system appears
 to destabilize. The situation does not occur if the cpu-bound
 loop is on a different core than the core doing the IRETQ. The
 %rip the IRETQ returns to (e.g. userland %rip address) matters a
 *LOT*. The problem occurs more often with high %rip addresses
 such as near the top of the user stack, which is where DragonFly's
 signal trampoline traditionally resides. So a user program taking
 a signal on one thread while another thread is cpu-bound can cause
 this behavior. Changing the location of the signal trampoline
 makes it more difficult to reproduce the problem. I have not
 been because the able to completely mitigate it. When a cpu-thread
 stalls in this manner it appears to stall INSIDE the microcode
 for IRETQ. It doesn't make it to the return pc, and the cpu thread
 cannot take any IPIs or other hardware interrupts while in this
 state."
  since the system instability has been observed on FreeBSD with SMT
  disabled.  Interrupts to appear to play a factor since running a
  signal-intensive process on the first CPU core, which handles most
  of the interrupts on my machine, is far more likely to trigger the
  problem than running such a process on any other core.

  Also lower sv_maxuser to prevent a malicious user from using mmap()
  to load and execute code in the top page of user memory that was made
  available when the shared page was moved down.

  Make the same changes to the 64-bit Linux emulator.

  PR:   219399
  Reported by:  n...@renzel.net
  Reviewed by:  kib
  Reviewed by:  dchagin (previous version)
  Tested by:n...@renzel.net (earlier version)
  Differential Revision:https://reviews.freebsd.org/D11780

Changes:
_U  stable/11/
  stable/11/sys/amd64/amd64/elf_machdep.c
  stable/11/sys/amd64/amd64/initcpu.c
  stable/11/sys/amd64/include/md_var.h
  stable/11/sys/amd64/linux/linux_sysvec.c

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

2017-08-08 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399

Ed Maste  changed:

   What|Removed |Added

 Status|New |Open

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

2017-08-08 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399

--- Comment #218 from Konstantin Belousov  ---
(In reply to Don Lewis from comment #216)
This is a reference to FreeBSD-SA-12:04.sysret.  We handle that by forcing
normal iret return path instead of the fast syscall return, same as we handle
any modifications to the context from usermode.  See the very end of the
amd64_syscall().

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

2017-08-07 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399

--- Comment #217 from Mark Millard  ---
(In reply to Nils Beyer from comment #215)

Looking around the comment is newer than the definition
but the comment was added on: 2014-Nov-4. (Based on
"blame".)

By contrast the line:

#define TASK_SIZE_MAX   ((1UL << 47) - PAGE_SIZE)

dates back to 2009-Feb-20.

Definitely not a new issue.

The placement in the files is in blame for:

https://github.com/torvalds/linux/blame/master/arch/x86/include/asm/processor.h

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

2017-08-07 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399

--- Comment #216 from Don Lewis  ---
LOL ... 

Prior to the fix in r321899, the top page of user memory for amd64 executables
was used by the shared page, the contents of which are controlled by the
kernel.  This page does contain the signal trampoline, which contains a SYSCALL
instruction, which made me very suspicious based on my experiments with
executing code in this page.  The SYSCALL instruction is located well away from
the top of the page, though.  I may try playing with this instruction if I ever
have the time.

After r321899, the shared page is moved lower and we don't allow the top page
to be used at all, similar to Linux.  CloudABI64 got a similar fix.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

2017-08-07 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399

--- Comment #215 from Nils Beyer  ---
(In reply to Don Lewis from comment #214)

documentation is the keyword, I don't know; I only have this:

from: linux/v4.12/source/arch/x86/include/asm/processor.h - lines 791 and seq

#ifdef CONFIG_X86_32
[...]
#else
/*
 * User space process size. 47bits minus one guard page.  The guard
 * page is necessary on Intel CPUs: if a SYSCALL instruction is at
 * the highest possible canonical userspace address, then that
 * syscall will enter the kernel with a non-canonical return
 * address, and SYSRET will explode dangerously.  We avoid this
 * particular problem by preventing anything from being mapped
 * at the maximum canonical address.
 */
#define TASK_SIZE_MAX   ((1UL << 47) - PAGE_SIZE)


do we have or need something similar?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

2017-08-07 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399

--- Comment #214 from Don Lewis  ---
I'm not familiar enough with the Linux memory map to comment, but I haven't
seen any reports of hang/reboot problems that sound like what what we ran into.
 There have been reports of idle machines having problems that seem to be
resolved by avoiding the deep Cx states.  I don't know if that is a potential
problem for us since our default seems to be:
  hw.acpi.cpu.cx_lowest: C1

It would be nice if the "safe area" was documented.  This doesn't appear to be
an issue with Intel CPUs.  My AMD FX-8320E is happy with the pre-Ryzen location
of our signal trampoline code.  I haven't run my test program on it because I'm
keeping it busy doing the port builds that I'd hoped to be doing on my new
Ryzen box.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

2017-08-07 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399

--- Comment #213 from Nils Beyer  ---
(In reply to Nils Beyer from comment #212)

more statements:

I'm new to this myself (I work on the GPU SW side) but AFAICS there are at
least three different CPU families (1 from AMD) over the last decade which
require special treatment, basically making sure that no code gets executed
near the end of canonical user address space. The top of user process address
space is the dividing line between the least privileged code and the
touch-it-and-die non-canonical address space.

Over time it seems that more "safe area" is required - presumably because each
new CPU generation pre-fetches further ahead than the last one. In a sense
Linux (and Windows I believe) got lucky by reserving a full guard page while
BSD allocated a smaller guard area. As a result BSD has had to bump the guard
area (to a full page) while other OSes did not.


-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

2017-08-07 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399

--- Comment #212 from Nils Beyer  ---
(In reply to Don Lewis from comment #204)

following claim came from a Linux user regarding freezes near the top memory
limit:
---
Thats looking more BSD specific as linux does have a full guard page as oppose
to a partial in BSD. Does this mitigate a CPU issue? probably but it isn't a
new one & the CPU/RAM controller shouldn't be susceptable. But this side of
things may have already been sorted in linux land. 
---

is there something to it?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

2017-08-06 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399

--- Comment #211 from Don Lewis  ---
(In reply to Nils Beyer from comment #210)
No.  The kernel needs to be modified to move the shared page out of the way so
that the program can mmap() the top page of user memory.

With an unmodified kernel, it should be possible to trigger the problem by
writing a program that installs a signal handler for some signal and then
sending itself signals by calling kill() in a loop.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

2017-08-06 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399

--- Comment #210 from Nils Beyer  ---
(In reply to Don Lewis from comment #204)

Don, is it possible to modify your program so that it triggers that freeze on a
vanilla 11.1-RELEASE?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

2017-08-05 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399

--- Comment #209 from Nils Beyer  ---
(In reply to Don Lewis from comment #208)

> It would also be interesting to see the results on non-Ryzen hardware.

done that on the mentioned Intel Xeon system. 11.1-RELEASE plus the single-line
patch in "vmparam.h":
---
#define SHAREDPAGE (VM_MAXUSER_ADDRESS - 2*PAGE_SIZE)
---

Your program runs through without any problems or slowdowns at/over
"0x7f40" - with as well without pinning it to core 0...

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

2017-08-05 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399

--- Comment #208 from Don Lewis  ---
The second WHERE 0x04fff000 is someleftover debug stuff from an earlier
version of the program that executed some more complicated code.  I needed to
debug that code in a harmless spot in memory so that I could get that code
working right.

Even without cpuset, I think I eventually got it to crash at 0x7f40,
probably because it migrated to CPU 0 on it's own or an interrupt finally
caught it at that address, which would be less frequent on the other cores. 
There might have been other stuff running on the system at the same time.

If you pin it to some other CPU, do you see system time spike up when it gets
to 0x7f40?  I wonder if it's getting kicked into a trap handler on
every iteration when it gets to that address.  That and an interrupt happening
at the same time might sent it off into the weeds.

It would also be interesting to see the results on non-Ryzen hardware.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

2017-08-04 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399

--- Comment #207 from Nils Beyer  ---
(In reply to Nils Beyer from comment #206)

answering myself: yes, maybe I should just listen to what Don said: I do need
that origin patch because without it the programm is not able to MMAP at
0x7f(...) - as Don instructed. And at 0x4f(...) there seems to be no problem.

Using "cpuset -l 0 ./ryzen_provoke_crash" it freezes exactly where my first
system did:

[...]
executing at 0x7f3a ..
executing at 0x7f3b ..
executing at 0x7f3c ..
executing at 0x7f3d ..
executing at 0x7f3e ..
executing at 0x7f3f ..
executing at 0x7f40 ..


Without using "cpuset -l 0" the program seems to pass the 0x7f40 mark,
but becomes very, very slow - don't know if it freezes because I aborted it;
took too long for one row...

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

2017-08-04 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399

--- Comment #206 from Nils Beyer  ---
(In reply to Nils Beyer from comment #205)

sorry, mass confusion in my brain; I accidentially executed that program on my
first Ryzen system with 32GB of RAM and your origin patch applied. The SSH
session to my second Ryzen system timed out, and because I do SSH there via SSH
to my first Ryzen system I was therefore thrown back to my first system which I
didn't notice. :-(

Sorry for the confusion, but the result stays the same. Freeze at the
suspicious location.

At the moment, I really try to get the same freeze on my second Ryzen system
(using another SSH hop) with 16GB of RAM. There, I had to use the second
"WHERE"-define as well. And there's vanilla 11.1-RELEASE indeed running, so I
assume that this freeze won't happen because I need your origin patch, right?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

2017-08-04 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399

--- Comment #205 from Nils Beyer  ---
(In reply to Don Lewis from comment #204)

absolutely wonderful test case you've created - despite your instructions I've
run that program on a vanilla 11.1-RELEASE (no patches) on my second Ryzen
system (the one with 16GB where I've never poudriered), and it freezes exactly
there where you have experienced it (done it via SSH, so output is still
visible):
---
[...]
executing at 0x7f30 ..
executing at 0x7f31 ..
executing at 0x7f32 ..
executing at 0x7f33 ..
executing at 0x7f34 ..
executing at 0x7f35 ..
executing at 0x7f36 ..
executing at 0x7f37 ..
executing at 0x7f38 ..
executing at 0x7f39 ..
executing at 0x7f3a ..
executing at 0x7f3b ..
executing at 0x7f3c ..
executing at 0x7f3d ..
executing at 0x7f3e ..
executing at 0x7f3f ..
executing at 0x7f40 ...
---

tried that on my Intel Xeon E3-1220 v3 system, but had to use the second
"WHERE"-define because it couldn't mmap at 0x7f(...) - ENOMEM. Anyways, the
result is that it didn't freeze there...

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

2017-08-04 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399

--- Comment #204 from Don Lewis  ---
Created attachment 185022
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=185022=edit
program to cause Ryzen hang/reboot on tweaked FreeBSD by executing code in high
memory

If you modify the FreeBSD kernel to lower the shared page, but leave sv_maxuser
at its original value so that a user program can mmap the page at
0x7000, the  attached program will fill that page with RET instructions
and perform calls to those in a loop.  I have not observed any issues with
calls to the RET instructions at 0x7f3f or below.  When the RET
instruction at 0x7f40 is executed, my machine will typically silently
reboot without a panic message, or it will sometimes hang with the screen
blanked.  This test is the most sensitive on core 0, which handles most
interrupts, so run under "cpuset -l 0" for best results.  The problem appears
to be triggered when the RET instruction is interrupted.

It is possible to load and execute arbitrary code for other experiments.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

2017-08-03 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399

--- Comment #203 from Nils Beyer  ---
(In reply to Don Lewis from comment #202)

> BTW, using either my origin workaround patch, or the committed version if the 
> sv_maxuser adjustment is commented out, it is possible to use a user process 
> to mmap() the top page of user memory,
> load some code up there, and execute it for testing purposes.  I've done some 
> experiments with that and it is possible to quickly hang the machine or cause 
> it to reboot.

that sounds interesting; do you have source code for that available that I can
try here on my systems, please?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

2017-08-02 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399

--- Comment #202 from Don Lewis  ---
(In reply to Nils Beyer from comment #200)
I believe so.  It's pretty unlikely that the problem is caused by undefined
opcodes, and we are not seeing any evidence (SIGILL) of valid instructions
being trapped as invalid because they experience page faults mid-fetch.

BTW, using either my origin workaround patch, or the committed version if the
sv_maxuser adjustment is commented out, it is possible to use a user process to
mmap() the top page of user memory, load some code up there, and execute it for
testing purposes.  I've done some experiments with that and it is possible to
quickly hang the machine or cause it to reboot.  The interesting thing is that
I haven't observed any ill effects as long as no instructions are executed
above 0x7f40.  That's sort of in the area mentioned in the Dragonfly
fix, but even they saw issues at addresses lower than that and a decreasing
rate as the address was lowered.  Our signal trampoline code was much closer to
the bottom of the page at 0x7000, so at this point I don't know why we
were having problems.  The only thing that I can think of is that the signal
trampoline code uses some unusual instructions like syscall and hlt, which are
unlike the more vanilla instructions that I was using in my experiments.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

2017-08-02 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399

--- Comment #201 from Nils Beyer  ---
(In reply to Nils Beyer from comment #200)

maybe the artificial intelligence inside the Ryzen is freaking out... I don't
know:

http://www.bbspot.com/Images/Comics/2008/2008-02-06_pcw.jpg

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

2017-08-02 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399

--- Comment #200 from Nils Beyer  ---
(In reply to Don Lewis from comment #198)

so, we're on the wrong track with "sandsifter" in order to find out what's
buggy in the CPU and how to possibly circumvent it, correct?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

2017-08-02 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399

--- Comment #199 from Nils Beyer  ---
(In reply to Nils Beyer from comment #197)

it's still running; as a side note: I cannot tell whether the overclocking is
really noticeable regarding compilation performance - I think I'll have to wait
until the complete run is finished. At least, I can notice in the sensor
readings that something has changed:
-

MBTEMP:   40
CPUTEMP:  66
AUXTEMP0: 14
AUXTEMP1: 29
AUXTEMP2: 23
AUXTEMP3: 231

VCORE:.656000
+3.3V:3.328000
VSOC: .936000

SYSFAN:   11529
CPUFAN:   4356
AUXFAN0:  65311
AUXFAN1:  65311
AUXFAN2:  65311

-

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

2017-08-02 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399

--- Comment #198 from Don Lewis  ---
(In reply to rozhuk.im from comment #190)
The slide deck here:
 
https://github.com/xoreaxeaxeax/sandsifter/blob/master/references/domas_breaking_the_x86_isa.pdf
is pretty informative.  It turns out that this problem affects the Geode.  The
difference in behavior is mentioned in Table 8-8 of the document that I
previously sited.

I think what is happening is that is that in the case of invalid instructions,
the hardware still does a preliminary determination of their length to
determine how many bytes to fetch.  If a page fault happens while fetching the
remaining bytes, then a page fault exception is supposed to happen, but in this
case, the hardware has already decided that the instruction is invalid and
raises an undefined instruction exception instead.

It looks to me like the only real damage is that this breaks the algorithm that
sandsifter uses to determine instruction lengths.  It doesn't look like it
causes valid instructions to be flagged as invalid if they can't be fetched
without causing a page fault.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

2017-08-02 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399

Nils Beyer  changed:

   What|Removed |Added

   See Also||https://bugs.freebsd.org/bu
   ||gzilla/show_bug.cgi?id=2210
   ||29

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

2017-08-02 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399

Nils Beyer  changed:

   What|Removed |Added

 Blocks||221029


Referenced Bugs:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029
[Bug 221029] AMD Ryzen: strange compilation failures using poudriere or plain
buildkernel/buildworld
-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

1 2 3 >

1 - 100 of 288 matches

Mail list logo