This seems like a good idea, thanks!
On Mon, May 16, 2016 at 1:55 PM, Shmulik Ladkani <
shmulik.ladk...@ravellosystems.com> wrote:
> Hi,
>
> On Mon, 16 May 2016 08:58:32 +0300, sam...@daynix.com wrote:
> > This means that on a real hardware when mit_delay==0 ( don't use the
> timer
> > ) the Ethe
Hi,
On Mon, 16 May 2016 08:58:32 +0300, sam...@daynix.com wrote:
> This means that on a real hardware when mit_delay==0 ( don't use the timer
> ) the Ethernet controller guarantees a maximum
> observable interrupt rate of 7813 interrupts/sec. Unfortunately that isn't
> the case in the emulated dev
As mentioned in the patch:
"According to the SPEC - intel PCI/PCI-X Family of Gigabit
Ethernet Controllers Software Developer's Manual, section
13.4.18 - the Ethernet controller guarantees a maximum
observable interrupt rate of 7813 interrupts/sec. If there is
no upper bound this could lead to an i
Hi Sameeh,
On Thu, 17 Mar 2016 09:37:57 +0200, sam...@daynix.com wrote:
> @@ -357,6 +357,14 @@ set_interrupt_cause(E1000State *s, int index, uint32_t
> val)
> }
> mit_update_delay(&mit_delay, s->mac_reg[ITR]);
>
> +/*
> + * According to e1000 SP
This patch introduces an upper bound for number of interrupts
per second. Without this bound an interrupt storm can occur as
it has been observed on Windows 10 when disabling the device.
According to the SPEC - Intel PCI/PCI-X Family of Gigabit
Ethernet Controllers Software Developer's Manual, sec
