[gentoo-amd64] Re: 965 chipset and 2 DIMM slots will never give 4GB available? Is that correct?

[gentoo-amd64] Re: 965 chipset and 2 DIMM slots will never give 4GB available? Is that correct?

[Evert]

Evert wrote:
> Hi all!
> 
> I was having some trouble with my AOpen EU965 barebone (
> http://xc.aopen.com.tw/Cube-m-specification%20.aspx?Auno=2209 ) and getting access to the
> full 4GB I plugged into it.
> 
> And now their helpdesk is telling me the following:
> 
> 'Based on the specification of the chipset, it can support 8GB when using 4 DIMM slot. Our
> MB had 2 slot only, so the max memory is 4GB. But if the main memory is 4GB, OS will
> allocate 3~4GB memory address for onboard device. This is why you can only get 3.xGB when
> you install 4GB memory. Other 965 chipset with 2 DIMM slot had the same result. The only
> way is use a 4 slot MB and add the memory more then 4GB. So that the memory size in OS
> will the same as you installed.'

I read their text again and noticed: 'OS will allocate 3~4GB memory address for onboard
device'.
Wouldn't that mean it's simply a (kernel)configuration issue...?


Regards,
	Evert

PS. I added gmane.linux.gentoo.amd64 to this thread, in case it is just a config-matter.
Here is 'uname -a' of the system:
Linux XCcube 2.6.22-gentoo-r8 #1 SMP Thu Sep 27 23:10:28 CEST 2007 x86_64 Intel(R)
Core(TM)2 Quad CPU @ 2.40GHz GenuineIntel GNU/Linux

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: 965 chipset and 2 DIMM slots will never give 4GB available? Is that correct?

[Volker Armin Hemmann]

On Donnerstag, 18. Oktober 2007, Evert wrote:

> I read their text again and noticed: 'OS will allocate 3~4GB memory address
> for onboard device'.
> Wouldn't that mean it's simply a (kernel)configuration issue...?

no, it is a 'stupid bios' issue. The bios could put the pci/other device 
memory space somewhere in the high terrabyte area, but instead it chooses to 
put it at the end of the 4gb range, because of historical reasons.
-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] Re: 965 chipset and 2 DIMM slots will never give 4GB available? Is that correct?

[Duncan]

Volker Armin Hemmann <volker.armin.hemmann@tu-clausthal.de> posted
200710181500.24885.volker.armin.hemmann@tu-clausthal.de, excerpted below,
on  Thu, 18 Oct 2007 15:00:24 +0200:

> On Donnerstag, 18. Oktober 2007, Evert wrote:
> 
>> I read their text again and noticed: 'OS will allocate 3~4GB memory
>> address for onboard device'.
>> Wouldn't that mean it's simply a (kernel)configuration issue...?
> 
> no, it is a 'stupid bios' issue. The bios could put the pci/other device
> memory space somewhere in the high terrabyte area, but instead it
> chooses to put it at the end of the 4gb range, because of historical
> reasons.

This is correct.  Here's a bit more detail.

Many legacy PCI devices (and possibly some PCI-E devices, I don't know as 
my board is PCI-X, not yet PCI-E) and/or their drivers (mainly a problem 
with closed source drivers if the device and board handles 64-bit, AFAIK) 
are designed to run in a 32-bit address space only.  As such, PCI device 
address space is normally located at the top of the 32-bit addressable 
memory area -- 3.5 to 4 GB.  Naturally, if devices are using that address 
space, it's not available to be used by memory, so there's a "memory 
hole" at that location -- about a half GB just below the 4 GB boundary, 
thus under /normal/ circumstances, limiting actual usable/addressable 
memory to ~3.5 GB if one has 4 GB memory, or ~half a GB less than total 
memory if one has > 4 GB.

