Re: Bug#374579: general protection error with linux-image-2.6.16-2-amd64-k8-smp [Re: Bug#374579: cpufreqd: crashing on startup (amd64, Athlon 64 X2)]
On Wed, Jun 21, 2006 at 07:58:59PM +0200, Mattia Dongili wrote:
> On Wed, Jun 21, 2006 at 04:45:09PM +1000, Vincent Ho wrote:
> > On Tue, Jun 20, 2006 at 06:46:07PM +0200, Mattia Dongili wrote:
> >
> > > Linus says that maybe
> > > echo 0 > /proc/sys/kernel/randomize_va_space
> > > can workraround the problem.
> > >
> > > Can you try it?
> >
> > This didn't seem to make any difference. I should add that it doesn't
> > always trigger the kernel message, but in any case it never starts
> > successfully (so presumably segfaults without kernel message).
> >
> > When tracing the program in gdb, I noticed that the cpufreqd_log()
> > function was opening syslog above (ie. log_opened == 0, so it calls
> > openlog() to do so). I'm beginning to think it's suspicious that adding
> > -V4 to the arguments makes a difference. In fact weirdly enough, adding
> > -V 4,5 or 2 helps, but -V3 doesn't. I presume adding that alters what
> > gets output and thus exactly when syslog is opened.
>
> it's printing with LOG_ERR there (== 3) so using a verbosity level of
> 3,4,5 doesn't make any difference on the code path...
> Anyway that code (apm plugin and logging code) is exactely the same as
> 2.0.0, this makes the thing even more wierd (on a cpufreqd perspective).
Agreed. You wouldn't think it makes a difference, but it consistently
does which is quite odd.
> Out of curiosity, does moving cpufreqd_apm.{so,la} away from
> /usr/lib/cpufreqd helps? or does it simply crash in a different place?
Yes, I tried that already. It simply crashes on another plugin (I think
it was pmu), presumably the next one in the list.
--
Vincent Ho
"If we hit that bullseye, the rest of the dominos will fall like a house
of cards. Checkmate."
Reply to: