DragonFlyBSD bugtracker: Issueshttps://bugs.dragonflybsd.org/https://bugs.dragonflybsd.org/favicon.ico?16293952082018-10-26T14:34:46ZDragonFlyBSD bugtracker
Redmine 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 - 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 - 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 - 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> DragonFlyBSD - Bug #2288 (Feedback): Random IO performance loss introduced since January 1sthttps://bugs.dragonflybsd.org/issues/22882012-01-24T13:02:54Zlentferj
<p>Running pgbench I found that performance had dropped by 13%. To figure out the reason I did some sysbench io tests (see below). All tests were run using the same test files, same hardware etc etc 3 times in a row. As the results were consistent I am only pasting the result of the last run of each set.</p>
<p>The cause for the performance loss must have been introduced some time between Jan 1st and Jan 23rd.</p>
<p>2.12:<br />atom# sysbench --test=fileio --file-num=8 --file-total-size=6G --file-test-mode=rndrd --max-requests=0 --max-time=300 run<br />sysbench 0.4.12: multi-threaded system evaluation benchmark</p>
<p>Running the test with following options:<br />Number of threads: 1</p>
<p>Extra file open flags: 0<br />8 files, 768Mb each<br />6Gb total file size<br />Block size 16Kb<br />Number of random requests for random IO: 0<br />Read/Write ratio for combined random IO test: 1.50<br />Periodic FSYNC enabled, calling fsync() each 100 requests.<br />Calling fsync() at the end of test, Enabled.<br />Using synchronous I/O mode<br />Doing random read test<br />Threads started!<br />Time limit exceeded, exiting...<br />Done.</p>
<p>Operations performed: 50389 Read, 0 Write, 0 Other = 50389 Total<br />Read 787.33Mb Written 0b Total transferred 787.33Mb (2.6244Mb/sec)<br /> 167.96 Requests/sec executed</p>
<p>Test execution summary:<br /> total time: 300.0027s<br /> total number of events: 50389<br /> total time taken by event execution: 299.7273<br /> per-request statistics:<br /> min: 0.02ms<br /> avg: 5.95ms<br /> max: 77.80ms<br /> approx. 95 percentile: 12.05ms</p>
<p>Threads fairness:<br /> events (avg/stddev): 50389.0000/0.00<br /> execution time (avg/stddev): 299.7273/0.00</p>
<p>2.13 g47f97 (new year's eve):<br />atom# sysbench --test=fileio --file-num=8 --file-total-size=6G --file-test-mode=rndrd --max-requests=0 --max-time=300 run<br />sysbench 0.4.12: multi-threaded system evaluation benchmark</p>
<p>Running the test with following options:<br />Number of threads: 1</p>
<p>Extra file open flags: 0<br />8 files, 768Mb each<br />6Gb total file size<br />Block size 16Kb<br />Number of random requests for random IO: 0<br />Read/Write ratio for combined random IO test: 1.50<br />Periodic FSYNC enabled, calling fsync() each 100 requests.<br />Calling fsync() at the end of test, Enabled.<br />Using synchronous I/O mode<br />Doing random read test<br />Threads started!<br />Time limit exceeded, exiting...<br />Done.</p>
<p>Operations performed: 50037 Read, 0 Write, 0 Other = 50037 Total<br />Read 781.83Mb Written 0b Total transferred 781.83Mb (2.6061Mb/sec)<br /> 166.79 Requests/sec executed</p>
<p>Test execution summary:<br /> total time: 300.0040s<br /> total number of events: 50037<br /> total time taken by event execution: 299.7070<br /> per-request statistics:<br /> min: 0.02ms<br /> avg: 5.99ms<br /> max: 104.73ms<br /> approx. 95 percentile: 12.06ms</p>
<p>Threads fairness:<br /> events (avg/stddev): 50037.0000/0.00<br /> execution time (avg/stddev): 299.7070/0.00</p>
<p>2.13 (from Jan 23rd incl. the sili/ahci fix):<br />atom# sysbench --test=fileio --file-num=8 --file-total-size=6G --file-test-mode=rndrd --max-requests=0 --max-time=300 run<br />sysbench 0.4.12: multi-threaded system evaluation benchmark</p>
<p>Running the test with following options:<br />Number of threads: 1</p>
<p>Extra file open flags: 0<br />8 files, 768Mb each<br />6Gb total file size<br />Block size 16Kb<br />Number of random requests for random IO: 0<br />Read/Write ratio for combined random IO test: 1.50<br />Periodic FSYNC enabled, calling fsync() each 100 requests.<br />Calling fsync() at the end of test, Enabled.<br />Using synchronous I/O mode<br />Doing random read test<br />Threads started!<br />Time limit exceeded, exiting...<br />Done.</p>
<p>Operations performed: 39898 Read, 0 Write, 0 Other = 39898 Total<br />Read 623.41Mb Written 0b Total transferred 623.41Mb (2.078Mb/sec)<br /> 132.99 Requests/sec executed</p>
<p>Test execution summary:<br /> total time: 300.0038s<br /> total number of events: 39898<br /> total time taken by event execution: 299.7377<br /> per-request statistics:<br /> min: 0.02ms<br /> avg: 7.51ms<br /> max: 61.00ms<br /> approx. 95 percentile: 12.27ms</p>
<p>Threads fairness:<br /> events (avg/stddev): 39898.0000/0.00<br /> execution time (avg/stddev): 299.7377/0.00</p> DragonFlyBSD - Bug #2090 (Feedback): snd_hda does not support headphone automutehttps://bugs.dragonflybsd.org/issues/20902011-06-15T07:46:35Zjustin
<p>The hda sound driver does not notice jack insert/removal events. Even when<br />booted verbosely, there's no action, so attaching headphones does not mute<br />speaker audio.</p>
<p>An update to FreeBSD's sound/pci/hda expressly mentions solving this problem:</p>
<p><a class="external" href="http://svnweb.freebsd.org/base?view=revision&revision=182999">http://svnweb.freebsd.org/base?view=revision&revision=182999</a></p> DragonFlyBSD - Bug #2081 (Feedback): Panic on device "detach" / "failure"https://bugs.dragonflybsd.org/issues/20812011-05-24T22:27:54Zvsrinivasvsrinivas@ops101.org
<p>...<br />ad10: FAILURE - device detached<br />subdisk10: detached<br />ad10: detached</p>
<p>Fatal trap 12: page fault while in kernel mode<br />fault virtual address = 0xa4<br />fault code = supervisor write, page not present<br />instruction pointer = 0x8:0xc03457e3<br />stack pointer = 0x10:0xc96aac44<br />frame pointer = 0x10:0xc96aac5c<br />code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, def32 1, gran 1<br />processor eflags = interrupt enabled, resume, IOPL = 0<br />current process = Idle<br />current thread = pri 14 (CRIT)</p>
<p>trap number = 12<br />panic: page fault<br />Trace beginning at frame 0xc96aab20<br />panic(ffffffff,c07ace20,c064edd8,c96aab50,c96aabfc) at panic+0x101<br />panic(c064edd8,c067eace,1,1,1) at panic+0x101<br />trap_fatal(0,0,1,1,3130) at trap_fatal+0x33f<br />trap_pfault(c034d4b3,c7d8c9f8,0,c96aabe4,a4) at trap_pfault+0x13c<br />trap(c96aabfc) at trap+0x4c6<br />calltrap() at calltrap+0xd<br />--- trap 0, eip = 0x2, esp = 0x10296, ebp = 0x1 ---<br />Uptime: 2d21h28m20s<br />Physical memory: 502 MB<br />Dumping 204 MB: 189 173 157 141 125 109 93 77 61 45 29 13</p> DragonFlyBSD - Bug #1860 (Feedback): Panic while creating UFS fs on vn(4) for initrdhttps://bugs.dragonflybsd.org/issues/18602010-10-05T00:02:53Zmatthias
<p>HI,</p>
<p>while creating an initrd with mkinitrd (creates an UFS file system on a<br />vn(4) disk the box paniced.</p>
<p>Crash dump is on its way to leaf in ~matthias/crash/crash_vn.7z (7zip<br />archive). The box runs master from Sep 27.</p>
<p>Cheers</p>
<pre><code>Matthias</code></pre> DragonFlyBSD - Bug #1824 (Feedback): kernel panic, x86, 2.7.3.859.ge5104https://bugs.dragonflybsd.org/issues/18242010-09-08T06:25:18Zakirchhoff135014
<p>SMP enabled, otherwise a GENERIC kernel.</p>
<p>Full backtrace:</p>
<p>(kgdb) bt<br />#0 _get_mycpu (di=0xc06ebee0) at ./machine/thread.h:83<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> md_dumpsys (di=0xc06ebee0) at <br />/usr/src/sys/platform/pc32/i386/dump_machdep.c:263<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> 0xc0315d31 in dumpsys () at /usr/src/sys/kern/kern_shutdown.c:880<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> 0xc03162f1 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:387<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> 0xc03165ba in panic (fmt=0xc06122c4 "m_copym, length > size of mbuf <br />chain")<br /> at /usr/src/sys/kern/kern_shutdown.c:786<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> 0xc034f662 in m_copym (m=0x0, off0=32, len=24, wait=4) at <br />/usr/src/sys/kern/uipc_mbuf.c:1113<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> 0xc03ec2e6 in tcp_output (tp=0xdcc96d88) at <br />/usr/src/sys/netinet/tcp_output.c:723<br /><a class="issue tracker-1 status-5 priority-3 priority-lowest closed" title="Bug: /sys/boot cleanup (Closed)" href="https://bugs.dragonflybsd.org/issues/7">#7</a> 0xc03f38da in tcp_usr_send (so=0xc6a73698, flags=<value optimized out>, <br />m=0xe20ca900, nam=0x0, control=0x0, <br /> td=0xdcc96988) at /usr/src/sys/netinet/tcp_usrreq.c:762<br /><a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: make upgrade broken (Closed)" href="https://bugs.dragonflybsd.org/issues/8">#8</a> 0xc03518a4 in netmsg_pru_send (msg=0xe5c15b5c) at <br />/usr/src/sys/kern/uipc_msg.c:548<br /><a class="issue tracker-1 status-5 priority-5 priority-high3 closed" title="Bug: panic with HEAD (Closed)" href="https://bugs.dragonflybsd.org/issues/9">#9</a> 0xc03a4674 in netmsg_service (msg=0xe5c15b5c, mpsafe_mode=1, mplocked=0) <br />at /usr/src/sys/net/netisr.c:310<br /><a class="issue tracker-1 status-5 priority-5 priority-high3 closed" title="Bug: make buildworld broken (Closed)" href="https://bugs.dragonflybsd.org/issues/10">#10</a> 0xc03a478a in netmsg_service_loop (arg=0xc068cda0) at <br />/usr/src/sys/net/netisr.c:357<br /><a class="issue tracker-1 status-5 priority-3 priority-lowest closed" title="Bug: libstand cleanup (Closed)" href="https://bugs.dragonflybsd.org/issues/11">#11</a> 0xc031f2ae in lwkt_deschedule_self (td=Cannot access memory at address 0x8<br />) at /usr/src/sys/kern/lwkt_thread.c:278<br />Backtrace stopped: previous frame inner to this frame (corrupt stack?)</p>
<p>I was building some packages in the background at the time. I was ssh'ed in <br />from a linux box, and running x2x to allow me to move the mouse and keyboard <br />from the linux box to the DF box. At the time of the lock up, I was moving <br />the mouse around on the DF box. Though I have no idea if that's related to <br />the crash, that's the only thing that comes to mind.</p>
<p>Adam</p>