There is, however, a BIOS workaround, depending on whether the mobo and 
BIOS installed support it or not.  Basically what it does is move the 
memory otherwise covered by the "hole" up beyond 4 GB, so with 4 GB 
memory, you'll actually have usable memory addresses running to ~4.5 GB.  
(Or, some implementations move the entire GB, or even two gigs, so you 
may see addresses to 5 or even 6 gigs, but only have 4 gigs memory.  Mine 
seems to move 2 gigs, so my 8 gigs memory appears as 10 gigs at POST.)

If the BIOS supports this memory address move, you'll see one or two 
different options therein.  Since I'm booted ATM I don't have immediate 
access to my BIOS to check and I don't remember exactly what they are, 
but I have two separate options here.  IIRC one of them is something like 
"contiguous memory" vs. something else.  The other one I don't remember 
at all ATM, only that I had it.  I never was entirely clear at what the 
specific interaction between them was, but one definitely has to be set 
correctly to get the addressing working right, while the other... I'm not 
sure about.  I just played with it and a kernel option or two until I got 
it working.

However, the first thing is that your BIOS supports it at all.  If it 
doesn't, you're simply SOL, unless you are lucky and they have a BIOS 
update adding the feature.  Unfortunately, given the reply from the 
board's support people as you quoted, specifically that they didn't 
mention any such feature at all, it would appear their BIOS doesn't 
support it, and you are stuck with 3.5 GB.  Of course, if they don't 
support Linux, they may not have known that it can take advantage of such 
an option given the chance, and may have given you the standard MSWormOS 
(or whatever) support answer, and their BIOS actually /does/ have the 
option.

Note that I've read of advanced users flashing a BIOS with the features 
they want but designed for another board using the same base chipset.  Of 
course, that's going to void your warrantee and could well end up 
bricking your board, but it's an option if you want to risk it.  It's 
also possible to replace the BIOS chip itself, and to buy BIOS chips pre-
flashed with various BIOS images, so if you decided to go that route, you 
could buy one flashed with some BIOS with that feature and see if it 
worked, without risking overwriting the supported BIOS on your current 
chip.  Of course, that's well beyond anything I've tried, and in the 
general case, if you were advanced enough to work with that sort of 
thing, you'd probably know all this including the above about the PCI 
device memory hole already, so it's well beyond anything I'd recommend.  
However, the option is there if you are suitably determined, and have 
access to the appropriate resources (a friend that has the tools and 
knows what they are doing, or funds to purchase the service commercially, 
or such that the risk of bricking isn't a major worry).

If you'd like the specific BIOS settings, I can reboot and look them up, 
but I'm not going to bother unless given the above, you think you might 
have the options, need to know more, and specifically request that info.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] Re: 965 chipset and 2 DIMM slots will never give 4GB available? Is that correct?

[Evert]

