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 #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 #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 #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 #1819 (In Progress): truss - Major revamping task listhttps://bugs.dragonflybsd.org/issues/18192010-09-03T17:36:17Ztuxillo
<p>Many things to do with truss. Please add more in case you consider:</p>
<ul>
<li>Identifying 'unknown syscalls' and fix them.</li>
<li>Make truss work for x86_64. This may require some hacking as truss looks in <code>/proc/<PID>/etype</code> to see the binary type, but we make no distinction between i386 and x86_64 binaries on that field.</li>
<li>Get rid of the need of /proc so it can be used in chroots</li>
</ul> DragonFlyBSD - Submit #1700 (In Progress): skip boot2 menu on <enter>https://bugs.dragonflybsd.org/issues/17002010-03-22T00:07:18ZJohannes.Hofmann
<p>Hi,</p>
<p>tuxillo noticed that the trick to speedup booting by hitting <enter><br />does not work with default UFS-based installations, as those have no<br />separate /boot partition, and therefore the default location for the<br />loader is wrong (it had been changed to match default HAMMER<br />installations in <a class="changeset" title="boot - Switch boot2 loader path around * Test /loader first, then /boot/loader, makes hitting en..." href="https://bugs.dragonflybsd.org/projects/dragonfly/repository/dragonflybsd/revisions/3735e368a1bdbe773c79c34512f49c905ff77bd7">3735e368a1bdbe773c79c34512f49c905ff77bd7</a>)</p>
<p>We could change boot2 to just continue it's normal operation without<br />entering the prompt when the user hits <enter>. That way one can avoid<br />the delay on UFS and HAMMER systems:</p>
<pre>
<code class="ruby syntaxhl" data-language="ruby"><span class="n">diff</span> <span class="o">--</span><span class="n">git</span> <span class="n">a</span><span class="o">/</span><span class="n">sys</span><span class="o">/</span><span class="n">boot</span><span class="o">/</span><span class="n">pc32</span><span class="o">/</span><span class="n">boot2</span><span class="o">/</span><span class="n">boot2</span><span class="p">.</span><span class="nf">c</span> <span class="n">b</span><span class="o">/</span><span class="n">sys</span><span class="o">/</span><span class="n">boot</span><span class="o">/</span><span class="n">pc32</span><span class="o">/</span><span class="n">boot2</span><span class="o">/</span><span class="n">boot2</span><span class="p">.</span><span class="nf">c</span>
<span class="n">index</span> <span class="mi">459436</span><span class="n">f</span><span class="o">..</span><span class="mi">55516</span><span class="n">be</span> <span class="mi">100644</span>
<span class="o">---</span> <span class="n">a</span><span class="o">/</span><span class="n">sys</span><span class="o">/</span><span class="n">boot</span><span class="o">/</span><span class="n">pc32</span><span class="o">/</span><span class="n">boot2</span><span class="o">/</span><span class="n">boot2</span><span class="p">.</span><span class="nf">c</span>
<span class="o">+++</span> <span class="n">b</span><span class="o">/</span><span class="n">sys</span><span class="o">/</span><span class="n">boot</span><span class="o">/</span><span class="n">pc32</span><span class="o">/</span><span class="n">boot2</span><span class="o">/</span><span class="n">boot2</span><span class="p">.</span><span class="nf">c</span>
<span class="err">@@</span> <span class="o">-</span><span class="mi">346</span><span class="p">,</span><span class="mi">7</span> <span class="o">+</span><span class="mi">346</span><span class="p">,</span><span class="mi">7</span> <span class="err">@@</span> <span class="n">main</span><span class="p">(</span><span class="n">void</span><span class="p">)</span>
<span class="o">*</span><span class="sr">/
if (autoboot && !*kname) {
memcpy(kname, PATH_BOOT3, sizeof(PATH_BOOT3));
- if (!keyhit(3*SECOND)) {
+ if (!keyhit(3*SECOND) || xgetc(0) == '\r') {
load();
memcpy(kname, PATH_BOOT3_ALT, sizeof(PATH_BOOT3_ALT));
load();
</span></code><br /></pre>
<p>To actually enter the prompt one has to hit any other key (e.g. Esc).</p>
<p>The check for '\r' works ok for me, but maybe we also need to check<br />for '\n'?</p>
<p>Cheers,<br />Johannes</p> DragonFlyBSD - Bug #1440 (New): ptrace/gdb doesn't work after process blocks SIGTRAPhttps://bugs.dragonflybsd.org/issues/14402009-07-28T20:01:56Zcorecode
<p>If a process blocks SIGTRAP, an attached debugger will not be able to break<br />again (same is true for SIGINT, for instance).</p>
<p>We should change the behavior so that the debugger will be able to see this<br />signal, or to change how a ptrace'd process gets suspended on trap exceptions.</p> DragonFlyBSD - Bug #901 (Feedback): route show needs to get data from all cpushttps://bugs.dragonflybsd.org/issues/9012007-12-31T00:07:48Zcorecode
<p>when executing `route show' on my MP system, I will get varying results. <br />Additionally, it will print all temporary route entries as well, even for hosts<br />outside the local network.</p> DragonFlyBSD - Bug #847 (Feedback): processes getting stuck on mount pointhttps://bugs.dragonflybsd.org/issues/8472007-11-23T07:03:06Zcorecode
<p>Hey,</p>
<p>I just experienced the infamous ``cache_lock: blocked on 0xd591d418 ""'' message. Checking why the process got stuck revealed that the lock is actually being held by another process which is in the process of doing a lstat(2) on /mnt, a nfs mount which server went away. The stuck process is doing the same, fwiw.</p>
<p>So here it is not a namecache bug, but rather an artifact of nfs being stuck. Anoying nevertheless. Anybody have a clue how to fix that? Yea, mount with -intr. Why don't we do that per default?</p>
<p>cheers<br /> simon</p> DragonFlyBSD - Bug #742 (In Progress): umount problems with multiple mountshttps://bugs.dragonflybsd.org/issues/7422007-07-27T02:46:01Zcorecode
<p>hey,</p>
<p>yes, my fault, but:</p>
<pre>
%mount
/dev/ad6s1a on / (ufs, local, soft-updates)
/dev/ad6s1b on /pbulk (ufs, local, soft-updates)
/ on /pbulk/clients/labospc67_1/root (null, local, read-only)
/pbulk/clients/labospc67_1/var on /pbulk/clients/labospc67_1/root/var (null, local)
/pbulk/clients/labospc67_1/tmp on /pbulk/clients/labospc67_1/root/tmp (null, local)
/pbulk/clients/labospc67_1/dev on /pbulk/clients/labospc67_1/root/dev (null, local)
/ on /pbulk/clients/labospc67_1/root (null, local, read-only)
%umount labospc67_1/root
umount: unmount of /pbulk/clients/labospc67_1/root failed: Device busy
%umount /pbulk/clients/labospc67_1/root/var
umount: unmount of /pbulk/clients/labospc67_1/root/var failed: Invalid argument
</pre>
<p>something is wrong here. i guess I can't umount the "upper" root mount, because it takes the "lower" root mount first. dito for the subdirs.</p>
<p>cheers<br /> simon</p> DragonFlyBSD - Bug #731 (New): system freeze on "slice too large"https://bugs.dragonflybsd.org/issues/7312007-07-15T20:11:05Zcorecode
<p>hey,</p>
<p>i've now had twice a nasty freeze (kind of) with something like this (hand transcribed):</p>
<p><code>dscheck(#ad/0x20021): slice too large 2/2</code><br />..</p>
<p>then vinum tells me that it put "build" down and continues:</p>
<p>fatal: build.p0.s0 read error, offset 33831591936 for 4096 bytes<br />build.p0.s0: user buffer offset 10209280000 for 4096 bytes</p>
<p>(more slice too large follow)</p>
<p>then, the namecache does</p>
<p>blocked on 0xd4fb7b58 "corecode"</p>
<p>and repeats it every 30 seconds or so. system is unoperable at this point.</p>
<p>breaking to the debugger works, but dumpsys does not work:</p>
<pre>
dumping to dev #ad/0x20023, blockno 2130432
dump failed, reason: area improper
</pre>
<p>i'm running:<br /><pre>
DragonFly sweatshorts.home.corecode.ath.cx 1.9.0-DEVELOPMENT DragonFly 1.9.0-DEVELOPMENT #14: Sun Jun 17 11:03:58 CEST 2007 corecode@sweatshorts.home.corecode.ath.cx:/usr/build/obj/usr/build/src/sys/SWEATSHORTS i386
</pre></p>
<p>i've attached relevant outputs.</p>
<p>thanks,<br /> simon</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>