| Message ID | 1379563520-7221-1-git-send-email-yinghai@kernel.org (mailing list archive) |
|---|---|
| State | Accepted, archived |
| Headers | show |
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> -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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!
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 -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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..).. -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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.
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);
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(-) -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html