From owner-freebsd-scsi@FreeBSD.ORG Wed Nov 7 14:05:31 2012 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EDB0C4EC for ; Wed, 7 Nov 2012 14:05:31 +0000 (UTC) (envelope-from jacks.1785@gmail.com) Received: from mail-ia0-f182.google.com (mail-ia0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id B303C8FC14 for ; Wed, 7 Nov 2012 14:05:30 +0000 (UTC) Received: by mail-ia0-f182.google.com with SMTP id k10so1471028iag.13 for ; Wed, 07 Nov 2012 06:05:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=UOqpmwB7kMqCjE02LsIrv0KVD/AvGjivVAQ9M3nYhCE=; b=lz8Mf3coJCNbgBE0w2dcMHhGmIR6qaCWKSzZdYBFAPFpg/kWPcF3Z2jcg+FA4H6zAc e+6898iKcFdJ4clPuCWuitzHvw1T951W897vJm74Us4AtTi6KThfWDxlTrJ3B8k97V3i 8HfmjIL8sPQc1z5/bec3hICmSDuA0tNY4IGudHXrWnyLmLSJ36b0MVV41MbMTVgvP1iZ PjLw27N6YT0/UEmcCxi6JCz3ckWmJ5/Uxq3vRewvgiPWmJk4wuku8uHZj02ukUWO6fG8 fLTAuhsEK3Htm1z7g9tYnezYMibxXaXpx6Qq6xMCqu39XM8dHjZKC4zwX8GeXLBXqg41 BDUw== MIME-Version: 1.0 Received: by 10.42.80.207 with SMTP id w15mr4046844ick.40.1352297130335; Wed, 07 Nov 2012 06:05:30 -0800 (PST) Received: by 10.64.11.166 with HTTP; Wed, 7 Nov 2012 06:05:29 -0800 (PST) In-Reply-To: References: Date: Wed, 7 Nov 2012 19:35:29 +0530 Message-ID: Subject: Re: cam probe sequence From: Jack To: freebsd-scsi@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 14:05:32 -0000 Hi, On Sun, Nov 4, 2012 at 2:40 PM, Jack wrote: > Hello all, > > I'm trying to understand the probe sequence of a scsi device, say > a scsi hard drive( with SPI/SAS/FC interface). > > I'm particularly interested in probe sequence of a device which is > attached to the system _after_ FreeBSD has booted completely. > (ie post-boot probing.) > > While going through the source of cam subsystem, a few > questions arose in my understanding. > > ( The relevant files I found are cam/cam_xpt.c, cam/cam_periph.c > and cam/scsi/scsi_xpt.c or cam/ata/ata_xpt.c in case of (S)ATA > drives. ) > > As far as I could got till now, it seems that struct cam_et and > struct cam_ed are _always_ created even _before_ the probing of > device commences. > > But how does cam sub-system get to know that a device got > attached to the system, so that it creates struct cam_et and > struct cam_ed in advance, and _then_ probes the device. > > Is it something like a event notfication at hardware level that > the HBA driver passes to cam sub-system which notifies cam > sub-system that a device has recently been attached. > > If it is true, then does all SPI/SAS/FC/(S)ATA HBAs support > such event notification -- something like a standard thing > in SPI/SAS/FC/(S)ATA world. > > If it is not so, then does userland have to intiate a scan after > device is attached, so that during scanning the cam-subsystem > get to know that Oh! there is a device we are meeting first time. > In other words, _until_ userland instructs cam subsystem to scan > all the buses by XPT_SCAN_BUS ccb through CAMIOCOMMAND > ioctl of /dev/xpt0, the struct cam_et and struct cam_ed will not > get created. Is it so? > But in this case also, does cam-subsystem creates > struct cam_et and struct cam_ed before probing the device?. > > In case of SPI/SAS/FC hard drives the probe code is in > cam/scsi/scsi_xpt.c While reading this source file it > also seems to me that a struct cam_periph is also created > as soon as struct cam_et and struct cam_ed are created. > This also happens before probing of device commences. > Is it the pass device that is created even before probing begins. > Then after probing and determining the type of device - e.g. disk, > cd-rom, etc, then the appropriate peripheral device(da, cd, etc. ) is > created for the probed device. Is it so? > > > It would be really helpful if someone could clear these things, > specially from the instant the device -say a hard disk; is attached, > to the instant the pass device and da device are created and > probing of this hard disk commences or finishes. > > > > Regards > -- > Jack Going through sources of cam, I still can't figure out the the invocation of probeschedule() and proberegister(). Actually I am trying to figure out the relation of probe device with xpt layer. a) What exactly is the purpose of "probe" device. It is not shown in /dev , so I guess it is for internal use only. Is there only one instance of "probe" device for each instance of xpt ? or, for each instance of struct cam_ed, a probe device is created, or I am missing something. b) Can anyone point me as where and how is probeschedule() or proberegister() got invoked from xptioctl(). ? (For the case of CAMIOCOMMAND and XPT_SCAN_LUN ccb.) I only know that this causes scsi_scan_lun() to be invoked, but then how is probeschedule() or proberegister() got invoked from it. c )It seems to me that there is no way for cam to automatically detect the presence/attachement of a device on some bus. Ofcourse, usb mass and firewire are exceptions, where the device removal event is triggered at hardware level. In case of SPI/SAS/FC/(S)ATA, this is not the case. So, the only way to determine the presence of recently attached device is to instruct cam to rescan the bus/lun. And this instruction is CAMIOCOMMAND ioctl with XPT_SCAN_xxx ccbs. of pass driver. But then why is xpt_rescan() ? I'm not sure what exactly is the purpose of xpt_rescan() . I guess it is intended to be used from within the kernel, as from within the kernel, xptioctl() can't be invoked. Any clarifications or pointers would be really appreciated. Thanks -- Jack