Posts Tagged ‘Kernel’

HOW-TO: Enabling 3D Acceleration under Debian Linux

Monday, April 28th, 2008

Purpose:

This blog entry will explain:

1. How to enable 3D acceleration under Debian Linux and may be perhaps under any other Linux distribution.

2. How to test if 3D acceleration is actually working or not.

Step 1: Find out if 3D acceleration is already enabled or not?

Give the following command:

# glxinfo | less

or

# glxinfo | less | grep Yes

If you see a line like:

“direct rendering: Yes”

in the following output:
3D Acceleration - Direct Rendering

then 3D acceleration is already enabled and you don’t need to do anything else.

However, if you see a line like:

“direct rendering: No”

then follow the steps to enable the 3D acceleration.

If you don’t have glxinfo installed, you can install it by:

# apt-get install mesa-utils

Step 2: Find out the Graphics chipset name

In order to recognize the proper driver for your Graphics chipset we need to find out it’s name/model by giving the following command:

# lspci

00:00.0 Host bridge: VIA Technologies, Inc. K8M800 Host Bridge
........
00:10.4 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 86)
00:11.0 ISA bridge: VIA Technologies, Inc. VT8237 ISA bridge [KT600/K8T800/K8T890 South]
00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller (rev 60)
00:12.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II] (rev 78)
01:00.0 VGA compatible controller: VIA Technologies, Inc. S3 Unichrome Pro VGA Adapter (rev 01)
#

The line in bold above shows the name/model of my graphic card (VGA controller). Note this down.

Step 3: XOrg Configuration

Also make sure that your Xorg server is using the correct driver for your graphic card. You can check this by the following command:

# cat /var/log/Xorg.0.log | grep driver

You should see the name of your driver in the output as shown below:

X.Org XInput driver : 0.6
(II) Loading /usr/lib/xorg/modules/drivers/via_drv.so
ABI class: X.Org XInput driver, version 0.6
ABI class: X.Org XInput driver, version 0.6
(II) VIA: driver for VIA chipsets: CLE266, KM400/KN400, K8M800,
(!!) VIA Technologies does not support or endorse this driver in any way.
(!!) For support please contact the driver maintainer or your X vendor.
(II) VIA(0): [drm] loaded kernel module for “via” driver
(II) VIA(0): [drm] created “via” driver at busid “PCI:1:0:0″

If you have the correct driver installed and still you are not able to get 3D acceleration, then try the following additional steps below.

Step 4: Configure the Kernel to include the support for your Graphics Card

Give the following commands:

# cd /usr/src/linux

# make xconfig (or whatever you use)

and configure the following highlighted options :

Kernel configuration for AGP Support Linux

Kernel Configuration to eable DRI support

In short you need to configure AGP Support and DRI/DRM (Direct Rendering Manager) support under Character Devices in the Kernel configuration menu.

You should do the above for your own Graphic Card make/model like Intel 855GM (i810) etc.

Now compile your kernel and install it. In case if you don’t know how to do it, then here is good link which explains the process.

Step 5: Install the DRI package (optional but may be required)

I have found this to be “required” for my configuration. Generally your 3D acceleration should be enabled at this point of time. You can check it as shown in Step1 above. In case if it is still not enabled then try to install the xlib mesa dri package by giving the following command:

# apt-get install xlibmesa-dri

Now check your 3D acceleration again by giving “glxinfo” command.

If you are still not able to get 3D acceleration then chances are that your card and/or your driver does not support it. Check the documentation of your card and driver and try searching on the Internet.

Other tools to check/measure 3D acceleration performance

Once you get your 3D acceleration going, you can use some of the X based tools to measure the performance.

1. GLXGEARS

# apt-get install mesa-utils

# glxgears

You should see 3 colored rotating gears as your output like this:

GLX Gears

2. XENGINE

# apt-get install xengine

# xengine

This utility will show you the RPM count. You can compare the RPM count with and w/o 3D accelerations to see the effect of 3D acceleration. The piston will rotate much more faster with 3D acceleration (a visual cue).

You should see something like this:

Xengine RPM count

3. Check AGP Support

You can also check if Linux detected your AGP or not by giving the following command:

# dmesg | grep agpgart

