DragonFlyBSD bugtracker: Issueshttps://bugs.dragonflybsd.org/https://bugs.dragonflybsd.org/favicon.ico?16293952082017-12-04T07:47:37ZDragonFlyBSD bugtracker
Redmine 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 #2931 (New): 'gdb' of 'vkernel' unable to print backtracehttps://bugs.dragonflybsd.org/issues/29312016-07-26T20:33:39Ztofergus
<p>Whilst attempting to look at issue <a class="issue tracker-5 status-5 priority-4 priority-default closed" title="Submit: PCIe memory mapped config (Closed)" href="https://bugs.dragonflybsd.org/issues/2390">#2390</a> I came across the 'vkernel' debugging page in the wiki</p>
<p><a class="external" href="https://www.dragonflybsd.org/docs/howtos/HowToDebugVKernels/">https://www.dragonflybsd.org/docs/howtos/HowToDebugVKernels/</a></p>
<p>this noted a failure in the current implementation, which caused lockup (issue <a class="issue tracker-1 status-5 priority-5 priority-high3 closed" title="Bug: gdb vkernel doesn't work at all anymore (Closed)" href="https://bugs.dragonflybsd.org/issues/1301">#1301</a>). However my STABLE build</p>
<p>[...] 4.4-RELEASE DragonFly v4.4.3.9.ge5cb2-RELEASE #0: Fri Jul 15 17:02:58 UTC 2016 [...]/usr/obj/usr/src/sys/VKERNEL64 x86_64</p>
<p>attaches correctly</p>
<p>$ sudo gdb /var/vkernel/boot/kernel/kernel 8418<br />GNU gdb (GDB) 7.6.1<br />Copyright (C) 2013 Free Software Foundation, Inc.<br />License GPLv3+: GNU GPL version 3 or later <<a class="external" href="http://gnu.org/licenses/gpl.html">http://gnu.org/licenses/gpl.html</a>><br />This is free software: you are free to change and redistribute it.<br />There is NO WARRANTY, to the extent permitted by law. Type "show copying" <br />and "show warranty" for details.<br />This GDB was configured as "x86_64-dragonfly".<br />For bug reporting instructions, please see:<br /><<a class="external" href="http://bugs.dragonflybsd.org/&gt;">http://bugs.dragonflybsd.org/&gt;</a>...<br />Reading symbols from /var/vkernel/boot/kernel/kernel...done.<br />Attaching to program: /var/vkernel/boot/kernel/kernel, process 8418<br />Reading symbols from /lib/libc.so.8...(no debugging symbols found)...done.<br />Loaded symbols for /lib/libc.so.8<br />Reading symbols from /libexec/ld-elf.so.2...(no debugging symbols found)...done.<br />Loaded symbols for /libexec/ld-elf.so.2<br />0x00000000100a3750 in extpread () from /lib/libc.so.8</p>
<p>but then causes an exception whilst trying to print a backtrace</p>
<p>(gdb) bt<br />#0 0x00000000100a3750 in extpread () from /lib/libc.so.8<br /><a class="issue tracker-1 status-5 priority-3 priority-lowest closed" title="Bug: lib/libcr/sys/ cleanup (Closed)" href="https://bugs.dragonflybsd.org/issues/1">#1</a> 0x00000000101374ab in pread () from /lib/libc.so.8<br /><a class="issue tracker-1 status-5 priority-3 priority-lowest closed" title="Bug: K&R -> ANSI cleanup status (Closed)" href="https://bugs.dragonflybsd.org/issues/2">#2</a> 0x00000000006b9614 in vconsgetc (private=<optimized out>)<br /> at /usr/src/sys/platform/vkernel64/platform/console.c:384<br /><a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: freebsds pipe-reverse test fails on dfly (Closed)" href="https://bugs.dragonflybsd.org/issues/3">#3</a> 0x00000000005040a6 in cngetc () at /usr/src/sys/kern/tty_cons.c:512<br /><a class="issue tracker-1 status-5 priority-5 priority-high3 closed" title="Bug: Rework of nrelease (Closed)" href="https://bugs.dragonflybsd.org/issues/4">#4</a> 0x0000000000473e6a in db_readline (<br /> lstart=lstart@entry=0xa7f480 <db_line> "", lsize=lsize@entry=120)<br /> at /usr/src/sys/ddb/db_input.c:313<br /><a class="issue tracker-1 status-5 priority-3 priority-lowest closed" title="Bug: sys/dev cleanup (Closed)" href="https://bugs.dragonflybsd.org/issues/5">#5</a> 0x00000000004743d2 in db_read_line () at /usr/src/sys/ddb/db_lex.c:55<br /><a class="issue tracker-1 status-5 priority-3 priority-lowest closed" title="Bug: sys/emulation cleanup (Closed)" href="https://bugs.dragonflybsd.org/issues/6">#6</a> 0x0000000000472ed9 in db_command_loop ()<br /> at /usr/src/sys/ddb/db_command.c:465<br /><a class="issue tracker-1 status-5 priority-3 priority-lowest closed" title="Bug: /sys/boot cleanup (Closed)" href="https://bugs.dragonflybsd.org/issues/7">#7</a> 0x0000000000475cff in db_trap (type=type@entry=3, code=code@entry=0)<br /> at /usr/src/sys/ddb/db_trap.c:71<br /><a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: make upgrade broken (Closed)" href="https://bugs.dragonflybsd.org/issues/8">#8</a> 0x00000000006ab64e in kdb_trap (type=type@entry=3, code=code@entry=0, <br /> regs=regs@entry=0x802a866a68)<br /> at /usr/src/sys/platform/vkernel64/x86_64/db_interface.c:173<br /><a class="issue tracker-1 status-5 priority-5 priority-high3 closed" title="Bug: panic with HEAD (Closed)" href="https://bugs.dragonflybsd.org/issues/9">#9</a> 0x00000000006add1c in kern_trap (frame=0x802a866a68)<br /> at /usr/src/sys/platform/vkernel64/x86_64/trap.c:769<br /><a class="issue tracker-1 status-5 priority-5 priority-high3 closed" title="Bug: make buildworld broken (Closed)" href="https://bugs.dragonflybsd.org/issues/10">#10</a> 0x00000000006aef32 in exc_segfault (signo=<optimized out>,<br /> info=<optimized out>, ctxp=<optimized out>)<br /> at /usr/src/sys/platform/vkernel64/x86_64/exception.c:209<br /><a class="issue tracker-1 status-5 priority-3 priority-lowest closed" title="Bug: libstand cleanup (Closed)" href="https://bugs.dragonflybsd.org/issues/11">#11</a> <signal handler called><br /><a class="issue tracker-1 status-5 priority-3 priority-lowest closed" title="Bug: /sys/net cleanup (Closed)" href="https://bugs.dragonflybsd.org/issues/12">#12</a> 0x000000802a8670a0 in ?? ()<br />Cannot access memory at address 0x1</p>
<p>This causes 'ddb' to exit and the process to halt. Presume this is due to the SIGSTOP that halts the 'db>' prompt but unable to decipher how this might be resolved. '~/.gdbinit' contains the</p>
<p>handle SIGSEGV noprint<br />handle SIGUSR1 noprint</p>
<p>suggested in the article. Adding SIGSTOP has no effect.</p>
<p>Additionally, connecting to a running 'vkernel' with 'gdb' appears to have a similar effect; the console is disconnected (although the kernel appears to run).</p>
<p>Happy to document if this is purely an information gap on my part.</p> DragonFlyBSD - Bug #2887 (New): Missing extattr_namespace_to_string and extattr_string_to_namespa...https://bugs.dragonflybsd.org/issues/28872016-02-06T13:09:05Zrubenkruben@rubenkerkhof.com
<p>Hi,</p>
<p>I'm working on porting Burp (<a class="external" href="http://burp.grke.org">http://burp.grke.org</a>) to DragonFly.<br />I've been looking into what it would take for it to support backing up extended attributes.</p>
<p>Burp uses the extattr_namespace_to_string and extattr_string_to_namespace functions, which FreeBSD has in libutil.h and NetBSD in sys/extattr.h. DragonFlyBSD misses those however.</p>
<p>Would it be possible to add those functions?</p> DragonFlyBSD - Bug #2797 (In Progress): vkernels with & without machdep.pmap_mmu_optimizehttps://bugs.dragonflybsd.org/issues/27972015-02-28T00:09:38Zyellowrabbit2010
<p>Hello,</p>
<p>I tried vkernel64 according to vkernel(7) with & without machdep.pmap_mmu_optimize.</p>
<p>With machdep.pmap_mmu_optimize=0 vkernel boots with many <br /><code>ept_copyout: could not fault in vm map, gpa: 804928000</code> (addresses are changing)</p>
<p>With machdep.pmap_mmu_optimize=1 box paniced (no dump, keyboard hangs --- I can't type anything)<br /><pre>
panic: assertion "origpte == 0 || (origpte & pmap->pmap_bit[PG_MANAGED_IDX])
failed in pmap_enter at /usr/src/sys/platform/pc64/x86_64/pmap.c:4122
trace beginning at frame
panic() at panic+0x21f
panic() at panic+0x21f
pmap_enter() at pmap_enter+0x297
vm_fault() at vm_fault+0x5ab
vmx_vmrun() at vmx_vm_run+0xebe
vmx_vmrun() at vmx_vm_run+0x1f
CPU0 stopping CPUs: 0x0000000e
Stopped
Stopped at Debugger+0x38: movb $0,0x125d681(%rip)
db> panic: kqueue: checkloop failed i=0
cpuid = 0
</pre></p>
<p>===================<br /><code>DragonFly fly.home.net 4.1-DEVELOPMENT DragonFly v4.1.0.876.g2deaaa-DEVELOPMENT</code></p>
<p>===================<br /><pre>
CPU: Intel(R) Core(TM) i5-3570 CPU @ 3.40GHz (3400.03-MHz K8-class CPU)
Origin = "GenuineIntel" Id = 0x306a9 Stepping = 9
Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
Features2=0x77bae3ff<SSE3,PCLMULQDQ,DTES64,MON,DS_CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,TSCDLT,AESNI,XSAVE,AVX,F16C,RDRND>
AMD Features=0x28100800<SYSCALL,NX,RDTSCP,LM>
AMD Features2=0x1<LAHF>
Structured Extended Features=0x281<GSFSBASE,SMEP,ENHMOVSB>
Thermal and PM Features=0x77<SENSOR,TURBO,ARAT,PLN,ECMD,PTM>
MONITOR/MWAIT Features=0x3<CST,INTBRK>
real memory = 7995148288 (7624 MB)
avail memory = 7503593472 (7155 MB)
</pre></p> DragonFlyBSD - Bug #2675 (New): Ultimate N WiFi Link 5300 get iwn_intr: fatal firmware error on 5GHzhttps://bugs.dragonflybsd.org/issues/26752014-05-28T22:54:41Zrevuwa
<p>I'm using a Lenovo Thinkad X200s with Intel Ultimate N WiFi Link 5300.</p>
<p>On Dragonfly BSD 3.6.2 it worked perfectly without any errors (and exactly the same configuration). Since 3.7.X and the actual testes 3.8.0RC my WiFi decive throws the following error on every try to load it (also over manual /etc/rc.d/netif restart):</p>
<ol>
<li>dmesg.boot (with rc_debug enabled) ###<br />iwn0: iwn_intr: fatal firmware error<br />firmware error log:<br /> error type = "SYSASSERT" (0x00000005)<br /> program counter = 0x00003130<br /> source line = 0x00000585<br /> error data = 0x0000000100000000<br /> branch link = 0x0000312A0000312A<br /> interrupt link = 0x0000091600000000<br /> time = 1270108785<br />driver status:<br /> tx ring 0: qid=0 cur=0 queued=0 <br /> tx ring 1: qid=1 cur=0 queued=0 <br /> tx ring 2: qid=2 cur=0 queued=0 <br /> tx ring 3: qid=3 cur=3 queued=0 <br /> tx ring 4: qid=4 cur=0 queued=0 <br /> tx ring 5: qid=5 cur=0 queued=0 <br /> tx ring 6: qid=6 cur=0 queued=0 <br /> tx ring 7: qid=7 cur=0 queued=0 <br /> tx ring 8: qid=8 cur=0 queued=0 <br /> tx ring 9: qid=9 cur=58 queued=0 <br /> tx ring 10: qid=10 cur=0 queued=0 <br /> tx ring 11: qid=11 cur=0 queued=0 <br /> tx ring 12: qid=12 cur=0 queued=0 <br /> tx ring 13: qid=13 cur=0 queued=0 <br /> tx ring 14: qid=14 cur=0 queued=0 <br /> tx ring 15: qid=15 cur=0 queued=0 <br /> tx ring 16: qid=16 cur=0 queued=0 <br /> tx ring 17: qid=17 cur=0 queued=0 <br /> tx ring 18: qid=18 cur=0 queued=0 <br /> tx ring 19: qid=19 cur=0 queued=0 <br /> rx ring: cur=11</li>
</ol>
<p>I just load 'iwn5000fw_load="YES"' over loader.conf, because the other modules (if_iwn.ko, wlan_ccmp.ko, wlan_tkip.ko) are loaded by the generic kernel. This is what I've loaded, too:</p>
<ol>
<li>kldstat ###<br />Id Refs Address Size Name<br /> 1 28 0xffffffff80200000 15a8710 kernel<br /> 2 1 0xffffffff817a9000 13020 snd_hda.ko<br /> 3 2 0xffffffff817bd000 31bf8 sound.ko<br /> 4 3 0xffffffff817ef000 bf758 acpi.ko<br /> 5 1 0xffffffff818af000 c7a0 ehci.ko<br /> 6 2 0xffffffff818bc000 f4c0 dm.ko<br /> 7 1 0xffffffff818cc000 1c4f8 dm_target_crypt.ko<br /> 8 4 0xffffffff827e9000 58d0 libiconv.ko<br /> 9 1 0xffffffff827ef000 20c8 libmchain.ko<br />10 1 0xffffffff827f2000 f98 msdos_iconv.ko<br />11 1 0xffffffff827f3000 f88 ntfs_iconv.ko<br />12 2 0xffffffff827f4000 10a38 ntfs.ko<br />13 1 0xffffffff82805000 fd0 cd9660_iconv.ko<br />14 1 0xffffffff82806000 5928 acpi_video.ko<br />15 1 0xffffffff8280c000 70c48 drm.ko<br />16 2 0xffffffff8287d000 2ec8 iicbus.ko<br />17 1 0xffffffff82880000 53fc8 iwn5000fw.ko<br />18 1 0xffffffff828d4000 1da8 coretemp.ko<br />19 1 0xffffffff828d6000 68d0 acpi_thinkpad.ko<br />20 1 0xffffffff828dd000 3dd0 est.ko<br />21 1 0xffffffff83042000 35000 pf.ko</li>
</ol>
<ol>
<li>rc.conf (relevant entries) ###<br />wlans_iwn0="wlan0" <br />ipv6_enable="YES" <br />ipv6_network_interfaces="wlan0" <br />ifconfig_wlan0="up DHCP WPA mode 11a"</li>
</ol>
<ol>
<li>wpa_supplicant.conf ###<br />ctrl_interface=/var/run/wpa_supplicant<br />eapol_version=2<br />network={<br /> ssid="my SSID name" <br /> priority=145<br />#scan_ssid=1<br /> proto=RSN<br /> key_mgmt=WPA-PSK <br /> pairwise=CCMP<br /> group=CCMP<br /> psk="my secure passphrase" <br />}</li>
</ol>
<ol>
<li>sysctl.conf (relevant entries) ###<br />net.inet6.ip6.use_tempaddr=1<br />net.inet6.icmp6.nodeinfo=0<br />net.inet6.icmp6.rediraccept=0</li>
</ol>
<p>In IRC at #dragonflybsd on EFNet <a class="user active user-mention" href="https://bugs.dragonflybsd.org/users/556">@profmakx</a> wrote: "I have iwn4965 and iwn6000, both work".</p>
<p>I've just tested (just for fun) to replace all that modules (if_iwn.ko, wlan_ccmp.ko, wlan_tkip.ko, iwn5000fw.ko) one by one and all together with the older one from v3.6.2. The result was exactly the same error.</p>
<p>I've found a FreeBSD issue with parallels:<br /><a class="external" href="http://www.marshut.com/sinuy/iwn-firmware-sysassert.html">http://www.marshut.com/sinuy/iwn-firmware-sysassert.html</a></p>
<p>Thanks in advance for any help!</p> DragonFlyBSD - Bug #2636 (Feedback): Add -x flag to iostat (a la solaris)https://bugs.dragonflybsd.org/issues/26362014-02-13T21:50:00Ztuxillo
<p>Add -x flag to iostat (a la solaris)</p> DragonFlyBSD - Bug #2631 (In Progress): Verify library versioning current with full package build...https://bugs.dragonflybsd.org/issues/26312014-02-13T21:46:57Ztuxillo
<p>Verify library versioning current with full package build and switch it on (after publishing packages)</p>
<p>most libraries complete and working now. libc/pthreads could be an issue.</p> DragonFlyBSD - Bug #2552 (New): hammer recovery should indicate progresshttps://bugs.dragonflybsd.org/issues/25522013-05-01T02:44:36Zphma
<p>I'm running hammer recover on a 55 GB partition of an IDE drive and it's been running for about a day. I have no idea how long it'll take. It would be a good idea if, every few minutes, hammer recover would output how many blocks it's read and how many are left, or just a percentage.</p> 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 #2020 (New): Port brcm80211 driver from Linux to DragonFly BSDhttps://bugs.dragonflybsd.org/issues/20202011-03-06T06:54:10Zstuder
<p>In September 2010, Broadcom released a full opensource version under BSD licence <br />of their driver for part of their WLAN hardware (BCM43224, BCM43225, BCM4313 <br />(PCIe NIC)).</p>
<p>That would be so nice if this could be added to DragonFly BSD.</p>
<p>For more information, see :<br />- <a class="external" href="http://thread.gmane.org/gmane.linux.kernel.wireless.general/55418">http://thread.gmane.org/gmane.linux.kernel.wireless.general/55418</a><br />- <a class="external" href="http://wireless.kernel.org/en/users/Drivers/brcm80211">http://wireless.kernel.org/en/users/Drivers/brcm80211</a></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 #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 #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 #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>