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

Probably there are more problems, you could also try a xen-unstable from before 
the commit that changed this code (msi.c)
Another thing that could make it eassier to debug would be to put some printk's 
around the WARN_ON's in msi.c  at the linenumbers that gave the warnings, 
showing but parts of the equation in the WARN_ON

--

Sander

Saturday, October 16, 2010, 7:14:11 PM, you wrote:

> On Sat, Oct 16, 2010 at 9:29 AM, Sander Eikelenboom
> <linux@xxxxxxxxxxxxxx> wrote:
>> Hi Bruce,
>>
>> I tripped over the same warning trying to solve my freezes.
>> Jan Beulich has posted a patch which is not in xen-unstable yet: [Xen-devel] 
>> [PATCH] x86/msi: fix inverted masks in c/s 22182:68cc3c514a0a
>>
>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxxxx>
>>
>> --- a/xen/arch/x86/msi.c
>> +++ b/xen/arch/x86/msi.c
>> @@ -549,14 +549,14 @@ static u64 read_pci_mem_bar(u8 bus, u8 s
>>         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;
>>  }
>>
>>  /**
>>
>>
>>
>> That fixes the warn, but my machine still keeps freezing non the less.
>> (but it also does so with pci=nomsi so it's not msi specific in my case)
>>
>> --
>>
>> Sander

> Hi Sander,

> Thank you.  I tried it against 4.1.0-22240 with no effect.
> I confirmed I had the right patch:

0 %>> hg diff  xen/arch/x86/msi.c

> diff -r 38ad3633ecaf xen/arch/x86/msi.c
> --- a/xen/arch/x86/msi.c        Wed Oct 13 12:01:30 2010 +0100
> +++ b/xen/arch/x86/msi.c        Sat Oct 16 10:12:31 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;
>  }

>  /**

> The boot time msi warn messages were unchanged.

> -Bruce

>>
>> Saturday, October 16, 2010, 6:14:17 PM, you wrote:
>>
>>> On Mon, Oct 11, 2010 at 2:05 PM, Bruce Edge <bruce.edge@xxxxxxxxx> wrote:
>>>> On Mon, Oct 11, 2010 at 10:12 AM, Gianni Tedesco
>>>> <gianni.tedesco@xxxxxxxxxx> wrote:
>>>>> On Fri, 2010-10-08 at 10:33 +0100, Gianni Tedesco wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I've been trying to boot stefano's minimal dom0 kernel from
>>>>>> git://xenbits.xen.org/people/sstabellini/linux-pvhvm.git
>>>>>> 2.6.36-rc1-initial-domain-v2+pat
>>>>>>
>>>>>> On xen-unstable, I get the following WARN_ON()'s from Xen when bringing
>>>>>> up the NIC's, then the machine hangs forever when trying to login either
>>>>>> over serial or NIC.
>>>>>>
>>>>>> (XEN) Xen WARN at msi.c:649
>>>>
>>>> I get the same Xen WARN messages using the current pvops/xen-next with
>>>> xen-unstable, here's the complete list for one boot, grep'd for WARN:
>>>>
>>>> (XEN) Xen WARN at msi.c:636
>>>> (XEN) Xen WARN at msi.c:649
>>>> (XEN) Xen WARN at msi.c:636
>>>> (XEN) Xen WARN at msi.c:649
>>>> (XEN) Xen WARN at msi.c:656
>>>> (XEN) Xen WARN at msi.c:636
>>>> (XEN) Xen WARN at msi.c:649
>>>> (XEN) Xen WARN at msi.c:636
>>>> (XEN) Xen WARN at msi.c:649
>>>> (XEN) Xen WARN at msi.c:656
>>>> (XEN) Xen WARN at msi.c:636
>>>> (XEN) Xen WARN at msi.c:649
>>>> (XEN) Xen WARN at msi.c:656
>>>> (XEN) Xen WARN at msi.c:636
>>>> (XEN) Xen WARN at msi.c:649
>>>> (XEN)    0000000080287db8 0(XEN) Xen WARN at msi.c:636
>>>> (XEN) Xen WARN at msi.c:649
>>>> (XEN) Xen WARN at msi.c:656
>>>>
>>>> The complete boot seq is attached.
>>>>
>>>> I do get a login at the end of the boot seq though.
>>>> My situation goes pear shaped when I try start a pv domU. The dom0
>>>> locks up after printing this on the console:
>>>>
>>>> (XEN) tmem: all pools frozen for all domains
>>>> (XEN) tmem: all pools thawed for all domains
>>>> (XEN) tmem: all pools frozen for all domains
>>>> (XEN) tmem: all pools thawed for all domains
>>>> mapping kernel into physical memory
>>>> about to get started...
>>>>
>>>> then prints these once a minute:
>>>> [  589.490894] BUG: soft lockup - CPU#0 stuck for 61s! [swapper:0]
>>>>
>>>> The xen console is still active and I can generate a diag dump, also 
>>>> attached.
>>>>
>>>> This dom0 lockup behavior started with pv-ops 2.6.32.21, all the way
>>>> to .24, rendering the later pvops kernels unusable for dom0.
>>>> The 2.6.32.18 kernel is the last one that functioned as a dom0.
>>>>
>>>> This behavior is consistent on platforms, HP proliant 380DL G6, and
>>>> G7, as well as i7 supermicros.
>>>>
>>>> -Bruce
>>>>
>>>>>
>>>>> Hmm so this appears not to be an issue with XCP kernel, in that case I
>>>>> get the warnings but everything still works fine.
>>>>>
>>>>> I will investigate further when I have some time.
>>>>>
>>>>> Gianni
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Xen-devel mailing list
>>>>> Xen-devel@xxxxxxxxxxxxxxxxxxx
>>>>> http://lists.xensource.com/xen-devel
>>>>>
>>>>
>>
>>> The latest xen-unstable, 22240 has the same "  (XEN) Xen WARN at
>>> msi.c:636 " messages with associated stack traces.
>>
>>> I spent a little more time working with this version, and except for
>>> these disconcerting messages, which do look like they are initiated by
>>> the ethernet card discovery, the system appears functional.
>>> In all cases the first occurrence is immediately after the NIC discovery:
>>
>>>  e1000e: Intel(R) PRO/1000 Network Driver - 1.0.2-k2
>>> | e1000e: Copyright (c) 1999-2008 Intel Corporation.
>>> | xen: registering gsi 16 triggering 0 polarity 1
>>> | xen_allocate_pirq: returning irq 16 for gsi 16
>>>   xen: --> irq=16
>>>   Already setup the GSI :16
>>>   e1000e 0000:06:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
>>>   e1000e 0000:06:00.0: setting latency timer to 64
>>>     alloc irq_desc for 493 on node 0
>>>     alloc kstat_irqs on node 0
>>>   (XEN) Xen WARN at msi.c:636
>>>   (XEN) ----[ Xen-4.1-unstable  x86_64  debug=y  Not tainted ]----
>>> ....
>>
>>> In case it's a NIC specific issue, I'm seeing it with both
>>>     06:00.0 Ethernet controller: Intel Corporation 82574L Gigabit
>>> Network Connection
>>> and
>>>     02:00.0 Ethernet controller: Broadcom Corporation NetXtreme II
>>> BCM5709 Gigabit Ethernet (rev 20)
>>> NICs
>>
>>> -Bruce
>>
>>
>>
>>
>>
>> --
>> Best regards,
>>  Sander                            mailto:linux@xxxxxxxxxxxxxx
>>
>>



-- 
Best regards,
 Sander                            mailto:linux@xxxxxxxxxxxxxx


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

<Prev in Thread] Current Thread [Next in Thread>