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:	Mon, 17 May 2010 01:36:06 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Donald Allen <donaldcallen@...il.com>
cc:	john stultz <johnstul@...ibm.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Arjan van de Ven <arjan@...radead.org>
Subject: Re: PROBLEM: tickless scheduling

Donald,

On Sat, 15 May 2010, Donald Allen wrote:
> Attached. This is from the 2.6.30 kernel on the Arch Linux install cd.
> 
> Here's another bit of data. As I've said previously, the problems I'm
> reporting were observed on a Toshiba NB310-305 netbook with a
> single-core Atom 450 processor. I just built myself a mini-ITX system
> using the Intel D510MO motherboard, which provides a dual-core D510
> Atom processor. The other hardware on the board is similar to the
> Toshiba. I installed the same Slackware snapshot I used on the
> Toshiba, and did the home directory transfer without any problem at
> all with the default tickless kernel. The hardware isn't identical,
> and while I don't know the internals of the Linux kernel at all, my
> gut, backed up by many years of OS development work in scheduling and
> memory management, is telling me that the key difference is dual- vs.
> single-core. Just a guess.

I fear you are wrong. 

The key difference is almost certainly that the BIOS of your netbook
tries to be overly clever vs. power management and is not aware of the
fact that the Linux kernel uses timer hardware in a very different way
than the other OS which comes preinstalled on that machine. 

The overly clever BIOS power management which works nicely with the
vendor provided "drivers" for the other OS is just interfering with
the kernels way of dealing with the problem.

Can you please boot with "hpet=disable" on the kernel command line ?

Thanks,

	tglx
--
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