Issue #2927 has been updated by arc...@b1t.name.
Hi all. I previously was able to reproduce lockups with hammer2 by transferring large (1G, 4G) to filesystem fairly reliably in 5 minutes or so. After last patch I was able at least once transfer files completely. After transferring files I tried to remove them thus causing a core: chain 00000000c1140010.02 key=0000000000000400 meth=30 CHECK FAIL (flags=00146002, bref/data 81ee268bc3884e4f/c7a20c5a57036b22) chain 00000000c1140010.02 key=0000000000000400 meth=30 CHECK FAIL (flags=00146002, bref/data 81ee268bc3884e4f/c7a20c5a57036b22) chain 00000000c1140010.02 key=0000000000000400 meth=30 CHECK FAIL (flags=00146002, bref/data 81ee268bc3884e4f/c7a20c5a57036b22) chain 00000000c1140010.02 key=0000000000000400 meth=30 CHECK FAIL (flags=00146002, bref/data 81ee268bc3884e4f/c7a20c5a57036b22) chain 00000000c1140010.02 key=0000000000000400 meth=30 CHECK FAIL (flags=00146202, bref/data 81ee268bc3884e4f/c7a20c5a57036b22) panic: delete base 0xffffffe14c85c000 element not found at 0/512 elm 0xffffffe3434ccde0 cpuid = 3 Trace beginning at frame 0xffffffe3430b8480 panic() at panic+0x25f 0xffffffff8027cb46 panic() at panic+0x25f 0xffffffff8027cb46 hammer2_base_delete() at hammer2_base_delete+0x9f 0xffffffff81783cfb hammer2_flush_core() at hammer2_flush_core+0xa4e 0xffffffff81788f2c hammer2_flush_recurse() at hammer2_flush_recurse+0xa0 0xffffffff81789100 hammer2_chain_tree_RB_SCAN() at hammer2_chain_tree_RB_SCAN+0x105 0xffffffff817822b1 boot() called on cpu#3 Uptime: 5m20s Physical memory: 15536 MB This can be totally unrelated though. On the other hand when I rebooted and savecore tried to save a core dump I had hard lockup. ---------------------------------------- Bug #2927: e2a21467e1 Updates to show "4.7" and other changes to major headers should be temporarily suspended http://bugs.dragonflybsd.org/issues/2927#change-12945 * Author: davshao * Status: In Progress * Priority: High * Assignee: dillon * Category: * Target version: ---------------------------------------- commit 5d920ec6b97613f06aba4a09bfb91413b1fd93c3 Fix excessive ipiq recursion (2) does not correct the problem I have observed on at least two machines that make -j7 buildworld locks up the machine. (When using make buildworld I move /usr/obj/usr to start the build from scratch.) On one machine there seems to be a reproducible lock up at sh /usr/src/tools/install.sh -o root -g wheel -m 555 lto1 /usr/obj/usr/src/ctools_x86_64_x86_64/usr/libexec/gcc50 Changes to major headers should be temporarily suspended until this problem is resolved, because I have observed that even make quickworld can fail to complete without lockup. Someone using UFS as their filesystem may experience quite substantial filesystem corruption after a lockup. By limiting changes to major headers, this gives the greatest chance of a successful make quickworld when this problem is finally resolved. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account
