|
From: | Alexander Graf |
Subject: | Re: [Qemu-devel] [RFC PATCH v1 2/2] e1000: adjust initial autoneg timing (for piix/osx) |
Date: | Wed, 02 Jul 2014 11:16:52 +0200 |
User-agent: | Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 |
On 02.07.14 11:02, Gabriel L. Somlo wrote:
On Mon, Jun 30, 2014 at 08:21:43PM +0200, Alexander Graf wrote:Am 30.06.2014 um 19:55 schrieb "Michael S. Tsirkin" <address@hidden>: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.Are you sure there's not just simply some irq unmasking event after 5500ms we don't handle properly?I poked around a bit, and the e1000 interrupt mask register is NOT the problem (the LSC mask bit is clear at all times). If anything, maybe the PIIX southbridge (or something further up "north") is masking PCI interrupts (at least from e1000) until roughly 5500 ms into the boot process ? Any ideas on how I could go about verifying this (without access to the guest source, obviously :) ) would be very helpful...
Yeah, maybe the interrupt is masked and doesn't get delivered properly? See if you can trace when the e1000 emulation starts kicking an interrupt and when the guest tries to fetch it (there should be an ack register for IRQs somewhere).
If we kick it but the guest doesn't react, the problem is further down - check whether the IRQ ever got injected into the guest with trace points.
If we don't kick it, we mask it somewhere in the e1000 emulation and need to make sure we do kick once we unmask :). I don't know whether the LSC mask is the only one involved.
Alex
[Prev in Thread] | Current Thread | [Next in Thread] |