WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Re: pv_ops dom0 USB fixed

To: Andrew Lyon <andrew.lyon@xxxxxxxxx>
Subject: Re: [Xen-devel] Re: pv_ops dom0 USB fixed
From: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Date: Fri, 12 Dec 2008 09:06:49 -0800
Cc: Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Aviv Grafi <aviv@xxxxxxxxxxxx>, Ian Campbell <Ian.Campbell@xxxxxxxxxx>
Delivery-date: Fri, 12 Dec 2008 09:07:28 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <f4527be0812120311i152f808eg5cb55b41dffe0aad@xxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <1e16a9ed0812110850odff8f56h836b7187ad0c64b0@xxxxxxxxxxxxxx> <1e16a9ed0812111147h3416cbb5uc11a8b9f5f0d0e80@xxxxxxxxxxxxxx> <1229025794.2770.32.camel@xxxxxxxxxxxxxxxxxxxxx> <1e16a9ed0812111220h40e62ee1ma27f48c5207bc735@xxxxxxxxxxxxxx> <49417755.4050703@xxxxxxxx> <1e16a9ed0812111312p2547884cgf4020eb9ea92ddde@xxxxxxxxxxxxxx> <4941930B.2010605@xxxxxxxx> <1e16a9ed0812111427i3626b94cu7ce56550d654227a@xxxxxxxxxxxxxx> <f4527be0812120112y13e74752kbd3d17d7daa98848@xxxxxxxxxxxxxx> <20081212105738.GL15052@xxxxxxxxxxxxxxx> <f4527be0812120311i152f808eg5cb55b41dffe0aad@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 2.0.0.18 (X11/20081119)
Andrew Lyon wrote:
With 2.6.27 they are detected, and I notice the controller gets a different irq:

 dmesg | grep -E "ata|scsi|ahci"
PERCPU: Allocating 42976 bytes of per cpu data
Memory: 3626568k/3847580k available (3374k kernel code, 212420k
reserved, 1712k data, 288k init)
libata version 3.00 loaded.
ahci 0000:00:1f.2: version 3.0
ahci 0000:00:1f.2: PCI INT C -> GSI 18 (level, low) -> IRQ 18

Yes, that's OK. In a dom0 kernel devices will generally get a different irq. The important thing is that it has the same GSI (18, in this case). In native linux irq == gsi, but in dom0 they're remapped (to make room for irqs for non-hardware events).

ahci 0000:00:1f.2: AHCI 0001.0200 32 slots 6 ports 3 Gbps 0x27 impl SATA mode
ahci 0000:00:1f.2: flags: 64bit ncq sntf pm led clo pmp pio slum part ems
ahci 0000:00:1f.2: setting latency timer to 64
scsi0 : ahci
scsi1 : ahci
scsi2 : ahci
scsi3 : ahci
scsi4 : ahci
scsi5 : ahci
ata1: SATA max UDMA/133 irq_stat 0x00000040, connection status changed irq 18

So this is where things start falling apart. I'm guessing there's some DMA problem; either the drive isn't getting the right command, or we're not seeing a proper response. I suspect the former, since the error message is a timeout rather than complains about bad data.

   J

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel