This mailing list post explains why.
A 2GB SD card reports a 1024 byte block size instead of the 512 byte block size that all smaller SD cards employ. However, I/O is performed in 512 byte blocks by the USB mass storage driver. The card reader is supposed to know about this and report a 512 byte block size, while multiplying the number of blocks reported by the card by 2, in order to report the correct card geometry to the operating system.
Older card readers do not know about this conversion, and may even assume that all SD cards have a 512 byte block size. Thus, a 512 byte block size is reported, along with the number of blocks reported by the card. This cuts the reported capacity of the card in half.
But the filesystem that exists on the card reports a 2GB size. On a system where the card physically only shows up as 1GB, this causes the FAT filesystem driver to read past the end of the card. This will produce read/write errors, and could even crash the filesystem driver if it is not equipped to deal with this case.
Windows reportedly employs one of two solutions to ensure that 2GB cards are correctly recognized.
The first solution is to assume that the card has a PC partition table on it (a mostly correct assumption for any card purchased retail). The Windows USB mass storage driver then examines the partition table to determine the number of blocks on the physical device, and ignores the number of blocks reported by the reader. A possible flaw with this scheme is that the Windows driver may not account for cases where a partition table has been erroneously or maliciously constructed, leading to an incorrect physical size being entered, and thus a device which cannot be correctly repartitioned or reformatted. It may also not account for the device being divided into several partitions. And of course this scheme won’t work for a card which is formatted without a partition table.
The other solution is to ignore the number of blocks reported by the reader, and to probe the size of the card by issuing test reads, probably in large increments at first and then smaller increments, until a read failure occurs. The read failure is assumed to occur because the read occurred past the end of the device. A possible flaw in this scheme is that a card with one or more defective sectors could cause the storage driver to believe it has found the end of the device, when in fact the read error occurs because of a bad sector.
At the moment, the solution for Linux and other operating systems which do not implement such hacks and which trust the card reader to report a useful block count and block size of the inserted card, is to buy a new card reader.