You should be able to see some text which talks about agpgart like this:

Linux agpgart interface v0.101 (c) Dave Jones
agpgart: Detected AGP bridge 0
agpgart: AGP aperture is 64M @ 0xe0000000
agpgart: Found an AGP 3.0 compliant device at 0000:00:00.0.
agpgart: Xorg tried to set rate=x12. Setting to AGP3 x8 mode.
agpgart: Putting AGP V3 device at 0000:00:00.0 into 8x mode
agpgart: Putting AGP V3 device at 0000:01:00.0 into 8x mode

As usual, please leave a comment/feedback, if you have any.

Create a Patch for Linux Kernel customizations

Saturday, April 5th, 2008

Purpose:

If you have been using Linux for over two to three years than chances are that you may have been in a situation where you need to modify your Kernel’s Makeconfig or Kconfig files or adding a new device driver for your hardware from your hardware vendor which is not yet into the mainstream kernel (www.kernel.org).

Once you do all of the above then you may need to generate a patch (for the changes that you just made) so that other users can simply apply that patch rather than going into the kernel sources and manually modify all those files. This blog posting will explain in a simple way how you can do that. Although I think there might be several postings which will explain you how to do that but they may not be clear or may not cover your case specifically.

Let’s start with an example:

I downloaded Kernel source 2.6.24 into my /usr/src/linux directory. Suppose I need to add a framebuffer driver support, say for example, for my VIA’s Unichrome Graphic chipset. I copy the framebuffer driver source directory (provided by VIA) into my kernel directory as follow:

cd /usr/src/linux

cp -a /usr/src/fbdev-via-unichrome /usr/src/linux/driver/video/via

Note: The directory /usr/src/linux/driver/video/via did not existed when we installed 2.6.24 kernel source initally.

After this suppose we need to make changes to files Kconfig and Makefile in /usr/src/linux/drivers/video directory.

Say I add the following line in the Makefile:

obj-$(CONFIG_FB_VIA) += via/

and the following line in the Kconfig:

config FB_VIA
tristate “VIA UniChrome/Chrome 9 HC display support”
depends on FB && PCI
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
select FRAMEBUFFER_CONSOLE
help
This is the frame buffer device driver for the VIA CLE266, CN400, CN700, CN800,
CN896, CX700, PMN800, PMN880, P4M800CE-Pro, P4M890, P4M900, VN800, VN896 and
VX700 chipsets.

The above are examples from the www.viaarena.com website.

That’s it! Our kernel is now ready to be compiled and installed to get the framebuffer support for the VIA graphic chipset. However, what if there are several users who want to do the same since they also happen to have the same VIA graphic chipset and the driver has still not made into the mainstream kernel.

Here are the steps to generate a patch after your making your own Kernel modifications:

Step 1: Download and prepare kernel sources

Download again the 2.6.24 kernel source (same as you did above) against which you want to build the patch and name directory to something like linux-pristine. For example, your /usr/src directory should now look something like this:

debian:/usr/src# ls -l

total 57316

drwxr-xr-x 20 root root 4096 2008-02-11 03:48 linux-pristine

drwxr-xr-x 20 root root 4096 2008-02-11 03:48 linux-source-2.6.24

lrwxrwxrwx 1 root src 19 2008-04-06 00:20 linux -> linux-source-2.6.24

debian:/usr/src#

Basically, you now have two kernel source 2.6.24 directories:

One with changes that you made to incorporate VIA’s framebuffer driver called as linux (a link to linux-source-2.6.24 directory)

and

the other original 2.6.24 kernel sources (straight from www.kernel.org website) that you just downloaded called as linux-pristine

Step 2: Clean both the kernel directories

We need to make sure that we remove any object or executables files in both the kernel directories. Give the following commands:

debian:/usr/src# cd linux
debian:/usr/src/linux# make mrproper
debian:/usr/src/linux# make clean
debian:/usr/src/linux# cd ../linux-pristine/
debian:/usr/src/linux-pristine# make mrproper
debian:/usr/src/linux-pristine# make clean
debian:/usr/src/linux-pristine#

Step 3: Generate patch

Now give the following commands to create the patch:

debian:# cd /usr/src

