Messages in this thread | | | Date | Sun, 13 Apr 2008 01:18:30 -0700 | From | "Yinghai Lu" <> | Subject | Re: [rfc] hw resource debugging checks (was: Re: x86 git tree broken (bisected)) |
| |
On Sun, Apr 13, 2008 at 12:58 AM, 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? > > 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
| |