lkml.org 
[lkml]   [2008]   [Apr]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [rfc] hw resource debugging checks (was: Re: x86 git tree broken (bisected))
On Sun, 13 Apr 2008 09:58:45 +0200
Ingo Molnar <mingo@elte.hu> wrote:

>
> * Rafael J. Wysocki <rjw@sisk.pl> wrote:
>
> > > > btw., Xorg works fine here on a comparable AMD system - but i
> > > > use a rather new distro (Fedora 8) which has Xorg 7.2.
> > >
> > > My system is an OpenSUSE 10.3 and it has Xorg 7.2 as well.
> > >
> > > I think the problem is somehow related to the Radeon.
> >
> > The bisection turned up commit
> > ea1441bdf53692c3dc1fd2658addcf1205629661 "x86: use bus conf in NB
> > conf fun1 to get bus range on, on 64-bit" as the one causing
> > problems.
>
> thanks Rafael for bisecting this!
>
> This was a rather nasty problem - and i'm wondering what else we
> could do to harden our hw resource management code. I'm wondering, is
> there any particular reason why clearly broken resource setup is not
> detected somewhere, automatically, and WARN_ON()-ed about?

that would be very welcome, esp if kerneloops.org can pick them up.

One thing we also need to do as Linux is get more conservative;
(this isn't per se about this specific thing)

With MCFG for example we learned over time "if it smells funny don't use it".
That concept should be carried much further imo; for example on K8 you
can compare the acpi table to the chipset for numa support, and if they don't match,
we SHOULD ignore both entirely.
The same is true all over; Linux tends to behave as "oh but we think we can make it work anyway",
in general imo that's a mistake in the long term, at least for default configs. Because there
will be cases where that will break, be it special bioses or next gens of chipsets.


--
If you want to reach me at my work email, use arjan@linux.intel.com
For development, discussion and tips for power savings,
visit http://www.lesswatts.org


\
 
 \ /
  Last update: 2008-04-13 17:55    [W:0.121 / U:0.208 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site