"Lu, Yinghai" <[EMAIL PROTECTED]> writes: > I think CAR for AMD Opteron MB esp Tyan MBs are validated. > > I don't understand the #ifdef cause problem.... > > And I didn't enable that on other MB that I can test. > > Also I didn't enable dual support for other MB too. > > You should know some MB don't support dual core because VRM problem...., > you could burn out the MB... > > So you could enable the dual core support for the MB that is not > validated or talk to HW engineers of the MB vendors....
Agreed. And we have not. CONFIG_MAX_SIBLINGS is not defined. A better explanation is that we had fundamental code cleanups that conflict with the current CAR implementation. In particular look at k8_init_and_stop_secondaries() from patch 4/16. It dramatically reduces the code duplication in auto.c by factoring out a common function. It was felt that maintainable code was preferable to an optional feature. The problem is that our method of detecting an init in early_mtrr_init_detected() while general purpose doesn't work if you have already played with the mttrs as the CAR code does. So either a new technique init detection is needed or we need to pass in a flag. It should only be a few days work to fix the CAR code, to work with the greatly simplified code base. There was also a practical concern with the CAR in that you cannot test changes to it except by flashing fallback which is contrary to the spirit of fallback/normal image separation. Again all minor practical problems, and not a criticism on the technique itself. Eric -- LinuxBIOS mailing list [email protected] http://www.openbios.org/mailman/listinfo/linuxbios
