On Fri, 2006-09-29 at 15:55 -0700, Pallipadi, Venkatesh wrote: > > >-----Original Message----- > >From: Dave Jones [mailto:davej at redhat.com] > >Sent: Friday, September 29, 2006 3:26 PM > >To: Pallipadi, Venkatesh > >Cc: Louis Garcia; Pavel Machek; linux-pm at lists.osdl.org > >Subject: Re: [linux-pm] suspending to disk on FC6 not working > > > >On Fri, Sep 29, 2006 at 02:35:43PM -0700, Pallipadi, Venkatesh wrote: > > > > > cpufreq_cpu_data[] = NULL; only happens when acpi_cpufreq > >driver init > > > fails; > > > Looks like acpi_cpufreq driver init is failing at some point in this > > > case and the driver is staying loaded after that failure. > >That in turn > > > seems similar to one other bug I saw recently. > > > >Ah, that was because it was marked CPUFREQ_STICKY in 2.6.18. > >That was added to work around another problem : If it was > >built modular, > >a modprobe acpi-cpufreq would be really noisy when it get an -ENODEV > > > > That's it.. This issue seems to be a side effect of that patch... > > Louis: After normal boot of 2.6.18, if you are not seeing the directory > /sys/devices/system/cpu/cpu0/cpufreq > > Then try reverting this patch > http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=c > ommit;h=911cb74bb9e77e40749abc2fca6fe74d87d940f3 > > and then check whether the suspend resume issue goes away. > > Thanks, > Venki I reverted this patch and my suspend issue is gone. Though the directory /sys/devices/system/cpu/cpu0/cpufreq is non existent, with or without this patch. -Louis
