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 ; 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: rev 0x04 int a irq 16 on pci0.18.0 ahc0: aic7895 Wide Channel A, SCSI Id=7, 16/255 SCBs ahc1: 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: 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: 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" 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 To: "Daniel C. Sobral" 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: