Date: Wed, 15 Jul 1998 04:54:10 -0400 From: "Gary Palmer" <gpalmer@FreeBSD.ORG> To: "Kenneth D. Merry" <ken@plutotech.com> Subject: Re: recent cam snapshot Message-ID: <13887.900492850@gjp.erols.com> In-Reply-To: Your message of "Tue, 14 Jul 1998 23:48:18 MDT." <199807150548.XAA01518@panzer.plutotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
"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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?13887.900492850>