I would like to see the bootchart with manual login + wait time.

dolphin_oracle wrote:I would like to see the bootchart with manual login + wait time.

+1 I think we can go off the other as frozen being default configuration... as the startup times should be the same regardless if the monitors are on or off (I think)

dolphin_oracle wrote:I would like to see the bootchart with manual login + wait time.

Dave wrote:+1 I think we can go off the other as frozen being default configuration... as the startup times should be the same regardless if the monitors are on or off (I think)

Attached..

bootchart initcall_debug printk.time=y desktop=icewm vga=791 persist_root lang=en_GB quiet splash=v disable=lx
Wait time at slim screen approx 10 seconds

well, one thing for sure, ntpupdate is done before the session launches.

sam, did you try the 10 second wait time with the monitors, or without. and if without, would you care to try with the monitors and post another bootchart?

dolphin_oracle wrote:sam, did you try the 10 second wait time with the monitors, or without.

That bootchart is with the clock and monitors in the taskbar. All are working correctly.

If I am reading the chart correctly and if the monitors and clock function properly after waiting 10 seconds then I would make a large guess (stab?) that the clock is broke by ntpdate and the monitors would freeze from acpi. As both start before slim but do not complete until a 10 second wait. Another guess would be if you wait aprox 5 seconds then login (within 3) the monitors would be frozen but the clock would work. There appears to be a 4 second window where the clock should work but not the monitors, anything before waiting 5 seconds neither would work, then anywhere from 5-9 seconds the clock should work, and anywhere from 10 seconds on both would work.


If I may question previous testing methods. How was xinitc used to bypass desktop-session. Would it in anyway have delayed startup from slim longer than 10s? Was there a process in xinitrc that needed to complete before it would start icewm-session? Was there time spent from bootup to copy and edit xinitrc? etc?

Would changing the slim.conf to load xinitrc and simply having xinitrc contain only 'exec icewm-session ' or 'icewm-session'. persist-save and reboot to avoid any delays produce the same non functioning result or a functioning result?

dave, the ~/xinitrc you asked for


#!/bin/sh

. /etc/X11/Xsession

exec icewm-session &

Dave wrote:Another guess would be if you wait aprox 5 seconds then login (within 3) the monitors would be frozen but the clock would work. There appears to be a 4 second window where the clock should work but not the monitors

It may be hard to hit that time slot but I will give it a try.

dolphin_oracle wrote:dave, the ~/xinitrc you asked for


#!/bin/sh

. /etc/X11/Xsession

exec icewm-session &

OK would commenting out or removal of the sourcing of Xsession change anything? What is etc/X11/Xsession anyway that being sourced?

Dave wrote:

dolphin_oracle wrote:dave, the ~/xinitrc you asked for


#!/bin/sh

. /etc/X11/Xsession

exec icewm-session &

OK would commenting out or removal of the sourcing of Xsession change anything? What is etc/X11/Xsession anyway that being sourced?

in this case, its a default file that loads a bunch of session variables, does a write check on /tmp, and and a few other things like error logging.

Dave wrote:If I may question previous testing methods. How was xinitc used to bypass desktop-session.

The method used to make sure desktop-session did not figure in the chain was to boot using init 3, log-in as demo, then startx to IceWM, root persistence ensured the monitors were displayed. They worked correctly each time tested that way.

SamK wrote:

Dave wrote:If I may question previous testing methods. How was xinitc used to bypass desktop-session.

The method used to make sure desktop-session did not figure in the chain was to boot using init 3, log-in as demo, then startx to IceWM, root persistence ensured the monitors were displayed. They worked correctly each time tested that way.

I'll add to SamK's note here that in this scenario, an ~/xinitrc file is not needed. The startup of X begun with"startx" will go through a whole bunch of checks to find session info, and will eventually default to a set of symlinks in /usr/bin, in our case"x-session-manager" is used, which points to icewm-session.

SamK wrote:

Dave wrote:Another guess would be if you wait aprox 5 seconds then login (within 3) the monitors would be frozen but the clock would work. There appears to be a 4 second window where the clock should work but not the monitors

It may be hard to hit that time slot but I will give it a try.

I don't think I can test the 4 sec window idea. I first tried to login before 5 seconds had elapsed i.e. before the window period started. Typing as fast as I can the monitors and clock all work correctly.

If I can't hit the preceding 5 sec period in which none should work, I can't hit the 4 sec period when the clock should but the monitors should not.

Re: 4 second window

After numerous attempts, as I suspected, I cannot pin this down via slim login.

Trying an alternative approach via automatic login of demo
acpi=off desktop=icewm vga=791 persist_root lang=en_GB quiet splash=v disable=lx
Result:
Meters in taskbar frozen.

So it seems the meters can freeze irrespective of whether acpi is activated or deactivated.

So, does VIAtech put out something like Intel's stick? Stick 8GB DDR3 in and get along for only 10W?
RasPi's emulators for x86 would lose too much? A little thin for building unicorn emulator bases?
How about an Intel stick? Is that in the candidates...hoping to lighten up on power.