RE: [Xen-devel] Re: xen dependant on pcpu 0 ?

["Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx>]

>-----Original Message-----
>From: Jan Beulich [mailto:JBeulich@xxxxxxxxxx]
>Sent: Wednesday, October 13, 2010 10:27 PM
>To: Sander Eikelenboom
>Cc: Ian; Keir Fraser; Jeremy Fitzhardinge; Jiang, Yunhong;
>xen-devel@xxxxxxxxxxxxxxxxxxx; Konrad Rzeszutek Wilk
>Subject: [Xen-devel] Re: xen dependant on pcpu 0 ?
>
>>>> On 13.10.10 at 15:36, Sander Eikelenboom <linux@xxxxxxxxxxxxxx> wrote:
>> it's this one:
>> WARN_ON(msi->table_base != read_pci_mem_bar(bus, slot, func, bir));
>
>Yeah, read_pci_mem_bar() uses an inverted mask in two places.
>Would you remove the ~ from the two uses of PCI_BASE_ADDRESS_MEM_MASK
>in that function and try again?
>
>(Yunhong, you had tested the patch that introduced this, and this
>warning would basically trigger unconditionally as it stands. Didn't
>you notice that in your logs?)

A bit amazing to me, but I do remember I didn't notice such log.
And seems with this bug, the patch itself should not work at all, since the 
PBA_addr is not correct, but I do remember with attached test module, and your 
patch, the write_vector() will cause fault.

--jyh



>
>The main thing however, if I correctly remember the context of this
>thread, is that this code was only recently introduced and doesn't
>exist in the 4.0 tree, so your original problem is unlikely caused by it.
>
>> I have added some printk's .. and read_pci_mem_bar seems to return a bogus
>> value .. the pba_addr is used later in the function, but i can't oversee if
>> and when this could have implications.
>> This also occurs when disabling the pci_resource_align on the kernel line.
>> In the same function it seems to trigger
>>            if ( d )
>>             {
>>                 /* XXX How to deal with existing mappings? */
>>             }
>>
>> Which seems to be a bit odd for a freshly booted system with no domU
>> restarts ?
>
>No, the comment refers to potentially existing mappings (which
>would need to be actively searched for). It doesn't mean there have
>to be any.
>
>Jan

Attachment: ro_msi.c
Description: ro_msi.c

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