On Tue, Jan 28, 2014 at 12:51:40AM +0100, Alexander Graf wrote:
On 27.01.2014, at 23:51, Gabriel L. Somlo <address@hidden> wrote:
- on Mavericks, the e1000 pci card doesn't work. In "System
Information", under "Hardware", I get nothing under "Ethernet
Cards", and "ethernet controller, pci slot 2, driver_installed=No"
under "PCI Cards". On MountainLion and earlier, "Driver Installed"
used to be "Yes", and the card used to show up under Ethernet Cards
as well, using the AppleIntel8254XEthernet.kext. This kext is
present on Mavericks as well, but doesn't seem to work there.
Does ioreg give any hints?
Nothing interesting as far as my semi-trained eye could tell, but I've
included a trimmed-down excerpt from both MountainLion (where it works)
and from Mavericks (where it doesn't) at the very end of this email.
PS. For *all* OS X versions mentioned above, I'm patching kvm to treat
monitor and mwait as NOP, and also the mysterious "ioapic polarity"
You only need to mark the mwait'ed pages as trapping and wake up the other cpu when it
hits ;). "only".
I already have a patch doing just that, which works reliably on UP,
and sometimes even on "-smp 2" :) But that's a post for the KVM list,
as soon as I re-acquaint myself with the parts of KVM I'm touching
(see www.contrib.andrew.cmu.edu/~somlo/OSXKVM/kvm-mwait-emu-20131213.patch
if you're curious). Just emulating monitor/mwait as NOP works 100% of
the time (and is 100% correct, at the expense of being 100% wasteful
of host CPU cycles). But it allows me to focus on the other moving parts
for now :)
patch without which OS X hangs at boot with "still waiting for root
device". I'll dig at this one a bit too, over the next couple of
IIRC the problem is that in our DSDT we declare the PCI interrupts as high
triggered while PCI is defined to be low triggered. Linux and Windows adhere to
PCI more than ACPI, but OSX seems to configure the IOAPIC accordingly and
doesn't see the interrupt because of that.
I remember you telling me a bit of that back when I first started.
Do you belive there's a chance we can work around this by just tweaking
ACPI on the QEMU side, and thus eliminate the need for a KVM patch ?