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 - 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 #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 #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 #1831 (Feedback): HAMMER "malloc limit exceeded" panichttps://bugs.dragonflybsd.org/issues/18312010-09-11T23:42:36Zeocallaghan
<p>I was able to reproduce with a hammer equivalent of issue1726 with the following<br />test case from vsrinivas in issue1726:</p>
<pre>
<code class="c syntaxhl" data-language="c"><span class="cp">#include</span> <span class="cpf"><unistd.h></span><span class="cp">
#include</span> <span class="cpf"><stdlib.h></span><span class="cp">
#include</span> <span class="cpf"><stdio.h></span><span class="cp">
</span>
<span class="n">main</span><span class="p">()</span> <span class="p">{</span>
<span class="kt">int</span> <span class="n">i</span><span class="p">;</span>
<span class="kt">char</span> <span class="n">id</span><span class="p">[</span><span class="mi">320</span><span class="p">]</span> <span class="o">=</span> <span class="p">{};</span>
<span class="k">for</span> <span class="p">(</span><span class="n">i</span> <span class="o">=</span> <span class="mi">0</span><span class="p">;</span> <span class="n">i</span> <span class="o"><</span> <span class="mi">10000000</span><span class="p">;</span> <span class="n">i</span><span class="o">++</span><span class="p">)</span> <span class="p">{</span>
<span class="n">sprintf</span><span class="p">(</span><span class="n">id</span><span class="p">,</span> <span class="s">"%09d"</span><span class="p">,</span> <span class="n">i</span><span class="p">);</span>
<span class="n">link</span><span class="p">(</span><span class="s">"sin.c"</span><span class="p">,</span> <span class="n">id</span><span class="p">);</span>
<span class="p">}</span>
<span class="k">return</span> <span class="mi">0</span><span class="p">;</span>
<span class="p">}</span>
</code><br /></pre>
<p>----<br /><pre>
(kgdb) bt
#0 _get_mycpu (di=0xc06d4ca0) at ./machine/thread.h:83
#1 md_dumpsys (di=0xc06d4ca0)
at /usr/src/sys/platform/pc32/i386/dump_machdep.c:263
#2 0xc0304d15 in dumpsys () at /usr/src/sys/kern/kern_shutdown.c:880
#3 0xc03052d5 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:387
#4 0xc030559e in panic (fmt=0xc05bb41b "%s: malloc limit exceeded")
at /usr/src/sys/kern/kern_shutdown.c:786
#5 0xc03032bb in kmalloc (size=25, type=0xc1d8f590, flags=258)
at /usr/src/sys/kern/kern_slaballoc.c:503
#6 0xc04aa5a3 in hammer_alloc_mem_record (ip=0xcb803d50, data_len=25)
at /usr/src/sys/vfs/hammer/hammer_object.c:280
#7 0xc04aa91f in hammer_ip_add_directory (trans=0xce350ad4,
dip=0xcb803d50, name=0xd3cdb1d0 "000452457", bytes=9, ip=0xce31df50)
at /usr/src/sys/vfs/hammer/hammer_object.c:666
#8 0xc04bbf8a in hammer_vop_nlink (ap=0xce350b2c)
at /usr/src/sys/vfs/hammer/hammer_vnops.c:1388
#9 0xc036cc1f in vop_nlink_ap (ap=0xce350b2c)
at /usr/src/sys/kern/vfs_vopops.c:1978
#10 0xc03717ca in null_nlink (ap=0xce350b2c)
at /usr/src/sys/vfs/nullfs/null_vnops.c:164
#11 0xc036d465 in vop_nlink (ops=0xcdbbe030, nch=0xce350c48,
dvp=0xce0913e8, vp=0xce2f04e8, cred=0xcdef1738)
at /usr/src/sys/kern/vfs_vopops.c:1397
---Type <return> to continue, or q <return> to quit---
---Type <return> to continue, or q <return> to quit---#12 0xc0365496 in
kern_link (nd=0xce350c80, linknd=0xce350c48)
at /usr/src/sys/kern/vfs_syscalls.c:2320
#13 0xc036ad49 in sys_link (uap=0xce350cf0)
at /usr/src/sys/kern/vfs_syscalls.c:2345
#14 0xc055f6b3 in syscall2 (frame=0xce350d40)
at /usr/src/sys/platform/pc32/i386/trap.c:1310
#15 0xc0547fb6 in Xint0x80_syscall ()
at /usr/src/sys/platform/pc32/i386/exception.s:876
#16 0x0000001f in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(kgdb)
</pre></p>
<p>Dump on my leaf account;<br /><a class="external" href="http://leaf.dragonflybsd.org/~evocallaghan/hammer_vfs_panic.7z">http://leaf.dragonflybsd.org/~evocallaghan/hammer_vfs_panic.7z</a></p>
<p>Cheers,<br />Edward.</p> DragonFlyBSD - Bug #1727 (Feedback): CD boot panic (2.6.1) (usb?)https://bugs.dragonflybsd.org/issues/17272010-04-14T08:55:06Zkiril
<p>dfly Live CD 2.6.1 panics on boot. logging a bug report with photos attached <br />as per SW's request. booting with ehci does not make any difference.</p>
<p>please let me know if a .zip it not an acceptable format.</p> DragonFlyBSD - Bug #1717 (Feedback): HAMMER panic in hammer_cursor_down()https://bugs.dragonflybsd.org/issues/17172010-04-08T09:25:15Zjosepht1
<p>I got the following panic (sorry it's just a backtrace):</p>
<p>panic: BTYPE MISMATCH L <br />Trace beginning at frame 0xdf17171c<br />panic(df171740,cee83300,df1717f4,e3903248,df171764) at panic+0x8c<br />panic(c06029f3,4c,0,e3903248,cefdf000) at panic+0x8c<br />hammer_cursor_down(df1717f4) at hammer_cursor_down+0x113<br />hammer_btree_iterate_reverse(df1717f4,df171a58,0,0,cefdf040) at<br />hammer_btree_iterate_reverse+0x1c0<br />hammer_ioc_prune(df171a58,d91c5610,dc874f00,df17195c,1) at<br />hammer_ioc_prune+0x682<br />hammer_ioctl(d91c5610,c0fc6801,dc874f00,1,d50b1050) at<br />hammer_ioctl+0x1c8<br />hammer_vop_ioctl(df171ac8,df171abc,d8797ab4,d8797ab4,d8cf32f0) at<br />hammer_vop_ioctl+0x2f<br />vop_ioctl(d8cead10,c47f3d28,c0fc6801,dc874f00,1) at vop_ioctl+0x58<br />vn_ioctl(d50f0338,c0fc6801,dc874f00,d50b1050,df171cf0) at<br />vn_ioctl+0xe0<br />mapped_ioctl(5,c0fc6801,280f0188,0,df171cf0) at mapped_ioctl+0x3e4<br />sys_ioctl(df171cf0,6,0,0,d86fa9d0) at sys_ioctl+0x17<br />syscall2(df171d40) at syscall2+0x20e<br />Xint0x80_syscall() at Xint0x80_syscall+0x36</p>
<p>I've uploaded the kern.25.gz and vmcore.25.gz to my leaf account.</p>
<p>Thanks,<br />Joe</p> DragonFlyBSD - Bug #1592 (Feedback): AcpiOSUnmapMemory : Warning, deallocation did not track allo...https://bugs.dragonflybsd.org/issues/15922009-10-31T23:37:47Zeocallaghan
<p>Each time the machine shuts down, dmesg throws a nasty looking message:</p>
<p>Shutting down ACPI<br />AcpiOsUnmapMemory : Warning, deallocation did not track allocation:<br />0xda627f60/000000a0 (actual was 0xda628000/00000032)</p>
<p>ver, 2.4.1 , i386, Lenovo X301.</p>
<p>Regards,<br />Edward.</p> DragonFlyBSD - Bug #1411 (Feedback): Burning doesn't work with ahci(4)https://bugs.dragonflybsd.org/issues/14112009-06-28T02:21:19Zhasso
<p>Burning (I have only DVD-RW to test with, though) doesn't work with SATA <br />burner attaching to ahci(4). Nata still works fine. Verbose cdrecord log for <br />simple blank process is available at <br /><a class="external" href="http://leaf.dragonflybsd.org/~hasso/ahci-cdrecord-verbose-blank.log">http://leaf.dragonflybsd.org/~hasso/ahci-cdrecord-verbose-blank.log</a></p> DragonFlyBSD - Bug #1332 (Feedback): DFBSD 2.2 - Booting usbcdrom/usbsticks on thinkpad hangs on ...https://bugs.dragonflybsd.org/issues/13322009-04-09T19:44:06Ztuxillo
<p>Hi</p>
<p>This is a bug reported by claus on the IRC and initally investigated by Jordan<br />(smtms).</p>
<p>It seems that booting USB cdrom/stick on a Thinkpad (model still to determine)<br />hangs and stops with BTX Halted.</p>
<p>claus reported that FBSD 7.1 booted without problems with that USB Cdrom drive,<br />but with FBSD 7.0 it crashes also.</p>
<p>This is a know issue on FreeBSD that was fixed in revision 177039. Also relevant<br />revisions are 181433, 181436 and 189017.</p>
<p>Cheers,<br />Antonio</p> DragonFlyBSD - Bug #979 (Feedback): Failure-prone USB mass storage (SB600? msdosfs? CAM?)https://bugs.dragonflybsd.org/issues/9792008-03-23T00:52:39Zfloid
<p>I'm still very behind when it comes to keeping track of development, so pardon<br />if this is known. I always need to do more testing, but some feedback will help<br />me narrow down the test cases.</p>
<p>Symptoms:</p>
<p>Using 1.12.0-RELEASE, copying from a FAT-formatted 2GB CF card in a reader with<br />a "Genesys" chipset hangs after the first ~82MB have been copied. A "hang" is<br />determined as iostat showing 0 throughput and cp not responding to ^C.</p>
<p>ehci.ko is <strong>not</strong> loaded, so ohci alone was involved here.</p>
<p>Hardware considerations:</p>
<p>SMP kernel (Athlon 64 x2)<br />SB600<br />The reader is part of a Mitsumi floppy combo device<br /> (A slim conventional floppy and USB card reader crammed into one 3.5" box.)</p>
<p>Relevant portion of usbdevs -v:<br />Controller /dev/usb4:<br />addr 1: full speed, self powered, config 1, OHCI root hub(0x0000), <abbr title="0x0000">ATI</abbr>,<br />rev 1.00<br /> port 1 addr 2: full speed, power 500 mA, config 1, USB Reader(0x070e),<br />Genesys(0x05e3), rev 93.25<br /> port 2 powered</p>
<p>...</p>
<p>The following from CAM was found in dmesg. I <strong>believe</strong> this was printed before<br />I rudely pulled the card, however I cannot be sure. (Have we considered<br />timestamping dmesg yet?) There was nothing else new in dmesg.</p>
<p>(da0:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 <br />(da0:umass-sim0:0:0:0): CAM Status: SCSI Status Error<br />(da0:umass-sim0:0:0:0): SCSI Status: Check Condition<br />(da0:umass-sim0:0:0:0): UNIT ATTENTION asc:28,0<br />(da0:umass-sim0:0:0:0): Not ready to ready change, medium may have changed<br />(da0:umass-sim0:0:0:0): Retrying Command (per Sense Data)</p>
<p>Similarly, cp has produced some odd output, but since the card was pulled and<br />the hung cp was left sitting for 24 hours before I got around to reporting this,<br />I'm not sure what happened here. :}</p>
<p>%cd /home/floid/Photos/<br />%cp /mnt/dcim/101olymp/* .<br />cp: ./pa091308.jpg: Bad address<br />cp: ./pa091307.jpg: Bad address<br />cp: /mnt/dcim/101olymp/pa091306.jpg: Input/output error<br />cp: /mnt/dcim/101olymp/pa091303.jpg: Input/output error<br />cp: /mnt/dcim/101olymp/pa091302.jpg: Cross-device link<br />^C</p>
<p>Adding to my confusion, the Linux (Ubuntu 7.10) machine I would attempt to read<br />the card with has a similar hardware configuration (another SB600, another card<br />reader that's also Genesys Logic-based) and its own intractable problems with<br />USB in general! On review, I see that Linux ("2.6.22-14-generic <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> SMP" i686)<br />made it exactly 32MB into the card before a majority of its USB support locked<br />up. Unfortunately that's been happening whenever anyone breathes near that<br />machine, and proprietary VMWare and fglrx modules are involved, so it'll be a<br />while before I can fsck or chkdsk the filesystem structure on the CF card itself!</p>
<p>(The media should be fine, since the camera has had no complaints.)</p>
<p>===</p>
<p>Should I be suspecting the filesystem, CAM (I've noticed Peter Avalos's work on<br />CAM locking but haven't tried it yet), or the basic hardware support?</p> DragonFlyBSD - Bug #570 (Feedback): 1.8.x: ACPI problemshttps://bugs.dragonflybsd.org/issues/5702007-03-03T11:46:01Zqhwt+dfly
<p>So if you enable ACPI and boot, it won't respond to keyboard no matter<br />whether you choose to boot into single- or multi-user mode?</p>
<p>So ... your keyboard does not work when you boot straight into the<br />single user mode, whether with or without ACPI driver enabled, right?<br />If not, I have no idea what this part really means:<br /> > But If I boot to non-ACPI-mode, everything works<br /> > just fine, but I can't get to sigle user mode, because prompt freezes<br /> > there too...</p>
<p>If the message buffer(which dmesg command shows you) survives across<br />reboot, I'd like to look at it after you boot with ACPI driver enabled<br />and booted with `boot -v' from the boot loader prompt (did I ask if<br />keyboard works when you go into the boot loader prompt?).</p>
<p>Cheers.</p>