DragonFlyBSD bugtracker: Issueshttps://bugs.dragonflybsd.org/https://bugs.dragonflybsd.org/favicon.ico?16293952082010-10-20T17:22:04ZDragonFlyBSD bugtracker
Redmine DragonFlyBSD - Bug #1882 (New): Idea for handling new USB vendor/device codeshttps://bugs.dragonflybsd.org/issues/18822010-10-20T17:22:04Zbmk
<p>This is just an idea / wish.</p>
<p>Have a config file called /etc/usb_hotwire.conf</p>
e.g.:
<ol>
<li>This file allows you to map a new unsupported usb vendor/device code</li>
<li>to an existing usb vendor/device code supported by a driver.</li>
<li>File Format:</li>
<li><unsupported vendor code>:<unsupported device code> <supported vendor<br />code>:<supported device code></li>
</ol>
<ol>
<li>The following makes my unsupported USB wireless adapter use the same driver<br />(rum) as a D-Link DWL-G122</li>
</ol>
<p>0x1044:0x2573 0x07d1:0x3c03</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 #1313 (New): Signal code in kernel needs major overhaul (signal queues, si_cod...https://bugs.dragonflybsd.org/issues/13132009-03-13T15:04:10Zhasso
<p>Although our siginfo structure has a si_code member, we don't use it and <br />don't even have a defines related to it.</p>
<p><a class="external" href="http://www.opengroup.org/onlinepubs/009695399/basedefs/signal.h.html">http://www.opengroup.org/onlinepubs/009695399/basedefs/signal.h.html</a></p> DragonFlyBSD - Bug #1148 (In Progress): BCM4311 wireless network adapter detected but not functionalhttps://bugs.dragonflybsd.org/issues/11482008-10-09T12:27:01Zarchimedes.gaviola
<p>Hi,</p>
<p>I have a mini-PCI wireless network adapter on my laptop that wasn't<br />detected on DragonFly 2.0.0 during installation. Since it wasn't<br />detected, what I did is performing the steps in the<br />bwi(4) manual <a class="external" href="http://leaf.dragonflybsd.org/cgi/web-man?command=bwi&section=ANY">http://leaf.dragonflybsd.org/cgi/web-man?command=bwi&section=ANY</a><br />and download the firmware at<br /><a class="external" href="http://leaf.dragonflybsd.org/~sephe/bwi/v3.tbz">http://leaf.dragonflybsd.org/~sephe/bwi/v3.tbz</a>. Now, the driver were<br />detected (Broadcom BCM4311) but seems not functional. It doesn't show<br />up after invoking ifconfig. Below is the dmesg output:</p>
<p>device_probe_and_attach: bwi0 attach returned 6<br />Preloaded elf module "/modules/if_bwi.ko" at 0xc07b93c8.<br />bwi0: <Broadcom BCM4311 802.11 Wireless Lan> mem 0x31300000-0x31303fff<br />irq 11 at device 0.0 on pci1<br />bwi0: BBP: id 0x4311, rev 0x2, pkg 0<br />bwi0: MAC rev 13 is not supported<br />bwi0: no MAC was found</p>
<p>And as I try looking at the /usr/src/sys/dev/netif/bwi/if_bwi.c code,<br />BCM4311 is part of the supported device</p>
<pre><code>{ PCI_VENDOR_BROADCOM, PCI_PRODUCT_BROADCOM_BCM4311,<br /> "Broadcom BCM4311 802.11 Wireless Lan" },</code></pre>
<p>Thanks,<br />Archimedes</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 #725 (In Progress): 'make distribution' fails w/'ro' /usr/objhttps://bugs.dragonflybsd.org/issues/7252007-07-10T09:42:05Zc.turner
<p>This seems to choke on sendmail from a ~1wk build<br />(no code changes on this part of the tree it seems)</p>
<p>not sure if it is 'supposed to work' or<br />for how long it has been broken, so I didn't investigate further..</p>
<p>basically, trying to use a -HEAD machine to build out jail<br />images from a release machine over ro nfs..</p>
<p>Thanks,</p>
<p>- Chris</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> DragonFlyBSD - Bug #285 (Feedback): interrupt latency with re without ip address configuredhttps://bugs.dragonflybsd.org/issues/2852006-08-07T06:00:07Zthomas.nikolajsen
<p>Playing sound using pcm(4)/snd(4) gives bad quality: hiss and hops, like sound isn't playing for very short time periods.</p>
<p>This is experienced:<br /> - not having SMP in kernel config (eg GENERIC)<br /> - from dfly-1.5 26th December '05 (24th is ok using kernels from chlamydia);<br />including HEAD.</p>
<p>dfly-1.4 is ok, including 1.4.4.</p>
<p>Using audio/mpg123 for MP3, 'cp test.raw /dev/dspW' or pcmplay for decoded sound.<br />Buffering audio data with mpg123 -b doesn't sound like making any difference.</p>
<p>CPU load doesn't sound like making any difference.<br />Problem experienced on several systems, using snd_via8233 and snd_ich.</p>
<p>No X11 used.</p>
<pre><code>-thomas</code></pre>