[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
- Re: [Qemu-devel] e1000 autoneg timing, piix/osx, (continued)
- Re: [Qemu-devel] e1000 autoneg timing, piix/osx, Gabriel L. Somlo, 2014/07/02
- Re: [Qemu-devel] e1000 autoneg timing, piix/osx, Alexander Graf, 2014/07/02
- Re: [Qemu-devel] e1000 autoneg timing, piix/osx, Gabriel L. Somlo, 2014/07/02
- Re: [Qemu-devel] e1000 autoneg timing, piix/osx, Alexander Graf, 2014/07/02
- Re: [Qemu-devel] e1000 autoneg timing, piix/osx, Gabriel L. Somlo, 2014/07/02
- Re: [Qemu-devel] e1000 autoneg timing, piix/osx, Alexander Graf, 2014/07/03
- Re: [Qemu-devel] e1000 autoneg timing, piix/osx, Gabriel L. Somlo, 2014/07/03
- Re: [Qemu-devel] e1000 autoneg timing, piix/osx, Alexander Graf, 2014/07/03
- Re: [Qemu-devel] e1000 autoneg timing, piix/osx, Gabriel L. Somlo, 2014/07/03
- Re: [Qemu-devel] e1000 autoneg timing, piix/osx, Alexander Graf, 2014/07/03
- Re: [Qemu-devel] e1000 autoneg timing, piix/osx,
Gabriel L. Somlo <=
- Re: [Qemu-devel] e1000 autoneg timing, piix/osx, Alexander Graf, 2014/07/03
- Re: [Qemu-devel] e1000 autoneg timing, piix/osx, Alexander Graf, 2014/07/03
- Re: [Qemu-devel] e1000 autoneg timing, piix/osx, Paolo Bonzini, 2014/07/03
- Re: [Qemu-devel] e1000 autoneg timing, piix/osx, Gabriel L. Somlo, 2014/07/03
- Re: [Qemu-devel] e1000 autoneg timing, piix/osx, Alexander Graf, 2014/07/03
Re: [Qemu-devel] [RFC PATCH v1 2/2] e1000: adjust initial autoneg timing (for piix/osx), Michael S. Tsirkin, 2014/07/02