DragonFlyBSD bugtracker: Issueshttps://bugs.dragonflybsd.org/https://bugs.dragonflybsd.org/favicon.ico?16293952082020-03-30T00:27:57ZDragonFlyBSD bugtracker
Redmine DragonFlyBSD - Bug #3228 (New): pfi_kif_unref: state refcount <= 0 in dmesghttps://bugs.dragonflybsd.org/issues/32282020-03-30T00:27:57Zjustin
<p>I see this in dmesg:</p>
<p>pfi_kif_unref: state refcount <= 0</p>
<p>Maybe about 100-125 in a day, in an estimate. This machine is using pf to NAT, with a few extra rules that are not in use. There doesn't seem to be any harm in these messages, but they've been going on for a long time. (several releases at least.)</p> DragonFlyBSD - Bug #3107 (New): ACPI interrupt storm when loading i915 on Lenovo T460https://bugs.dragonflybsd.org/issues/31072017-12-04T07:47:37Zoyvinhtoyvinht@pvv.ntnu.no
<p>This is on a Lenovo T460 (firmware r06uj56d)</p>
<pre><code>root# uname -a<br /> DragonFly slaptop 5.1-DEVELOPMENT DragonFly v5.1.0.381.ge8ac90-DEVELOPMENT #10: Mon Dec 4 07:52:28 CET 2017 root@slaptop:/usr/obj/usr/src/sys/SLAPTOP x86_64</code></pre>
<p>After doing:</p>
<pre><code>root# kldload i915</code></pre>
<p>the systems gets very slow, and looking at vmstat I see interrupts from acpi0 increasing by 2000-5000 every second (using kern.livelock_lowater=1000 and kern.livelock_limit=2000 makes the system usable again):</p>
<pre><code>root# vmstat -i</code></pre>
<pre><code>interrupt total rate<br /> acpi0 1681307 1925</code></pre>
<p>FWIW I have tested enabling DDB and INVARIANTS in the kernel, and built /sys/dev/acpica with ACPI_DEBUG=1, which fills the kernel message buffer with messages like:</p>
<pre><code>evgpe-0634 EvGpeDetect : Read registers for GPE 60-67: Status=40, Enable=46, RunEnable=46, WakeEnable=00<br /> evgpe-0607 EvGpeDetect : Ignore disabled registers for GPE 68-6F: RunEnable=00, WakeEnable=00<br /> evgpe-0607 EvGpeDetect : Ignore disabled registers for GPE 70-77: RunEnable=00, WakeEnable=00<br /> evgpe-0607 EvGpeDetect : Ignore disabled registers for GPE 78-7F: RunEnable=00, WakeEnable=00<br /> evevent-0361 EvFixedEventDetect : Fixed Event Block: Enable 00000120 Status 00000001<br /> evgpe-0607 EvGpeDetect : Ignore disabled registers for GPE 00-07: RunEnable=00, WakeEnable=00<br /> evgpe-0607 EvGpeDetect : Ignore disabled registers for GPE 08-0F: RunEnable=00, WakeEnable=00</code></pre> DragonFlyBSD - Bug #2931 (New): 'gdb' of 'vkernel' unable to print backtracehttps://bugs.dragonflybsd.org/issues/29312016-07-26T20:33:39Ztofergus
<p>Whilst attempting to look at issue <a class="issue tracker-5 status-5 priority-4 priority-default closed" title="Submit: PCIe memory mapped config (Closed)" href="https://bugs.dragonflybsd.org/issues/2390">#2390</a> I came across the 'vkernel' debugging page in the wiki</p>
<p><a class="external" href="https://www.dragonflybsd.org/docs/howtos/HowToDebugVKernels/">https://www.dragonflybsd.org/docs/howtos/HowToDebugVKernels/</a></p>
<p>this noted a failure in the current implementation, which caused lockup (issue <a class="issue tracker-1 status-5 priority-5 priority-high3 closed" title="Bug: gdb vkernel doesn't work at all anymore (Closed)" href="https://bugs.dragonflybsd.org/issues/1301">#1301</a>). However my STABLE build</p>
<p>[...] 4.4-RELEASE DragonFly v4.4.3.9.ge5cb2-RELEASE #0: Fri Jul 15 17:02:58 UTC 2016 [...]/usr/obj/usr/src/sys/VKERNEL64 x86_64</p>
<p>attaches correctly</p>
<p>$ sudo gdb /var/vkernel/boot/kernel/kernel 8418<br />GNU gdb (GDB) 7.6.1<br />Copyright (C) 2013 Free Software Foundation, Inc.<br />License GPLv3+: GNU GPL version 3 or later <<a class="external" href="http://gnu.org/licenses/gpl.html">http://gnu.org/licenses/gpl.html</a>><br />This is free software: you are free to change and redistribute it.<br />There is NO WARRANTY, to the extent permitted by law. Type "show copying" <br />and "show warranty" for details.<br />This GDB was configured as "x86_64-dragonfly".<br />For bug reporting instructions, please see:<br /><<a class="external" href="http://bugs.dragonflybsd.org/&gt;">http://bugs.dragonflybsd.org/&gt;</a>...<br />Reading symbols from /var/vkernel/boot/kernel/kernel...done.<br />Attaching to program: /var/vkernel/boot/kernel/kernel, process 8418<br />Reading symbols from /lib/libc.so.8...(no debugging symbols found)...done.<br />Loaded symbols for /lib/libc.so.8<br />Reading symbols from /libexec/ld-elf.so.2...(no debugging symbols found)...done.<br />Loaded symbols for /libexec/ld-elf.so.2<br />0x00000000100a3750 in extpread () from /lib/libc.so.8</p>
<p>but then causes an exception whilst trying to print a backtrace</p>
<p>(gdb) bt<br />#0 0x00000000100a3750 in extpread () from /lib/libc.so.8<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> 0x00000000101374ab in pread () from /lib/libc.so.8<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> 0x00000000006b9614 in vconsgetc (private=<optimized out>)<br /> at /usr/src/sys/platform/vkernel64/platform/console.c:384<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> 0x00000000005040a6 in cngetc () at /usr/src/sys/kern/tty_cons.c:512<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> 0x0000000000473e6a in db_readline (<br /> lstart=lstart@entry=0xa7f480 <db_line> "", lsize=lsize@entry=120)<br /> at /usr/src/sys/ddb/db_input.c:313<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> 0x00000000004743d2 in db_read_line () at /usr/src/sys/ddb/db_lex.c:55<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> 0x0000000000472ed9 in db_command_loop ()<br /> at /usr/src/sys/ddb/db_command.c:465<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> 0x0000000000475cff in db_trap (type=type@entry=3, code=code@entry=0)<br /> at /usr/src/sys/ddb/db_trap.c:71<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> 0x00000000006ab64e in kdb_trap (type=type@entry=3, code=code@entry=0, <br /> regs=regs@entry=0x802a866a68)<br /> at /usr/src/sys/platform/vkernel64/x86_64/db_interface.c:173<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> 0x00000000006add1c in kern_trap (frame=0x802a866a68)<br /> at /usr/src/sys/platform/vkernel64/x86_64/trap.c:769<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> 0x00000000006aef32 in exc_segfault (signo=<optimized out>,<br /> info=<optimized out>, ctxp=<optimized out>)<br /> at /usr/src/sys/platform/vkernel64/x86_64/exception.c:209<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> <signal handler called><br /><a class="issue tracker-1 status-5 priority-3 priority-lowest closed" title="Bug: /sys/net cleanup (Closed)" href="https://bugs.dragonflybsd.org/issues/12">#12</a> 0x000000802a8670a0 in ?? ()<br />Cannot access memory at address 0x1</p>
<p>This causes 'ddb' to exit and the process to halt. Presume this is due to the SIGSTOP that halts the 'db>' prompt but unable to decipher how this might be resolved. '~/.gdbinit' contains the</p>
<p>handle SIGSEGV noprint<br />handle SIGUSR1 noprint</p>
<p>suggested in the article. Adding SIGSTOP has no effect.</p>
<p>Additionally, connecting to a running 'vkernel' with 'gdb' appears to have a similar effect; the console is disconnected (although the kernel appears to run).</p>
<p>Happy to document if this is purely an information gap on my part.</p> DragonFlyBSD - Bug #2887 (New): Missing extattr_namespace_to_string and extattr_string_to_namespa...https://bugs.dragonflybsd.org/issues/28872016-02-06T13:09:05Zrubenkruben@rubenkerkhof.com
<p>Hi,</p>
<p>I'm working on porting Burp (<a class="external" href="http://burp.grke.org">http://burp.grke.org</a>) to DragonFly.<br />I've been looking into what it would take for it to support backing up extended attributes.</p>
<p>Burp uses the extattr_namespace_to_string and extattr_string_to_namespace functions, which FreeBSD has in libutil.h and NetBSD in sys/extattr.h. DragonFlyBSD misses those however.</p>
<p>Would it be possible to add those functions?</p> DragonFlyBSD - Bug #2680 (New): boot0cfg update makes box unbootablehttps://bugs.dragonflybsd.org/issues/26802014-06-07T17:56:45Zherrgard
<p>If I hit any of the F-keys box will not boot next time. Laptop says "Bootable device not found".</p>
<p>Workaround: install boot0 in noupdate mode:</p>
<blockquote>
<p>fdisk -I da0<br />boot0cfg -B -o noupdate da0</p>
</blockquote>
<p>Only running boot0cfg and not fdisk does not fix it. Warning: fdisk may mess up your fancy slice setup.</p> DragonFlyBSD - Bug #2675 (New): Ultimate N WiFi Link 5300 get iwn_intr: fatal firmware error on 5GHzhttps://bugs.dragonflybsd.org/issues/26752014-05-28T22:54:41Zrevuwa
<p>I'm using a Lenovo Thinkad X200s with Intel Ultimate N WiFi Link 5300.</p>
<p>On Dragonfly BSD 3.6.2 it worked perfectly without any errors (and exactly the same configuration). Since 3.7.X and the actual testes 3.8.0RC my WiFi decive throws the following error on every try to load it (also over manual /etc/rc.d/netif restart):</p>
<ol>
<li>dmesg.boot (with rc_debug enabled) ###<br />iwn0: iwn_intr: fatal firmware error<br />firmware error log:<br /> error type = "SYSASSERT" (0x00000005)<br /> program counter = 0x00003130<br /> source line = 0x00000585<br /> error data = 0x0000000100000000<br /> branch link = 0x0000312A0000312A<br /> interrupt link = 0x0000091600000000<br /> time = 1270108785<br />driver status:<br /> tx ring 0: qid=0 cur=0 queued=0 <br /> tx ring 1: qid=1 cur=0 queued=0 <br /> tx ring 2: qid=2 cur=0 queued=0 <br /> tx ring 3: qid=3 cur=3 queued=0 <br /> tx ring 4: qid=4 cur=0 queued=0 <br /> tx ring 5: qid=5 cur=0 queued=0 <br /> tx ring 6: qid=6 cur=0 queued=0 <br /> tx ring 7: qid=7 cur=0 queued=0 <br /> tx ring 8: qid=8 cur=0 queued=0 <br /> tx ring 9: qid=9 cur=58 queued=0 <br /> tx ring 10: qid=10 cur=0 queued=0 <br /> tx ring 11: qid=11 cur=0 queued=0 <br /> tx ring 12: qid=12 cur=0 queued=0 <br /> tx ring 13: qid=13 cur=0 queued=0 <br /> tx ring 14: qid=14 cur=0 queued=0 <br /> tx ring 15: qid=15 cur=0 queued=0 <br /> tx ring 16: qid=16 cur=0 queued=0 <br /> tx ring 17: qid=17 cur=0 queued=0 <br /> tx ring 18: qid=18 cur=0 queued=0 <br /> tx ring 19: qid=19 cur=0 queued=0 <br /> rx ring: cur=11</li>
</ol>
<p>I just load 'iwn5000fw_load="YES"' over loader.conf, because the other modules (if_iwn.ko, wlan_ccmp.ko, wlan_tkip.ko) are loaded by the generic kernel. This is what I've loaded, too:</p>
<ol>
<li>kldstat ###<br />Id Refs Address Size Name<br /> 1 28 0xffffffff80200000 15a8710 kernel<br /> 2 1 0xffffffff817a9000 13020 snd_hda.ko<br /> 3 2 0xffffffff817bd000 31bf8 sound.ko<br /> 4 3 0xffffffff817ef000 bf758 acpi.ko<br /> 5 1 0xffffffff818af000 c7a0 ehci.ko<br /> 6 2 0xffffffff818bc000 f4c0 dm.ko<br /> 7 1 0xffffffff818cc000 1c4f8 dm_target_crypt.ko<br /> 8 4 0xffffffff827e9000 58d0 libiconv.ko<br /> 9 1 0xffffffff827ef000 20c8 libmchain.ko<br />10 1 0xffffffff827f2000 f98 msdos_iconv.ko<br />11 1 0xffffffff827f3000 f88 ntfs_iconv.ko<br />12 2 0xffffffff827f4000 10a38 ntfs.ko<br />13 1 0xffffffff82805000 fd0 cd9660_iconv.ko<br />14 1 0xffffffff82806000 5928 acpi_video.ko<br />15 1 0xffffffff8280c000 70c48 drm.ko<br />16 2 0xffffffff8287d000 2ec8 iicbus.ko<br />17 1 0xffffffff82880000 53fc8 iwn5000fw.ko<br />18 1 0xffffffff828d4000 1da8 coretemp.ko<br />19 1 0xffffffff828d6000 68d0 acpi_thinkpad.ko<br />20 1 0xffffffff828dd000 3dd0 est.ko<br />21 1 0xffffffff83042000 35000 pf.ko</li>
</ol>
<ol>
<li>rc.conf (relevant entries) ###<br />wlans_iwn0="wlan0" <br />ipv6_enable="YES" <br />ipv6_network_interfaces="wlan0" <br />ifconfig_wlan0="up DHCP WPA mode 11a"</li>
</ol>
<ol>
<li>wpa_supplicant.conf ###<br />ctrl_interface=/var/run/wpa_supplicant<br />eapol_version=2<br />network={<br /> ssid="my SSID name" <br /> priority=145<br />#scan_ssid=1<br /> proto=RSN<br /> key_mgmt=WPA-PSK <br /> pairwise=CCMP<br /> group=CCMP<br /> psk="my secure passphrase" <br />}</li>
</ol>
<ol>
<li>sysctl.conf (relevant entries) ###<br />net.inet6.ip6.use_tempaddr=1<br />net.inet6.icmp6.nodeinfo=0<br />net.inet6.icmp6.rediraccept=0</li>
</ol>
<p>In IRC at #dragonflybsd on EFNet <a class="user active user-mention" href="https://bugs.dragonflybsd.org/users/556">@profmakx</a> wrote: "I have iwn4965 and iwn6000, both work".</p>
<p>I've just tested (just for fun) to replace all that modules (if_iwn.ko, wlan_ccmp.ko, wlan_tkip.ko, iwn5000fw.ko) one by one and all together with the older one from v3.6.2. The result was exactly the same error.</p>
<p>I've found a FreeBSD issue with parallels:<br /><a class="external" href="http://www.marshut.com/sinuy/iwn-firmware-sysassert.html">http://www.marshut.com/sinuy/iwn-firmware-sysassert.html</a></p>
<p>Thanks in advance for any help!</p> DragonFlyBSD - Bug #2552 (New): hammer recovery should indicate progresshttps://bugs.dragonflybsd.org/issues/25522013-05-01T02:44:36Zphma
<p>I'm running hammer recover on a 55 GB partition of an IDE drive and it's been running for about a day. I have no idea how long it'll take. It would be a good idea if, every few minutes, hammer recover would output how many blocks it's read and how many are left, or just a percentage.</p> DragonFlyBSD - Bug #2529 (New): Sundance network adapter is not detected and attachedhttps://bugs.dragonflybsd.org/issues/25292013-03-21T14:13:29Zkworrc.kworr@gmail.com
<p>I have one of those ASUS NX1001 cards with Sundance controller. Current version doesn't correctly detects it.</p>
<p>pciconf -lv (snip):<br />none6@pci0:2:6:0: class=0x020000 card=0x82131043 chip=0x020013f0 rev=0x31 hdr=0x00<br /> vendor = 'Sundance Technology Inc / IC Plus Corp'<br /> device = 'IC Plus IP100A Integrated 10/100 Ethernet MAC + PHY'<br /> class = network<br /> subclass = ethernet</p>
<p>In current FreeBSD (RELENG_9) it is detected as:</p>
<p>ste0: <Sundance ST201 10/100BaseTX> port 0xd100-0xd17f mem 0xfe920000-0xfe9201ff irq 20 at device 6.0 on pci2<br />ste0: Ethernet address: 00:26:18:eb:37:85<br />miibus1: <MII bus> on ste0<br />ukphy0: <Generic IEEE 802.3u media interface> PHY 0 on miibus1<br />ukphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto</p> DragonFlyBSD - Bug #2252 (New): snd_hda not useable if loaded via /boot/loader.confhttps://bugs.dragonflybsd.org/issues/22522011-12-05T19:58:43Zxbit
<p>When loading snd_hda from /boot/loader.conf it is loaded, but cannot be used and configured. At least audio/moc does not work, it is unable to use the OSS interface. But after unloading and loading snd_hda again the sound card is useable.</p>
<p>As a workaround I added "/sbin/kldload snd_hda" to /etc/rc.local and then the soundcard is useable form audio/moc as OSS device.</p>
<p>snd_hda was the only sound kernel module that has been loaded via /boot/loader.conf.</p>
<p>Kernel configuration is GENERIC x86_64 (v2.12.0.23.gec4cf).</p> DragonFlyBSD - Bug #2020 (New): Port brcm80211 driver from Linux to DragonFly BSDhttps://bugs.dragonflybsd.org/issues/20202011-03-06T06:54:10Zstuder
<p>In September 2010, Broadcom released a full opensource version under BSD licence <br />of their driver for part of their WLAN hardware (BCM43224, BCM43225, BCM4313 <br />(PCIe NIC)).</p>
<p>That would be so nice if this could be added to DragonFly BSD.</p>
<p>For more information, see :<br />- <a class="external" href="http://thread.gmane.org/gmane.linux.kernel.wireless.general/55418">http://thread.gmane.org/gmane.linux.kernel.wireless.general/55418</a><br />- <a class="external" href="http://wireless.kernel.org/en/users/Drivers/brcm80211">http://wireless.kernel.org/en/users/Drivers/brcm80211</a></p> DragonFlyBSD - Bug #1982 (New): There is no linuxulator on x86-64https://bugs.dragonflybsd.org/issues/19822011-02-04T21:53:04Zherrgard
<p>The linuxulator would have to be ported from x86.</p> DragonFlyBSD - Bug #1532 (New): jemalloc doesn't work on DragonFlyhttps://bugs.dragonflybsd.org/issues/15322009-09-25T19:10:21Zhasso
<p>jemalloc is a malloc(3) implementation from FreeBSD and for some reason <br />increasingly popular in various software pieces dealing ECMAscript and related <br />stuff. This means browsers (Firefox, Chrome), but also Gnash for example. <br />Unfortunately jemalloc doesn't work with DragonFly. Matt explained why some <br />time ago:</p>
<p><a class="external" href="http://leaf.dragonflybsd.org/mailarchive/users/2009-04/msg00162.html">http://leaf.dragonflybsd.org/mailarchive/users/2009-04/msg00162.html</a></p> DragonFlyBSD - Bug #1313 (New): Signal code in kernel needs major overhaul (signal queues, si_cod...https://bugs.dragonflybsd.org/issues/13132009-03-13T15:04:10Zhasso
<p>Although our siginfo structure has a si_code member, we don't use it and <br />don't even have a defines related to it.</p>
<p><a class="external" href="http://www.opengroup.org/onlinepubs/009695399/basedefs/signal.h.html">http://www.opengroup.org/onlinepubs/009695399/basedefs/signal.h.html</a></p> DragonFlyBSD - Bug #679 (New): Netgraph backward compatibility for old *LEN constantshttps://bugs.dragonflybsd.org/issues/6792007-06-05T07:56:01Znant
<p>Maintain the old *LEN netgraph constants around for some time to allow<br />the building of earlier mpd (Multi-link PPP Daemon).</p>
<p>Pointed out by: Alexander Motin <<a class="email" href="mailto:mav@freebsd.org">mav@freebsd.org</a>><br />Obtained from: FreeBSD</p>
<p>BTW: Do we need a BURN_BRIDGES kernel option?</p>
<p>Thanks,<br />Nuno</p> DragonFlyBSD - Bug #600 (New): /sys/libkern/karc4randomhttps://bugs.dragonflybsd.org/issues/6002007-04-11T17:14:04Zrobin_carey5
<p>What is the point of keeping/using the in-kernel arc4<br />random number generator when you already have a very<br />good/superior IBAA/L15 random number generator.</p>
<p>If you need a u_int32_t quantity then simply add a<br />function to /sys/kern/kern_nrandom.c to produce a<br />u_int32_t.</p>
<p>--</p>
<p>Some issues with /sys/libkern/karc4random.c :</p>
<p>(a) If you intend to keep /sys/libkern/karc4random.c I<br />recommend you make a modification to it to improve<br />performance: Every time the karc4_random() function is<br />called it calls getmicrotime(), to check the time, and<br />it also checks the number of runs made, to see if it<br />should reseed itself. You can make a big performance<br />improvement by removing this call to getmicrotime()<br />and instead simply checking the number of runs to<br />determine when it should reseed itself.</p>
<p>(b) The karc4random.c file uses u_int8_t types for<br />arc4_i, arc4_j and arc4_t so there is no need for the<br />% 256 operation - another performance improvement.</p>
<p>(c) In arc4_init() you are throwing away 256*4 bytes<br />of output, when you only need to throw away the first<br />256 bytes of output.</p>
<p>Sincerely,<br />R Carey.</p>
<pre><code>_<em><i></em></i>__<em>_</em>_______________________________________________<br />Yahoo! Answers - Got a question? Someone out there knows the answer. Try it<br />now.<br /><a class="external" href="http://uk.answers.yahoo.com/">http://uk.answers.yahoo.com/</a></code></pre>