> 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
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:
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().
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
Please read the FAQ at http://www.tux.org/lkml/