On Thu, Oct 29 2020 at 11:19, Heiner Kallweit wrote:
> On 29.10.2020 10:42, Thomas Gleixner wrote:
> Correct, just that the legacy PCI interrupt scenario doesn't affect old
> systems/devices only. Users may run the system with nomsi for
> whatever reason and we need to be prepared.
>
> We could add
On 29.10.2020 10:42, Thomas Gleixner wrote:
> On Thu, Oct 29 2020 at 09:42, Heiner Kallweit wrote:
>> On 29.10.2020 00:29, Jakub Kicinski wrote:
>>> Other handles may take spin_locks, which will sleep on RT.
>>>
>>> I guess we may need to switch away from the _irqoff() variant for
>>> drivers with
On Thu, Oct 29 2020 at 09:42, Heiner Kallweit wrote:
> On 29.10.2020 00:29, Jakub Kicinski wrote:
>> Other handles may take spin_locks, which will sleep on RT.
>>
>> I guess we may need to switch away from the _irqoff() variant for
>> drivers with IRQF_SHARED after all :(
>>
> Right. Unfortunatel
On 29.10.2020 00:29, Jakub Kicinski wrote:
> On Wed, 28 Oct 2020 13:17:58 +0100 Heiner Kallweit wrote:
>> On 28.10.2020 12:43, Serge Belyshev wrote:
For several network drivers it was reported that using
__napi_schedule_irqoff() is unsafe with forced threading. One way to
fix this is
On Wed, 28 Oct 2020 13:17:58 +0100 Heiner Kallweit wrote:
> On 28.10.2020 12:43, Serge Belyshev wrote:
> >> For several network drivers it was reported that using
> >> __napi_schedule_irqoff() is unsafe with forced threading. One way to
> >> fix this is switching back to __napi_schedule, but then w
On 28.10.2020 12:43, Serge Belyshev wrote:
>
>> For several network drivers it was reported that using
>> __napi_schedule_irqoff() is unsafe with forced threading. One way to
>> fix this is switching back to __napi_schedule, but then we lose the
>> benefit of the irqoff version in general. As stat
On 28.10.2020 12:43, Serge Belyshev wrote:
>
>> For several network drivers it was reported that using
>> __napi_schedule_irqoff() is unsafe with forced threading. One way to
>> fix this is switching back to __napi_schedule, but then we lose the
>> benefit of the irqoff version in general. As stat
>> [8.850099] genirq: Flags mismatch irq 18. 00010080 (eth0) vs. 2080
>> (ahci[:05:00.0])
>>
> Please provide the following info in addition:
> - dmesg
> - lspci -v
> - cat /proc/interrupts
Attached below.
[0.00] Linux version 5.9.0-10641-g424a646e072a (ssb@spider) (gcc 4.
> For several network drivers it was reported that using
> __napi_schedule_irqoff() is unsafe with forced threading. One way to
> fix this is switching back to __napi_schedule, but then we lose the
> benefit of the irqoff version in general. As stated by Eric it doesn't
> make sense to make the m
On Wed, Oct 28 2020 at 13:17, Heiner Kallweit wrote:
> On 28.10.2020 12:43, Serge Belyshev wrote:
>>> For several network drivers it was reported that using
>>> __napi_schedule_irqoff() is unsafe with forced threading. One way to
>>> fix this is switching back to __napi_schedule, but then we lose t
On Sun, 18 Oct 2020 18:38:59 +0200 Heiner Kallweit wrote:
> For several network drivers it was reported that using
> __napi_schedule_irqoff() is unsafe with forced threading. One way to
> fix this is switching back to __napi_schedule, but then we lose the
> benefit of the irqoff version in general.
For several network drivers it was reported that using
__napi_schedule_irqoff() is unsafe with forced threading. One way to
fix this is switching back to __napi_schedule, but then we lose the
benefit of the irqoff version in general. As stated by Eric it doesn't
make sense to make the minimal hard
12 matches
Mail list logo
