On 02/01/2016 04:17 AM, Igor Mammedov wrote: > On Fri, 29 Jan 2016 09:13:15 -0600 > Wei Huang <w...@redhat.com> wrote: > >> On 01/29/2016 08:50 AM, Peter Maydell wrote: >>> On 29 January 2016 at 14:46, Shannon Zhao <shannon.z...@linaro.org> wrote: >>>> On 2016/1/29 22:35, Wei Huang wrote: >>>>> On 01/29/2016 04:10 AM, Shannon Zhao wrote: >>>>>> This makes ACPI work well but makes DT not work. The reason is systemd or >>>>>> acpid open /dev/input/event0 failed. So the interrupt could be injected >>>>>> and >>>>>> could see under /proc/interrupts but guest doesn't have any action. I'll >>>>>> investigate why it opens failed later. >>>>> >>>>> >>>>> That is interesting. Could you try it with the following? This reverses >>>>> the order to down-up and worked on ACPI case. >>>>> >>>> Yeah, that's very weird. >>>> >>>>> qemu_set_irq(qdev_get_gpio_in(pl061_dev, 3), 0); >>>>> qemu_set_irq(qdev_get_gpio_in(pl061_dev, 3), 1); >>>>> >>>> I'll try this tomorrow. But even if this works, it's still weird. >>> >>> I wonder if we should be asserting the GPIO pin in the powerdown-request >>> hook and then deasserting it on system reset somewhere... >> >> This is another possibility. We can try to reset the pl061 state by >> hooking up with dc->reset and see what happens. > I think that's what we do on x86.
So the device state is wrong after reset. I just sent out a fix for it, which was verified on ACPI code path. Basically the old_in_data is stale after reboot, causing QEMU to believe that it isn't necessary to raise up IRQ again for the second reboot/shutdown (see s->old_in_data ^ s->data in pl061.c file). Shannon: could you double check from your side with my patch? -Wei > >> >>> >>> thanks >>> -- PMM >>> >> >