Upgrade motherboard & processor
in [Linux Help]
|
From: John Hasler on 17 Jan 2010 15:50 Yousuf Khan > Anyways, what sort of driver modules are not compiled? How do they run > then? The system boots up running entirely out of RAM (using a RAM filesystem), probes the hardware to find out what it is dealing with, and loads the driver modules it needs. See <http://en.wikipedia.org/wiki/Initrd> -- John Hasler jhasler(a)newsguy.com Dancing Horse Hill Elmwood, WI USA
From: AZ Nomad on 17 Jan 2010 16:24 On Sun, 17 Jan 2010 12:59:47 -0600, Ignoramus15099 <ignoramus15099(a)NOSPAM.15099.invalid> wrote: >On 2010-01-17, AZ Nomad <aznomad.3(a)PremoveOBthisOX.COM> wrote: >> On Sun, 17 Jan 2010 12:06:24 -0600, Ignoramus15099 <ignoramus15099(a)NOSPAM.15099.invalid> wrote: >>>On 2010-01-17, Yousuf Khan <bbbl67(a)yahoo.com> wrote: >>>> dennis(a)home wrote: >>>>> However there are compiled in options that could break a linux system if >>>>> they have been used by the OP. >>>>> Its unlikely and they probably wouldn't be asking such simple questions >>>>> if they had. >>>> >>>> That is part of the question, are there any compiled in options in the >>>> standard Ubuntu distro kernel that I will have to worry about? For >>>> example for the chipset. I remember from the old days of Linux that most >>>> drivers were compiled in, and now they are mostly run-time loaded; but >>>> are there still any holdovers left that are only compiled in? >> >>>There are some drivers that are not compiled in by default; those tend >>>to be experimental or incomplete drivers. >> >> There are few drivers that are compiled in. The vast majority are >> modules and not loaded unless the hardware is detected. >Sure. But some are not even compiled as modules. Yes. All 0.005% of them. Everything that isn't a core driver can be built as a module and a distribution like ubuntu does everything as modules when possible.
From: Baron on 18 Jan 2010 04:53 dennis(a)home Inscribed thus: > > > "AZ Nomad" <aznomad.3(a)PremoveOBthisOX.COM> wrote in message > news:slrnhl4aq6.63t.aznomad.3(a)ip70-176-155-130.ph.ph.cox.net... >> On Sat, 16 Jan 2010 12:03:35 -0500, Yousuf Khan >> <bbbl67(a)spammenot.yahoo.com> wrote: >>>Just purchased a new motherboard/chipset and processor for my >>>desktop. Haven't switched them out yet, waiting to see what >>>preparations I need to take on Ubuntu before going for it? I'll be >>>keeping the existing hard drives and video card, as is. >> >> ubuntu isn't a microsoft product; there's no code to disable >> the system after a hardware cange. > > There isn't any in windows either. Rubish ! Windows monitors every change you make. > However there are compiled in options that could break a linux system > if they have been used by the OP. ???? -- Best Regards: Baron.
From: Aragorn on 18 Jan 2010 05:00 On Sunday 17 January 2010 07:59 in alt.os.linux, somebody identifying as Yousuf Khan wrote... > AZ Nomad wrote: > >> On Sat, 16 Jan 2010 12:03:35 -0500, Yousuf Khan >> <bbbl67(a)spammenot.yahoo.com> wrote: >> >>> Just purchased a new motherboard/chipset and processor for my >>> desktop. Haven't switched them out yet, waiting to see what >>> preparations I need to take on Ubuntu before going for it? I'll be >>> keeping the existing hard drives and video card, as is. >> >> ubuntu isn't a microsoft product; there's no code to disable >> the system after a hardware cange. > > More worried about drivers. The motherboard will be going from Nvidia > chipset to ATI chipset. Onboard video will change likewise, but > discrete graphics will remain Nvidia 8600GT. Stock distribution kernels are always built without processor- or chipset-specific optimizations. They contain generic code that will work on all processors or motherboard chipsets of that particular market segment. By this I mean the type of distribution you are installing, i.e. IA32 (alias x86, x86-32 or i586 (or perhaps i686)) or AMD64 (alias x86-64). The idea behind a binary GNU/Linux distribution is that it would be compatible with as much of the hardware as possible for that particular platform - e.g. AMD64 - without getting into any optimizations specific for Intel or AMD, or chipset optimizations. All chipsets and processors for the x86 platform processors understand generic x86 instructions, and in some cases the Linux kernel can pick a subset of (slightly) more optimized instructions specific to a given chipset by autodetecting what is there. Processor and chipset support is built into the kernel itself - i.e. statically linked - as well as some very common peripheral support - e.g. generic PATA and SATA support and ext3 filesystem support - but support for other peripherals (like videocards) is loaded via driver modules. These driver modules are usually all included in the /initrd/ image, and for some, the kernel will autodetect which one to load, while others are being loaded with prejudice, regardless of whether the hardware supported by those modules is present or not. For instance, the stock PCLinuxOS kernel I'm using on this machine here loads many different types of network adapter modules, of which only two actually have the hardware present in the system - one being an on-board connector, the other being a PCI plug-in card. My advice however would be to disable your on-board video adapter in the BIOS, because nVidia drivers don't work well with two different types of video adapters in your system. The bottom line is that the only variable that seems to exist between both your old and your new system is that the motherboard and CPU are different, and those differences will be handled by the Linux kernel itself through its built-in generic support for just about every chipset and CPU with the exception of bleeding edge stuff[1] and by the /initrd/ via all the driver modules it contains. The proprietary nVidia driver will be working with the same video adapter card, so that should not be a problem either. Things that require a proprietary driver module might not be supported, though. This depends on your distribution and whether it includes proprietary drivers or not. [1] If the chipset is too new for the kernel, then it'll still be supported for essential functionality, but then some optional things might not be correctly detected, e.g. certain hardware monitoring functions or the likes. -- *Aragorn* (registered GNU/Linux user #223157)
From: Kadaitcha Man on 18 Jan 2010 05:44
"Aragorn", thou legless lecherous. Like the toad, ugly and venomous. Ye tehee'd: > On Sunday 17 January 2010 07:59 in alt.os.linux, somebody identifying as > Yousuf Khan wrote... > >> AZ Nomad wrote: >> >>> On Sat, 16 Jan 2010 12:03:35 -0500, Yousuf Khan >>> <bbbl67(a)spammenot.yahoo.com> wrote: >>> >>>> Just purchased a new motherboard/chipset and processor for my >>>> desktop. Haven't switched them out yet, waiting to see what >>>> preparations I need to take on Ubuntu before going for it? I'll be >>>> keeping the existing hard drives and video card, as is. >>> >>> ubuntu isn't a microsoft product; there's no code to disable the >>> system after a hardware cange. >> >> More worried about drivers. The motherboard will be going from Nvidia >> chipset to ATI chipset. Onboard video will change likewise, but >> discrete graphics will remain Nvidia 8600GT. > > Stock distribution kernels are always built without processor- or > chipset-specific optimizations. They contain generic code that will > work on all processors or motherboard chipsets of that particular market > segment. By this I mean the type of distribution you are installing, > i.e. IA32 (alias x86, x86-32 or i586 (or perhaps i686)) or AMD64 (alias > x86-64). > > The idea behind a binary GNU/Linux distribution is that it would be > compatible with as much of the hardware as possible for that particular > platform - e.g. AMD64 - without getting into any optimizations specific > for Intel or AMD, or chipset optimizations. All chipsets and processors > for the x86 platform processors understand generic x86 instructions, and > in some cases the Linux kernel can pick a subset of (slightly) more > optimized instructions specific to a given chipset by autodetecting what > is there. > > Processor and chipset support is built into the kernel itself - i.e. > statically linked - as well as some very common peripheral support - > e.g. generic PATA and SATA support and ext3 filesystem support - but > support for other peripherals (like videocards) is loaded via driver > modules. These driver modules are usually all included in the /initrd/ > image, and for some, the kernel will autodetect which one to load, while > others are being loaded with prejudice, regardless of whether the > hardware supported by those modules is present or not. > > For instance, the stock PCLinuxOS kernel I'm using on this machine here > loads many different types of network adapter modules, of which only two > actually have the hardware present in the system - one being an on-board > connector, the other being a PCI plug-in card. > > My advice however would be to disable your on-board video adapter in the > BIOS, because nVidia drivers don't work well with two different types of > video adapters in your system. > > The bottom line is that the only variable that seems to exist between > both your old and your new system is that the motherboard and CPU are > different, and those differences will be handled by the Linux kernel > itself through its built-in generic support for just about every chipset > and CPU with the exception of bleeding edge stuff[1] and by the /initrd/ > via all the driver modules it contains. The proprietary nVidia driver > will be working with the same video adapter card, so that should not be > a problem either. Things that require a proprietary driver module might > not be supported, though. This depends on your distribution and whether > it includes proprietary drivers or not. > > > [1] If the chipset is too new for the kernel, then it'll still be > supported for essential functionality, but then some optional things > might not be correctly detected, e.g. certain hardware monitoring > functions or the likes. Translation: Linux is always compiled for the absolute lowest common denominator. If your processor is a 1985 386-SX, Linux is guaranteed to run on it. |