On Tue, Apr 12, 2022 at 09:46:24AM +0300, Andrew Krasavin wrote: > On Tue, Apr 12, 2022 at 06:44:09AM +0200, Sebastien Marie wrote: > > On Mon, Apr 11, 2022 at 10:35:37PM +0300, Andrew Krasavin wrote: > > > > > > Unfortunately, I didn't have a chance to get to my home computer last > > > week and provide you with the information you need. My apologies. > > > > > > > It isn't a problem. but I will be still interested by result on your > > computer, > > as it could help to figure the problem. > > Of course. I wouldn't think of refusing to give you information. I > would be glad if I could do something to help you find the cause of > the problem. Feel free to ask me for any information you need about > it.
As you have a good way to reproduce it on amd64, i might ask you to test some additionnal patches. For now, we need to properly understand the problem. > I successfully built the latest current snapshot with your diff and > booted with the new kernel. The panic was reproduced in the same way > as on previous times. > > This time, with your permission, I will post photos. If necessary, > I can reprint what would be desirable to translate into text (please > let me know if such a thing is needed). I will transcribe some of them for others devs. > trace: > http://46.23.91.227:8098/trace0.jpg > http://46.23.91.227:8098/trace1.jpg > > Scrollback in the ddb console did not work for me for some reason. > However, the 'dmesg' command seemed to show everything we needed: > http://46.23.91.227:8098/console0.jpg > http://46.23.91.227:8098/console1.jpg > http://46.23.91.227:8098/console2.jpg > http://46.23.91.227:8098/console3.jpg > http://46.23.91.227:8098/console4.jpg > http://46.23.91.227:8098/console5.jpg > http://46.23.91.227:8098/console6.jpg uvn_io: start: 0xffff8000ffab9688, type VREG, use 0, write 0, hold 0, flags (VBIOONFREELIST) tag VT_UFS, ino 14802284, on dev 4, 30 flags 0x100, effnlink 1, nlink 1 mode 0100644, owner 858, group 1000, size 345603015 => vnode_history_print 0xffff8000ffab9688, next=1 [0] #0 vput #1 dofstatat #2 syscall #3 Xsyscall [1>] #0 vput #1 dofstatat #2 syscall #3 Xsyscall [2] #0 vget #1 ufs_ihashget #2 ffs_vget #3 ufs_lookup #4 VOP_LOOKUP #5 vfs_lookup #6 namei #7 vn_open #8 doopenat #9 syscall #10 Xsyscall [3] #0 uvn_attach #1 uvm_mmapfile #2 sys_mmap #3 syscall #4 Xsyscall [4] #0 vput #1 vn_closefile #2 fdrop #3 closef #4 fdfree #5 exit1 #6 single_thread_check_locked #7 userret #8 intr_user_exit [5] #0 vrele #1 uvm_unmap_detach #2 uvm_map_teardown #3 uvmspace_free #4 reaper #5 proc_trampoline [6] #0 vget #1 ufs_ihashget #2 ffs_vget #3 ufs_lookup #4 VOP_LOOKUP #5 vfs_lookup #6 namei #7 dofstatat #8 syscall #9 Xsyscall [7] #0 vput #1 dofstatat #2 syscall #3 Xsyscall [8] #0 vget #1 ufs_ihashget #2 ffs_vget #3 ufs_lookup #4 VOP_LOOKUP #5 vfs_lookup #6 namei #7 dofstatat #8 syscall #9 Xsyscall panic: vn_lock: v_usecount == 0 Stopped at db_enter+0x10: popq %rbp TID PID UID PRFLAGS PFLAGS CPU COMMAND 448838 87877 858 0 0x4000000 3 qbittorrent-nox *281933 50305 0 0x14000 0x200 1K pagedaemon db_enter() at ... panic(...) vn_lock(ffff800ffab9688,81) uvn_io(fffffd837a66bee8,...,1,90,1) uvm_pager_put(fffffd837a66bee8, ....) uvmpd_scan_inactive(...) uvmpd_scan() uvm_pageout(ffff8000ffff5270) > But just in case, here is also the output of the 'show vnode' > command itself: > http://46.23.91.227:8098/show_vnode0.jpg > http://46.23.91.227:8098/show_vnode1.jpg > http://46.23.91.227:8098/show_vnode2.jpg > http://46.23.91.227:8098/show_vnode3.jpg > > show mount: > http://46.23.91.227:8098/show_mount.jpg > > show uvm: > http://46.23.91.227:8098/show_uvm.jpg > > After I rebooted into OS from ddb and got distracted by some > personal stuff, qbittorrent continued rechecking from where it > stopped during the panic (about half of 27Gb). I was searching for > something in firefox at the time. > Very soon I saw the kernel panic again, now with a slightly different > content. I'm not sure if these things are related, but just in case, > I'll leave the data from the console for this panic as well: > > http://46.23.91.227:8098/second_panic0.jpg > http://46.23.91.227:8098/second_panic_bcstats.jpg > http://46.23.91.227:8098/second_panic_precpu0.jpg > http://46.23.91.227:8098/second_panic_precpu1.jpg > http://46.23.91.227:8098/second_panic_uvm.jpg > > (I suspect I should open a separate bug report for this problem?) at this point, I dunno if it is related. just transcribing the main elements: panic: kernel diagnostic assertion "rv" failed: file "/sys/uvm/uvm_glue.c", line 428 current process: aiodoned (others: 3 firefox processes) trace: __assert(...) uvm_atopg(...) uvm_aio_aiodone(...) uvm_aiodone_daemon(...) the assert itself is: 417 /* 418 * uvm_atopg: convert KVAs back to their page structures. 419 */ 420 struct vm_page * 421 uvm_atopg(vaddr_t kva) 422 { 423 struct vm_page *pg; 424 paddr_t pa; 425 boolean_t rv; 426 427 rv = pmap_extract(pmap_kernel(), kva, &pa); 428 KASSERT(rv); 429 pg = PHYS_TO_VM_PAGE(pa); 430 KASSERT(pg != NULL); 431 return (pg); 432 } Thanks. -- Sebastien Marie
