Install problems on Intel 965 boards, specifically DG965RY

[tji]

Edit to add summary information for new people running into this problem:


Summary of issue / solution:

Problem: Due to a BIOS bug, when running in 64bit mode, with 4GB+ of RAM, intel motherboards run extremely slow (i.e. it would take days to go through install process). The problem shows up with BIOS revision 1676 - 1687 (1687 = most recent BIOS at this time).

Workaround: Take out some memory, to run with less than 4GB. This allows installation and usage with any BIOS revision.

Current Solution: Revert back to BIOS version 1669, the last version before the problem was introduced. With this version, you can use 4GB+ at full performance.


Motherboards effected: List in BIOS release notes is: DP965LT, DG965SS, DG965RY, DG965PZ, DG965OT, DG965MS, DG965MQ, DQ963FX, DQ963GS

Other Notes on Board: Older Linux versions had trouble with the PATA controller on this board. Fedora 7 includes the marvell-pata driver and should work fine without any other kernel options. Using a SATA CD/DVD drive would allow for installation with with older distros. The Intel BIOS update ISO CD image doesn't work with SATA CD drives.


------------- Original Post Below --------------

- Problem is seen when running in 64bit mode, with 4GB+ of RAM
- Intel motherboard BIOS update


I have seen many reports on this and other sites regarding problems installing on boards with the Intel 965 chipset, and specifically on the board I have, the Intel DG965RY. I went with Intel as the stable / reliable option, but have run into nothing but troubles in getting it installed. There are a lot of problem reports for this board, many success reports, and many conflicting reports of which settings to use...

HW info: Intel DG965 RY motherboard, 4x 1GB DDR2 DIMMs, Core 2 Duo 1.86GHz CPU, Maxtor 500GB SATA HDD, LG PATA DVD-R drive (later replaced with LG SATA DVD-R drive)

Software Info: Fedora 7 x86-64. I have also tried Ubuntu Feisty and OpenSUSE 10.2, all had approximately the same behavior. I haven't tried a 32 bit Linux yet.. with 4GB or RAM I wanted to stick to a 64 bit OS, but I'll try a 32 bit install as a test later.

Initially, I tried to install with a SATA hard drive (Maxtor 500GB SATA), and a PATA DVD-R drive. The install screens were slow, and I thought it was the widely reported problem with the Marvell PATA controller on the board. So, I bought a SATA DVD-R drive and tried again.

Apparently, the problem was not the PATA controller.. as far as I can tell Fedora 7 has the driver for that controller, and it should work fine. The slowness must be caused by something else, because it behaved the same way when I replaced it with the SATA DVD-R drive.

Install steps take forever to update, and if I went through the whole install, it would take many hours to complete (I started an actual install this morning when I left, we'll see if it's completed when I return tonight). I also went to a command shell and ran a few commands, like 'lspci' and found there was a pause of about 15 seconds before the output. It seems like there might be some IRQ or DMA issue causing a general slowdown, but I haven't been able to isolate it.


Is anyone else getting this slowdown behavior with their G965 board??

[tji]

BIOS Settings:

Most discussions about this board revolve around the SATA/IDE settings. There are a few BIOS options, for which the implications are not very clear. I guess the correct setting depends on what drives and interface you are using. I am now using SATA for both my DVD-R drive and my Hard Drive, so I switched to Native/AHCI modes.

SATA Mode: AHCI / IDE -- I have tried both. It seems like AHCI is the preferred mode for Linux, although people reported using IDE mode to get the Marvell controller working with PATA DVD drives. My current setting is: AHCI

ATA Mode: Native / Legacy -- People also reported setting this to Legacy in order to use their PATA DVD drives. My current setting is: Native


Those didn't make much difference in my install, so I tried simplifying other BIOS areas to see if that helped. Nothing did, but discussion on the preferred BIOS settings, and implications of various settings, might be useful.

Dual Core Support: Tried both On & Off
Serial Port: Disabled
Parallel Port: Disabled
Ethernet Port (Intel E1000): Tried both On & Off
Firewire Port: Tried both On & Off
Audio: Tried both On & Off
HPET (?) High Performance Timer: Tried both On & Off.

USB Ports: Tried both On & Off (I initially used a USB kbd/mouse, but switched to PS/2 to simplify)
USB Legacy Mode: Left ON to allow USB keyboard support in BIOS screens.



Kernel Options:

The most common suggestion for kernel options is to include the following:

all-generic-die pci=nommconf irqpoll

I believe the 'all-generic-ide' addresses the compatibility issues for kernels not directly supporting the IDE controller on this board.

pci=nommconf -- Stops the use of MMCONFIG (memory mapped configuration of PCI resources??) Didn't make a difference for my install.

