What you need to do is to first, make sure that your kernel source packages are installed. Can't really help you there, it depends on your distro and how your system was initially set up.
Anyway, once these are installed, (at least on Fedora Core 6) they should reside in
/usr/src/kernels/linux-2.6.18.1
or whatever version of the kernel whose source packages you have installed.
What you then need to do is
1. Configure the kernel to (maybe) have support for your motherboard's DMA
2. Compile and Install the new kernel
3. Boot into the new kernel
4. Test DMA with a video player
This is exactly how, on my old Gigabyte TRS350MT motherboarded PC I managed to get DMA working, and eventually got smooth video playback / DVD playback on Fedora Core 3 on the TRS350MT motherboard.
First, your current kernel. Most likely, if you have a normal / mass distributed distro like Fedora, Mandrake, Suse, etc. the kernel will be very much configured in a "generalised" way, i. e. the hardware it supports and the way it operates is as general as possible to please as many people as possible. What happened to me on Fedora Core 3 was -exactly- what you describe your problem as being. Other guys also told me to try
Code:
/sbin/hdparm -d1 -c1 /dev/dvd
to try and set DMA up on my DVD drive. It failed with the same HDIO errors you seem to get.
So I started looking into recompiling the kernel so that it would do DMA. After days of searching and looking, I finally discovered that the stock kernel that came with my FC3 would NOT ever do DMA with the TRS350MT motherboard, because the kernel did not have support for the ATI IXP southbridge chips on that board. So I went to kernel.org and downloaded the 2.6.18.1 kernel, which was current at that time.
I. e. your current kernel might not have support for the hardware you have, you may need to get a newer kernel from kernel.org as well...
Ok, step by step:
------------------------------------------------------------------------------------------------------------------------------------------------------------------------
1. Configure the kernel to (maybe) have support for your motherboard's DMA
To do this you first need to know WHAT type of southbridge chipset you have on your motherboard. I had an ATI IXP southbridge (looked up in my motherboard manual).
I. e. , as root do
Code:
[root@development ~]# cd /usr/src/kernels/linux-2.6.18.1/
[root@development linux-2.6.18.1]# make clean
[root@development linux-2.6.18.1]# make mrproper
[root@development linux-2.6.18.1]# make menuconfig
You will now be taken into a text interface where you can configure the kernel. Alternatively, for a graphical interface, do
Code:
[root@development linux-2.6.18.1]# make xconfig
It is your choice.
In the interface you now have before you, either graphical or text based, configure your kernel. Usually it is best to leave most things as they are, you should have pretty good defaults. However, if you want to experiment, go ahead. But as for the point of the whole effort, go the block devices / DMA section (if I remember right - I did this quite a while ago). Look for any and all settings referring to DMA and / or block devices and make sure DMA is enabled / on everywhere. Additionally, look for the name of your chipset.
For example, in menuconfig, I could not find my ATI IXP chipset (it WAS there, but it was hidden between hundreds of other options). So what I did was to configure the kernel with menuconfig, and then, OUTSIDE menuconfig I looked for the string "IXP" with VI to find the entry I needed to change.
I. e. when you exit menuconfig, your kernel configuration is saved into a file called
in the kernel directory (in my case /usr/src/kernels/linux-2.6.18.1/)
So once you are back at the root prompt do
Code:
[root@development linux-2.6.18.1]# vi .config
To see your .config file "in the raw". What I did here was use the / command in vi (for search) and I found the line referring to IXP. It looked something like this
Code:
ATI_IXP_DMA_SUPPORT=N
I. e. that kernel, if I had compiled it then, would STILL not have had DMA support for my chipset. So I changed that line to
Code:
ATI_IXP_DMA_SUPPORT=Y
Note that this can sometimes cascade a bit, i. e. in step 2 (which we'll get to right now) you might get asked a few more questions once you start compiling the kernel, based on changes you might have made "yourself" to .config.
I. e. for your chipset, if you can find out what your motherboard has, do as I did... it might just work for your too, and spare you hours of trial and error.
Anyway, I then saved this .config file with the change manually made as detailed above (i. e. without using menuconfig or xconfig)
One more thing before you are ready to compile is to edit the kernel makefile, to give your kernel a unique name (so, when you boot your system, you'll know which is which).
After editing .config, do
Code:
[root@development linux-2.6.18.1]# vi Makefile
The top of the file should look something like this:
Code:
VERSION = 2
PATCHLEVEL = 6
SUBLEVEL = 18
EXTRAVERSION = .1_Vol_No_Preempt
NAME=No Preempt Polar Design
Put your own stuff / name in the
Code:
EXTRAVERSION =
NAME=
fields. These will then be used by the kernel when you install it, and you'll see the NAME and EXTRAVERSION fields displayed in your GRUB menu when you boot your system after installing the new kernel (so you'll know WHICH kernel to start - you give it a unique name).
NOTE THAT I AM ASSUMING YOU WILL USE GRUB AS BOOTLOADER!
2. Compile and Install the new kernel
Ok, after editing the Makefile and giving your kernel a unique, recognisable name, start the compile process.
This is done like this:
Code:
[root@development linux-2.6.18.1]# make all
Note that the above can take a LONG time - up to an hour or two if you have a very slow system. On most modern PCs, expect to wait AT LEAST 20 minutes or so for the kernel to compile. You should get no errors, and maybe one or two warnings. Warnings can usually be safely ignored. You won't be able to ignore errors, the compilation will stop and you WILL be stuck. If that happens you might have selected some option somewhere in xconfig or menuconfig that won't work on your setup / hardware (which is why it is unwise, if you don't feel adventurous or patient enough, to edit the default kernel's settings TOO much)
Note that, as I said earlier, the compilation process might stop here and there and ask you a question. You can usually choose between the general logical options of yes, no, auto, or force. If you are unuse, always leave at auto.
Once the kernel compile has finished and you have the # back, do
Code:
[root@development linux-2.6.18.1]# make modules_install
The above can again take a few minutes, then, the final step
Code:
[root@development linux-2.6.18.1]# make install
This should install the kernel into GRUB, and add a GRUB bootlist entry.
That's it! You have now compiled and installed your new kernel.
3. Boot into the new kernel
Simply restart your machine. When GRUB now comes up, you should see your stock kernel (the one that came with your distro) AND -your- kernel, the one you just compiled. Choose "your" kernel, and hopefully if all went well, your system will start up with the new kernel you compiled yourself, running the "show".
4. Test DMA with a video player
NOW try to do a
Code:
/sbin/hdparm -d1 -c1 /dev/dvd
again - IF everything went as planned, your "HDIO_" error messages should be gone, OR your DMA speed might already be at its max. Start up your video player and see if there was any improvement.
NOTE: It is possible that "your" kernel might fail to boot or that your system won't start with the new kernel. Don't panic, simply reboot again and from the GRUB menu choose your "old, known as working" kernel. That's the beauty of playing around with the kernel, if you foul up, it is dead easy to just start your old, working kernel, and use THAT again to fiddle with the new custom kernel.
One advantage of this of course is when you are configuring your new kernel, you can set it up EXACTLY like you want. For example, I dropped many, many drivers and services and filesystems from my custom kernel, because I knew I'd never need them. This resulted in a smaller, and maybe a tiny bit faster kernel. Not as important these days, sure, with everybody having a gargantuan PC, but back then it mattered a lot if you could cut a few kilobytes or CPU cycles out of the kernel so you could have more horses available to do actual work.
Hope this helped!
Regards,
