From adrian@thneed.ubergeeks.com  Sat Feb  6 08:07:00 1999
Received: from thneed.ubergeeks.com (thneed.ubergeeks.com [206.205.41.245])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA22723
          for <FreeBSD-gnats-submit@freebsd.org>; Sat, 6 Feb 1999 08:06:56 -0800 (PST)
          (envelope-from adrian@thneed.ubergeeks.com)
Received: (from adrian@localhost)
	by thneed.ubergeeks.com (8.9.2/8.9.1) id LAA00642;
	Sat, 6 Feb 1999 11:09:19 -0500 (EST)
	(envelope-from adrian)
Message-Id: <199902061609.LAA00642@thneed.ubergeeks.com>
Date: Sat, 6 Feb 1999 11:09:19 -0500 (EST)
From: adrian@ubergeeks.com
Reply-To: adrian@ubergeeks.com
To: FreeBSD-gnats-submit@freebsd.org
Subject: miltichannel scsi 3940 channel swapping problem
X-Send-Pr-Version: 3.2

>Number:         9927
>Category:       kern
>Synopsis:       [ahc] the ahc driver doesn't correctly grok switched SCSI channels (workaround)
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    gibbs
>State:          suspended
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sat Feb  6 08:10:00 PST 1999
>Closed-Date:    
>Last-Modified:  Tue Nov 29 05:56:13 GMT 2005
>Originator:     Adrian Filipi-Martin
>Release:        FreeBSD 3.0-STABLE i386
>Organization:
Ubergeeks Consulting
>Environment:

	The system has a dual UW AHA-3940 SCSI controller on the
	MB, a Tyan S1836DULAN.  Since I want to segregate the UW
	devices from the non-UW devices, they all get attached to
	channel B.  Channel B is the one with my boot disk.  Channel
	A and B have been swapped in the BIOS, so that it does not
	try to boot from the non-UW disk on channel A.

	Below are the relavent lines from the kernel probing.  Note
	that ahc0 is channel A, and ahc1 is channel B.

ahc0: <Adaptec aic7895 Ultra SCSI adapter> rev 0x04 int a irq 16 on pci0.18.0
ahc0: aic7895 Wide Channel A, SCSI Id=7, 16/255 SCBs
ahc1: <Adaptec aic7895 Ultra SCSI adapter> rev 0x04 int b irq 16 on pci0.18.1
ahc1: aic7895 Wide Channel B, SCSI Id=7, 16/255 SCBs
da1 at ahc1 bus 0 target 6 lun 0
da1: <IBM DGVS09U 03B0> Fixed Direct Access SCSI-3 device 
da1: 40.0MB/s transfers (20.0MHz, offset 8, 16bit), Tagged Queueing Enabled
da1: 8705MB (17829870 512 byte sectors: 255H 63S/T 1109C)
da0 at ahc0 bus 0 target 6 lun 0
da0: <SEAGATE ST15230W SUN4.2G 0738> Fixed Direct Access SCSI-2 device 
da0: 20.0MB/s transfers (10.0MHz, offset 8, 16bit), Tagged Queueing Enabled
da0: 4095MB (8386733 512 byte sectors: 255H 63S/T 522C)

>Description:

	The ahc driver assigns the unit numbers in the same order whether
	or not the primary chanel has been changed in the BIOS.

	As a result the boot disk shows up as da1.  This is sort of ok
	except that the BIOS reports this device as drive 0, and not drive 1.
	This confuses the hell out of the new bootblocks.  To boot I
	must have "0:da(1,a)kernel" in /boot.config.  The new loader doesn't
	like the fact that da1 == BIOS 0 either.

>How-To-Repeat:

	Swap your primary and secondary channel on a similar card
	and boot.  ahc0 will _always_ be assigned to channel A,
	regardless of the BIOS primary channel setting.

>Fix:

	I do not have a fix, but I did try to see if it was easy
	to fix.  There is code in the ahc driver that will change
	the order of unit number assignemts when the primary chanel
	is swapped.  The problem is that is does not seem to work
	for this particular controller.  I tried making a few
	changes by looking at what other flags changed when the
	BIOS setting was changed, but it doesn't appear to be a
	simple fix.

>Release-Note:
>Audit-Trail:

From: "Daniel C. Sobral" <dcs@newsguy.com>
To: adrian@ubergeeks.com
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: kern/9927: miltichannel scsi 3940 channel swapping problem
Date: Sun, 07 Feb 1999 01:51:02 +0900

 >         As a result the boot disk shows up as da1.  This is sort of ok
 >         except that the BIOS reports this device as drive 0, and not drive 1.
 >         This confuses the hell out of the new bootblocks.  To boot I
 >         must have "0:da(1,a)kernel" in /boot.config.  The new loader doesn't
 >         like the fact that da1 == BIOS 0 either.
 
 set root_disk_unit=1 does not help?
 
 --
 Daniel C. Sobral			(8-DCS)
 dcs@newsguy.com
 dcs@freebsd.org
 
 	Well, as a computer geek, I have to believe in the binary universe.
 
 

