Scott Long <scottl@samsco.org> writes:
quoted text > Robert Noland wrote:
>> On Wed, 2009-03-11 at 00:36 +0100, Arno J. Klaassen wrote:
>>> John Baldwin <jhb@freebsd.org> writes:
>>>
>>>> On Tuesday 10 March 2009 3:00:00 pm Arno J. Klaassen wrote:
>>>>> John Baldwin <jhb@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
quoted text > 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
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
