This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours

Bug 830261

Summary: NetBSD v5.1.2 won't execute in qemu-kvm: "no console device"
Product: [Fedora] Fedora Reporter: Ken Jackson <linux>
Component: qemuAssignee: Fedora Virtualization Maintainers <virt-maint>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 17CC: amit.shah, berrange, cfergeau, dwmw2, itamar, kmcmartin, knoel, mikeandmore, pbonzini, scottt.tw, swisscheeseo, tcpip4000, virt-maint
Target Milestone: ---Keywords: Reopened, Triaged
Target Release: ---   
Hardware: x86_64   
OS: Other   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-02-28 02:02:06 EST Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:

Description Ken Jackson 2012-06-08 12:57:03 EDT
Description of problem:
NetBSD v5.1.2 executed without problem under F16, but won't start under F17.
The guest reports: "panic: cnopen: no console device"

Version-Release number of selected component (if applicable):
On the F17 host:
uname -a
Linux xxxxxx 3.4.0-1.fc17.x86_64 #1 SMP Sun Jun 3 06:35:17 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
(It failed the same way right after upgrading to F17 when I was still
running 3.3.6-3.fc16.x86_64, before I got grub fixed.)

rpm -qa | grep qemu
qemu-kvm-tools-1.0-17.fc17.x86_64
qemu-kvm-1.0-17.fc17.x86_64
ipxe-roms-qemu-20120328-1.gitaac9718.fc17.noarch
qemu-common-1.0-17.fc17.x86_64
qemu-img-1.0-17.fc17.x86_64
qemu-system-x86-1.0-17.fc17.x86_64


How reproducible:
Always

Steps to Reproduce:
1. Download the iso here or from another mirror:
http://mirror.planetunix.net/pub/NetBSD/NetBSD-5.1.2/iso/amd64cd-5.1.2.iso

2. Execute either command:
qemu-kvm -boot c -cdrom amd64cd-5.1.2.iso &
qemu-system-x86_64 -boot c -cdrom amd64cd-5.1.2.iso &

3. When the NetBSD guest presents the menu (white text in the SDL window), press '1' to install or wait for the timeout.
  
Actual results:
The guest scrolls its the second level boot (green text) until it fails:

    warning: no /dev/console
    panic: cnopen: no console device
    fatal breakpoint trap in supervisor mode
    trap type 1 code 0 rip ffffffff80527525 cs 8 rflags 246 cr2 7f7ffde3e188 cpl 0 rsp ffff80000a7f57f0
    Stopped in pid 2.1 (sh) at      0xffffffff80527525:     leave
    db[0}>


Expected results:
Normal execution.

Additional info:
It fails the same way with the virtual disk I installed it on under F16.
I also tried -no-kvm-irqchip, -no-kvm-pit and -no-kvm in turn but they had
no effect.
Comment 1 Mike Qin 2012-07-20 17:13:34 EDT
confirm this bug

For other BSDs.  I was able to boot OpenBSD/bitrig and FreeBSD.

This could be a bug of NetBSD though.
Comment 2 Avi Kivity 2012-07-22 07:34:54 EDT
Strange.  Upstream works.  Maybe an ACPI regression.
Comment 3 Juan P. Daza P. 2012-09-29 07:44:26 EDT
Confirmed this behaviour in Fedora 17 (x86_64) with kvm-qemu; same machine with VirtualBox installs and boots netbsd 6.0RC2 fine.

packages:
  augeas-libs.x86_64 0:0.10.0-3.fc17                                            
  gnutls-utils.x86_64 0:2.12.17-1.fc17                                          
  libvirt-client.x86_64 0:0.9.11.5-3.fc17                                       
  libvirt-python.x86_64 0:0.9.11.5-3.fc17                                       
  libwsman1.x86_64 0:2.2.7-5.fc17                                               
  netcf-libs.x86_64 0:0.1.9-2.fc17                                              
  spice-gtk.x86_64 0:0.12-5.fc17                                                
  spice-gtk-python.x86_64 0:0.12-5.fc17                                         
  virt-manager-common.noarch 0:0.9.4-1.fc17                                     
  vte.x86_64 0:0.28.2-6.fc17                                                    
  xen-libs.x86_64 0:4.1.3-4.fc17                                                
  xen-licenses.x86_64 0:4.1.3-4.fc17
  VirtualBox-4.2.x86_64 0:4.2.0_80737_fedora17-1
  python-virtinst.noarch 0:0.600.3-1.fc17   
  qemu-kvm.x86_64 2:1.0.1-1.fc17     
  virt-manager.noarch 0:0.9.4-1.fc17
  virt-viewer.x86_64 0:0.5.3-1.fc17  
  augeas-libs.x86_64 0:0.10.0-3.fc17                                            
  gnutls-utils.x86_64 0:2.12.17-1.fc17                                          
  libvirt-client.x86_64 0:0.9.11.5-3.fc17                                       
  libvirt-python.x86_64 0:0.9.11.5-3.fc17                                       
  libwsman1.x86_64 0:2.2.7-5.fc17                                               
  netcf-libs.x86_64 0:0.1.9-2.fc17                                              
  spice-gtk.x86_64 0:0.12-5.fc17                                                
  spice-gtk-python.x86_64 0:0.12-5.fc17                                         
  virt-manager-common.noarch 0:0.9.4-1.fc17                                     
  vte.x86_64 0:0.28.2-6.fc17                                                    
  xen-libs.x86_64 0:4.1.3-4.fc17                                                
  xen-licenses.x86_64 0:4.1.3-4.fc17 

