Date: Tue, 14 Jul 1998 23:48:18 -0600 (MDT) From: "Kenneth D. Merry" <ken@plutotech.com> To: (Gary Palmer) Subject: Re: recent cam snapshot Message-ID: <199807150548.XAA01518@panzer.plutotech.com> In-Reply-To: <13142.900479032@gjp.erols.com> from Gary Palmer at "Jul 15, 98 01:03:52 am"
next in thread | previous in thread | raw e-mail | index | archive | help
Gary Palmer wrote... > > Hi, > > I just installed the latest SNAP on -currnent (via make world) and have > a question about camcontrol. I tried using it and fast ran into a > brick wall. > > root@gjp:~/cam> camcontrol -l > camcontrol: cam_real_open_device: CAMGETPASSTHRU ioctl failed > cam_real_open_device: No such file or directory > > I've tried numerous argument combinations with no luck so far. Similarly > with ``camcontrol -i''. Anyone got any hints as to how to use > the command? 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 have been some changes in the CAMGETPASSTHRU ioctl in the transport layer recently. Basically, what it's telling you above is that for whatever reason it can't find one of three things: - the general type of peripheral driver you're looking for, which is in this case "da", since you didn't specify any other argument for camcontrol. - the particular peripheral driver you're looking for, which is in this case da0, since you didn't specify any arguments. - the passthrough driver associated with da0. 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. Try specifying the device you want, like this: camcontrol -t -n cd -u 0 camcontrol -i -n da -u 2 > I also guess that the new support for devfs causes the scsi chains > to be probed at the end of the kernel bootstrap? 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. > (probe7:ahc1:0:0:0): Sending SDTR!! > changing root device to da0s1a > da1 at ahc1 bus 0 target 0 lun 0 > da1: <FUJITSU M1603S-512 6404> Fixed Direct Access SCSI2 device > da1: 10.0MB/s transfers (10.0MHz, offset 15), Tagged Queueing Enabled > da1: 519MB (1064268 512 byte sectors: 64H 32S/T 519C) > da2 at ahc0 bus 0 target 1 lun 0 > da2: <SEAGATE ST15230W SUN4.2G 0738> Fixed Direct Access SCSI2 device > da2: 10.0MB/s transfers (10.0MHz, offset 15), Tagged Queueing Enabled > da2: 4095MB (8386733 512 byte sectors: 255H 63S/T 522C) > da3 at ahc1 bus 0 target 1 lun 0 > da3: <SEAGATE ST15230W SUN4.2G 0738> Fixed Direct Access SCSI2 device > da3: 10.0MB/s transfers (10.0MHz, offset 15), Tagged Queueing Enabled > da3: 4095MB (8386733 512 byte sectors: 255H 63S/T 522C) > da0 at ahc0 bus 0 target 0 lun 0 > da0: <QUANTUM FIREBALL ST4.3S 0F0C> Fixed Direct Access SCSI2 device > da0: 10.0MB/s transfers (10.0MHz, offset 15), Tagged Queueing Enabled > da0: 4136MB (8471232 512 byte sectors: 255H 63S/T 527C) > cd0 at ahc0 bus 0 target 6 lun 0 > cd0: <NEC CD-ROM DRIVE:463 1.05> Removable CD-ROM SCSI2 device > cd0: 3.300MB/s transfers > cd0: Attempt to query device size failed: NOT READY, Medium not present > (da0:ahc0:0:0:0): tagged openings now 8 > (da3:ahc1:0:1:0): tagged openings now 63 > > The CDROM was detected noticably later than the disks, I guess > because of the timeout trying to probe the size? It's more likely that the CDROM drive was just slower to respond. We do ask twice for the size, though, and only fail after the second negative response. So I guess that would also cause it to come back last. Generally, my CDROM drives probe last, even if they do have media in them. > 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 Ken -- Kenneth Merry Ken@plutotech.com 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?199807150548.XAA01518>