On Thu, 2005-11-24 at 16:10 +0100, Michael Schmitz wrote:
> The power loss most probably results from communication
> between CPU and PMU breaking down,
It most certainly is. It can be the result of a very high interrupt
latency at the wrong time, a kernel crash just at the wrong time, or
something else making the PMU unhappy...
Are you guys all confirming that the problem happens on a kernel without
CONFIG_CPUFREQ enabled at all ?
Thank you for the detail to look for. I see it IS enabled in this kernel -- here's an excerpt from that part of the config file:
CONFIG_CPU_FREQ=y
CONFIG_CPU_FREQ_TABLE=y
# CONFIG_CPU_FREQ_DEBUG is not set
CONFIG_CPU_FREQ_STAT=m
CONFIG_CPU_FREQ_STAT_DETAILS=y
CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y
# CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set
CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
CONFIG_CPU_FREQ_GOV_POWERSAVE=m
CONFIG_CPU_FREQ_GOV_USERSPACE=m
CONFIG_CPU_FREQ_GOV_ONDEMAND=m
CONFIG_CPU_FREQ_GOV_CONSERVATIVE=m
CONFIG_CPU_FREQ_PMAC=y
CONFIG_PPC601_SYNC_FIX=y
CONFIG_PM=y
CONFIG_PPC_STD_MMU=y
Just to clarify -- I should set CONFIG_CPU_FREQ=n -- Anything else I should change before I compile?
Have you tried also doing (as root)
echo "0" >/proc/sys/kernel/powersave_nap
That will make the machine hotter & suck more battery (at least on
machines where nap mode is supported, that isn't the case of the
wallstreet in the first place) but it may be a good indication if that
fixes the occasional shutdown.
Yes, as you say, the powersave_nap node doesn't exist on this Wallstreet, but maybe that tidbit will help someone else. If you know any Wallstreet PMU related bits I can tweak, I'd be happy to try.
I wish I knew some action that would consistently trigger the shutdown, so I can more efficiently test it (and/or avoid it). Using a 100Mbps Ethernet PCMCIA card (instead of the built-in 10Mbps port) seems to make it shutdown more frequently, but that observation is entirely subjective. I have not yet tried using my Orinoco wireless card using this kernel....
