please check some amd opteron related mmconf and numa patches
could make up for system that system have acpi problem
or still can mmconf and numa when acpi=off
YH
* Yinghai Lu <[email protected]> wrote:
> please check some amd opteron related mmconf and numa patches
>
> could make up for system that system have acpi problem or still can
> mmconf and numa when acpi=off
Greg, any deep objections against these patches? (other than that they
need a good amount of testing) I personally think that the more
independent the kernel is of the whims of the BIOS, the better ...
Ingo
Yinghai Lu wrote:
> please check some amd opteron related mmconf and numa patches
>
> could make up for system that system have acpi problem
> or still can mmconf and numa when acpi=off
ACK for my parts (stuff associated with PCI domain support on x86)
Jeff
On Tue, Feb 19, 2008 at 12:23:22PM +0100, Ingo Molnar wrote:
>
> * Yinghai Lu <[email protected]> wrote:
>
> > please check some amd opteron related mmconf and numa patches
> >
> > could make up for system that system have acpi problem or still can
> > mmconf and numa when acpi=off
>
> Greg, any deep objections against these patches? (other than that they
> need a good amount of testing) I personally think that the more
> independent the kernel is of the whims of the BIOS, the better ...
No objection from me, other than they need a LOT of testing. Oh, and
the networking patch is still wrong, and the poster has been told this
numerous times, which makes me wonder how well the pci bridge patch was
tested...
thanks,
greg k-h
* Greg KH <[email protected]> wrote:
> > > could make up for system that system have acpi problem or still
> > > can mmconf and numa when acpi=off
> >
> > Greg, any deep objections against these patches? (other than that
> > they need a good amount of testing) I personally think that the more
> > independent the kernel is of the whims of the BIOS, the better ...
>
> No objection from me, other than they need a LOT of testing. [...]
ok - have queued it up for v2.6.26. Note: Andrew might get grumpy when
your PCI tree starts changing nearby places in arch/x86/pci again and it
clashes with these changes in x86.git - in that case please pick up the
full lot from x86.git#testing and carry it in the PCI tree. (or,
alternatively, send me any trivial, arch/x86-only PCI bits to
x86.git#testing so that we can keep it and test it all in a single place
- whichever approach is more convenient to you)
> [...] Oh, and the networking patch is still wrong, and the poster has
> been told this numerous times, which makes me wonder how well the pci
> bridge patch was tested...
i think the optimization should be more correct now than in the past,
its purpose and dependencies just have not been communicated fully.
We'll get there eventually :-)
Ingo
On Wed, 20 Feb 2008 07:37:52 +0100 Ingo Molnar <[email protected]> wrote:
> Note: Andrew might get grumpy when
> your PCI tree starts changing nearby places in arch/x86/pci again and it
> clashes with these changes in x86.git
s/Andrew/Stephen/I hope/;)/
Hopefully we can soon start feeding these more problematic trees into linux-next
and yes, Stephen will need some more thought/support from his upstreams to make
that viable.
* Andrew Morton <[email protected]> wrote:
> On Wed, 20 Feb 2008 07:37:52 +0100 Ingo Molnar <[email protected]> wrote:
>
> > Note: Andrew might get grumpy when
> > your PCI tree starts changing nearby places in arch/x86/pci again and it
> > clashes with these changes in x86.git
>
> s/Andrew/Stephen/I hope/;)/
>
> Hopefully we can soon start feeding these more problematic trees into
> linux-next and yes, Stephen will need some more thought/support from
> his upstreams to make that viable.
btw., the correct metric would be "real user-side regressions per
commit" (maybe real regressions per line of code changed), not "number
of commits". With the latter metric, x86.git is "problematic". For the
former, it's much less so ;-)
i.e. you should punish buggy trees that affect real testers out there,
not high-flux trees that by virtue of their flux cause more integration
work.
Ingo