Duncan wrote:
> Volker Armin Hemmann <volker.armin.hemmann@tu-clausthal.de> posted
> 200710181500.24885.volker.armin.hemmann@tu-clausthal.de, excerpted below,
> on  Thu, 18 Oct 2007 15:00:24 +0200:
> 
>> On Donnerstag, 18. Oktober 2007, Evert wrote:
>>
>>> I read their text again and noticed: 'OS will allocate 3~4GB memory
>>> address for onboard device'.
>>> Wouldn't that mean it's simply a (kernel)configuration issue...?
>> no, it is a 'stupid bios' issue. The bios could put the pci/other device
>> memory space somewhere in the high terrabyte area, but instead it
>> chooses to put it at the end of the 4gb range, because of historical
>> reasons.
> 
> This is correct.  Here's a bit more detail.
> 
> Many legacy PCI devices (and possibly some PCI-E devices, I don't know as 
> my board is PCI-X, not yet PCI-E) and/or their drivers (mainly a problem 
> with closed source drivers if the device and board handles 64-bit, AFAIK) 
> are designed to run in a 32-bit address space only.  As such, PCI device 
> address space is normally located at the top of the 32-bit addressable 
> memory area -- 3.5 to 4 GB.  Naturally, if devices are using that address 
> space, it's not available to be used by memory, so there's a "memory 
> hole" at that location -- about a half GB just below the 4 GB boundary, 
> thus under /normal/ circumstances, limiting actual usable/addressable 
> memory to ~3.5 GB if one has 4 GB memory, or ~half a GB less than total 
> memory if one has > 4 GB.
> 
> There is, however, a BIOS workaround, depending on whether the mobo and 
> BIOS installed support it or not.  Basically what it does is move the 
> memory otherwise covered by the "hole" up beyond 4 GB, so with 4 GB 
> memory, you'll actually have usable memory addresses running to ~4.5 GB.  
> (Or, some implementations move the entire GB, or even two gigs, so you 
> may see addresses to 5 or even 6 gigs, but only have 4 gigs memory.  Mine 
> seems to move 2 gigs, so my 8 gigs memory appears as 10 gigs at POST.)
> 
> If the BIOS supports this memory address move, you'll see one or two 
> different options therein.  Since I'm booted ATM I don't have immediate 
> access to my BIOS to check and I don't remember exactly what they are, 
> but I have two separate options here.  IIRC one of them is something like 
> "contiguous memory" vs. something else.  The other one I don't remember 
> at all ATM, only that I had it.  I never was entirely clear at what the 
> specific interaction between them was, but one definitely has to be set 
> correctly to get the addressing working right, while the other... I'm not 
> sure about.  I just played with it and a kernel option or two until I got 
> it working.
> 
> However, the first thing is that your BIOS supports it at all.  If it 
> doesn't, you're simply SOL, unless you are lucky and they have a BIOS 
> update adding the feature.  Unfortunately, given the reply from the 
> board's support people as you quoted, specifically that they didn't 
> mention any such feature at all, it would appear their BIOS doesn't 
> support it, and you are stuck with 3.5 GB.  Of course, if they don't 
> support Linux, they may not have known that it can take advantage of such 
> an option given the chance, and may have given you the standard MSWormOS 
> (or whatever) support answer, and their BIOS actually /does/ have the 
> option.
> 
> Note that I've read of advanced users flashing a BIOS with the features 
> they want but designed for another board using the same base chipset.  Of 
> course, that's going to void your warrantee and could well end up 
> bricking your board, but it's an option if you want to risk it.  It's 
> also possible to replace the BIOS chip itself, and to buy BIOS chips pre-
> flashed with various BIOS images, so if you decided to go that route, you 
> could buy one flashed with some BIOS with that feature and see if it 
> worked, without risking overwriting the supported BIOS on your current 
> chip.  Of course, that's well beyond anything I've tried, and in the 
> general case, if you were advanced enough to work with that sort of 
> thing, you'd probably know all this including the above about the PCI 
> device memory hole already, so it's well beyond anything I'd recommend.  
> However, the option is there if you are suitably determined, and have 
> access to the appropriate resources (a friend that has the tools and 
> knows what they are doing, or funds to purchase the service commercially, 
> or such that the risk of bricking isn't a major worry).
> 
> If you'd like the specific BIOS settings, I can reboot and look them up, 
> but I'm not going to bother unless given the above, you think you might 
> have the options, need to know more, and specifically request that info.
> 

Thank you for putting the whole problem in cleartext. I have forwarded your text to AOpen,
hoping that even they understand it... ;-)
(I understood the problem already, but it's not easy to get AOpen to see this/my point of
view on the issue...)


Thanks! :-)

   Evert

-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] Bad LiveCD at torrent site?

[Kevin N. Carpenter]

Just a note that the livecd 2007.0 iso image at the torrent site appears 
to be unbootable.  At least my new system couldn't handle it (burned 3 
CDs trying).  The livedvd image is fine.

Symptom was simple:  the system hung during the first stage of the boot.

Kevin
-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] Re: Bad LiveCD at torrent site?

[Duncan]

