Louis Garcia | 1 Oct 04:49 2006
Picon

Re: suspending to disk on FC6 not working

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
> 
(Continue reading)

Dave Jones | 1 Oct 05:21 2006
Picon

Re: suspending to disk on FC6 not working

On Sat, Sep 30, 2006 at 10:49:42PM -0400, Louis Garcia wrote:
 > On Fri, 2006-09-29 at 15:55 -0700, Pallipadi, Venkatesh wrote:
 > > 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.

Ok, I've backed that out in cpufreq.git, it'll go along to Linus soon.
If you build acpi-cpufreq as a module, and you modprobe acpi-cpufreq,
does it fail silently ? Or does it revert us back to the behaviour
where it's noisy again?

	Dave
Louis Garcia | 1 Oct 07:00 2006
Picon

Re: suspending to disk on FC6 not working

On Sat, 2006-09-30 at 23:21 -0400, Dave Jones wrote:
> On Sat, Sep 30, 2006 at 10:49:42PM -0400, Louis Garcia wrote:
>  > On Fri, 2006-09-29 at 15:55 -0700, Pallipadi, Venkatesh wrote:
>  > > 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.
> 
> Ok, I've backed that out in cpufreq.git, it'll go along to Linus soon.
> If you build acpi-cpufreq as a module, and you modprobe acpi-cpufreq,
> does it fail silently ? Or does it revert us back to the behaviour
> where it's noisy again?
> 
> 	Dave

I had not noticed it was not loaded. This maybe a bigger problem. With
the latest FC6 kernel this module gets loaded and thus suspend fails. I
(Continue reading)

Dave Jones | 1 Oct 07:05 2006
Picon

Re: suspending to disk on FC6 not working

On Sun, Oct 01, 2006 at 01:00:00AM -0400, Louis Garcia wrote:
 > On Sat, 2006-09-30 at 23:21 -0400, Dave Jones wrote:
 > > On Sat, Sep 30, 2006 at 10:49:42PM -0400, Louis Garcia wrote:
 > >  > On Fri, 2006-09-29 at 15:55 -0700, Pallipadi, Venkatesh wrote:
 > >  > > 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. 
 > >  > 
 > >  > 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.
 > > 
 > > Ok, I've backed that out in cpufreq.git, it'll go along to Linus soon.
 > > If you build acpi-cpufreq as a module, and you modprobe acpi-cpufreq,
 > > does it fail silently ? Or does it revert us back to the behaviour
 > > where it's noisy again?
 > > 
 > > 	Dave
 > 
 > I had not noticed it was not loaded. This maybe a bigger problem. With
 > the latest FC6 kernel this module gets loaded and thus suspend fails. I
 > rebuilt the same kernel but plopped this patch in. The module does not
 > want to load:
(Continue reading)

Pallipadi, Venkatesh | 1 Oct 07:07 2006
Picon

Re: suspending to disk on FC6 not working


>-----Original Message-----
>From: Louis Garcia [mailto:louisg00 <at> bellsouth.net] 
>Sent: Saturday, September 30, 2006 10:00 PM
>To: Dave Jones
>Cc: Pallipadi, Venkatesh; Pavel Machek; linux-pm <at> lists.osdl.org
>Subject: Re: [linux-pm] suspending to disk on FC6 not working
>
>On Sat, 2006-09-30 at 23:21 -0400, Dave Jones wrote:
>> On Sat, Sep 30, 2006 at 10:49:42PM -0400, Louis Garcia wrote:
>>  > On Fri, 2006-09-29 at 15:55 -0700, Pallipadi, Venkatesh wrote:
>>  > > 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
(Continue reading)

Dave Jones | 1 Oct 07:22 2006
Picon

Re: suspending to disk on FC6 not working

On Sat, Sep 30, 2006 at 10:07:16PM -0700, Pallipadi, Venkatesh wrote:

 > >I had not noticed it was not loaded. This maybe a bigger problem. With
 > >the latest FC6 kernel this module gets loaded and thus suspend fails. I
 > >rebuilt the same kernel but plopped this patch in. The module does not
 > >want to load:
 > >
 > ># /sbin/modprobe acpi-cpufreq
 > >FATAL: Error inserting acpi_cpufreq
 > >(/lib/modules/2.6.18-1.2708.cpufreq/kernel/arch/i386/kernel/cpu
 > >/cpufreq/acpi-cpufreq.ko): No such device
 > >
 > >This is why suspend works. But now this module won't load.
 > >
 > 
 > The module was not working on your laptop even when suspend was failing.
 > That is what the absence of /sys.../cpufreq says. If this module was
 > working for you earlier and stopped working recently or even otherwise
 > both this and speedstep-centrino does not work on your platform, that is
 > a separate issue. Was this module working and cpufreq supported on your
 > system with any earlier kernels?

One problem acpi-cpufreq faces when built modular compared to the
other cpufreq drivers is that there's no way of knowing before modprobe'ing
whether or not it's going to do anything or not, so userspace never knows
if it's really 'safe' to load this module.

