qemu-devel
[Top][All Lists]
Advanced

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

[Qemu-devel] [RFC PATCH v1 0/2] e1000: More link negotiation vs. OS X


From: Gabriel L. Somlo
Subject: [Qemu-devel] [RFC PATCH v1 0/2] e1000: More link negotiation vs. OS X
Date: Mon, 30 Jun 2014 12:55:48 -0400

So I accidentally noticed this morning that my previous batch of
e1000 link negotiation patches (specifically, commit 39bb8ee737...)
only fix the problem on q35, but (at least on OS X 10.8 and 10.9)
not also on piix.

After digging around a bit, I came up with the following two issues:

  - 1/2 set_phy_ctrl() seems to act on the value about to be written
        to the phy ctrl. register, but not actually write the value
        to the register! Assuming that's not intentional, once I fix
        it and write the register, I can use the factored-out check
        for autoneg availability from earlier ( have_autoneg() ) if
        I move it before set_phy_ctrl() to avoid a forward declaration.

  - 2/2 the timer delay requested from set_phy_ctrl() is currently 500,
        which, at least on piix + OS X + the built-in e1000 driver, fires
        too early (on piix, OS X takes longer to start paying attention
        to LSC interrupts than it does on q35, for some reason I'm not
        yet clear about). Increasing the timer delay to 5500 (by trial
        and error, possibly specific to my dev machine -- a macpro1,1)
        has it fire, bring the link up, and inject the LSC late enough
        that the OS X driver will be ready for it.

I'm curious what you all think of this. If e.g. patch 1/2 makes sense,
I'd be OK with having it go in without 2/2, which may feel a bit hacky :)

But mainly I'm looking to be educated about what I might have missed :)

Thanks much,
  Gabriel

Gabriel L. Somlo (2):
  e1000: clean up set_phy_ctrl function
  e1000: adjust initial autoneg timing (for piix/osx)

 hw/net/e1000.c | 27 ++++++++++++++-------------
 1 file changed, 14 insertions(+), 13 deletions(-)

-- 
1.9.3




reply via email to

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