drm-current-kmod panics
Has anyone else had these since Dec 9? <4>WARN_ON(!mutex_is_locked(&fbc->lock))WARN_ON(!mutex_is_locked(&fbc-> lock)) panic: page fault cpuid = 1 time = 1576772837 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe007c98b930 vpanic() at vpanic+0x17e/frame 0xfe007c98b990 panic() at panic+0x43/frame 0xfe007c98b9f0 trap_fatal() at trap_fatal+0x386/frame 0xfe007c98ba50 trap_pfault() at trap_pfault+0x4f/frame 0xfe007c98bac0 trap() at trap+0x41b/frame 0xfe007c98bbf0 calltrap() at calltrap+0x8/frame 0xfe007c98bbf0 --- trap 0xc, rip = 0x242c52, rsp = 0x7fffbe70, rbp = 0x7fffbe90 --- Uptime: 59m7s It is triggered through random keystrokes or mouse movements. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: drm-current-kmod panics
On 2019-12-19 17:50, Cy Schubert wrote: Has anyone else had these since Dec 9? <4>WARN_ON(!mutex_is_locked(&fbc->lock))WARN_ON(!mutex_is_locked(&fbc-> lock)) panic: page fault cpuid = 1 time = 1576772837 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe007c98b930 vpanic() at vpanic+0x17e/frame 0xfe007c98b990 panic() at panic+0x43/frame 0xfe007c98b9f0 trap_fatal() at trap_fatal+0x386/frame 0xfe007c98ba50 trap_pfault() at trap_pfault+0x4f/frame 0xfe007c98bac0 trap() at trap+0x41b/frame 0xfe007c98bbf0 calltrap() at calltrap+0x8/frame 0xfe007c98bbf0 --- trap 0xc, rip = 0x242c52, rsp = 0x7fffbe70, rbp = 0x7fffbe90 --- Uptime: 59m7s It is triggered through random keystrokes or mouse movements. Looks like a double fault. Did you recompile drm-current-kmod with the latest kernel sources? --HPS ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: drm-current-kmod panics
In message , Hans Petter Sela sky writes: > On 2019-12-19 17:50, Cy Schubert wrote: > > Has anyone else had these since Dec 9? > > > > <4>WARN_ON(!mutex_is_locked(&fbc->lock))WARN_ON(!mutex_is_locked(&fbc-> > > lock)) > > panic: page fault > > cpuid = 1 > > time = 1576772837 > > KDB: stack backtrace: > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > > 0xfe007c98b930 > > vpanic() at vpanic+0x17e/frame 0xfe007c98b990 > > panic() at panic+0x43/frame 0xfe007c98b9f0 > > trap_fatal() at trap_fatal+0x386/frame 0xfe007c98ba50 > > trap_pfault() at trap_pfault+0x4f/frame 0xfe007c98bac0 > > trap() at trap+0x41b/frame 0xfe007c98bbf0 > > calltrap() at calltrap+0x8/frame 0xfe007c98bbf0 > > --- trap 0xc, rip = 0x242c52, rsp = 0x7fffbe70, rbp = 0x7fffbe90 -- > - > > Uptime: 59m7s > > > > It is triggered through random keystrokes or mouse movements. > > Looks like a double fault. > > Did you recompile drm-current-kmod with the latest kernel sources? Yes. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: New external GCC toolchain ports/packages
On 12/18/19 4:16 PM, Mark Millard wrote: > > > On 2019-Dec-18, at 13:48, John Baldwin wrote: > >> In the interest of supporting newer versions of GCC for a base system >> toolchain, I've renamed the external GCC packages from -gcc >> to -gcc6. These are built as flavors of a new devel/freebsd-gcc6 >> port. The xtoolchain package is not used for these new packages, instead >> one does 'pkg install mips-gcc6' to get the GCC 6.x MIPS compiler and >> uses 'CROSS_TOOLCHAIN=mips-gcc6'. I've also gone ahead and updated this >> compiler to 6.5.0. >> >> I will leave the old ports/packages around for now to permit an easy >> transition, but going forward, the -gcc6 packages should be preferred >> to -xtoolchain-gcc for all but riscv (riscv64-gcc and >> riscv64-xtoolchain-gcc >> are separate from the powerpc64-gcc set of packages). >> >> In addition, I've also just added a devel/freebsd-gcc9 package which >> builds -gcc9 packages. It adds powerpc and riscv flavors relative >> to freebsd-gcc6 and uses GCC 9.2.0. To date in my testing I've yet to >> be able to finish a buildworld on any of the platforms I've tried >> (amd64, mips, sparc64), but the packages should permit other developers >> to get the tree building with GCC 9. To use these packages one would do >> something like: >> >> # pkg install amd64-gcc9 >> # make buildworld CROSS_TOOLCHAIN=amd64-gcc9 >> >> You can install both the gcc6 and gcc9 versions of a package at the same >> time, e.g. amd64-gcc6 and amd64-gcc9. Having different packages for major >> versions is similar to llvm and will also let us keep a known-good >> toolchain package for older releases while using newer major versions on >> newer FreeBSD releases (e.g gcc9 for 13.0 and gcc6 for 12.x). >> >> I do plan to switch the default toolchains for make universe/tinderbox >> for targets using -xtoolchain-gcc based on GCC 6 over to the >> freebsd-gcc6 variants in the next week or so. >> > > How about base/binutils and base/gcc ? Is their (future?) status > changed by any of this activity? I plan to rename base/gcc to base/gcc6 (and update it to 6.5) and then add a base/gcc9 that would provide GCC 9 as /usr/bin/cc. -- John Baldwin ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: drm-current-kmod panics
On 2019-12-19 19:40, Cy Schubert wrote: In message , Hans Petter Sela sky writes: On 2019-12-19 17:50, Cy Schubert wrote: Has anyone else had these since Dec 9? <4>WARN_ON(!mutex_is_locked(&fbc->lock))WARN_ON(!mutex_is_locked(&fbc-> lock)) panic: page fault cpuid = 1 time = 1576772837 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe007c98b930 vpanic() at vpanic+0x17e/frame 0xfe007c98b990 panic() at panic+0x43/frame 0xfe007c98b9f0 trap_fatal() at trap_fatal+0x386/frame 0xfe007c98ba50 trap_pfault() at trap_pfault+0x4f/frame 0xfe007c98bac0 trap() at trap+0x41b/frame 0xfe007c98bbf0 calltrap() at calltrap+0x8/frame 0xfe007c98bbf0 --- trap 0xc, rip = 0x242c52, rsp = 0x7fffbe70, rbp = 0x7fffbe90 -- - Uptime: 59m7s It is triggered through random keystrokes or mouse movements. Looks like a double fault. Did you recompile drm-current-kmod with the latest kernel sources? Yes. Are you able to get a full backtrace? --HPS ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: drm-current-kmod panics
In message , Hans Petter Sela sky writes: > On 2019-12-19 19:40, Cy Schubert wrote: > > In message , Hans Petter > > Sela > > sky writes: > >> On 2019-12-19 17:50, Cy Schubert wrote: > >>> Has anyone else had these since Dec 9? > >>> > >>> <4>WARN_ON(!mutex_is_locked(&fbc->lock))WARN_ON(!mutex_is_locked(&fbc-> > >>> lock)) > >>> panic: page fault > >>> cpuid = 1 > >>> time = 1576772837 > >>> KDB: stack backtrace: > >>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > >>> 0xfe007c98b930 > >>> vpanic() at vpanic+0x17e/frame 0xfe007c98b990 > >>> panic() at panic+0x43/frame 0xfe007c98b9f0 > >>> trap_fatal() at trap_fatal+0x386/frame 0xfe007c98ba50 > >>> trap_pfault() at trap_pfault+0x4f/frame 0xfe007c98bac0 > >>> trap() at trap+0x41b/frame 0xfe007c98bbf0 > >>> calltrap() at calltrap+0x8/frame 0xfe007c98bbf0 > >>> --- trap 0xc, rip = 0x242c52, rsp = 0x7fffbe70, rbp = 0x7fffbe90 > -- > >> - > >>> Uptime: 59m7s > >>> > >>> It is triggered through random keystrokes or mouse movements. > >> > >> Looks like a double fault. > >> > >> Did you recompile drm-current-kmod with the latest kernel sources? > > > > Yes. > > > > > > Are you able to get a full backtrace? (kgdb) #0 __curthread () at /opt/src/svn-current/sys/amd64/include/pcpu_aux .h:5 5 #1 doadump (textdump=1) at /opt/src/svn-current/sys/kern/kern_shutdown.c:39 2 #2 0x80690a2a in kern_reboot (howto=260) at /opt/src/svn-current/sys/kern/kern_shutdown.c:479 #3 0x80690ec6 in vpanic (fmt=, ap=) at /opt/src/svn-current/sys/kern/kern_shutdown.c:908 #4 0x80690ce3 in panic (fmt=) at /opt/src/svn-current/sys/kern/kern_shutdown.c:835 #5 0x80a31c06 in trap_fatal (frame=0xfe007c98bc00, eva=2928416) at /opt/src/svn-current/sys/amd64/amd64/trap.c:926 #6 0x80a31c5f in trap_pfault (frame=0xfe007c98bc00, usermode=, signo=, ucode=) at /opt/src/svn-current/sys/amd64/amd64/trap.c:743 #7 0x80a3144b in trap (frame=0xfe007c98bc00) at /opt/src/svn-current/sys/amd64/amd64/trap.c:347 #8 #9 0x00242c52 in ?? () Backtrace stopped: Cannot access memory at address 0x7fffbe70 (kgdb) I also tried drm-legacy-kmod this morning before heading off to work. It wouldn't panic but a hard hang. At least drm-current-kmod panics. I suspect some of It's interesting to note that though the first occurrence of this panic occurred on Dec 9, it is more frequent now. -rw--- 1 root wheel 476 Dec 9 18:53 /var/crash/info.0 -rw--- 1 root wheel 517 Dec 16 12:28 /var/crash/info.1 -rw--- 1 root wheel 473 Dec 18 10:26 /var/crash/info.2 -rw--- 1 root wheel 476 Dec 18 12:35 /var/crash/info.3 -rw--- 1 root wheel 476 Dec 19 08:31 /var/crash/info.4 My workload hasn't changed. Random mouse clicks or key presses trigger it. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: drm-current-kmod panics
On Thu, 19 Dec 2019, Hans Petter Selasky wrote: On 2019-12-19 19:40, Cy Schubert wrote: In message , Hans Petter Sela sky writes: On 2019-12-19 17:50, Cy Schubert wrote: Has anyone else had these since Dec 9? <4>WARN_ON(!mutex_is_locked(&fbc->lock))WARN_ON(!mutex_is_locked(&fbc-> lock)) panic: page fault cpuid = 1 time = 1576772837 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe007c98b930 vpanic() at vpanic+0x17e/frame 0xfe007c98b990 panic() at panic+0x43/frame 0xfe007c98b9f0 trap_fatal() at trap_fatal+0x386/frame 0xfe007c98ba50 trap_pfault() at trap_pfault+0x4f/frame 0xfe007c98bac0 trap() at trap+0x41b/frame 0xfe007c98bbf0 calltrap() at calltrap+0x8/frame 0xfe007c98bbf0 --- trap 0xc, rip = 0x242c52, rsp = 0x7fffbe70, rbp = 0x7fffbe90 -- - Uptime: 59m7s It is triggered through random keystrokes or mouse movements. Looks like a double fault. Did you recompile drm-current-kmod with the latest kernel sources? Yes. Are you able to get a full backtrace? Since my recent scheduler commits the following functions now return without the thread lock held: sched_add()/sched_wakeup()/sched_switch()/mi_switch()/setrunnable()/sleepq_abort() I audited drm and linuxkpi for use of these functions. There was one in the linuxkpi sources that I corrected in the same commit as the change in api. I don't see any users of these in drm-current-kmod. It is possible that I have somehow missed it. I did just commit a fix to cpuset that may be called indirectly somehow. That fix is r355915. The first commit of this series was r35579. If this is at fault I may need some assistance in identifying what the offending call is. It should show up with INVARIANTS/WITNESS more quickly than a pagefault if so though. Thanks, Jeff --HPS ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: drm-current-kmod panics
On 2019-12-19 20:12, Cy Schubert wrote: In message , Hans Petter Sela sky writes: On 2019-12-19 19:40, Cy Schubert wrote: In message , Hans Petter Sela sky writes: On 2019-12-19 17:50, Cy Schubert wrote: Has anyone else had these since Dec 9? <4>WARN_ON(!mutex_is_locked(&fbc->lock))WARN_ON(!mutex_is_locked(&fbc-> lock)) panic: page fault cpuid = 1 time = 1576772837 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe007c98b930 vpanic() at vpanic+0x17e/frame 0xfe007c98b990 panic() at panic+0x43/frame 0xfe007c98b9f0 trap_fatal() at trap_fatal+0x386/frame 0xfe007c98ba50 trap_pfault() at trap_pfault+0x4f/frame 0xfe007c98bac0 trap() at trap+0x41b/frame 0xfe007c98bbf0 calltrap() at calltrap+0x8/frame 0xfe007c98bbf0 --- trap 0xc, rip = 0x242c52, rsp = 0x7fffbe70, rbp = 0x7fffbe90 -- - Uptime: 59m7s It is triggered through random keystrokes or mouse movements. Looks like a double fault. Did you recompile drm-current-kmod with the latest kernel sources? Yes. Are you able to get a full backtrace? (kgdb) #0 __curthread () at /opt/src/svn-current/sys/amd64/include/pcpu_aux .h:5 5 #1 doadump (textdump=1) at /opt/src/svn-current/sys/kern/kern_shutdown.c:39 2 #2 0x80690a2a in kern_reboot (howto=260) at /opt/src/svn-current/sys/kern/kern_shutdown.c:479 #3 0x80690ec6 in vpanic (fmt=, ap=) at /opt/src/svn-current/sys/kern/kern_shutdown.c:908 #4 0x80690ce3 in panic (fmt=) at /opt/src/svn-current/sys/kern/kern_shutdown.c:835 #5 0x80a31c06 in trap_fatal (frame=0xfe007c98bc00, eva=2928416) at /opt/src/svn-current/sys/amd64/amd64/trap.c:926 #6 0x80a31c5f in trap_pfault (frame=0xfe007c98bc00, usermode=, signo=, ucode=) at /opt/src/svn-current/sys/amd64/amd64/trap.c:743 #7 0x80a3144b in trap (frame=0xfe007c98bc00) at /opt/src/svn-current/sys/amd64/amd64/trap.c:347 #8 #9 0x00242c52 in ?? () Backtrace stopped: Cannot access memory at address 0x7fffbe70 (kgdb) I also tried drm-legacy-kmod this morning before heading off to work. It wouldn't panic but a hard hang. At least drm-current-kmod panics. I suspect some of It's interesting to note that though the first occurrence of this panic occurred on Dec 9, it is more frequent now. -rw--- 1 root wheel 476 Dec 9 18:53 /var/crash/info.0 -rw--- 1 root wheel 517 Dec 16 12:28 /var/crash/info.1 -rw--- 1 root wheel 473 Dec 18 10:26 /var/crash/info.2 -rw--- 1 root wheel 476 Dec 18 12:35 /var/crash/info.3 -rw--- 1 root wheel 476 Dec 19 08:31 /var/crash/info.4 My workload hasn't changed. Random mouse clicks or key presses trigger it. Can you try to get the very latest FreeBSD SVN (r355915) First rebuild the kernel and then rebuild the module. Also make sure you do "porsnap fetch update" to get the latest drm-current-kmod port. --HPS ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: drm-current-kmod panics
In message <6f60d4b5-8abe-573c-7140-9b449f3dd...@selasky.org>, Hans Petter Sela sky writes: > On 2019-12-19 20:12, Cy Schubert wrote: > > In message , Hans Petter > > Sela > > sky writes: > >> On 2019-12-19 19:40, Cy Schubert wrote: > >>> In message , Hans Pette > r > >>> Sela > >>> sky writes: > On 2019-12-19 17:50, Cy Schubert wrote: > > Has anyone else had these since Dec 9? > > > > <4>WARN_ON(!mutex_is_locked(&fbc->lock))WARN_ON(!mutex_is_locked(&fbc-> > > lock)) > > panic: page fault > > cpuid = 1 > > time = 1576772837 > > KDB: stack backtrace: > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > > 0xfe007c98b930 > > vpanic() at vpanic+0x17e/frame 0xfe007c98b990 > > panic() at panic+0x43/frame 0xfe007c98b9f0 > > trap_fatal() at trap_fatal+0x386/frame 0xfe007c98ba50 > > trap_pfault() at trap_pfault+0x4f/frame 0xfe007c98bac0 > > trap() at trap+0x41b/frame 0xfe007c98bbf0 > > calltrap() at calltrap+0x8/frame 0xfe007c98bbf0 > > --- trap 0xc, rip = 0x242c52, rsp = 0x7fffbe70, rbp = 0x7fffbe9 > 0 > >> -- > - > > Uptime: 59m7s > > > > It is triggered through random keystrokes or mouse movements. > > Looks like a double fault. > > Did you recompile drm-current-kmod with the latest kernel sources? > >>> > >>> Yes. > >>> > >>> > >> > >> Are you able to get a full backtrace? > > > > (kgdb) #0 __curthread () at /opt/src/svn-current/sys/amd64/include/pcpu_au > x > > .h:5 > > 5 > > #1 doadump (textdump=1) at /opt/src/svn-current/sys/kern/kern_shutdown.c:3 > 9 > > 2 > > #2 0x80690a2a in kern_reboot (howto=260) > > at /opt/src/svn-current/sys/kern/kern_shutdown.c:479 > > #3 0x80690ec6 in vpanic (fmt=, ap=) > > at /opt/src/svn-current/sys/kern/kern_shutdown.c:908 > > #4 0x80690ce3 in panic (fmt=) > > at /opt/src/svn-current/sys/kern/kern_shutdown.c:835 > > #5 0x80a31c06 in trap_fatal (frame=0xfe007c98bc00, eva=2928416 > ) > > at /opt/src/svn-current/sys/amd64/amd64/trap.c:926 > > #6 0x80a31c5f in trap_pfault (frame=0xfe007c98bc00, > > usermode=, signo=, ucode= > ) > > at /opt/src/svn-current/sys/amd64/amd64/trap.c:743 > > #7 0x80a3144b in trap (frame=0xfe007c98bc00) > > at /opt/src/svn-current/sys/amd64/amd64/trap.c:347 > > #8 > > #9 0x00242c52 in ?? () > > Backtrace stopped: Cannot access memory at address 0x7fffbe70 > > (kgdb) > > > > I also tried drm-legacy-kmod this morning before heading off to work. It > > wouldn't panic but a hard hang. At least drm-current-kmod panics. I suspect > > some of > > > > It's interesting to note that though the first occurrence of this panic > > occurred on Dec 9, it is more frequent now. > > > > -rw--- 1 root wheel 476 Dec 9 18:53 /var/crash/info.0 > > -rw--- 1 root wheel 517 Dec 16 12:28 /var/crash/info.1 > > -rw--- 1 root wheel 473 Dec 18 10:26 /var/crash/info.2 > > -rw--- 1 root wheel 476 Dec 18 12:35 /var/crash/info.3 > > -rw--- 1 root wheel 476 Dec 19 08:31 /var/crash/info.4 > > > > My workload hasn't changed. Random mouse clicks or key presses trigger it. > > > > > > Can you try to get the very latest FreeBSD SVN (r355915) Sure. Already running r355910 > > First rebuild the kernel and then rebuild the module. Also make sure you > do "porsnap fetch update" to get the latest drm-current-kmod port. I'm already on the latest drm-current-kmod. I'll try r355915. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: New external GCC toolchain ports/packages
On Wed, Dec 18, 2019 at 1:49 PM John Baldwin wrote: > > In the interest of supporting newer versions of GCC for a base system > toolchain, I've renamed the external GCC packages from -gcc > to -gcc6. These are built as flavors of a new devel/freebsd-gcc6 > port. The xtoolchain package is not used for these new packages, instead > one does 'pkg install mips-gcc6' to get the GCC 6.x MIPS compiler and > uses 'CROSS_TOOLCHAIN=mips-gcc6'. I've also gone ahead and updated this > compiler to 6.5.0. > > I will leave the old ports/packages around for now to permit an easy > transition, but going forward, the -gcc6 packages should be preferred > to -xtoolchain-gcc for all but riscv (riscv64-gcc and > riscv64-xtoolchain-gcc > are separate from the powerpc64-gcc set of packages). > > In addition, I've also just added a devel/freebsd-gcc9 package which > builds -gcc9 packages. It adds powerpc and riscv flavors relative > to freebsd-gcc6 and uses GCC 9.2.0. To date in my testing I've yet to > be able to finish a buildworld on any of the platforms I've tried > (amd64, mips, sparc64), but the packages should permit other developers > to get the tree building with GCC 9. To use these packages one would do > something like: > > # pkg install amd64-gcc9 > # make buildworld CROSS_TOOLCHAIN=amd64-gcc9 > > You can install both the gcc6 and gcc9 versions of a package at the same > time, e.g. amd64-gcc6 and amd64-gcc9. Having different packages for major > versions is similar to llvm and will also let us keep a known-good > toolchain package for older releases while using newer major versions on > newer FreeBSD releases (e.g gcc9 for 13.0 and gcc6 for 12.x). > > I do plan to switch the default toolchains for make universe/tinderbox > for targets using -xtoolchain-gcc based on GCC 6 over to the > freebsd-gcc6 variants in the next week or so. > > -- > John Baldwin Awesome, thanks! I was able to get amd64 buildworld and buildkernel to succeed with just a few changes, and none to the port. I'll work on getting the changes in. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: drm-current-kmod panics
In message <6f60d4b5-8abe-573c-7140-9b449f3dd...@selasky.org>, Hans Petter Sela sky writes: > On 2019-12-19 20:12, Cy Schubert wrote: > > In message , Hans Petter > > Sela > > sky writes: > >> On 2019-12-19 19:40, Cy Schubert wrote: > >>> In message , Hans Pette > r > >>> Sela > >>> sky writes: > On 2019-12-19 17:50, Cy Schubert wrote: > > Has anyone else had these since Dec 9? > > > > <4>WARN_ON(!mutex_is_locked(&fbc->lock))WARN_ON(!mutex_is_locked(&fbc-> > > lock)) > > panic: page fault > > cpuid = 1 > > time = 1576772837 > > KDB: stack backtrace: > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > > 0xfe007c98b930 > > vpanic() at vpanic+0x17e/frame 0xfe007c98b990 > > panic() at panic+0x43/frame 0xfe007c98b9f0 > > trap_fatal() at trap_fatal+0x386/frame 0xfe007c98ba50 > > trap_pfault() at trap_pfault+0x4f/frame 0xfe007c98bac0 > > trap() at trap+0x41b/frame 0xfe007c98bbf0 > > calltrap() at calltrap+0x8/frame 0xfe007c98bbf0 > > --- trap 0xc, rip = 0x242c52, rsp = 0x7fffbe70, rbp = 0x7fffbe9 > 0 > >> -- > - > > Uptime: 59m7s > > > > It is triggered through random keystrokes or mouse movements. > > Looks like a double fault. > > Did you recompile drm-current-kmod with the latest kernel sources? > >>> > >>> Yes. > >>> > >>> > >> > >> Are you able to get a full backtrace? > > > > (kgdb) #0 __curthread () at /opt/src/svn-current/sys/amd64/include/pcpu_au > x > > .h:5 > > 5 > > #1 doadump (textdump=1) at /opt/src/svn-current/sys/kern/kern_shutdown.c:3 > 9 > > 2 > > #2 0x80690a2a in kern_reboot (howto=260) > > at /opt/src/svn-current/sys/kern/kern_shutdown.c:479 > > #3 0x80690ec6 in vpanic (fmt=, ap=) > > at /opt/src/svn-current/sys/kern/kern_shutdown.c:908 > > #4 0x80690ce3 in panic (fmt=) > > at /opt/src/svn-current/sys/kern/kern_shutdown.c:835 > > #5 0x80a31c06 in trap_fatal (frame=0xfe007c98bc00, eva=2928416 > ) > > at /opt/src/svn-current/sys/amd64/amd64/trap.c:926 > > #6 0x80a31c5f in trap_pfault (frame=0xfe007c98bc00, > > usermode=, signo=, ucode= > ) > > at /opt/src/svn-current/sys/amd64/amd64/trap.c:743 > > #7 0x80a3144b in trap (frame=0xfe007c98bc00) > > at /opt/src/svn-current/sys/amd64/amd64/trap.c:347 > > #8 > > #9 0x00242c52 in ?? () > > Backtrace stopped: Cannot access memory at address 0x7fffbe70 > > (kgdb) > > > > I also tried drm-legacy-kmod this morning before heading off to work. It > > wouldn't panic but a hard hang. At least drm-current-kmod panics. I suspect > > some of > > > > It's interesting to note that though the first occurrence of this panic > > occurred on Dec 9, it is more frequent now. > > > > -rw--- 1 root wheel 476 Dec 9 18:53 /var/crash/info.0 > > -rw--- 1 root wheel 517 Dec 16 12:28 /var/crash/info.1 > > -rw--- 1 root wheel 473 Dec 18 10:26 /var/crash/info.2 > > -rw--- 1 root wheel 476 Dec 18 12:35 /var/crash/info.3 > > -rw--- 1 root wheel 476 Dec 19 08:31 /var/crash/info.4 > > > > My workload hasn't changed. Random mouse clicks or key presses trigger it. > > > > > > Can you try to get the very latest FreeBSD SVN (r355915) > > First rebuild the kernel and then rebuild the module. Also make sure you > do "porsnap fetch update" to get the latest drm-current-kmod port. The new kernel has been built and installed. Let's give it a couple of days before considering it fixed. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
r355889 snapshot works fine
I was a bit worried with all the talk in drm changes, but just fine here. AMD Ryzen 7 3700x/MSI 570 chipset Motherboard & Video card I did notice the drm-current-kmod had a date of 12/17/2019: Works fine. dmesg: nvd0: 976762MB (2000409264 512 byte sectors) hdacc0: at cad 0 on hdac0 hdaa0: at nid 1 on hdacc0 pcm0: at nid 3 on hdaa0 pcm1: at nid 5 on hdaa0 pcm2: at nid 7 on hdaa0 pcm3: at nid 9 on hdaa0 pcm4: at nid 11 on hdaa0 pcm5: at nid 13 on hdaa0 hdacc1: at cad 0 on hdac1 hdaa1: at nid 1 on hdacc1 pcm6: at nid 20,22,21 and 24,26 on hdaa1 pcm7: at nid 27 and 25 on hdaa1 pcm8: at nid 30 on hdaa1 Trying to mount root from ufs:/dev/nvd0p2 [rw]... WARNING: WITNESS option enabled, expect reduced performance. ada0 at ahcich3 bus 0 scbus3 target 0 lun 0 ada0: ACS-3 ATA SATA 3.x device ada0: Serial Number ZFL0FRH4 ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 1907729MB (3907029168 512 byte sectors) ada0: quirks=0x1<4K> cd0 at ahcich0 bus 0 scbus0 target 0 lun 0 cd0: Removable CD-ROM SCSI device cd0: Serial Number J8D0CL027235 cd0: 150.000MB/s transfers (SATA 1.x, UDMA6, ATAPI 12bytes, PIO 8192bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed uhub1: 8 ports with 8 removable, self powered uhub0: 10 ports with 10 removable, self powered uhub2: 10 ports with 10 removable, self powered [drm] amdgpu kernel modesetting enabled. drmn0: on vgapci0 vgapci0: child drmn0 requested pci_enable_io vgapci0: child drmn0 requested pci_enable_io [drm] initializing kernel modesetting (POLARIS10 0x1002:0x67DF 0x1462:0x341B 0xEF). [drm] register mmio base: 0xFCF0 [drm] register mmio size: 262144 [drm] PCI I/O BAR is not found. [drm] probing gen 2 caps for device 1022:1483 = 737904/180001e [drm] probing mlw for device 1002:67df = 400903 [drm] UVD is enabled in VM mode [drm] UVD ENC is enabled in VM mode [drm] VCE enabled in VM mode ATOM BIOS: 113V34114-F3 [drm] vm size is 64 GB, 2 levels, block size is 10-bit, fragment size is 9-bit ugen0.2: at usbus0 ukbd0 on uhub2 ukbd0: on usbus0 ugen1.2: at usbus1 kbd2 at ukbd0 drmn0: successfully loaded firmware image with name: amdgpu/polaris10_mc.bin drmn0: VRAM: 8192M 0x00F4 - 0x00F5 (8192M used) drmn0: GTT: 256M 0x - 0x0FFF Successfully added WC MTRR for [0xe000-0xefff]: 0; [drm] Detected VRAM RAM=8192M, BAR=256M [drm] RAM width 256bits GDDR5 [TTM] Zone kernel: Available graphics memory: 8346406 kiB [TTM] Zone dma32: Available graphics memory: 2097152 kiB [TTM] Initializing pool allocator [drm] amdgpu: 8192M of VRAM memory ready [drm] amdgpu: 8192M of GTT memory ready. [drm] GART: num cpu pages 65536, num gpu pages 65536 [drm] PCIE GART of 256M enabled (table at 0x00F40004). [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [drm] Driver supports precise vblank timestamp query. [drm] Connector DP-1: get mode from tunables: [drm] - kern.vt.fb.modes.DP-1 [drm] - kern.vt.fb.default_mode [drm] Connector DP-2: get mode from tunables: [drm] - kern.vt.fb.modes.DP-2 [drm] - kern.vt.fb.default_mode [drm] Connector HDMI-A-1: get mode from tunables: [drm] - kern.vt.fb.modes.HDMI-A-1 [drm] - kern.vt.fb.default_mode [drm] Connector HDMI-A-2: get mode from tunables: [drm] - kern.vt.fb.modes.HDMI-A-2 [drm] - kern.vt.fb.default_mode [drm] Connector DVI-D-1: get mode from tunables: [drm] - kern.vt.fb.modes.DVI-D-1 [drm] - kern.vt.fb.default_mode [drm] AMDGPU Display Connectors [drm] Connector 0: [drm] DP-1 [drm] HPD6 [drm] DDC: 0x4868 0x4868 0x4869 0x4869 0x486a 0x486a 0x486b 0x486b [drm] Encoders: [drm] DFP1: INTERNAL_UNIPHY2 [drm] Connector 1: [drm] DP-2 [drm] HPD4 [drm] DDC: 0x4870 0x4870 0x4871 0x4871 0x4872 0x4872 0x4873 0x4873 [drm] Encoders: [drm] DFP2: INTERNAL_UNIPHY2 [drm] Connector 2: [drm] HDMI-A-1 [drm] HPD1 [drm] DDC: 0x486c 0x486c 0x486d 0x486d 0x486e 0x486e 0x486f 0x486f [drm] Encoders: [drm] DFP3: INTERNAL_UNIPHY1 [drm] Connector 3: [drm] HDMI-A-2 [drm] HPD5 [drm] DDC: 0x4874 0x4874 0x4875 0x4875 0x4876 0x4876 0x4877 0x4877 [drm] Encoders: [drm] DFP4: INTERNAL_UNIPHY1 [drm] Connector 4: [drm] DVI-D-1 [drm] HPD3 [drm] DDC: 0x487c 0x487c 0x487d 0x487d 0x487e 0x487e 0x487f 0x487f [drm] Encoders: [drm] DFP5: INTERNAL_UNIPHY drmn0: successfully loaded firmware image with name: amdgpu/polaris10_pfp_2.bin ugen1.3: at usbus1 uhub3 on uhub0 uhub3: on usbus1 ugen0.3: at usbus0 drmn0: successfully loaded firmware image with name: amdgpu/polaris10_me_2.bin uhub3: 4 ports with 4 removable, self powered drmn0: successfully loaded firmware image with name: amdgpu/polaris10_ce_2.bin [drm] Chained IB support enabled! drmn0: successfully loaded firmware image with name: amdgpu/polaris10_rlc.bin drmn0: successfully loaded firmware image with name: amdgpu/polaris10_mec_2.bin drmn0: successfully loaded firmware image with name: amdgpu
