Re: Bug#459573: cpufrequtils appears to cause my machine to freeze
reassign 459573 linux-2.6
thanks
Sorry,
I asked for more info from the submitter but he never got back to me and
the bug report went off of my radar.
The kernel of the OP is pretty old, close at your discretion.
On Mon, Jan 14, 2008 at 02:02:36PM +0900, Mattia Dongili wrote:
> On Mon, Jan 07, 2008 at 10:33:59PM +1100, Cameron Horsburgh wrote:
> > Package: cpufrequtils
> > Version: 002-5
> > Severity: important
> >
> > *** Please type your report below this line ***
> >
> > Hi folks,
> >
> > I've just installed a new Lenny system from a recent Lenny netinst
> > CD. I've had an issue with random system freezes that doesn't appear
> > to respond to a remote login or even alt-SysRq. However, this only
> > seemed to happen in multiuser mode --- I've had no problem at all with
> > a single user login. The logs don't seem to tell me much, although
> > there seems to be a lot of things regarding acpi and the cpu scaling
> > in the second or two before the point where the freeze presumably
> > happens. Typical output looks something like:
> >
> > Jan 7 20:53:00 mercury kernel: input: Power Button (FF) as /class/input/input3
> > Jan 7 20:53:00 mercury kernel: ACPI: Power Button (FF) [PWRF]
> > Jan 7 20:53:00 mercury kernel: input: Power Button (CM) as /class/input/input4
> > Jan 7 20:53:00 mercury kernel: ACPI: Power Button (CM) [PWRB]
> > Jan 7 20:53:00 mercury kernel: input: Sleep Button (CM) as /class/input/input5
> > Jan 7 20:53:00 mercury kernel: ACPI: Sleep Button (CM) [SLPB]
> > Jan 7 20:53:01 mercury kernel: Marking TSC unstable due to: cpufreq changes.
> > Jan 7 20:53:01 mercury kernel: Time: acpi_pm clocksource has been installed.
> > Jan 7 20:53:01 mercury kernel: lp0: using parport0 (interrupt-driven).
> > Jan 7 20:53:01 mercury kernel: Clocksource tsc unstable (delta = -145741813 ns)
> >
> > There is often something to do with the avahi system as well in there,
> > but that appears to be quite common in the log. Lines similar to these
> > always seem to appear in the second or two before the end of the log
> > for that session.
> >
> > To investigate the issue I booted to runlevel three several times. I
> > initially set the runlevel to be identical to runlevel one and
> > gradually introduced new services for each new boot. I tried several
> > combinations of the acpi, cpufrequtils and avahi scripts, and tried to
> > coax the machine to freeze. It did a few times, and the only common
> > element seems to be the presence of cpufrequtils in the start up. The
> > load on the machine doesn't appear to be a factor.
> >
> > Of course, this sort of testing does take a long time, and it's quite
> > possible I've missed something. The freezes appear to be completely
> > random, so it's also possible I haven't waited long enough for a
> > freeze to manifest in some of my successful tests.
>
> Hummmm... it's hardly related to userspace. It sounds much more like a
> kernel problem.
> Try to boot in single user mode once again and load the cpufreq kernel
> modules by hand (that is what the cpufrequtils init script actually
> does) and set the ondemand governor. See if your system survives.
>
> Still it really sounds like a kernel problem.
> Also, booting with clocksource=acpi_pm may help.
>
> Let me know
> --
> mattia
> :wq!
>
>
>
--
mattia
:wq!
Reply to: