On Fri, Mar 10, 2000 at 02:40:46PM +0000, Roger Brooks wrote:
> I put a UDMA mode 2 slave and a UDMA mode 4 master on the same channel.
> Monitoring with iostat showed some interesting behaviour.  Reading a
> raw partition from the mode 2 drive gave a data rate of ~9 MB/s, while
> the mode 4 drive gave ~25 MB/s.  It so happened that the partition which
> I chose on the mode 2 drive was much smaller than the other one and so
> finished first.  What I observed was
> 
>     Start reading from mode 4 drive - iostat shows 25 MB/s
>     Start reading from mode 2 drive - mode 4 drive slows down, so both
>     are at 9 MB/sec
>     Finish reading from mode 2 drive - mode 4 drive goes back to 25 MB/sec.

This is because IDE doesn't send overlapped commands like scsi does
(this is a driver's limitation, I'll work on this some day).
Your first drive slows down not because the whole bus runs at UDMA2 now
but because the bus is grabbed by the second drive when there's a command
ready for the first one.

> 
> I also added the chip tuning tables for 25 MHz and 40 MHz PCI bus speeds
> from the Linux driver.  I'm not completely convinced that this stuff is
> actually needed, as up to now the timing register always seems to contain
> the right value already.  The info Highpoint WWW site does say it's

The BIOS set it up. But what happens if you put such a board in a powermac
or an alpha, or sparc ? We can't assume the default values are rigth.

> self-tuning.  Feedback from anyone with the unlikely combination of a
> machine with a 25 MHz PCI bus (an old 486 system?) and an Abit Hot-Rod
> PCI card would be interesting.

> 
> >Hum. I think this is really needed !
> >Look at pdc202xx_pci_intr() for example (although as you've a single-channel
> >attachemement the above code should be enouth).
> >I suspect that under some conditions a hard hang can occur if we read the
> >status register before IRQ occured (this may be related to some controllers
> >doing funny things with registers). We can also lose interrupt because of
> >this. This can only happen with interrupt sharing, so it's not needed for
> >controllers in legaty mode.
> 
> But doesn't/shouldn't wdcintr check that a transfer has been started on
> the channel before trying to read the status register?  But this doesn't

It does. reading the status register if no transfer is active is harmless
anyway.

> help does it?  If both channels share an IRQ, and both have a transfer
> in progress, then the handler gets called once for each channel, and has
> to read the status register to see if that channel caused the interrupt.

This is what the above code avoids ! "if the controller didn't see an
interrupt for this channel don't call wdcintr()". So we are sure to
call wdcintr for a  channel which interrupted.
Also note that this code seems to acknoledge the interrupt to the
controller.

> But if reading the status register for a channel which hasn't completed
> causes a hangup, then how on earth can you possibly manage to do
> concurrent transfers on both channels?

Because the controller told us if there has been an interrupt for a
given channel via its own registers.

> 
> There's also a kernel configuration option in the Linux driver for
> "fast interrupt prediction".  Does anyone know what this is?  I've
> added code to allow it to be turned off/on from the flags on the
> pciide config file entry, but haven't yet tried turning it on to
> see if it helps.

No, this should be described in the docs.

> 
> >Also, as a general note I prefer to #define registers names and contents
> >in pciide_xxx_reg.h and use symbolic names in the driver :)
> 
> I quite agree!  I was rather disappointed (the polite way of putting it :-))
> when I started looking at the code for the Linux driver.  Hex constants
> scattered all over the place...  and a twisty maze of little functions,
> all with very similar names.

Welcome to the linux world :0

--
Manuel Bouyer, LIP6, Universite Paris VI.           Manuel.Bouyer@lip6.fr
     {Net,Free}BSD: 22 ans d'experience feront toujours la difference
--