From owner-freebsd-scsi Wed Jul 15 01:54:21 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA16350 for freebsd-scsi-outgoing; Wed, 15 Jul 1998 01:54:21 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from gjp.erols.com (root@alex-va-n008c079.moon.jic.com [206.156.18.89]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA16343 for ; Wed, 15 Jul 1998 01:54:20 -0700 (PDT) (envelope-from gjp@gjp.erols.com) Received: from gjp.erols.com (gjp@localhost.erols.com [127.0.0.1]) by gjp.erols.com (8.8.8/8.8.7) with ESMTP id EAA13891; Wed, 15 Jul 1998 04:54:11 -0400 (EDT) (envelope-from gjp@gjp.erols.com) X-Mailer: exmh version 2.0.1 12/23/97 To: "Kenneth D. Merry" cc: From: "Gary Palmer" Subject: Re: recent cam snapshot In-reply-to: Your message of "Tue, 14 Jul 1998 23:48:18 MDT." <199807150548.XAA01518@panzer.plutotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 15 Jul 1998 04:54:10 -0400 Message-ID: <13887.900492850@gjp.erols.com> Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org "Kenneth D. Merry" wrote in message ID <199807150548.XAA01518@panzer.plutotech.com>: > Generally, it should work. Make sure your copy of libcam is up to > date, and make sure that your camcontrol binary was linked against it. Also > make sure your kernel is up to date. There has never been CAM on this machine before. I upgraded by doing a CVS `co' of the appropriate -current source (with a -D flag that I hope would specify the matching source tree to the patches), and then following the instructions in the README file. The only problem I had was when I rebooted and I realised I had forgotten a patch to i386/i386/mp_machdep.c that correctly wires the IRQ's for my PCI bridged 3940 card (which the bios doesn't do correclty in the MP table) Since camcontrol is not dynamic, I am not sure how to check, but it seems unlikely that it would have picked up the wrong libcam where there is only one version on my system :) > I'm not sure why you'd be having trouble with this, unless > something is out of date or the snapshot is somehow messed up. I know that > the first sets of diffs Justin put up for both -current and -stable last > night didn't apply cleanly, but surely you would have noticed a problem > when you applied the patch. The NCR driver had two rejects (which I didn't care about since I don't use NCR/Symbios cards), and it complained that it couldn't patch /sys/i386/conf/ASLAN. I have the full patch output if you are interested (tee is your friend :) ) > Try specifying the device you want, like this: > > camcontrol -t -n cd -u 0 root@gjp:~> camcontrol -t -n cd -u 0 camcontrol: cam_real_open_device: CAMGETPASSTHRU ioctl failed cam_real_open_device: No such file or directory > camcontrol -i -n da -u 2 root@gjp:~> camcontrol -i -n da -u 2 camcontrol: cam_real_open_device: CAMGETPASSTHRU ioctl failed cam_real_open_device: No such file or directory > New support for DEVFS? No. The reason scsi devices appear at the > end of the kernel boot messages, and often out of order, is that they are > probed once interrupts are enabled. Devices are probed in ascending order > by bus, target, and lun, but they appear in the order that they respond to > the probe commands. Ah, sorry, I thought I saw something from Justin in passing on one of the lists saying he was trying to support devfs's insert/remove sequence. Maybe I mis-remembered him mentioning it in relation to this snapshot. > > What is the default number of tags per device? It logs the fact > > that they've changed, but doesn't indicate if its a change down > > or up, and what the previous value was... > > The default number of tags is 64. I'm surprised you only see > "tagged openings now 8" for your Fireball ST. I would think that you > would see more log messages than that. There are some drives for which the > default number of tags is lower, mainly the Quantum Atlas II's. Look at > the xpt_quirk_table in src/sys/cam/cam_xpt.c Since this is my home `workstation'/gateway/server I don't beat on it much :) I've noticed a message about all of the drives except the Fujitsu. Since I only use that to hold my CVS tree, I doubt I'll see a message until the next time I do a cvsup or a full tree update. Hrm. Or maybe not. I'm doing a cvsup and a find /home/ncvs across it and it seems to not be complaining. Weird. Maybe Fujitsu has 64 or more tags? Thanks Ken, Gary -- Gary Palmer FreeBSD Core Team Member FreeBSD: Turning PC's into workstations. See http://www.FreeBSD.ORG/ for info To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message