From: "Mike McCarthy, W1NR" <lists@w1nr.net>
To: "Stan Gammons" <s_gammons@charter.net>,
"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>
Subject: Re: 64 bit kernel
Date: Mon, 9 Jan 2006 08:25:35 -0500 [thread overview]
Message-ID: <001c01c61520$2cbba6b0$6d0ea8c0@LoJackOne.LoJack.com> (raw)
In-Reply-To: <1136780835.6695.37.camel@falklands.home.pc>
I saw a similar issue many years ago that turned out to be a chipset bug.
This was a PII system that used 16 bit wide modules. When using only one
module, the chipset "fooled" the OS into thinking that it was doing 32 bit
wide operations. However, it failed at full speed. Reducing the memory bus
speed or installing modules in pairs "fixed" the problem. I suspect a bus
or memory controller issue rather than the kernel.
The failure mode was exactly as you describe. It manifested itself as disk
errors or DMA failures. Unfortunately the chipset vendor determined that it
was a silicon bug and said that they would NOT fix it!
Mike
----- Original Message -----
From: "Stan Gammons" <s_gammons@charter.net>
To: "Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>
Sent: Sunday, January 08, 2006 11:27 PM
Subject: 64 bit kernel
> Hi everyone,
>
> I was wondering if anyone can tell me if the following is a 64 bit
> kernel problem or if it's a BIOS problem.
>
> I have a Gigabyte K8NSC-939 with an AMD64 3200+ (Venice) CPU version F7
> BIOS. When I first got this board, I put a single 512 Mb PC2700 DIMM in
> it from an older Celeron board I had. 32 bit Suse 10.0 and 32 bit FC4
> loaded fine. When I tried the 64 bit version of either, I kept getting
> DMA errors on boot like the HD or controller was bad. After some
> searching I found others with similar problems and they had to use
> "noapic nolapic" kernel boot options to install and boot the OS. That
> worked for me too and I was able to install the OS.
>
> After I upgraded the memory and put 2 512Mb PC3200 DIMMS in the board. I
> tried a 64 bit install again. This time I no longer had to use the
> "noapic nolapic" options. With a single DIMM, BIOS (during boot)
> reported "single channel" memory. With 2 DIMMS, BIOS (during boot)
> reports "dual channel" memory. My question though is does the 64 bit
> kernel require "dual channel" memory or is this a BIOS problem?
>
>
>
> Stan
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
next prev parent reply other threads:[~2006-01-09 13:25 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-01-09 4:27 Stan Gammons
2006-01-09 13:25 ` Mike McCarthy, W1NR [this message]
2006-01-09 15:04 ` Gene Heskett
2006-01-09 22:47 ` Stan Gammons
2006-01-09 18:25 ` Andi Kleen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='001c01c61520$2cbba6b0$6d0ea8c0@LoJackOne.LoJack.com' \
--to=lists@w1nr.net \
--cc=linux-kernel@vger.kernel.org \
--cc=s_gammons@charter.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®