** Changed in: qemu
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1753309
Title:
Ethernet interrupt vectors for sabrelite machine are defined backwards
This is now fixed in git master by commit 6461d7e2678fe4, which updates
the defines and also has a workaround for older guest kernels (which we
can remove if/when we model the IOMUX).
** Changed in: qemu
Status: New => Fix Committed
--
You received this bug notification because you are a
Submitted https://patchwork.kernel.org/patch/10264615/
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1753309
Title:
Ethernet interrupt vectors for sabrelite machine are defined backwards
Status
#3: Correct, Linux version 4.14 and older registers two interrupt lines,
both the correct and the wrong one. With qemu version, the kernel
receives interrupts on irq 151, with the other on 150. So, yes, I guess
it works by accident. My question is what to do with older (pre-4.14)
kernels.
"4.14+: Both versions of qemu (as-is and interrupts reverted) work fine"
Hm. I really wonder how it can be possible that Linux works with the
interrupt vectors reversed, though to be fair I have not looked at the
Linux i.MX6 ENET driver code. I suppose it's possible that the driver is
binding the
Followup on #1: The relevant upstream commit is 4c8777892e80b ("ARM:
dts: imx6qdl-sabrelite: remove erratum ERR006687 workaround").
Test results with various kernel versions:
4.14+: Both versions of qemu (as-is and interrupts reverted) work fine
4.9.y: Requires cherry-pick of 4c8777892e80b for
Swapping the interrupt pins fixes the problem on Linux v4.13 and later.
Older kernels start failing as follows.
On v4.12 and earlier, the Ethernet interface fails to instantiate with
fec 2188000.ethernet (unnamed net_device) (uninitialized): MDIO read timeout
fec: probe of