debian:/usr/src# diff -Nur linux-pristine/drivers/video/ linux/drivers/video/ > patch-2.6.24-viafb

The format of the diff command is:

diff -options oldfile newfile > patch

where -options = -Nur

oldfile = linux-pristine/drivers/video/

newfile = linux/drivers/video/

patch = patch-2.6.24-viafb

Your patch is now ready and you can view your patch by using your favourite editor like gedit, less, nano, etc.

debian:/usr/src# less patch-2.6.24-viafb

Step 4: Test your patch

We need to make sure that the patch we just generated is correct or now. There is a simple way to do it.

Make a temporary copy of your linux-pristine directory as follow:

debian:/usr/src# cp -r linux-pristine/ /tmp/linux-test-patch

Now patch this kernel source by the patch that you just created in Step 3 above.

debian: cd /tmp/linux-test-patch/

debian:/tmp/linux-test-patch# patch -p1 < /usr/src/patch-2.6.24-viafb

You should be seeing some output as follow:

*******************************
patching file drivers/video/Kconfig
patching file drivers/video/Makefile
patching file drivers/video/via/accel.c
… … … … … … … … … … … … … … … …
patching file drivers/video/via/via_utility.h
patching file drivers/video/via/vt1622a.c
patching file drivers/video/via/vt1622.c
patching file drivers/video/via/vt1625.c
patching file drivers/video/via/vt1636.c
patching file drivers/video/via/vt1636.h
debian:/tmp/linux-test-patch#

*******************************

Finally give the following command to test your patch:

debian:/tmp# diff -rq linux-test-patch/drivers/video/ /usr/src/linux/drivers/video/

If your patch was successfully created in Step 3 than you should not see any output after giving the above command. Basically the above command makes sure that there is no difference in any of the files after you patched your kernel.

Note: If you want to see the explanations of the options of the “diff” command, please see the man page:

debian:/ man diff

Step 5: Tell your users how to use your patch

Just ask your users to patch their 2.6.24 kernel by giving the following command:

debian:/usr/src/linux-source-2.6.24# patch -p1 < /usr/src/patch-2.6.24-viafb

Congratulations! You have successfully created a patch that you can distribute to other users who do not want to make changes manually to the kernel sources as you did initially. Treat yourself with something you like to eat or just sit back and relax and enjoy seeing people using your patch.

As usual, please leave a comment/feedback, if you have any.

VFS: Kernel Panic Error - ACPI and APIC Issues - Part 1

Tuesday, March 4th, 2008

I guess most of us who have been an ardent user of Linux O.S. must have seen dreaded “Kernel Panic” error messages at some point of time and generally those are very difficult to solve and takes away lot of time researching on it.There are many reasons for Kernel Panic error messages and one of them is related to ACPI and APCI, which I am going to talk about in this post. ACPI has superseded the old APM.

Typically you will see error messages like this:

“kernel panic - not syncing: VFS: unable to mount root fs on unknown-block(0,0)”

Solution

Try passing the following kernel parameters (all at once) in your GRUB (menu.lst) or LILO (lilo.conf) configuration file:

“acpi=off pci=noacpi noapic nolapic”

There are 90% chances that your problem will solve if it is related to ACPI and APIC. Once you can boot your system by giving above parameters, try eliminating each one of them, one by one, to find which parameter actually is required. However, there could be more than one parameter that you will end up using. For example, in my case I had to give “acpi=off nolapic” to resolve my Kernel panic error.

If you are still getting Kernel panic even after giving the above four parameters, then try these addtional parameters in permutation and combination with the above four to see if you resolve the issue:

“pnpbios, pci=usepirqmask, pci=biosirq”

If you are still not able to solve it, then I suspect that it might not be an APCI and ACPI related issue. However, I strongly encourage you to boot from a Knoppix live CD or Ubuntu live CD and look at the “Help” section before it starts booting. In the help section they suggest many kernel parameters that you may have to give because of broken firmware or buggy BIOS in order to boot your system.

In my next part of this post, I will explain and also give some useful pointers as to why we need to give those parameters to safely boot the Linux Kernel and how can we boot the kernel without giving those parameters because in some situation (when you are using a laptop) you simply cannot give up ACPI features.