Problems applying 5.0.x patches

[Doug Ledford]

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  <dledford at dialnet.net>
  Opinions expressed are my own, but
     they should be everybody's.

To Unsubscribe: send mail to majordomo at FreeBSD.org
with "unsubscribe aic7xxx" in the body of the message