linux-kernel - Re: Sony Vaio VGN-SZ340 (was Re: sonypc with Sony Vaio VGN-SZ1VP)

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, 11 Jan 2007 14:52:31 -0500
From:	Len Brown <lenb@...nel.org>
To:	Bjorn Helgaas <bjorn.helgaas@...com>
Cc:	MoRpHeUz <morpheuz@...il.com>, "Andrew Morton" <akpm@...l.org>,
	"Stelian Pop" <stelian@...ies.net>,
	"Mattia Dongili" <malattia@...ux.it>,
	"Ismail Donmez" <ismail@...dus.org.tr>,
	"Andrea Gelmini" <gelma@...ma.net>, linux-kernel@...r.kernel.org,
	linux-acpi@...r.kernel.org,
	"Cacy Rodney" <cacy-rodney-cacy@...n.pl>
Subject: Re: Sony Vaio VGN-SZ340 (was Re: sonypc with Sony Vaio VGN-SZ1VP)

On Friday 05 January 2007 23:09, Bjorn Helgaas wrote:
> On Friday 05 January 2007 11:10, Len Brown wrote:
> > On Friday 05 January 2007 12:24, MoRpHeUz wrote:
> > > > What workaround are you using?
> > > 
> > >  This one: http://bugzilla.kernel.org/show_bug.cgi?id=7465
> > 
> > Ah yes, the duplicate MADT issue is clearly a BIOS bug.
> > It is possible that we can tweak our Linux workaround for it to be more
> > Microsoft Windows Bug Compatbile(TM).
> 
> Maybe Windows discovers processors using the namespace rather
> than the MADT.

Nod.

Based on the fact that the 1st MADT on this box is toast, they're not using that.
If the last one also doesn't work universally, then they must be using the namespace.

For us to do the same would be a relatively significant change -- as it means
we either have to push SMP startup after the interpreter init, or move the
interpreter init yet sooner.

In general, over the last couple of years, we've been forced for compatibility
with various systems to move ACPI initialization sooner and sooner.
(I think the last issue was getting the HW into "ACPI mode" sooner
 because some stuff I don't recall didn't work if we didn't)
It would probably make sense to experiment with what the soonest we
can initialize ACPI, as I have a feeling we're going to have to head that way.

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