qemu-arm
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v3 1/1] hw/arm/aspeed:Add vpd data for Rainier machine


From: Andrew Jeffery
Subject: Re: [PATCH v3 1/1] hw/arm/aspeed:Add vpd data for Rainier machine
Date: Thu, 25 May 2023 10:00:35 +0930
User-agent: Cyrus-JMAP/3.9.0-alpha0-441-ga3ab13cd6d-fm-20230517.001-ga3ab13cd


On Wed, 24 May 2023, at 17:14, Joel Stanley wrote:
> On Wed, 24 May 2023 at 06:38, Cédric Le Goater <clg@kaod.org> wrote:
>>
>> But, I also got this :
>>
>>    root@p10bmc:~# [   91.656331] watchdog: watchdog0: watchdog did not stop!
>>    [   91.734858] systemd-shutdown[1]: Using hardware watchdog 'aspeed_wdt', 
>> version 0, device /dev/watchdog0
>>    [   91.735766] systemd-shutdown[1]: Watchdog running with a timeout of 
>> 1min.
>>    [   91.987363] systemd-shutdown[1]: Syncing filesystems and block devices.
>>    [   93.471897] systemd-shutdown[1]: Sending SIGTERM to remaining 
>> processes...
>>
>> and the machine rebooted.
>>
>> Joel had the same problem :
>>
>>    https://github.com/openbmc/qemu/issues/39
>>
>> Is it unrelated ? I haven't started a rainier in 2 years at least so I can
>> not tell.
>
> I don't think it's related to Ninad's patches.
>
> I am able to reproduce the issue on my old Skylake x86 machine, but it
> doesn't happen on my M1 mac mini.
>
> I suspect the emulation is moving too slowly, but the host's wall
> clock is still ticking, so all of a sudden the BMC finds out that time
> has passed an the watchdog bites. I could be wrong.

Yeah, I also suspect this is occurring. In some cases we see output
like:

```
[  295.474921] hrtimer: interrupt took 411679950 ns
Watchdog timer 0 expired.
```

This suggests that we've exhausted the three iterations of the hrtimer
callback list from the hrtimer interrupt[1]. Too much stuff happening
for the time-keeping we have.

[1]: 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/kernel/time/hrtimer.c?h=v6.3#n1869

However, regarding Cédric's log above, a reboot is expected on the first
boot of a fresh image when there's valid VPD available. For the first
boot of a fresh image we configure the kernel with a minimal devicetree
that allows us to read the VPD data. This determines the system we're
actually on and configures an appropriate devicetree for subsequent
boots. We then reboot to pick up the new devicetree.

The devicetree to use is stored in the u-boot environment (in
`fitconfig`).

Andrew



reply via email to

[Prev in Thread] Current Thread [Next in Thread]