In Fedora, we modprobe the acpi-cpufreq module if all other scaling
drivers have failed their init routines. Ie, it's treated as a fallback
"Well, nothing else worked, lets try this, and if this don't work out, bail..."
(Continue reading)

Louis Garcia | 1 Oct 07:22 2006
Picon

Re: suspending to disk on FC6 not working

On Sat, 2006-09-30 at 22:07 -0700, Pallipadi, Venkatesh wrote:
>  
> >-----Original Message-----
> >From: Louis Garcia [mailto:louisg00 <at> bellsouth.net] 
> >Sent: Saturday, September 30, 2006 10:00 PM
> >To: Dave Jones
> >Cc: Pallipadi, Venkatesh; Pavel Machek; linux-pm <at> lists.osdl.org
> >Subject: Re: [linux-pm] suspending to disk on FC6 not working
> >
> >On Sat, 2006-09-30 at 23:21 -0400, Dave Jones wrote:
> >> On Sat, Sep 30, 2006 at 10:49:42PM -0400, Louis Garcia wrote:
> >>  > On Fri, 2006-09-29 at 15:55 -0700, Pallipadi, Venkatesh wrote:
> >>  > > 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
> >>  > 
(Continue reading)

Pavel Machek | 1 Oct 07:30 2006
Picon

Re: suspending to disk on FC6 not working

Hi!

>  > I had not noticed it was not loaded. This maybe a bigger problem. With
>  > the latest FC6 kernel this module gets loaded and thus suspend fails. I
>  > rebuilt the same kernel but plopped this patch in. The module does not
>  > want to load:
>  > 
>  > # /sbin/modprobe acpi-cpufreq
>  > FATAL: Error inserting acpi_cpufreq
>  >
(/lib/modules/2.6.18-1.2708.cpufreq/kernel/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.ko):
No such device
>  > 
>  > This is why suspend works. But now this module won't load.
> 
> Right, what the STICKY patch that you reverted does is it silences the
> failure, by not unloading the module when it fails to init.
> 
> What we want is the best of both worlds: Silence when its loaded and
> init fails, and no module around.  Hmm.

? Using more kernel memory when hardware can't do acpi_cpufreq just to
get a rid of message... seems like very bad tradeoff. ACPI tables are
not hotpluggable, so it _should_ be impossible to load that module...

								Pavel
--

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
(Continue reading)

Rafael J. Wysocki | 1 Oct 14:28 2006
Picon

Re: suspending to disk on FC6 not working

On Sunday, 1 October 2006 07:22, Dave Jones wrote:
> On Sat, Sep 30, 2006 at 10:07:16PM -0700, Pallipadi, Venkatesh wrote:
> 
>  > >I had not noticed it was not loaded. This maybe a bigger problem. With
>  > >the latest FC6 kernel this module gets loaded and thus suspend fails. I
>  > >rebuilt the same kernel but plopped this patch in. The module does not
>  > >want to load:
>  > >
>  > ># /sbin/modprobe acpi-cpufreq
>  > >FATAL: Error inserting acpi_cpufreq
>  > >(/lib/modules/2.6.18-1.2708.cpufreq/kernel/arch/i386/kernel/cpu
>  > >/cpufreq/acpi-cpufreq.ko): No such device
>  > >
>  > >This is why suspend works. But now this module won't load.
>  > >
>  > 
>  > The module was not working on your laptop even when suspend was failing.
>  > That is what the absence of /sys.../cpufreq says. If this module was
>  > working for you earlier and stopped working recently or even otherwise
>  > both this and speedstep-centrino does not work on your platform, that is
>  > a separate issue. Was this module working and cpufreq supported on your
>  > system with any earlier kernels?
> 
> One problem acpi-cpufreq faces when built modular compared to the
> other cpufreq drivers is that there's no way of knowing before modprobe'ing
> whether or not it's going to do anything or not, so userspace never knows
> if it's really 'safe' to load this module.
> 
> In Fedora, we modprobe the acpi-cpufreq module if all other scaling
> drivers have failed their init routines. Ie, it's treated as a fallback
(Continue reading)

Heikki Orsila | 1 Oct 17:22 2006
Picon

Re: [RFC] OMAP1 PM Core, PM Core Implementation 2/2

Some nitpicking about the patch follows..

On Sat, Sep 30, 2006 at 02:24:35AM +0400, Eugeny S. Mints wrote:
> +static long 
> +get_vtg(const char *vdomain)
> +{
> +	long ret = 0;

Unnecessary initialisation.

> +static long 
> +set_vtg(const char *vdomain, int val)
> +{
> +	long ret = 0;

here too. This and 'int i = 0;' happens in many functions.

> +	err = omap_pm_core_verify_opt(opt);
> +	if (err != 0)
> +		goto out;
> +
> +	return (void *)opt;
> +out:
> +	kfree(opt);
> +	return NULL;
> +}

Maybe use if (err != 0) { kfree(opt); return NULL; } because goto out is 
only used once?

(Continue reading)


Gmane