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 #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 #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 #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 #604 (In Progress): 1.8.1-RELEASE - clock runs fast on mainboard ASUS P5A-Bhttps://bugs.dragonflybsd.org/issues/6042007-04-18T18:55:03Zyeti
<p>After a fresh install of 1.8.1-RELEASE on a system with ASUS P5A-B<br />mainboard (ALI chipset), the clock runs twice as fast as normal.</p>
<p>Booting with ACPI disabled solved this problem.</p>
<p>The clock problem on some ATI chipsets was a problem in Linux some<br />kernels ago too. The solution was triggered by clock=pit as bootarg if I<br />remember right... maybe having a peek into Linux's code helps.</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> DragonFlyBSD - Bug #570 (Feedback): 1.8.x: ACPI problemshttps://bugs.dragonflybsd.org/issues/5702007-03-03T11:46:01Zqhwt+dfly
<p>So if you enable ACPI and boot, it won't respond to keyboard no matter<br />whether you choose to boot into single- or multi-user mode?</p>
<p>So ... your keyboard does not work when you boot straight into the<br />single user mode, whether with or without ACPI driver enabled, right?<br />If not, I have no idea what this part really means:<br /> > But If I boot to non-ACPI-mode, everything works<br /> > just fine, but I can't get to sigle user mode, because prompt freezes<br /> > there too...</p>
<p>If the message buffer(which dmesg command shows you) survives across<br />reboot, I'd like to look at it after you boot with ACPI driver enabled<br />and booted with `boot -v' from the boot loader prompt (did I ask if<br />keyboard works when you go into the boot loader prompt?).</p>
<p>Cheers.</p>