LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Kernel (http://www.linuxquestions.org/questions/linux-kernel-70/)
-   -   Update kernel to 2.6.20-rc4 --> Ultra slow HD access (http://www.linuxquestions.org/questions/linux-kernel-70/update-kernel-to-2-6-20-rc4-ultra-slow-hd-access-523127/)

KyPeN 01-26-2007 08:24 PM

Update kernel to 2.6.20-rc4 --> Ultra slow HD access
 
I need to update my Edgy Eft vanilla kernel the aforementioned version in order to resolve a conflict between ndiswrapper, broadcom drivers, and nvidia drivers (fsking binary drivers!!!).

So I imported the old config file, recompiled, installed, and booted. It locked up when it was trying to set up the "Waiting for Root File System...", or so I thought. A little research later, I found out that it was searching for sda6, when it really needed hda6. So I changed it and it takes forever to boot, runs slow, but works. It is also worth noting that on the old kernel I was on sda6, hence the confusion. I think it is also worth noting that, before I found out that I just needed to change the boot disk to hda6, I recompiled the kernel on suggestion from a friend with most of the essential stuff (ext3 support, sata support, pci-express) included in the kernel instead of modules.

Here is my output from some commands to diagnose the problem.

Code:

kypen@M1710 ~ $ uname -r
2.6.20-rc4-take2
kypen@M1710 ~ $ sudo hdparm /dev/hda

/dev/hda:
 multcount    =  0 (off)
 IO_support  =  0 (default 16-bit)
 unmaskirq    =  0 (off)
 using_dma    =  0 (off)
 keepsettings =  0 (off)
 readonly    =  0 (off)
 readahead    = 256 (on)
 geometry    = 16383/255/63, sectors = 153356490, start = 0
kypen@M1710 ~ $ sudo hdparm -d1 /dev/hda

/dev/hda:
 setting using_dma to 1 (on)
 HDIO_SET_DMA failed: Operation not permitted
 using_dma    =  0 (off)
kypen@M1710 ~ $

From what I've read, to alleviate this problem requires me to compile chipset support directly into the kernel. After some research, I *think* I found the proper drivers. So I included them, recompiled, and reinstalled the new kernel. Same issue. I'm not convinced I have the right drivers.

I've run 3 different hdparm -Tt /dev/hda on my 3 different kernels:

Code:

Original (comes with ubuntu, don't remember version number)
Cache: 2754mbs
Read/Write: 44.18mbs

2.6.20-rc4 take 1 (without including what *may* be the proper chipset drivers in the kernel, but leaving them as modules)
Cache: 2723mbs
Read/Write: 1.67mbs

2.6.20-rc4 take 2 (including what *may* be the proper chipset drivers in kernel, not modules)
Cache: 2649mbs
Read/Write: 1.69mbs

As you can see, SOMETHING has gone totally wrong in this kernel upgrade. I really think it has to do with SATA/IDE confusion in the kernel. When I boot the 2.6.20-rc4, I have to specify it to be /dev/hda, not /dev/sda as with the stock ubuntu kernel.

Please help!

Lenard 01-27-2007 06:55 AM

Try again, this time clean your problematic configuration first (make mrproper), then do 'make oldconfig'. While using 'make menuconfig' disable;

#
# ATA/ATAPI/MFM/RLL support
#
# CONFIG_IDE is not set

And configure the SATA and PATA support;

#
# Serial ATA (prod) and Parallel ATA (experimental) drivers
#

Build all as modules unless you know which modules you really need.

KyPeN 01-27-2007 11:28 PM

I finally fixed this.

I ended up searching for which SATA controller my 945 chipset had, and futher searching for exactly which kernel module was required to get this working. A couple hours of Googling and working out dependancies for different modules, I finally got it up.

Thanks guys.

jaknowlden 02-20-2007 07:52 PM

Installation
 
Quote:

Originally Posted by KyPeN
I finally fixed this.

I ended up searching for which SATA controller my 945 chipset had, and futher searching for exactly which kernel module was required to get this working. A couple hours of Googling and working out dependancies for different modules, I finally got it up.

Thanks guys.

KyPen,

I have noticed the exact same problem while building 2.6.20 from source on my Ubuntu box - previously sda to hda. I plan to resolve the problem similarly to yours, but am wondering whether you installed the kernel via the canonical "make; make install; make modules_install" or whether you used debian's "make-kpkg" approach.

KyPeN 02-21-2007 12:26 AM

I used Debian's makepkg method. I figured this made it easier because it should automatically update Grub's menu.lst file.


All times are GMT -5. The time now is 03:22 AM.