This post might be of some interest to any GNU/Linux user who has a motherboard built for Intel Core 2 Duo processors, hence the title. The whole reason I went to compile my own kernel (and as suggested by dylunio) was basically lack of stable support for one of the common features of such motherboards: a JMicron PATA controller.
Here's the story. Many (if not most) Core 2 Duo compatible motherboards (such as ones from Asus and Gigabyte) come with an Intel 965P Express chipset which *does not* have native support for PATA drives. PATA is short for Parallel ATA and is apparently recently called that to differentiate from SATA, which is Serial ATA, a standard that is increasingly being pushed as a replacement for PATA. Since Intel 965P chipset natively supports only SATA, motherboard manufacturers resort to adding a special controller to allow for one PATA IDE port for those who still have old disk and CD/DVD drives (like me). This controller is the JMicron, or JMB controller that we are talking about here.
Since this is all still quite new support for this hasn't been available until Linux kernel 2.6.18, and even there it isn't quite stable, as I have discovered. My board is Gigabyte 965P DS3 and I have been getting short temporary freezes throughout the normal use of my system. The freezes actually happen when it does an "ATAPI reset". I have described the problem in this forum thread where I also posted the output of messages I got when the reset (and a freeze) happened. Because of this, burning CDs also failed.
This problem has apparently been solved in kernels 2.6.19 and upwards. I have decided to compile the latest one, 126.96.36.199, but that was a bad decision. As I later found out this kernel has disabled support for the onboard ethernet controller (which is also used on most similar C2D boards), the currently infamous Marvell 88E8056, because it was causing data corruption and instability on many boards. It has been disabled until the solution for this is found.
However, as it turns out, not everyone experienced these problems. The problem seems to be limited to Gigabyte motherboards, but from my experience not all of them either. It probably depends a lot on the way you use your ethernet connection. If you don't use it heavily and speeds aren't generally above 100Mbit/s then you may be fine. There is a way to re-enable this driver in the latest kernel by uncommenting the "ifdef broken" lines in /usr/src/linux-188.8.131.52/drivers/net/sky2.c, but I'm not sure if that's all you have to do since it didn't quite work for me.
What I would recommend instead is the 184.108.40.206 kernel which has this driver enabled and yet also has JMicron problems ironed out. I would say that at this point, 220.127.116.11 kernel is probably the best bet for any user of a Core 2 Duo based systems with a Intel's 965 series of chipsets.
For your convenience here is what you need to enable to have support for your JMicron controller and your Marvell ethernet:
- Device Drivers --->
- Serial ATA (prod) and Parallel ATA (experimental) drivers --->
- <*> JMicron PATA support
- <*> AHCI SATA support (also recommended)
- Device Drivers --->
- ATA/ATAPI/MFM/RLL support --->
- generic/default IDE chipset support
- JMicron JMB36x support
- Generic PCI IDE Chipset Support (just in case)
- Include IDE/ATAPI CDROM support (just in case for CD support)
It is recommended to enable AHCI for your drives in your BIOS.
- Device Drivers --->
- Network device support --->
- Ethernet (1000 Mbit) --->
- <*> New SysKonnect GigaEthernet support
- <*> SysKonnect Yukon2 support (EXPERIMENTAL)
- <*> Marvell Yukon Chipset / SysKonnect SK-98xx Support (although I believe this is Yukon2, it can't hurt to enable this one too, just in case)
So there, I hope this may be helpful to some. I bet there will be only more and more users with these sort of motherboards and while support will almost certainly improve, it'll be useful to people compiling their own kernels for these systems.
My kernel dance was quite a ride. I compiled the 18.104.22.168 kernel at least two times, and then after deciding to go with 22.214.171.124 about four times. This was mostly because either I missed to enable some options or the compile got borked. To those who may be asking whether they really need to do a
make-kpkg clean every time they make a configuration change, I would recommend yes. It just seems to be the safest way, and if you possibly can wait these 20 minutes or so doing something else it can't hurt.
Also for convenience, the process of compiling and recompiling a kernel in debian is as follows (126.96.36.199 in this example):
- Download a kernel image:
wget -c ftp://ftp.kernel.org/pub/linux/kernel/v2.6/linux-188.8.131.52.tar.bz2
- Go to /usr/src/ and extract it there:
cd /usr/src/ && tar xvjf /home/you/linux-184.108.40.206.tar.bz2
- Configure it (this is where you also have to enable the above for Marvell and JMicron):
- Clean up and compile:
make-kpkg clean && fakeroot make-kpkg --initrd --revision=nameyourkernel-v1.0 kernel_image
- Install the resulting Debian package (which will automatically generate boot stuff like System.map, initrd and grub configuration):
dpkg -i ../linux-image-220.127.116.11_liberdeb.2_amd64.deb
- Update bootloader:
grub-install /dev/hda (/dev/hda may be something else on your install, it has to be the HD you boot from)
- Reboot and hope for the best.
The above steps reflect the "Debian way" of compiling a kernel, as instructed here. It works well though.
If you end up needing to recompile it is good to move your previous kernel installation out of the way. You can do it by either renaming the /lib/modules/18.104.22.168/kernel/ directory (for example
mv /lib/modules/22.214.171.124/kernel /lib/modules/126.96.36.199/kernel.1) or removing the previous kernel installation (like this
rm -R /lib/modules/188.8.131.52/). The latter might be acceptable if you don't care to keep the old compilation (with old settings) around, and just want a new fixed one.
These instructions might be all redundant, but hey.. it's nice to have it all in one place, right?
So any fellow Core 2 Duo system users, feel free to share your experiences below.