Date: Tue, 20 Jan 1998 05:33:18 -0600 (CST) From: Doug Ledford <dledford@dialnet.net> To: Luis.G.Silva@inesc.pt Cc: aic7xxx@FreeBSD.ORG Subject: RE: AIC-7895 Message-ID: <XFMail.980120054315.dledford@dialnet.net> In-Reply-To: <199801192350.XAA24624@krylov.inesc.pt>
next in thread | previous in thread | raw e-mail | index | archive | help
On 19-Jan-98 Luis.G.Silva@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@dialnet.net> Date: 20-Jan-98 Time: 05:33:19 ----------------------------------
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.980120054315.dledford>