Re: [Qemu-devel] e1000 autoneg timing, piix/osx

[Alexander Graf <agraf@suse.de>]

On 03.07.14 15:58, Gabriel L. Somlo wrote:
> On Thu, Jul 03, 2014 at 03:20:50PM +0200, Alexander Graf wrote:
>> On 03.07.2014, at 15:17, Gabriel L. Somlo <gsomlo@gmail.com> wrote:
>>
>>> On Thu, Jul 03, 2014 at 10:04:55AM +0200, Alexander Graf wrote:
>>>>> so Ethernet, SATA, and USB, all sharing IRQ 11. Is there an easy way
>>>>> to force one of those to use a different IRQ ?
>>> Oh, and on Q35, while Ethernet (and one of the USBs) is still on IRQ 11,
>>> SATA ended up on IRQ 10, and things are fine there...
>>>
>>>> IIRC if you plug the device in a different slot, the irq distribution
>>>> should be different :).
>>> Sorry for being thick, but I'm still trying to figure out if there's a
>>> command-line way of making that happen. Re-ordering the "-device"
>>> arguments to qemu obviously doesn't make a difference in how they're
>>> assigned...
>> The magic word is "devfn" :). It's basically the token PCI uses to find out which slot and function id a device is on. You can set "devfn" with the "addr" attribute on -device.
> OK. So simply doing "-device e1000-82545em,...,bus=pci.0,addr=5" to
> move it up one slot from its default of "4" gets it set up with IRQ 10.
> As long as it doesn't share an irq line with the SATA controller, the
> network link gets detected just fine, same as on Q35.
>
> So this is not really an autonegotiation or timing bug, it's an
> unfortunate side effect of the OS X built-in proprietary e1000 driver
> not playing nice when IRQs are shared with SATA in particular. At
> least as far as I'm able to tell so far... :)
>
> So I'll send out some autoneg cleanup patches after 2.1 is officially
> out, but the "osx link on piix not working" mystery is solved as far
> as I can tell :)

Maybe only ICR bits that actually would trigger an interrupt get cleared?


Alex