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 #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 #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 #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 #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 #2763 (Resolved): pthread_mutex_destroy fails with error EINVAL(22) when run f...https://bugs.dragonflybsd.org/issues/27632015-01-08T10:43:32Zmneumann
<p>The following program when compiled with -pthread on DragonFly fails with assertion 22, while it works on Linux:</p>
<p>#include <assert.h><br />#include <pthread.h></p>
<p>int main() {<br /> pthread_mutex_t lock = PTHREAD_MUTEX_INITIALIZER;<br /> assert(pthread_mutex_destroy(&lock) == 0); // returns EINVAL (22)<br />}</p>
<p>While when it goes through a lock/unlock cycle or pthread_mutex_init() is called before,<br />the pthread_mutex_destroy() does not fail with EINVAL:</p>
<p>int main() {<br /> pthread_mutex_t lock = PTHREAD_MUTEX_INITIALIZER;<br /> pthread_mutex_init(&lock, NULL);<br /> assert(pthread_mutex_destroy(&lock) == 0); // OK<br />}</p>
<p>I propose the attached patch to return success if pthread_mutex_destroy() is called <br />for the PTHREAD_MUTEX_INITIALIZER case.</p> DragonFlyBSD - Bug #1333 (Closed): pkgsrc/lang/squeak fixeshttps://bugs.dragonflybsd.org/issues/13332009-04-13T18:11:56Zmneumann
<p>Hi,</p>
<p>Attached a diff to compile Squeak on DragonFly.</p>
<p>Regards,</p>
<pre><code>Michael</code></pre> DragonFlyBSD - Bug #1296 (Closed): vinum: drivename bug or manpage not in synchttps://bugs.dragonflybsd.org/issues/12962009-02-23T02:41:42Zmneumann
<p>"of" in the Subject should be "or" of course.</p> DragonFlyBSD - Bug #1295 (Closed): vinum: drivename bug or manpage not in synchttps://bugs.dragonflybsd.org/issues/12952009-02-23T02:07:30Zmneumann
<p>Hi,</p>
<p>Vinum only allows drives to be named like vinumdrive0 or vinumdrive1,<br />but the examples in the man page use custom names for drives lik:</p>
<pre><code>drive d1 device /dev/da2s0e</code></pre>
<p>If I try to execute this via "vinum create config.file", I'll get:</p>
<pre><code>1: drive d1 device /dev/mydev...<br />**1 : Invalid argument</code></pre>
<p>and it fails. So either the examples are out of sync or the<br />implementation has a bug.</p>
<p>Regards,</p>
<pre><code>Michael</code></pre> DragonFlyBSD - Bug #1224 (Closed): out-of-the box support for nsshttps://bugs.dragonflybsd.org/issues/12242009-01-10T23:33:00Zmneumann
<p>Hi,</p>
<p>When adding:</p>
<pre><code>CONFIGURE_ARGS+=--without-nss</code></pre>
<p>mail/dovecot will compile successfully.</p>
<p>Regards,</p>
<pre><code>Michael</code></pre> DragonFlyBSD - Bug #1191 (Closed): suser to priv conversion patchhttps://bugs.dragonflybsd.org/issues/11912008-12-30T02:29:01Zmneumann
<p>Hi,</p>
<p>I've attached a patch that replaces suser(9) with priv(9). Priv(9) is a<br />new API used by FreeBSD, and what it adds is fine-grained control over<br />which privelges are requested (and granted in turn).</p>
<p>So instead of</p>
<pre><code>suser(td)</code></pre>
<p>you write:</p>
<pre><code>priv_check(td, PRIV_ROOT);</code></pre>
<p>This will request ROOT privileges (which is equivalent to the suser()<br />call above). Of course PRIV_ROOT is not recommended and only serves<br />until all privileges are replaced by more fine grained privileges.</p>
<p>In sys/priv.h all existing privileges are defined.</p>
<p>The new API is as follows:</p>
<pre><code>int priv_check(struct thread *td, int priv);<br /> int priv_check_cred(struct ucred *cred, int priv, int flag);</code></pre>
<p>Old suser calls still work, but should be avoided and replaced by the<br />corresponding priv_* call.</p>
<p>The patch does not (yet) modify the way privileges are granted, i.e.<br />the implementation is identical to the corresponding suser_*() function.</p>
<p>If no one objects, I'd like to commit this soon to then concentrate on<br />introducing fine-grained privileges. If possible, I'd like to (later)<br />get rid of the flags argument of priv_check_cred() (or suser_cred()),<br />which can be either NULL_CRED_OKAY or PRISON_ROOT, but I've not yet<br />thought about it throrrowly enough.</p>
<p>Regards,</p>
<pre><code>Michael</code></pre> DragonFlyBSD - Bug #1050 (Closed): nfe0 ping and dhclient problemshttps://bugs.dragonflybsd.org/issues/10502008-07-06T23:58:01Zmneumann
<p>Hi,</p>
<p>I'm running -HEAD as of today and nfe0 doesn't seem to work 100%.</p>
<p>I can ping to another computer on the same network (directly connected<br />via a 100 MBit/s switch), but I can't ping the DragonFly box from the<br />other machine. Also, dhclient doesn't work on the DragonFly box!</p>
<p>I've also tried setting hw.nfe0.imtimer=-125 but that doesn't help<br />either.</p>
<p>Any hints?</p>
<p>Regards,</p>
<pre><code>Michael</code></pre> DragonFlyBSD - Bug #1018 (Closed): vnrlu_proc: vnode recycler stopped working!https://bugs.dragonflybsd.org/issues/10182008-05-24T16:50:05Zmneumann
<p>I'm getting the same problem as described in [1] with the most recent<br />head revision. I just tried to "cvs checkout" and then the message<br />appears repetitive and no further progress of cvs checkout seems to<br />happen.</p>
<p>Regards,</p>
<pre><code>Michael</code></pre>
<p>[1]: <a class="external" href="http://leaf.dragonflybsd.org/mailarchive/bugs/2004-12/msg00020.html">http://leaf.dragonflybsd.org/mailarchive/bugs/2004-12/msg00020.html</a></p> DragonFlyBSD - Bug #955 (Closed): lwkt_token_is_stale patchhttps://bugs.dragonflybsd.org/issues/9552008-02-29T21:03:05Zmneumann
<p>Hi,</p>
<p>Now that the release is over, is there any chance that the following <br />patch gets commited?</p>
<pre><code><a class="external" href="http://leaf.dragonflybsd.org/mailarchive/kernel/2008-02/msg00015.html">http://leaf.dragonflybsd.org/mailarchive/kernel/2008-02/msg00015.html</a></code></pre>
<p>Any feedback is welcome!</p>
<p>And the possible race for UP I describe in the mail:</p>
<pre><code><a class="external" href="http://leaf.dragonflybsd.org/mailarchive/kernel/2008-02/msg00013.html">http://leaf.dragonflybsd.org/mailarchive/kernel/2008-02/msg00013.html</a></code></pre>
<p>Do you think this can happen?</p>
<p>Regards,</p>
<pre><code>Michael</code></pre>