irqpoll - Help systems with badly broken firmware. When an interrupt is not handled, search all handlers for it. Check all handlers on each timer interrupt. Didn't change my behavior.


I also tried the OpenSUSE safe settings, which include most of the above, and a lot more common ones like nolapic acpi=off apm=off, etc...


-------

Any suggestions for BIOS or kernel option tweaks or debugging measures?

[tji]

I just checked in on the installation process, which after running for 7+ hours was still nowhere near complete. So, I killed it.

I grabbed a 32 bit Linux install CD (Ubuntu Feisty) and booted that, and it works just fine..

So, the problem appears to be 64 bit related.

I wonder if it could be with the BIOS version I'm using. Has anyone else successfully run 64 bit Linux on this board? After I run 32bit Feisty through its paces a bit, I'll try installing OpenSolaris, or FreeBSD 64 bit, to try and see if it's an issue with Linux only, or 64 bit in general.

[danwaineo]

Interesting. Thanks for posting. I've only tried the 32 bit versions on my DG965OT.

[tji]

After some more searching around, I found reports of similar behavior from 64bit Vista users:

http://forums.microsoft.com/technet/...&tf=0&pageid=2

Running with 1,2,or 3GB of RAM works fine, but when you put 4GB in, it slows to a crawl.


I had tested earlier with 2GB of RAM, but that didn't work for me. I must have mixed that up with the problems with the PATA DVD-R, because when I tried it again it worked great with 1-3GB and only slowed down with 4GB.

The Vista thread suggests backing off to BIOS version 1669, which they say works fine with 4GB in 64bit mode. So, that may be my next move. For now, I've got 64bit Fedora 7 installed, and 3GB of RAM operational. So, things are looking much better than a couple days ago.

[tji]

I installed BIOS version 1669, and with that version it runs at normal speed in 64bit mode and 4GB of RAM.

Of course, even reverting to that BIOS version was not so simple.. with my SATA DVD drive the BIOS install ISO failed saying it couldn't find a drive. I had to put the PATA drive back in to install the BIOS.


I guess I was really unlucky to buy a board shortly after they released a bad BIOS, then use it with 4GB of RAM and a 64 bit OS.

[marko]

Since the slowness only seems to affect the install, why not either set
the bios to ignore part of the ram so it just sees 3GB or whatever
you like < 4GB. then install linux. When done return to the bios and
turn it back on. You could also set the kernel only at install time to
just use 3GB:

boot: linux mem=3G

Or the hardware way, remove the stick physically, do the install and
put it back in.

Mark

[manoreken]

Hello. I'm new to this forum.

I experienced similar problem to tji.
Fedora Core6 x86-64 installer was awfully slow.

Intel DG965WH.
RAM 4GB (DDR667 2GB 5-5-5-15 x2)
BIOS version 1687.

I searched the net and found this thread.
I reverted BIOS version to 1669 and...
The problem was disappeared!!

Thanks tji

[tji]

Since the slowness only seems to affect the install, why not either set
the bios to ignore part of the ram so it just sees 3GB or whatever
you like < 4GB. then install linux. When done return to the bios and
turn it back on. You could also set the kernel only at install time to
just use 3GB:

boot: linux mem=3G

Or the hardware way, remove the stick physically, do the install and
put it back in.

It's not just an install problem, it effects all aspects of the system. I just focused on the install because while the problem was happening I couldn't get past the install.. it would have taken days to complete. After installing the OS with less memory, I put back in 4GB and it went back to dog slow.

Also, in the Intel BIOS, there is no way to disable memory modules. The settings are limited to memory timings. I tried decreasing the memory speed, but that made no difference.

It seems to be strictly a BIOS issue, not related to the Linux kernel, since people also see this with Vista 64.

[tji]

Hello. I'm new to this forum.

I experienced similar problem to tji.
Fedora Core6 x86-64 installer was awfully slow.

Intel DG965WH.
RAM 4GB (DDR667 2GB 5-5-5-15 x2)
BIOS version 1687.

I searched the net and found this thread.
I reverted BIOS version to 1669 and...
The problem was disappeared!!

Thanks tji

Glad to help. I also reported it to Intel's motherboard support. So, hopefully they will fix it quickly, or at least document it to prevent others wasting time on this problem.

[manoreken]

or at least document it to prevent others wasting time on this problem.

Indeed it was a waste of time

Last night I set up memtest86 3.3 with a newly bought 8GB of memory(2GB stick x4).
Today I woke up and turn on the monitor and shocked.
Memtest progressed only 2percent ...

Now with older BIOS I restarted memtest86.
It was not completed yet but it progressed 22percent in 90 minutes so far.

