From owner-freebsd-xen@FreeBSD.ORG Fri Apr 24 15:43:58 2015 Return-Path: Delivered-To: freebsd-xen@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DB95D3B4 for ; Fri, 24 Apr 2015 15:43:58 +0000 (UTC) Received: from SMTP02.CITRIX.COM (smtp02.citrix.com [66.165.176.63]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.citrix.com", Issuer "Cybertrust Public SureServer SV CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 807B61C3A for ; Fri, 24 Apr 2015 15:43:57 +0000 (UTC) X-IronPort-AV: E=Sophos;i="5.11,641,1422921600"; d="scan'208";a="258394847" Message-ID: <553A645F.4020206@citrix.com> Date: Fri, 24 Apr 2015 17:42:23 +0200 From: =?UTF-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: =?UTF-8?B?R3VzdGF1IFDDqXJleg==?= CC: FreeBSD XEN Subject: Re: Two issues with xen References: <5528F578.2030908@entel.upc.edu> <552BAE1C.1090603@citrix.com> <97e3bb8b2ea7acfb89c861e21f1534c7@webmail.entel.upc.edu> <552BE23D.9030107@citrix.com> <552BFBD3.7060304@citrix.com> <552CACE1.8070101@entel.upc.edu> <552E9664.3050400@citrix.com> <5534C859.1020400@entel.upc.edu> In-Reply-To: <5534C859.1020400@entel.upc.edu> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-DLP: MIA2 X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion of the freebsd port to xen - implementation and usage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2015 15:43:58 -0000 Hello, El 20/04/15 a les 11.35, Gustau Pérez ha escrit: >> I've cleaned up the patch that fixed the reboots while creating PV >> guests that you experienced before. Since I'm not able to reproduce this >> problem, can you make sure the new version also works for you? >> > > Hi Roger, > > I applied the patch to a clean HEAD (as of April 10th) wout problems > and PV domains seem to work just fine. I also tried a HVM domain just in > case and it did work fine too. > > Just as a reminder and completely unrelated, the sound problem is > still there. Can you boot with hw.snd.verbose=4 and paste the boot log? I've tested on two systems, one of them works fine and the other fails. Here are the relevant parts of the boot log. Working system: [...] hdac0: mem 0xf7ffc000-0xf7ffffff irq 16 at device 27.0 on pci0 hdac0: PCI card vendor: 0x1028, device: 0x0293 hdac0: HDA Driver Revision: 20120126_0002 hdac0: Config options: on=0x00000000 off=0x00000000 hdac0: TCSEL: 0x00 -> 0x00 hdac0: DMA Coherency: Uncacheable / vendor=0x8086 hdac0: attempting to allocate 1 MSI vectors (1 supported) hdac0: using IRQ 258 for MSI hdac0: Caps: OSS 4, ISS 4, BSS 0, NSDO 1, 64bit, CORB 256, RIRB 256 hdac0: hdac_dma_alloc: size=1024 -> roundsz=1024 hdac0: hdac_dma_alloc: size=2048 -> roundsz=2048 hdac0: hdac_dma_alloc: size=4096 -> roundsz=4096 hdac0: hdac_dma_alloc: size=4096 -> roundsz=4096 hdac0: hdac_dma_alloc: size=4096 -> roundsz=4096 hdac0: hdac_dma_alloc: size=4096 -> roundsz=4096 hdac0: hdac_dma_alloc: size=4096 -> roundsz=4096 hdac0: hdac_dma_alloc: size=4096 -> roundsz=4096 hdac0: hdac_dma_alloc: size=4096 -> roundsz=4096 hdac0: hdac_dma_alloc: size=4096 -> roundsz=4096 hdac0: Reset controller... [...] hdac0: Starting CORB Engine... hdac0: Starting RIRB Engine... hdac0: Enabling controller interrupt... hdac0: Scanning HDA codecs ... hdac0: Found CODEC at address 0 hdacc0: at cad 0 on hdac0 hdacc0: Root Node at nid=0: 1 subnodes 1-1 hdaa0: at nid 1 on hdacc0 [...] Broken system: [...] hdac0: mem 0xf7034000-0xf7037fff irq 16 at device 3.0 on pci0 hdac0: PCI card vendor: 0x8086, device: 0x2058 hdac0: HDA Driver Revision: 20120126_0002 hdac0: Config options: on=0x00000000 off=0x00000000 hdac0: TCSEL: 0x145 -> 0x145 hdac0: DMA Coherency: Uncacheable / vendor=0x8086 hdac0: Caps: OSS 3, ISS 0, BSS 0, NSDO 1, 64bit, CORB 256, RIRB 256 hdac0: hdac_dma_alloc: size=1024 -> roundsz=1024 hdac0: hdac_dma_alloc: size=2048 -> roundsz=2048 hdac0: hdac_dma_alloc: size=4096 -> roundsz=4096 hdac0: hdac_dma_alloc: size=4096 -> roundsz=4096 hdac0: hdac_dma_alloc: size=4096 -> roundsz=4096 hdac0: Reset controller... [...] hdac1: mem 0xf7030000-0xf7033fff irq 22 at device 27.0 on pci0 hdac1: PCI card vendor: 0x8086, device: 0x2058 hdac1: HDA Driver Revision: 20120126_0002 hdac1: Config options: on=0x00000000 off=0x00000000 hdac1: TCSEL: 0x00 -> 0x00 hdac1: DMA Coherency: Uncacheable / vendor=0x8086 hdac1: Caps: OSS 4, ISS 4, BSS 0, NSDO 1, 64bit, CORB 256, RIRB 256 hdac1: hdac_dma_alloc: size=1024 -> roundsz=1024 hdac1: hdac_dma_alloc: size=2048 -> roundsz=2048 hdac1: hdac_dma_alloc: size=4096 -> roundsz=4096 hdac1: hdac_dma_alloc: size=4096 -> roundsz=4096 hdac1: hdac_dma_alloc: size=4096 -> roundsz=4096 hdac1: hdac_dma_alloc: size=4096 -> roundsz=4096 hdac1: hdac_dma_alloc: size=4096 -> roundsz=4096 hdac1: hdac_dma_alloc: size=4096 -> roundsz=4096 hdac1: hdac_dma_alloc: size=4096 -> roundsz=4096 hdac1: hdac_dma_alloc: size=4096 -> roundsz=4096 hdac1: Reset controller... [...] hdac0: Starting CORB Engine... hdac0: Starting RIRB Engine... hdac0: Enabling controller interrupt... hdac0: Scanning HDA codecs ... hdac0: Found CODEC at address 0 hdac0: Command timeout on address 0 hdac0: Command timeout on address 0 hdac0: CODEC is not responding! hdac1: Starting CORB Engine... hdac1: Starting RIRB Engine... hdac1: Enabling controller interrupt... hdac1: Scanning HDA codecs ... hdac1: Found CODEC at address 0 hdacc0: at cad 0 on hdac1 hdacc0: Root Node at nid=0: 1 subnodes 1-1 hdaa0: at nid 1 on hdacc0 hdaa0: Subsystem ID: 0x80862058 [...] As can be seen from the logs above, in the broken system the detection of the codec in the first card (hdac0) fails when booting as Dom0 (it succeeds when booting bare metal). Do you see something similar on your system? Roger.