DragonFlyBSD bugtracker: Issueshttps://bugs.dragonflybsd.org/https://bugs.dragonflybsd.org/favicon.ico?16293952082023-03-25T12:34:12ZDragonFlyBSD bugtracker
Redmine DragonFlyBSD - Bug #3347 (In Progress): pctrack fails with kvm_nlist: No such file or directoryhttps://bugs.dragonflybsd.org/issues/33472023-03-25T12:34:12Ztuxillo
<p>As reported by kworr, it seems pctrack(8) does not work:</p>
<pre>
# pctrack
pctrack: kvm_nlist: No such file or directory
</pre> DragonFlyBSD - Bug #3318 (In Progress): Segmenation fault when a process resumed with checkpt exitshttps://bugs.dragonflybsd.org/issues/33182022-06-12T11:51:16Zzabolekar
<p>DragonFly version: 6.2.1</p>
<p>Code example (error handling omitted for brevity):<br /><pre><code class="c syntaxhl" data-language="c"><span class="cp">#include</span> <span class="cpf"><stdlib.h></span><span class="cp">
#include</span> <span class="cpf"><fcntl.h></span><span class="cp">
#include</span> <span class="cpf"><unistd.h></span><span class="cp">
#include</span> <span class="cpf"><sys/checkpoint.h></span><span class="cp">
</span>
<span class="kt">void</span> <span class="nf">save</span><span class="p">(</span><span class="k">const</span> <span class="kt">char</span><span class="o">*</span> <span class="n">filename</span><span class="p">)</span>
<span class="p">{</span>
<span class="kt">int</span> <span class="n">file</span> <span class="o">=</span> <span class="n">open</span><span class="p">(</span><span class="n">filename</span><span class="p">,</span> <span class="n">O_RDWR</span><span class="o">|</span><span class="n">O_CREAT</span><span class="o">|</span><span class="n">O_TRUNC</span><span class="p">,</span> <span class="mo">0666</span><span class="p">);</span>
<span class="n">sys_checkpoint</span><span class="p">(</span><span class="n">CKPT_FREEZE</span><span class="p">,</span> <span class="n">file</span><span class="p">,</span> <span class="o">-</span><span class="mi">1</span><span class="p">,</span> <span class="o">-</span><span class="mi">1</span><span class="p">);</span>
<span class="n">close</span><span class="p">(</span><span class="n">file</span><span class="p">);</span>
<span class="p">}</span>
<span class="kt">int</span> <span class="nf">main</span><span class="p">()</span>
<span class="p">{</span>
<span class="n">puts</span><span class="p">(</span><span class="s">"a"</span><span class="p">);</span>
<span class="n">save</span><span class="p">(</span><span class="s">"a.ckpt"</span><span class="p">);</span>
<span class="n">puts</span><span class="p">(</span><span class="s">"b"</span><span class="p">);</span>
<span class="p">}</span>
</code></pre></p>
<p>Expected output:</p>
<pre>
% gcc test.c -o test -Wall -Wextra
% ./test
a
b
% checkpt -r a.ckpt
b
</pre>
<p>Actual output:</p>
<pre>
% gcc test.c -o test -Wall -Wextra
% ./test
a
b
% checkpt -r a.ckpt
b
pid 1143 (test), uid 1001: exited on signal 11 (core dumped)
Segmentation fault (core dumped)
</pre>
<p>Backtrace with <code>gdb test test.core</code>:</p>
<pre>
#0 0x000000080040400f in __tls_get_addr () from /libexec/ld-elf.so.2
#1 0x000000080075648a in _thread_finalize () from /lib/libc.so.8
#2 0x0000000800756449 in exit () from /lib/libc.so.8
#3 0x00000000004007b3 in _start ()
</pre>
<p>See also: <a class="external" href="https://lists.dragonflybsd.org/pipermail/users/2022-June/405002.html">https://lists.dragonflybsd.org/pipermail/users/2022-June/405002.html</a></p> DragonFlyBSD - Bug #3314 (New): Bring virtio_console(4) from FreeBSDhttps://bugs.dragonflybsd.org/issues/33142022-05-29T15:24:40Ztuxillo
<p>Bring virtio_console(4) from FreeBSD. It should help with qemu-guest-agent and probably other things I am not aware of yet.</p>
<p>Once I have patches to test, I'll post them here.</p>
<p>References:<br /><a class="external" href="https://www.freebsd.org/cgi/man.cgi?query=virtio_console&sektion=4">https://www.freebsd.org/cgi/man.cgi?query=virtio_console&sektion=4</a><br /><a class="external" href="https://github.com/aborche/qemu-guest-agent">https://github.com/aborche/qemu-guest-agent</a></p> DragonFlyBSD - Bug #3295 (In Progress): Adapt devel/libvirt for nvmmhttps://bugs.dragonflybsd.org/issues/32952021-09-01T00:36:33Ztuxillo
<p>With the recent addition of nvmm, it would be interesting to have something that eases the VM lifecycle, like <code>devel/libvirt</code> . This is a feature request to myself to, at least try to, make <code>devel/libvirt</code> usable with nvmm under DragonFly.</p> 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 #2828 (New): On AMD APUs and Bulldozer CPUs, the machdep.cpu_idle_hlt sysctl s...https://bugs.dragonflybsd.org/issues/28282015-06-13T23:21:11Zvadaszi
<p>Power usage of a default install is unnecessarily high on current AMD CPUs. Setting the default value of the machdep.cpu_idle_hlt sysctl on these CPUs to 3 by default allows for significant power savings.</p>
<p>I'm not sure how setting machdep.cpu_idle_hlt=3 affects power usage on AMD Family 10h CPUs (e.g. Phenom CPUs).</p>
<p>Some quick benchmarking should be done if possible, to compare the performance difference.</p> DragonFlyBSD - Bug #2577 (New): virtio-blk iops performance is cpu limited on high end deviceshttps://bugs.dragonflybsd.org/issues/25772013-08-01T20:59:44Zgjs278gjs278@yahoo.com
<p>Qemu 1.5.2 on Gentoo AMD64 kernel 3.10.4 host with an i7 980x processor at 4.2ghz</p>
<p>qemu-system-x86_64 -machine accel=kvm -cpu host -drive file=/dev/fioa3,if=virtio,cache=none,aio=native -balloon virtio -smp 6 -m 6144M</p>
<p>/dev/fioa3 is a 160gb slc fusion-io card</p>
<p>DragonFlyBSD 3.4.2-RELEASE is the guest OS</p>
<ol>
<li>/tmp/rr1 /dev/vbd0<br />Device /dev/vbd0 bufsize 512 limit 10.800GB nprocs 32<br />randrand 1.001s 24293 loops = 41.202uS/loop<br />randrand 1.002s 24384 loops = 41.072uS/loop<br />randrand 1.001s 24633 loops = 40.640uS/loop</li>
</ol>
<ol>
<li>/tmp/rr1 /dev/vbd0 4096<br />Device /dev/vbd0 bufsize 4096 limit 10.800GB nprocs 32<br />randrand 1.001s 24333 loops = 41.119uS/loop<br />randrand 1.002s 24389 loops = 41.052uS/loop<br />randrand 1.001s 24367 loops = 41.093uS/loop</li>
</ol>
<ol>
<li>/tmp/rr1 /dev/vbd0 16384<br />Device /dev/vbd0 bufsize 16384 limit 10.800GB nprocs 32<br />randrand 1.001s 21006 loops = 41.619uS/loop<br />randrand 1.002s 21167 loops = 41.348uS/loop<br />randrand 1.001s 20520 loops = 48.850uS/loop</li>
</ol>
<p>cpu usage on the host nears 100% while /tmp/rr1 is running. at nprocs 32, the device should be capable of at least 100k iops. the same 25k limit is seen using an ssd array as well.</p> DragonFlyBSD - Bug #2496 (New): NTFS malloc limit exceededhttps://bugs.dragonflybsd.org/issues/24962013-01-21T22:15:44Zplasmobplasmob@gmail.com
<p>I core dumped on NTFS malloc limit exceeded error. /var/crash/core.0.txt is here <a class="external" href="http://www.pastebin.ca/2305534">http://www.pastebin.ca/2305534</a></p> DragonFlyBSD - Bug #2416 (New): '.' entry can be removed on mounted nfs filesystemhttps://bugs.dragonflybsd.org/issues/24162012-09-01T09:18:14Zftigeot
<p>I use a shared /usr/pkgsrc/packages on various DragonFlyBSD machines</p>
<p>Just after doing a "rm *" to remove accumulated cruft in packages/All<br />on a client machine, I noticed the "." entry had disappeared.</p>
<p>On the client machine I typed the command on, ls(1) only shows a unique '..'<br />entry in /usr/pkgsrc/packages/All. /usr/pkgsrc/packages doesn't<br />contain a '.' entry anymore. None of its subdirectories do.</p>
<p>On other client machine, the '.' entry has also disappeared from<br />/usr/pkgsrc/packages and all its subdirectories.</p>
<p>The server still contains '.' and '..' entries in the exported directory and<br />all its subdirectories.</p>
<p>Clients and server machines are all running DragonFly-3.1.<br />mount points and all of is</p> DragonFlyBSD - Bug #2391 (In Progress): System lock with ahci and acpi enabled on ATI RS690 chips...https://bugs.dragonflybsd.org/issues/23912012-06-24T20:41:54Zjorisgiojoris@giovannangeli.fr
<p>Page fault during boot with ahci and acpi.<br />Kernel boot without ahci but locks in userspace after a fixed time.<br />Page fault without acpi but with ahci.</p> DragonFlyBSD - Bug #2370 (New): panic: ffs_valloc: dup allochttps://bugs.dragonflybsd.org/issues/23702012-05-16T21:40:41Zmarino
<p>core text file located: <a class="external" href="http://leaf.dragonflybsd.org/~marino/core/core.ffs_valloc_dup_alloc.txt">http://leaf.dragonflybsd.org/~marino/core/core.ffs_valloc_dup_alloc.txt</a><br />core dump located on leaf, ~/marino/crash</p>
<p>uname: DragonFly v3.1.0.634.gc6fd7-DEVELOPMENT <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>: Sat May 5 09:02:18 CEST 2012 <a class="email" href="mailto:root@dracofly.synsport.com">root@dracofly.synsport.com</a>:/usr/obj/usr/src/sys/GENERIC</p>
<p>backtrace:<br />Unread portion of the kernel message buffer:<br />mode = 041777, inum = 4, fs = /mech<br />panic: ffs_valloc: dup alloc<br />cpuid = 1<br />Trace beginning at frame 0xe4b8b838<br />panic(ffffffff,1,c07290b3,e4b8b86c,d867f860) at panic+0x1a8 0xc039af00 <br />panic(c07290b3,43ff,4,defc10d4,e4b8b8f0) at panic+0x1a8 0xc039af00 <br />ffs_valloc(dee285d8,81a4,e00929e0,e4b8b8f0,c82dcc10) at ffs_valloc+0x518 0xc0542ad4 <br />ufs_makeinode(e4b8ba8c,d867f97c,dee285d8,dee67460,e4b8ba2c) at ufs_makeinode+0x71 0xc0556327 <br />ufs_create(e4b8ba38,e4b8ba68,c04139c0,e4b8ba38,c07d5b38) at ufs_create+0x2c 0xc0556692 <br />ufs_vnoperate(e4b8ba38,c07d5b38,dee67460,dee67460,c04043ef) at ufs_vnoperate+0x16 0xc0555bb6 <br />vop_old_create(dee67460,dee285d8,e4b8bbf0,e4b8ba8c,e4b8bb44) at vop_old_create+0x5b 0xc04139c0 <br />vop_compat_ncreate(e4b8badc,e4b8bad0,c0555bb6,e4b8badc,e4b8bb10) at vop_compat_ncreate+0x11d 0xc03f9813 <br />vop_defaultop(e4b8badc,e4b8bb10,c0412061,e4b8badc,c07d5c98) at vop_defaultop+0x16 0xc03f7f72 <br />ufs_vnoperate(e4b8badc,c07d5c98,dee67460,c7e6f2f8,0) at ufs_vnoperate+0x16 0xc0555bb6 <br />vop_ncreate(dee67460,e4b8bc74,dee285d8,e4b8bbf0,e00929e0) at vop_ncreate+0x64 0xc0412061 <br />vn_open(e4b8bc74,e3731f08,602,1a4,c77f211c) at vn_open+0x183 0xc0410eab <br />kern_open(e4b8bc74,601,1b6,e4b8bcf0,e372f7a8) at kern_open+0xa3 0xc040e0c7 <br />sys_open(e4b8bcf0,e4b8bd00,c,c03a6652,d867f860) at sys_open+0x54 0xc040e3a9 <br />syscall2(e4b8bd40) at syscall2+0x270 0xc067745c <br />Xint0x80_syscall() at Xint0x80_syscall+0x36 0xc0646466 <br />Debugger("panic")</p> DragonFlyBSD - Bug #2358 (In Progress): DFBSD v3.0.2.32.g928ca - panic: hammer: insufficient undo...https://bugs.dragonflybsd.org/issues/23582012-04-29T11:43:04Ztuxillo
<p>Hi,</p>
<p>HAMMER filesystem recently created on a LVM stripe of 5 disks. Box has 1GB with no swap.</p>
<p>databank# lvs<br /> LV VG Attr LSize Origin Snap% Move Log Copy% Convert<br /> lv_root main <del>wi-a</del> 186.17g</p>
<p>I got no dump but I have located which panic in the code was hit: <a class="external" href="http://pkgbox64.dragonflybsd.org/xref/DragonFly-master/sys/vfs/hammer/hammer_redo.c#91">http://pkgbox64.dragonflybsd.org/xref/DragonFly-master/sys/vfs/hammer/hammer_redo.c#91</a></p>
<p>Backtrace function call is:</p>
<p>panic()<br />panic()<br />hammer_generate_redo()<br />hammer_vop_write()<br />vop_write()<br />vn_write()<br />kern_pwritev()<br />sys_extpwrite()<br />syscall2()<br />Xint0x80_syscall()</p>
<p>Image: <a class="external" href="http://leaf.dragonflybsd.org/~tuxillo/archive/pics/panic_fifo.jpg">http://leaf.dragonflybsd.org/~tuxillo/archive/pics/panic_fifo.jpg</a></p>
<p>After rebooting and trying to mount again the HAMMER FS:</p>
<p>databank# mount -a<br />hammer: mount on /mnt/safe: Result too large</p>
<p>And dmesg shows:</p>
<p><abbr title="SAFE">HAMMER</abbr> recovery check seqno=00d791fe<br /><abbr title="SAFE">HAMMER</abbr> recovery range 30000000070ef490-3000000004a90000<br /><abbr title="SAFE">HAMMER</abbr> recovery nexto 3000000004a90000 endseqno=00e638f5<br /><abbr title="SAFE">HAMMER</abbr> recovery undo 30000000070ef490-3000000004a90000 (488246128 bytes)(RW)<br /><abbr title="SAFE">HAMMER</abbr> Found REDO_SYNC 30000000070ef490<br /><abbr title="SAFE">HAMMER</abbr> Ignoring extra REDO_SYNC records in UNDO/REDO FIFO.<br /><abbr title="SAFE">HAMMER</abbr> recovery complete<br /><abbr title="SAFE">HAMMER</abbr> recovery redo 30000000070ef490-3000000004a90000 (488246128 bytes)(RW)<br /><abbr title="SAFE">HAMMER</abbr> Find extended redo 30000000070ef490, 0 extbytes<br /><abbr title="SAFE">HAMMER</abbr> Find extended redo failed 34, unable to run REDO<br /><abbr title="SAFE">HAMMER</abbr> End redo recovery</p>
<p>I've activated swap and I'm going to try to reproduce it again and see if I can get a dump, but any tip would be appreciated :)</p>
<p>Cheers,<br />Antonio Huete</p> DragonFlyBSD - Bug #2113 (New): nmalloc threaded program fork leakhttps://bugs.dragonflybsd.org/issues/21132011-08-12T02:25:48Zvsrinivasvsrinivas@ops101.org
<p>When a threaded program forks, magazines held by threads other than the forkee<br />should be released along with their contents. Currently we leak those buffers.</p> DragonFlyBSD - Bug #1921 (In Progress): we miss mlockallhttps://bugs.dragonflybsd.org/issues/19212010-11-24T16:19:21Zalexh
<p>We don't have the mlockall/munlockall syscalls as documented in [1]. We have at <br />least one tool in base that would benefit from it: cryptsetup. Hopefully someone <br />more familiar with the VM system can implement it without much effort as we <br />already have mlock/munlock.</p>
<p>Cheers,<br />Alex Hornung</p>
<p>[1]: <a class="external" href="http://opengroup.org/onlinepubs/007908799/xsh/mlockall.html">http://opengroup.org/onlinepubs/007908799/xsh/mlockall.html</a></p> DragonFlyBSD - Bug #293 (Feedback): Various updates to the handbookhttps://bugs.dragonflybsd.org/issues/2932006-08-11T04:26:06Zvictor
<p>Hi,</p>
<p>there are 3 patches attached:</p>
<p>book.diff - Updates the copyright info relating to FreeBSD at the header<br /> of the handbook.</p>
<p>dfbsd-updating - Update cvsup port path to the current pkgsrc version in<br /> the chapter "Updating DragonFly".</p>
<p>basics.diff - Update various paths relating to pkgsrc and hier(7). Also<br /> make it use the new entity for pkgsrc <br /> tree/collection/framework.</p>