From: Jason Wang <jasowang@redhat.com>
To: Andrew Melnichenko <andrew@daynix.com>
Cc: dmitry.fleytman@gmail.com, qemu-devel@nongnu.org
Subject: Re: [PATCH v2] e1000e: Added ICR clearing by corresponding IMS bit.
Date: Tue, 12 May 2020 11:34:05 +0800 [thread overview]
Message-ID: <910f7851-3876-2753-08e7-67adbf64fe21@redhat.com> (raw)
In-Reply-To: <CABcq3pGvAdXazPs-91F=seUQxv3VUNVwbFOrQ42CBSLSwMw_Kg@mail.gmail.com>
On 2020/5/11 下午6:08, Andrew Melnichenko wrote:
> Yo,
>
> So I think we should implement the 82574l behavior?
>
> Well, as I understand it - its already implemented. I've added ICR
> clearance if ICR & IMS(also need to add ICR_ASSERTED check, my bad,
> I'll prepare new patch).
Yes, but it behave more like e.g 82573 not what we claim to emulate like
82574l.
>
> At first, I had hacks to clear 'msi_causes_pending' at
> 'e1000e_core_set_link_status()' before link down. It works but it's
> not a solution.
> Also, on Windows the bug doesn't reproduce. I've traced Windows and
> Linux - the difference that Windows driver clears pending by writing
> to ICR, where Linux tries to clear by reading it.
> I had another possible fix - for Linux driver(writing to ICR at
> interrupt routine).
> I've asked intel guys, does Linux driver works with a device(I don't
> have real one). Thay said that it works and suggested to check 8257x
> spec. I'll forward the message to you.
Ok.
Thanks
>
> On Sat, May 9, 2020 at 9:02 AM Jason Wang <jasowang@redhat.com
> <mailto:jasowang@redhat.com>> wrote:
>
>
> On 2020/5/9 上午2:13, Andrew Melnichenko wrote:
> > Yo, I've used OpenSDM_8257x-18.pdf specification.
> > This document was recommended by Intel guys(Also, they
> referenced to
> > that note).
> > I've made a fast fix and it works. Before that I had a fix for
> Linux
> > e1000e driver.
> > Overall, the issue was in pending interrupts that can't be
> cleared by
> > reading ICR in Linux(Windows driver clears by writing to ICR).
> >
> > You can download spec for example from:
> >
> http://iweb.dl.sourceforge.net/project/e1000/8257x%20Developer%20Manual/Revision%201.8/OpenSDM_8257x-18.pdf
>
>
> Interesting, this spec doesn't include 82574l which is what e1000e
> claims to emulate:
>
> c->vendor_id = PCI_VENDOR_ID_INTEL;
> c->device_id = E1000_DEV_ID_82574L;
>
> Looking at 82574l spec (using the link mentioned in
> e1000e_core.c), it
> said (7.4.3):
>
> In MSI-X mode the bits in this register can be configured to
> auto-clear
> when the MSI-X
> interrupt message is sent, in order to minimize driver overhead, and
> when using MSI-X
> interrupt signaling.
> In systems that do not support MSI-X, reading the ICR register clears
> it's bits or writing
> 1b's clears the corresponding bits in this register.
>
> So the auto clear is under the control of EIAC (MSIX) or
> unconditionally
> (non MSI-X).
>
> But what has been implemented in e1000e_mac_icr_read() is something
> similar to the behavior of non 82574l card.
>
> So I think we should implement the 82574l behavior?
>
> Thanks
>
>
> >
> > On Fri, May 8, 2020 at 5:21 AM Jason Wang <jasowang@redhat.com
> <mailto:jasowang@redhat.com>
> > <mailto:jasowang@redhat.com <mailto:jasowang@redhat.com>>> wrote:
> >
> >
> > On 2020/5/7 上午5:26, andrew@daynix.com
> <mailto:andrew@daynix.com> <mailto:andrew@daynix.com
> <mailto:andrew@daynix.com>>
> > wrote:
> > > From: Andrew Melnychenko <andrew@daynix.com
> <mailto:andrew@daynix.com>
> > <mailto:andrew@daynix.com <mailto:andrew@daynix.com>>>
> > >
> > > Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1707441
> > > Added ICR clearing if there is IMS bit - according to the
> note by
> > > section 13.3.27 of the 8257X developers manual.
> > >
> > > Signed-off-by: Andrew Melnychenko <andrew@daynix.com
> <mailto:andrew@daynix.com>
> > <mailto:andrew@daynix.com <mailto:andrew@daynix.com>>>
> > > ---
> > > hw/net/e1000e_core.c | 9 +++++++++
> > > hw/net/trace-events | 1 +
> > > 2 files changed, 10 insertions(+)
> > >
> > > diff --git a/hw/net/e1000e_core.c b/hw/net/e1000e_core.c
> > > index d5676871fa..302e99ff46 100644
> > > --- a/hw/net/e1000e_core.c
> > > +++ b/hw/net/e1000e_core.c
> > > @@ -2624,6 +2624,15 @@ e1000e_mac_icr_read(E1000ECore
> *core, int
> > index)
> > > e1000e_clear_ims_bits(core, core->mac[IAM]);
> > > }
> > >
> > > + /*
> > > + * PCIe* GbE Controllers Open Source Software Developer's
> > Manual
> > > + * 13.3.27 Interrupt Cause Read Register
> > > + */
> >
> >
> > Hi Andrew:
> >
> > Which version of the manual did you use? I try to use the one
> > mentioned
> > in e1000e.c which is
> >
> http://www.intel.com/content/dam/doc/datasheet/82574l-gbe-controller-datasheet.pdf.
> >
> > But I couldn't find chapter 13.3.27.
> >
> > Thanks
> >
> >
> > > + if (core->mac[ICR] & core->mac[IMS]) {
> > > + trace_e1000e_irq_icr_clear_icr_bit_ims(core->mac[ICR],
> > core->mac[IMS]);
> > > + core->mac[ICR] = 0;
> > > + }
> > > +
> > > trace_e1000e_irq_icr_read_exit(core->mac[ICR]);
> > > e1000e_update_interrupt_state(core);
> > > return ret;
> > > diff --git a/hw/net/trace-events b/hw/net/trace-events
> > > index e18f883cfd..46e40fcfa9 100644
> > > --- a/hw/net/trace-events
> > > +++ b/hw/net/trace-events
> > > @@ -237,6 +237,7 @@ e1000e_irq_icr_read_entry(uint32_t icr)
> > "Starting ICR read. Current ICR: 0x%x"
> > > e1000e_irq_icr_read_exit(uint32_t icr) "Ending ICR read.
> > Current ICR: 0x%x"
> > > e1000e_irq_icr_clear_zero_ims(void) "Clearing ICR on
> read due
> > to zero IMS"
> > > e1000e_irq_icr_clear_iame(void) "Clearing ICR on read
> due to IAME"
> > > +e1000e_irq_icr_clear_icr_bit_ims(uint32_t icr, uint32_t ims)
> > "Clearing ICR on read due corresponding IMS bit: 0x%x & 0x%x"
> > > e1000e_irq_iam_clear_eiame(uint32_t iam, uint32_t cause)
> > "Clearing IMS due to EIAME, IAM: 0x%X, cause: 0x%X"
> > > e1000e_irq_icr_clear_eiac(uint32_t icr, uint32_t eiac)
> > "Clearing ICR bits due to EIAC, ICR: 0x%X, EIAC: 0x%X"
> > > e1000e_irq_ims_clear_set_imc(uint32_t val) "Clearing IMS
> bits
> > due to IMC write 0x%x"
> >
>
next prev parent reply other threads:[~2020-05-12 3:35 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-06 21:26 [PATCH v2] e1000e: Added ICR clearing by corresponding IMS bit andrew
2020-05-08 2:21 ` Jason Wang
2020-05-08 18:13 ` Andrew Melnichenko
2020-05-09 6:01 ` Jason Wang
2020-05-11 10:08 ` Andrew Melnichenko
2020-05-12 3:34 ` Jason Wang [this message]
-- strict thread matches above, loose matches on Subject: below --
2020-12-03 13:32 Andrew Melnychenko
2020-12-03 17:57 ` Alexander Duyck
2020-12-14 11:42 ` Andrew Melnichenko
2020-12-14 16:31 ` Alexander Duyck
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=910f7851-3876-2753-08e7-67adbf64fe21@redhat.com \
--to=jasowang@redhat.com \
--cc=andrew@daynix.com \
--cc=dmitry.fleytman@gmail.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).