DragonFlyBSD bugtracker: Issueshttps://bugs.dragonflybsd.org/https://bugs.dragonflybsd.org/favicon.ico?16293952082020-04-28T13:58:19ZDragonFlyBSD bugtracker
Redmine 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 #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 #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 #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 #2973 (Resolved): Kernel panic "faddr mismatch for reconnect"https://bugs.dragonflybsd.org/issues/29732016-12-28T11:08:50Zmneumann
<p>It can be easily reproduced (at least on my box) with the following commands:</p>
<pre><code>gem install --user-install taskwarrior-web<br /> .gem/ruby/2.2/bin/task-web</code></pre>
<p>Needs following packages:</p>
<pre><code>ruby-2.2.6_1,1<br /> ruby22-gems-2.6.8</code></pre>
<p>Panics with "faddr mismatch for reconnect" in sys/netinet/tcp_usrreq.c.</p>
<p>Kernel is most recent:</p>
<pre><code>4.7-DEVELOPMENT DragonFly v4.7.0.1061.g5abb6-DEVELOPMENT</code></pre>
<p>I can provide crash dumps if neccessary.</p> DragonFlyBSD - Bug #1933 (Closed): HAMMER Insufficient undo FIFO space panichttps://bugs.dragonflybsd.org/issues/19332010-12-10T18:53:00Zmneumann
<p>Somehow my 120 GB HAMMER filesystem got into a situation where I couldn't<br />recover (mount r/w) anymore. Mounting it always failed with an "insufficient<br />undo FIFO space" panic. (See screenshots df-hammer{1-4}.png).</p>
<p>The only way to recover was to mount read-only and then copy to a new HAMMER<br />filesystem (see hammer-recovery-ro.png).</p>
<p>I tried with the most recent version of DragonFly (daily snapshot; i386), but<br />also with a 2.6 version.</p>
<p>Any thoughts why this could happen and what to do in this situation? It somehow<br />must have paniced the system while running for the first time, then paniced upon<br />reboot during HAMMER recovery.</p>
<p>Screenshots: <a class="external" href="http://leaf.dragonflybsd.org/~mneumann/hammer_insuff_fifo/">http://leaf.dragonflybsd.org/~mneumann/hammer_insuff_fifo/</a></p> DragonFlyBSD - Bug #1223 (Closed): Hammer boot cannot load modules anymorehttps://bugs.dragonflybsd.org/issues/12232009-01-10T23:23:01Zmneumann
<p>Hi,</p>
<p>I'm using the pure Hammer bootloader.</p>
<p>At first it worked, but now, after using the system for a while I cannot <br />load modules at boot time anymore. So I always have to disable acpi, <br />otherwise it will hang shortly after showing some progress trying to <br />load the module (it just shows a few "/", "|", backslash, "-" <br />characters, then it hangs).</p>
<p>The kernel itself boots just fine. I am using the GENERIC kernel.</p>
<p>Regards,</p>
<pre><code>Michael</code></pre> DragonFlyBSD - Bug #1222 (Closed): NATA patcheshttps://bugs.dragonflybsd.org/issues/12222009-01-08T08:56:07Zmneumann
<p>Hi,</p>
<p>Here is a first patchset to bring in some new stuff from FreeBSD's ata<br />implementation. More to follow.</p>
<p>Note that the huge diffs produced by the modularization commits is<br />nothing more than splitting the ata-chipset.c into cs-*.c files and<br />later renaming them to chipsets/*.c (no other code changes!).</p>
<p><a class="external" href="http://leaf.dragonflybsd.org/~mneumann/nata1.patch.gz">http://leaf.dragonflybsd.org/~mneumann/nata1.patch.gz</a></p>
<p>Regards,</p>
<pre><code>Michael</code></pre> DragonFlyBSD - Bug #1201 (Closed): NATA patcheshttps://bugs.dragonflybsd.org/issues/12012009-01-08T01:44:01Zmneumann
<p>Ah cool. Didn't know about private git repos :)</p>
<p>I've uploaded my changes. It's in branch ata-sync-freebsd.</p>
<p>Regards,</p>
<pre><code>Michael</code></pre> DragonFlyBSD - Bug #1100 (Closed): /usr/Makefile needs to be updated for 2.0 (release-src-cvsup)https://bugs.dragonflybsd.org/issues/11002008-07-29T19:53:00Zmneumann
<p>Hi,</p>
<p>The release-src-cvsup target still contains the RELEASE_1_12 tag, which <br />should instead be:</p>
<pre><code>-rDragonFly_RELEASE_2_0_Slip</code></pre>
<p>I don't know where to find this file in the source tree, so I can't fix <br />it myself. Anyone?</p>
<p>Regards,</p>
<pre><code>Michael</code></pre> DragonFlyBSD - Bug #1099 (Closed): Frequent X11 Fatal server errors (caught signal 11)https://bugs.dragonflybsd.org/issues/10992008-07-29T19:50:10Zmneumann
<p>Hi,</p>
<p>X11 starts just fine, but after a while I always get a Fatal server <br />error (caught signal 11).</p>
<p>This happens with the intel driver. Xorg.0.log appended, together with <br />xorg.conf and dmesg.</p>
<p>Anything I can do about it? Any hints how to track down this bug?</p>
<p>Regards,</p>
<pre><code>Michael</code></pre> DragonFlyBSD - Bug #1051 (Closed): Hammer snapshot symbolic links with @@https://bugs.dragonflybsd.org/issues/10512008-07-07T20:07:09Zmneumann
<p>Hi,</p>
<p>lrwxr-xr-x 1 root wheel 27 Jul 7 15:29 snap-20080707-1529 -> <br />/hammer@@0x0000000106267ffd<br />dragnas# cd snap-20080707-1529<br />snap-20080707-1529: No such file or directory.</p>
<p>It works if the symbolic link is /hammer/<code>@... (instead of<br />"/hammer</code>@..."). I can update the "hammer snapshot" utility to generate<br />"correct" symlinks but only if "/hammer@@" is incorrect.</p>
<p>Regards,</p>
<pre><code>Michael</code></pre> DragonFlyBSD - Bug #947 (Closed): Kernel panic during boot in usb_add_taskhttps://bugs.dragonflybsd.org/issues/9472008-02-13T04:59:18Zmneumann
<p>I tried my brand new HP Compaq laptop 6710b under DragonFly, but during booting<br />the installer CD it "throws" a page fault:</p>
<pre><code>uhub0: 2 ports ...<br /> uhub0: &lt;Intel UHCI root hub, ...&gt;</code></pre>
<pre><code>Fatal trap 12: page fault while in kernel mode<br /> fault virtual address = 0x0<br /> fault code = supervisor write, page not present<br /> instruction pointer = 0x8:0xc04a9c5c<br /> stack pointer = 0x10:0xc25f8d38<br /> frame pointer = 0x10:0xc25f8d48<br /> code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, def32 1, gram 1<br /> processor eflags = interrupt enabled, resume, IOPL = 0<br /> current process = Idle<br /> current thread = pri 46 (CRIT)</code></pre>
<pre><code>kernel: type 12, code=2<br /> stopped at usb_add_task+0x4c: movl %edi,0(%eax)</code></pre>
<p>This happens with the latest snapshot version as of yesterday and also with the<br />1.10 release.</p>
<p>FreeBSD 7.0-BETA3 silently hangs during boot, while NetBSD 4.0RC_4 works like a<br />charm (it can even dual-boot windows natively)!</p>
<p>There exists a thread on dragonfly.kernel named "Kernel panic during boot in<br />usb_add_task" about this issue.</p> DragonFlyBSD - Bug #925 (Closed): Document kmalloc() M_INTWAIThttps://bugs.dragonflybsd.org/issues/9252008-01-23T18:22:29Zmneumann
<p>man page of kmalloc doesn't show M_INTWAIT.</p>
<p>Also see doc/notes/porting_drivers.txt for usage in contrast to FreeBSD's M_NOWAIT.</p>