DragonFlyBSD bugtracker: Issueshttps://bugs.dragonflybsd.org/https://bugs.dragonflybsd.org/favicon.ico?16293952082019-09-18T13:28:07ZDragonFlyBSD bugtracker
Redmine DragonFlyBSD - Bug #3205 (Feedback): Go compiler net test failinghttps://bugs.dragonflybsd.org/issues/32052019-09-18T13:28:07ZAnonymous
<p>A recent commit appears to have broken the net test for the Go compiler:<br /><a class="external" href="https://build.golang.org/log/58be31cfd1a92ba9582fdf33e01f79e03184e59b">https://build.golang.org/log/58be31cfd1a92ba9582fdf33e01f79e03184e59b</a></p>
<p>This was working on commit be02f354 and started failing when I upgraded to b7d3e1.</p> DragonFlyBSD - Bug #2037 (Feedback): Panic Bad link elm while building packageshttps://bugs.dragonflybsd.org/issues/20372011-03-29T23:35:40Zftigeot
<p>This panic occured while building packages on a 4-core x86_64 machine.</p>
<p>Complete core dump is available here:<br /><a class="external" href="http://dl.zefyris.com/crash.0/">http://dl.zefyris.com/crash.0/</a></p> DragonFlyBSD - Bug #1831 (Feedback): HAMMER "malloc limit exceeded" panichttps://bugs.dragonflybsd.org/issues/18312010-09-11T23:42:36Zeocallaghan
<p>I was able to reproduce with a hammer equivalent of issue1726 with the following<br />test case from vsrinivas in issue1726:</p>
<pre>
<code class="c syntaxhl" data-language="c"><span class="cp">#include</span> <span class="cpf"><unistd.h></span><span class="cp">
#include</span> <span class="cpf"><stdlib.h></span><span class="cp">
#include</span> <span class="cpf"><stdio.h></span><span class="cp">
</span>
<span class="n">main</span><span class="p">()</span> <span class="p">{</span>
<span class="kt">int</span> <span class="n">i</span><span class="p">;</span>
<span class="kt">char</span> <span class="n">id</span><span class="p">[</span><span class="mi">320</span><span class="p">]</span> <span class="o">=</span> <span class="p">{};</span>
<span class="k">for</span> <span class="p">(</span><span class="n">i</span> <span class="o">=</span> <span class="mi">0</span><span class="p">;</span> <span class="n">i</span> <span class="o"><</span> <span class="mi">10000000</span><span class="p">;</span> <span class="n">i</span><span class="o">++</span><span class="p">)</span> <span class="p">{</span>
<span class="n">sprintf</span><span class="p">(</span><span class="n">id</span><span class="p">,</span> <span class="s">"%09d"</span><span class="p">,</span> <span class="n">i</span><span class="p">);</span>
<span class="n">link</span><span class="p">(</span><span class="s">"sin.c"</span><span class="p">,</span> <span class="n">id</span><span class="p">);</span>
<span class="p">}</span>
<span class="k">return</span> <span class="mi">0</span><span class="p">;</span>
<span class="p">}</span>
</code><br /></pre>
<p>----<br /><pre>
(kgdb) bt
#0 _get_mycpu (di=0xc06d4ca0) at ./machine/thread.h:83
#1 md_dumpsys (di=0xc06d4ca0)
at /usr/src/sys/platform/pc32/i386/dump_machdep.c:263
#2 0xc0304d15 in dumpsys () at /usr/src/sys/kern/kern_shutdown.c:880
#3 0xc03052d5 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:387
#4 0xc030559e in panic (fmt=0xc05bb41b "%s: malloc limit exceeded")
at /usr/src/sys/kern/kern_shutdown.c:786
#5 0xc03032bb in kmalloc (size=25, type=0xc1d8f590, flags=258)
at /usr/src/sys/kern/kern_slaballoc.c:503
#6 0xc04aa5a3 in hammer_alloc_mem_record (ip=0xcb803d50, data_len=25)
at /usr/src/sys/vfs/hammer/hammer_object.c:280
#7 0xc04aa91f in hammer_ip_add_directory (trans=0xce350ad4,
dip=0xcb803d50, name=0xd3cdb1d0 "000452457", bytes=9, ip=0xce31df50)
at /usr/src/sys/vfs/hammer/hammer_object.c:666
#8 0xc04bbf8a in hammer_vop_nlink (ap=0xce350b2c)
at /usr/src/sys/vfs/hammer/hammer_vnops.c:1388
#9 0xc036cc1f in vop_nlink_ap (ap=0xce350b2c)
at /usr/src/sys/kern/vfs_vopops.c:1978
#10 0xc03717ca in null_nlink (ap=0xce350b2c)
at /usr/src/sys/vfs/nullfs/null_vnops.c:164
#11 0xc036d465 in vop_nlink (ops=0xcdbbe030, nch=0xce350c48,
dvp=0xce0913e8, vp=0xce2f04e8, cred=0xcdef1738)
at /usr/src/sys/kern/vfs_vopops.c:1397
---Type <return> to continue, or q <return> to quit---
---Type <return> to continue, or q <return> to quit---#12 0xc0365496 in
kern_link (nd=0xce350c80, linknd=0xce350c48)
at /usr/src/sys/kern/vfs_syscalls.c:2320
#13 0xc036ad49 in sys_link (uap=0xce350cf0)
at /usr/src/sys/kern/vfs_syscalls.c:2345
#14 0xc055f6b3 in syscall2 (frame=0xce350d40)
at /usr/src/sys/platform/pc32/i386/trap.c:1310
#15 0xc0547fb6 in Xint0x80_syscall ()
at /usr/src/sys/platform/pc32/i386/exception.s:876
#16 0x0000001f in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(kgdb)
</pre></p>
<p>Dump on my leaf account;<br /><a class="external" href="http://leaf.dragonflybsd.org/~evocallaghan/hammer_vfs_panic.7z">http://leaf.dragonflybsd.org/~evocallaghan/hammer_vfs_panic.7z</a></p>
<p>Cheers,<br />Edward.</p> DragonFlyBSD - Bug #1593 (Feedback): panic: assertion: ccb == ap->ap_err_ccb in ahci_put_err_ccbhttps://bugs.dragonflybsd.org/issues/15932009-11-01T01:37:40Zftigeot
<p>This panic occurs when trying to read a defective SATA hard drive with ahci.</p>
<p>On the same machine, when using the nata disk driver (by disabling ahci in<br />BIOS), the disk is still unreadable with READ_DMA errors but the kernel does<br />not panic.</p>
<p>System is DragonFly 2.4.1 running on a Core 2 Duo machine with an Intel ICH9<br />SATA chipset.</p>
<p>The mainboard is a Supermicro X7SBL-LN2:<br /><a class="external" href="http://www.supermicro.com/products/motherboard/Xeon3000/3200/X7SBL-LN2.cfm">http://www.supermicro.com/products/motherboard/Xeon3000/3200/X7SBL-LN2.cfm</a></p>
<p>gzipped kernel and core file are available here:<br /><a class="external" href="http://www.wolfpond.org/crash.dfly/">http://www.wolfpond.org/crash.dfly/</a></p> DragonFlyBSD - Bug #1587 (Feedback): can't gdb across forkhttps://bugs.dragonflybsd.org/issues/15872009-10-25T23:56:18Zcorecode
<p>When the debugged process performs a fork(), gdb/ptrace won't notice and <br />will not be able to remove breakpoints in the new child. When the child <br />then hits a breakpoint, it will receive a SIGTRAP and dump core.</p>
<p>gdb needs to be aware of forks, so that it will be able to remove the <br />breakpoints in the child.</p>
<p>Test: gdb sh and break stalloc.</p> DragonFlyBSD - Bug #1579 (Feedback): dfly 2.4.1 does not like HP DL360G4p and Smart Array 6400 wi...https://bugs.dragonflybsd.org/issues/15792009-10-19T20:57:34Ztomaz.borstnar
<p>Hello!</p>
<pre><code>I have a HP DL360G4p machine with 5 gigs of RAM, internal SATA disk and HP SmartArray 6400 controller (2 channels) with <br />6400EM card (additional 2 channels attached as daughter card) with MSA20 enclosure with SATA disks - configured as 4 <br />volumes. Install went fine, but dmesg prints some errors (full dmesg output attached), but here are relevant parts:</code></pre>
<p>bge0: <Broadcom BCM5704C Dual Gigabit Ethernet> mem 0xfddf0000-0xfddfffff irq 7 at device 2.0 on pci2<br />bge0: CHIP ID 0x21000000; ASIC REV 0x02; CHIP REV 0x21; PCI-X<br />alignment check failed<br />miibus0: <MII bus> on bge0<br />brgphy0: <BCM5704 10/100/1000baseT PHY> on miibus0<br />brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto<br />bge0: MAC address: 00:15:60:0f:b0:e8<br />bge1: <Broadcom BCM5704C Dual Gigabit Ethernet> mem 0xfdde0000-0xfddeffff irq 7 at device 2.1 on pci2<br />bge1: CHIP ID 0x21000000; ASIC REV 0x02; CHIP REV 0x21; PCI-X<br />alignment check failed<br />alignment check failed<br />miibus1: <MII bus> on bge1<br />brgphy1: <BCM5704 10/100/1000baseT PHY> on miibus1<br />brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto<br />bge1: MAC address: 00:15:60:0f:b0:e7</p>
<p>And...</p>
<p>CAM: Configuring 5 busses<br />CAM: finished configuring all busses (-2 left)<br /><b>WARNING</b> waiting for the following device to finish configuring:<br /> xpt: func=0xc015423d arg=0<br /><b>WARNING</b> waiting for the following device to finish configuring:<br /> xpt: func=0xc015423d arg=0<br /><b>WARNING</b> waiting for the following device to finish configuring:<br /> xpt: func=0xc015423d arg=0<br /><b>WARNING</b> waiting for the following device to finish configuring:<br /> xpt: func=0xc015423d arg=0<br /><b>WARNING</b> waiting for the following device to finish configuring:<br /> xpt: func=0xc015423d arg=0<br />Giving up, interrupt routing is probably hosed</p>
<p>But ciss is seen:<br />ciss0: <HP Smart Array 6400> port 0x5000-0x50ff mem 0xfdff0000-0xfdff1fff irq 7 at device 4.0 on pci11<br />ciss1: <HP Smart Array 6400 EM> port 0x5400-0x54ff mem 0xfdf70000-0xfdf71fff irq 5 at device 5.0 on pci11</p>
<p>Anything I can help to test?</p>
<p>Tomaž</p> DragonFlyBSD - Bug #1428 (Feedback): POSIX.1e implementation is too oldhttps://bugs.dragonflybsd.org/issues/14282009-07-17T02:08:53Zhasso
<p>Our posix1e(3) implementation is too old and not compatible with any <br />recent enough piece of software.</p> DragonFlyBSD - Bug #1411 (Feedback): Burning doesn't work with ahci(4)https://bugs.dragonflybsd.org/issues/14112009-06-28T02:21:19Zhasso
<p>Burning (I have only DVD-RW to test with, though) doesn't work with SATA <br />burner attaching to ahci(4). Nata still works fine. Verbose cdrecord log for <br />simple blank process is available at <br /><a class="external" href="http://leaf.dragonflybsd.org/~hasso/ahci-cdrecord-verbose-blank.log">http://leaf.dragonflybsd.org/~hasso/ahci-cdrecord-verbose-blank.log</a></p> DragonFlyBSD - Bug #1397 (Feedback): jobs -l output inconsistency when called from scripthttps://bugs.dragonflybsd.org/issues/13972009-06-08T00:49:49ZAnonymous
<p>Salute.</p>
<p>The jobs(1) utility gives different output when called from a script and when<br />from an interactive shell.</p>
<pre>
[beket@voyager ~] cat testjobs.sh
#!/bin/sh
sleep 30 &
jobs -l
[beket@voyager ~] sh testjobs.sh
[1] + 10005 Running
[beket@voyager ~] sleep 30 &
[1] 10006
[beket@voyager ~] jobs -l
[1]+ 10006 Running sleep 30 &
[beket@voyager ~]
</pre>
<p>It is not clear whether the jobs(1) should work at all inside a script. POSIX<br />says that since it doesn't fall into the 'special' built-in category a new<br />environment (subshell?) would be created upon its invocation. Even this is true,<br />the jobs aren't specific to the shell environment, so they should be visible to<br />jobs(1). And in any case, the command should either print nothing or print all<br />the fields.</p>
<p>NetBSD 5.0:<br /><pre>
$ sh testjobs.sh
[1] + 27159 Running sleep 30
</pre></p>
<p>SunOS 5.10:<br /><pre>
tuxillo@solaris$ /usr/xpg4/bin/sh testjobs.sh
[1] + 11754 Running <command unknown>
</pre></p>
<p>FreeBSD: same as us. (kindly reported by vstemen at #dragonflybsd).</p>
<p>Any thoughts ?</p>
<p>Best regards,<br />Stathis</p> DragonFlyBSD - Bug #1287 (Feedback): altq configuration doesn't workhttps://bugs.dragonflybsd.org/issues/12872009-02-18T20:47:35Zcorecode
<p>There seem to be serious issues with ALTQ.</p>
<p>Just now I tried to disable it, by removing altq queue definitions from pf.conf<br />+ resync, by disabling pf and also by flushing all pf data. Nevertheless it<br />kept on doing bandwidth shaping. Had to reboot to get rid of this.</p>
<p>Also I had the feeling that changing the altq queue parameters + resync did not<br />have any effect on the queueing behavior (changed from 560kbps -> 5kbps), but I<br />could be mistaken in that regard.</p> DragonFlyBSD - Bug #911 (Feedback): kldload/kernel linker can exceed malloc reserve and panic systemhttps://bugs.dragonflybsd.org/issues/9112008-01-11T06:31:28Zcorecode
<p>hey,</p>
<p>I just booted with hw.physmem=64m and got a panic when trying to load a module:</p>
<p>panic: kld: malloc limit exceeded</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> 0xc018450c in boot (howto=256) at /usr/build/src/sys/kern/kern_shutdown.c:375<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> 0xc0184661 in panic (fmt=Variable "fmt" is not available.<br />) at /usr/build/src/sys/kern/kern_shutdown.c:800<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> 0xc0182129 in kmalloc (size=78, type=0xc02f5600, flags=2)<br /> at /usr/build/src/sys/kern/kern_slaballoc.c:445<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> 0xc01678b4 in linker_make_file (pathname=0xc641b000 "./nvidia.ko", priv=0xc63ea028, <br /> ops=0xc02f5bc8) at /usr/build/src/sys/kern/kern_linker.c:369<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> 0xc016a773 in link_elf_load_module (filename=0xc641b000 "./nvidia.ko", result=0xc83efc7c)<br /> at /usr/build/src/sys/kern/link_elf.c:604<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> 0xc01684e0 in linker_load_file (filename=0xc641b000 "./nvidia.ko", result=0xc83efca8)<br /> at /usr/build/src/sys/kern/kern_linker.c:272<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> 0xc016871c in sys_kldload (uap=0xc83efcf0) at /usr/build/src/sys/kern/kern_linker.c:724</p>
<p>the problem seems to be that M_LINKER already used 10% of all memory (allegedly). In this case kmalloc() simply panics if passing M_WAITOK without M_NULLOK. This is quite unfortunate. Shouldn't we try to stay alive and print a warning and block, hoping that the problem will resolve itself?</p>
<p>cheers<br /> simon</p> DragonFlyBSD - Bug #901 (Feedback): route show needs to get data from all cpushttps://bugs.dragonflybsd.org/issues/9012007-12-31T00:07:48Zcorecode
<p>when executing `route show' on my MP system, I will get varying results. <br />Additionally, it will print all temporary route entries as well, even for hosts<br />outside the local network.</p> DragonFlyBSD - Bug #847 (Feedback): processes getting stuck on mount pointhttps://bugs.dragonflybsd.org/issues/8472007-11-23T07:03:06Zcorecode
<p>Hey,</p>
<p>I just experienced the infamous ``cache_lock: blocked on 0xd591d418 ""'' message. Checking why the process got stuck revealed that the lock is actually being held by another process which is in the process of doing a lstat(2) on /mnt, a nfs mount which server went away. The stuck process is doing the same, fwiw.</p>
<p>So here it is not a namecache bug, but rather an artifact of nfs being stuck. Anoying nevertheless. Anybody have a clue how to fix that? Yea, mount with -intr. Why don't we do that per default?</p>
<p>cheers<br /> simon</p> DragonFlyBSD - Bug #385 (Feedback): Mail archive address removalhttps://bugs.dragonflybsd.org/issues/3852006-11-22T22:22:03Zjustin
<p>Here's a question for everyone: I had originally the mail archive to<br />completely remove mail addresses, but it seems to mostly be annoying -<br />contacting someone from an archived email would be a dead end unless you<br />happened to already know the person's email address. Meanwhile, the<br />DragonFly lists are archived other places like MARC and Gmane, and<br />addresses are at best mildly obfusticated there.</p>
<p>Opinions? If anyone is significantly bothered by this, I'll keep the<br />addresses completely hidden.</p> 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>