linux-kernel - Re: Linux 2.6.30-rc8 [also: VIA Support]

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:	Thu, 4 Jun 2009 10:46:00 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	"Michael S. Zick" <lkml@...ethan.org>
cc:	Duane Griffin <duaneg@...da.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Harald Welte <HaraldWelte@...tech.com>
Subject: Re: Linux 2.6.30-rc8 [also: VIA Support]

On Thu, 4 Jun 2009, Michael S. Zick wrote:
>
> Yes, I build test cases with and without - -
> It was a fixed-speed kernel build that first hit the 4 hour up-time mark.
> I just reposted that build today (the -09143lk).
> 
> > Features like that easily put a huge stress on power regulators etc, if 
> > they result in sudden changes in current draw.  Underspecced capacitors 
> > etc can cause CPU "brown-outs", which in turn can easily cause total 
> > failure. 
> 
> There is also a possible thermal issue with these machines - -
> I doubt that VIA runs their qualification testing in bake ovens;
> which is what NetBook cases amount too.  ;)

If the fixed-speed case runs for longer, it's not likely to be a thermal 
issue. The fixed speed case should be the higher-power one.

So it can easily be a weak power setup (insufficient grounding, bad 
capacitors etc). But it could also be external bus issues, in case VIA 
power management also impact the external bus (eg "stopclock" like 
behavior on the CPU<->chipset bus).

One thing you could try is to avoid using the "halt" instruction. It will 
obviously increase power use (and thus higher temperatures), but again, 
current fluctuations are much more likely to cause problems than higher, 
but fairly constant, power draw.

Think about all the light-bulbs you've seen that burn out just when you 
turn them on. 

Use "idle=poll" on the kernel command line to avoid the idle loop using 
the "halt" or "mwait" instructions to save power.

(That polling idle loop can also end up hiding cache coherency issues with 
DMA, so if that works better, it doesn't necessarily prove it's 
power-related. Shutting down the CPU core can have interesting 
implications for external events, and you can have various races - maybe 
you shut down the core just as a chipset event happened, and the chipset 
_thinks_ the core is now awake, but the core went to sleep. End result: 
hung machine).

		Linus
--
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/