On Wed, Jun 10, 2015 at 01:06:27PM +0100, Jan Beulich wrote: > >>> On 10.06.15 at 13:43, <m...@redhat.com> wrote: > > On Wed, Jun 10, 2015 at 08:00:55AM +0100, Jan Beulich wrote: > >> >>> On 08.06.15 at 13:28, <m...@redhat.com> wrote: > >> > On Mon, Jun 08, 2015 at 11:55:22AM +0100, Jan Beulich wrote: > >> >> while function 0 has > >> >> > >> >> 0x10: Base Address Register 0 = 0xca23000c (Memory space, 64-bit > >> >> access, prefetchable) > >> >> 0x18: Base Address Register 2 = 0xca24000c (Memory space, 64-bit > >> >> access, prefetchable) > >> >> 0x20: Base Address Register 4 = 0xca25000c (Memory space, 64-bit > >> >> access, prefetchable) > >> >> > >> >> and function 1 > >> >> > >> >> 0x10: Base Address Register 0 = 0xca20000c (Memory space, 64-bit > >> >> access, prefetchable) > >> >> 0x18: Base Address Register 2 = 0xca21000c (Memory space, 64-bit > >> >> access, prefetchable) > >> >> 0x20: Base Address Register 4 = 0xca22000c (Memory space, 64-bit > >> >> access, prefetchable) > >> >> > >> >> > Does the sibling device have a BAR overlapping the address? > >> >> > >> >> No, its BARs are fully separate. > >> > > >> > Judging from the above, it's actually function 1's BAR 2 that > >> > is accessed? Are you saying disabling memory on function 0 > >> > breaks function 2 somehow? > >> > >> Oops, just noticed I didn't reply to this. Not sure how you > >> come to that conclusion - the ITP log says that the bad write is to > >> 0xca25004c. > > > > Look at the bridge configuration though - looks like it > > will only forward transactions to 0xca21XXXX. > > Anything else will be terminated by the bridge itself. > > Right, that's what I had pointed out before, but then again things > work prior to the guest shutting down (and in the absence of any > guest), even if I can't explain why or how. > > Jan
I have a wild idea. Maybe there's a chance function 1 sends the offending write to 0xca25000c, then gets confused and crashes if that fails? -- MST
