Date: Tue, 3 Jul 2018 16:01:59 -0700 From: John Baldwin <jhb@FreeBSD.org> To: Matthew Macy <mat.macy@gmail.com>, Pete Wright <pete@nomadlogic.org> Cc: FreeBSD Current <freebsd-current@freebsd.org>, Niclas Zeising <zeising+freebsd@daemonic.se>, "O. Hartmann" <ohartmann@walstatt.org> Subject: Re: atomic changes break drm-next-kmod? Message-ID: <f28cd724-c0ae-353f-833a-5f7c51b807ac@FreeBSD.org> In-Reply-To: <CAPrugNqvDKS8883wDWHiMJ1%2BhiRx5BfQaLJ3882X3RQrUgzP=w@mail.gmail.com> References: <c640afcd-1fa4-a43e-5f36-f0bd11aad63d@protected-networks.net> <20180703170223.266dbf5b@thor.intern.walstatt.dynvpn.de> <cbd2d2f2-8ce4-871a-9aaf-75738d6c465b@daemonic.se> <ee0f7fce-7ce3-3784-f9e8-0f6862d59303@FreeBSD.org> <c7a3b447-00e9-8501-0484-841a371cfd62@nomadlogic.org> <bb2cac77-4bcd-c87c-9bc9-ce5f8ce1c726@nomadlogic.org> <845aca10-8c01-fa3b-087f-f957df4e7531@nomadlogic.org> <063ae5c3-0584-1284-dd9d-ab8b5790baf1@FreeBSD.org> <0bf8e57b-fdb4-4c1a-3d0d-a734f8187ca8@nomadlogic.org> <CAPrugNqvDKS8883wDWHiMJ1%2BhiRx5BfQaLJ3882X3RQrUgzP=w@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 7/3/18 3:40 PM, Matthew Macy wrote: > This seems like a clang inline asm bug. Could you try building the port with a recent gcc against an unpatched HEAD? I've already committed the patch to HEAD, but using 'e' is from the GCC docs, not clang docs: https://gcc.gnu.org/onlinedocs/gcc/Machine-Constraints.html#Machine-Constraints The disassembly of one of the functions from the kmod using one of the affected atomic ops would show if it is working correctly (there should now be a mov with a 64-bit immediate into a register followed by the atomic op using a register operand). You could also try using just 'r' to always force the use of a register. It would be less optimal than "er" but should function correctly. > On Tue, Jul 3, 2018 at 15:38 Pete Wright <pete@nomadlogic.org <mailto:pete@nomadlogic.org>> wrote: > > > > On 07/03/2018 15:29, John Baldwin wrote: > > That seems like kgdb is looking at the wrong CPU. Can you use > > 'info threads' and look for threads not stopped in 'sched_switch' > > and get their backtraces? You could also just do 'thread apply > > all bt' and put that file at a URL if that is easiest. > > > > > sure thing John - here's a gist of "thread apply all bt" > > https://gist.github.com/gem-pete/d8d7ab220dc8781f0827f965f09d43ed > > cheers! > -pete > > -- > Pete Wright > pete@nomadlogic.org <mailto:pete@nomadlogic.org> > @nomadlogicLA > > _______________________________________________ > freebsd-current@freebsd.org <mailto:freebsd-current@freebsd.org> mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org <mailto:freebsd-current-unsubscribe@freebsd.org>" > -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?f28cd724-c0ae-353f-833a-5f7c51b807ac>