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 <gso...@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?
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
