Re: [Qemu-devel] [RFC PATCH v1 2/2] e1000: adjust initial autoneg timing (for piix/osx)

[Alexander Graf]

> 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?

Alex

> 
>> -- 
>> 1.9.3