Re: kern/52199 (vioscsi kernel panic on a KVM hypervisor)

[MB <code%boerschig.net@localhost>]

The following reply was made to PR kern/52199; it has been noted by GNATS.

From: MB <code%boerschig.net@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: kern/52199 (vioscsi kernel panic on a KVM hypervisor)
Date: Tue, 16 May 2017 23:00:11 +0200

 On 16.05.2017 00:05, Jaromír DoleÄ?ek wrote:
 > The following reply was made to PR kern/52199; it has been noted by GNATS.
 > 
 > From: =?UTF-8?B?SmFyb23DrXIgRG9sZcSNZWs=?= <jaromir.dolecek%gmail.com@localhost>
 > To: gnats-bugs%netbsd.org@localhost
 > Cc: code%boerschig.net@localhost
 > Subject: Re: kern/52199 (vioscsi kernel panic on a KVM hypervisor)
 > Date: Tue, 16 May 2017 00:02:15 +0200
 > 
 >  --001a114904e844ac46054f973543
 >  Content-Type: text/plain; charset="UTF-8"
 >  
 >  Hello,
 >  
 >  committed another fix for the resource shortage, messages and related i/o
 >  delays should be gone for good. You can grab just the new kernel from
 >  NetBSD-daily once it gets built.
 >  
 >  Thanks for the reproduction instructions. I did see the resource shortages
 >  during sysinst extracting, but unfortunately I wasn't able to trigger the
 >  lockup using the dd's so far. I'm using QEMU 2.9, and I haven't try with
 >  KVM yet. I don't see anything related in release notes for 2.6-2.9, so
 >  maybe my non-kvm QEMU is too slow to trigger the problem.
 >  
 >  Can you let me know if the latest fix by chance helps with the lockup too?
 >  
 >  And can you please try without --enable-kvm too?
 >  
 >  Another thing to try would be to compile&run custom kernel with LOCKDEBUG
 >  and DEBUG options enabled. If the freeze is due to locking issue, those
 >  options help to find the problematic spot.
 >  
 >  Jaromir
 
 Hi,
 
 looks like you fixed the messages and the lockups.
 Just tried to reproduce the freeze with vioscsi.c version 1.19 but could
 not reproduce it. FWIW, i tried only with kvm enabled, and performance
 looks reasonable good now, too.
 I tried dd in an infinite loop (2hours...) and also added extracting the
 pkgsrc tarballs for good measure -- so far not a single resource
 shortage or lockup.
 
 Again, thanks a lot.
 
 PS: any chance these fixes will get pulled up in a stable release?