On Tue, Mar 9, 1999, William O Ferry <woferry@iname.com> wrote:

>	That's correct.  Since the CMD PCI0640 controller was "not configured", it 
>was unable to find wd0.  cd0 (and sd0 if you have a Zip drive) are off of 
>Paddington's internal IDE controller, which is detected with some
changes, but
>
>still does not work (it seems that most interrupts are not getting
through the
>
>bridge, it's why bm0 is sending but not receiving, and when I tried booting 
>off a zip I got lost interrupts and lots of timeouts (the drive was never 
>accessed).  It's not everything, as USB seems to work just fine.  But it
seems
>
>that at least interrupts from Paddington aren't making it through the
bridge, 
>at least that's my guess on things.  Would the Paddington IDE drive
detection 
>work without interrupts, or is that proof that it works at least some of the 
>time?).  As far as the CMD controller goes I'm going to give a shot at
porting
>
>pciide to macppc, it seems like it should be fairly easy, when I tried this 
>past weekend it seemed that at least the iot's were getting filled out 
>incorrectly upon entry to the pciide routines.  Will take a closer look at 
>things, probably not until this coming weekend, though (really don't
have time
>
>to code during the week).

The interrupt problem you are having seems to be similar to one I fixed
in linux-pmac: the interrupt controller inside Apple's ASIC seems to be
quite slow and you must make sure that, after a write to it, you do a
read from it to make sure that the access has been fully done and all the
PCI bridges have actually done the write. This is especially true on the
Blue G3 since the path to the controller crosses 2 bridges, both of them
potentially "posting" writes.

Also, the interrupts may not go directly from the Paddington to the CPU,
is there an interrupt controller in the DEC bridge ? Bridge may have been
cascaded... (but I don't think so).


-- 
           E-Mail: <mailto:bh40@calva.net>
BenH.      Web   : <http://calvaweb.calvacom.fr/bh40/>