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]
Date:	Wed, 29 May 2013 19:12:04 -0700
From:	Yinghai Lu <yinghai@...nel.org>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
Cc:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: System slow down from udev

On Wed, May 29, 2013 at 5:20 PM, Rafael J. Wysocki <rjw@...k.pl> wrote:
> On Thursday, May 30, 2013 01:55:07 AM Rafael J. Wysocki wrote:
>> On Wednesday, May 29, 2013 03:49:38 PM Yinghai Lu wrote:
>> > On Wed, May 29, 2013 at 2:34 PM, Rafael J. Wysocki <rjw@...k.pl> wrote:
>> > > On Wednesday, May 29, 2013 01:13:46 PM Yinghai Lu wrote:
>> > >> On Wed, May 29, 2013 at 4:29 AM, Rafael J. Wysocki <rjw@...k.pl> wrote:
>> > >> > On your systems the processor driver is built-in.  Any chance to build it as
>> > >> > a module and see if that helps?
>> > >>
>> > >> it CONFIG_ACPI_PROCESSOR it not set in the config
>> > >> the boot get to normal speed.
>> > >
>> > > Well, if it is not set at all, there won't be problems with it. :-)
>> > >
>> > > I've tested my linux-next branch on OpenSUSE 11.3 both with the processor
>> > > driver built in and modular and I'm not able to reproduce the issue you're
>> > > seeing.
>> > >
>> > > Moreover, I'm not sure if user space is involved here at all, because the
>> > > problem triggers for you when all of the relevant kernel code is non-modular.
>> > >
>> > > With the processor driver enabled, when the slowdown happens, are the systems
>> > > usable enough to get some debug info out of them?
>> >
>> > please check the bootchart data.
>> >
>> > looks like it take 200s if no acpi_processor ...
>> > otherwise will take 800s or more.
>>
>> Well, something's fishy for sure.
>>
>> To my eyes it looks like we're getting lots of notifications related to the
>> processor driver and that generates a lot of workqueue load.
>>
>> Can you please get /proc/interrupts from both cases and the output of
>> "find /sys/firmware/acpi/interrupts/ -print -exec cat {} \;"?
>>
>> Also please send the output of "ls -l /sys/devices/system/cpu/cpu*" with the
>> processor driver present.
>
> Well, this is kind of a blind shot, but I'm wondering if the appended patch
> makes any difference?

No difference. it's still slow.

>
>
> ---
>  drivers/acpi/processor_driver.c |    3 ---
>  1 file changed, 3 deletions(-)
>
> Index: linux-pm/drivers/acpi/processor_driver.c
> ===================================================================
> --- linux-pm.orig/drivers/acpi/processor_driver.c
> +++ linux-pm/drivers/acpi/processor_driver.c
> @@ -87,9 +87,6 @@ static void acpi_processor_notify(acpi_h
>         struct acpi_processor *pr;
>         int saved;
>
> -       if (device->handle != handle)
> -               return;
> -
>         pr = acpi_driver_data(device);
>         if (!pr)
>                 return;
>
--
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