> I did some fishing on my fasttrack.
> As near as I can figure out, there are two IDE controllers on one card
> that share a common interrupt. The busmaster IOport is 6900; the master
> drive on channel 1 is at io base 6500 and the slave drive is at io base
> 6602; channel 2 is at 6700 and 6802.
> I looked at ide.c, but I don't know near enough about ide controllers to
> try to make sense out of it. From looking at /proc/ioports, it seems
> that the master/slave io ports are 0x206 apart (e.g. ide 3 is at 0168
> and 036e) v. the fasttrack's 0x102. I don't know how this relates to
> major/minor devices, etc.
Device numbers simply indicate which driver should be used to deal with
i/o to/from a given device file. Not related.
Quote:> If nothing else, this would allow for 4 IDE devices to use a single
> interrupt and probably would provide for faster RAID. Since the
> fastrack's RAID is done in software anyway, I can't see any real
> advantage in waiting for promise to come up with a driver.
I think the Ultra33 also uses only a single IRQ. But then I've never
used both channels at once so I don't know if it spawns a second one.
Quote:> Also, two fasttracks can be used in the same machine. This would allow
> 8 drivers on only 2 interrups; pretty good savings for loaded servers.
> My guess is that only the ioports change when the second card is added.
It's a PCI card, so all its resources are determined through magical
plug-n-play type means...
Quote:> So can anyone give me some guidance for writing a (non-raid) driver for
> the fasttrack?
Look at the existing drivers in the kernel a bit... Then ask someone who
knows what they're doing if it's still confusing. Andre Hedrick is the
de facto IDE guy currently, you should be able to dig up his e-mail
address from a linux-kernel mailing list archive or something.
I recommend working against a current 2.1 kernel rather than a 2.0
kernel - after all, it's the development kernels that should be being
> > Heck, THEY told me to return the controller. I don't understand their
> > attitude; it would help them sell more units. The fasttrak is a pretty slick
> > piece of equipment, and it works really well. For the price, it can't be
> > beat.
> > I can't see that the driver is so difficult to write that they couldn't hire a
> > CS major for a summer and have them write an unsupported version.....
Quite mystifying... the only possible explanation is if they think that
it will cost them more to hire someone than they will make on sales to
Linux users (in which case it would be nice if they would _say_ "we
don't think there's enough demand to justify it"). Of course they could
just release some info and it would get done for free, but that doesn't
appeal either. Ah well.