DragonFlyBSD bugtracker: Issueshttps://bugs.dragonflybsd.org/https://bugs.dragonflybsd.org/favicon.ico?16293952082023-12-05T04:09:21ZDragonFlyBSD bugtracker
Redmine DragonFlyBSD - Submit #3362 (New): Reduce package dependencies of sysutils/cdrtools in branch wit...https://bugs.dragonflybsd.org/issues/33622023-12-05T04:09:21Zmneumann
<p>Git branch withpkg.</p>
<p>Build `sysutils/cdrtools` without options DOCS, LAME and VORBIS. This should get rid of various dependent packages in `dports.base`.<br />We only need cdrtools for mkisofs, not for burning audio cds...</p> DragonFlyBSD - Bug #3323 (New): virtio (if_vtnet...) not detected on Hetzner cloud (AMD system)https://bugs.dragonflybsd.org/issues/33232022-08-08T19:15:54Zmneumann
<p>`pciconf -lv` lists a "Virtio network device"</p>
<p><img src="https://bugs.dragonflybsd.org/attachments/download/1724/clipboard-202208082105-nspru.png" alt="" loading="lazy" /></p>
<p>But it does not show up under `ifconfig`. Also the virtio SCSI harddisk is not detected.</p>
<p>Just curious if I am doing anything wrong.</p> DragonFlyBSD - Bug #3317 (In Progress): Network vtnet0 not working on Hetzner cloudhttps://bugs.dragonflybsd.org/issues/33172022-06-09T15:14:35Zmneumann
<p>After running `dhclient vtnet0`, I cannot ping anything except the default gateway (172.31.1.1).</p>
<p>`route show` shows two entries for the default route (172.31.1.1) and<br />one contains <strong>very</strong> strange characters:</p>
<p><img src="https://bugs.dragonflybsd.org/attachments/download/1716/clipboard-202206091711-dw2gp.png" title="Screenshot" alt="Screenshot" loading="lazy" /></p>
<p>(See the second line for 172.31.1.1...)</p> DragonFlyBSD - Bug #3235 (New): Kernel panic in devfs_vnops.chttps://bugs.dragonflybsd.org/issues/32352020-04-28T13:58:19Zmneumann
<p>I got this panic after installing DragonFly on an encrypted device, when I unmounted the file systems.</p>
<p>Installer and kernel was from most recent master.</p> DragonFlyBSD - Bug #3234 (Resolved): pthread - Respect RLIMIT_STACK for main threadhttps://bugs.dragonflybsd.org/issues/32342020-04-25T11:44:20Zmneumann
<p>The stack size of the main thread when pthread is used is limited to 4 MB (hard coded value).<br />This breaks, for example, the crystal compiler (<a class="external" href="http://www.crystal-lang.org">www.crystal-lang.org</a>).</p>
<p>The stack size of a process not using pthread is limited by RLIMIT_STACK. As soon as pthread is linked in,<br />the main thread's stack size is limited to 4 MB.</p>
<p>FreeBSD uses two environment variables LIBPTHREAD_BIGSTACK_MAIN and<br />LIBPTHREAD_SPLITSTACK_MAIN to control use of RLIMIT_STACK vs. the hard-coded<br />4MB and defaults to respect RLIMIT_STACK when none is specified.</p>
<p>This patch</p>
<p><a class="external" href="https://leaf.dragonflybsd.org/~mneumann/patch-libthread_xu.diff">https://leaf.dragonflybsd.org/~mneumann/patch-libthread_xu.diff</a></p>
<p>fixes the issue. Crystal compiles.</p> DragonFlyBSD - Bug #3233 (Resolved): LLVM does not ship with stdatomic and libatomichttps://bugs.dragonflybsd.org/issues/32332020-04-16T18:19:00Zmneumann
<p>Compilation of</p>
<pre><code>#include &lt;stdatomic.h&gt;<br /> int main(int argc, char **argv) {}</code></pre>
<p>fails when compiled with clang. Works on gcc. Note that LLVM/clang will also<br />link against -latomic is some cases (-mcx16 ?), despite using opcodes instead of<br />library calls to libatomic (e.g. __atomic_compare_exchange_16). So, having a libatomic.a<br />would help too (even an empty one).</p> DragonFlyBSD - Bug #3222 (New): gcc - undefined reference to '__atomic_load' (missing libatomic?)https://bugs.dragonflybsd.org/issues/32222020-02-08T10:45:36Zmneumann
<p>I can't compile the following C11 program:</p>
<p>// atomic_test.c<br />#include <stdio.h><br />#include <complex.h><br />#include <stdatomic.h></p>
<p>int main(void)
{<br /> _Atomic long double _Complex x; <br /> printf("(%Lf,%Lf)\n",creall(x), cimagl(x));<br /> return 0;<br />}</p>
<blockquote>
<p>cc -std=c11 atomic_test.c</p>
</blockquote>
<p>/tmp//ccTm73vw.o:atomic_test.c:function main: error: undefined reference to '__atomic_load'<br />/tmp//ccTm73vw.o:atomic_test.c:function main: error: undefined reference to '__atomic_load'<br />collect2: error: ld returned 1 exit status</p>
<p>On my Linux system, I can link in -latomic:</p>
<blockquote>
<p>cc -std=c11 atomic_test.c -latomic</p>
</blockquote>
<p>But it seems this got removed from DragonFly's gcc8. I try to compile the Pony compiler ponyc,<br />which requires these atomic ops.</p> DragonFlyBSD - Bug #3207 (Resolved): swapon fails silently when trim option is givenhttps://bugs.dragonflybsd.org/issues/32072019-09-21T08:39:34Zmneumann
<p>In /etc/fstab I have the following line:</p>
<p>/dev/serno/xxx.s1b none swap sw,crypt,trim 0 0</p>
<p>When I startup, "swapctl -l" does not list any devices.<br />If I remove the "trim" option above, it works and "swapctl -l" <br />shows the configured device.</p>
<p>The disk is a Samsung SSD 960 PRO using the nvme driver.</p>
<p>Having no swap configured silently might not be the best option.</p> DragonFlyBSD - Bug #3202 (Resolved): Cannot boot from HAMMER2https://bugs.dragonflybsd.org/issues/32022019-08-30T11:46:54Zmneumann
<p>Booting from HAMMER2 "BOOT" PFS works when created via "newfs_hammer2 -L BOOT".</p>
<p>But when I use "hammer2 pfs-create BOOT", I got the message "hammer2: 'BOOT' PFS not found".<br />I might have created and deleted the "BOOT" PFS multiple times on that file system.</p>
<p>My BOOT PFS inode number is "0xd9b36ce135528001", but HAMMER2_BOOT_KEY is defined as "0xd9b36ce135528000".<br />With the following patch I can successfully boot from HAMMER2:</p>
<p>--- a/lib/libstand/hammer2.c<br />+<ins>+ b/lib/libstand/hammer2.c<br /><code>@ -692,7 +692,7 </code>@ h2init(struct hammer2_fs *hfs)<br /> return(<del>1);<br /> h2lookup(hfs, NULL, 0, 0, NULL, NULL);<br /> r = h2lookup(hfs, &hfs</del>>sroot,<br />- HAMMER2_BOOT_KEY, HAMMER2_BOOT_KEY,<br /></ins> HAMMER2_BOOT_KEY, HAMMER2_BOOT_KEY | 0xFFFFU,<br /> &hfs->sroot, &data);<br /> if (r <= 0) {<br /> printf("hammer2: 'BOOT' PFS not found\n");</p>
<p>I am not sure if this is 100% the right approach.<br />I would rather like to check for the name explicitly as there can be hash collisions.</p>
<p>To successfully boot from HAMMER2, I have to "set currdev="disk0s1d" and then <br />"cd /kernel" and then follow normal boot procedure (loadall, boot).</p>
<p>To really be useful, one would have to allow other PFSes than "BOOT" to be booted from,<br />so that you can boot from a snapshot for instance.</p> DragonFlyBSD - Bug #3167 (Resolved): UEFI boot hangs right after initializing UEFI framebufferhttps://bugs.dragonflybsd.org/issues/31672019-01-09T20:17:26Zmneumann
<p>This happens on a recent Tuxedo laptop. See attached screenshot.</p>
<p>I have come up with a working (but hacky) patch:</p>
<p><a class="external" href="https://www.dragonflybsd.org/~mneumann/patch-fb-machdep.c">https://www.dragonflybsd.org/~mneumann/patch-fb-machdep.c</a></p>
<p>After patching, if I set loader tunable sc.probe_early=1 then it correctly boots.</p> DragonFlyBSD - Bug #3111 (In Progress): Mouse lags every second heavily under X11https://bugs.dragonflybsd.org/issues/31112017-12-10T17:30:40Zmneumann
<p>Mouse moves normal for one second, then completely stops for roughly one second, then moves again for a second.<br />The whole repeats infinitivly.</p>
<p>This commit has <strong>no</strong> mouse lag: e0a1e7abb95f53e4b0c633f57fbd3ba163a98e73<br />This commit has mouse lag: d6c92fb146a95bd38feaa94c8d2bafda63600e8e</p>
<p>I first assumed it is either one of the commits related to evdev support, so I reverted them:</p>
<pre><code>d3d1dd3e4513b2ab753f8ba52f144dc916420ba6<br /> 3ea800bb832ad69c10f85ce9bce98efd8e892285<br /> eaf0d054af4aa304548c1efc497aad966b86a590</code></pre>
<p>But the mouse lag still happens. Next I reverted the recent drm/radeon commit:</p>
<pre><code>d235ee5f3490f63ba738915974154a0e2e49378d</code></pre>
<p>But mouse lag still there. So I assume it must be one of dillon's commits on 5th or 6th December.</p>
<p>Anyone else seeing the problem? I can easily bisect the problem, as it's only 6 commits. But maybe dillon can see the problem faster.</p> DragonFlyBSD - Bug #3087 (Resolved): Acer TravelMate Spin B hangs in TSC testing synchronization..https://bugs.dragonflybsd.org/issues/30872017-10-21T12:33:47Zmneumann
<p>I am running DragonFly 5.0.0-RELEASE on an Acer TravelMate Spin B (Intel N3450 @ 1.10 GHz) laptop.</p>
<p>When booting, it shows:</p>
<pre><code>TSC invariant clock: 1094436275 Hz<br /> ....<br /> lapic: TSC Deadline Mode: shift 0, frequency 1094436275 Hz<br /> srat_probe: can't locate SRAT<br /> Initialize MI interrupts<br /> TSC testing synchronization ...</code></pre>
<p>and then it loops/hangs forever. Any help appreciated.</p> DragonFlyBSD - Bug #2972 (New): ipfw3 "deny to me" does not work correctlyhttps://bugs.dragonflybsd.org/issues/29722016-12-27T20:11:06Zmneumann
<p>I am using ipfw3 with following rule:</p>
<p>ipfw3 add 1000 deny tcp to me dst-port 443</p>
<p>But it does not block incoming traffic. It works when I replace "me" with the IP address of the incoming interface.</p>
<p>I am running 4.7-DEVELOPMENT DragonFly 7f20f9e1c-DEVELOPMENT.</p>
<p>Also I noticed that there is some gap between the man page and the current implementation.</p> DragonFlyBSD - Bug #2881 (New): Pulseaudio hangs/resets system when starting X11https://bugs.dragonflybsd.org/issues/28812016-01-09T11:08:45Zmneumann
<p>When I start X, the last two messages I see on the console (via ssh):</p>
<p>Jan 9 11:33:05 babel kernel: info: [drm] Initialized radeon 2.40.0 20080528<br />Jan 9 11:33:07 babel pulseaudio<sup><a href="#fn1126">1126</a></sup>: [(null)] oss-util.c: '/dev/dsp0' doesn't support full duplex</p>
<p>Then it either hangs the system, or it immediatly crashes and reboots. When I disable snd_hda in the boot loader,<br />this obviously doesn't crash. Also, when I start X as root, it does not crash.</p>
<p>This is on:</p>
<p>DragonFly babel.localnet 4.5-DEVELOPMENT DragonFly v4.5.0.299.g1bc3e-DEVELOPMENT #0: Wed Jan 6 11:49:45 UTC 2016 <a class="email" href="mailto:root@pkgbox64.dragonflybsd.org">root@pkgbox64.dragonflybsd.org</a>:/usr/obj/usr/src/sys/X86_64_GENERIC x86_64</p>
<p>People on IRC tell me it's a know issue with pulseaudio. I think we should add a big message is dports pkg-message that pulseaudio is dangerous.</p> DragonFlyBSD - Bug #2788 (New): ioctl GSLICEINFO: Not working for vnode slicehttps://bugs.dragonflybsd.org/issues/27882015-02-12T15:49:48Zmneumann
<p>Execution of "newfs_msdos /dev/vn0s2" results in the following error:</p>
<p>newfs_msdos: ioctl (GSLICEINFO): Inappropriate ioctl for device<br />newfs_msdos: /dev/vn0s2: can't get slice info</p>
<p>Complete example that fails:</p>
<p>truncate -s 1G disk<br />cat <<EOS | fdisk -p disk -B -f -<br />p 1 165 63 2080387<br />p 2 12 2000450 88000 <br />a 1<br />EOS</p>
<p>vnconfig vn0 disk<br />newfs_msdos /dev/vn0s2</p>
<p>When run on /dev/vn0, newfs_msdos works as expected.</p>