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: Gabriel L. Somlo
Subject: Re: [Qemu-devel] [RFC PATCH v1 2/2] e1000: adjust initial autoneg timing (for piix/osx)
Date: Wed, 2 Jul 2014 08:05:46 -0400
User-agent: Mutt/1.5.23 (2014-03-12)

On Wed, Jul 02, 2014 at 12:33:16PM +0300, Michael S. Tsirkin wrote:
> On Wed, Jul 02, 2014 at 05:02:07AM -0400, 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...
> > 
> > Thanks,
> > --Gabriel
> 
> 
> Just poking around the spec I find more things
> we don't implement correctly wrt to auto-negotiation.
> For example, MII_SR_AUTONEG_CAPS isn't set, is it?
> Maybe that's why your guest doesn't work:
> it doesn't expect to get autonegotation at all?
> 
> So I have a question: does your patch actually help any guests?
> If not, maybe we should defer it to after release,
> and try to clean up autonegotiation more thouroughly for 2.2?

The patch you just accepted (handling self clearing + reserved bits
for phy_ctrl) was just "collateral cleanup" in my attempts to fix
the suspected interrupt masking issue on PIIX. As such, either now
or waiting for 2.2 is fine with me.

Not sure I'll be able to figure out the real/main issue while 2.1
bugfixes are still being accepted, but *that* would actually be really
nice :)

Thanks,
--Gabriel



reply via email to

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