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: Paolo Bonzini
Subject: Re: [Qemu-devel] [RFC PATCH v1 2/2] e1000: adjust initial autoneg timing (for piix/osx)
Date: Mon, 30 Jun 2014 20:00:47 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0

Il 30/06/2014 19:55, Michael S. Tsirkin ha scritto:
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.

It can be turned into a property though.

Paolo




reply via email to

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