Messages in this thread Patch in this message |  | | From | Zoltan Hidvegi <> | Subject | cmd640 speed | Date | Sun, 1 Sep 1996 19:12:34 +0200 (MET DST) |
| |
I finally had some time to figure out why recent kernels are slower with cmd640 than 2.0.10. The reason was an obvious bug in program_drive_counts() which is fixed by the patch included below. If you have a very fast PIO mode4 drive it may speed up transfer rates by about 15%. Fast devsel may have to be enabled for that using hdparm -p7.
The patch also adds a CMD640_PREFETCH_MASKS macro which can be changed to zero to allow interrupt unmasking when cmd640 prefetch is enabled. Defining this to zero only has effect if you also use hdparm -u1. This is dangerous but it san be used with some motherboards. On bad motherboards it may cause data corruption when the floppy and the hard drive used simultaneously.
Zoltan
--- linux/drivers/block/cmd640.c.ml Thu Aug 22 05:37:08 1996 +++ linux/drivers/block/cmd640.c Sun Sep 1 18:44:05 1996 @@ -97,6 +97,7 @@ */ #undef REALLY_SLOW_IO /* most systems can safely undef this */ +#define CMD640_PREFETCH_MASKS 1 #include <linux/config.h> #include <linux/types.h> @@ -408,9 +409,11 @@ drive->no_io_32bit = 1; drive->io_32bit = 0; } else { +#if CMD640_PREFETCH_MASKS drive->no_unmask = 1; - drive->no_io_32bit = 0; drive->unmask = 0; +#endif + drive->no_io_32bit = 0; } } @@ -454,8 +457,10 @@ cli(); b = get_cmd640_reg(reg); if (mode) { /* want prefetch on? */ +#if CMD640_PREFETCH_MASKS drive->no_unmask = 1; drive->unmask = 0; +#endif drive->no_io_32bit = 0; b &= ~prefetch_masks[index]; /* enable prefetch */ } else { @@ -556,9 +561,10 @@ * Convert setup_count to internal chipset representation */ switch (setup_count) { - case 4: setup_count = 0x00; - case 3: setup_count = 0x80; - case 2: setup_count = 0x40; + case 4: setup_count = 0x00; break; + case 3: setup_count = 0x80; break; + case 1: + case 2: setup_count = 0x40; break; default: setup_count = 0xc0; /* case 5 */ }
|  |