>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.
>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.
Xen-devel mailing list