Re: msi broken?

On Wed, 2009-03-11 at 14:47 +0100, Arno J. Klaassen wrote:
> Scott Long <scottl_at_samsco.org> writes:
> 
> > Robert Noland wrote:
> >> On Wed, 2009-03-11 at 00:36 +0100, Arno J. Klaassen wrote:
> >>> John Baldwin <jhb_at_freebsd.org> writes:
> >>>
> >>>> On Tuesday 10 March 2009 3:00:00 pm Arno J. Klaassen wrote:
> >>>>> John Baldwin <jhb_at_freebsd.org> writes:
> >>>>>
> >>>>>> On Tuesday 10 March 2009 10:08:59 am Arno J. Klaassen wrote:
> >>>>>>> Hello,
> >>>>>>>
> >>>>>>> when upgrading this morning from a March 1 -current, if_bge
> >>>>>>> stopped working (and irq256: bge0 not showing up in
> >>>>>>> vmstat -i ). Setting hw.pci.enable_msi="0" makes it work again.
> >>>>>> Can you get a verbose dmesg (boot -v) with MSI enabled?
> >>>> Ok, so you are getting MSI interrupts assigned and routed ok.  Can
> >>>> you try disabling the code that sets the INTx_MASK flag in the PCI
> >>>> command register in sys/dev/pci/pci.c:pci_setup_intr()?
> >>> grr : "rid" sure is 1 for the if_bge interrupt. Please tell me which
> >>> lines of code set the INTx_MASK flag. Thanx, more tomorrow.
> >>
> >> if rid is 0, the chip should be using INTx.  if rid > 0 then it should
> >> be using MSI.
> >>
> >>
> >>                         }
> >>                         mte->mte_handlers++;
> >>                 }
> >> #if 0 /* Comment this out/*
> >>                 /* Make sure that INTx is disabled if we are using MSI/MSIX */
> >>                 pci_set_command_bit(dev, child, PCIM_CMD_INTxDIS);
> >> #endif
> >>         bad:
> >>                 if (error) {
> >>                         (void)bus_generic_teardown_intr(dev, child, irq,
> >>                             cookie);
> >>                         return (error);
> >>
> >> robert.
> >>
> >
> > If this turns out to help this particular gentleman,
> 
> yes it does ;) with otherwise clean sources
> 
> sorry I did not understand directly what you asked me to do
> 
> > then I'd like to
> > suggest a further test of having the bge driver explicitly reset the
> > the INTxDIS bit after calling bus_setup_intr().  If that works, then I
> > strongly suggest that we treat this as a localized quirk that drivers
> > will need to manage for themselves, and not something that the PCI layer
> > should try to control.  It might be possible to set up some sort of
> > hint system for drivers to programatically tell the PCI layer to treat
> > this bit special for a particular device instance.  What I don't want
> > to see is the PCI layer growing yet another hidden quirk table of
> > PCI IDs.  This kind of quirk knowledge belongs in the driver.
> 

Ok, well I agree with Scott, this needs to be addressed in the bge
driver.

robert.

> iff you'd like I can test things on this board for a while ...
> 
> Thank you very much, Arno
-- 
Robert Noland <rnoland_at_FreeBSD.org>
FreeBSD