|
|
|
|
|
|
|
|
|
|
xen-devel
Re: [Xen-devel] Re: Comments on Xen bug 1732
On Wed, 2011-03-16 at 08:22 +0000, Jan Beulich wrote:
> >>> On 15.03.11 at 19:30, Gianni Tedesco <gianni.tedesco@xxxxxxxxxx> wrote:
> > ixgbevf: eth: ixgbevf_reset: PF still resetting
>
> And nothing interesting in Dom0's logs?
Nothing of interest in the kernel messages no.
> > And correspondingly no Tx or Rx traffic at all. It all seems very much
> > like a lack of interrupts, but /proc/interrupts shows good numbers:
> >
> > 201: 146 PCI-MSI-X eth-rx-0
> > 209: 140 PCI-MSI-X eth-tx-0
> > 217: 8 PCI-MSI-X eth:mbx
>
> With the above, I'd guess more towards a PF <-> VF communication
> problem (which I can say nothing about).
Actually, I do get this from the dom0 kernel:
ixgbe: eth5: ixgbe_rcv_msg_from_vf: Set MAC msg received from vf 0
> > Furthermore this used to work on xen 3.4 but fails on 4.1 so it seems to
> > be a regression. One other notable change is the assignments of the
> > MSI-X vectors that I see when hitting the Q debug key:
> >
> > On 3.4:
> > (XEN) 04:10.0 - dom 1 - MSIs < 66 74 82 >
> >
> > On 4.1:
> > (XEN) 04:10.1 - dom 0 - MSIs < 117 118 119 >
>
> dom 1 on 3.4 vs dom 0 on 4.1? And different functions? Doesn't
> look like a 1:1 comparison to me.
Yeah they are different machines with the same SR-IOV NIC (similar
enough hardware wise). But the point is the different assigned domains,
bear in mind that in both cases the function in question is assigned to
a guest at the time the debug key was pressed.
> > Any ideas?
>
> Not really. Despite me not thinking that the change in question
> (that introduced the WARN_ON()s) has any functionality impact
> (it's really only about trying to write protect certain MMIO
> ranges, with the WARN_ON()s reporting that this didn't work as
> expected) - did you try reverting it (and its follow-up fixes)?
No change.
Gianni
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
|
|