2008/9/30 Stefan Bader <[email protected]>:
> Ingo Molnar wrote:
>>> Someone from the community found out, that after repeatedly unloading
>>> and loading a device driver that uses MSI IRQs, the system eventually
>>> assigned the vector initially reserved for IRQ0 to the device driver.
>>
>>> The reason for this is, that although IRQ0 is tied to the
>>> FIRST_DEVICE_VECTOR when declaring the irq_vector table, the
>>> corresponding bit in the used_vectors map is not set. So, if vectors
>>> are released and assigned often enough, the vector will get assigned
>>> to another interrupt. This happens more often with MSI interrupts as
>>> those are exclusively using a vector.
>>>
>>> Fix this by setting the bit for the FIRST_DEVICE_VECTOR in the bitmap.
>>
>> hi, the IO-APIC code got unified in the x86 tree for v2.6.28.
>>
>> So could you please send the fix against tip/master:
>>
>> http://people.redhat.com/mingo/tip.git/README
>>
>> Thanks,
>>
>> Ingo
>
> I can't see this as required for tip. FIRST_DEVICE_VECTOR is there defined
> distinct to the ISA IRQs (IRQ15_VECTOR+2) while it is defined to be equal to
> IRQ0_VECTOR on 2.6.27 and before (at least down to 2.6.24).
>
Hi Ingo,
I didn't see any follow up, so for clarification: there is nothing to
fix in tip but the bug is there in kernels between 2.6.24 and 2.6.27.
Could you push it to 2.6.27 and possibly to the stable trees?
Stefan
* Stefan Bader <[email protected]> wrote:
> Hi Ingo,
>
> I didn't see any follow up, so for clarification: there is nothing to
> fix in tip but the bug is there in kernels between 2.6.24 and 2.6.27.
> Could you push it to 2.6.27 and possibly to the stable trees?
it's too late for v2.6.27 - this bug permeates so many kernel versions
that it's clearly not in the '2.6.27 regression' category. But it can be
asked to be included in -stable after v2.6.27 is released.
Ingo