On Thu, Sep 6, 2012 at 11:17 PM, Rafael J. Wysocki <rjw@xxxxxxx> wrote: > On Thursday, September 06, 2012, Sedat Dilek wrote: >> On Thu, Sep 6, 2012 at 10:50 PM, Andre Przywara <andre.przywara@xxxxxxx> wrote: >> > On 09/06/2012 10:30 PM, Sedat Dilek wrote: >> >> >> >> On Thu, Sep 6, 2012 at 10:08 PM, Rafael J. Wysocki<rjw@xxxxxxx> wrote: >> >>> >> >>> On Thursday, September 06, 2012, Sedat Dilek wrote: >> >>>> >> >>>> On Thu, Sep 6, 2012 at 1:48 PM, Sedat Dilek<sedat.dilek@xxxxxxxxx> >> >>>> wrote: >> >>>>> >> >>>>> On Thu, Sep 6, 2012 at 9:23 AM, Stephen Rothwell<sfr@xxxxxxxxxxxxxxxx> >> >>>>> wrote: >> >>>>>> >> >>>>>> Hi all, >> >>>>> >> >>>>> Hi, >> >>>>> >> >>>>> >> >>>>> Unfortunately, today's linux-next does not boot here on Ubuntu/precise >> >>>>> AMD64. >> >>>>> My yesterday's next-20120905 is fine. >> >>>>> >> >>>>> I throw out all my additional patches an rebuild again as "-2", but >> >>>>> this linux-image does not boot. >> >>>>> It's in very early stage. >> >>>>> I removed "quiet" etc. from kernel-command-line, but this reveals not >> >>>>> much more. >> >>>>> >> >>>>> From the attached kernel-config.diff: >> >>>>> Dunno why the 2nd is disabled now and try to turn off the 1st one in a >> >>>>> "-3" build. >> >>>>> >> >>>>> +CONFIG_X86_ACPI_CPUFREQ_CPB=y >> >>>>> -CONFIG_USB_LIBUSUAL=y >> >>>>> >> >>>> >> >>>> [ CC Rafael (cpufreq sub-maintainer) ] >> >>> >> >>> >> >>> Well, this is related to the AMD cpufreq patchset I've just added to >> >>> linux-next. I'll drop it for now until the issue is resolved. >> >>> >> >> >> >> Hi Rafael, >> >> >> >> The problem was caused by the slab/next merge (see [1]). >> >> >> >> [1] http://marc.info/?t=134695686500008&r=1&w=2 >> >> >> >>>> I hacked to turn off CONFIG_X86_ACPI_CPUFREQ_CPB, but this is not the >> >>>> root cause. >> >>>> Not sure why this setting is default YES, Rafael? >> >>>> >> >>>> To switch from upstart to systemd does not help. >> >>> >> >>> >> >>> Andre, care to have a look at this? >> >>> >> >> >> >> I am not sure if the depends-on/default-n/default-y lines are correct. >> >> Here, I am on a Intel sandy-bridge CPU, so why do I need to activate >> >> any AMD CPU workaround? >> > >> > >> > It is not a workaround, it is about keeping a feature that was in >> > powernow-k8 for 2.5 years. AMD CPUs have this sysfs knob for turning on and >> > off the boost feature, we want to keep this around for some time for >> > compatibility reasons. >> > Newer AMD CPUs (Phenoms/Barcelona and up) are now only supported by >> > acpi-cpufreq, not by powernow-k8 anymore. >> > >> > And: it will only be activated on AMD: >> > +#ifdef CONFIG_X86_ACPI_CPUFREQ_CPB >> > .... >> > + * Lets enable it only on AMD CPUs for compatibility reasons and >> > + * only if configured. This is considered legacy code, which >> > + * will probably be removed at some point in the future. >> > + */ >> > + if (check_amd_hwpstate_cpu(0)) { >> > ... >> > >> >> >> >> [ Linux-Next (next-20120906) ] >> >> >> >> 19 config X86_ACPI_CPUFREQ >> >> 20 tristate "ACPI Processor P-States driver" >> >> 21 select CPU_FREQ_TABLE >> >> 22 depends on ACPI_PROCESSOR >> >> 23 help >> >> 24 This driver adds a CPUFreq driver which utilizes the ACPI >> >> 25 Processor Performance States. >> >> 26 This driver also supports Intel Enhanced Speedstep and newer >> >> 27 AMD CPUs. >> >> 28 >> >> 29 To compile this driver as a module, choose M here: the >> >> 30 module will be called acpi-cpufreq. >> >> 31 >> >> 32 For details, take a look at<file:Documentation/cpu-freq/>. >> >> 33 >> >> 34 If in doubt, say N. >> >> 35 >> >> 36 config X86_ACPI_CPUFREQ_CPB >> >> 37 default y >> >> 38 bool "Legacy cpb sysfs knob support for AMD CPUs" >> >> 39 depends on X86_ACPI_CPUFREQ&& CPU_SUP_AMD >> >> >> >> 40 help >> >> 41 The powernow-k8 driver used to provide a sysfs knob called >> >> "cpb" >> >> 42 to disable the Core Performance Boosting feature of AMD CPUs. >> >> This >> >> 43 file has now been superseeded by the more generic "boost" >> >> entry. >> >> 44 >> >> 45 By enabling this option the acpi_cpufreq driver provides the >> >> old >> >> 46 entry in addition to the new boost ones, for compatibility >> >> reasons. >> >> >> >> Why is there no depends-on "X86_POWERNOW_K8" (see above help-text)? >> > >> > >> > Because this driver lost the support for newer CPUs and thus also this >> > feature. We migrate this feature over to acpi-cpufreq. >> > >> > >> >> I have set CONFIG_CPU_SUP_AMD=y which leads always to >> >> CONFIG_X86_ACPI_CPUFREQ_CPB=y. >> >> As said Intel SNB CPU! >> > >> > >> > As said it does not hurt if you boot it on an Intel CPU, the code will not >> > be run. >> > >> > >> >> >> >> What about this (untested)? >> >> >> >> ----- SNIP ----- >> >> config X86_ACPI_CPUFREQ_CPB >> >> bool "Legacy cpb sysfs knob support for AMD CPUs" >> >> depends on X86_ACPI_CPUFREQ >> >> default y if X86_POWERNOW_K8&& CPU_SUP_AMD >> > >> > >> > Powernow-K8 does not support CPB anymore, this code is now in acpi-cpufreq. >> > So a dependency on the old driver does not help. >> > >> > Are there still any problems with this patchset? Or are you only wondering >> > about the new config switch? >> > >> >> Just wondering... Fell over it when digging into my boot-problem (this >> appeared as a new Kconfig option, so). >> Thanks for the explanations! > > Ah, OK. I got the impression that the patchset caused a problem to happen for > you. I suppose it's fine to keep it in linux-next after all, then? > Please, keep it! My system boots with the slab-next-fixes! My apologies for my curiosity - asking should be allowed, anyway :-). - Sedat - > Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
