| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <CA+icZUW_wkFA5giQGWeVypMtD3coT8FBwzZ6bNSEOvfasCAF_g@mail.gmail.com>
Date: Thu, 6 Sep 2012 23:15:25 +0200
From: Sedat Dilek <sedat.dilek@...il.com>
To: "Rafael J. Wysocki" <rjw@...k.pl>
Cc: Andre Przywara <andre.przywara@....com>,
Stephen Rothwell <sfr@...b.auug.org.au>,
linux-next@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
Matthew Garrett <mjg@...hat.com>,
Linux PM list <linux-pm@...r.kernel.org>,
Thomas Renninger <trenn@...e.de>
Subject: Re: linux-next: Tree for Sept 6 (does not boot on AMD64)
On Thu, Sep 6, 2012 at 11:17 PM, Rafael J. Wysocki <rjw@...k.pl> wrote:
> On Thursday, September 06, 2012, Sedat Dilek wrote:
>> On Thu, Sep 6, 2012 at 10:50 PM, Andre Przywara <andre.przywara@....com> wrote:
>> > On 09/06/2012 10:30 PM, Sedat Dilek wrote:
>> >>
>> >> On Thu, Sep 6, 2012 at 10:08 PM, Rafael J. Wysocki<rjw@...k.pl> wrote:
>> >>>
>> >>> On Thursday, September 06, 2012, Sedat Dilek wrote:
>> >>>>
>> >>>> On Thu, Sep 6, 2012 at 1:48 PM, Sedat Dilek<sedat.dilek@...il.com>
>> >>>> wrote:
>> >>>>>
>> >>>>> On Thu, Sep 6, 2012 at 9:23 AM, Stephen Rothwell<sfr@...b.auug.org.au>
>> >>>>> 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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists