On Mon, Feb 07, 2005 at 07:50:34PM +0100, Michele Alzetta wrote:
> A few days ago I started having problems with my BIOS and I thought it
> was my motherboard (a while ago the inbuilt ethernet broke and I had
> to pass to another card - luckily I already had a second one installed
> - so something definitely HAS happened to the mobo).
> 
> The BIOS problems seem to have disappeared by simply changing the
> battery (lucky me !).
> 
> However this started a train of thought. 
> I have a gentoo system with CFLAGS="-march=athlon-xp .... etc. etc. ".
> 
> If I ever wanted to change CPU, would a 64 bit amd cpu work on this
> system, or would I have to mount the system from a live CD and rebuild
> it from scratch, or else rebuild it from scratch with -mcpu before
> changing cpu ?
> 
> If the motherboard broke and I wanted to change __that__ ... I imagine
> my kernel might not work, so mounting the system and building a new
> kernel would be a must ...
> 
> Has anyone had experience with this sort of problem ? What would be
> the safest and smoothest way to face this ?

I actually was faced with this situation a couple of months ago.  My 
ultra-reliable K6-2/400 server finally started acting weird.  A couple 
of weeks before, I'd upgraded my desktop, so I had a free AthlonXP 
board, cpu, and ram.

I just backed everything up, rebuilt the kernel to make sure that I had 
support for the new chipset.  Mind you, everything is build -march=k6.

Yanked the old board, put the new one in place, held my breath, and it 
booted fine.

Going AMD -> newer AMD or Intel -> newer Intel shouldn't be much of an 
issue.  It's when you have to fall back where you get problems.  Again, 
if you have a need to worry about that, put in your cflags "-march=i468 
-mcpu=$your1337cpu".  That way, it'll boot on anything down to a 486.  I 
don't recommend using -march=i386 anymore because you give up some 
things with glibc when you do that.  And using a 386 for anything but a 
doorstop these days is a waste of time.
--
S. Bergeron, [EMAIL PROTECTED]

--
[email protected] mailing list

Reply via email to