[DragonFlyBSD - Bug #2927] e2a21467e1 Updates to show "4.7" and other changes to major headers should be temporarily suspended

[bugtracker-admin at leaf.dragonflybsd.org]

Issue #2927 has been updated by arcade at 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