On Fri, Sep 20, 2013 at 6:30 AM, Rafael J. Wysocki <rjw@xxxxxxx> 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@xxxxxxxxxx> wrote: >> > On 20 September 2013 07:01, Yinghai Lu <yinghai@xxxxxxxxxx> 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 cpufreq" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