From: Adrian Filipi-Martin <adrian@ubergeeks.com>
To: "Daniel C. Sobral" <dcs@newsguy.com>
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: kern/9927: miltichannel scsi 3940 channel swapping problem
Date: Sat, 6 Feb 1999 21:28:12 -0500 (EST)

 On Sun, 7 Feb 1999, Daniel C. Sobral wrote:
 
 > >         As a result the boot disk shows up as da1.  This is sort of ok
 > >         except that the BIOS reports this device as drive 0, and not drive 1.
 > >         This confuses the hell out of the new bootblocks.  To boot I
 > >         must have "0:da(1,a)kernel" in /boot.config.  The new loader doesn't
 > >         like the fact that da1 == BIOS 0 either.
 > 
 > set root_disk_unit=1 does not help?
 
 	Well, no it didn't the last time I tried.  But this was actually
 before the new bootblocks became the default, so I decided to try the
 loader again.  I suppose I really am using the new boot blocks, and that
 the loader is the first boot stage that doesn't grok my hardware
 configuration.   I discussed the loader problem with Robert Nordier a few
 weeks ago, but I now see real that the problem is with ahc and not the
 loader.
 
 	For the sake of completeness, here's what I see on my box,
 including trying your suggestion.
 
 scenario 1:
 With no /boot.config:
 
 	pressed space to get "boot: " prompt.
 	defaults to 0:da(0,a)/boot/loader
 	pressed enter to load loader
 	announces that btx loader is using the following bios mapping:
 		a: -> disk0
 		c: -> disk1
 		d: -> disk2
 	pressed enter to load kernel
 	loads kernel, but panics when mounting root from wrong disk.	
 
 secenario 2:
 With no /boot.config:
 
 	pressed space to get "boot: " prompt.
 	defaults to 0:da(0,a)/boot/loader
 	pressed enter to load loader
 	announces that btx loader is using the following bios mapping:
 		a: -> disk0
 		c: -> disk1
 		d: -> disk2
 	pressed space to get loader prompt.
 	show currdev == loaddev == disk1s2a
 	set root_disk_unit=1
 	boot -s
 	loads kernel, but panics when mounting root from wrong disk.	
 
 secenario 3:
 With no /boot.config:
 
 	pressed space to get "boot: " prompt.
 	entered 0:da(1,a)/boot/loader
 	pressed enter to load loader
 	announces that btx loader is using the following bios mapping:
 		a: -> disk0
 		c: -> disk1
 		d: -> disk2
 	pressed space to get loader prompt.
 	show currdev == loaddev == disk2s2a
 	cannot do 'ls' or load kernel.
 	set root_disk_unit=1
 	cannot do 'ls' or load kernel.
 	unset root_disk_unit
 	set currdev=disk1s2a
 	ls works now, but still cannot load kernel
 	set root_disk_unit=1
 	ls still works, and cannot load kernel
  
 
 	As I mentioned above, I believe the problem is that the ahc driver
 isn't correctly handling the switched SCSI channels.  The code in
 /sys/dev/aic7xxx/aic7xxx.c is not doing the right thing.  It does try.  See
 aic7xxx.c near line 987:
 
     /*
      * Attach secondary channel first if the user has
      * declared it the primary channel.
      */
     if ((ahc->flags & AHC_CHANNEL_B_PRIMARY) != 0) {
         bus_id = 1;
         bus_id2 = 0; 
     } else {
         bus_id = 0;
         bus_id2 = 1; 
     }
 
 	The "ahc->flags & AHC_CHANNEL_B_PRIMARY" test is never true.  I
 tried examining some of the other flags for the correct bit, but when I did
 fine one that changed when I switch the primnary channel, it caused other
 problems, so I don't think I had it correct.
 
 thanks,
 
 	Adrian
 --
 [ adrian@ubergeeks.com -- Ubergeeks Consulting -- http://www.ubergeeks.com/ ]
 
 
State-Changed-From-To: open->suspended 
State-Changed-By: gibbs 
State-Changed-When: Mon Feb 8 07:23:01 PST 1999 
State-Changed-Why:  
The 3940 series of controllers look to the system as two independent 
SCSI controllers.  For this reason it is difficult to modify the attach 
order to match the BIOS channel configuration setting.  A correct solution 
involves allowing CAM drivers to prioritize their channels during the 
probe sequence so that they can be sorted prior to attach.  This is not 
as trivial a problem to solve as it may seem since you probably want to 
do things like detect if a particular channel has the boot drive and 
bump its priority.  I plan to look into this at some point, but not in 
the immediate future. 

In the mean time, man scsi(4) and read the section on hardwiring devices. 
You can force the channels to attach in any order with this mechanism. 


Responsible-Changed-From-To: freebsd-bugs->gibbs 
Responsible-Changed-By: gibbs 
Responsible-Changed-When: Mon Feb 8 07:23:01 PST 1999 
Responsible-Changed-Why:  
CAM and ahc maintainer. 
>Unformatted:
