Not possible to shutdown the system (N900) #85
Comments
|
I've seen this too on both the N900 and Droid 4. |
|
With latest image, http://maedevu.maemo.org/images/n900/20180224/, shutdown still does not work. However, when I am in a recovery shell, with the same image/kernel, poweroff works just fine all the time. Maybe the problem is in userspace after all? |
|
I am thinking it might be watchdog related. What if DSME stops, and the watchdogs are not disabled properly? Then the device reboots. Might be related to this: |
|
Can either of you confirm that this is enabled or disabled in PMOS? |
|
There is a possible related issue where the watchdog/lifeguard kicks in and triggers a reboot when doing things like switching runlevels or sending a SIGHUP to Xorg. Fremantle has this behaviour too but I always thought of them as bugs. My personal preference would be to fix these sorts of things. In my opinion, sending a SIGHUP to any daemon should cause it to restart itself, not restart the system. It really depends on the direction you want to take the project. Do we want to make Leste behave like Fremantle or do we make it more Unix-like? If you agree with me I'll open new issues for these. |
|
Well, they do not run dsme, so they likely do not even start a watchdog, so then the kernel always takes care of it. Meaning that the issue likely doesn't even occur. I wonder what happens if we remove (as a test) the watchdog, or have dsme not kick any watchdog at all, and then power off the system. Might try it later. As for the general idea of your post, let's not make it reboot randomly. We can have named runlevels, OpenRC supports those, so in general it can be less hacky. You can make an issue for it - we also are working on cleaning up the general boot process, so there's a lot to be done and discussed there anyway. |
|
So I suppose the first obvious test would be to remove any watchdog kicking support from dsme (for the test only) and see if reboot and such works as expected. |
|
It looks like dsme has no way to close a watchdog properly, even if the magic close is supported: https://www.kernel.org/doc/Documentation/watchdog/watchdog-api.txt When the device is closed, the watchdog is disabled, unless the "Magic Close" feature is supported (see below). This is not always such a good idea, since if there is a bug in the watchdog daemon and it crashes the system will not reboot. Because of this, some of the drivers support the configuration option "Disable watchdog shutdown on close", CONFIG_WATCHDOG_NOWAYOUT. If it is set to Y when compiling the kernel, there is no way of disabling the watchdog once it has been started. So, if the watchdog daemon crashes, the system will reboot after the timeout has passed. Watchdog devices also usually support the nowayout module parameter so that this option can be controlled at runtime. Magic Close feature: If a driver supports "Magic Close", the driver will not disable the watchdog unless a specific magic character 'V' has been sent to /dev/watchdog just before closing the file. If the userspace daemon closes the file without sending this special character, the driver will assume that the daemon (and userspace in general) died, and will stop pinging the watchdog without disabling it first. This will then cause a reboot if the watchdog is not re-opened in sufficient time. So we can try to disable NOWAYOUT and see if this still happens. The right way to do this would be to implement dsme watchdog stopping support, I think? But right now it looks like dsme doesn't implement stop() at all in the initscript, but that may be by design? @freemangordon - any comments? |
|
I disabled NOWAYOUT, but 'poweroff' still seems to reboot the device (although mine is in development mode, not sure if that matters) |
|
When I boot without dsme (and thus no h-d, etc), 'poweroff' works as expected. |
|
When I implement a basic dsme kill/stop() in the openrc init script; I see this while shutting down: watchdog0: watchdog did not stop! watchdog1: watchdog did not stop! Code in question is here: Which seems to indicate that dsme MUST send the magic close command, otherwise the kernel will not stop the watchdog, and the shutdown process will fail (because it gets interrupted by the watchdog that is still running) |
|
When dsme sends magic close command on quit, then this works fine. I will prepare a new version. |
|
Version It's possible that it doesn't work for you yet, because I disabled NOWAYOUT. |
|
The alternatively, that I don't like as much, is to set a very high watchdog timeout before dsme stops. |
Installed update. Doesn't work for me. When I issue sudo poweroff, device (N900) reboots. |
|
Right, you also need to disable |
|
@freemangordon found the likely cause that dsme exits too early: 10:23 < freemangordon> ok, that's it 10:24 < Wizzup> ? 10:24 < freemangordon> https://pastebin.com/07ZRnLa1 10:24 < Wizzup> ... 10:24 < freemangordon> seems dbus is acting 10:25 < freemangordon> I don't have dbus debug symbols installed 10:25 < freemangordon> but at least we know what happens 10:25 < freemangordon> bye... 10:25 < Wizzup> ciao 10:25 < Wizzup> good work 10:26 < spiiroin> dbus exits & dsme does not handle system bus disconnect well? 10:26 < Wizzup> it looks like libdbus just calls _exit() 10:26 < Wizzup> which is immediate termination 10:26 < spiiroin> it is default behavior for some things 10:27 < Wizzup> ah, in case there is no handler 10:27 < spiiroin> like unhandled disconnect Paste contains: Thread 1 "dsme-server" hit Breakpoint 1, __GI__exit (status=1) at ../sysdeps/unix/sysv/linux/_exit.c:27 27 ../sysdeps/unix/sysv/linux/_exit.c: No such file or directory. (gdb) bt #0 0xb6dec6b8 in __GI__exit (status=1) at ../sysdeps/unix/sysv/linux/_exit.c:27 #1 0xb62ddaae in () at /lib/arm-linux-gnueabihf/libdbus-1.so.3 #2 0xb62c9058 in () at /lib/arm-linux-gnueabihf/libdbus-1.so.3 (gdb) To be continued later today. |
10:28 < spiiroin> then IIRC also things like passing invalid / not utf8 cleans strings / making method calls on diconnected but existing connection 10:28 < Wizzup> *nod* 10:29 < spiiroin> https://git.merproject.org/mer-core/dsme/commit/ae1b8ba 10:30 < Wizzup> ... we *REALLY* need to go through those commits ;) 10:30 < Wizzup> thanks |
|
@sicelo - I think it should now work with the latest dsme. (install upgrade, sync, reboot any way you like, and then try to shutdown using |
|
The problem remains after update. |
|
I propose setting nowayout to "no". That should fix the issue (taking into account PowerVR oops fix). |
|
Need to implement PowerVR kernel module oops fix either by userspace or in kernel. |
|
With the latest kernel from leste devel repo, poweroff seems to do the right thing for me. Please confirm. If you run into issues installing the new package, ensure that /boot (p1) is 'ext2' and not vfat (as in current images). |
|
With latest |
|
BTW: when we do close it, let's open a new one for enabling NOWAYOUT and fixing it proper. I think one of the issues is that openrc runs all of its own scripts, and the devuan ones. And the latter take a long time to stop, longer than the WD timeout. This might be better in Devuan ceres already. |
|
See #219 |
Attempts to halt/shutdown the system do not seem to work.
Both
shutdown -h nowandpoweroffresult in a reboot. Most of the time, the screen backlight also does not light up for uboot.The text was updated successfully, but these errors were encountered: