Re: [rfc] hw resource debugging checks (was: Re: x86 git tree broken (bisected))

[Yinghai Lu]

On Sun, Apr 13, 2008 at 12:58 AM, Ingo Molnar <mingo@xxxxxxx> wrote:
>
>  * Rafael J. Wysocki <rjw@xxxxxxx> 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?
>
>  for example, in the scheduler code we used to have similar bug patterns
>  again and again: architecture code set up scheduler domains incorrectly
>  and broke the system in subtle ways. So we added sched_domain_debug()
>  which is active under CONFIG_SCHED_DEBUG=y and does a few sanity checks
>  and complains if something is wrong. This caught quite a few bugs
>  whenever the sched-domains code was modified.
>
>         Ingo

there is silicon abut about agp bridge aperture order reading...
=====> just sent out one patch to work around that

also BIOS is sick to allocate overlapping MMIO to the same link..

node 0 link 0: io port [1000, ffffff]
TOM: 0000000080000000 aka 2048M
node 0 link 0: mmio [e0000000, efffffff]
node 0 link 0: mmio [a0000, bffff]
node 0 link 0: mmio [80000000, ffffffff]
bus: [00,ff] on node 0 link 0

never thought that BIOS could be so sick.
 ===> already have one work around, need more test next week.

YH
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/