Unlike Sparkfun, who actually manage to find fake Atmel ICs, we just get strange batches.
The Atmel ATMega328 is the power behind the Arduino/Freeduino/*duino, and we have to set up a programming system to burn the venerable Arduino Bootloader into these chips.
We normally use an AVR STK500 in HVSP (high voltage serial programming) mode, as that lets us be absolutely sure the fuses are set correctly and the burn is correct. Interestingly enough, this last batch of chips refused to work with our batch files. Asking the chip's ID often returned 0x01 0x03 0X05 instead of the expected signature.
After spending a day checking to see if the programmer was broken (nope) or if the chips were fake (nope, we think), we did find that they did respond to regular old ICSP (in-circuit serial programming), but only partially.
Digging around, we found some older ATMega328 chips that worked fine, and compared them to this new batch. This troublesome batch has a date code of 1015 (15th week of 2010), and a batch code on the bottom as 9J4302 / 35473d / 1-P1015 e3.
So we re-wrote our batch file burning code to use AVRDude instead of the STK500 command-programmer, and to run it in ICSP mode on the STK500. The key addition is the "-B" part, which slows down the communication a bit. You want it as low as possible for fastest burn times. I tried a "-B 2" on both fuse & programming lines, but that really slowed the process. What's below is what we settled on.
: Set fuse bits, lock bits, voltages
.avrdude -c stk500v2 -i 20 -p m328p -P COM1 -b 115200 -B 1.8 -e -u -U lock:w:0x3f:m -U efuse:w:0x05:m -U hfuse:w:0xDA:m -U lfuse:w:0xFF:m
: Burn & Lock Arduino hex bootloader file
.avrdude -c stk500v2 -p m328p -P COM1 -b 115200 -B 1.1 -U flash:w:%HEXFILE% -U lock:w:0x0f:m
Hope that'll save anybody else from blowing better part of a day figuring out why their Atmel isn't programming normally!