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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20060730191932.GA31309@outpost.ds9a.nl>
Date:	Sun, 30 Jul 2006 21:19:32 +0200
From:	bert hubert <bert.hubert@...herlabs.nl>
To:	Dave Jones <davej@...hat.com>,
	Alexey Starikovskiy <alexey_y_starikovskiy@...ux.intel.com>,
	linux-kernel@...r.kernel.org, zwane@....linux.org.uk,
	venkatesh.pallipadi@...el.com, tony@...mide.com, akpm@...l.org,
	cpufreq@...ts.linux.org.uk, len.brown@...el.com
Subject: Re: 2.6.17 -> 2.6.18 regression: cpufreq broken since 2.6.18-rc1 on	pentium4

On Sun, Jul 30, 2006 at 03:01:33PM -0400, Dave Jones wrote:

> Normally, if the necessary BIOS bits aren't there, then acpi-cpufreq will
> fail to register.  For some reason it sounds like it believes that everything
> went ok.  I wonder if something changed in acpi recently that caused this
> change in behaviour ? Len ?

As far as I can see, acpi_cpufreq does not pass on any errors it sees during
init:

static int __init acpi_cpufreq_init (void)
{
        int                     result = 0;

        dprintk("acpi_cpufreq_init\n");

        result = acpi_cpufreq_early_init_acpi();
...

And from acpi_cpufreq_early_init_acpi():

static int acpi_cpufreq_early_init_acpi(void)
{
        struct acpi_processor_performance       *data;
        unsigned int                            i, j;

        dprintk("acpi_cpufreq_early_init\n");

	( some memory allocations, does not look at acpi or bios )
	
        /* Do initialization in ACPI core */
        acpi_processor_preregister_performance(acpi_perf_data);
        return 0;
}

Note how any error from acpi_processor_preregister_performance is ignored.

Ghetto patch which "fixes" the problem for me:

--- ./arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c~orig  2006-07-30 21:14:43.000000000 +0200
+++ ./arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c       2006-07-30 21:11:34.000000000 +0200
@@ -384,8 +384,7 @@
        }

        /* Do initialization in ACPI core */
-       acpi_processor_preregister_performance(acpi_perf_data);
-       return 0;
+       return acpi_processor_preregister_performance(acpi_perf_data);
 }


But tonight I have no speedstep laptop available to check if this does not
kill acpi_cpufreq when it can work.

Thanks for the hint, dave!

-- 
http://www.PowerDNS.com      Open source, database driven DNS Software 
http://netherlabs.nl              Open and Closed source services
-
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