qemu-devel
[Top][All Lists]
Advanced

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

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


From: Gabriel L. Somlo
Subject: Re: [Qemu-devel] e1000 autoneg timing, piix/osx
Date: Thu, 3 Jul 2014 10:14:52 -0400
User-agent: Mutt/1.5.23 (2014-03-12)

On Thu, Jul 03, 2014 at 04:02:06PM +0200, Alexander Graf wrote:
> 
> 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 <address@hidden> 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?

you mean, modify e1000's mac_icr_read() to only clear bits on read if
the mask says they should be "active" at that moment ?

The e1000 spec doesn't seem to say that though, it's "you read it,
it's now 0", regardless of the mask configuration.

http://download.intel.com/design/network/manuals/8254x_GBe_SDM.pdf
on page 293.

Thanks,
--Gabriel




reply via email to

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