Date: Wed, 02 Aug 2017 16:42:49 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen... Message-ID: <bug-219399-8-6fc6YbEQf0@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-219399-8@https.bugs.freebsd.org/bugzilla/> References: <bug-219399-8@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D219399 --- Comment #198 from Don Lewis <truckman@FreeBSD.org> --- (In reply to rozhuk.im from comment #190) The slide deck here: =20 https://github.com/xoreaxeaxeax/sandsifter/blob/master/references/domas_bre= aking_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 instructio= ns, 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. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-219399-8-6fc6YbEQf0>