Re: msi broken?

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, 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.

Scott