qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] e1000e: Do not auto-clear ICR bits which aren't


From: Jan Kiszka
Subject: Re: [Qemu-devel] [PATCH] e1000e: Do not auto-clear ICR bits which aren't set in EIAC
Date: Tue, 22 May 2018 09:00:35 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666

On 2018-04-16 17:29, Peter Maydell wrote:
> On 16 April 2018 at 16:25, Jan Kiszka <address@hidden> wrote:
>> On 2018-04-01 23:17, Jan Kiszka wrote:
>>> From: Jan Kiszka <address@hidden>
>>>
>>> The spec does not justify clearing of any E1000_ICR_OTHER_CAUSES when
>>> E1000_ICR_OTHER is set in EIAC. In fact, removing this code fixes the
>>> issue the Linux driver runs into since 4aea7a5c5e94 ("e1000e: Avoid
>>> receiver overrun interrupt bursts") and was worked around by
>>> 745d0bd3af99 ("e1000e: Remove Other from EIAC").
>>>
>>> Signed-off-by: Jan Kiszka <address@hidden>
>>> ---
>>>
>>> This resolves the issue I reported on February 18 ("e1000e: MSI-X
>>> problem with recent Linux drivers").
>>>
>>>  hw/net/e1000e_core.c | 4 ----
>>>  1 file changed, 4 deletions(-)
>>>
>>> diff --git a/hw/net/e1000e_core.c b/hw/net/e1000e_core.c
>>> index ecf9b15555..d38f025c0f 100644
>>> --- a/hw/net/e1000e_core.c
>>> +++ b/hw/net/e1000e_core.c
>>> @@ -2022,10 +2022,6 @@ e1000e_msix_notify_one(E1000ECore *core, uint32_t 
>>> cause, uint32_t int_cfg)
>>>
>>>      effective_eiac = core->mac[EIAC] & cause;
>>>
>>> -    if (effective_eiac == E1000_ICR_OTHER) {
>>> -        effective_eiac |= E1000_ICR_OTHER_CAUSES;
>>> -    }
>>> -
>>>      core->mac[ICR] &= ~effective_eiac;
>>>
>>>      if (!(core->mac[CTRL_EXT] & E1000_CTRL_EXT_IAME)) {
>>>
>>
>> Ping for this - as well as https://patchwork.ozlabs.org/patch/895476.
>>
>> Given that q35 uses e1000e by default and many Linux kernel versions no
>> longer work, this should likely go into upcoming and stable versions
> 
> I'd rather not put it into 2.12 at this point in the release
> cycle unless it's a regression from 2.11, I think.

Second ping - nothing hit the repo so far, nor did I receive feedback.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux



reply via email to

[Prev in Thread] Current Thread [Next in Thread]