"Kevin N. Carpenter" <kevinc@seaplace.org> posted
4718CD44.5010503@seaplace.org, excerpted below, on  Fri, 19 Oct 2007
10:29:08 -0500:

> Just a note that the livecd 2007.0 iso image at the torrent site appears
> to be unbootable.  At least my new system couldn't handle it (burned 3
> CDs trying).  The livedvd image is fine.
> 
> Symptom was simple:  the system hung during the first stage of the boot.

Nothing to add re: your note, but...

Next time please avoid hijacking a thread.  You apparently hit reply to 
an existing message, then replaced the subject line with your own, 
starting a new topic.  The problem is, the reference headers still point 
to the message you replied to as your message parent, so it appears in 
the same thread in clients designed to thread based on those headers (the 
purpose for them, after all), so your message ends up hijacking the 
original thread, starting an entirely different subject under it.

The better alternative is to always start a /new/ post (not a reply to an 
existing post) when you intend to start a new thread.  That way, it /is/ 
a new thread, having no reference headers to existing messages.

Thanks in advance. =8^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] Re: 965 chipset and 2 DIMM slots will never give 4GB available? Is that correct?

[Duncan]

Evert <evert@poboxes.info> posted bifmu4-nhd.ln1@poboxes.info, excerpted
below, on  Fri, 19 Oct 2007 13:04:11 +0200:

> Thank you for putting the whole problem in cleartext. I have forwarded
> your text to AOpen, hoping that even they understand it... ;-) (I
> understood the problem already, but it's not easy to get AOpen to see
> this/my point of view on the issue...)

Hopefully they can be made to see it. then. =8^)

FWIW, while they /are/ somewhat more expensive (being targeted at 
servers), I've been /very/ happy with Tyan.  They seem to have the best 
Linux support of any of the big board makers, even offering preconfigured 
lm_sensors.conf files in many cases (including mine), as well as 
certifying to Red Hat, SuSE, etc.  I was also quite surprised when well 
after I bought this board and after many manufacturers would be end-of-
life-ing their products, Tyan was still updating their BIOS firmware, and 
did so to provide dual-core support on this board and several others 
where they could, even tho the board had never been originally designed 
or marketed with that feature.  That was quite a pleasant surprise! =8^)  
OTOH, as I said, more expensive.  It's a dual-socket-940 Opteron system; 
a roughly $400 board.  Still, that's in line with what other makers were 
charging for similar at the time.

Anyway, altho I'll likely move back down-scale some at my next upgrade, 
it's quite likely that Tyan got a repeat customer.  I've been very happy 
with both the board itself and with Tyan's Linux support (altho there was 
a memory timing issue in the early BIOS versions that drove me crazy for 
awhile, given I had generic memory that wasn't quite stable at the 
labeled speeds; but they solved that nicely too; it just took a bit 
longer than I'd have liked, given I had the problem at the time).

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: 965 chipset and 2 DIMM slots will never give 4GB available? Is that correct?

[Volker Armin Hemmann]

On Freitag, 19. Oktober 2007, Duncan wrote:
> Evert <evert@poboxes.info> posted bifmu4-nhd.ln1@poboxes.info, excerpted
>
> below, on  Fri, 19 Oct 2007 13:04:11 +0200:
> > Thank you for putting the whole problem in cleartext. I have forwarded
> > your text to AOpen, hoping that even they understand it... ;-) (I
> > understood the problem already, but it's not easy to get AOpen to see
> > this/my point of view on the issue...)
>
> Hopefully they can be made to see it. then. =8^)
>
> FWIW, while they /are/ somewhat more expensive (being targeted at
> servers), I've been /very/ happy with Tyan.  

well, you were lucky. Just got to a lkml archive of your choice and search for 
tyan. A lot of people had data-corruption problems with Tyan boards.

Sadly, today even the expensive stuff is crap (as I learnt the hard way some 
weeks ago. Two dead mobos and a enermax psu that killed them).
-- 
gentoo-amd64@gentoo.org mailing list