On Thu, Mar 08, 2018 at 02:51:04PM +0000, Peter Maydell wrote: > On 8 March 2018 at 14:47, Guenter Roeck <li...@roeck-us.net> wrote: > > On 03/08/2018 02:50 AM, Peter Maydell wrote: > >> So do the works-by-accident kernels fail on QEMU because > >> we don't emulate some bit of the ethernet device ? > >> Ideally we could fix that so we could boot newer kernels > >> without breaking the old ones... > > > > > I don't know if a fix working for all versions of Linux is even possible. > > Creating both interrupts might be an option, but would likely cause > > other problems since some versions of Linux would handle the same > > interrupt twice, while others expect the second interrupt > > to be associated with the timer. > > Did the older Linux kernels work on the real hardware? (I > would guess so, but sometimes these things only get tested > on emulation...) If so, then in theory "make QEMU work like > the hardware" should allow all the kernels to work on QEMU. > Older kernels (4.9 and earlier) register the second interrupt on a gpio pin.
Linux 4.1, ToT qemu with this patch applied: 38: 0 gpio-mxc 6 Level 2188000.ethernet 286: 0 GIC 151 Level 2188000.ethernet Linux 4.1, ToT qemu without this patch: 38: 0 gpio-mxc 6 Level 2188000.ethernet 286: 64 GIC 151 Level 2188000.ethernet linux 4.14, ToT qemu with this patch: 64: 64 GIC-0 150 Level 2188000.ethernet 65: 0 GIC-0 151 Level 2188000.ethernet linux 4.14, ToT qemu without this patch: 64: 0 GIC-0 150 Level 2188000.ethernet 65: 64 GIC-0 151 Level 2188000.ethernet Presumably real hardware generates interrupts on the gpio pin. The qemu code specifically states that it won't generate MDIO related interrupts on gpio pins. From hw/net/imx_fec.c: /* * The MII phy could raise a GPIO to the processor which in turn * could be handled as an interrpt by the OS. * For now we don't handle any GPIO/interrupt line, so the OS will * have to poll for the PHY status. */ Linux doesn't poll the phy but expects interrupts to work. I have no idea what is supposed to happen with regular ethernet interrupts, and if those are also mapped to a gpio pin on real hardware. Any idea how to fix this ? Guenter
