Re: msi broken?

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.


iff you'd like I can test things on this board for a while ...

Thank you very much, Arno