linux-kernel - Re: [Bugme-new] [Bug 7495] New: Kernel periodically hangs.

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: <1163332237.3293.100.camel@laptopd505.fenrus.org>
Date:	Sun, 12 Nov 2006 12:50:37 +0100
From:	Arjan van de Ven <arjan@...radead.org>
To:	Andrew Morton <akpm@...l.org>
Cc:	David Howells <dhowells@...hat.com>,
	Neil Brown <neilb@....unsw.edu.au>,
	"bugme-daemon@...nel-bugs.osdl.org" 
	<bugme-daemon@...zilla.kernel.org>, linux-kernel@...r.kernel.org,
	alex@...snet.ru
Subject: Re: [Bugme-new] [Bug 7495] New: Kernel periodically hangs.

> I don't know.  In fact I forget how I worked out that it worsened in
> 2.6.early.
> 
> google(noapic) gets 232,000 hits.

is there a way to ask google "only stuff in the last year"?
Asking because "noapic" in 2.4 was the standard "try this" answer when
people had a bios that had busted MPS (but good ACPI)...

> I don't think it really matters when or why it happened. 

well to some degree it does; if it's one patch causing it narrowing it
down at least somewhat in time would help ;)

>  If we take the
> approach of fixing one machine at a time, we'll only need to fix a few
> individual machines to improve the situation for a lot of people.

alternative is that more new machines showed up that need it somehow, eg
not really a regression just something else. Different approach is
needed for hunting that down. But to be realistic we need to narrow
things down a bit, which means

1) Only care about SMP machines. APIC on true UP (no
Hyperthreading/Dualcore) is a thing no hardware vendor tests (Microsoft
doesn't use it) and is just too likely to trip up SMM and other bad BIOS
stuff. 
 * exception is probably people who don't WANT to use apic but where it
somehow gets used anyway; if that happens we probably have the magic
bullet that causes the regression :)
2) Only care about ACPI using kernels. Non-ACPI uses MPS tables for
this, but most vendors hardly maintain those anymore at all and they are
generally just /dev/random nowadays
3) Ignore overclocking; if you overclock using the FSB the apic busses
run out of spec as well; can be a huge timewaster in debug time.

-- 
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org

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