BIOS 1669 is 50x faster than BIOS 1687.

[jussit]

I have Intel DG965WH which is also completely useless with 4 GB of RAM and without any kernel parameters. If booting (installer or installed OS) with kernel parameter mem=4G the system is fast, but only 3 GB of RAM was deployed. For more details about my problem and my temporary workaround to detect full 4 GB and still run system fast is available at:

https://bugzilla.redhat.com/bugzilla....cgi?id=239931

So wrote a shell script to initialize /proc/mtrr manually and called that script as the first task in /etc/rc.d/rc.sysinit.

I have also contacted Linus and then Intel, since this looks like a BIOS problem, not a Linux kernel or Fedora problem. Got a reply from Intel that they will keep me informed when a new BIOS release is available someday. Currently usin BIOS 1687 which is the same BIOS that DG965RY uses. I guess this is a common problem with Intel DG965 series motherboards.

To install a OS with 4 GB of RAM installed, always use 'mem=4G' switch. That helps.

[tji]

Yeah, that was the same BIOS version I had problems with. I looked through the release notes for the BIOS releases, and didn't see any major issues relevant to me in the releases after 1669. I have also not seen any performance or functionality issues when using 1669.

The release dates between 1669 (April 6, 2007) and the next version which introduced the performance problem (April 13, 2007) was only a week. So, obviously not a lot of testing happened before the bug was introduced. Unfortunately, they are not as quick to put out a remedy.


Why not just back off to 1669 BIOS, to get full 4GB RAM without any extra modifications?

[jussit]

Why not just back off to 1669 BIOS, to get full 4GB RAM without any extra modifications?

That was new information to me. Haven't tested it. I think I stay with the current BIOS with my workaround, and look forward to next BIOS release if they were able to fix this BIOS problem.

You can easily test my workaround. Write a script, say /usr/bin/mtrrfix.sh and put there those

#!/bin/sh
echo "base=0x100000000 size=0x20000000 type=write-back" >| /proc/mtrr
echo "base=0x120000000 size=0x8000000 type=write-back" >| /proc/mtrr
echo "base=0x128000000 size=0x4000000 type=write-back" >| /proc/mtrr


Supposing that the memory map on your system is identical to mine:

$ dmesg | grep BIOS-e820
BIOS-e820: 0000000000000000 - 000000000008f000 (usable)
BIOS-e820: 000000000008f000 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 00000000cf58f000 (usable)
BIOS-e820: 00000000cf58f000 - 00000000cf59c000 (reserved)
BIOS-e820: 00000000cf59c000 - 00000000cf64d000 (usable)
BIOS-e820: 00000000cf64d000 - 00000000cf6a5000 (ACPI NVS)
BIOS-e820: 00000000cf6a5000 - 00000000cf6a8000 (ACPI data)
BIOS-e820: 00000000cf6a8000 - 00000000cf6ef000 (ACPI NVS)
BIOS-e820: 00000000cf6ef000 - 00000000cf6f1000 (ACPI data)
BIOS-e820: 00000000cf6f1000 - 00000000cf6f2000 (usable)
BIOS-e820: 00000000cf6f2000 - 00000000cf6ff000 (ACPI data)
BIOS-e820: 00000000cf6ff000 - 00000000cf700000 (usable)
BIOS-e820: 00000000cf700000 - 00000000d0000000 (reserved)
BIOS-e820: 00000000fff00000 - 0000000100000000 (reserved)
BIOS-e820: 0000000100000000 - 000000012c000000 (usable)


Now, reboot to single user mode (give kernel parameter 'single' if your boot loader menu does not have a single user mode selection available. It takes time to boot upto to bash shell because of this BIOS bug. When booted (in 5 minutes or so), run the script you wrote and check 'free' as well as 'cat /proc/mtrr' to confirm, that you got now 4 GB detected. If it works, use your favourite ascii editor to carefully add a launch call to the script in the beginning part of script /etc/rc.d/rc.sysinit which could be something like

#!/bin/bash
#
# /etc/rc.d/rc.sysinit - run once at boot time
#
# Taken in part from Miquel van Smoorenburg's bcheckrc.
#

# initialize /proc/mtrr manually for 4 GB RAM:
. /usr/bin/mtrrfix.sh

HOSTNAME=`/bin/hostname`
HOSTTYPE=`uname -m`
unamer=`uname -r`

[ .. rest of rc.sysinit removed here .. ]


That's quite a hack but it really works.

Jussi

[jussit]

So I have Intel DG965WH mobo with Intel E6600 processor. Is this CPU supported in that old 1669 BIOS release? Release notes of the BIOS just tells about changed CPU support between releases, but no further information included.