Current-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Serious crashes on 9.99.93



Dear current-users,

On 2021-12-28, pin wrote:
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> 
> Unfortunately, I had to wipe my disk due to a corrupted file system.
> I did a fresh install using the 9.99.93 image from today 28-Dec-2021 08:57
> 
> The same crash happened the first time I launched the web browser.
> This time I got a stack backtrace, as follows:
> 
> ----
> pin@mybox # pwd
> /var/crash
> pin@mybox # ls -l
> total 797032
> -rw-------  1 root  wheel          2 Dec 28 20:41 bounds
> -rw-------  1 root  wheel          5 Dec 28 00:19 minfree
> -rw-------  1 root  wheel    2332254 Dec 28 20:41 netbsd.0
> -rw-------  1 root  wheel  405485080 Dec 28 20:41 netbsd.0.core
> pin@mybox # gdb --eval-command="file /netbsd.gdb"
> GNU gdb (GDB) 11.0.50.20200914-git
> Copyright (C) 2020 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> 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--netbsd".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> <https://www.gnu.org/software/gdb/bugs/>.
> Find the GDB manual and other documentation resources online at:
>     <http://www.gnu.org/software/gdb/documentation/>.
> 
> For help, type "help".
> Type "apropos word" to search for commands related to "word".
> Reading symbols from /netbsd.gdb...
> (gdb) target kvm netbsd.0.core
> 0xffffffff802261f5 in cpu_reboot (howto=howto@entry=260, bootstr=bootstr@entry=0x0) at /usr/src/sys/arch/amd64/amd64/machdep.c:720
> 720     /usr/src/sys/arch/amd64/amd64/machdep.c: No such file or directory.
> (gdb) bt
> #0  0xffffffff802261f5 in cpu_reboot (howto=howto@entry=260, bootstr=bootstr@entry=0x0) at /usr/src/sys/arch/amd64/amd64/machdep.c:720
> #1  0xffffffff80dbcd54 in kern_reboot (howto=howto@entry=260, bootstr=bootstr@entry=0x0) at /usr/src/sys/kern/kern_reboot.c:73
> #2  0xffffffff80dffcf2 in vpanic (fmt=fmt@entry=0xffffffff81390370 "trap", ap=ap@entry=0xffff8580b77ebab8) at /usr/src/sys/kern/subr_prf.c:290
> #3  0xffffffff80dffdb7 in panic (fmt=fmt@entry=0xffffffff81390370 "trap") at /usr/src/sys/kern/subr_prf.c:209
> #4  0xffffffff80229017 in trap (frame=0xffff8580b77ebc00) at /usr/src/sys/arch/amd64/amd64/trap.c:326
> #5  0xffffffff802210e3 in alltraps ()
> #6  0xff404040ff404040 in ?? ()
> #7  0x0000000000000019 in ?? ()
> #8  0xffff80f752dea000 in ?? ()
> #9  0x0000000000000000 in ?? ()
> (gdb)
> 
> ----
> 
> This did not happen before on 9.99.92 up to the 15th of December.
> Hope that this is useful.
> 
> Best Regards

I tried to reproduce the problems that pin is seeing. I seldom got
as far as the web browser, but did get the following backtraces:

  Crash version 9.99.42, image version 9.99.93.
  WARNING: versions differ, you may not be able to examine this image.
  System panicked: pr_phinpage_check: [i915_request] item 0xffff939b82a4f840 not part of pool
  Backtrace from time of crash is available.
  _KERNEL_OPT_GENFB_GLYPHCACHE() at 0
  _KERNEL_OPT_GENFB_GLYPHCACHE() at 0
  sys_reboot() at sys_reboot
  vpanic() at vpanic+0x160
  device_printf() at device_printf
  pool_cache_put_paddr() at pool_cache_put_paddr+0x14f
  linux_dma_resv_fini() at linux_dma_resv_fini+0x55
  __i915_gem_free_object_rcu() at __i915_gem_free_object_rcu+0x45
  gc_thread() at gc_thread+0x92

  Crash version 9.99.42, image version 9.99.93.
  WARNING: versions differ, you may not be able to examine this image.
  System panicked: trap
  Backtrace from time of crash is available.
  _KERNEL_OPT_GENFB_GLYPHCACHE() at 0
  ?() at ffffbf014f2a0000
  sys_reboot() at sys_reboot
  vpanic() at vpanic+0x160
  device_printf() at device_printf
  startlwp() at startlwp
  calltrap() at calltrap+0x19
  ffs_sync() at ffs_sync+0x75
  VFS_SYNC() at VFS_SYNC+0x22
  sched_sync() at sched_sync+0x90

Could the first backtrace be a clue? Changes were made in this area after the 15th,
which is when pin still had a stable kernel.

-- 
Kind regards,

Yorick Hardy


Home | Main Index | Thread Index | Old Index