DragonFlyBSD bugtracker: Issueshttps://bugs.dragonflybsd.org/https://bugs.dragonflybsd.org/favicon.ico?16293952082022-01-30T10:33:08ZDragonFlyBSD bugtracker
Redmine DragonFlyBSD - Bug #3311 (New): TrueCrypt support may cause kernel crashhttps://bugs.dragonflybsd.org/issues/33112022-01-30T10:33:08Zarcade@b1t.namearcade@b1t.name
<p>When working on tcplay:hammer2 device kernel can crash. Screenshots attached...</p> 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 #3132 (New): unifdef minedhttps://bugs.dragonflybsd.org/issues/31322018-04-27T03:34:07Zbcallah
<p>Hi --</p>
<p>The included diff unifdefs the code in bin/mined. The #ifdef'd out paths probably would not even compile with the current #includes anyway.<br />No binary change. I have been running this on OpenBSD/amd64 and OpenBSD/armv7 for a while now. The DragonFly build is also happy with this.</p> DragonFlyBSD - Bug #3024 (New): sys/dev/netif/wi/if_wi.c:1090]: (style) Redundant conditionhttps://bugs.dragonflybsd.org/issues/30242017-04-11T18:56:08Zdcb
<p>sys/dev/netif/wi/if_wi.c:1090]: (style) Redundant condition: params. '!params || (params && params.ibp_flags&IEEE80211_BPF_CRYPTO)' is equivalent to '!params || params.ibp_flags&IEEE80211_BPF_CRYPTO'</p>
<p>Source code is</p>
<pre><code>if ((wh->i_fc[1] & IEEE80211_FC1_PROTECTED) &&<br /> (!params || (params && (params->ibp_flags & IEEE80211_BPF_CRYPTO)))) {</code></pre> DragonFlyBSD - Bug #2882 (New): bridge sends packets from individual interfaceshttps://bugs.dragonflybsd.org/issues/28822016-01-09T20:43:59Zarcade@b1t.namearcade@b1t.name
<p>Hi, recently tried configuring a bridge/stp alongside freebsd host with bridge. Looks like DragonFly version has some bugs in it... Dunno whether they are serious one or not. From time to time it loses connectivity and falls back to "blocking". Much more frequently following situation occurs:</p>
<p>FreeBSD (net.link.bridge.log_stp=1):</p>
<p>Jan 9 22:08:45 limbo kernel: arp: 172.29.1.195 moved from b6:02:35:28:d0:b1 to d4:3d:7e:48:ab:9d on bridge0<br />Jan 9 22:28:41 limbo kernel: arp: 172.29.1.195 moved from b6:02:35:28:d0:b1 to d4:3d:7e:48:ab:9d on bridge0</p>
<p>DragonFly (net.link.bridge.debug=1):</p>
<p>Jan 9 22:07:36 probe kernel: ff:ff:ff:ff:ff:ff 02:3b:77:1f:48:00 type 0608 lla b6:02:35:28:d0:b1<br />Jan 9 22:07:36 probe kernel: 02:3b:77:1f:48:00 52:54:00:12:34:56 type 0608 lla b6:02:35:28:d0:b1<br />Jan 9 22:08:45 probe kernel: ff:ff:ff:ff:ff:ff 02:3b:77:1f:48:00 type 0608 lla b6:02:35:28:d0:b1<br />Jan 9 22:10:40 probe kernel: ff:ff:ff:ff:ff:ff 02:3b:77:1f:48:00 type 0608 lla b6:02:35:28:d0:b1<br />Jan 9 22:12:13 probe kernel: ff:ff:ff:ff:ff:ff 94:eb:cd:2d:05:5f type 0608 lla b6:02:35:28:d0:b1<br />Jan 9 22:12:13 probe kernel: ff:ff:ff:ff:ff:ff 94:eb:cd:2d:05:5f type 0608 lla b6:02:35:28:d0:b1<br />Jan 9 22:25:43 probe kernel: ff:ff:ff:ff:ff:ff 84:8e:df:11:d2:e2 type 0608 lla b6:02:35:28:d0:b1<br />Jan 9 22:25:44 probe kernel: ff:ff:ff:ff:ff:ff 84:8e:df:11:d2:e2 type 0608 lla b6:02:35:28:d0:b1<br />Jan 9 22:27:11 probe kernel: ff:ff:ff:ff:ff:ff 94:eb:cd:2d:05:5f type 0608 lla b6:02:35:28:d0:b1<br />Jan 9 22:27:11 probe kernel: ff:ff:ff:ff:ff:ff 94:eb:cd:2d:05:5f type 0608 lla b6:02:35:28:d0:b1<br />Jan 9 22:27:32 probe kernel: ff:ff:ff:ff:ff:ff 02:3b:77:1f:48:00 type 0608 lla b6:02:35:28:d0:b1<br />Jan 9 22:27:32 probe kernel: 02:3b:77:1f:48:00 52:54:00:12:34:56 type 0608 lla b6:02:35:28:d0:b1<br />Jan 9 22:28:41 probe kernel: ff:ff:ff:ff:ff:ff 02:3b:77:1f:48:00 type 0608 lla b6:02:35:28:d0:b1</p>
<p>re0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500<br /> options=19<RXCSUM,VLAN_MTU,VLAN_HWTAGGING><br /> inet6 fe80::d63d:7eff:fe48:ab9d%re0 prefixlen 64 scopeid 0x1<br /> ether d4:3d:7e:48:ab:9d<br /> media: Ethernet autoselect (1000baseT <full-duplex>)<br /> status: active</p>
<p>bridge0: flags=8043<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500<br /> inet6 fe80::b402:35ff:fe28:d0b1%bridge0 prefixlen 64 scopeid 0x3<br /> inet 172.29.1.195 netmask 0xffffff00 broadcast 172.29.1.255<br /> ether b6:02:35:28:d0:b1<br /> priority 32768 hellotime 2 fwddelay 15 maxage 20<br /> member: tap0 flags=3<LEARNING,DISCOVER><br /> member: re0 flags=37<LEARNING,DISCOVER,STP,DESIGNATED,ROOT><br /> port 1 priority 128 pathcost 55 forwarding<br /> bondweight 1<br /> designated root: 8000b6023528d0b1<br /> designated bridge: 8000b6023528d0b1<br /> designated cost: 54<br /> designated port: 0</p>
<p>There's no hints on how bridge should be set up also. The recipe that works for me flawlessly is:</p>
<p>1. Clone one bridge interface:<br /> cloned_interfaces=bridge0</p>
<p>1. Bring child interfaces up:<br /> ifconfig_re0=up</p>
<p>2. Set up inet on the bridge in first configuration directive:<br /> ifconfig_bridge0=DHCP<br />or:<br /> ifconfig_bridge0='inet 172.29.1.100/24'</p>
<p>3. Add other interfaces:<br /> ifconfig_bridge0_alias0='addm re0 stp re0'</p>
<p>Just to pinpoint - FreeBSD guide page is fine about bridges except that DHCP will not work in aliases.</p> DragonFlyBSD - Bug #2878 (New): [fix] CCVER problem when using clang and cpu extensions (intrinsics)https://bugs.dragonflybsd.org/issues/28782015-12-30T20:46:33Zarcade@b1t.namearcade@b1t.name
<p>Ok, I'm trying to compile dri with clang37. When I setting CCVER to clang37 build stops on:</p>
<p>In file included from utils.c:37:<br />In file included from ../../../../../src/mesa/main/macros.h:36:<br />../../../../../src/util/rounding.h:33:10: fatal error: 'xmmintrin.h' file not found<br />include <xmmintrin.h><br /> ^<br /> 2 warnings and 1 error generated.</p>
<p>The file is present, but as per /etc/defaults/compiler.conf:</p>
<p>STD_INCOPT="-nostdinc -iprefix ${INCPREFIX} -iwithprefixbefore /usr/include" <br />DPORT_GCC_STD_INCOPTXX="-isystem /usr/local/lib/${CCVER}/include/c++ \<br /> -isystem /usr/local/lib/${CCVER}/include/c++/${MACHARCH}-portbld-dragonfly${MACHREL}" <br />DPORT_CLANG_STD_INCOPTXX="-cxx-isystem /usr/include/c++/5.0"</p>
<p>...</p>
<p>clang37_INCOPT=${STD_INCOPT}<br />clang37_INCOPTCXX=${DPORT_CLANG_STD_INCOPTXX}</p> DragonFlyBSD - Bug #2877 (New): sed fails when working with UTF-8 locale and non-UTF symbolshttps://bugs.dragonflybsd.org/issues/28772015-12-30T19:20:47Zarcade@b1t.namearcade@b1t.name
<p>I.e. when some file has a line with upper ASCII symbols:</p>
<ul>
<li>and L<E1>szl<F3> N<E9>meth (Hunspell). Portions created by the Initial Developers</li>
</ul>
<p>and LANG is set to *.UTF8 running sed on that file results in:</p>
<p>+ /usr/bin/sed -i.bak -e 's|%%LOCALBASE%%|/usr/local|g' /tmp/ports/www/firefox/firefox-43.0.1/extensions/spellcheck/hunspell/glue/mozHunspell.cpp<br />sed: RE error: Illegal byte sequence</p>
<p>Unsetting lang makes sed silently accept the file.</p> DragonFlyBSD - Bug #2797 (In Progress): vkernels with & without machdep.pmap_mmu_optimizehttps://bugs.dragonflybsd.org/issues/27972015-02-28T00:09:38Zyellowrabbit2010
<p>Hello,</p>
<p>I tried vkernel64 according to vkernel(7) with & without machdep.pmap_mmu_optimize.</p>
<p>With machdep.pmap_mmu_optimize=0 vkernel boots with many <br /><code>ept_copyout: could not fault in vm map, gpa: 804928000</code> (addresses are changing)</p>
<p>With machdep.pmap_mmu_optimize=1 box paniced (no dump, keyboard hangs --- I can't type anything)<br /><pre>
panic: assertion "origpte == 0 || (origpte & pmap->pmap_bit[PG_MANAGED_IDX])
failed in pmap_enter at /usr/src/sys/platform/pc64/x86_64/pmap.c:4122
trace beginning at frame
panic() at panic+0x21f
panic() at panic+0x21f
pmap_enter() at pmap_enter+0x297
vm_fault() at vm_fault+0x5ab
vmx_vmrun() at vmx_vm_run+0xebe
vmx_vmrun() at vmx_vm_run+0x1f
CPU0 stopping CPUs: 0x0000000e
Stopped
Stopped at Debugger+0x38: movb $0,0x125d681(%rip)
db> panic: kqueue: checkloop failed i=0
cpuid = 0
</pre></p>
<p>===================<br /><code>DragonFly fly.home.net 4.1-DEVELOPMENT DragonFly v4.1.0.876.g2deaaa-DEVELOPMENT</code></p>
<p>===================<br /><pre>
CPU: Intel(R) Core(TM) i5-3570 CPU @ 3.40GHz (3400.03-MHz K8-class CPU)
Origin = "GenuineIntel" Id = 0x306a9 Stepping = 9
Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
Features2=0x77bae3ff<SSE3,PCLMULQDQ,DTES64,MON,DS_CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,TSCDLT,AESNI,XSAVE,AVX,F16C,RDRND>
AMD Features=0x28100800<SYSCALL,NX,RDTSCP,LM>
AMD Features2=0x1<LAHF>
Structured Extended Features=0x281<GSFSBASE,SMEP,ENHMOVSB>
Thermal and PM Features=0x77<SENSOR,TURBO,ARAT,PLN,ECMD,PTM>
MONITOR/MWAIT Features=0x3<CST,INTBRK>
real memory = 7995148288 (7624 MB)
avail memory = 7503593472 (7155 MB)
</pre></p> DragonFlyBSD - Submit #2790 (New): filedesc softrefs increment code factoringhttps://bugs.dragonflybsd.org/issues/27902015-02-21T12:00:29Zdclinkdevnexen@gmail.com
<p>Just putting locking + sifters field update in common function ...</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 #2631 (In Progress): Verify library versioning current with full package build...https://bugs.dragonflybsd.org/issues/26312014-02-13T21:46:57Ztuxillo
<p>Verify library versioning current with full package build and switch it on (after publishing packages)</p>
<p>most libraries complete and working now. libc/pthreads could be an issue.</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 #2403 (New): newfs -E doesn't handle /dev/serno device names properlyhttps://bugs.dragonflybsd.org/issues/24032012-08-17T12:07:45Zftigeot
<p>Trying to run this command fails:</p>
<pre><code>newfs_hammer -E -L USR_OBJ /dev/serno/00000000112233445566</code></pre>
<pre><code>Device:/dev/serno/00000000112233445566 (kern.cam.da.rno/00000000112233445566.trim_enabled) does not support the TRIM command<br /> usage: newfs_hammer -L label [-Ef] [-b bootsize] [-m savesize] [-u undosize]<br /> [-V version] special ...</code></pre>
<p>The only trim_enabled sysctls id are of the form<br /> kern.cam.da.0.trim_enabled<br /> kern.cam.da.1.trim_enabled<br /> kern.cam.da.2.trim_enabled<br /> etc...</p>
<p>It seems newfs -E only expects drive names to be of the form /dev/daX<br />TRIM options in other utilities such as fdisk or disklabel may have the same issue</p> DragonFlyBSD - Bug #285 (Feedback): interrupt latency with re without ip address configuredhttps://bugs.dragonflybsd.org/issues/2852006-08-07T06:00:07Zthomas.nikolajsen
<p>Playing sound using pcm(4)/snd(4) gives bad quality: hiss and hops, like sound isn't playing for very short time periods.</p>
<p>This is experienced:<br /> - not having SMP in kernel config (eg GENERIC)<br /> - from dfly-1.5 26th December '05 (24th is ok using kernels from chlamydia);<br />including HEAD.</p>
<p>dfly-1.4 is ok, including 1.4.4.</p>
<p>Using audio/mpg123 for MP3, 'cp test.raw /dev/dspW' or pcmplay for decoded sound.<br />Buffering audio data with mpg123 -b doesn't sound like making any difference.</p>
<p>CPU load doesn't sound like making any difference.<br />Problem experienced on several systems, using snd_via8233 and snd_ich.</p>
<p>No X11 used.</p>
<pre><code>-thomas</code></pre>