---

Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 4 Ken Jackson 2012-10-21 08:10:58 EDT
It fails similarly with NetBSD 6.0, though the error text is different.
http://mirror.planetunix.net/pub/NetBSD/iso/6.0/NetBSD-6.0-amd64.iso

Guest error text:

    ioapic0 at mainbus0 apid 1
    acpi0 at mainbus0: Intel ACPICA 20110623
    panic: pci_make_tag: bad request
    fatal breakpoint trap in supervisor mode
    trap type 1 code 0 rip ffffffff80252d0d cs 8 rflags 246 cr2  0 cpl 8 rsp ffffffff80fcab10
    Stopped in pid 0.1 (system) at  netbsd:breakpoint+0x5:  leave
    db{0}>

Host:
uname -a
Linux xxxxxx 3.6.1-1.fc17.x86_64 #1 SMP Wed Oct 10 12:13:05 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

rpm -qa | grep qemu
qemu-kvm-1.0.1-2.fc17.x86_64
qemu-img-1.0.1-2.fc17.x86_64
qemu-common-1.0.1-2.fc17.x86_64
ipxe-roms-qemu-20120328-1.gitaac9718.fc17.noarch
qemu-system-x86-1.0.1-2.fc17.x86_64
qemu-kvm-tools-1.0.1-2.fc17.x86_64
Comment 5 Kyle McMartin 2013-01-28 17:48:59 EST
Can you reproduce this with F18? It looks to be fixed there.

[
FWIW, I was successfully working around it by "boot -d" to drop into the kernel debugger, and then "w pci_mode 1" to force it to use PCI mode1 config access instead of attempting to probe it.

My guess is something in the KVM emulation of PCIbios got fixed, and the reason most other OS didn't see this is they poke PCIbios during their bootloader and pass it into the kernel, whereas NetBSD doesn't look at what mode the BIOS says to use at all.
]
Comment 6 Ken Jackson 2013-01-28 21:30:55 EST
Chuck Silvers from the NetBSD world emailed me saying,

  "In fedora 17, netbsd autodetects the PCI configuration mode
  as "mode 2", which is almost certainly wrong since mode 2 supposedly
  isn't used by anything these days.  In fedora 18 it's detected as mode 1
  and everything works."

So I upgraded to Fedora 18, and yes indeed!  It works.  Now I can continue my exploration of NetBSD from within Fedora/QEMU/KVM.
Comment 7 Kyle McMartin 2013-01-29 17:17:09 EST
I spent the afternoon learning how PCI works on qemu/seabios... Turns out this is:

master@qemu:.% git show cdde6ffc               (kyle@redacted:~/src/qemu)
commit cdde6ffc27517bdf069734fbc5693ce2b14edc75
Author: Avi Kivity <avi@redhat.com>
Date:   Wed Jan 4 16:28:42 2012 +0200

    pci: fix corrupted pci conf index register by unaligned write
    
    Commit d0ed8076cbdc261 converted the PCI config access to the memory
    API, but also inadvertantly changed it to accept unaligned writes,
    and corrupt the index register in the process.  This causes a regression
    booting NetBSD.
    
    Fix by ignoring unaligned or non-dword writes.
    
    https://bugs.launchpad.net/qemu/+bug/897771
    
    Reported-by: Andreas Gustafsson <gson@gson.org>
    Signed-off-by: Avi Kivity <avi@redhat.com>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

I don't really see a reason why we cannot fix it in F-17 as well, so I'm going to reopen it.
Comment 8 Fedora Update System 2013-01-30 10:56:57 EST
qemu-1.0.1-4.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/qemu-1.0.1-4.fc17
Comment 9 Fedora Update System 2013-02-01 12:14:35 EST
Package qemu-1.0.1-4.fc17:
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing qemu-1.0.1-4.fc17'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-1796/qemu-1.0.1-4.fc17
then log in and leave karma (feedback).
Comment 10 Fedora Update System 2013-02-28 02:02:09 EST
qemu-1.0.1-4.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.