All of lore.kernel.org
 help / color / mirror / Atom feed
* [Bug 194837] New: VM with virtio-scsi drive often crashes during boot with kernel 4.11rc1
@ 2017-03-09 23:53 bugzilla-daemon
  2017-03-09 23:58 ` [Bug 194837] " bugzilla-daemon
                   ` (16 more replies)
  0 siblings, 17 replies; 18+ messages in thread
From: bugzilla-daemon @ 2017-03-09 23:53 UTC (permalink / raw)
  To: linux-scsi

https://bugzilla.kernel.org/show_bug.cgi?id=194837

            Bug ID: 194837
           Summary: VM with virtio-scsi drive often crashes during boot
                    with kernel 4.11rc1
           Product: IO/Storage
           Version: 2.5
    Kernel Version: 4.11rc1
          Hardware: All
                OS: Linux
              Tree: Mainline
            Status: NEW
          Severity: blocking
          Priority: P1
         Component: SCSI
          Assignee: linux-scsi@vger.kernel.org
          Reporter: adamw@happyassassin.net
        Regression: No

In Fedora, we use the openQA automated test system, which runs qemu VMs and
does tests in them. By default, it attaches optical disc images to the test VM
using a virtio-scsi drive.

When Fedora 26 and Rawhide's kernels went from kernel-4.11.0-0.rc0.git9.1 to
kernel-4.11.0-0.rc1.git0.1 , many openQA tests suddenly started failing because
at some point in the test, the VM would fail to boot properly, with a kernel
error and traceback often displayed (sometimes the screen would just be blank).
I've seen three variants on this failure so far. Two have identical-looking
tracebacks but a slightly different error message:

https://openqa.fedoraproject.org/tests/60571#step/_console_wait_login/7
https://openqa.fedoraproject.org/tests/60572#step/_console_wait_login/6

note that one error is 'unable to handle kernel paging request' and the other
is 'unable to handle kernel NULL pointer dereference', but the tracebacks look
very similar.

Another case shows a somewhat different traceback:

https://openqa.fedoraproject.org/tests/60574#step/_console_wait_login/4

but doesn't show an error message (it may just be in the backscroll,
unfortunately there's no way to recover it from that test now). The traceback
is still in SCSI code, however.

I can reproduce this problem manually using virt-manager, so long as I attach a
SCSI optical drive to the VM (Add Hardware, Device type -> "CDROM device", Bus
type -> "SCSI"). If I use an IDE optical drive (which is the default in
virt-manager), the bug does not occur. So long as a SCSI optical drive is
attached, about half of the attempts to boot the system with the affected
kernel fail. Usually with a traceback looking like the ones from openQA,
sometimes it also just apparently hangs when enumerating SCSI devices (I think
that's what it's doing, the last line is 'scsi 3:0:0:0: CD-ROM     QEMU   QEMU
CD-ROM   2.0. PQ: 0 ANSI: 5' or a bit after that).

-- 
You are receiving this mail because:
You are the assignee for the bug.

^ permalink raw reply	[flat|nested] 18+ messages in thread

end of thread, other threads:[~2017-03-17 19:03 UTC | newest]

Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-03-09 23:53 [Bug 194837] New: VM with virtio-scsi drive often crashes during boot with kernel 4.11rc1 bugzilla-daemon
2017-03-09 23:58 ` [Bug 194837] " bugzilla-daemon
2017-03-09 23:59 ` bugzilla-daemon
2017-03-09 23:59 ` bugzilla-daemon
2017-03-10  0:47 ` bugzilla-daemon
2017-03-13 15:04 ` bugzilla-daemon
2017-03-13 15:15 ` bugzilla-daemon
2017-03-13 16:01 ` bugzilla-daemon
2017-03-14 19:25 ` bugzilla-daemon
2017-03-14 21:23 ` bugzilla-daemon
2017-03-14 22:56 ` bugzilla-daemon
2017-03-15  6:57 ` bugzilla-daemon
2017-03-15  7:02 ` bugzilla-daemon
2017-03-15  7:07 ` bugzilla-daemon
2017-03-15  7:47 ` bugzilla-daemon
2017-03-16 12:49 ` bugzilla-daemon
2017-03-16 16:18 ` bugzilla-daemon
2017-03-17 19:02 ` bugzilla-daemon

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.