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 #3107 (New): ACPI interrupt storm when loading i915 on Lenovo T460https://bugs.dragonflybsd.org/issues/31072017-12-04T07:47:37Zoyvinhtoyvinht@pvv.ntnu.no
<p>This is on a Lenovo T460 (firmware r06uj56d)</p>
<pre><code>root# uname -a<br /> DragonFly slaptop 5.1-DEVELOPMENT DragonFly v5.1.0.381.ge8ac90-DEVELOPMENT #10: Mon Dec 4 07:52:28 CET 2017 root@slaptop:/usr/obj/usr/src/sys/SLAPTOP x86_64</code></pre>
<p>After doing:</p>
<pre><code>root# kldload i915</code></pre>
<p>the systems gets very slow, and looking at vmstat I see interrupts from acpi0 increasing by 2000-5000 every second (using kern.livelock_lowater=1000 and kern.livelock_limit=2000 makes the system usable again):</p>
<pre><code>root# vmstat -i</code></pre>
<pre><code>interrupt total rate<br /> acpi0 1681307 1925</code></pre>
<p>FWIW I have tested enabling DDB and INVARIANTS in the kernel, and built /sys/dev/acpica with ACPI_DEBUG=1, which fills the kernel message buffer with messages like:</p>
<pre><code>evgpe-0634 EvGpeDetect : Read registers for GPE 60-67: Status=40, Enable=46, RunEnable=46, WakeEnable=00<br /> evgpe-0607 EvGpeDetect : Ignore disabled registers for GPE 68-6F: RunEnable=00, WakeEnable=00<br /> evgpe-0607 EvGpeDetect : Ignore disabled registers for GPE 70-77: RunEnable=00, WakeEnable=00<br /> evgpe-0607 EvGpeDetect : Ignore disabled registers for GPE 78-7F: RunEnable=00, WakeEnable=00<br /> evevent-0361 EvFixedEventDetect : Fixed Event Block: Enable 00000120 Status 00000001<br /> evgpe-0607 EvGpeDetect : Ignore disabled registers for GPE 00-07: RunEnable=00, WakeEnable=00<br /> evgpe-0607 EvGpeDetect : Ignore disabled registers for GPE 08-0F: RunEnable=00, WakeEnable=00</code></pre> DragonFlyBSD - Bug #2252 (New): snd_hda not useable if loaded via /boot/loader.confhttps://bugs.dragonflybsd.org/issues/22522011-12-05T19:58:43Zxbit
<p>When loading snd_hda from /boot/loader.conf it is loaded, but cannot be used and configured. At least audio/moc does not work, it is unable to use the OSS interface. But after unloading and loading snd_hda again the sound card is useable.</p>
<p>As a workaround I added "/sbin/kldload snd_hda" to /etc/rc.local and then the soundcard is useable form audio/moc as OSS device.</p>
<p>snd_hda was the only sound kernel module that has been loaded via /boot/loader.conf.</p>
<p>Kernel configuration is GENERIC x86_64 (v2.12.0.23.gec4cf).</p> DragonFlyBSD - Bug #1819 (In Progress): truss - Major revamping task listhttps://bugs.dragonflybsd.org/issues/18192010-09-03T17:36:17Ztuxillo
<p>Many things to do with truss. Please add more in case you consider:</p>
<ul>
<li>Identifying 'unknown syscalls' and fix them.</li>
<li>Make truss work for x86_64. This may require some hacking as truss looks in <code>/proc/<PID>/etype</code> to see the binary type, but we make no distinction between i386 and x86_64 binaries on that field.</li>
<li>Get rid of the need of /proc so it can be used in chroots</li>
</ul> DragonFlyBSD - Bug #1714 (New): hwpmchttps://bugs.dragonflybsd.org/issues/17142010-04-03T18:59:28Zalexh
<p>I've put together Aggelos' original patches to import hwpmc from FreeBSD into <br />one place. Each file is prefixed with a number indicating the order of the <br />original submissions,<br /><a class="external" href="http://leaf.dragonflybsd.org/~alexh/hwpmc/">http://leaf.dragonflybsd.org/~alexh/hwpmc/</a></p>
<p>FWIW I think this is a nice thing to have and it would be nice if someone would <br />step up to firstly make the patches apply cleanly to master, then import them as <br />commits into git and if possible, make all the features work ;)</p>
<p>Cheers,<br />Alex</p>
<p>The original mail to submit@ was:<br />Hello,</p>
<p>this port of hwpmc ( start here: <a class="external" href="http://wiki.freebsd.org/PmcTools">http://wiki.freebsd.org/PmcTools</a> ) has<br />been stagnating on my hard disk for some months now. I'm finally<br />submitting it for inclusion because</p>
<p>a) the parts that work might be useful to someone and, more importantly,<br />b) complaints and bug reports might help get me off my butt and fix the<br /> remaining issues.</p>
<p>I've taken the time to split the patches so that people can review them<br />easily (the original freebsd code is submitted as .tgz since I'm not<br />interested in your review of that).</p>
<p>Please apply patches / extract tarballs in numerical order. I'll be a<br />bit surprised if there are no omissions/duplicate patches, but at least<br />my build test for world/kernel worked.</p>
<p>You will need these lines in your kernel config. See the manual pages<br />for usage examples.</p>
<p>options HWPMC_HOOKS<br />#device hwpmc</p>
<p>Testing status:</p>
<p>feature test status</p>
<p>global counting pmc tested, works<br />process counting pmc tested, works [0]<br />descendent tracking for<br />process counting pmc tested, works [0]<br />global sampling pmc possibly broken<br />process sampling pmc broken<br />logfile output untested<br />mapfilename untested<br />gprof execution profiles untested<br />SMP untested [1]<br />threaded (lwp) programs untested</p>
<p>[0] May still have bugs of course, test it out!<br />[1] Not even compile-tested</p> DragonFlyBSD - Bug #1538 (New): mountroot should probe file systemshttps://bugs.dragonflybsd.org/issues/15382009-09-28T01:48:34Zcorecode
<p>When mounting root from hammer, it is necessary to specify the file <br />system type in the vfs.root.mountfrom setting, otherwise the machine <br />will just be unhappy and issue the mountroot prompt (or rather, directly <br />go to ddb, see other bug report). This is very inconvenient and <br />irritating. The kernel should try all available file systems to mount root.</p>
<p>Possibly this should also be extended to mount itself, but this bug <br />report only deals with the mountroot issue.</p> DragonFlyBSD - Bug #1532 (New): jemalloc doesn't work on DragonFlyhttps://bugs.dragonflybsd.org/issues/15322009-09-25T19:10:21Zhasso
<p>jemalloc is a malloc(3) implementation from FreeBSD and for some reason <br />increasingly popular in various software pieces dealing ECMAscript and related <br />stuff. This means browsers (Firefox, Chrome), but also Gnash for example. <br />Unfortunately jemalloc doesn't work with DragonFly. Matt explained why some <br />time ago:</p>
<p><a class="external" href="http://leaf.dragonflybsd.org/mailarchive/users/2009-04/msg00162.html">http://leaf.dragonflybsd.org/mailarchive/users/2009-04/msg00162.html</a></p> DragonFlyBSD - Bug #1428 (Feedback): POSIX.1e implementation is too oldhttps://bugs.dragonflybsd.org/issues/14282009-07-17T02:08:53Zhasso
<p>Our posix1e(3) implementation is too old and not compatible with any <br />recent enough piece of software.</p> DragonFlyBSD - Bug #1127 (Feedback): cdrom drive not detectedhttps://bugs.dragonflybsd.org/issues/11272008-08-22T22:48:07Ztgr
<p>Hi, I've got a bit of a problem with the install CD. I've tested this on<br />2.0 and 2.1.0-DEV (i.e. the daily iso downloadable on 2008.08.22). This<br />happens way before I can make any sort of FS, but the same machine's<br />booted up XP, Kubuntu and FBSD5.4.</p>
<p>Anyway, what I can see on the bootup screen of that machine now is as<br />follows:</p>
<p><quote><br />iso_mountroot: can't find rootvp<br />Root mount failed: 6<br />Mounting root from cd9660:acd0<br />no disk named 'acd0'<br />setrootbyname failed<br />iso_mountroot: can't find rootvp<br />Root mount failed: 6<br />Mounting root from cd9660:acd1<br />no disk named 'acd1'<br />setrootbyname failed<br />iso_mountroot: can't find rootvp<br />Root mount failed: 6<br />Mounting root from cd9660:/dev/acd0a<br />no disk named 'acd0a'<br />setrootbyname failed<br />iso_mountroot: can't find rootvp<br />Root mount failed: 6<br /></quote></p>
<p>When I then type "panic", the following appears:</p>
<p><quote><br />panic: panic from console<br />Trace beginning at frame 0xc872ca8<br />panic(c05ce64a,c06bc720,c05d0be3,c0872cd8,6) at panic+0x99<br />panic(c05d0be3,c05ce4a6,696e6170,c0560063,8) at panic+0x99<br />vfs_mountroot_ask(c4360b70,c06702dc,d7886c3c,87d000,c0872d98) at<br />vfs_mountroot_ask+0xd7<br />vfs_mountroot(0,87d000,86fc00,87d000,0) at fvs_mountroot+oxcf<br />mi_startup(86f000,d,c06b2a38,c0872c24,c0872c0c) at mi_startup+0x99<br />begin() at begin+0x42<br />Debugger("panic")<br />Stopped at Debugger+0x44: movb $0,in_Debugger.0<br /></quote></p>
<p>I've run this twice in a row just to verify all the values, in case they<br />changed. They didn't.</p>
<p>If there is any more information I can provide, please do tell. This<br />system is not in use in any other way, all data on the HDs etc is<br />discardable, so anything goes.</p> DragonFlyBSD - Bug #679 (New): Netgraph backward compatibility for old *LEN constantshttps://bugs.dragonflybsd.org/issues/6792007-06-05T07:56:01Znant
<p>Maintain the old *LEN netgraph constants around for some time to allow<br />the building of earlier mpd (Multi-link PPP Daemon).</p>
<p>Pointed out by: Alexander Motin <<a class="email" href="mailto:mav@freebsd.org">mav@freebsd.org</a>><br />Obtained from: FreeBSD</p>
<p>BTW: Do we need a BURN_BRIDGES kernel option?</p>
<p>Thanks,<br />Nuno</p> DragonFlyBSD - Bug #600 (New): /sys/libkern/karc4randomhttps://bugs.dragonflybsd.org/issues/6002007-04-11T17:14:04Zrobin_carey5
<p>What is the point of keeping/using the in-kernel arc4<br />random number generator when you already have a very<br />good/superior IBAA/L15 random number generator.</p>
<p>If you need a u_int32_t quantity then simply add a<br />function to /sys/kern/kern_nrandom.c to produce a<br />u_int32_t.</p>
<p>--</p>
<p>Some issues with /sys/libkern/karc4random.c :</p>
<p>(a) If you intend to keep /sys/libkern/karc4random.c I<br />recommend you make a modification to it to improve<br />performance: Every time the karc4_random() function is<br />called it calls getmicrotime(), to check the time, and<br />it also checks the number of runs made, to see if it<br />should reseed itself. You can make a big performance<br />improvement by removing this call to getmicrotime()<br />and instead simply checking the number of runs to<br />determine when it should reseed itself.</p>
<p>(b) The karc4random.c file uses u_int8_t types for<br />arc4_i, arc4_j and arc4_t so there is no need for the<br />% 256 operation - another performance improvement.</p>
<p>(c) In arc4_init() you are throwing away 256*4 bytes<br />of output, when you only need to throw away the first<br />256 bytes of output.</p>
<p>Sincerely,<br />R Carey.</p>
<pre><code>_<em><i></em></i>__<em>_</em>_______________________________________________<br />Yahoo! Answers - Got a question? Someone out there knows the answer. Try it<br />now.<br /><a class="external" href="http://uk.answers.yahoo.com/">http://uk.answers.yahoo.com/</a></code></pre> DragonFlyBSD - Bug #385 (Feedback): Mail archive address removalhttps://bugs.dragonflybsd.org/issues/3852006-11-22T22:22:03Zjustin
<p>Here's a question for everyone: I had originally the mail archive to<br />completely remove mail addresses, but it seems to mostly be annoying -<br />contacting someone from an archived email would be a dead end unless you<br />happened to already know the person's email address. Meanwhile, the<br />DragonFly lists are archived other places like MARC and Gmane, and<br />addresses are at best mildly obfusticated there.</p>
<p>Opinions? If anyone is significantly bothered by this, I'll keep the<br />addresses completely hidden.</p> DragonFlyBSD - Bug #293 (Feedback): Various updates to the handbookhttps://bugs.dragonflybsd.org/issues/2932006-08-11T04:26:06Zvictor
<p>Hi,</p>
<p>there are 3 patches attached:</p>
<p>book.diff - Updates the copyright info relating to FreeBSD at the header<br /> of the handbook.</p>
<p>dfbsd-updating - Update cvsup port path to the current pkgsrc version in<br /> the chapter "Updating DragonFly".</p>
<p>basics.diff - Update various paths relating to pkgsrc and hier(7). Also<br /> make it use the new entity for pkgsrc <br /> tree/collection/framework.</p>