From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36193) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VMHYI-0005C0-3E for qemu-devel@nongnu.org; Wed, 18 Sep 2013 09:12:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VMHY9-0007fP-KW for qemu-devel@nongnu.org; Wed, 18 Sep 2013 09:12:18 -0400 Received: from mail-ee0-x234.google.com ([2a00:1450:4013:c00::234]:55616) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VMHY9-0007cl-B6 for qemu-devel@nongnu.org; Wed, 18 Sep 2013 09:12:09 -0400 Received: by mail-ee0-f52.google.com with SMTP id c41so3397194eek.25 for ; Wed, 18 Sep 2013 06:12:08 -0700 (PDT) Date: Wed, 18 Sep 2013 15:12:04 +0200 From: Stefan Hajnoczi Message-ID: <20130918131204.GG13359@stefanha-thinkpad.redhat.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] Hibernate and qemu-nbd List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Mark Trumpold Cc: nbd-general@lists.sourceforge.net, w@uter.be, bonzini@stefanha-thinkpad.redhat.com, Paul Clements , "qemu-devel@nongnu.org" On Tue, Sep 17, 2013 at 07:10:44AM -0700, Mark Trumpold wrote: > I am using the kernel functionality directly with the commands: > echo platform >/sys/power/disk > echo disk >/sys/power/state > > The following appears in dmesg when I attempt to hibernate: > > ==================================================== > [ 38.881397] nbd (pid 1473: qemu-nbd) got signal 0 > [ 38.881401] block nbd0: shutting down socket > [ 38.881404] block nbd0: Receive control failed (result -4) > [ 38.881417] block nbd0: queue cleared > [ 87.463133] block nbd0: Attempted send on closed socket > [ 87.463137] end_request: I/O error, dev nbd0, sector 66824 > ==================================================== > > My environment: > Debian: 6.0.5 > Kernel: 3.3.1 > Qemu userspace: 1.2.0 This could be a bug in the nbd client kernel module. drivers/block/nbd.c:sock_xmit() does the following: result = kernel_recvmsg(sock, &msg, &iov, 1, size, msg.msg_flags); if (signal_pending(current)) { siginfo_t info; printk(KERN_WARNING "nbd (pid %d: %s) got signal %d\n", task_pid_nr(current), current->comm, dequeue_signal_lock(current, ¤t->blocked, &info)); result = -EINTR; sock_shutdown(nbd, !send); break; } The signal number in the log output looks bogus, we shouldn't get 0. sock_xmit() actually blocks all signals except SIGKILL before calling kernel_recvmsg(). I guess this is an artifact of the suspend-to-disk operation, maybe the signal pending flag is set on the process. Perhaps someone with a better understanding of the kernel internals can check this? What happens next is that the nbd kernel module shuts down the NBD connection. As a workaround, please try running a separate nbd-client(1) process and drop the qemu-nbd -c command-line argument. This way nbd-client(1) uses the nbd kernel module instead of the qemu-nbd process and you'll get the benefit of nbd-client's automatic reconnect. Stefan