DragonFlyBSD bugtracker: Issueshttps://bugs.dragonflybsd.org/https://bugs.dragonflybsd.org/favicon.ico?16293952082019-09-18T13:28:07ZDragonFlyBSD bugtracker
Redmine DragonFlyBSD - Bug #3205 (Feedback): Go compiler net test failinghttps://bugs.dragonflybsd.org/issues/32052019-09-18T13:28:07ZAnonymous
<p>A recent commit appears to have broken the net test for the Go compiler:<br /><a class="external" href="https://build.golang.org/log/58be31cfd1a92ba9582fdf33e01f79e03184e59b">https://build.golang.org/log/58be31cfd1a92ba9582fdf33e01f79e03184e59b</a></p>
<p>This was working on commit be02f354 and started failing when I upgraded to b7d3e1.</p> DragonFlyBSD - Bug #3152 (Feedback): Console's size in ttyv0 and single user mode is sticking to ...https://bugs.dragonflybsd.org/issues/31522018-10-26T14:34:46Zovertime
<p>I had try</p> DragonFlyBSD - Submit #3142 (Feedback): lib/libdmsg: Unbreak using new API EVP_CIPHER_CTX_new()https://bugs.dragonflybsd.org/issues/31422018-07-08T11:18:33Ztkusumikusumi.tomohiro@gmail.com
<p><a class="external" href="https://github.com/kusumi/DragonFlyBSD/commit/e6833c80bc898c2674e180828fe62cd0b53226e7">https://github.com/kusumi/DragonFlyBSD/commit/e6833c80bc898c2674e180828fe62cd0b53226e7</a></p>
<p>--<br />The upstream OpenSSL no longer publicly expose definition of<br />EVP_CIPHER_CTX (struct evp_cipher_ctx_st).</p>
<p>Due to this change clients need to have it as a pointer instead<br />of as a value, and allocate or free EVP_CIPHER_CTX instance by<br />EVP_CIPHER_CTX_new()/EVP_CIPHER_CTX_free().</p>
<blockquote>
<p><a class="external" href="https://github.com/openssl/openssl/issues/962#issuecomment-208792020">https://github.com/openssl/openssl/issues/962#issuecomment-208792020</a></p>
</blockquote> DragonFlyBSD - Bug #2958 (Feedback): Hammer FS dies during pruning after massive write loadhttps://bugs.dragonflybsd.org/issues/29582016-10-09T11:11:20Zneilbkyuupichan@gmail.com
<p>I have one or two apps that use leveldb badly, and read and write a lot of data to disk.</p>
<p>I have a 256GB SSD, and to avoid running out of space within an hour or two of starting these apps, I have them use the DB on a no history PFS and clean the FS intraday. This kernel freezes around 40% of the time during pruning. The other operations are never a problem.</p>
<p>I don't really know what I can give as useful information. Normal usage without these apps is fine; hammer never gives a problem. Just after 100s of GBs of writes pruning sometimes kills the kernel. The FS is always fine and not corrupt after rebooting, and redoing the clean usually then succeeds (though once it died again, after making progress freeing space).</p>
<p>Incidentally, during these pruning phases that do succeed, X completely freezes for 20-30s several times; the mouse doesn't move and the desktop clock I have stops ticking. Not losing userspace interactivity would be nice.</p>
<p>$ uname -a<br />DragonFly zotac.akihabara.co.uk 4.5-DEVELOPMENT DragonFly v4.5.0.681.g2e03c8-DEVELOPMENT <a class="issue tracker-1 status-5 priority-3 priority-lowest closed" title="Bug: K&R -> ANSI cleanup status (Closed)" href="https://bugs.dragonflybsd.org/issues/2">#2</a>: Sun Mar 20 21:54:05 JST 2016 <a class="email" href="mailto:root@zotac.akihabara.co.uk">root@zotac.akihabara.co.uk</a>:/usr/obj/usr/src/sys/X86_64_GENERIC x86_64</p> DragonFlyBSD - Bug #2957 (Feedback): swapoff -a followed by swapon -a doesn't give your swap backhttps://bugs.dragonflybsd.org/issues/29572016-10-09T11:06:08Zneilbkyuupichan@gmail.com
<p>I did swapoff -a taking all my swap away. I think I got an error message about an interrupted syscall from the program at the end of it. If you're trying to reproduce you should probably have swap space in use.</p>
<p>I then did swapon -a. It doesn't complain, and I can't remember if swap is shown as existing, but if it is the swap is not used.</p>
<p>A few hours later the kernel killed a process and in the sys logs there was a warning saying no swap space. None was used, it's that there wasn't any available at all, used or unused.</p>
<p>This has been a bug for a while; I remember it for 1-2 years at least.</p>
<p>$ uname -a<br />DragonFly zotac.akihabara.co.uk 4.5-DEVELOPMENT DragonFly v4.5.0.681.g2e03c8-DEVELOPMENT <a class="issue tracker-1 status-5 priority-3 priority-lowest closed" title="Bug: K&R -> ANSI cleanup status (Closed)" href="https://bugs.dragonflybsd.org/issues/2">#2</a>: Sun Mar 20 21:54:05 JST 2016 <a class="email" href="mailto:root@zotac.akihabara.co.uk">root@zotac.akihabara.co.uk</a>:/usr/obj/usr/src/sys/X86_64_GENERIC x86_64</p> DragonFlyBSD - Submit #2721 (Feedback): Some few zalloc calls to objcache ones replacementshttps://bugs.dragonflybsd.org/issues/27212014-08-30T17:12:51Zdclinkdevnexen@gmail.comDragonFlyBSD - Submit #2717 (Feedback): Out of range numeric handlinghttps://bugs.dragonflybsd.org/issues/27172014-08-22T12:36:50Zdclinkdevnexen@gmail.com
<p>In a similar way than OpenBSD, the numeric values overflows are checked.</p> DragonFlyBSD - Bug #2644 (Feedback): 3.6.0-REL trap 9 on boothttps://bugs.dragonflybsd.org/issues/26442014-02-20T06:53:30Zmemmerto
<p>Booting 3.6.0-REL on my not-quite-ancient IBM x3400 (with Intel E5310 QC processor) traps:</p>
<p>CPU0 stopping CPUs: 0x0000000e<br /> stopped<br />Stopped vmx_set_ctl_setting+0x36: rdmsr<br />db> where<br />vmx_set_ctl_setting() at vmx_set_ctl_setting+0x36 0xffffffff809721f6<br />vmx_set_default_settings() at vmx_set_default_settings+0x1e 0xffffffff80972326<br />vmx_init() at vmx_init+0x5c 0xffffffff8097305e<br />vmm_init() at vmm_init+0xa3 0xffffffff80971c1f<br />mi_startup() at mi_startup+0xb1 0xffffffff80532775<br />db></p>
<p>For reference, 3.4.2-REL worked fine on this machine.</p> DragonFlyBSD - Bug #2638 (Feedback): Fix machdep.pmap_mmu_optimizehttps://bugs.dragonflybsd.org/issues/26382014-02-13T21:51:39Ztuxillo
<p>Fix machdep.pmap_mmu_optimize (currently off by default in commit 1ac5304a10366be7ed3129ceee7ca94beb0f3183 ). Affects apache and rtorrent for sure.</p>
<p>"might be fixed here: a44410dd8663abb121417692995d3b365f32fd6e<br />update: it's not fixed"</p> DragonFlyBSD - Bug #2636 (Feedback): Add -x flag to iostat (a la solaris)https://bugs.dragonflybsd.org/issues/26362014-02-13T21:50:00Ztuxillo
<p>Add -x flag to iostat (a la solaris)</p> DragonFlyBSD - Bug #2617 (Feedback): Possible issue with wireless mouse on 3.6 releasehttps://bugs.dragonflybsd.org/issues/26172013-12-20T09:52:27ZFilippoMofilippomore@yahoo.com
<p>I have a possible bug to report on RELEASE_3_6_0 on i386 arch.<br />I have a usb cordless mouse that does'not work.It is correctly identified<br />as ums0 and there is a /dev/ums0 on the same receiver there is a keyboard that works and the hardware works on other OSes.<br />I killed moused and started moused -p /dev/sysmouse but it did not work.<br />Filippo</p>
<p>On Thursday, December 19, 2013 9:00 PM, "<a class="email" href="mailto:bugs-request@dragonflybsd.org">bugs-request@dragonflybsd.org</a>" <<a class="email" href="mailto:bugs-request@dragonflybsd.org">bugs-request@dragonflybsd.org</a>> wrote:</p>
<p>Send Bugs mailing list submissions to<br /> <a class="email" href="mailto:bugs@dragonflybsd.org">bugs@dragonflybsd.org</a></p>
<p>To subscribe or unsubscribe via the World Wide Web, visit<br /> <a class="external" href="http://lists.dragonflybsd.org/mailman/listinfo/bugs">http://lists.dragonflybsd.org/mailman/listinfo/bugs</a><br />or, via email, send a message with subject or body 'help' to<br /> <a class="email" href="mailto:bugs-request@dragonflybsd.org">bugs-request@dragonflybsd.org</a></p>
<p>You can reach the person managing the list at<br /> <a class="email" href="mailto:bugs-owner@dragonflybsd.org">bugs-owner@dragonflybsd.org</a></p>
<p>When replying, please edit your Subject line so it is more specific<br />than "Re: Contents of Bugs digest..."</p>
<p>Today's Topics:</p>
<p> 1. [DragonFlyBSD - Bug <a class="issue tracker-1 status-3 priority-5 priority-high3 closed" title="Bug: panic while running gdb test suite (Resolved)" href="https://bugs.dragonflybsd.org/issues/2615">#2615</a>] (Resolved) panic while running gdb<br /> test suite (Pierre Abbat via Redmine)</p>
<hr />
<p>Message: 1<br />Date: Wed, 18 Dec 2013 22:35:30 -0800<br />From: Pierre Abbat via Redmine<br /> <<a class="email" href="mailto:bugtracker-admin@leaf.dragonflybsd.org">bugtracker-admin@leaf.dragonflybsd.org</a>><br />To: undisclosed-recipients:;<br />Subject: [DragonFlyBSD - Bug <a class="issue tracker-1 status-3 priority-5 priority-high3 closed" title="Bug: panic while running gdb test suite (Resolved)" href="https://bugs.dragonflybsd.org/issues/2615">#2615</a>] (Resolved) panic while running gdb<br /> test suite<br />Message-ID:<br /> <<a class="email" href="mailto:redmine.journal-11682.20131219063529.7a9eb072d3b04776@leaf.dragonflybsd.org">redmine.journal-11682.20131219063529.7a9eb072d3b04776@leaf.dragonflybsd.org</a>><br /> <br />Content-Type: text/plain; charset=UTF-8</p>
<p>Issue <a class="issue tracker-1 status-3 priority-5 priority-high3 closed" title="Bug: panic while running gdb test suite (Resolved)" href="https://bugs.dragonflybsd.org/issues/2615">#2615</a> has been updated by phma.</p>
<p>Status changed from New to Resolved</p>
<p>It is fixed. Thanks.</p>
<p>----------------------------------------<br />Bug <a class="issue tracker-1 status-3 priority-5 priority-high3 closed" title="Bug: panic while running gdb test suite (Resolved)" href="https://bugs.dragonflybsd.org/issues/2615">#2615</a>: panic while running gdb test suite<br /><a class="external" href="http://bugs.dragonflybsd.org/issues/2615#change-11682">http://bugs.dragonflybsd.org/issues/2615#change-11682</a></p>
<ul>
<li>Author: phma</li>
<li>Status: Resolved</li>
<li>Priority: High</li>
<li>Assignee: </li>
<li>Category: </li>
<li>Target version: <br />----------------------------------------<br />see <a class="external" href="https://github.com/DragonFlyBSD/DPorts/wiki/Run-GDB-testsuite">https://github.com/DragonFlyBSD/DPorts/wiki/Run-GDB-testsuite</a></li>
</ul>
<p>I ran the testsuite on gdb 7.6.1 and it crashed partway through. This is as far as it got:</p>
<p>Running ./gdb.base/fileio.exp ...<br />FAIL: gdb.base/fileio.exp: Open for write but no write permission returns <br />EACCES<br />FAIL: gdb.base/fileio.exp: Unlinking a file in a directory w/o write access <br />returns EACCES<br />Running ./gdb.base/gcore-relro.exp ...<br />Running ./gdb.base/huge.exp ...<br />Running ./gdb.base/find.exp ...<br />Running ./gdb.base/ctxobj.exp ...<br />Running ./gdb.base/cond-eval-mode.exp ...<br />Running ./gdb.base/arrayidx.exp ...<br />Running ./gdb.base/eval-skip.exp ...<br />Running ./gdb.base/attach.exp ...</p>
<p>It crashed in the same place both times. The kernel dumps are numbers 2 and 3 in leaf:/home/phma/crash/zyxomma/. I need this fixed so that I can fix the thread bug in gdb.</p>
<p>-- <br />You have received this notification because you have either subscribed to it, or are involved in it.<br />To change your notification preferences, please click here: <a class="external" href="http://bugs.dragonflybsd.org/my/account">http://bugs.dragonflybsd.org/my/account</a></p>
<hr />
<p>_<em><i></em></i>__<em>_</em>___________________________________<br />Bugs mailing list<br /><a class="email" href="mailto:Bugs@dragonflybsd.org">Bugs@dragonflybsd.org</a><br /><a class="external" href="http://lists.dragonflybsd.org/mailman/listinfo/bugs">http://lists.dragonflybsd.org/mailman/listinfo/bugs</a></p>
End of Bugs Digest, Vol 16, Issue 10
<hr /> DragonFlyBSD - Bug #2556 (Feedback): DragonFly v3.5.0.81.gd3479 - Process signal weirdnesshttps://bugs.dragonflybsd.org/issues/25562013-05-07T22:59:34Ztuxillo
<p>Hi,</p>
<p>tmux has a memory leak somewhere and it was causing a lot of swap memory to be used. I started using truss(1) to see what it was doing and after 3-4 tracing attempts the tmux process was stuck in status "stopevent". After sending to it all sorts of signals (CONT, HUP, KILL) the process is kept stopped in the same situation. I also tried disabling tracing with ktrace(1) but it didn't help.</p>
<p>Eventually I tried to reboot the virtual machine but it got stuck for around 10 minutes without actually being able to shutdown. Last step was dropping to DDB and producing a dump. Dump is available on leaf on demand. See below the backtrace of the thread involved (tmux process)</p>
<p>Best regards,<br />Antonio Huete</p>
<hr />
<p>(kgdb) thread 26<br />[Switching to thread 26 (pid 835/0, tmux)]<br />#0 0xffffffff8050dfb0 in lwkt_switch () at /home/source/dfbsd/sys/kern/lwkt_thread.c:872<br />872 /home/source/dfbsd/sys/kern/lwkt_thread.c: No such file or directory.<br />(kgdb) bt<br />#0 0xffffffff8050dfb0 in lwkt_switch () at /home/source/dfbsd/sys/kern/lwkt_thread.c:872<br /><a class="issue tracker-1 status-5 priority-3 priority-lowest closed" title="Bug: lib/libcr/sys/ cleanup (Closed)" href="https://bugs.dragonflybsd.org/issues/1">#1</a> 0xffffffff80518f0e in tsleep (ident=ident@entry=0xffffffe071efc990, flags=flags@entry=1024, <br /> wmesg=wmesg@entry=0xffffffff8097e168 "stopevent", timo=timo@entry=0) at /home/source/dfbsd/sys/kern/kern_synch.c:612<br /><a class="issue tracker-1 status-5 priority-3 priority-lowest closed" title="Bug: K&R -> ANSI cleanup status (Closed)" href="https://bugs.dragonflybsd.org/issues/2">#2</a> 0xffffffff80538091 in stopevent (p=p@entry=0xffffffe071efc780, event=event@entry=4, val=val@entry=7)<br /> at /home/source/dfbsd/sys/kern/sys_process.c:771<br /><a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: freebsds pipe-reverse test fails on dfly (Closed)" href="https://bugs.dragonflybsd.org/issues/3">#3</a> 0xffffffff808c5a7a in syscall2 (frame=0xffffffe07280e9f8) at /home/source/dfbsd/sys/platform/pc64/x86_64/trap.c:1229<br /><a class="issue tracker-1 status-5 priority-5 priority-high3 closed" title="Bug: Rework of nrelease (Closed)" href="https://bugs.dragonflybsd.org/issues/4">#4</a> 0xffffffff808af75b in ?? () at /home/source/dfbsd/sys/platform/pc64/x86_64/exception.S:323<br /><a class="issue tracker-1 status-5 priority-3 priority-lowest closed" title="Bug: sys/dev cleanup (Closed)" href="https://bugs.dragonflybsd.org/issues/5">#5</a> 0x00000000000000c5 in ?? ()<br /><a class="issue tracker-1 status-5 priority-3 priority-lowest closed" title="Bug: sys/emulation cleanup (Closed)" href="https://bugs.dragonflybsd.org/issues/6">#6</a> 0x0000000000000000 in ?? ()</p> DragonFlyBSD - Submit #2438 (Feedback): TRIM fixeshttps://bugs.dragonflybsd.org/issues/24382012-10-22T04:59:20ZAnonymous
<p>This patch is to fix bugs associated with TRIM.</p>
<p>If trim is on as a option, display that when typing "mount".</p>
<p>Change post-trim ffs_blkfree_cg() to use taskqueue_swi_mp and get mp token when modifying freemap.</p>
<p>Make sure TRIM works with softdep. Stash a copy of that vnode's mount point in the ufs inode so that if we are using softdep, we can get access to the mount point through the faked up inode (created in freeblocks). The original mount point path (ip->i_devvp->v_mount->mnt_flag) doesn't have the mount point options.</p>
<p>Tim</p> DragonFlyBSD - Bug #2396 (Feedback): Latest 3.1 development version core dumps while destroying m...https://bugs.dragonflybsd.org/issues/23962012-07-18T10:50:26Zsgeorgesgeorge.ml2@gmail.com
<p>Hi,</p>
<p>I was destroying a master PFS on the ROOT volume and the system ( v3.1.0.827.gf6167a5-DEVELOPMENT )core dumped.<br />I tried today's latest snapshot and got the same result.<br />The Coredump is uploaded to sgeorge@leaf:~/crash/Coredump20120718.tbz</p>
<p>panic: assertion "layer2->zone == zone" failed in hammer_blockmap_free at /usr/src/sys/vfs/hammer/hammer_blockmap.c:1020<br />cpuid = 0<br />Trace beginning at frame 0xffffffe09e20f178<br />panic() at panic+0x1fb 0xffffffff804bef68 <br />panic() at panic+0x1fb 0xffffffff804bef68 <br />hammer_blockmap_free() at hammer_blockmap_free+0x2e5 0xffffffff80691a0c <br />hammer_delete_at_cursor() at hammer_delete_at_cursor+0x4e2 0xffffffff806aac62 <br />hammer_pfs_rollback() at hammer_pfs_rollback+0x26c 0xffffffff806b0b20 <br />hammer_ioc_destroy_pseudofs() at hammer_ioc_destroy_pseudofs+0x77 0xffffffff806b0c6c <br />hammer_ioctl() at hammer_ioctl+0x80e 0xffffffff806a5b1e <br />hammer_vop_ioctl() at hammer_vop_ioctl+0x58 0xffffffff806be8d3 <br />vop_ioctl() at vop_ioctl+0x98 0xffffffff8053d244 <br />vn_ioctl() at vn_ioctl+0xfd 0xffffffff8053a4d9 <br />fo_ioctl() at fo_ioctl+0x46 0xffffffff804f026e <br />mapped_ioctl() at mapped_ioctl+0x493 0xffffffff804f0725 <br />sys_ioctl() at sys_ioctl+0x1c 0xffffffff804f07be <br />syscall2() at syscall2+0x370 0xffffffff807814c1 <br />Xfast_syscall() at Xfast_syscall+0xcb 0xffffffff8076ae2b <br />(null)() at 0 0 <br />(null)() at 0x723d524553550061 0x723d524553550061</p>
<p>Fatal trap 9: general protection fault while in kernel mode<br />cpuid = 0; lapic->id = 00000000<br />instruction pointer = 0x8:0xffffffff8077acf9<br />stack pointer = 0x10:0xffffffe09e20f010<br />frame pointer = 0x10:0xffffffe09e20f028<br />code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, long 0, def32 0, gran 1<br />processor eflags = interrupt enabled, resume, IOPL = 0<br />current process = 957<br />current thread = pri 10 <br />kernel: type 9 trap, code=0</p>
<p>CPU0 stopping CPUs: 0x00000002<br /> stopped<br />Physical memory: 3787 MB<br />Dumping 1055 MB: 1040 1024 1008 992 976 960 944 928 912 896 880 864 848 832 816 800 784 768 752 736 720 704 688 672 656 640 624 608 592 576 560 544 528 512 496 480 464 448 432 416 400 384 368 352 336 320 304 288 272 256 240 224 208 192 176 160 144 128 112 96 80 64 48 32 16</p> DragonFlyBSD - Bug #2347 (Feedback): Hammer PFSes destroy does not give back full space allocated...https://bugs.dragonflybsd.org/issues/23472012-04-11T07:17:48Zsgeorgesgeorge.ml2@gmail.com
<p>I was mirroring PFSes from 3.1 dev to slaves in 3.02 and I found that<br />the PFSes took more space on the 3.02 slave.<br />Investigating I found this strange thing</p>
<p>94 GB is allocated for this slave PFS. But when it is removed only 52<br />GB is freed :-(</p>
<p>dfly-bkpsrv2# hammer dedup /pfs/software<br />Dedup running<br />Dedup /pfs/software succeeded<br />Dedup ratio = 1.06<br /> 100 GB referenced<br /> 94 GB allocated<br /> 4339 KB skipped<br /> 429 CRC collisions<br /> 0 SHA collisions<br /> 1 bigblock underflows<br /> 0 new dedup records<br /> 0 new dedup bytes</p>
<p>dfly-bkpsrv2# df -h<br />Filesystem Size Used Avail Capacity Mounted on<br />ROOT 459G 354G 106G 77% /<br />devfs 1.0K 1.0K 0B 100% /dev<br />/dev/serno/QM00001.s1a 756M 168M 527M 24% /boot<br />/pfs/<code>@-1:00001 459G 354G 106G 77% /var<br />/pfs/</code>@-1:00002 459G 354G 106G 77% /tmp<br />/pfs/<code>@-1:00003 459G 354G 106G 77% /usr<br />/pfs/</code>@-1:00004 459G 354G 106G 77% /home<br />/pfs/<code>@-1:00005 459G 354G 106G 77% /usr/obj<br />/pfs/</code>@-1:00006 459G 354G 106G 77% /var/crash<br />/pfs/<code>@-1:00007 459G 354G 106G 77% /var/tmp<br />procfs 4.0K 4.0K 0B 100% /proc<br />dfly-bkpsrv2# ls<br />home software usr var<br />var.tmp vms2-lxc<br />mysql-baks tmp usr.obj var.crash vms1-lxc<br />dfly-bkpsrv2# hammer pfs-destroy /pfs/software<br />You have requested that PFS#11 () be destroyed<br />This will irrevocably destroy all data on this PFS!!!!!<br />Do you really want to do this? y<br />Destroying PFS #11 () in 5 4 3 2 1.. starting destruction pass<br />pfs-destroy of PFS#11 succeeded!<br />dfly-bkpsrv2# df -h<br />Filesystem Size Used Avail Capacity Mounted on<br />ROOT 459G 302G 158G 66% /<br />devfs 1.0K 1.0K 0B 100% /dev<br />/dev/serno/QM00001.s1a 756M 168M 527M 24% /boot<br />/pfs/</code>@-1:00001 459G 302G 158G 66% /var<br />/pfs/<code>@-1:00002 459G 302G 158G 66% /tmp<br />/pfs/</code>@-1:00003 459G 302G 158G 66% /usr<br />/pfs/<code>@-1:00004 459G 302G 158G 66% /home<br />/pfs/</code>@-1:00005 459G 302G 158G 66% /usr/obj<br />/pfs/<code>@-1:00006 459G 302G 158G 66% /var/crash<br />/pfs/</code>@-1:00007 459G 302G 158G 66% /var/tmp<br />procfs 4.0K 4.0K 0B 100% /proc</p>