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] MSI badness in xen-unstable

To: "Bruce Edge" <bruce.edge@xxxxxxxxx>
Subject: Re: [Xen-devel] MSI badness in xen-unstable
From: "Jan Beulich" <JBeulich@xxxxxxxxxx>
Date: Mon, 18 Oct 2010 09:24:17 +0100
Cc: Sander Eikelenboom <linux@xxxxxxxxxxxxxx>, Xen Devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Keir Fraser <Keir.Fraser@xxxxxxxxxxxxx>, Gianni Tedesco <gianni.tedesco@xxxxxxxxxx>, Stefano Stabellini <Stefano.Stabellini@xxxxxxxxxxxxx>
Delivery-date: Mon, 18 Oct 2010 01:25:17 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <AANLkTimNNHPgZT-MZ3OOH=TgycoOPL7T50-0ZXmh0BJY@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: <1286530426.12843.199.camel@xxxxxxxxxxxxxxxxxxxxxx> <1286817142.12843.515.camel@xxxxxxxxxxxxxxxxxxxxxx> <AANLkTi=O=uqeUfL4kOhaHFM7V-9dOdMZvM47kVNpUpz9@xxxxxxxxxxxxxx> <AANLkTimq7J3S0UB=HFQ=8Veh5974Yo3RYemQaAhRWVyF@xxxxxxxxxxxxxx> <1766682273.20101016182926@xxxxxxxxxxxxxx> <AANLkTimLya+s=OMz-8zfkprjnrLj99y49T252T+r2Buy@xxxxxxxxxxxxxx> <1868325440.20101016192611@xxxxxxxxxxxxxx> <AANLkTinnOoGyV2iUEns8K0AjDoXE0eDp0nJfKwSU+sjh@xxxxxxxxxxxxxx> <AANLkTimNNHPgZT-MZ3OOH=TgycoOPL7T50-0ZXmh0BJY@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>>> On 18.10.10 at 00:33, Bruce Edge <bruce.edge@xxxxxxxxx> wrote:
> diff -r 3a5755249361 xen/arch/x86/msi.c
> --- a/xen/arch/x86/msi.c        Thu Oct 14 12:46:29 2010 +0100
> +++ b/xen/arch/x86/msi.c        Sun Oct 17 15:32:05 2010 -0700
> @@ -549,14 +549,14 @@
>          return 0;
>      if ( (addr & PCI_BASE_ADDRESS_MEM_TYPE_MASK) == 
> PCI_BASE_ADDRESS_MEM_TYPE_64 )
>      {
> -        addr &= ~PCI_BASE_ADDRESS_MEM_MASK;
> +        addr &= PCI_BASE_ADDRESS_MEM_MASK;
>          if ( ++bir >= limit )
>              return 0;
>          return addr |
>                 ((u64)pci_conf_read32(bus, slot, func,
>                                       PCI_BASE_ADDRESS_0 + bir * 4) << 32);
>      }
> -    return addr & ~PCI_BASE_ADDRESS_MEM_MASK;
> +    return addr & PCI_BASE_ADDRESS_MEM_MASK;
>  }
> 
>  /**
> @@ -634,6 +634,14 @@
> 
>          ASSERT(!dev->msix_used_entries);
>          WARN_ON(msi->table_base != read_pci_mem_bar(bus, slot, func, bir));
> +        if(msi->table_base == read_pci_mem_bar(bus, slot, func, bir)) { // 
> XXX

Did you perhaps mean != here? The log you provided shows the two
values to be identical when these printk()s get executed (which raises
the question how the warning could get triggered, the more on line
635 when it sits on line 636 according to the patch).

> +                       printk( 
> "==================================================\n");
> +                       printk( "msi->table_base != read_pci_mem_bar(bus, 
> slot, func, bir)\n");
> +                       printk( "msi->table_base = %0lx\n", msi->table_base );
> +                       printk( "read_pci_mem_bar = %0lx\n", 
> read_pci_mem_bar(bus, slot, func, bir) );
> +                       printk( "bus=%0x, slot=%0x, func=%0x, bir=%0x\n", 
> bus, slot, func, bir);
> +                       printk( 
> "==================================================\n\n");
> +               }
> 
>          dev->msix_nr_entries = nr_entries;
>          dev->msix_table.first = PFN_DOWN(table_paddr);
> @@ -647,6 +655,11 @@
>          bir = (u8)(pba_offset & PCI_MSIX_BIRMASK);
>          pba_paddr = read_pci_mem_bar(bus, slot, func, bir);
>          WARN_ON(!pba_paddr);

Similar here: the warning sits on line 657, but the log shows warnings
only on lines 635, 639, and 660. Something's out of sync here.

> +        if (!pba_paddr) { // XXX
> +                       printk( 
> "==================================================\n");
> +                       printk( "No pba_addr: bus=%0x, slot=%0x, func=%0x, 
> bir=%0x\n", bus, slot, func, bir);
> +                       printk( 
> "==================================================\n\n");
> +               }
>          pba_paddr += pba_offset & ~PCI_MSIX_BIRMASK;
> 
>          dev->msix_pba.first = PFN_DOWN(pba_paddr);
> @@ -654,6 +667,14 @@
>                                        BITS_TO_LONGS(nr_entries) - 1);
>          WARN_ON(rangeset_overlaps_range(mmio_ro_ranges, dev->msix_pba.first,
>                                          dev->msix_pba.last));
> +        if ( rangeset_overlaps_range(mmio_ro_ranges, dev->msix_pba.first,
> +                                        dev->msix_pba.last)) { // XXX
> +                       printk( 
> "==================================================\n");
> +                       printk( "rangeset_overlaps_range\n" );
> +                       printk( "mmio_ro_ranges = %p, dev->msix_pba.first = 
> %0lx, dev->msix_pba.last = %0lx\n",
> +                                       mmio_ro_ranges, dev->msix_pba.first, 
> dev->msix_pba.last);
> +                       printk( 
> "==================================================\n\n");
> +               }
> 
>          if ( rangeset_add_range(mmio_ro_ranges, dev->msix_table.first,
>                                  dev->msix_table.last) )

Jan


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