| 1 |
Hi, |
| 2 |
|
| 3 |
On Thu, 14 Jul 2005 16:27:49 +0100 |
| 4 |
Jim Hatfield <subscriber@××××××××.com> wrote: |
| 5 |
|
| 6 |
> So I just installed another machine, using the 2005.0 CD and using |
| 7 |
> the new instructions. It has a Matrox G400 so I added support for |
| 8 |
> that in the kernel. This may have been a mistake. |
| 9 |
> |
| 10 |
> Everything is fine until I reboot, when after the GRUB screen and |
| 11 |
> kernel selection, the screen goes black with lots of pretty blue |
| 12 |
> squares all over it. |
| 13 |
|
| 14 |
This may be due to the framebuffer chosing a wrong mode for the kind of |
| 15 |
monitor you have. You can set the resolution and frame rate on the |
| 16 |
kernel command line. This should be documented in /usr/src/linux/ |
| 17 |
Documentation/fb/... (don't have it here atm) |
| 18 |
|
| 19 |
> I guess I will rebuild the kernel with Matrox support removed and |
| 20 |
> see if that fixes. |
| 21 |
|
| 22 |
This will probably work, too :-) |
| 23 |
|
| 24 |
> BTW, what is the received wistom wrt building things into the |
| 25 |
> kernel or building them as modules? As well as the G400 I have |
| 26 |
> an Intel NIC and a VIA sound card, and this time round chose to |
| 27 |
> build them in, though before I built them as modules. I'm not |
| 28 |
> clear as to the pros and cons. |
| 29 |
|
| 30 |
If the hardware is builtin, and you don't have problems with somewhat |
| 31 |
random hardware enumeration (i.e., multiple NICs getting different |
| 32 |
devices on each boot), there's little reason to build the drivers as |
| 33 |
modules. OTOH, probing a module triggers (if it loads successfully) a |
| 34 |
hotplug event, which is not the case during bootup (AFAIK, at least |
| 35 |
there are no hotplug scripts available at that moment). So if you chose |
| 36 |
to compile them into the kernel, you need to e.g. have "net.eth0" in |
| 37 |
the runlevel configuration for "boot" or "default". If you're probing |
| 38 |
them as modules, that will trigger hotplug and this should take care of |
| 39 |
running the respective start script. If you intend to run a common |
| 40 |
kernel on multiple machines, it may be wiser to compile some drivers to |
| 41 |
modules, but for e.g. PCI devices this shouldn't matter a lot, you only |
| 42 |
will save some RAM on machines that don't need the driver (compiled |
| 43 |
into the kernel). |
| 44 |
|
| 45 |
Sound is another matter: The kernel ALSA isn't always the latest |
| 46 |
version. So it's best to only configure sound support but no ALSA or |
| 47 |
OSS and then later "emerge alsa-driver". |
| 48 |
|
| 49 |
Then there are drivers that have their own code base only. In most |
| 50 |
cases it's much more complicated to integrate them into the kernel |
| 51 |
sources than to compile them as external modules. |
| 52 |
|
| 53 |
|
| 54 |
-hwh |
| 55 |
-- |
| 56 |
gentoo-user@g.o mailing list |
Archives