DragonFlyBSD bugtracker: Issueshttps://bugs.dragonflybsd.org/https://bugs.dragonflybsd.org/favicon.ico?16293952082018-03-04T09:01:41ZDragonFlyBSD bugtracker
Redmine DragonFlyBSD - Bug #3124 (New): DragonFlyBSD 5.0.2 with Hammer2 with UEFI install doesn't boothttps://bugs.dragonflybsd.org/issues/31242018-03-04T09:01:41Zwiesl
<p>DragonFlyBSD 5.0.2 with Hammer2 with UEFI install doesn't boot<br />FATAL: Could not read from the boot medium! System halted.<br />Legacy BIOS install is OK.<br />Looks like that the boot installer isn't run.</p> DragonFlyBSD - Bug #3113 (In Progress): Booting vKernel fails due being out of swap spacehttps://bugs.dragonflybsd.org/issues/31132017-12-17T19:17:50Ztcullen
<p>The step by step directions at <a class="external" href="https://www.dragonflybsd.org/docs/handbook/vkernel/">https://www.dragonflybsd.org/docs/handbook/vkernel/</a> fail because when you attempt to boot the vkernel you never get a shell prompt because the shell is instantly and repeatedly killed due to a never ending stream of "out of swap space" error messages.</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 #2870 (New): Broken text and icons when glamor acceleration is usedhttps://bugs.dragonflybsd.org/issues/28702015-12-19T15:09:16Z375gnu
<p>I'm using DF 4.4.1 with radeonkms, my videocard is radeon 7750. When I disable 2D acceleration in xorg.conf then output is correct, but when I enable it I see garbage, the more applications is run the more garbage I see, letters in gtk2/3 applications are broken, icons are black.</p>
<p>It depends on number of application started, i.e. when I use startx (twm + 3 xterm) and start 1 gtk application then it has only icons broken, qt applications are clean, but I use startxfce then everything is broken.</p>
<p>It does not matter what 3D (mesa) driver is used, radeonsi or llvmpipe.</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 #2735 (New): iwn panics SYSSASSERThttps://bugs.dragonflybsd.org/issues/27352014-11-14T22:04:08Zcnbcneirabustos@gmail.com
<p>iwn driver panics with SYSASSERT error that is described in this link<br /><a class="external" href="http://lists.freebsd.org/pipermail/freebsd-wireless/2013-July/003653.html">http://lists.freebsd.org/pipermail/freebsd-wireless/2013-July/003653.html</a></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 #2499 (In Progress): DRAGONFLY_3_2 lockd not responding correctlyhttps://bugs.dragonflybsd.org/issues/24992013-01-22T08:41:27ZNerzhul
<p>Hello,<br />i must use lockd for concurrent access on a webserver with nfs extended storage. There is some concurrent access and lockd isn't responding correctly.</p>
<p>On the NFSv3 client, timeout appears and console logs:<br />nfs server A.B.C.65:/nfs/fbsd_pkg: lockd not responding<br />nfs server A.B.C.65:/nfs/fbsd_pkg: lockd not responding<br />nfs server A.B.C.65:/nfs/fbsd_pkg: lockd is alive again<br />nfs server A.B.C.65:/nfs/fbsd_pkg: lockd not responding<br />nfs server A.B.C.65:/nfs/fbsd_pkg: lockd not responding<br />nfs server A.B.C.65:/nfs/fbsd_pkg: lockd is alive again<br />nfs server A.B.C.65:/nfs/fbsd_pkg: lockd not responding<br />nfs server A.B.C.65:/nfs/fbsd_pkg: lockd not responding<br />nfs server A.B.C.65:/nfs/fbsd_pkg: lockd is alive again<br />nfs server A.B.C.65:/nfs/fbsd_pkg: lockd not responding<br />nfs server A.B.C.65:/nfs/fbsd_pkg: lockd not responding<br />nfs server A.B.C.65:/nfs/fbsd_pkg: lockd is alive again<br />nfs server A.B.C.65:/nfs/fbsd_pkg: lockd not responding<br />nfs server A.B.C.65:/nfs/fbsd_pkg: lockd not responding<br />nfs server A.B.C.65:/nfs/fbsd_pkg: lockd is alive again<br />nfs server A.B.C.65:/nfs/fbsd_pkg: lockd not responding<br />nfs server A.B.C.65:/nfs/fbsd_pkg: lockd not responding<br />nfs server A.B.C.65:/nfs/fbsd_pkg: lockd is alive again</p>
<p>After "netstat -an -f inet" i see there is a queue on rpc socket</p>
<p>netstat -an -f inet</p>
<p>Active Internet connections (including servers)<br />Proto Recv-Q Send-Q Local Address Foreign Address (state)<br />tcp4 0 0 A.B.C.65.nfsd WebCluster1.977 ESTABLISHED<br />tcp4 0 0 A.B.C.65.nfsd WebCluster1.611 ESTABLISHED<br />tcp4 0 0 localhost.smtp <strong>.* LISTEN<br />tcp4 0 0 *.ssh *.</strong> LISTEN<br />tcp4 0 0 <strong>.1017 *.</strong> CLOSED<br />tcp4 0 0 <strong>.1020 *.</strong> LISTEN<br />tcp4 0 0 <strong>.nfsd *.</strong> LISTEN<br />tcp4 0 0 <strong>.1023 *.</strong> LISTEN<br />tcp4 0 0 <strong>.1022 *.</strong> LISTEN<br />tcp4 0 0 <strong>.sunrpc *.</strong> LISTEN<br />tcp4 0 0 A.B.C.65.nfsd A.B.C.96.811 ESTABLISHED<br />tcp4 0 0 A.B.C.65.nfsd WebCluster1.972 ESTABLISHED<br />tcp4 0 48 A.B.C.65.ssh 129.175.196.190.60067 ESTABLISHED<br />udp4 0 0 <strong>.918 *.</strong> <br />udp4 0 0 A.B.C.65.1028 ntp.u-psud.fr.ntp <br />udp4 456 0 <strong>.1017 *.</strong> <br />udp4 18656 0 <strong>.1018 *.</strong> <br />udp4 0 0 <strong>.nfsd *.</strong> <br />udp4 0 0 <strong>.1021 *.</strong> <br />udp4 0 0 <strong>.1020 *.</strong> <br />udp4 0 0 <strong>.1022 *.</strong> <br />udp4 0 0 <strong>.sunrpc *.</strong></p>
<p>When i see that, i make tcpdump -nni em0 to see what's happening:</p>
<p>22:12:42.781597 IP 10.117.100.95.961 > 10.117.100.65.1017: UDP, length 212<br />22:12:48.801935 IP 10.117.100.95.961 > 10.117.100.65.1017: UDP, length 212<br />22:12:54.669917 IP 10.117.100.95.961 > 10.117.100.65.1017: UDP, length 212<br />22:13:00.148965 IP 10.117.100.95.961 > 10.117.100.65.1017: UDP, length 212</p>
<p>After a little time, lockd respond to all request, but many failed because of timeout</p>
<p>On the dragonflyBSD server i can see this in /var/log/messages</p>
<p>Jan 21 22:14:19 webfiler1 rpc.lockd: duplicate lock from WebCluster1.srv.<br />Jan 21 22:14:19 webfiler1 last message repeated 3 times<br />Jan 21 22:14:19 webfiler1 rpc.lockd: no matching entry for WebCluster1.srv.<br />Jan 21 22:14:29 webfiler1 dntpd<sup><a href="#fn571">571</a></sup>: issuing offset adjustment: 0.026637s<br />Jan 21 22:14:44 webfiler1 rpc.lockd: rpc to statd failed: RPC: Timed out<br />Jan 21 22:14:44 webfiler1 rpc.lockd: duplicate lock from WebCluster1.srv.<br />Jan 21 22:14:44 webfiler1 last message repeated 3 times<br />Jan 21 22:14:44 webfiler1 rpc.lockd: no matching entry for WebCluster1.srv.</p>
<p>I think there is a problem on DragonFlyBSD which queue many lockd requests.</p> DragonFlyBSD - Bug #2495 (New): DFBSD v3.3.0.960.g553fe7 - ocnt != 0" failed in prop_object_releasehttps://bugs.dragonflybsd.org/issues/24952013-01-21T15:41:55Ztuxillo
<p>Hi,</p>
<p>While trying to install recent master to a couple of striped disks using LVM, I get the following:</p>
<pre>
dm_target_stripe: Successfully initialized
dm_target_linear: Successfully initialized
disk scheduler: set policy of mapper/main-lv_swap to noop
disk scheduler: set policy of mapper/main-lv_root to noop
panic: assertion "ocnt != 0" failed in prop_object_release at /usr/src/sys/libprop/prop_object.c:1085
Backtrace:
#0 _get_mycpu () at ./machine/thread.h:69
#1 md_dumpsys (di=<optimized out>) at /usr/src/sys/platform/pc64/x86_64/dump_machdep.c:265
#2 0xffffffff804f3bb2 in dumpsys () at /usr/src/sys/kern/kern_shutdown.c:913
#3 0xffffffff802a77ac in db_fncall (dummy1=<optimized out>, dummy2=<optimized out>, dummy3=<optimized out>, dummy4=<optimized out>)
at /usr/src/sys/ddb/db_command.c:539
#4 0xffffffff802a7c7f in db_command (aux_cmd_tablep_end=0xffffffff809e1bb8, aux_cmd_tablep=0xffffffff809e1b80,
cmd_table=<optimized out>, last_cmdp=<optimized out>) at /usr/src/sys/ddb/db_command.c:401
#5 db_command_loop () at /usr/src/sys/ddb/db_command.c:467
#6 0xffffffff802aab41 in db_trap (type=<optimized out>, code=<optimized out>) at /usr/src/sys/ddb/db_trap.c:71
#7 0xffffffff808ac758 in kdb_trap (type=<optimized out>, code=<optimized out>, regs=<optimized out>)
at /usr/src/sys/platform/pc64/x86_64/db_interface.c:174
#8 0xffffffff808b1a10 in trap_fatal (frame=0xffffffe0556cb2f8, eva=<optimized out>) at /usr/src/sys/platform/pc64/x86_64/trap.c:1024
#9 0xffffffff808b2389 in trap (frame=0xffffffe0556cb2f8) at /usr/src/sys/platform/pc64/x86_64/trap.c:754
#10 0xffffffff8089c36f in calltrap () at /usr/src/sys/platform/pc64/x86_64/exception.S:188
#11 0xffffffff808ac549 in db_read_bytes (addr=282584257676679, size=8, data=0xffffffe0556cb3d8 "")
at /usr/src/sys/platform/pc64/x86_64/db_interface.c:240
#12 0xffffffff802a70ad in db_get_value (addr=282584257676679, size=8, is_signed=0) at /usr/src/sys/ddb/db_access.c:58
#13 0xffffffff808ad1e5 in db_nextframe (ip=<optimized out>, fp=<optimized out>) at /usr/src/sys/platform/pc64/x86_64/db_trace.c:234
#14 db_stack_trace_cmd (addr=<optimized out>, have_addr=<optimized out>, count=<optimized out>, modif=<optimized out>)
at /usr/src/sys/platform/pc64/x86_64/db_trace.c:440
#15 0xffffffff808ad3a7 in print_backtrace (count=1433187288) at /usr/src/sys/platform/pc64/x86_64/db_trace.c:452
#16 0xffffffff804f4498 in panic (fmt=0xffffffff808f6540 "assertion \"%s\" failed in %s at %s:%u")
at /usr/src/sys/kern/kern_shutdown.c:812
#17 0xffffffff80766e47 in prop_object_release (obj=0xffffffe003410680) at /usr/src/sys/libprop/prop_object.c:1085
#18 0xffffffff804f9305 in udev_event_externalize (ev=<optimized out>) at /usr/src/sys/kern/kern_udev.c:496
#19 udev_dev_read (ap=<optimized out>) at /usr/src/sys/kern/kern_udev.c:745
#20 0xffffffff804d3aa7 in dev_dread (dev=0xffffffe03204ade0, uio=<optimized out>, ioflag=<optimized out>)
at /usr/src/sys/kern/kern_device.c:192
#21 0xffffffff806d5017 in devfs_fo_read (fp=0xffffffe021529f58, uio=0xffffffe0556cb998, cred=<optimized out>, flags=<optimized out>)
at /usr/src/sys/vfs/devfs/devfs_vnops.c:1176
#22 0xffffffff8052ab51 in fo_read (cred=<optimized out>, uio=<optimized out>, fp=<optimized out>, flags=<optimized out>)
at /usr/src/sys/sys/file2.h:57
#23 dofileread (res=<optimized out>, flags=<optimized out>, auio=<optimized out>, fp=<optimized out>, fd=<optimized out>)
at /usr/src/sys/kern/sys_generic.c:305
#24 kern_preadv (fd=3, auio=0xffffffe0556cb998, flags=0, res=<optimized out>) at /usr/src/sys/kern/sys_generic.c:269
#25 0xffffffff8052ad17 in sys_read (uap=0x0) at /usr/src/sys/kern/sys_generic.c:145
#26 0xffffffff808b2a2c in syscall2 (frame=0xffffffe0556cbab8) at /usr/src/sys/platform/pc64/x86_64/trap.c:1238
#27 0xffffffff8089c5bb in Xfast_syscall () at /usr/src/sys/platform/pc64/x86_64/exception.S:323
#28 0x000000000000002b in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
</pre><br />Core dumps available at: leaf:~tuxillo/*_ocount.1
<p>Cheers,<br />Antonio Huete</p> DragonFlyBSD - Bug #2423 (New): After multiple panics/locks, hitting KKASSERT in hammer_init_cursorhttps://bugs.dragonflybsd.org/issues/24232012-09-17T17:12:40Zrumcic
<p>After quite a few locks (machine stopped responding, nothing on serial console, unable to panic the machine), the hammer FS (v6) got a corrupted(?) UNDO.</p>
<p>Booting the latest snapshot and mounting with ro,noatime it looked as if it was able to rerun the UNDO/FIFO. But trying to mount the "clean" FS result in triping over a KKASSERT (error == 0 at hammer_cursor.c:202)</p> DragonFlyBSD - Bug #2141 (New): loader and/or documentation brokenhttps://bugs.dragonflybsd.org/issues/21412011-10-09T14:15:29Zsjg
<p>For example,</p>
<pre><code>The ehci driver is automatically loaded upon boot. To disable this<br /> behavior temporarily, the ehci_load variable can be unset at the loader<br /> prompt (see loader(8)). To disable it permanently, the<br /> hint.ehci.0.disabled tunable can be set to 1 in /boot/loader.conf.</code></pre>
<p>But when operating from the loader prompt the ehci_load variable has no effect <br />at all, it seems to only be checked from the menu, which is useless if you are <br />operating from the prompt.</p>
<p>This is confusing at best, but I am leaning more towards steaming pile. The <br />loader or the documentation needs to be reworked.</p> DragonFlyBSD - Bug #2117 (New): ACPI and/or bce(4) problem with 2.11.0.673.g0d557 on HP DL380 G6https://bugs.dragonflybsd.org/issues/21172011-08-18T16:40:24Zpauska
<p>I got a standard HP Proliant DL380 G6 server with a built-in quad broadcom NIC.</p>
<p>2.10 didn't have the updated bcn drivers, so I installed the 2.11.0.673 snapshot <br />to get connectivity.</p>
<p>First, the ACPI error (also present in 2.10):<br />[ACPI Debug] String [0xB] "_TMP Method"</p>
<p>This message repeats 60 times every 10 minutes. I have no idea what it means, <br />googling for it only points me at a NetBSD discussion from 2009.</p>
<p>Secondly, the bcn driver (or perhaps atapci?):<br />interrupt total rate<br />sio2 0 0<br />sio0 0 0<br />acpi0 12125 0<br />bce0 1547359 26<br />bce1/atapci0 2293301893 39875 <-- ouch?<br />bce2 0 0<br />bce3 0 0<br />uhci0/ehci0 1 0<br />uhci2/uhci4 34 0<br />uhci1/uhci3 44 0<br />ciss0 267683 4<br />swi_siopoll 0 0<br />swi_cambio 267762 4<br />swi_vm 0 0<br />swi_taskq/swi_mp_taskq 25 0<br />Total 2295396926 39911</p>
<p>The weird part is that I dont have any ATA devices in use, there's only a CD-<br />rom. bcn1 isnt configured or marked up, only bcn0 is in use.</p>
<p>The deal breaker here is that I can't do anything disk intensive without getting <br />a crash. I tried updating pkgsrc yesterday, and here are two examples:</p>
[snip]
* [new branch] dragonfly-2010Q3 -> origin/dragonfly-2010Q3
<ul>
<li>Signal 10<br />Stop in /usr.<br />[snip]</li>
</ul>
[snip]
* [new branch] master -> origin/master<br />Bus error (core dumped)
<ul>
<li>Error code 1<br />Stop in /usr.<br />[snip]</li>
</ul>
<p>While getting these errors messages like this flooded dmesg:<br />intr 16 at 40001/40000 hz, livelocked limit engaged!<br />[ACPI Debug] String [0xB] "_TMP Method" <br />intr 16 at 882/20000 hz, livelock removed<br />intr 16 at 40001/40000 hz, livelocked limit engaged!<br />pid 34805 (git), uid 0: exited on signal 10 (core dumped)<br />intr 16 at 3225/20000 hz, livelock removed<br />intr 16 at 40001/40000 hz, livelocked limit engaged!<br />intr 16 at 751/20000 hz, livelock removed<br />intr 16 at 40001/40000 hz, livelocked limit engaged!<br />intr 16 at 765/20000 hz, livelock removed<br />intr 16 at 40001/40000 hz, livelocked limit engaged!<br />intr 16 at 795/20000 hz, livelock removed<br />[ACPI Debug] String [0xB] "_TMP Method"</p>
<p>I'm not familiar with debugging this, so please let me know if you need more <br />info. I can also put the server in the DMZ and give a developer SSH access if <br />needed.</p> DragonFlyBSD - Bug #1921 (In Progress): we miss mlockallhttps://bugs.dragonflybsd.org/issues/19212010-11-24T16:19:21Zalexh
<p>We don't have the mlockall/munlockall syscalls as documented in [1]. We have at <br />least one tool in base that would benefit from it: cryptsetup. Hopefully someone <br />more familiar with the VM system can implement it without much effort as we <br />already have mlock/munlock.</p>
<p>Cheers,<br />Alex Hornung</p>
<p>[1]: <a class="external" href="http://opengroup.org/onlinepubs/007908799/xsh/mlockall.html">http://opengroup.org/onlinepubs/007908799/xsh/mlockall.html</a></p> DragonFlyBSD - Bug #1198 (New): DDB loops panic in db_read_byteshttps://bugs.dragonflybsd.org/issues/11982009-01-05T22:50:04Zcorecode
<p>I have some panic which I can't debug because there is a flurry of panic<br />messages on my screen. The offender is:</p>
<p>sys/platform/pc32/i386/db_interface.c:208</p>
<p>I see that ddb uses longjmp, but seems that doesn't work here somehow.</p> 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>