From: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
To: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>,
Thomas Renninger <trenn@suse.de>, Len Brown <lenb@kernel.org>,
linux-acpi <linux-acpi@vger.kernel.org>,
Zhao Yakui <yakui.zhao@intel.com>,
me@markdoughty.co.uk,
linux-thinkpad <linux-thinkpad@linux-thinkpad.org>,
"devel@acpica.org" <devel@acpica.org>
Subject: Re: [RESEND] [PATCH 2/3] Introduce acpi_root_table=rsdt boot param and dmi list to force rsdt
Date: Tue, 21 Oct 2008 13:46:15 -0200 [thread overview]
Message-ID: <20081021154615.GA21989@khazad-dum.debian.net> (raw)
In-Reply-To: <20081021152755.GA30633@srcf.ucam.org>
On Tue, 21 Oct 2008, Matthew Garrett wrote:
> Right, but in this case we understand the root cause of the problem - we
> behave differently to Windows in a very specific way. What we don't
> understand are the precise circumstances in which Windows behaves that
> way. It could be that Vista always uses the 64-bit addresses if
> available, and in that case this is the best possible solution. But it
> could also be that Vista swaps addresses based on whether _INI requests
> the Vista OSI or not. It could be that Vista uses the 32-bit addresses
> on 32-bit CPUs. Or where the addresses differ and there's a valid 32-bit
> entry, perhaps they use that. When there's a simple test to perform, we
> should do that before adding a static list.
>
> > > See the number of people who reported that acpi_apic_instance made a
> > > difference, or even the fact that Thomas included a bunch of systems with no
> > > real assurance that they were hit by this.
> >
> > Hm, this is not a good thing. Is there any reliable way to verify that?
>
> We can verify whether the addresses are actually different, but it's
> possible that that's harmless on some machines. However, history
> suggests that there's a placebo effect in adding boot options...
This is all nice and true, HOWEVER apparently all of us lack the hardware
and lab setup to perform the testing. And I haven't seen anyone publish
clear instructions we could ask a Vista user to do, either.
So, can we please commit these patches, with the T4x BIOSes removed from the
DMI list already? We already know the R40e and R50e are borked, we have a
patch that fixes them *cleanly* and completely safely (no side-effects on
any other box). There is no excuse not to apply it since we do NOT have
anything better on hand, NOR are we going to be able to produce better
patches anytime soon.
If someone manages to set up a lab to do testing, or manages to ask someone
else who has deep knowledge of how Microsoft made Vista behave on border
conditions, he can send us better information, and a general solution can be
deployed and the band-aid DMI table, removed.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
next prev parent reply other threads:[~2008-10-21 15:46 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-19 21:50 [RESEND] [PATCH 2/3] Introduce acpi_root_table=rsdt boot param and dmi list to force rsdt Thomas Renninger
2008-10-20 1:01 ` Matthew Garrett
2008-10-20 15:31 ` Henrique de Moraes Holschuh
2008-10-20 16:23 ` Thomas Renninger
2008-10-20 16:27 ` Matthew Garrett
2008-10-20 16:48 ` Thomas Renninger
2008-10-20 16:54 ` Matthew Garrett
2008-10-20 17:51 ` Henrique de Moraes Holschuh
2008-10-20 17:58 ` Matthew Garrett
2008-10-20 18:16 ` Henrique de Moraes Holschuh
2008-10-20 18:24 ` Matthew Garrett
2008-10-20 18:47 ` Henrique de Moraes Holschuh
2008-10-20 18:52 ` Matthew Garrett
2008-10-20 19:25 ` Henrique de Moraes Holschuh
2008-10-21 8:14 ` Thomas Renninger
2008-10-21 9:53 ` Thomas Renninger
2008-10-21 9:57 ` Thomas Renninger
2008-10-21 12:46 ` Matthew Garrett
2008-10-21 13:05 ` Thomas Renninger
2008-10-21 13:08 ` Matthew Garrett
2008-10-21 13:34 ` Thomas Renninger
2008-10-21 14:01 ` Rafael J. Wysocki
2008-10-21 14:00 ` Matthew Garrett
2008-10-21 14:12 ` Thomas Renninger
2008-10-21 14:19 ` Matthew Garrett
2008-10-21 14:25 ` Rafael J. Wysocki
2008-10-21 14:29 ` Matthew Garrett
2008-10-21 14:45 ` Thomas Renninger
2008-10-21 14:49 ` Matthew Garrett
2008-10-21 15:10 ` Rafael J. Wysocki
2008-10-21 15:27 ` Matthew Garrett
2008-10-21 15:46 ` Henrique de Moraes Holschuh [this message]
2008-10-21 15:50 ` Matthew Garrett
2008-10-21 16:58 ` [ltp] " Henrique de Moraes Holschuh
2008-10-21 17:02 ` Matthew Garrett
2008-10-21 19:04 ` Rafael J. Wysocki
2008-10-20 16:43 ` Thomas Renninger
2008-10-20 18:05 ` Henrique de Moraes Holschuh
2008-10-20 15:46 ` Henrique de Moraes Holschuh
2008-10-21 11:07 ` Thomas Renninger
2008-11-11 0:58 ` Matthew Garrett
2008-11-12 23:58 ` Thomas Renninger
2008-11-13 0:56 ` Matthew Garrett
2008-11-13 2:21 ` [Devel] " Zhang Rui
2008-11-13 2:24 ` Matthew Garrett
2008-11-13 8:27 ` Zhang Rui
2008-11-13 11:13 ` Matthew Garrett
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20081021154615.GA21989@khazad-dum.debian.net \
--to=hmh@hmh.eng.br \
--cc=devel@acpica.org \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-thinkpad@linux-thinkpad.org \
--cc=me@markdoughty.co.uk \
--cc=mjg59@srcf.ucam.org \
--cc=rjw@sisk.pl \
--cc=trenn@suse.de \
--cc=yakui.zhao@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox