AIC-7895

[Doug Ledford]

On 19-Jan-98 Luis.G.Silva at inesc.pt wrote:
>
>Hi !
>
>First, *THANK YOU*, for this new AIC7xxx driver release.
>
>Finally, I will be able to use my AIC-7895 SCSI adapter (on a Tyan Thunder
>2).
>
>I applied your patches to the Linux kernel (version 2.0.33) and installed a
>new kernel (under RH5.0). During the boot it recognizes the adapter and
>detects all the SCSI devices in Channel A, but it hangs when scanning
>for devices on Channel B. I have no devices attached to channel B, is this
>a problem ? Is it possible to make it ignore Channel B ?
>
>Thanks in advance,
>-Luis

No, it's not possible to make it ignore the B channel :)  If there is a
problem with the detection on your B channel, then it's something I need to
get fixed anyway.  In my case, I have no devices on channel A, and all of my
devices on channel B and it scans both of them just fine.  So, what I need
you to do is to boot the kernel with the line aic7xxx=verbose:0xffff and get
me any debugging output you can from when this hangs.  Esentially, when the
drive gets around to scanning channel B, it should print out a message like
(scsi1:0:-1:-1) Scanning channel B for devices.
(scsi1:-1:-1:-1) Allocating initial 30 SCB structures.

I need to know what, if anything, gets printed after that.  I also need to
know if the machine goes into a reset loop, or if the machine simply dies at
this point and nothing further happens.  If it's a reset loop, then very
likely there is something going on either with termination settings, or
there is something wrong and the interrupt routine is not getting run
properly.  I had this exact problem with the 2842 controllers (which is what
took *soooo* long to get this patch out).  In short, the new method of
sending extended messages to drives (the reqinit handler) was causing me
lots of grief on the slower processor because we would make our message for
the drive, then enable reqinit processing, and before we could get out of
the interrupt handler we would already have a reqinit interrupt active. 
This caused the driver to essentially "miss" an interrupt and fail to
complete the reqinit handling.  However, I hadn't had any problem with this,
regardless of card type, on typical PCI machines, and the code added to fix
the 486 class computers is active on all machines, so this shouldn't be the
problem either (and indeed, it can't be your problem if you don't have any
devices attached to that SCSI channel).  So, it's something I have to look
into and get figured out.

----------------------------------
E-Mail: Doug Ledford <dledford at dialnet.net>
Date: 20-Jan-98
Time: 05:33:19
----------------------------------