The other part of the story is a nasty bug in ide-disk.c driver:
write_cache() is called with (drive->id->cfs_enable_2 & 0x300) as argument
'arg' of type 'int' and then this value is assigned to the 'drive->wcache'
of type 'unsigned char' so drive->wcache == 0 because 0x3000 gets truncated.
This bug has been present since introduction of drive->wcache (2.5.3),
therefore we have never handled cache flush correctly before and never
hit '& 0x2400' problem before.
Linus & Alan, you were almost right after all, drive->wcache was almost
always zero for normal disks before 2.6.6. It could be forced by user but
only for disks having ATA-6 cache flush bits and was auto-set but only for
removable disks (after Alan's fixes in 2.6.65). You lucky b*st*rds. ;-)
Rene, that's why wcache is 0 in /proc/ide/hdX/settings for older kernels
or with my 'bandaid' fixes for 2.6.6. 'hdparm -W1' should work but only on
quite recent drives (having ATA-6 bits). However I don't know why you get
regression in tiobench, we still need to explain this.