On Tue, Mar 27, 2012 at 3:24 PM, Roland Dreier <roland@xxxxxxxxxxxxxxx> wrote: > Just to follow up on this, it turns out this is a bug in how the > Mellanox firmware deals with FLR (function level reset). The > FW will be fixed in a future release, but in the meantime I've > been able to work around this with the following hack (probably > going to be whitespace destroyed by the gmail web interface > I'm using, but you should be able to recreate it if you care): > > --- a/drivers/pci/quirks.c > +++ b/drivers/pci/quirks.c > @@ -3085,6 +3085,12 @@ static int reset_intel_82599_sfp_virtfn(struct > pci_dev *dev, int probe) > return 0; > } > > +static int reset_mellanox_dev(struct pci_dev *dev, int probe) > +{ > + /* skip FLR, it busts the Mellanox FW */ > + return 0; > +} > + > #define PCI_DEVICE_ID_INTEL_82599_SFP_VF 0x10ed > > static const struct pci_dev_reset_methods pci_dev_reset_methods[] = { > @@ -3092,6 +3098,8 @@ static const struct pci_dev_reset_methods > pci_dev_reset_methods[] = { > reset_intel_82599_sfp_virtfn }, > { PCI_VENDOR_ID_INTEL, PCI_ANY_ID, > reset_intel_generic_dev }, > + { PCI_VENDOR_ID_MELLANOX, 0x673c, > + reset_mellanox_dev }, > { 0 } > }; And just to be clear, this is in the host kernel to avoid FLR there. The guest running the standard kernel would never do FLR anyway, so with the hack above in the host, the standard driver works fine. - R. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html