On 22/12/2020 16:16, Guenter Roeck wrote:
Hi,commit 459ca8bfa41 ("pci: Assert irqnum is between 0 and bus->nirqs in pci_bus_change_irq_level") added sanity checks to the interrupt number passed to pci_bus_change_irq_level(). That makes sense, given that bus->irq_count is indexed and sized by the number of interrupts. However, as it turns out, the interrupt number passed to this function is the _mapped_ interrupt number. The result in assertion failures for various emulations.
That doesn't sound quite right. My understanding from the other boards I have been working on is that they use the map_irq() functions recursively so that the final set_irq() is on the physical pin, so it might just be that the assert() is simply exposing an existing bug.
Examples (I don't know if there are others): - ppc4xx_pci_map_irq() maps the interrupt number to "slot - 1". Obviously that isn't a good thing to do for slot 0, and indeed results in an assertion as soon as slot 0 is initialized (presumably that is the root bridge). Changing the mapping to "slot" doesn't help because valid slots are 0..4, and only four interrupts are allocated. - pci_bonito_map_irq() changes the mapping all over the place. Whatever it does, it returns numbers starting with 32 for slots 5..12. With a total number of 32 interrupts, this again results in an assertion failure. ppc4xx_pci_map_irq() is definitely buggy. I just don't know what the correct mapping should be. slot & 3, maybe ?
Yeah that doesn't look right. Certainly both the Mac PPC machines use ((pci_dev->devfn >> 3)) & 3) plus the interrupt pin so I think you're right that this is missing an & 3 here. Does adding this allow your image to boot?
I don't really have a good solution for pci_bonito_map_irq(). It may not matter much - I have not been able to boot fuloong_2e since qemu v4.0, and afaics that is the only platform using it. Maybe it is just completely broken ?
It looks like you want this patchset posted last week: https://patchew.org/QEMU/20201216022513.89451-1-jiaxun.y...@flygoat.com/ (specifically: https://patchew.org/QEMU/20201216022513.89451-1-jiaxun.y...@flygoat.com/20201216022513.89451-4-jiaxun.y...@flygoat.com/). Zoltan was working on the VIA southbridge wiring at the start of the year and provided me a test case that would boot Linux on the fulong2e machine, so at that point in time it wasn't completely broken.
So far it does seem like these are existing bugs being exposed, but please do report back on whether the above suggestions fix the problems you are experiencing.
ATB, Mark.
