From owner-aic7xxx Thu Mar 19 21:58:22 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA29963 for aic7xxx-outgoing; Thu, 19 Mar 1998 21:58:22 -0800 (PST) (envelope-from owner-aic7xxx@FreeBSD.ORG) Received: from dledford.dialnet.net (root@dledford.dialnet.net [206.65.249.116]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA29909 for ; Thu, 19 Mar 1998 21:58:04 -0800 (PST) (envelope-from dledford@dialnet.net) Received: from dialnet.net (localhost [127.0.0.1]) by dledford.dialnet.net (8.8.5/8.8.4) with ESMTP id XAA30768; Thu, 19 Mar 1998 23:57:45 -0600 Message-ID: <35120559.B332D44B@dialnet.net> Date: Thu, 19 Mar 1998 23:57:45 -0600 From: Doug Ledford X-Mailer: Mozilla 4.04 [en] (X11; I; Linux 2.0.33 i686) MIME-Version: 1.0 To: Steve Brueggeman CC: aic7xxx@FreeBSD.ORG Subject: Re: Problems applying 5.0.x patches References: <3511f09f.59947@smtp.primenet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aic7xxx@FreeBSD.ORG Precedence: bulk Steve Brueggeman wrote: > Apparently, between the driver included in the linux-2.0.33.tar.gz kernel, and > aic7xxx-5.0.8, the order of PCI scan was reversed. The order wasn't reversed, it was corrected. The old driver used to always find cards according to thier vendor ID and leave them in the order it found them. That meant that if your boot card was a 3940UW for instance, but you happened to have a 2940AU card in the system for tape backups, then the 2940AU would always be controller 0. Most BIOSes scan from the lowest PCI bus/function number to the highest, branching off to secondary busses whenever it encounters a bridge chip. The new driver does this same thing, except we don't branch at bridge chips. For most BIOSes, the default order is the correct order. Now, as a side note, I didn't take the time to update the /usr/src/linux/drivers/scsi/README.aic7xxx file for nothing. The answer to your question about the BIOS sorting order is in there. Read it. > This is a real delema, > because (if I understand things correctly), lilo uses the BIOS scan order to > determine which device to get the kernel from (/dev/sda), but then when it comes > time to continue on, what was /dev/sda as far as lilo was concerned is not > /dev/sda after the kernel scans the devices. I found this by removing all > devices from my 2nd controller, and found I was able to boot OK. This merely means that your BIOS uses a descending SCAN of the PCI bus instead the normal ascending scan. > A couple of questions. > (1) Is the problem of HAVING to have the BIOS settings match the actual device > capabilities, going to be fixed. The sequencer should be able to let the kernel > know what the device ended up agreeing to for the width and sync negotiations. > This is basic SCSI stuff. What changed between the old drivers and the new, to > break this? Good question. Send me your broken tape drive and I'll get it fixed. Unfortunately, my tape drive doesn't cause this, so I don't know what code path is being followed to generate this error. The last time there was anything like this that was fixed, it was when we had too large of a message in the MESG_OUT phase for the device to handle. That was fixed when we set the driver to never try and negotiate while using a tagged command. > (2) I've seen threads about the PCI scan order problem enough, to suspect there > is still no good solution to this problem. So... could somebody out there be > kind enough to let me know how, or where to find info on, how to force a PCI > scan order, so the kernel finds my Adaptec PCI cards in the same order that the > BIOS finds them in? Try that README.aic7xxx file I mentioned. -- Doug Ledford Opinions expressed are my own, but they should be everybody's. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe aic7xxx" in the body of the message