DragonFlyBSD bugtracker: Issueshttps://bugs.dragonflybsd.org/https://bugs.dragonflybsd.org/favicon.ico?16293952082022-09-13T17:38:34ZDragonFlyBSD bugtracker
Redmine DragonFlyBSD - Bug #3328 (Closed): rcenable will not add `_enable` prefixhttps://bugs.dragonflybsd.org/issues/33282022-09-13T17:38:34Zmneumann
<p>When I run</p>
<p>```<br />rcenable dhcpcd<br />```</p>
<p>I get the following line added to rc.conf:</p>
<p>dhcpcd="YES"</p>
<p>While I'd expect it to be:</p>
<p>dhcpcd_enable="YES"</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 #3309 (Closed): psm0 (Synaptics Touchpad) regularily freezes mouse for 2 secondshttps://bugs.dragonflybsd.org/issues/33092021-12-29T10:21:03Zmneumann
<ul>
<li>First note: Using an USB mouse exhibits none of the problems reported below!</li>
</ul>
<ul>
<li>moused is enabled (by default).</li>
</ul>
<ul>
<li>I am running from an USB stick with the DragonFly installer (nrelease + gui).</li>
</ul>
<ul>
<li>There are no interrupt storms. Low frequent "psm0: lost interrupt?" messages seem to be fine<br /> (they happen on FreeBSD too).</li>
</ul>
<ul>
<li>This happens repeatedly and roughly every 3-5 seconds (when moving the mouse).</li>
</ul>
<ul>
<li>This happens when running moused on the terminal (though less likely).</li>
</ul>
<ul>
<li>This happens with X11 (no matter of driver, i915 or scfb). /dev/sysmouse is used.</li>
</ul>
<ul>
<li>It is much more likely to happen when running X11.</li>
</ul>
<ul>
<li>It is less likely to happen on the console when psm debug output is enabled and the<br /> console is full of debug messages. Note that the debug output does not affect it from<br /> happending when running X11.</li>
</ul>
<ul>
<li>This does not happen on FreeBSD 13 [1].</li>
</ul>
<ul>
<li>[1] IIRC I could once reproduce this on FreeBSD, but as I switched between<br /> FreeBSD and DragonFly quite often, I am not 100% sure that this actually appeared on FreeBSD.</li>
</ul>
<ul>
<li>I reviewed the changes in the psm driver between<br /> FreeBSD and DragonFly and couldn't find anything that would explain this behaviour.</li>
</ul>
<ul>
<li>On FreeBSD, I disabled psm mux (hw.psm.mux_disabled=1), so that the code paths are mostly identical.<br /> It still works on FreeBSD!</li>
</ul>
<ul>
<li>I also synced the psm driver a bit, still no luck on DragonFly.</li>
</ul>
<ul>
<li>The 2 seconds "freeze" comes from this piece of code (around line 6554 in psm.c):
<p>/*
* Drop even good packets if they occur within a timeout
* period of a sync error. This allows the detection of
* a change in the mouse's packet mode without exposing
* erratic mouse behavior to the user. Some KVMs forget
* enhanced mouse modes during switch events.<br /> */<br /> if (!timeelapsed(&sc->lastinputerr, psmerrsecs, psmerrusecs,<br /> &now)) {<br /> pb->inputbytes = 0;<br /> continue;<br /> }</p></li>
</ul>
<ul>
<li>It's paired with these messages:
<p>psmintr: out of sync (0000 != 0080) 106 cmds since last error.<br /> psmintr: discard a byte (1)</p></li>
</ul>
<ul>
<li>Normally PSM packets looks like this:
<p>psmintr: 80 00 00 c0 00 00</p></li>
</ul>
<ul>
<li>But what I sometimes get are corrupted packets or variations of:
<p>psmintr: 00 80 00 00 c0 00<br /> ^^</p></li>
</ul>
<ul>
<li>Note that there are various reports of similar problems for FreeBSD (ages ago):
<p><a class="external" href="https://www.mail-archive.com/freebsd-current@freebsd.org/msg41898.html">https://www.mail-archive.com/freebsd-current@freebsd.org/msg41898.html</a><br /> <a class="external" href="https://freebsd-current.freebsd.narkive.com/sW2d54mP/kernel-psmintr-out-of-sync">https://freebsd-current.freebsd.narkive.com/sW2d54mP/kernel-psmintr-out-of-sync</a></p></li>
</ul>
<ul>
<li>My assumption is that this is somehow a timing problem. But I'd like to<br /> understand why this happens on DragonFly but not on FreeBSD.<br /> The psm code is so similar, except that FreeBSD uses splx locks whereas<br /> we use lockmgr. I found suggestions to turn of powerd etc... but they all come<br /> down to the fact that there are timing issues.</li>
</ul>
<ul>
<li>BTW, NetBSD has beautiful and highly understandable psm code (truely amazing)!<br /> I might want to try if psm works there.</li>
</ul>
<ul>
<li>Running recent DragonFly master (6.1-DEVELOPMENT), i7-8565U CPU @ 1.80GHz, TUXEDO InfinityBook Pro 14 v3 (Clevo "clone").</li>
</ul>
<ul>
<li>Below is my dmesg output for psm0 (just for the record):</li>
</ul>
<p>psm0: current command byte:0067<br />Synaptics Touchpad v8.2<br /> Model information:<br /> infoRot180: 0<br /> infoPortrait: 0<br /> infoSensor: 1<br /> infoHardware: 113<br /> infoNewAbs: 1<br /> capPen: 0<br /> infoSimplC: 1<br /> infoGeometry: 1<br /> Extended capabilities:<br /> capExtended: 1<br /> capMiddle: 0<br /> nExtendedQueries: 7<br /> capPassthrough: 0<br /> capLowPower: 0<br /> capMultiFingerReport: 1<br /> capSleep: 0<br /> capFourButtons: 0<br /> capBallistics: 0<br /> capMultiFinger: 1<br /> capPalmDetect: 1<br /> infoXupmm: 55<br /> infoYupmm: 102<br /> Extended model ID:<br /> verticalScroll: 0<br /> horizontalScroll: 0<br /> verticalWheel: 0<br /> nExtendedButtons: 0<br /> capEWmode: 1<br /> Continued capabilities:<br /> capClickPad: 0<br /> capDeluxeLEDs: 0<br /> noAbsoluteFilter: 0<br /> capReportsV: 1<br /> capUniformClickPad: 0<br /> capReportsMin: 1<br /> capInterTouch: 1<br /> capReportsMax: 1<br /> capClearPad: 0<br /> capAdvancedGestures: 0<br /> capCoveredPad: 0<br /> maximumXCoord: 5718<br /> maximumYCoord: 4908<br /> minimumXCoord: 1238<br /> minimumYCoord: 956<br /> Additional Buttons: 0<br />psm0: found Synaptics Touchpad<br />psm0: <PS/2 Mouse> irq 12 on atkbdc0<br />interrupt uses mplock: psm0<br />psm0: model Synaptics Touchpad, device ID 0-00, 3 buttons<br />psm0: config:00004000, flags:00000008, packet size:6<br />psm0: syncmask:c0, syncbits:00</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 #3070 (Closed): drm/radeon broken again since ee479021092456b32f018d8b9dc5d3e1...https://bugs.dragonflybsd.org/issues/30702017-10-06T22:24:00Zmneumann
<p>See <a class="external" href="http://bugs.dragonflybsd.org/issues/3031">http://bugs.dragonflybsd.org/issues/3031</a>. It was once broken. Then fixed by</p>
<p><a class="external" href="http://gitweb.dragonflybsd.org/dragonfly.git/commit/62dc643ef61b347c4c2e60ad9ea68dd766741c90">http://gitweb.dragonflybsd.org/dragonfly.git/commit/62dc643ef61b347c4c2e60ad9ea68dd766741c90</a> (and <a class="external" href="http://gitweb.dragonflybsd.org/dragonfly.git/commit/7d829069c0009b901fc3cac433685334a793947f">http://gitweb.dragonflybsd.org/dragonfly.git/commit/7d829069c0009b901fc3cac433685334a793947f</a>).</p>
<p>Since commit ee479021092456b32f018d8b9dc5d3e1f4fb9363, X hangs during startup (completely freezes, have to hard reset). I wonder if maybe commit 7d829069c0009b901fc3cac433685334a793947f was reverted too?</p> DragonFlyBSD - Bug #2976 (Resolved): Recent kernel no longer boots EFIhttps://bugs.dragonflybsd.org/issues/29762016-12-31T11:56:55Zmneumann
<p>The kernel as of commit 9294ae32a (Dec 28) works fine when booting with EFI. More recent kernels fail when switching to 80x25 (see screenshot). It just hangs there.</p>