* [PATCH] cpufreq: return EEXIST instead of EBUSY for second registering
@ 2013-09-19 4:05 Yinghai Lu
2013-09-19 4:08 ` Viresh Kumar
0 siblings, 1 reply; 10+ messages in thread
From: Yinghai Lu @ 2013-09-19 4:05 UTC (permalink / raw)
To: Rafael J. Wysocki, Viresh Kumar
Cc: cpufreq, linux-pm, linux-kernel, Yinghai Lu
System that cpu support intel_pstate, acpi_cpufreq fail to
load, and udev keep trying until trace get filled up and
kernel crash.
The root cause is driver return ret from cpufreq_register_driver
and when some other driver take over before, it would return
EBUSY, then udev will keep trying...
cpufreq_register_driver should return EEXIST instead.
then system could boot without appending intel_pstate=disable
and still use intel_pstate.
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
---
drivers/cpufreq/cpufreq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6/drivers/cpufreq/cpufreq.c
===================================================================
--- linux-2.6.orig/drivers/cpufreq/cpufreq.c
+++ linux-2.6/drivers/cpufreq/cpufreq.c
@@ -2104,7 +2104,7 @@ int cpufreq_register_driver(struct cpufr
write_lock_irqsave(&cpufreq_driver_lock, flags);
if (cpufreq_driver) {
write_unlock_irqrestore(&cpufreq_driver_lock, flags);
- return -EBUSY;
+ return -EEXIST;
}
cpufreq_driver = driver_data;
write_unlock_irqrestore(&cpufreq_driver_lock, flags);
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [PATCH] cpufreq: return EEXIST instead of EBUSY for second registering
2013-09-19 4:05 [PATCH] cpufreq: return EEXIST instead of EBUSY for second registering Yinghai Lu
@ 2013-09-19 4:08 ` Viresh Kumar
2013-09-19 22:37 ` Rafael J. Wysocki
0 siblings, 1 reply; 10+ messages in thread
From: Viresh Kumar @ 2013-09-19 4:08 UTC (permalink / raw)
To: Yinghai Lu
Cc: Rafael J. Wysocki, cpufreq@vger.kernel.org,
linux-pm@vger.kernel.org, Linux Kernel Mailing List
On 19 September 2013 09:35, Yinghai Lu <yinghai@kernel.org> wrote:
> System that cpu support intel_pstate, acpi_cpufreq fail to
> load, and udev keep trying until trace get filled up and
> kernel crash.
>
> The root cause is driver return ret from cpufreq_register_driver
> and when some other driver take over before, it would return
> EBUSY, then udev will keep trying...
>
> cpufreq_register_driver should return EEXIST instead.
> then system could boot without appending intel_pstate=disable
> and still use intel_pstate.
>
> Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] cpufreq: return EEXIST instead of EBUSY for second registering
2013-09-19 4:08 ` Viresh Kumar
@ 2013-09-19 22:37 ` Rafael J. Wysocki
2013-09-20 1:31 ` Yinghai Lu
0 siblings, 1 reply; 10+ messages in thread
From: Rafael J. Wysocki @ 2013-09-19 22:37 UTC (permalink / raw)
To: Viresh Kumar
Cc: Yinghai Lu, cpufreq@vger.kernel.org, linux-pm@vger.kernel.org,
Linux Kernel Mailing List
On Thursday, September 19, 2013 09:38:32 AM Viresh Kumar wrote:
> On 19 September 2013 09:35, Yinghai Lu <yinghai@kernel.org> wrote:
> > System that cpu support intel_pstate, acpi_cpufreq fail to
> > load, and udev keep trying until trace get filled up and
> > kernel crash.
> >
> > The root cause is driver return ret from cpufreq_register_driver
> > and when some other driver take over before, it would return
> > EBUSY, then udev will keep trying...
> >
> > cpufreq_register_driver should return EEXIST instead.
> > then system could boot without appending intel_pstate=disable
> > and still use intel_pstate.
> >
> > Signed-off-by: Yinghai Lu <yinghai@kernel.org>
>
> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Applied, thanks!
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] cpufreq: return EEXIST instead of EBUSY for second registering
2013-09-19 22:37 ` Rafael J. Wysocki
@ 2013-09-20 1:31 ` Yinghai Lu
2013-09-20 4:23 ` Viresh Kumar
0 siblings, 1 reply; 10+ messages in thread
From: Yinghai Lu @ 2013-09-20 1:31 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Viresh Kumar, cpufreq@vger.kernel.org, linux-pm@vger.kernel.org,
Linux Kernel Mailing List
On Thu, Sep 19, 2013 at 3:37 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> On Thursday, September 19, 2013 09:38:32 AM Viresh Kumar wrote:
>> On 19 September 2013 09:35, Yinghai Lu <yinghai@kernel.org> wrote:
>> > System that cpu support intel_pstate, acpi_cpufreq fail to
>> > load, and udev keep trying until trace get filled up and
>> > kernel crash.
>> >
>> > The root cause is driver return ret from cpufreq_register_driver
>> > and when some other driver take over before, it would return
>> > EBUSY, then udev will keep trying...
>> >
>> > cpufreq_register_driver should return EEXIST instead.
>> > then system could boot without appending intel_pstate=disable
>> > and still use intel_pstate.
>> >
>> > Signed-off-by: Yinghai Lu <yinghai@kernel.org>
>>
>> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
>
> Applied, thanks!
Sorry, looks like this one is not enough.
please let me know if you prefer me send addon patch
or revised one.
Thanks
Yinghai
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] cpufreq: return EEXIST instead of EBUSY for second registering
2013-09-20 1:31 ` Yinghai Lu
@ 2013-09-20 4:23 ` Viresh Kumar
2013-09-20 5:30 ` Yinghai Lu
0 siblings, 1 reply; 10+ messages in thread
From: Viresh Kumar @ 2013-09-20 4:23 UTC (permalink / raw)
To: Yinghai Lu
Cc: Rafael J. Wysocki, cpufreq@vger.kernel.org,
linux-pm@vger.kernel.org, Linux Kernel Mailing List
On 20 September 2013 07:01, Yinghai Lu <yinghai@kernel.org> wrote:
> Sorry, looks like this one is not enough.
>
> please let me know if you prefer me send addon patch
> or revised one.
Atleast you can let us know what the problem is? And then we
can decide on that.. But anyway, you can send a new patch
based over latest linux-next (which will have your original patch),
and then leave it onto Rafael to merge it or have two patches..
(though I am quite sure he will not drop anything now, unless its
too screwed.., at worst he might revert it..)..
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] cpufreq: return EEXIST instead of EBUSY for second registering
2013-09-20 4:23 ` Viresh Kumar
@ 2013-09-20 5:30 ` Yinghai Lu
2013-09-20 13:30 ` Rafael J. Wysocki
0 siblings, 1 reply; 10+ messages in thread
From: Yinghai Lu @ 2013-09-20 5:30 UTC (permalink / raw)
To: Viresh Kumar
Cc: Rafael J. Wysocki, cpufreq@vger.kernel.org,
linux-pm@vger.kernel.org, Linux Kernel Mailing List
On Thu, Sep 19, 2013 at 9:23 PM, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> On 20 September 2013 07:01, Yinghai Lu <yinghai@kernel.org> wrote:
>> Sorry, looks like this one is not enough.
>>
>> please let me know if you prefer me send addon patch
>> or revised one.
>
> Atleast you can let us know what the problem is? And then we
> can decide on that.. But anyway, you can send a new patch
> based over latest linux-next (which will have your original patch),
> and then leave it onto Rafael to merge it or have two patches..
> (though I am quite sure he will not drop anything now, unless its
> too screwed.., at worst he might revert it..)..
looks like the crash is intermittent..., so i thought that patch fixed
the problem.
but later I found other suspicious print out.
please check new one:
https://patchwork.kernel.org/patch/2915181/
Thanks
Yinghai
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] cpufreq: return EEXIST instead of EBUSY for second registering
2013-09-20 5:30 ` Yinghai Lu
@ 2013-09-20 13:30 ` Rafael J. Wysocki
2013-09-20 17:12 ` Yinghai Lu
0 siblings, 1 reply; 10+ messages in thread
From: Rafael J. Wysocki @ 2013-09-20 13:30 UTC (permalink / raw)
To: Yinghai Lu
Cc: Viresh Kumar, cpufreq@vger.kernel.org, linux-pm@vger.kernel.org,
Linux Kernel Mailing List
On Thursday, September 19, 2013 10:30:04 PM Yinghai Lu wrote:
> On Thu, Sep 19, 2013 at 9:23 PM, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> > On 20 September 2013 07:01, Yinghai Lu <yinghai@kernel.org> wrote:
> >> Sorry, looks like this one is not enough.
Well, I've already applied this one and it makes sense to me anyway.
> >> please let me know if you prefer me send addon patch
> >> or revised one.
> >
> > Atleast you can let us know what the problem is? And then we
> > can decide on that.. But anyway, you can send a new patch
> > based over latest linux-next (which will have your original patch),
> > and then leave it onto Rafael to merge it or have two patches..
> > (though I am quite sure he will not drop anything now, unless its
> > too screwed.., at worst he might revert it..)..
>
> looks like the crash is intermittent..., so i thought that patch fixed
> the problem.
> but later I found other suspicious print out.
So, does it mean that the $subject patch fixes the issue for you to some
extent, but more changes are necessary to make it go away completely?
> please check new one:
>
> https://patchwork.kernel.org/patch/2915181/
I see.
I *think* we can just drop the module requesting stuff entirely, because it
doesn't seem to work anyway and udev is handling this for us.
Thanks,
Rafael
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] cpufreq: return EEXIST instead of EBUSY for second registering
2013-09-20 13:30 ` Rafael J. Wysocki
@ 2013-09-20 17:12 ` Yinghai Lu
2013-09-20 19:30 ` Yinghai Lu
0 siblings, 1 reply; 10+ messages in thread
From: Yinghai Lu @ 2013-09-20 17:12 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Viresh Kumar, cpufreq@vger.kernel.org, linux-pm@vger.kernel.org,
Linux Kernel Mailing List
On Fri, Sep 20, 2013 at 6:30 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> On Thursday, September 19, 2013 10:30:04 PM Yinghai Lu wrote:
>> On Thu, Sep 19, 2013 at 9:23 PM, Viresh Kumar <viresh.kumar@linaro.org> wrote:
>> > On 20 September 2013 07:01, Yinghai Lu <yinghai@kernel.org> wrote:
>> >> Sorry, looks like this one is not enough.
>
> Well, I've already applied this one and it makes sense to me anyway.
you can keep that.
>
>> >> please let me know if you prefer me send addon patch
>> >> or revised one.
>> >
>> > Atleast you can let us know what the problem is? And then we
>> > can decide on that.. But anyway, you can send a new patch
>> > based over latest linux-next (which will have your original patch),
>> > and then leave it onto Rafael to merge it or have two patches..
>> > (though I am quite sure he will not drop anything now, unless its
>> > too screwed.., at worst he might revert it..)..
>>
>> looks like the crash is intermittent..., so i thought that patch fixed
>> the problem.
>> but later I found other suspicious print out.
>
> So, does it mean that the $subject patch fixes the issue for you to some
> extent, but more changes are necessary to make it go away completely?
yes.
>
>> please check new one:
>>
>> https://patchwork.kernel.org/patch/2915181/
>
> I see.
>
> I *think* we can just drop the module requesting stuff entirely, because it
> doesn't seem to work anyway and udev is handling this for us.
looks some nehalem/westmere based system may need it when they have
several SSDTs. will double check that.
Thanks
Yinghai
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] cpufreq: return EEXIST instead of EBUSY for second registering
2013-09-20 17:12 ` Yinghai Lu
@ 2013-09-20 19:30 ` Yinghai Lu
2013-09-20 20:16 ` Rafael J. Wysocki
0 siblings, 1 reply; 10+ messages in thread
From: Yinghai Lu @ 2013-09-20 19:30 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Viresh Kumar, cpufreq@vger.kernel.org, linux-pm@vger.kernel.org,
Linux Kernel Mailing List
On Fri, Sep 20, 2013 at 10:12 AM, Yinghai Lu <yinghai@kernel.org> wrote:
>>
>> I *think* we can just drop the module requesting stuff entirely, because it
>> doesn't seem to work anyway and udev is handling this for us.
>
Yes. looks like acpi_processor_load_module() is not needed.
udev will do the work.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] cpufreq: return EEXIST instead of EBUSY for second registering
2013-09-20 19:30 ` Yinghai Lu
@ 2013-09-20 20:16 ` Rafael J. Wysocki
0 siblings, 0 replies; 10+ messages in thread
From: Rafael J. Wysocki @ 2013-09-20 20:16 UTC (permalink / raw)
To: Yinghai Lu
Cc: Viresh Kumar, cpufreq@vger.kernel.org, linux-pm@vger.kernel.org,
Linux Kernel Mailing List
On Friday, September 20, 2013 12:30:19 PM Yinghai Lu wrote:
> On Fri, Sep 20, 2013 at 10:12 AM, Yinghai Lu <yinghai@kernel.org> wrote:
> >>
> >> I *think* we can just drop the module requesting stuff entirely, because it
> >> doesn't seem to work anyway and udev is handling this for us.
> >
> Yes. looks like acpi_processor_load_module() is not needed.
> udev will do the work.
OK, I'll cut a patch to drop that stuff.
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2013-09-20 20:05 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-09-19 4:05 [PATCH] cpufreq: return EEXIST instead of EBUSY for second registering Yinghai Lu
2013-09-19 4:08 ` Viresh Kumar
2013-09-19 22:37 ` Rafael J. Wysocki
2013-09-20 1:31 ` Yinghai Lu
2013-09-20 4:23 ` Viresh Kumar
2013-09-20 5:30 ` Yinghai Lu
2013-09-20 13:30 ` Rafael J. Wysocki
2013-09-20 17:12 ` Yinghai Lu
2013-09-20 19:30 ` Yinghai Lu
2013-09-20 20:16 ` Rafael J. Wysocki
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox