From owner-freebsd-questions Sun Jul 12 20:54:51 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA03120 for freebsd-questions-outgoing; Sun, 12 Jul 1998 20:54:51 -0700 (PDT) (envelope-from owner-freebsd-questions@FreeBSD.ORG) Received: from pau-amma.whistle.com (s205m64.whistle.com [207.76.205.64]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA03115 for ; Sun, 12 Jul 1998 20:54:50 -0700 (PDT) (envelope-from dhw@whistle.com) Received: (from dhw@localhost) by pau-amma.whistle.com (8.8.8/8.8.7) id UAA06193 for questions@freebsd.org; Sun, 12 Jul 1998 20:54:12 -0700 (PDT) (envelope-from dhw) Date: Sun, 12 Jul 1998 20:54:12 -0700 (PDT) From: David Wolfskill Message-Id: <199807130354.UAA06193@pau-amma.whistle.com> To: questions@FreeBSD.ORG Subject: Re: SCSI "device wiring" query In-Reply-To: Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >Date: Sat, 11 Jul 1998 21:59:19 -0700 (PDT) >From: Doug White >On Thu, 9 Jul 1998, David Wolfskill wrote: >> OK; I think I understand how to "wire" the devices on a given SCSI bus >> in the kernel config (running 2.2.6-RELEASE here, for this purpose). >> However, how is it determined which SCSI host adapter is (say) ahc0 vs. >> ahc1? Does it have something to do with the physical slot in which the >> host adapter is placed on the system board? >You attach adapters to scbusses, then asociate devices with target IDs on >those busses. See LINT for details. Well, LINT doesn't discuss the issue I was trying to address; that's probably a failure in how I tried to express myself -- at least, I don't see anything in LINT that tells how to determine which physical card will have a given logical name. If I properly understood (and am relating) the conversation I had with Julian, it seems that there really isn't a simple way to determine this ahead of time; there are apparently too many variables. I ended up configuring & building a new kernel (with hard-wired devices assuming that the controllers were going to be swapped and that I'd be moving all of the narrow devices to one controller, while leaving only wide devices on the other). I then physically swapped the locations of the SCSI host adapters, and on boot, the adapters were recognized with the names I had hoped. In this case, I have a couple of ahc devices: a 2940, and a 2940UW. The 2940 is strictly a narrow adapter, and all of the devices connected to it were external to the machine; each is also narrow. The 2940UW had a couple of narrow internal devices connected to it, as well as a couple of wide internal devices. One of the narrow internal devices happens to be the boot disk (a Quantum Empire 1080S). Unfortunately, I found that merely ensuring that a given disk is SCSI target 0 on the first-detected SCSI host adapter (ahc0, in this case) apparently has *no* bearing on what device the machine will use to try to boot: despite the hardware-hackery I did (above), the machine insisted on trying to boot from a drive on ahc1. (I had also changed the termination settings for the controllers: for the 2940, from "enabled" to "disabled"; fo rthe 2940UW, from "high on/low off" to "automatic".) This was not useful. After several attempts to try to find some clue as to what might be thus perverting the boot order, I eventually saw that the 2940's "BIOS" was "disabled" (whatever that means), while the 2940UW's "BIOS" was "enabled". In desperation, I tried switching the two -- enabling the 2940, and disabling the 2940UW. (Naturally, every time one looks at a different adapter's settings or changes them, a re-boot is forced.) This caused the machine to issue a dire-sounding warning about some geometry being different from that which was expected, and that data corruption might occur. Of course, at this point, I had no way of knowing anything better to do, so I told it to go ahead... and things *seem* to be OK.... Now, of course, if this server goes down, someone with access to the server room will need to come on-site, ensure there's a keyboard & monitor hooked up, and manually tell it that re-booting really is OK. :-( I'm trying again to get a full set of backups (previously, the machine would fall over before the backups were completed, the failure apparently involving the SCSI errors & timeouts)... and so far, there's been absolutely no whining at all about any SCSI problems... so other than the forced manual intervention to complete a boot sequence, this seems to have been OK ... so far: the backups aren't done yet.... david -- David Wolfskill UNIX System Administrator dhw@whistle.com voice: (650) 577-7158 pager: (650) 371-4621 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message