qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC PATCH v1 2/2] e1000: adjust initial autoneg timing


From: Michael S. Tsirkin
Subject: Re: [Qemu-devel] [RFC PATCH v1 2/2] e1000: adjust initial autoneg timing (for piix/osx)
Date: Mon, 30 Jun 2014 20:55:54 +0300

On Mon, Jun 30, 2014 at 12:55:50PM -0400, Gabriel L. Somlo wrote:
> When running on PIIX (as opposed to q35), the stock OS X e1000
> driver (AppleIntel8254XEthernet.kext) takes longer to load and
> activete, and will "miss" the link status change interrupt
> injected when the emulated "hardware" autonegotiation completes
> (see commit 39bb8ee737595e9b264d075dfcd7d86f4d3f1133).
> 
> This patch extends the delay of the autonetotiation timer set up
> during set_phy_ctrl() to a value just large enough to work with
> the OS X driver.
> 
> Signed-off-by: Gabriel Somlo <address@hidden>
> ---
> 
> So, the loading OS X driver must take longer between its last
> write to the PHY_CTRL register and the time it starts looking
> for LSC interrupts, because at delay==500 it obviously misses
> the relevant interrupt. Making this 5500 (actually anything
> larger than 5300, but there's a bit of variation across OS X
> versions, so I rounded up a bit) has the timer fire after
> enough time has passed that the driver knows what to do when
> the interrupt from the network card fires...
> 
> Thanks,
>   Gabriel
> 
>  hw/net/e1000.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/hw/net/e1000.c b/hw/net/e1000.c
> index 2376910..2300477 100644
> --- a/hw/net/e1000.c
> +++ b/hw/net/e1000.c
> @@ -209,7 +209,7 @@ set_phy_ctrl(E1000State *s, int index, uint16_t val)
>          e1000_link_down(s);
>          DBGOUT(PHY, "Start link auto negotiation\n");
>          timer_mod(s->autoneg_timer,
> -                  qemu_clock_get_ms(QEMU_CLOCK_VIRTUAL) + 500);
> +                  qemu_clock_get_ms(QEMU_CLOCK_VIRTUAL) + 5500);
>      }
>  }


Besides being a bit hacky, it actually has a decent chance
to delay boot for guests. 500ms is probably the max we
can reasonably tolerate, even that is a bit high.

> -- 
> 1.9.3



reply via email to

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