altivo: The Clydesdale Librarian (Miktar's Altivo)
[personal profile] altivo
Well, we did get some shopping done, and had lunch out. But most of the day was spent hassling with the crashed computer, which is still not back up. They replaced the hard drive, and have had a terrible time getting the supposedly simple backup software to actually restore the contents of the drive. While they had it open, they noticed that it had two empty RAM slots and Gary decided to expand the memory. So, with considerable doubt, I accompanied him to Best Buy to get two 1 GB DDR2 memory boards. They had some on sale that fit the spec and claimed to be compatible with his machine, so we took two, and went back. Installed them. BIOS can see them, good. Windows only uses one, so instead of 4 GB of RAM, he has 3. Went back to the BIOS and sure enough, one of them is a 1 rank design while the other is 2 ranks. Even though they were packaged identically, with the same part number and specs on the outside of the containers, they are electronically different.

So we take them back. Best Buy manager agrees that they are different and that probably causes a problem. We go back to the locked cabinet with him only to find that the others they have are all of the 1 rank design. The two already in the machine are 2 rank. We finally decided to exchange the 2 rank for a 1 rank so the pair will match, which I think is sufficient for it to work. I know I've installed single rank DIMMs into a machine that had double ranks in two slots already and it worked. But we won't know until tomorrow.

Went to the evil empire of W to finish our grocery shopping. Gary got some clothes for his classes that start again on Monday. I splurged on a new book bag/briefcase for work, since the two I've been using are literally falling apart. It was all of nine dollars and has lots of pockets. Places to put things, yay.

Came home, put groceries away, fed dogs, made very late dinner. Now it's bed time, except it's too soon after eating to lie down. Boo. Hopefully tomorrow will be better, though it will also be chewed by the not yet working PC. The Clinton parade is tomorrow, but looks like we'll miss it. My brother is coming for dinner, which is not to be missed. We see him about once every two years. Meanwhile, no progress on the fiber work that I'm supposed to do this week.

Date: 2009-08-23 04:53 am (UTC)
From: [identity profile] duskwuff.livejournal.com
You're barking up the wrong tree with Gary's computer. 32-bit editions of Windows can only use up to (around) 3 GB of RAM.

Date: 2009-08-23 05:58 am (UTC)
ext_185737: (Rex - Cool dude...)
From: [identity profile] corelog.livejournal.com
Keep in mind that 32-bit versions of Windows can only use a total of 4GB of memory. The tricky bit, though, is the fact that Windows uses some of those memory addresses for driver and kernel functions, which means the full 4GB is never available to the system.

There is a way around this, but it involves mucking with the boot switches in the boot.ini file. Commonly quoted is the /3GB switch, but this will not help so much. I believe the correct switch is /PAE, which enables Physical Address Extension. Windows still won't use more than 4GB of RAM, but that should enable use of the full 4GB.

*checks* Yes, this is excerpted from http://support.microsoft.com/kb/833721: Use the /PAE switch with the corresponding entry in Boot.ini to permit a computer that supports physical address extension (PAE) mode to start normally.

There's actually a seperate version of ntoskrnl.exe that supports PAE. I don't remember the PAE version's filename, but using the switch causes the bootloader to use the PAE version instead, thus enabling the full 4GB RAM capacity, while still preserving the usual 1.5GB of memory-mapped addressing space reserved by the kernel for internal functions and driver use.

Date: 2009-08-23 12:53 pm (UTC)
ext_39907: The Clydesdale Librarian (radio)
From: [identity profile] altivo.livejournal.com
You're right, at least in part. I had forgotten about these peculiarities in Microsoft systems because I don't deal with them. Linux or other current environments make it more transparent, and The Alpha processors, being native 64-bit machines, never had it.

This whole mess was referred to a friend who is much more patient with Windows than I ever have been. Evidently he also forgot about this limitation (or never knew.) I've now found the relevent Microsoft documentation, which is a nest of recursive and digressionary self references and absolutely horrid. It seems to suggest that more memory can be made available, but the cost of doing so may include failure of some software and device drivers. That's probably not worth the bother in this case, so I expect he'll have to settle for 3 out of the 4 available GB. Mucking with BOOT.INI doesn't really sound like something we want to do.

Date: 2009-08-23 01:02 pm (UTC)
ext_39907: The Clydesdale Librarian (radio)
From: [identity profile] altivo.livejournal.com
Thanks. See note to [livejournal.com profile] duskwuff above. It would appear that this is the newest version of Microsoft's old 640KB line, eh? "No one will ever have more than 2GB of RAM, so why worry about it?" Right.

Linux kernels 4.6 and later apparently handle large memory models quietly and automatically. They were well ahead of Vista, which does it by making all the old hardware drivers dysfunctional and forcing everyone to start over, do not pass "go", do not collect $200... Based on Microsoft documentation, it appears that XP may be able to deal with the large memory by virtual addressing that limits any one application to 2 GB but allows an aggregate total that is larger. However, this can be implemented only if the user is willing to chase the truth around a mobius strip and into a klein bottle to figure it out. I'm not willing to bother.

Date: 2009-08-23 03:22 pm (UTC)
From: [identity profile] rustitobuck.livejournal.com
Yeah, before I went to bed last night, I booted my laptop (which has a recent Core 2 Duo and an nVidia chipset) into Windows, and even with PAE, it only sees 2.97GB of 4GB.

There's some discussion here which seems to indicate that the system only maps memory and devices into 32-bit addresses to avoid problems with PCI cards that are doing DMA.

What really takes a bit out is that the top gigabyte is taken up with Memory-Mapped I/O (MMIO). Basically, if you have, say, a 256MB video card, that memory has to be mapped somewhere. Similarly with the AGP aperture and other things.

But anyway, I thought I'd give it a try, and I can tell you that 32-bit XP can't use all 4 GB of RAM even with modern and capable hardware.

Date: 2009-08-23 03:26 pm (UTC)
From: [identity profile] rustitobuck.livejournal.com
The 2GB maximum virtual size of a process is an arbitrary choice to split the address space into user and kernel addresses, just like in VMS. The boundary can be moved to 3GB with the /3GB switch.

On OS X, and I think on Linux and BSD as well, the kernel is not visible from a user process, so the whole 4GB is available. In fact, this also lets OS X run 64-bit processes on a machine running a 32-bit kernel.

I don't know how Linux and OS X get around the PCI DMA limitation. PCI has a 32-bit address bus, and so any PCI cards doing DMA have to be looking at a buffer in the first 4GB of physical address space. Maybe those OS' are just careful where they put the buffers.

Date: 2009-08-23 03:34 pm (UTC)
ext_39907: The Clydesdale Librarian (Default)
From: [identity profile] altivo.livejournal.com
Yep, I figured that out this morning. It's amusing really. I watched and lived through IBM having the exact same problems with 32 bit addressing back in the 1980s, as MVS morphed into MVS/SP1 and eventually MVS/XA. Not that anyone had gigabytes of memory back then, but mainframes finally had disk storage large enough to allow virtual memory addresses in the multi-gigabyte ranges. Because MVS had reserved the eight high order bits of a 32 bit program counter for use as flags and status bits, MVS could only handle addresses up to 24 bits. Application software likewise assumed that anything above 24 bits was not part of the address. The upheaval was similar to what happened with Windows going to Vista, Hardware drivers broke, operating system routines failed. The shakeout took a couple of years.

Then we had Mr. Gates with his declaration that "No one will ever need more than 640K" so MS-DOS had a built in limitation that eventually had to be overcome. After that it was the move to full 32 bit addressing capability (when? 80386 to 80486 I think, but I may be wrong.) And here we see Windows with the same issue that IBM had 20 years ago, and the only difference is that they messed up their own ability to address physical memory rather than virtual (though I suspect virtual memory addressing has the same issue, so no one application can deal with more than 2 GB at once.)

Date: 2009-08-23 08:17 pm (UTC)
From: [identity profile] duskwuff.livejournal.com
Under Linux, PCI IO mappings all go into the first 4GB, and physical memory gets mapped higher up as necessary. Not sure about OS X (as it's less exposed and I've never bothered looking closely), but I expect it does something similar, as I've got 4GB in my laptop, all of which is accessible. :)

Date: 2009-08-24 07:08 am (UTC)
From: [identity profile] duskwuff.livejournal.com
Despite popular belief, the 640K limit wasn't Microsoft's doing. Instead, it's largely the result of architectural limitations of Intel's processors when operating in 16-bit mode, combined with the IBM PC architecture - out of a 20-bit (1 MB) address space, the upper 384 KB were reserved for hardware, leaving 640 KB for applications. This was resolved with the 80386, which introduced 32-bit addressing (as well as memory protection).

Date: 2009-08-24 05:40 pm (UTC)
From: [identity profile] cabcat.livejournal.com
Someone sounds like he's a grumpy wumpy pony, which means he's going to get tummy pokes till he cheers up ;) *runs off holding his tail in front of him*

Date: 2009-08-26 01:53 am (UTC)
ext_39907: The Clydesdale Librarian (Default)
From: [identity profile] altivo.livejournal.com
I'm degrumped a bit now, but I can tell that this week is going by too fast.

November 2024

S M T W T F S
     12
345678 9
10111213141516
17181920212223
24252627282930

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Jan. 26th, 2026 09:05 am
Powered by Dreamwidth Studios