DragonFlyBSD bugtracker: Issueshttps://bugs.dragonflybsd.org/https://bugs.dragonflybsd.org/favicon.ico?16293952082016-07-26T20:33:39ZDragonFlyBSD bugtracker
Redmine 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 #2930 (New): 'objcache' causes panic during 'nfs_readdir'https://bugs.dragonflybsd.org/issues/29302016-07-26T20:00:23Ztofergus
<p>'vkernel' with '/home' file system mounted from host produces the following panic when trying to read a directory with 10s of 1000s of files. Increasing memory to the 'vkernel' avoids the issue.</p>
<p>panic: NFS node: malloc limit exceeded<br />cpuid = 0<br />Trace beginning at frame 0x80291f70a0<br />panic() at 0x4bc587<br />panic() at 0x4bc587<br />kmalloc() at 0x4b87aa<br />objcache_malloc_alloc() at 0x4af344<br />objcache_get() at 0x4afba5<br />nfs_nget_nonblock() at 0x5f7ab4<br />Debugger("panic")</p>
<p>CPU0 stopping CPUs: 0x0000000000000000<br /> stopped<br />Stopped at 0x6ab941: movb $0,0x1165564(%rip)</p> DragonFlyBSD - Bug #2835 (New): /usr/include/c++/5.0/bits/c++locale.h likes _POSIX_C_SOURCE>=200809https://bugs.dragonflybsd.org/issues/28352015-08-04T15:05:55Zdavshao
<p>Using current master DragonFly, trying to build dports devel/ncurses or pkgsrc devel/ncurses fails with:</p>
<p>c++ -DHAVE_CONFIG_H -I. -I../../c++ -I../include -I../../c++/../include -D_BSD_TYPES -D__BSD_VISIBLE -D_POSIX_C_SOURCE=200112L -D_XOPEN_SOURCE=600 -DNDEBUG -pipe -g -O2 -fno-strict-aliasing -fPIC -DPIC -c ../../c++/cursesmain.cc -o ../obj_s/cursesmain.o<br />In file included from /usr/include/c++/5.0/bits/localefwd.h:40:0,<br /> from /usr/include/c++/5.0/ios:41,<br /> from /usr/include/c++/5.0/ostream:38,<br /> from /usr/include/c++/5.0/iostream:39,<br /> from ../../c++/cursesmain.cc:39:<br />/usr/include/c++/5.0/bits/c++locale.h: In function 'int std::__convert_from_v(int* const&, char*, int, const char*, ...)':<br />/usr/include/c++/5.0/bits/c++locale.h:61:47: error: 'locale_t' was not declared in this scope<br /> _<em>c_locale __old = (</em>_c_locale)uselocale((locale_t)__cloc);<br /> ^<br />/usr/include/c++/5.0/bits/c++locale.h:61:62: error: 'uselocale' was not declared in this scope<br /> _<em>c_locale __old = (</em>_c_locale)uselocale((locale_t)__cloc);</p>
<p>I suspect the responsible change may be:</p>
<p>commit d1732c039257d5ff06e218b885a2d1ee92daa355<br />Date: Thu Jul 30 22:22:02 2015 +0200</p>
<pre><code>gcc50: Remove generic versions of added files</code></pre>
<p>where in particular<br />.../libstdc++-v3/config/locale/generic/c_locale.h <br />was removed.</p>
<p>c++/5.0/bits/c++locale.h contains<br />#include <clocale></p>
<p>/usr/include/c++/5.0/clocale contains<br />#include <locale.h></p>
<p>/usr/include/locale.h contains</p>
<p>#if __POSIX_VISIBLE >= 200809<br />#include <xlocale/_locale.h><br />#endif</p>
<p>locale_t appears to be defined in /usr/include/xlocale/_locale.h</p>
<p>And I believe __POSIX_VISIBLE is defined in cdefs.h where it is set depending on the value of _POSIX_C_SOURCE.</p>
<p>At least on pkgsrc devel/ncurses, the build was able to be completed when its configure was hacked similar to the following:</p>
<p>cf_POSIX_C_SOURCE=200809L<br />cf_XOPEN_SOURCE=700</p>
<p>Now the obvious workaround is simply to use the built-in ncurses. However I am wondering if in general the new recommendation for userland software is to edit their aclocal.m4's or whatever else they use defining</p>
<p>_POSIX_C_SOURCE=200809<br />_XOPEN_SOURCE=700</p>
<p>for DragonFly. And do they need to test the version of DragonFly?</p>
<p>Or would it be possible to put the deleted generic files back?</p> DragonFlyBSD - Bug #2825 (New): 3x dhclient = hanging system (objcache exhausted)https://bugs.dragonflybsd.org/issues/28252015-06-09T13:59:46Zjaccovonb
<p>Starting dhclient 3 times causes the system to hang:</p>
<pre><code>Warning, objcache(mbuf pkt hdr + cluster): Exhausted!</code></pre>
<p>To reproduce, set the following in /etc/rc.conf:</p>
<p>ifconfig_em0="DHCP" <br />ifconfig_em1="DHCP" <br />ifconfig_em2="DHCP"</p> DragonFlyBSD - Bug #2688 (New): 67613368bdda7 Fix wrong checks for U4B presence Asrock Z77M diffi...https://bugs.dragonflybsd.org/issues/26882014-06-29T02:06:55Zdavshao
<p>For an Asrock Z77M motherboard, Intel Core i3-3225 CPU PC, detection of a USB keyboard was already somewhat erratic, but following 67613368bdda7 Fix wrong checks for U4B presence it has become almost impossible. The motherboard is UEFI, but I am using legacy support modes for hard drives and USB to emulate older booting using BIOS. The following summarizes the differences I can see between two verbose dmesg's, one asrock_z77m_verbose_good.txt with 67613368bdda7 reverted, the other asrock_z77m_verbose_bad.txt with current master. The USB keyboard and USB mouse are attached using a USB hub but similar behavior has been observed not using a hub. Nothing similar has been noticed with the same system using other OSes such as FreeBSD i386 current, FreeBSD 10 stable, FreeBSD 10 releng, NetBSD 6.99.x, OpenBSD 5.5-current, etc.</p>
<p>Both have</p>
<p>kbd: new array size 4<br />kbd1 at kbdmux0</p>
<p>Both have</p>
<p>pci0: <serial bus, USB> (vendor 0x8086, dev 0x1e31) at device 20.0 irq 16<br />pci0: <simple comms> (vendor 0x8086, dev 0x1e3a) at device 22.0 irq 16<br />ehci0.pci0.pcib0.acpi0.nexus0.root0<br />ehci0: <Intel Panther Point USB 2.0 controller> [tentative] mem 0xf7f18000-0xf7f183ff irq 16 at device 26.0 on pci0</p>
<p>Only the reverted good boot has:</p>
<p>ehci0: <Intel Panther Point USB 2.0 controller> [tentative] mem 0xf7f18000-0xf7f183ff irq 16 at device 26.0 on pci0<br />ehci0: Reserved 0x400 bytes for rid 0x10 type 3 at 0xf7f18000<br />usbus0: waiting for BIOS to give up control</p>
<p>Then both have:</p>
<p>usbus0: EHCI version 1.0<br />usbus0.ehci0.pci0.pcib0.acpi0.nexus0.root0<br />usbus0: <Intel Panther Point USB 2.0 controller> [tentative] on ehci0<br />usbus0: <Intel Panther Point USB 2.0 controller> [attached!] on ehci0<br />ehci0: <Intel Panther Point USB 2.0 controller> [attached!] mem 0xf7f18000-0xf7f183ff irq 16 at device 26.0 on pci0</p>
<p>Later both dmesgs have:</p>
<p>ehci1.pci0.pcib0.acpi0.nexus0.root0<br />ehci1: <Intel Panther Point USB 2.0 controller> [tentative] mem 0xf7f17000-0xf7f173ff irq 23 at device 29.0 on pci0</p>
<p>Only the reverted good dmesg has:</p>
<p>ehci1: Reserved 0x400 bytes for rid 0x10 type 3 at 0xf7f17000</p>
<p>Both have:</p>
<p>ugen0.1: <Intel> at usbus0<br />uhub0: <Intel EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus</p>
<p>Only the reverted good dmesg has:</p>
<p>usbus1: waiting for BIOS to give up control</p>
<p>Then both have:</p>
<p>usbus1: EHCI version 1.0<br />usbus1.ehci1.pci0.pcib0.acpi0.nexus0.root0<br />usbus1: <Intel Panther Point USB 2.0 controller> [tentative] on ehci1<br />usbus1: <Intel Panther Point USB 2.0 controller> [attached!] on ehci1<br />ehci1: <Intel Panther Point USB 2.0 controller> [attached!] mem 0xf7f17000-0xf7f173ff irq 23 at device 29.0 on pci0</p>
<p>Later both have:</p>
<p>usbus1: 480Mbps High Speed USB v2.0<br />ugen1.1: <Intel> at usbus1<br />uhub1: <Intel EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus1<br />uhub0: 2 ports with 2 removable, self powered<br />uhub1: 2 ports with 2 removable, self powered<br />ugen0.2: <vendor 0x8087> at usbus0<br />uhub2: <vendor 0x8087 product 0x0024, class 9/0, rev 2.00/0.00, addr 2> on usbus0<br />...<br />ugen1.2: <vendor 0x8087> at usbus1<br />uhub3: <vendor 0x8087 product 0x0024, class 9/0, rev 2.00/0.00, addr 2> on usbus1<br />uhub2: 6 ports with 6 removable, self powered</p>
<p>But then only the reverted good dmesg has:</p>
<p>uhub3: 8 ports with 8 removable, self powered<br />ugen1.3: <vendor 0x1a40> at usbus1<br />uhub4: <vendor 0x1a40 USB 2.0 Hub MTT, class 9/0, rev 2.00/1.00, addr 3> on usbus1<br />uhub4: MTT enabled<br />uhub4: 7 ports with 7 removable, self powered<br />...<br />ugen1.4: <vendor 0x04d9> at usbus1<br />ukbd0: <vendor 0x04d9 USB Keyboard, class 0/0, rev 1.10/1.01, addr 4> on usbus1<br />kbd2 at ukbd0<br />kbd2: ukbd0, generic (0), config:0x0, flags:0x3d0000<br />uhid0: <vendor 0x04d9 USB Keyboard, class 0/0, rev 1.10/1.01, addr 4> on usbus1<br />...<br />ugen1.5: <Logitech> at usbus1<br />...<br />ums0: <Logitech USB Laser Mouse, class 0/0, rev 2.00/31.00, addr 5> on usbus1<br />ums0: 8 buttons and [XYZT] coordinates ID=0</p> DragonFlyBSD - Bug #2657 (New): Needs acl to migrate our servershttps://bugs.dragonflybsd.org/issues/26572014-03-28T14:17:42ZferneyDamien.Ferney@univ-bpclermont.fr
<p>Hi all, (sry: my first post and i place in submit! sry i resend it )<br />im member of MATHRICE (<a class="external" href="http://www.mathrice.fr">http://www.mathrice.fr</a> & <a class="external" href="http://math.cnrs.fr">http://math.cnrs.fr</a>) a group of System manager in mathematics laboratory in france. <br />We have a lot of computers on 5 cities and would migrate our storage (data, VM disk... ) on 8 redondants DragonFly servers. <br />But we have a lot of services of web hosting for our users and<br /> we use actually fACLs <br />on nfs htdocs directory. <br />So we have migrate a lot of services but we cant replace our linux servers<br />cause we need this functionality. <br />I think that to make hammer an attractive actual file server, it 's a lack to not have fACLs<br />or a support of them on nfs share.</p>
<p>Can you tell me if it could be a priority for you to incorporate this on Dragonfly <br />or if we need to maintain 2 files nfs servers in // ? <br />I think samba need it and it was great to have setfacl / getfacl and support of fACLs on nfs share.</p>
<p>We have discuss this with f. Tigeot and he said me to write this first bugtrackers<br />Thanks a lot (and sorry for my poor english ;-))</p>
<p>Damien Ferney for Mathrice Team</p> DragonFlyBSD - Bug #2652 (New): 189a0ff3761b47 ... ix: Implement MSI-X support locks up Lenovo S1...https://bugs.dragonflybsd.org/issues/26522014-03-03T21:20:17Zdavshao
<p>For a i386 Lenovo S10 Intel Atom n270 netbook, bisection indicates using<br />189a0ff3761b47 ... ix: Implement MSI-X support and enable multiple TX rings<br />locks up the machine on booting at the point:</p>
<p>...<br />md0: invalid primary partition table: no magic<br />Math emulator present<br />hptrr: RocketRAID 17xx/2xxx SATA controller driver v1.2<br />hpt27xx: RocketRAID 27xx controller driver v1.0 (Feb 28 2014 21:38:19)</p>
<p>Attached is a full verbose dmesg from the same machine running with master<br />previous to the above commit. The machine only fully boots with<br />acpi disabled using hint.acpi.0.disabled=1, but even with acpi enabled the<br />lockup with the problematic commit occurs sooner than the normal lockup<br />with acpi enabled. "Normally" on this machine booting with acpi halts at</p>
<p>acpi0.nexus0.root0<br />acpi0: <LENOVO CB-01> [tentative] on motherboard<br />ACPI: All ACPI Tables successfully acquired<br />ACPI FADT: SCI testing interrupt mode ...<br />ACPI FADT: SCI testing level/high<br />IOAPIC: irq 9, gsi 9 edge/high -> level/high</p> DragonFlyBSD - Bug #2565 (New): "ifconfig ix0 up" panichttps://bugs.dragonflybsd.org/issues/25652013-05-27T22:47:05Zltpig402altpig402a@live.com
<p>Just installed a new nic - 10G 82599 dual port.</p>
<p>The system recognizes the ixgbe device and shows up ix0 and ix1.</p>
<p>Whenever a "ifconfig ix0 up" or "ifconfig ix1 up" is issued, the system crashed -</p>
<p>Fatal trap 3: breakpoint instruction fault while in kernel mode<br />cpuid = 0; lapic->id = 00000000<br />instruction pointer = 0x8:ffffffff808be4c3<br />stack pointer = 0x10:fffffffe4eb530e18<br />frame pointer = 0x10:fffffffe4eb530e18<br />code segment = base 0x0, limit 0xfffff, type 0x1b^?
= DPL 0, pres 1, long 1, def32 0, gran 1<br />processor eflags = interrupt enabled, IOPL = 0<br />current process = 866<br />current thread = prio 10 (CRIT)taskqueue_enqueue() at taskqueue_enqueue+0x28 0xffffffff80531cfa<br />ixgbe_init_locked() at ixgbe_init_locked+0x12c6 0xffffffff803a21d2<br />ixgbe_init() at ixgbe_init+0x2f 0xffffffff803a244c<br />ixgbe_ioctl() at ixgbe_ioctl+0x1b 0xffffffff803a2618<br />in6_update_ifa() at in6_update_ifa+0x492 0xffffffff80621189<br />...<br />Stopped at taskqueue_enqueue+0x28: lock addl $0x1, 0x38(%rdi)</p>
<p>db> where</p> DragonFlyBSD - Bug #2416 (New): '.' entry can be removed on mounted nfs filesystemhttps://bugs.dragonflybsd.org/issues/24162012-09-01T09:18:14Zftigeot
<p>I use a shared /usr/pkgsrc/packages on various DragonFlyBSD machines</p>
<p>Just after doing a "rm *" to remove accumulated cruft in packages/All<br />on a client machine, I noticed the "." entry had disappeared.</p>
<p>On the client machine I typed the command on, ls(1) only shows a unique '..'<br />entry in /usr/pkgsrc/packages/All. /usr/pkgsrc/packages doesn't<br />contain a '.' entry anymore. None of its subdirectories do.</p>
<p>On other client machine, the '.' entry has also disappeared from<br />/usr/pkgsrc/packages and all its subdirectories.</p>
<p>The server still contains '.' and '..' entries in the exported directory and<br />all its subdirectories.</p>
<p>Clients and server machines are all running DragonFly-3.1.<br />mount points and all of is</p> DragonFlyBSD - Bug #2138 (New): > 100% CPU usagehttps://bugs.dragonflybsd.org/issues/21382011-09-26T19:20:22Zrobin.carey1
<p>Dear DragonFlyBSD bugs,</p>
<p>I think I have mentioned this problem before, but it appears nothing was<br />done about it.</p>
<p>Sorry if I am creating noise.</p>
<p>The Problem:</p>
<p>When I start a CPU intensive program on leaf.dragonflybsd.org, and then type<br />ps -xguaww, the process<br />is shown as consuming more than 100% of the CPU, e.g. 105%.</p>
<p>In my opinion that should never happen as the maximum value is 100%, and<br />ps(1) should not show<br />a process consuming more than 100%.</p> DragonFlyBSD - Bug #2107 (New): 2.10.1 sata dvd drive issuehttps://bugs.dragonflybsd.org/issues/21072011-07-30T08:23:49Zausppc
<p>Hello. I downloaded a cd image of dragonflybsd 2.10.1 to try and<br />found that it wouldn't load completely. I have an asus m4n68t-m board<br />with a two core am3 cpu and sata dvd drive. When I unplugged the sata<br />drive and plugged in a pata drive dragonfly was able to load<br />successfully.</p>
<p>Regards, Matthew.</p> DragonFlyBSD - Bug #1990 (New): /mnt too large to mounthttps://bugs.dragonflybsd.org/issues/19902011-02-16T02:26:53Zpeur.neu
<p>Hi!</p>
<p>beyond dma stuff i got a crash after several data parallel updates</p>
<p>after reboot /dev/ad1s1d seems to be crashed but it´s not.</p>
<p>i did fsck /dev/ad1s1a booted ok.</p>
<p>hammer still faulty!!!</p>
<p>then i did hammer -f /dev/ad1s1d checkmap<br />the filesystem is on place!!!</p>
<p>then i did mount_hammer -o ro /dev/ad1s1d /mnt<br />mounts fine!!!</p>
<p>BUT doing mount_hammer -o rw /dev/ad1s1d /mnt</p>
<p>UNDO_REDO etc<br />/mnt too large<br />error.</p>
<p>HELP</p>
<p>thansk</p> DragonFlyBSD - Bug #1293 (New): 2.2.1-REL Installer Requesthttps://bugs.dragonflybsd.org/issues/12932009-02-20T11:43:06Zmk
<p>I would like the option (when installing a Hammer FS) to choose if I <br />want to use PFS's or not, and if so, which directories I want to map to <br />PFS's.</p>
<p>Thanks, MK</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 #599 (New): 1.9.0 reproducable panichttps://bugs.dragonflybsd.org/issues/5992007-04-11T10:24:26Zpavalos
<p>Here's a panic I'm getting with some pretty serious network (www) load, then <br />doing a netstat -an:</p>
<p>Unread portion of the kernel message buffer:<br />panic: m_copydata, negative off -1<br />mp_lock = 00000000; cpuid = 0; lapic.id = 00000000<br />boot() called on cpu#0</p>
<p>syncing disks... 5<br />done<br />Uptime: 12d22h0m32s</p>
<p>(kgdb) bt<br />#0 dumpsys () at thread.h:83<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> 0xc01954bb in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:370<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> 0xc01957c0 in panic (fmt=Variable "fmt" is not available.<br />) at /usr/src/sys/kern/kern_shutdown.c:767<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> 0xc01c3a32 in m_copydata (m=0x0, off=0, len=0, cp=0xee9534b0 "\001\001<br />\b\n\006¦*$\035\bͬ") at /usr/src/sys/kern/uipc_mbuf.c:1014<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> 0xc020fc25 in tcp_output (tp=0xdae0c720) <br />at /usr/src/sys/netinet/tcp_output.c:690<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> 0xc02152bf in tcp_timer_persist (xtp=0xdae0c720) <br />at /usr/src/sys/netinet/tcp_timer.c:363<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> 0xc01a6423 in softclock_handler (arg=0xc0386a80) <br />at /usr/src/sys/kern/kern_timeout.c:307<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> 0xc019d037 in lwkt_deschedule_self (td=Variable "td" is not available.<br />) at /usr/src/sys/kern/lwkt_thread.c:207<br />Previous frame inner to this frame (corrupt stack?)</p>
<p>The kernel and vmcore is being uploaded to leaf. The source is from March 28.</p>
<p>--Peter</p>