<div dir="ltr">The smp_invltlb() issue should hopefully be fixed in the latest master but the code has not been well-tested yet.<div><br></div><div>The cause of the original issue you reported is not entirely known (its an issue with one of the other cpu cores, not the one that generated the message and backtrace), but it is usually able to self-recover from it.  The new code should work a lot better.<br><div><br></div><div>-Matt</div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jul 15, 2016 at 3:54 AM, Stefan Unterweger <span dir="ltr"><<a href="mailto:232.20711@chiffre.aleturo.com" target="_blank">232.20711@chiffre.aleturo.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">* Stefan Unterweger on Thu, Jul 07, 2016 at 09:31:47AM +0200:<br>
<span class="">> > >> Virtio (for block storage devices) could be the cause.  There are known<br>
> > >> bugs in the DragonFly driver for virtio which haven't been tracked down yet<br>
> > >> (not enough of the devs are using virtual hosting to be able to reproduce<br>
> > >> the problem in a debugable way).<br>
> ><br>
> > Can you try the latest master?  I think it has been fixed there.<br>
><br>
> So, the patch is finally in.  At least from the first superficial<br>
> glances, the system now feels more stable than before: a big Synth<br>
> upgrade marathon previously easily got the machine down, yesterday it<br>
> went through.  I’ll have to do a few more stress tests, perhaps on a<br>
> second machine, before I can tick that off.<br>
<br>
</span>With the ‚gentle‘ stress tests done so far the system -seems- stable,<br>
but it looks trecherous.  Today I have got another semi-crash under<br>
moderate load; this is the trace that has just appeared in syslog:<br>
<br>
| Jul 15 12:44:01 rhaal kernel: Trace beginning at frame 0xffffffe08025d580<br>
| Jul 15 12:44:01 rhaal kernel: smp_invltlb() at smp_invltlb+0x229 0xffffffff80a2d3c1<br>
| Jul 15 12:44:01 rhaal kernel: smp_invltlb() at smp_invltlb+0x229 0xffffffff80a2d3c1<br>
| Jul 15 12:44:01 rhaal kernel: pmap_qenter() at pmap_qenter+0x6d 0xffffffff80a260f0<br>
| Jul 15 12:44:01 rhaal kernel: allocbuf() at allocbuf+0x5eb 0xffffffff80669b92<br>
| Jul 15 12:44:01 rhaal kernel: getblk() at getblk+0x467 0xffffffff8066ccff<br>
| Jul 15 12:44:01 rhaal kernel: hammer_io_inval() at hammer_io_inval+0x84 0xffffffff80821c6e<br>
| Jul 15 12:44:01 rhaal kernel: hammer_del_buffers() at hammer_del_buffers+0x1cb 0xffffffff8082e06c<br>
| Jul 15 12:44:01 rhaal kernel: hammer_io_direct_wait() at hammer_io_direct_wait+0xd2 0xffffffff808231f4<br>
| Jul 15 12:44:01 rhaal kernel: hammer_ip_sync_record_cursor() at hammer_ip_sync_record_cursor+0xcb 0xffffffff80829556<br>
| Jul 15 12:44:01 rhaal kernel: hammer_sync_record_callback() at hammer_sync_record_callback+0x24d 0xffffffff8081b45c<br>
| Jul 15 12:44:01 rhaal kernel: hammer_rec_rb_tree_RB_SCAN() at hammer_rec_rb_tree_RB_SCAN+0xfa 0xffffffff80826844<br>
| Jul 15 12:44:01 rhaal kernel: hammer_sync_inode() at hammer_sync_inode+0x27e 0xffffffff8081db74<br>
| Jul 15 12:44:01 rhaal kernel: hammer_flusher_flush_inode() at hammer_flusher_flush_inode+0x55 0xffffffff80819f84<br>
| Jul 15 12:44:01 rhaal kernel: hammer_fls_rb_tree_RB_SCAN() at hammer_fls_rb_tree_RB_SCAN+0xfc 0xffffffff808190fd<br>
| Jul 15 12:44:01 rhaal kernel: hammer_flusher_slave_thread() at hammer_flusher_slave_thread+0x7a 0xffffffff80819231<br>
| Jul 15 12:44:01 rhaal kernel: smp_invltlb: endless loop 00000000 00000002, rflags 0000000000000286 retrysmp_invltlb: ipi sent<br>
<br>
The machine thankfully is still running.<br>
<br>
The kernel is master edca023af (or at most one or two commits after<br>
that).  I‘ll try out today‘s master on a second machine tomorrow, but<br>
until booting is still flakey, it’s difficult to replicate the setup to<br>
reliably provoke a crash.  The dmesg is attached for reference.<br>
<br>
<br>
Thanks,<br>
<div class="HOEnZb"><div class="h5">    Stefan<br>
<br>
<br>
--<br>
Die Internetbleibe.  Schick, magisch, leistungsstark.<br>
<a href="https://internetbleibe.de/" rel="noreferrer" target="_blank">https://internetbleibe.de/</a><br>
<br>
medoly media UG (haftungsbeschränkt), Hausburgstr. 13, 10249 Berlin<br>
<br>
E-Mail: <a href="mailto:info@medolymedia.de">info@medolymedia.de</a><br>
Telefon 030 - 609 826 560<br>
Fax 030 - 609 826 569<br>
Website: <a href="https://medolymedia.de/" rel="noreferrer" target="_blank">https://medolymedia.de/</a><br>
<br>
Geschäftsführer: Matthias Nothhaft, HRB 131198 (Amtsgericht Berlin-Charlottenburg), Sitz: Berlin, USt-ID: DE275221203<br>
</div></div></blockquote></div><br></div>