There are two ways your processor can access devices attached to the rest of the system, either through ports or through memory mapped input output (MMIO). Everything uses MMIO because ports are sucky.
A 32bit system has 2^32 numbers to play with, which gives it 4GiB of numbers (or 'address space') to map different MMIO devices to.
Anything attached to your system will take up some of this available address space. Normally this isn't much of an issue because the address space used by, say, your ethernet controller is fairly small. However this situation starts to change once you start putting in graphics cards with huge amounts of RAM. The card takes up part of the address space, but it gets complicated because not all the address space gets mapped to physical RAM. A GeForce GTX280, which has 1GiB of RAM, for example will map 256MiB of address space, as will most modern 512MiB high-end cards.
Devices get assigned address space first, and your RAM gets assigned to what is left over. If your available RAM exceeds the left over address space therefore, it 'vanishes', leaving you with the ~3.2GB problem with 4GB physically installed on a 32bit OS.
All current 32bit x86 processors actually support 36bit addressing. Indeed, run 32bit Windows XP prior to SP2, or 32bit Windows Server 2008 Datacenter (which supports up to 64GiB) and they will happily show you more than 4GiB RAM if you have more than that installed.
In fact you're probably running with PAE enabled in Windows anyway without knowing it. If you don't have "/noexecute=disable" in your boot.ini then PAE will be enabled. This is because a larger address space is required for processors to be able to use 'no execute', and the NX-bit is obviously required for DEP which has been present in XP since SP2 and is in all versions of Vista.
The reason your can't get 32bit Windows to show more than 4GiB of RAM is because MS had to artificially limit it, starting with XP SP2. This is because certain companies (nVidia) couldn't write drivers that could cope with an expanded address space. MS therefore simply limited the address space Windows could use.
Each application can only access 2GiB of virtual address space anyway (apps don't address RAM directly, they use v.a.s, and so some of the pages could be in RAM, some might be in the swap file etc). The OS can't assign any more than that, but tbh it would be extremely unlikely for any app to use anywhere near that amount of address space anyway. It is possible for something like Photoshop to push this limit with massive files and complex operations - 36bit addressing wouldn't help there unless the application was developed to use Address Windowing Extensions (AWE) to take advantage of extra address space, and you ran the /3GB switch to enable Windows to assign more than 2GiB virtual address space to the app (which has its own performance tradeoff for the rest of the system as it causes the TLB to be continually flushed).
There is also some simplication above, as not all the 'lost' RAM is lost for system I/O. Almost 1GB gets taken up by the PFN database, which is where the memory manager keeps track of all open pages. The rest of the 2GiB virtual space for the OS itself is all that remains to map the kernel, device drivers etc.
Still, 2.3GiB is rather low. You probably have a feature in your BIOS setup set incorrectly - look for something called "memory remap" or similar, as this can cause 32bit XP to lose even more RAM.
The solution to all this is to install a 64bit operating system.
You do not have dual channel RAM - technically there is no such thing.
What you probably have is a dual channel memory controller, which is a chip on your motherboard.
If a board has, say, 4 DIMM slots and a dual channel MCH then two slots will be channel A, two channel B.
If you populate the channel A slots but not the channel B slots then obviously the MCH only has a single channel to work with.
So yes, you are correct in your thinking - you need to move one of your DIMMs into a different slot. The Chinglish motherboard manuals are often not terribly clear
