Messages in this thread | | | Date | Mon, 26 Oct 1998 20:45:15 +0200 (IST) | From | Gadi Oxman <> | Subject | Re: IDE tape and SMP |
| |
On Mon, 26 Oct 1998, Andre M. Hedrick wrote:
> Find an poke this in as an initial test........... > > I find that this works on 2/4 chipsets that I have to test with under SMP. > PDC20246 appears to stablize but no DMA transefers are allowed. > HPT343 (unreleased chipset specific) appears to stablize with Fast-ATA > enabled, but no DMA transefers are allowed. > > Both Intel and AEC6210 still have troubles, IMHO. > > I just grabbed a Colorado 8GB Drive over the weekend for home use. > Something to backup and test with, also......... > > Note that using the native software under MSDos 6.22, it flys at about > 34MB/minute uncompressed on the Intel-chipset. > > static void idetape_setup (ide_drive_t *drive, idetape_tape_t *tape, int minor) > { > > drive->ready_stat = 0; /* An ATAPI device ignores DRDY */ > - drive->dsc_overlap = 1; > + drive->dsc_overlap = (drive->id->capability & 0x20) ? 1 : 0; > + > +#if IDETAPE_DEBUG_LOG > + printk (KERN_INFO "ATAPI overlap : %sabled.\n", > + drive->dsc_overlap ? "en" : "dis"); > +#endif /* IDETAPE_DEBUG_LOG */
DSC overlap and ATAPI overlap are two different protocols.
The above bit is set when the tape drive supports ATAPI overlap, which is defined as optional in QIC-157 and not currently supported by the Linux IDE driver. However, DSC overlap is defined as mandatory in QIC-157 regardless of the above bit.
DSC overlap greatly improves performance, as it is used by Linux to allow access to the tape drive and the other IDE device on the same channel simultaneously.
Automatic disabling of DSC overlap is not a correct solution for the ide-tape and SMP problems, as DSC overlap in theory is not related at all to SMP, works correctly without SMP, and has worked all the time on 2.0.x (both UP and SMP) on all the drives which currently show problems under 2.1.x SMP.
One point in which the ide-tape driver is not SMP safe, for example, is in code sequences such as:
save_flags(flags); cli(); idetape_wait_for_request(); restore_flags(flags);
However, when local interrupts are already disabled prior to cli(), __global_cli() doesn't seem to get the kernel lock under i386 SMP, and nothing seems to prevent the other processor from getting an interrupt and servicing the request which we intended to wait on before we even installed a semaphore in it and used down().
Gadi
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |