Last night I got the driver working with both channels of the HPT366.
After Manuel's comments, I started lookign very closely at the interrupt
handler, and realised that I'd bogged the code to check if the interrupt
belongs to that channel (I was reading a register at the right offset,
but in configuration space, not I/O space :%).

I'll do a bit more testing, and should be able to post a new version of the
patch in a day or so.  However, I'd like advice on another point.  Manuel's
comments about using the Abit Hot-Rod (the PCI card version of the HPT366)
in a non-i386 machine set me thinking.  In the i386, the Highpoint BIOS
sets up a 32 bit "tuning register" with a magic number which depends on
disk I/O mode and PCI bus speed.  As I don't have the HPT366 docs, I don't
know if they describe how to generate this magic number.  However, the driver
prints out the value at boot time, so you could obtain the magic numbers
for a particular PCI bus speed by starting with a UDMA mode 4 drive and
reducing the I/O mode through all the UDMA, DMA and PIO modes in the
Highpoint BIOS, with each reboot giving you the next magic number.

The Linux driver which I have been working from has three such tables,
for 25, 33 and 40MHz bus clock.  The FreeBSD driver has something similar.
Although I've reproduced the code, I think it's a bit questionable because
in order to determine the bus clock, it looks at the magic number already
written to the register by the BIOS.  The only point of this code is that
if you have used a flags value on the "wdN" config file line, it will
retune the chip to your preferred I/O mode.

Now for the problem.  If you don't have the BIOS to set the chip up, how can
the driver find the bus clock speed?  I can't find anything in the PCI code
which seems to do this.  How many machines have PCI bus clocks which aren't
33 MHz?  How many of those are something other than 25 or 40 MHz?  I suppose
I could get the bus clock from a config file option, but that seems a bit
tacky, so say the least.

My current thought is to assume the existence of a function which returns
the speed of the PCI bus clock.  If this returns non-zero, I use it, otherwise
I'll read the value which the BIOS should have already put into the HPT366
bus timing register.  I'll provide a dummy bus clock function which will
return zero (presumably this should go in the MD pci code?).  Anyone who
wants to get the thing working on a non-i386 architecture will need to
provide a function which delivers the correct value.



Roger

------------------------------------------------------------------------------
Roger Brooks (Systems Programmer),          |  Email: R.S.Brooks@liv.ac.uk
Computing Services Dept,                    |  Tel:   +44 151 794 4441
The University of Liverpool,                |  Fax:   +44 151 794 4442
PO Box 147, Liverpool L69 3BX, UK           | 
------------------------------------------------------------------------------