DragonFlyBSD bugtracker: Issueshttps://bugs.dragonflybsd.org/https://bugs.dragonflybsd.org/favicon.ico?16293952082009-10-23T17:28:21ZDragonFlyBSD bugtracker
Redmine DragonFlyBSD - Bug #1584 (In Progress): can't use ssh from jail: debug1: read_passphrase: can't o...https://bugs.dragonflybsd.org/issues/15842009-10-23T17:28:21Zcorecode
<p>When running ssh from a jail, I get:</p>
<p>debug1: read_passphrase: can't open /dev/tty: Device busy</p>
<p>can also repeat this:</p>
<ol>
<li>cat `tty`<br />cat: /dev/pts/4: Device busy</li>
</ol>
<p>outside:<br />% cat `tty`<br />^C</p>
<p>cheers<br /> simon</p> DragonFlyBSD - Bug #1583 (In Progress): panic: assertion: cursor->trans->sync_lock_refs > 0 in ha...https://bugs.dragonflybsd.org/issues/15832009-10-23T01:46:46Zcorecode
<p>Happened when I started 8 mirror-stream at the same time.</p>
<p>(kgdb) bt<br />#0 _get_mycpu () at ./machine/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> dumpsys () at /usr/src/sys/kern/kern_shutdown.c:657<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> 0xc019ba89 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:378<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> 0xc019bdf5 in panic (fmt=0xc032b90c "assertion: %s in %s")<br /> at /usr/src/sys/kern/kern_shutdown.c:813<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> 0xc0299c7f in hammer_recover_cursor (cursor=0xe84826b4)<br /> at /usr/src/sys/vfs/hammer/hammer_cursor.c:591<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> 0xc02a5139 in hammer_ioc_mirror_write (trans=0xe8482a50, <br />ip=0xea5ce6d0, mirror=0xe51a6f88)<br /> at /usr/src/sys/vfs/hammer/hammer_mirror.c:465<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> 0xc02a37b8 in hammer_ioctl (ip=0xea5ce6d0, com=3234097160, <br />data=0xe51a6f88 "", fflag=1,<br /> cred=0xc6787308) at /usr/src/sys/vfs/hammer/hammer_ioctl.c:142<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> 0xc02b65e4 in hammer_vop_ioctl (ap=0xe8482aac) at <br />/usr/src/sys/vfs/hammer/hammer_vnops.c:2305<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> 0xc0203107 in vop_ioctl (ops=0xe4795b70, vp=0xea5f22e8, <br />command=3234097160,<br /> data=0xe51a6f88 "", fflag=1, cred=0xc6787308, msg=0xe8482cf0)<br /> at /usr/src/sys/kern/vfs_vopops.c:389<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> 0xc0202b75 in vn_ioctl (fp=0xe4585910, com=3234097160, <br />data=0xe51a6f88 "", ucred=0xc6787308,<br /> msg=0xe8482cf0) at /usr/src/sys/kern/vfs_vnops.c:938<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> 0xc01c3c1b in fo_ioctl (fd=3, com=3234097160,<br /> uspc_data=0xbfbff954 <Address 0xbfbff954 out of bounds>, map=0x0, <br />msg=0xe8482cf0)<br /> at /usr/src/sys/sys/file2.h:88<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> mapped_ioctl (fd=3, com=3234097160, uspc_data=0xbfbff954 <Address <br />0xbfbff954 out of bounds>,<br /> map=0x0, msg=0xe8482cf0) at /usr/src/sys/kern/sys_generic.c:697<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> 0xc01c3ccb in sys_ioctl (uap=0xe8482cf0) at <br />/usr/src/sys/kern/sys_generic.c:521<br /><a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: Buildworld error/panic (Closed)" href="https://bugs.dragonflybsd.org/issues/13">#13</a> 0xc03088ea in syscall2 (frame=0xe8482d40) at <br />/usr/src/sys/platform/pc32/i386/trap.c:1339<br /><a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: zombie processes waiting for a lock, smth to worry about? (Closed)" href="https://bugs.dragonflybsd.org/issues/14">#14</a> 0xc02f3356 in Xint0x80_syscall () at <br />/usr/src/sys/platform/pc32/i386/exception.s:876</p>
<p>kernel+core nr. 13 on leaf:~corecode/crash</p>
<p>cheers<br /> simon</p> DragonFlyBSD - Bug #1556 (New): many processes stuck in "hmrrcm", system unusablehttps://bugs.dragonflybsd.org/issues/15562009-10-04T01:19:29Zcorecode
<p>On chlamydia I have many processes stuck in "hmrrcm", making the system <br />unusable - can't open new shells, etc. After a minute or two the <br />situation seems to improve again.</p> DragonFlyBSD - Bug #1547 (In Progress): disklabel64 automatic sizinghttps://bugs.dragonflybsd.org/issues/15472009-10-02T20:18:02Zcorecode
<p>disklabel64 is a prime example for unintuitive behavior:</p>
<ul>
<li>it requires an arbitrary 4KB aligment on sizes and offset</li>
<li>size aligments seem to be enforced directly, but offset alignments are <br />not. offsets just show up as "ILLEGAL" when re-editing the label. no <br />complaint before</li>
<li>automatic sizing using "*" does not work:</li>
</ul>
<p>d: * * HAMMER</p>
<p>but then:<br />partition d: size out of bounds (4825292800)</p>
<p>the size is completely off, roughly by a factor of 10(!)</p>
<p>I had to do:</p>
<p>d: 4 * HAMMER</p>
<p>and then re-edit to make it read</p>
<p>d: * 4712200 HAMMER</p>
<ul>
<li>there is no way to change the display block size</li>
<li>there is no way to specify sector counts or byte counts in size/offset</li>
</ul> 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 #1528 (In Progress): ktrace does not show proper return values for pipe(2)https://bugs.dragonflybsd.org/issues/15282009-09-24T15:58:42Zcorecode
<p>When ktracing a pipe syscall, the output is:</p>
<p>57705 a.out CALL pipe<br />57705 a.out RET pipe 3</p>
<p>However, the return value of pipe is 0, and the returned value for the <br />file descs is {3, 4}.</p> DragonFlyBSD - Bug #1475 (In Progress): kernel blocks with low memory and syscons setting a high ...https://bugs.dragonflybsd.org/issues/14752009-09-01T03:06:17Zcorecode
<p>I just booted with hw.physmem=32m. I have my allscreens_flags set to -h <br />4700 MODE_279. When processing the allscreens_flags in rc.d, the system <br />blocks (not hangs) while booting, ^T says "no controlling terminal". No <br />mode change occured. Same happened with 48m, just with a mode change, <br />so I suspect it to have worked for one screen but then not for another.</p> DragonFlyBSD - Bug #1474 (New): ithread 1 unexpectedly rescheduledhttps://bugs.dragonflybsd.org/issues/14742009-09-01T03:02:23Zcorecode
<p>Just had a hang during high swap activity. I kept pressing ^T to see <br />what is happening, suddenly the kernel said "ithread 1 unexpectedly <br />rescheduled". SMP 4-way system.</p> DragonFlyBSD - Bug #1469 (In Progress): Hammer history security concernhttps://bugs.dragonflybsd.org/issues/14692009-08-28T17:59:03Zcorecode
<p>Hammer history mounts allow access to deleted files.</p>
<p>This can be an issue if you realized that this data should not have been <br />available in the first place.</p>
<p>An alternate scenario is that group membership changed, and you don't <br />want the new group members to have access to past data.</p>
<p>I think we should address this in some sort in the release. One way is <br />to only allow the owner to access the snapshot, and ignore group/other <br />permissions on snapshots. This is probably very inconvenient, <br />especially for root owned system directories.</p>
<p>Another way would be to somehow combine current and past owner/flags, <br />but this is probably hard to reason about.</p>
<p>cheers<br /> simon</p> DragonFlyBSD - Bug #1442 (New): blocking SIGSEGV and triggering a segment violation produces an a...https://bugs.dragonflybsd.org/issues/14422009-07-28T20:05:09Zcorecode
<p>If a process blocks (or ignores?) SIGSEGV (or SIGFPE, SIGILL, SIGBUS, etc.) and<br />then triggers the associated signal without having a handler installed, the<br />process/thread will be stuck on the triggering instruction without any hope.</p>
<p>I think the kernel should detect such a situation (i.e. trap leading to<br />blocked/ignored signal without handler) and should kill the process.</p> DragonFlyBSD - Bug #1440 (New): ptrace/gdb doesn't work after process blocks SIGTRAPhttps://bugs.dragonflybsd.org/issues/14402009-07-28T20:01:56Zcorecode
<p>If a process blocks SIGTRAP, an attached debugger will not be able to break<br />again (same is true for SIGINT, for instance).</p>
<p>We should change the behavior so that the debugger will be able to see this<br />signal, or to change how a ptrace'd process gets suspended on trap exceptions.</p> DragonFlyBSD - Bug #1307 (In Progress): hammer tid -2 shows unexpected resulthttps://bugs.dragonflybsd.org/issues/13072009-03-06T21:58:25Zcorecode
<p>When using the HAMMER tid -2, 0xfffffffffffffffe, HAMMER will actually return<br />the second oldest file, not the latest nor the oldest. -1, -3, -4, etc. all<br />show the newest.</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 #731 (New): system freeze on "slice too large"https://bugs.dragonflybsd.org/issues/7312007-07-15T20:11:05Zcorecode
<p>hey,</p>
<p>i've now had twice a nasty freeze (kind of) with something like this (hand transcribed):</p>
<p><code>dscheck(#ad/0x20021): slice too large 2/2</code><br />..</p>
<p>then vinum tells me that it put "build" down and continues:</p>
<p>fatal: build.p0.s0 read error, offset 33831591936 for 4096 bytes<br />build.p0.s0: user buffer offset 10209280000 for 4096 bytes</p>
<p>(more slice too large follow)</p>
<p>then, the namecache does</p>
<p>blocked on 0xd4fb7b58 "corecode"</p>
<p>and repeats it every 30 seconds or so. system is unoperable at this point.</p>
<p>breaking to the debugger works, but dumpsys does not work:</p>
<pre>
dumping to dev #ad/0x20023, blockno 2130432
dump failed, reason: area improper
</pre>
<p>i'm running:<br /><pre>
DragonFly sweatshorts.home.corecode.ath.cx 1.9.0-DEVELOPMENT DragonFly 1.9.0-DEVELOPMENT #14: Sun Jun 17 11:03:58 CEST 2007 corecode@sweatshorts.home.corecode.ath.cx:/usr/build/obj/usr/build/src/sys/SWEATSHORTS i386
</pre></p>
<p>i've attached relevant outputs.</p>
<p>thanks,<br /> simon</p> DragonFlyBSD - Bug #341 (New): Vinum erroneously repors devices as busyhttps://bugs.dragonflybsd.org/issues/3412006-10-05T22:58:36Zcorecode
<p>Most of the time vinum reports devices as busy when they are not. At least I<br />can't find a different way than to use stop -f.</p>