From owner-freebsd-scsi Sun Aug 4 13:28:30 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1469F37B400; Sun, 4 Aug 2002 13:28:28 -0700 (PDT) Received: from bingnet2.cc.binghamton.edu (bingnet2.cc.binghamton.edu [128.226.1.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5A29D43E42; Sun, 4 Aug 2002 13:28:27 -0700 (PDT) (envelope-from zzhang@cs.binghamton.edu) Received: from opal (cs.binghamton.edu [128.226.123.101]) by bingnet2.cc.binghamton.edu (8.11.6/8.11.6) with ESMTP id g74KSQ312858; Sun, 4 Aug 2002 16:28:26 -0400 (EDT) Date: Sun, 4 Aug 2002 16:28:26 -0400 (EDT) From: Zhihui Zhang X-Sender: zzhang@opal To: freebsd-hackers@freebsd.org, freebsd-scsi@freebsd.org Subject: transaction ordering in SCSI subsystem Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org While reading the document on FreeBSD SCSI subsystem, I am wondering what does guaranteed transaction ordering mean? Does it have anything to do with I/O ordering, tagging, write caching, etc.? Thanks for any enlightment. -Zhihui To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Aug 4 14:11:41 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7012F37B400; Sun, 4 Aug 2002 14:11:39 -0700 (PDT) Received: from aslan.scsiguy.com (aslan.scsiguy.com [63.229.232.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9F67143E6A; Sun, 4 Aug 2002 14:11:38 -0700 (PDT) (envelope-from gibbs@scsiguy.com) Received: from scsiguy.com (localhost [127.0.0.1]) by aslan.scsiguy.com (8.12.5/8.12.5) with ESMTP id g74LBVSY063691; Sun, 4 Aug 2002 15:11:31 -0600 (MDT) (envelope-from gibbs@scsiguy.com) Message-Id: <200208042111.g74LBVSY063691@aslan.scsiguy.com> To: Zhihui Zhang Cc: freebsd-hackers@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: transaction ordering in SCSI subsystem In-Reply-To: Your message of "Sun, 04 Aug 2002 16:28:26 EDT." Date: Sun, 04 Aug 2002 15:11:31 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > >While reading the document on FreeBSD SCSI subsystem, I am wondering what >does guaranteed transaction ordering mean? Does it have anything to do >with I/O ordering, tagging, write caching, etc.? Yes, yes, and yes. CAM guarantees that transactions are queued to the device in the order they were queued to CAM. Even if an error recovery action occurs, I/O is retried/resumed in order once the device is recovered. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Aug 4 22:43: 9 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6097537B400; Sun, 4 Aug 2002 22:43:05 -0700 (PDT) Received: from warez.scriptkiddie.org (uswest-dsl-142-38.cortland.com [209.162.142.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id E3DC043E4A; Sun, 4 Aug 2002 22:43:04 -0700 (PDT) (envelope-from lamont@scriptkiddie.org) Received: from [192.168.69.11] (unknown [192.168.69.11]) by warez.scriptkiddie.org (Postfix) with ESMTP id 5BDDD62D1A; Sun, 4 Aug 2002 22:43:04 -0700 (PDT) Date: Sun, 4 Aug 2002 22:43:25 -0700 (PDT) From: Lamont Granquist To: "Justin T. Gibbs" Cc: Zhihui Zhang , , Subject: Re: transaction ordering in SCSI subsystem In-Reply-To: <200208042111.g74LBVSY063691@aslan.scsiguy.com> Message-ID: <20020804223605.X892-100000@coredump.scriptkiddie.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org So what exactly gets ordered and how do things get tagged? I tried following this in the code from VOP_STRATEGY and never quite figured it out. Basically when you do a write are you just tagging the data writes along with the metadata writes and then sequencing them so that they have to complete in a given order? And can operations with different tags be mixed around randomly? Also, how does the feedback from the SCSI controller that the write completed get used by the O/S (and the corollary being how does IDE write caching lying about completion affect the O/S and the data integrity)? On Sun, 4 Aug 2002, Justin T. Gibbs wrote: > >While reading the document on FreeBSD SCSI subsystem, I am wondering what > >does guaranteed transaction ordering mean? Does it have anything to do > >with I/O ordering, tagging, write caching, etc.? > > Yes, yes, and yes. CAM guarantees that transactions are queued to > the device in the order they were queued to CAM. Even if an error > recovery action occurs, I/O is retried/resumed in order once the > device is recovered. > > -- > Justin > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Aug 4 23:43: 0 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ADD7537B400; Sun, 4 Aug 2002 23:42:51 -0700 (PDT) Received: from harrier.mail.pas.earthlink.net (harrier.mail.pas.earthlink.net [207.217.120.12]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3EFD143E6A; Sun, 4 Aug 2002 23:42:51 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0179.cvx40-bradley.dialup.earthlink.net ([216.244.42.179] helo=mindspring.com) by harrier.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17bbZf-0007gI-00; Sun, 04 Aug 2002 23:42:40 -0700 Message-ID: <3D4E1E0D.582EBE7C@mindspring.com> Date: Sun, 04 Aug 2002 23:41:17 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Lamont Granquist Cc: "Justin T. Gibbs" , Zhihui Zhang , freebsd-hackers@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: transaction ordering in SCSI subsystem References: <20020804223605.X892-100000@coredump.scriptkiddie.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Lamont Granquist wrote: > So what exactly gets ordered and how do things get tagged? > > I tried following this in the code from VOP_STRATEGY and never quite > figured it out. Basically when you do a write are you just tagging the > data writes along with the metadata writes and then sequencing them so > that they have to complete in a given order? And can operations with > different tags be mixed around randomly? > > Also, how does the feedback from the SCSI controller that the write > completed get used by the O/S Requests are issued to CAM. CAM issues requests with tags to SCSI controller. SCSI controller issues commands to target on SCSI bus using a tag. Target completes command, issues "completed" on tag. SCSI controller write status to memory for request struct. SCSI controller issues interrupt. ISR in SCSI driver runs, and notes completed request. ISR notifies CAM. Operations on tags may be concurrently outstanding. There are a limited number of concurrent operations permitted to be outstanding, as dictated by the number of tags supported by a physical disk drive. Operations which can occur concurrently are requested concurrently; the order in which they complete does not matter. Operations which can *not* occur concurrently are requested only serially. This serialization is called a "stall barrier": the next operation is not attempted until the previous operation has been committed to stable storage. Operations at the CAM layer are proxied transactions; as Justin stated, operations queued to CAM are guaranteed to be queued to the underlying physical device in the same order. The FS is responsible for introducing stall barriers, as necessary, to enbsure metadata integrity. If the FS guarantees user data integrity as well, then it must introduce stall barriers for that, as well. The minimal requirement for end-to-end data integrity is for the operating system to guarantee metadata integrity -- transactional idempotence of operations in order to guarantee atomicity -- and the application to provide user data integrity through proper use of metadata operation ordering in order to implement user data transactioning. Usually, this includes explicit data sychronization to disk using fsync(2) calls, if user data integrity is required. In most cases, user data integrity is implied; if, on the other hand, you have seperate files for data record indexing and data record storage, you must provide for explicit synchronization, because you are implying application metadata within user data regions of files, in order to provide services on top of the OS platform, which the OS platform itself does not provide. There are several ways for an FS to ensure metadata integrity. The easiest to implement is synchronous metadata operations. This implies a stall barrier after each metadata operation, prohibiting subsequent metadata operations until the single outstanding operations permitted by the FS is committed to stable storage. In this way, metadata operations ordering is assurred. The second easiest to implement is ordered metadata operations. This is accomplished by dividing metadata operations into sets of "dependent" and "independent" operations. Operations which are "independent" are permitted to occurr concurrently. Operations which are "dependent" imply a stall barrier. This method is formally called "Delayed Order Writes", or "DOW". There are two USL patenets on this (both assigned to Novell). For this reason, if you want to sell your FS in the U.S., you will not use this approach. The third method is much more difficult to implement, since it requires an understanding of graph thoery. It's called "soft updates" (sometimes it's called "soft dependencies") and was invented by Gregory Ganger and Yale Patt. Operations are registered in dependency order into a graph, and stal barriers are only introduced on non-commutive edge traversals. This ends up introducing much fewer stall barriers, overall. In addition, operations which roll forward then backward (e.g. access timestamp updates on intermediate object files which are deleted as part of a compilation process) are never committed to disk; thus only permanent changes end up committed, so long as the operations occur within the update clock time window. If an operation occurs that requires a stall barrier, then a stall barrier is introduced. While it's technically possible to export a transactioning interface to user space programs for all three of these approaches, in practice it is difficult to implement properly. The easiest approach is to simply extend the graph edge in the soft updates case. This has the additional benefit, in a stacking vnode architecture, of avoiding the normally introduced stall barriers that occur between VFS layers, unless there are real dependencies (i.e. the VFS/VFS boundary will normally introduce an artificial stall barrier). For this to be done in FreeBSD would require generalizing the soft updates dependency graph relationship code, to permit registration of node/node edge dependency resolvers (which are explicit in the current soft updates implementation). So the answer to your question is that metadata writes and data writes are treated seperately, and you must write code in your application to deal with user data, rather than relying on the OS to do it for you. For more information on how to deal with this, take a 300 level database class at your local university and/or do a search on the phrase "two stage commit". > (and the corollary being how does IDE write > caching lying about completion affect the O/S and the data integrity)? If a drive lies about having committed data to stable storage (it doesn't matter if it's an IDE drive or a SCSI drive, but IDE drives tend to be crhronic liars), then it causes the SCSI controller to lie to CAM. When the SCSI controller lies to CAM, then it causes CAM to lie to the VFS. When the CAM lies to the VFS, the VFS lies about metadata integrity guarantees, and lies about user data having been commited to stable storage before the fsync(2) call returns. After which the kernel lies to the application program, and the application program lies to the human running it. Moral: do not buy hardware which lies to you, unless you want to have your software lie to you. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Aug 5 18:54:45 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 408B337B400; Mon, 5 Aug 2002 18:54:43 -0700 (PDT) Received: from warez.scriptkiddie.org (uswest-dsl-142-38.cortland.com [209.162.142.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id A16D943E65; Mon, 5 Aug 2002 18:54:42 -0700 (PDT) (envelope-from lamont@scriptkiddie.org) Received: from [192.168.69.11] (unknown [192.168.69.11]) by warez.scriptkiddie.org (Postfix) with ESMTP id D83DB62D1A; Mon, 5 Aug 2002 18:54:41 -0700 (PDT) Date: Mon, 5 Aug 2002 18:55:03 -0700 (PDT) From: Lamont Granquist To: Terry Lambert Cc: "Justin T. Gibbs" , Zhihui Zhang , , Subject: Re: transaction ordering in SCSI subsystem In-Reply-To: <3D4E1E0D.582EBE7C@mindspring.com> Message-ID: <20020805184018.F2654-100000@coredump.scriptkiddie.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sun, 4 Aug 2002, Terry Lambert wrote: > Operations which can *not* occur concurrently are requested only > serially. This serialization is called a "stall barrier": the > next operation is not attempted until the previous operation has > been committed to stable storage. > > Operations at the CAM layer are proxied transactions; as Justin > stated, operations queued to CAM are guaranteed to be queued to > the underlying physical device in the same order. So it sounds like CAM has two features which aid in preserving data integrity. First it serializes operations with the same tag and second it implements stall barriers in those pipelines? Is there a good SCSI reference out there for someone interested more in the features of CAM and the upper layers of the protocol? Also, at a higher level in the VFS layer, which operations are tagged the same? Are operations on the same vnode tagged the same and then write barriers are introduced appropriately between data and metadata writes? Are operations on different vnodes always different tags? And how is the consistancy of something like the block allocation table maintained? [ p.s. thanks quite a lot for that last response ] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Aug 5 19:34:32 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1AD1337B400; Mon, 5 Aug 2002 19:34:24 -0700 (PDT) Received: from harrier.mail.pas.earthlink.net (harrier.mail.pas.earthlink.net [207.217.120.12]) by mx1.FreeBSD.org (Postfix) with ESMTP id A1B3E43E72; Mon, 5 Aug 2002 19:34:23 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0488.cvx40-bradley.dialup.earthlink.net ([216.244.43.233] helo=mindspring.com) by harrier.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17buAm-0007Ta-00; Mon, 05 Aug 2002 19:34:13 -0700 Message-ID: <3D4F34FF.21862712@mindspring.com> Date: Mon, 05 Aug 2002 19:31:27 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Lamont Granquist Cc: "Justin T. Gibbs" , Zhihui Zhang , freebsd-hackers@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: transaction ordering in SCSI subsystem References: <20020805184018.F2654-100000@coredump.scriptkiddie.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Lamont Granquist wrote: > So it sounds like CAM has two features which aid in preserving data > integrity. First it serializes operations with the same tag and > second it implements stall barriers in those pipelines? No. It merely maintains order of requests made to it when it makes requests to underlying layers. Stalls are either the result of hardware limitations (on the bottom end) or semantic guarantees by the VFS (on the top end). It is up to the VFS above whether it wants to make additional requests to CAM, once there are requests outstanding. It is up to the hardware below whether it will accept or defer additional requests from CAM. CAM only limits requests from above when it is itself limited by the hardware below. It's more correct to say that it *propagates* pipeline stalls. The distinction is important here. The main performance issue that you face as a result of a stall barrier is propagation delay down to, and back up from, the physical hardware. Because CAM permits concurrent operations, up to the limits of the hardware, as long as you don't over-drive the hardware, it adds latency on individual transactions, but does not itself limit throughput in the normal case: any bottleneck you have is a result of the underlying hardware, or of the explicit stalls caused by the code above CAM voluntarily avoiding queueing new requests until a previous request has been successfully completed. It's a queue pool retention problem, just like a sliding window protocol, like TCP/IP: for N requests, I end up with a single round trip latency due to the introduced propagation delay. N can be arbitrarily large, up to the limits of the hardware. If you hit those limits, then you start eating a latency per request, as requests become turnstiled by available tags for tagged commands, etc.. > Is there a good SCSI reference out there for someone interested more in > the features of CAM and the upper layers of the protocol? The source code? Justin? I'm sure people would appreciate it if someone would document this code. Right now, most people get to learn about it by writing a provider (like a SCSI driver) or a consumer (kernel block I/O code) of CAM. Trial by fire is not the best way to learn things (IMO), since you only learn about the main road and a few branches, rather than the shape and size of the city. > Also, at a higher level in the VFS layer, which operations are tagged the > same? Are operations on the same vnode tagged the same and then write > barriers are introduced appropriately between data and metadata writes? > Are operations on different vnodes always different tags? And how is the > consistancy of something like the block allocation table maintained? Operations are not explicitly tagged on a per system call basis, if that's what you are asking. For your other questions, there are really two different issues: 1) POSIX semantics. POSIX semantics dictate which operations must be committed to stable storage before other operations are permitted to proceed. POSIX therefore implies some soft barrier points, and some hard barrier points (e.g. fsync(2)). These are normally handled by the FS, not by the system call layer (e.g. you might have NVRAM to which metdata changes are logged by the FS, so it can return immediately, so it's reall an FS thing). 2) File System implementation details. Each FS implementation has internal consistency guarantees that differ based on the FS implementation. For example, if you constrast directory management in MSDOSFS and FFS, in FFS, a directory entry is just a *reference* to an inode (hence the ability to support hard links) and in MSDOSFS, the directory entry has both the name and the inode metadata, as one unit (a FAT entry -- hence the inability to support hard links). What this means is that in FFS there are two operations that have an explicit ordering relationship, whereas in MSDOSFS, there is just one operation. This also explains why ordering can't be implemented at the upper level, in the system call layer. The upshot of this is that consistency is maintained by semantics specific to each FS implementation, which deal with that FS' decision whether or not to implement a stall barrier for a particular operation (e.g. "lock an inode; cause subsequent requests to sleep until the current outstanding request is satisfied; unlock the inode" ... thus causing operations to be ordered: inodes are per-FS objects, so any stalling by waiting for operations to be acknowledged,k rather than simply blindly queueing them has to be in FS specific code). The reality is even more complicated; I've hidden a number of layers, and I generalized quite a bit (I'm surprised no one has complained, yet). For example, between the VFS and CAM is the VM, and a block I/O system based on page-based I/O management, with specific exceptions allowed for physical disk block access on a block-by-block basis for directory entries. So when you do a write of 35 bytes, you may end up having to do a lot more than you think (e.g. page in the page containing the 35 bytes -- or two, if it spans a page boundary, modify the 35 bytes with a copy from the user space buffer to the page hung off the vm_object_t off the vnode to the file, pointed to by the per process open file table pointed to by the proc structure, mark the page as dirty, sleep pending it being written out if what we are dealing with is a metadata change, etc.). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Aug 7 6:36:50 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 96C7937B400 for ; Wed, 7 Aug 2002 06:36:44 -0700 (PDT) Received: from enserg.enserg.fr (enserg.enserg.fr [192.93.178.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id C53DE43E4A for ; Wed, 7 Aug 2002 06:36:43 -0700 (PDT) (envelope-from jdalbosc@enserg.fr) Received: (from www@localhost) by enserg.enserg.fr (8.12.1/8.12.1) id g77DagTe031718; Wed, 7 Aug 2002 15:36:42 +0200 Date: Wed, 7 Aug 2002 15:36:42 +0200 Message-Id: <200208071336.g77DagTe031718@enserg.enserg.fr> X-Authentication-Warning: enserg.enserg.fr: www set sender to jdalbosc@enserg.fr using -f From: "Jean-françois Dalbosco" To: freebsd-scsi@FreeBSD.org Subject: CAM and the passthrough device X-Mailer: NeoMail 1.24 X-IPAddress: 194.206.211.65 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org hi, i'm currently trying to port an Irix software to FreeBSD. Part of the software consist in a driver for a SCSI device which is a bit particular. However particular it may be on Irix it worked perfectly. But now with some specific CDB i don't manage to perform the same actions on the mbm. I'm using the passthrough driver and the CAM ccb to send my opcodes to the device. But it seems like it doesn't work ( the device doesn't fullfill the buffer i'm giving it for retrieving datas ) for some opcodes though it should insofar as it used to work on Irix. I join the code i'm using to test those opcodes and i've 2 questions: 1. is the way i'm using CAM correct?( i manage to get some good result for some opcodes but for other like Read A Page it sucks completly ...) 2. does the passthrough driver require something more for my code to work? And if no, where could the data be stored if not at the adress of dataptr? thanks by advance for your help! #include #include #include #include #include #include #include #include #include #define AdrPage 0 int main(int argc,char *argv[]) { int status = 0 , i; struct cam_device *cam_dev = NULL; union ccb *ccb; u_int8_t *data_ptr; long int databytes; char Nom_Fichier[]="ENTETMBM"; /************************************************/ /* Opening of the device */ /************************************************/ cam_dev = cam_open_device("/dev/da2",O_RDWR); if ( cam_dev == NULL ) { printf("Error while opening the device %s\n%s\n",argv [1],cam_errbuf); status = -1; } else { printf("Device opening succeed\n"); } /************************************************/ /* Creation of the ccb that goes with */ /************************************************/ ccb = cam_getccb(cam_dev); /**************************************************/ /* Memory space reservation for */ /* the datas */ /**************************************************/ if (argv[1]!=NULL){ databytes = (long int)atoi(argv[2]); printf("Nb de databytes= %x\n",databytes); } else databytes = 1024; data_ptr = (u_int8_t *)malloc(databytes); if ( data_ptr == NULL ) { printf("malloc failure"); status=-1; } else { bzero(data_ptr,databytes); } /*************************************************/ /* fullfill the ccb a 1st time */ /*************************************************/ cam_fill_csio(&ccb->csio, /* retries */ 1, /* cbfcnp */ NULL, /* flags */ CAM_DIR_IN, /* tag_action */ MSG_SIMPLE_Q_TAG, /* data_ptr */ Nom_Fichier, /* data tfert len */ 8, /* sense lenght */ SSD_FULL_SIZE, /* cdb_len */ 10, /* timeout */ 35000 ); bzero( &ccb->csio.cdb_io.cdb_bytes,10); ccb->csio.cdb_io.cdb_bytes[0]=(u_int8_t)0xF8; ccb->csio.cdb_io.cdb_bytes[9]=(u_int8_t)0x80; if ( cam_send_ccb(cam_dev,ccb)<0 ) { printf("cam_send_ccb ERROR!\n%s\n%s\n",cam_errbuf,strerror (errno)); status = -1; } else { printf("1st send_ccb succeed!\n"); } /*************************************************/ /* fullfill the ccb a 2nd time for */ /* another opcode */ /*************************************************/ cam_fill_csio(&ccb->csio, /* retries */ 1, /* cbfcnp */ NULL, /* flags */ CAM_DIR_IN, /* tag_action */ MSG_SIMPLE_Q_TAG, /* data_ptr */ data_ptr, /* data tfert len */ databytes, /* sense lenght */ SSD_FULL_SIZE, /* cdb_len */ 10, /* timeout */ 35000 ); bzero( &ccb->csio.cdb_io.cdb_bytes,10); ccb->csio.cdb_io.cdb_bytes[0]=(u_int8_t)0xE0; // ccb->csio.cdb_io.cdb_bytes[9]=(u_int8_t)0x80; ccb->csio.cdb_io.cdb_bytes[2]=/* Adresse Page */(u_int8_t)AdrPage; ccb->csio.cdb_io.cdb_bytes[3]=/* Adresse Page & 0x00FF */AdrPage & 0x00FF; ccb->csio.cdb_io.cdb_bytes[7]=1 | 0x80; ccb->csio.cdb_io.cdb_bytes[8]=1 & 0x00FF; printf("Avant le Lecture_Directe_Page, data_ptr:%s\n",data_ptr); if ( cam_send_ccb(cam_dev,ccb)<0 ) { printf("cam_send_ccb ERROR!\n%s\n%s\n",cam_errbuf,strerror (errno)); status = -1; } else { printf("cam_send_ccb SUCCESS!\nApres le Lecture_Directe_Pages, data_ptr:\n"); for(i=0;i; Wed, 7 Aug 2002 10:05:01 -0700 (PDT) Received: from magic.adaptec.com (magic.adaptec.com [208.236.45.80]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2208C43E42 for ; Wed, 7 Aug 2002 10:05:01 -0700 (PDT) (envelope-from gibbs@scsiguy.com) Received: from redfish.adaptec.com (redfish.adaptec.com [162.62.50.11]) by magic.adaptec.com (8.10.2+Sun/8.10.2) with ESMTP id g77H4vG26568 for ; Wed, 7 Aug 2002 10:04:57 -0700 (PDT) Received: from btc.btc.adaptec.com (btc.btc.adaptec.com [10.100.0.52]) by redfish.adaptec.com (8.8.8+Sun/8.8.8) with ESMTP id KAA22813 for ; Wed, 7 Aug 2002 10:04:56 -0700 (PDT) Received: from [10.100.253.70] (aslan [10.100.253.70]) by btc.btc.adaptec.com (8.8.8+Sun/8.8.8) with ESMTP id LAA28306 for ; Wed, 7 Aug 2002 11:04:53 -0600 (MDT) Date: Wed, 07 Aug 2002 09:21:02 -0600 From: "Justin T. Gibbs" To: Jean-franXois Dalbosco Message-ID: <943380000.1028733662@aslan.scsiguy.com> In-Reply-To: <200208071336.g77DagTe031718@enserg.enserg.fr> References: <200208071336.g77DagTe031718@enserg.enserg.fr> X-Mailer: Mulberry/2.2.1 (Linux/x86) Subject: Re: CAM and the passthrough device X-Resent-Mailer: Mulberry/2.2.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > /*************************************************/ > /* fullfill the ccb a 2nd time for */ > /* another opcode */ > /*************************************************/ ... > bzero( &ccb->csio.cdb_io.cdb_bytes,10); > ccb->csio.cdb_io.cdb_bytes[0]=(u_int8_t)0xE0; This is a vendor unique command, so I don't really know what format it takes, but it certainly looks like you have a bug here. > // ccb->csio.cdb_io.cdb_bytes[9]=(u_int8_t)0x80; > > ccb->csio.cdb_io.cdb_bytes[2]=/* Adresse Page */(u_int8_t)AdrPage; > ccb->csio.cdb_io.cdb_bytes[3]=/* Adresse Page & 0x00FF */AdrPage & > 0x00FF; Multi-byte integers in SCSI are in BigEndian format. The code above sets both cdb[2] and cdb[3] to the low byte of the page address. The code should look like: scsi_ulto2b(AdrPage, &ccb->csio.cdb_io.cdb_bytes[2]); which is equivalent to doing: ccb->csio.cdb_io.cdb_bytes[2] = AdrPage; ccb->csio.cdb_io.cdb_bytes[3] = AdrPage >> 8; > ccb->csio.cdb_io.cdb_bytes[7]=1 | 0x80; > ccb->csio.cdb_io.cdb_bytes[8]=1 & 0x00FF; Is this really what you had in mind? 1 & 0x00FF == 1 -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Aug 8 2:13:33 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 90FCE37B400 for ; Thu, 8 Aug 2002 02:13:31 -0700 (PDT) Received: from enserg.enserg.fr (enserg.enserg.fr [192.93.178.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9361343E6E for ; Thu, 8 Aug 2002 02:13:30 -0700 (PDT) (envelope-from jdalbosc@enserg.fr) Received: (from www@localhost) by enserg.enserg.fr (8.12.1/8.12.1) id g789DOtP027235; Thu, 8 Aug 2002 11:13:24 +0200 Date: Thu, 8 Aug 2002 11:13:24 +0200 Message-Id: <200208080913.g789DOtP027235@enserg.enserg.fr> X-Authentication-Warning: enserg.enserg.fr: www set sender to jdalbosc@enserg.fr using -f From: "Jean-françois Dalbosco" To: freebsd-scsi@FreeBSD.org Subject: still don't work :o( X-Mailer: NeoMail 1.24 X-IPAddress: 194.206.211.65 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org hi, First i would like to thank you for your reply. i've tryed to change the bytes order and use the scsi_ulto2b() function but it still doesn't work. The buffer pointed to by the dataptr member of my ccb is still full of zero with no data from my device in it... besides i have 2 questions: 1. when i send a READ_6 opcode to the device it fullfills the databuffer with a series of characters. They are not really what i'm expecting but they do come from the device since i've been able to recognize 'on the fly' a string that has something to do with the device name. The device is a sort of Memory Disk and i was wondering from where those data could spring out? 2. my second question is how specific a driver can be? or in other words does the specificity of a device only resides in the specificity of its command opcodes or is there any other specificity that the Passthrough driver couldn't deal with? thanks a lot for your help. -- NeoMail - Webmail that doesn't suck... as much. http://neomail.sourceforge.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Aug 8 7:32:17 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4D4A137B400 for ; Thu, 8 Aug 2002 07:32:14 -0700 (PDT) Received: from noe.warszawa.mtl.pl (noe.warszawa.multinet.pl [213.241.3.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id CC16243E3B for ; Thu, 8 Aug 2002 07:32:12 -0700 (PDT) (envelope-from mgryszkalis@cerint.pl) Received: by noe.warszawa.mtl.pl (Postfix, from userid 1007) id 449FA7DF60; Thu, 8 Aug 2002 16:32:23 +0200 (CEST) Received: from cerint.pl (systemy237.toya.net.pl [217.113.225.237]) by arka.warszawa.mtl.pl (Postfix) with ESMTP id EF515EA77A for ; Thu, 8 Aug 2002 16:32:21 +0200 (CEST) Message-ID: <3D5280F4.8030706@cerint.pl> Date: Thu, 08 Aug 2002 16:32:20 +0200 From: Marcin Gryszkalis Organization: Cerint Technology Group User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1b) Gecko/20020806 X-Accept-Language: en-us, en, pl MIME-Version: 1.0 To: freebsd-scsi@freebsd.org Subject: da driver problem? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus: Poczta jest monitorowana oprogramowaniem antywirusowym. Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi I upgraded to 4.6-STABLE (from 4.5) and after reboot I notices very strange behavior (from dmesg:) da0 : fixed SCSI device da1: fixed SCSI device da2: fixed SCSI device . . . da14: fixed SCSI device - so, all 15 da devices are set as my frist hdd. Because of that I cannot acces my second hdd: (/dev/da0e is /var and /dev/da1e is /www) #mount /dev/da1e /www WARNING: R/W mount of /var denied. Filesystem is not clean - run fsck mount /dev/da1e: Operation not permitted I will be able to get to the box tomorrow - I think I could do 'sh MAKEDEV' but I didn't - would it help? The box is Digital alpha workstation 500, I cannot tell you details about controller etc. I'll check tomorrow regards marcin cc me, please. -- Marcin Gryszkalis or To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Aug 8 14:29:49 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0EB4837B400 for ; Thu, 8 Aug 2002 14:29:47 -0700 (PDT) Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by mx1.FreeBSD.org (Postfix) with ESMTP id D4B0243E5E for ; Thu, 8 Aug 2002 14:29:45 -0700 (PDT) (envelope-from ken@panzer.kdm.org) Received: from panzer.kdm.org (localhost [127.0.0.1]) by panzer.kdm.org (8.12.5/8.12.5) with ESMTP id g78LTNKD018784; Thu, 8 Aug 2002 15:29:23 -0600 (MDT) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.12.5/8.12.5/Submit) id g78LTMVI018783; Thu, 8 Aug 2002 15:29:22 -0600 (MDT) (envelope-from ken) Date: Thu, 8 Aug 2002 15:29:22 -0600 From: "Kenneth D. Merry" To: Marcin Gryszkalis Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: da driver problem? Message-ID: <20020808152922.A18763@panzer.kdm.org> References: <3D5280F4.8030706@cerint.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3D5280F4.8030706@cerint.pl>; from mgryszkalis@cerint.pl on Thu, Aug 08, 2002 at 04:32:20PM +0200 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, Aug 08, 2002 at 16:32:20 +0200, Marcin Gryszkalis wrote: > Hi > I upgraded to 4.6-STABLE (from 4.5) and after reboot I notices > very strange behavior (from dmesg:) > da0 : fixed SCSI device > da1: fixed SCSI device > da2: fixed SCSI device > . > . > . > da14: fixed SCSI device > > - so, all 15 da devices are set as my frist hdd. > > Because of that I cannot acces my second hdd: > > (/dev/da0e is /var and /dev/da1e is /www) > > #mount /dev/da1e /www > WARNING: R/W mount of /var denied. Filesystem is not clean - run fsck > mount /dev/da1e: Operation not permitted > > I will be able to get to the box tomorrow - I think I could > do 'sh MAKEDEV' but I didn't - would it help? > > The box is Digital alpha workstation 500, I cannot tell you details about > controller etc. I'll check tomorrow We'll probably need to see complete dmesg output, and perhaps camcontrol devlist output in order to help figure this one out. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Aug 8 15: 8:51 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1B0D837B400 for ; Thu, 8 Aug 2002 15:08:49 -0700 (PDT) Received: from rootlabs.com (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 46F2F43E6E for ; Thu, 8 Aug 2002 15:08:47 -0700 (PDT) (envelope-from nate@rootlabs.com) Received: (qmail 20873 invoked by uid 1000); 8 Aug 2002 22:08:48 -0000 Date: Thu, 8 Aug 2002 15:08:48 -0700 (PDT) From: Nate Lawson To: =?X-UNKNOWN?Q?Jean-fran=E7ois_Dalbosco?= Cc: freebsd-scsi@FreeBSD.org Subject: Re: still don't work :o( In-Reply-To: <200208080913.g789DOtP027235@enserg.enserg.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: 8BIT Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, 8 Aug 2002, Jean-françois Dalbosco wrote: > 1. when i send a READ_6 opcode to the device it fullfills the > databuffer with a series of characters. They are not really what i'm > expecting but they do come from the device since i've been able to > recognize 'on the fly' a string that has something to do with the > device name. The device is a sort of Memory Disk and i was wondering > from where those data could spring out? No idea what your device is, but the data could be a boot block, device-specific storage, etc. > 2. my second question is how specific a driver can be? or in other > words does the specificity of a device only resides in the specificity > of its command opcodes or is there any other specificity that the > Passthrough driver couldn't deal with? > > thanks a lot for your help. The passthrough driver just sends the CCB to the SIM based on the path. It's up to your SIM to execute the command and the target's firmware to perform the requested operation. Try looking at the code to camcontrol/libcam. They correctly implement commands like INQUIRY that should be useful to you in learning how CAM works. has some useful premade structs for SCSI-2 commands. -Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Aug 9 1: 9:21 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DBBD937B400 for ; Fri, 9 Aug 2002 01:09:19 -0700 (PDT) Received: from enserg.enserg.fr (enserg.enserg.fr [192.93.178.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id E092F43E3B for ; Fri, 9 Aug 2002 01:09:18 -0700 (PDT) (envelope-from jdalbosc@enserg.fr) Received: (from www@localhost) by enserg.enserg.fr (8.12.1/8.12.1) id g7989CEu029039; Fri, 9 Aug 2002 10:09:12 +0200 Date: Fri, 9 Aug 2002 10:09:12 +0200 Message-Id: <200208090809.g7989CEu029039@enserg.enserg.fr> X-Authentication-Warning: enserg.enserg.fr: www set sender to jdalbosc@enserg.fr using -f From: "Jean-françois Dalbosco" To: freebsd-scsi@FreeBSD.org Subject: need to write a specific SIM? X-Mailer: NeoMail 1.24 X-IPAddress: 194.206.211.65 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Bonjour c'est encore moi... So following to the answer of Nate i was wondering: first if i needed to rewrite a personnal SIM for my device which is a Magnetic Bubble Memory though i have already been able to send succesfully generic command like 0x00 ( TUR ) READ_6 and one vendor unique command 0xF0 ( Test MBM ) with the passthrough driver to my device /dev/da2? secondly if it is not compulsory to rewrite a SIM which SIM does my device use at the present time knowing that it is attached to the passthrough driver? thank you for help! -- Jeff qui un jour fera fonctionner sa *** de mbm To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Aug 9 6: 2:42 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B295B37B400; Fri, 9 Aug 2002 06:02:30 -0700 (PDT) Received: from noe.warszawa.mtl.pl (noe.warszawa.multinet.pl [213.241.3.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 544AC43E42; Fri, 9 Aug 2002 06:02:29 -0700 (PDT) (envelope-from mgryszkalis@cerint.pl) Received: by noe.warszawa.mtl.pl (Postfix, from userid 1007) id 6330F7E03D; Fri, 9 Aug 2002 15:02:39 +0200 (CEST) Received: from cerint.pl (systemy237.toya.net.pl [217.113.225.237]) by arka.warszawa.mtl.pl (Postfix) with ESMTP id 0E658EA7A7; Fri, 9 Aug 2002 15:02:25 +0200 (CEST) Message-ID: <3D53BD58.1060600@cerint.pl> Date: Fri, 09 Aug 2002 15:02:16 +0200 From: Marcin Gryszkalis Organization: Cerint Technology Group User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1b) Gecko/20020806 X-Accept-Language: en-us, en, pl MIME-Version: 1.0 To: "Kenneth D. Merry" Cc: freebsd-scsi@FreeBSD.ORG, freebsd-alpha Subject: Re: da driver problem? References: <3D5280F4.8030706@cerint.pl> <20020808152922.A18763@panzer.kdm.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus: Poczta jest monitorowana oprogramowaniem antywirusowym. Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Kenneth D. Merry wrote: > We'll probably need to see complete dmesg output, and perhaps camcontrol > devlist output in order to help figure this one out. Here it is, as if you need more informtaion: camcontrol devlist: at scbus0 target 1 lun 0 (pass0,da0) at scbus0 target 2 lun 0 (pass1,da1) at scbus0 target 3 lun 0 (pass2,da2) at scbus0 target 4 lun 0 (pass3,da3) at scbus0 target 5 lun 0 (pass4,da4) at scbus0 target 6 lun 0 (pass5,da5) at scbus0 target 7 lun 0 (pass6,da6) at scbus0 target 8 lun 0 (pass7,da7) at scbus0 target 9 lun 0 (pass8,da8) at scbus0 target 10 lun 0 (pass9,da9) at scbus0 target 11 lun 0 (pass10,da10) at scbus0 target 12 lun 0 (pass11,da11) at scbus0 target 13 lun 0 (pass12,da12) at scbus0 target 14 lun 0 (pass13,da13) at scbus0 target 15 lun 0 (pass14,da14) dmesg output: Copyright (c) 1992-2002 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.6-STABLE #22: Thu Aug 1 22:49:13 CEST 2002 root@ldah.math.uni.lodz.pl:/usr/src/sys/compile/ldah AlphaStation 500 or 600 (KN20AA) Digital AlphaStation 500/333, 333MHz 8192 byte page size, 1 processor. CPU: EV5 (21164) major=5 minor=0 OSF PAL rev: 0x1000000020115 real memory = 64856064 (63336K bytes) avail memory = 58195968 (56832K bytes) Preloaded elf kernel "kernel" at 0xfffffc0000580000. cia0: ALCOR/ALCOR2, pass 2 pcib0: <2117x PCI host bus adapter> on cia0 pci0: on pcib0 de0: port 0x10100-0x1017f mem 0x82019000-0x8201907f irq 13 at device 6.0 on pci0 de0: interrupting at CIA irq 13 de0: DEC 21040 [10Mb/s] pass 2.4 de0: address 00:00:f8:24:19:eb pci0: at 8.0 irq 16 isp0: port 0x10000-0x100ff mem 0x82018000-0x82018fff irq 12 at device 9.0 on pci0 isp0: interrupting at CIA irq 12 isp0: invalid NVRAM header isab0: at device 10.0 on pci0 isa0: on isab0 fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: interrupting at ISA irq 6 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 atkbd0: interrupting at ISA irq 1 psm0: irq 12 on atkbdc0 psm0: interrupting at ISA irq 12 psm0: model Generic PS/2 mouse, device ID 0 vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 sc0: on isa0 sc0: VGA <16 virtual consoles, flags=0x200> mcclock0: at port 0x70-0x71 on isa0 sio0 at port 0x3f8-0x3ff irq 4 on isa0 sio0: type 16550A sio0: interrupting at ISA irq 4 sio1: reserved for low-level i/o Timecounter "alpha" frequency 333330940 Hz IP packet filtering initialized, divert disabled, rule-based forwarding enabled, default to deny, logging limited to 100 packets/entry by default Waiting 15 seconds for SCSI devices to settle de0: enabling 10baseT port Mounting root from ufs:/dev/da0a da0 at isp0 bus 0 target 1 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 20.000MB/s transfers (10.000MHz, offset 12, 16bit), Tagged Queueing Enabled da0: 4091MB (8380080 512 byte sectors: 255H 63S/T 521C) da1 at isp0 bus 0 target 2 lun 0 da1: Fixed Direct Access SCSI-2 device da1: 20.000MB/s transfers (10.000MHz, offset 12, 16bit), Tagged Queueing Enabled da1: 4091MB (8380080 512 byte sectors: 255H 63S/T 521C) da2 at isp0 bus 0 target 3 lun 0 da2: Fixed Direct Access SCSI-2 device da2: 20.000MB/s transfers (10.000MHz, offset 12, 16bit), Tagged Queueing Enabled da2: 4091MB (8380080 512 byte sectors: 255H 63S/T 521C) da3 at isp0 bus 0 target 4 lun 0 da3: Fixed Direct Access SCSI-2 device da3: 20.000MB/s transfers (10.000MHz, offset 12, 16bit), Tagged Queueing Enabled da3: 4091MB (8380080 512 byte sectors: 255H 63S/T 521C) da4 at isp0 bus 0 target 5 lun 0 da4: Fixed Direct Access SCSI-2 device da4: 20.000MB/s transfers (10.000MHz, offset 12, 16bit), Tagged Queueing Enabled da4: 4091MB (8380080 512 byte sectors: 255H 63S/T 521C) da5 at isp0 bus 0 target 6 lun 0 da5: Fixed Direct Access SCSI-2 device da5: 20.000MB/s transfers (10.000MHz, offset 12, 16bit), Tagged Queueing Enabled da5: 4091MB (8380080 512 byte sectors: 255H 63S/T 521C) da6 at isp0 bus 0 target 7 lun 0 da6: Fixed Direct Access SCSI-2 device da6: 20.000MB/s transfers (10.000MHz, offset 12, 16bit), Tagged Queueing Enabled da6: 4091MB (8380080 512 byte sectors: 255H 63S/T 521C) da7 at isp0 bus 0 target 8 lun 0 da7: Fixed Direct Access SCSI-2 device da7: 20.000MB/s transfers (10.000MHz, offset 12, 16bit), Tagged Queueing Enabled da7: 4091MB (8380080 512 byte sectors: 255H 63S/T 521C) da8 at isp0 bus 0 target 9 lun 0 da8: Fixed Direct Access SCSI-2 device da8: 20.000MB/s transfers (10.000MHz, offset 12, 16bit), Tagged Queueing Enabled da8: 4091MB (8380080 512 byte sectors: 255H 63S/T 521C) da9 at isp0 bus 0 target 10 lun 0 da9: Fixed Direct Access SCSI-2 device da9: 20.000MB/s transfers (10.000MHz, offset 12, 16bit), Tagged Queueing Enabled da9: 4091MB (8380080 512 byte sectors: 255H 63S/T 521C) da10 at isp0 bus 0 target 11 lun 0 da10: Fixed Direct Access SCSI-2 device da10: 20.000MB/s transfers (10.000MHz, offset 12, 16bit), Tagged Queueing Enabled da10: 4091MB (8380080 512 byte sectors: 255H 63S/T 521C) da11 at isp0 bus 0 target 12 lun 0 da11: Fixed Direct Access SCSI-2 device da11: 20.000MB/s transfers (10.000MHz, offset 12, 16bit), Tagged Queueing Enabled da11: 4091MB (8380080 512 byte sectors: 255H 63S/T 521C) da12 at isp0 bus 0 target 13 lun 0 da12: Fixed Direct Access SCSI-2 device da12: 20.000MB/s transfers (10.000MHz, offset 12, 16bit), Tagged Queueing Enabled da12: 4091MB (8380080 512 byte sectors: 255H 63S/T 521C) da13 at isp0 bus 0 target 14 lun 0 da13: Fixed Direct Access SCSI-2 device da13: 20.000MB/s transfers (10.000MHz, offset 12, 16bit), Tagged Queueing Enabled da13: 4091MB (8380080 512 byte sectors: 255H 63S/T 521C) da14 at isp0 bus 0 target 15 lun 0 da14: Fixed Direct Access SCSI-2 device da14: 20.000MB/s transfers (10.000MHz, offset 12, 16bit), Tagged Queueing Enabled da14: 4091MB (8380080 512 byte sectors: 255H 63S/T 521C) -- Marcin Gryszkalis or To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Aug 9 6: 8:15 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D82FC37B400; Fri, 9 Aug 2002 06:08:11 -0700 (PDT) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id C3D6643E5E; Fri, 9 Aug 2002 06:08:10 -0700 (PDT) (envelope-from ticso@cicely5.cicely.de) Received: from cicely5.cicely.de (p5087B56A.dip.t-dialin.net [80.135.181.106]) (authenticated bits=0) by srv1.cosmo-project.de (8.12.5/8.12.5) with ESMTP id g79D84vo052488 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Fri, 9 Aug 2002 15:08:06 +0200 (CEST) (envelope-from ticso@cicely5.cicely.de) Received: from cicely5.cicely.de (localhost [IPv6:::1]) by cicely5.cicely.de (8.12.1/8.12.1) with ESMTP id g79D7qFJ058327 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 9 Aug 2002 15:07:52 +0200 (CEST)?g (envelope-from ticso@cicely5.cicely.de) Received: (from ticso@localhost) by cicely5.cicely.de (8.12.1/8.12.1/Submit) id g79D7p78058326; Fri, 9 Aug 2002 15:07:51 +0200 (CEST)?g (envelope-from ticso) Date: Fri, 9 Aug 2002 15:07:50 +0200 From: Bernd Walter To: Marcin Gryszkalis Cc: "Kenneth D. Merry" , freebsd-scsi@FreeBSD.ORG, freebsd-alpha Subject: Re: da driver problem? Message-ID: <20020809130749.GJ52932@cicely5.cicely.de> Reply-To: ticso@cicely.de References: <3D5280F4.8030706@cerint.pl> <20020808152922.A18763@panzer.kdm.org> <3D53BD58.1060600@cerint.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D53BD58.1060600@cerint.pl> X-Operating-System: FreeBSD cicely5.cicely.de 5.0-CURRENT i386 User-Agent: Mutt/1.5.1i Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, Aug 09, 2002 at 03:02:16PM +0200, Marcin Gryszkalis wrote: > Kenneth D. Merry wrote: > >We'll probably need to see complete dmesg output, and perhaps camcontrol > >devlist output in order to help figure this one out. > > Here it is, as if you need more informtaion: > camcontrol devlist: > > at scbus0 target 1 lun 0 (pass0,da0) > at scbus0 target 2 lun 0 (pass1,da1) > at scbus0 target 3 lun 0 (pass2,da2) > at scbus0 target 4 lun 0 (pass3,da3) > at scbus0 target 5 lun 0 (pass4,da4) > at scbus0 target 6 lun 0 (pass5,da5) > at scbus0 target 7 lun 0 (pass6,da6) > at scbus0 target 8 lun 0 (pass7,da7) > at scbus0 target 9 lun 0 (pass8,da8) > at scbus0 target 10 lun 0 (pass9,da9) > at scbus0 target 11 lun 0 (pass10,da10) > at scbus0 target 12 lun 0 (pass11,da11) > at scbus0 target 13 lun 0 (pass12,da12) > at scbus0 target 14 lun 0 (pass13,da13) > at scbus0 target 15 lun 0 (pass14,da14) If this is all the same drive you should check for an SCSI-ID collision - most likely with the host adapter. -- B.Walter COSMO-Project http://www.cosmo-project.de ticso@cicely.de Usergroup info@cosmo-project.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Aug 9 6:14: 3 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A4AEA37B400; Fri, 9 Aug 2002 06:14:00 -0700 (PDT) Received: from noe.warszawa.mtl.pl (noe.warszawa.multinet.pl [213.241.3.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 28A1543E72; Fri, 9 Aug 2002 06:14:00 -0700 (PDT) (envelope-from mgryszkalis@cerint.pl) Received: by noe.warszawa.mtl.pl (Postfix, from userid 1007) id D8B677DF51; Fri, 9 Aug 2002 15:14:10 +0200 (CEST) Received: from cerint.pl (systemy237.toya.net.pl [217.113.225.237]) by arka.warszawa.mtl.pl (Postfix) with ESMTP id F29FDEA77A; Fri, 9 Aug 2002 15:14:09 +0200 (CEST) Message-ID: <3D53C01A.1050702@cerint.pl> Date: Fri, 09 Aug 2002 15:14:02 +0200 From: Marcin Gryszkalis Organization: Cerint Technology Group User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1b) Gecko/20020806 X-Accept-Language: en-us, en, pl MIME-Version: 1.0 To: freebsd-scsi@FreeBSD.ORG Cc: freebsd-alpha Subject: Re: da driver problem? References: <3D5280F4.8030706@cerint.pl> <20020808152922.A18763@panzer.kdm.org> <3D53BD58.1060600@cerint.pl> <20020809130749.GJ52932@cicely5.cicely.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus: Poczta jest monitorowana oprogramowaniem antywirusowym. Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Bernd Walter wrote: >>camcontrol devlist: >> at scbus0 target 1 lun 0 (pass0,da0) .... >> at scbus0 target 15 lun 0 (pass14,da14) > If this is all the same drive you should check for an SCSI-ID > collision - most likely with the host adapter. Sure - it is the same drive - I can't access the other one. but - how do I check - I don't know much about scsi internals. -- Marcin Gryszkalis or To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Aug 9 8:12:12 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2574B37B400; Fri, 9 Aug 2002 08:12:08 -0700 (PDT) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 38E2543E5E; Fri, 9 Aug 2002 08:12:07 -0700 (PDT) (envelope-from ticso@cicely5.cicely.de) Received: from cicely5.cicely.de (cicely5.cicely.de [IPv6:3ffe:400:8d0:301:200:92ff:fe9b:20e7]) (authenticated bits=0) by srv1.cosmo-project.de (8.12.5/8.12.5) with ESMTP id g79FC2vo054033 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Fri, 9 Aug 2002 17:12:03 +0200 (CEST) (envelope-from ticso@cicely5.cicely.de) Received: from cicely5.cicely.de (localhost [IPv6:::1]) by cicely5.cicely.de (8.12.1/8.12.1) with ESMTP id g79FC0FJ059120 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 9 Aug 2002 17:12:01 +0200 (CEST)?g (envelope-from ticso@cicely5.cicely.de) Received: (from ticso@localhost) by cicely5.cicely.de (8.12.1/8.12.1/Submit) id g79FC0E3059119; Fri, 9 Aug 2002 17:12:00 +0200 (CEST)?g (envelope-from ticso) Date: Fri, 9 Aug 2002 17:12:00 +0200 From: Bernd Walter To: Marcin Gryszkalis Cc: freebsd-scsi@FreeBSD.ORG, freebsd-alpha Subject: Re: da driver problem? Message-ID: <20020809151159.GV52932@cicely5.cicely.de> Reply-To: ticso@cicely.de References: <3D5280F4.8030706@cerint.pl> <20020808152922.A18763@panzer.kdm.org> <3D53BD58.1060600@cerint.pl> <20020809130749.GJ52932@cicely5.cicely.de> <3D53C01A.1050702@cerint.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D53C01A.1050702@cerint.pl> X-Operating-System: FreeBSD cicely5.cicely.de 5.0-CURRENT i386 User-Agent: Mutt/1.5.1i Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, Aug 09, 2002 at 03:14:02PM +0200, Marcin Gryszkalis wrote: > Bernd Walter wrote: > >>camcontrol devlist: > >> at scbus0 target 1 lun 0 (pass0,da0) > .... > >> at scbus0 target 15 lun 0 (pass14,da14) > > >If this is all the same drive you should check for an SCSI-ID > >collision - most likely with the host adapter. > > Sure - it is the same drive - I can't access the other one. > but - how do I check - I don't know much about scsi internals. I would say selecting IDs is scsi fundamentals. Each scsi device usualy has 3 to 4 id jumpers which are binary coded to an id. The hostadapter typicaly use id 7. But after reviewing your mail before I noticed that there is no id 0, which could mean that your drive as well the hostadapter is on id 0. As you said it's a new problem I would guess the controller driver failed to use the right ID for itself. Do you have bootlogs in /var/log/messages* from the old OS version? -- B.Walter COSMO-Project http://www.cosmo-project.de ticso@cicely.de Usergroup info@cosmo-project.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Aug 9 9:17:34 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B058337B400 for ; Fri, 9 Aug 2002 09:17:32 -0700 (PDT) Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by mx1.FreeBSD.org (Postfix) with ESMTP id 04C3D43E75 for ; Fri, 9 Aug 2002 09:17:32 -0700 (PDT) (envelope-from ken@panzer.kdm.org) Received: from panzer.kdm.org (localhost [127.0.0.1]) by panzer.kdm.org (8.12.5/8.12.5) with ESMTP id g79GHQKD023615; Fri, 9 Aug 2002 10:17:26 -0600 (MDT) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.12.5/8.12.5/Submit) id g79GHPPB023614; Fri, 9 Aug 2002 10:17:25 -0600 (MDT) (envelope-from ken) Date: Fri, 9 Aug 2002 10:17:25 -0600 From: "Kenneth D. Merry" To: =?iso-8859-1?Q?Jean-fran=E7ois_Dalbosco?= Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: need to write a specific SIM? Message-ID: <20020809101725.A23587@panzer.kdm.org> References: <200208090809.g7989CEu029039@enserg.enserg.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: <200208090809.g7989CEu029039@enserg.enserg.fr>; from jdalbosc@enserg.fr on Fri, Aug 09, 2002 at 10:09:12AM +0200 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, Aug 09, 2002 at 10:09:12 +0200, Jean-françois Dalbosco wrote: > Bonjour c'est encore moi... > > So following to the answer of Nate i was wondering: > > first if i needed to rewrite a personnal SIM for my device which is a > Magnetic Bubble Memory though i have already been able to send > succesfully generic command like 0x00 ( TUR ) READ_6 and one vendor > unique command 0xF0 ( Test MBM ) with the passthrough driver to my > device /dev/da2? No, you don't need to write your own SIM. If you can talk to the device via the passthrough driver, you're fine. > secondly if it is not compulsory to rewrite a SIM which SIM does my > device use at the present time knowing that it is attached to the > passthrough driver? dmesg will tell you, e.g.: da2 at ahc0 bus 0 target 2 lun 0 da2: Fixed Direct Access SCSI-3 device da2: 160.000MB/s transfers (80.000MHz, offset 63, 16bit), Tagged Queueing Enabled da2: 17501MB (35843670 512 byte sectors: 255H 63S/T 2231C) So da2 is on ahc0. camcontrol devlist -v will also show which controller each device is on. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Aug 9 9:22:42 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E5E5A37B400; Fri, 9 Aug 2002 09:22:35 -0700 (PDT) Received: from noe.warszawa.mtl.pl (noe.warszawa.multinet.pl [213.241.3.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 71FEE43E4A; Fri, 9 Aug 2002 09:22:34 -0700 (PDT) (envelope-from mgryszkalis@cerint.pl) Received: by noe.warszawa.mtl.pl (Postfix, from userid 1007) id 5FDCD7DF3A; Fri, 9 Aug 2002 18:22:44 +0200 (CEST) Received: from cerint.pl (systemy237.toya.net.pl [217.113.225.237]) by arka.warszawa.mtl.pl (Postfix) with ESMTP id 987FDEA707; Fri, 9 Aug 2002 18:22:42 +0200 (CEST) Message-ID: <3D53EC4A.30007@cerint.pl> Date: Fri, 09 Aug 2002 18:22:34 +0200 From: Marcin Gryszkalis Organization: Cerint Technology Group User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1b) Gecko/20020806 X-Accept-Language: en-us, en, pl MIME-Version: 1.0 To: freebsd-alpha Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: da driver problem? References: <3D5280F4.8030706@cerint.pl> <20020808152922.A18763@panzer.kdm.org> <3D53BD58.1060600@cerint.pl> <20020809130749.GJ52932@cicely5.cicely.de> <3D53C01A.1050702@cerint.pl> <20020809151159.GV52932@cicely5.cicely.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus: Poczta jest monitorowana oprogramowaniem antywirusowym. Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Bernd Walter wrote: > I would say selecting IDs is scsi fundamentals. > Each scsi device usualy has 3 to 4 id jumpers which are binary > coded to an id. > The hostadapter typicaly use id 7. I didn't change anything inside of the box since I got it (I started with FreeBSD 4.1) and It worked well until I installed 4.6-STABLE. > But after reviewing your mail before I noticed that there is > no id 0, which could mean that your drive as well the hostadapter > is on id 0. > As you said it's a new problem I would guess the controller driver > failed to use the right ID for itself. > Do you have bootlogs in /var/log/messages* from the old OS version? Unfortunately I keep old logs on the second disk (that I cannot access now). I think I'll try to boot old kernels (I have 4.5-STABLE and 4.1-RELEASE) and check messages (I'll be able to do it tomorrow or on monday). regards Marcin -- Marcin Gryszkalis or To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Aug 9 9:34: 2 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 61EB437B400; Fri, 9 Aug 2002 09:33:54 -0700 (PDT) Received: from noe.warszawa.mtl.pl (noe.warszawa.multinet.pl [213.241.3.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id C52F143E5E; Fri, 9 Aug 2002 09:33:53 -0700 (PDT) (envelope-from mgryszkalis@cerint.pl) Received: by noe.warszawa.mtl.pl (Postfix, from userid 1007) id C64937DF3A; Fri, 9 Aug 2002 18:34:03 +0200 (CEST) Received: from cerint.pl (systemy237.toya.net.pl [217.113.225.237]) by arka.warszawa.mtl.pl (Postfix) with ESMTP id 598ABEA707; Fri, 9 Aug 2002 18:34:02 +0200 (CEST) Message-ID: <3D53EEF2.2090602@cerint.pl> Date: Fri, 09 Aug 2002 18:33:54 +0200 From: Marcin Gryszkalis Organization: Cerint Technology Group User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1b) Gecko/20020806 X-Accept-Language: en-us, en, pl MIME-Version: 1.0 To: freebsd-alpha Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: da driver problem? References: <3D5280F4.8030706@cerint.pl> <20020808152922.A18763@panzer.kdm.org> <3D53BD58.1060600@cerint.pl> <20020809130749.GJ52932@cicely5.cicely.de> <3D53C01A.1050702@cerint.pl> <20020809151159.GV52932@cicely5.cicely.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus: Poczta jest monitorowana oprogramowaniem antywirusowym. Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > Do you have bootlogs in /var/log/messages* from the old OS version? I forgot about 'daily' reports :) here's old one: ldah.math.uni.lodz.pl kernel log messages: > Copyright (c) 1992-2000 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD 4.2-BETA #8: Sat Nov 4 23:03:11 CET 2000 > root@ldah.math.uni.lodz.pl:/usr/src/sys/compile/ldah > AlphaStation 500 or 600 (KN20AA) > Digital AlphaStation 500/333, 333MHz > 8192 byte page size, 1 processor. > CPU: EV5 (21164) major=5 minor=0 > OSF PAL rev: 0x1000000020115 > real memory = 64856064 (63336K bytes) > avail memory = 57171968 (55832K bytes) > Preloaded elf kernel "kernel" at 0xfffffc0000672000. > md0: Malloc disk > cia0: ALCOR/ALCOR2, pass 2 > pcib0: <2117x PCI host bus adapter> on cia0 > pci0: on pcib0 > de0: port 0x10100-0x1017f mem 0x82019000-0x8201907f irq 13 at device 6.0 on pci0 > de0: interrupting at CIA irq 13 > de0: DEC 21040 [10Mb/s] pass 2.4 > de0: address 00:00:f8:24:19:eb > pci0: at 8.0 irq 16 > isp0: port 0x10000-0x100ff mem 0x82018000-0x82018fff irq 12 at device 9.0 on pci0 > isp0: interrupting at CIA irq 12 > isp0: invalid NVRAM header > isab0: at device 10.0 on pci0 > isa0: on isab0 > fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 > fdc0: interrupting at ISA irq 6 > fdc0: FIFO enabled, 8 bytes threshold > fd0: <1440-KB 3.5" drive> on fdc0 drive 0 > atkbdc0: at port 0x60,0x64 on isa0 > atkbd0: irq 1 on atkbdc0 > atkbd0: interrupting at ISA irq 1 > psm0: irq 12 on atkbdc0 > psm0: interrupting at ISA irq 12 > psm0: model Generic PS/2 mouse, device ID 0 > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > sc0: on isa0 > sc0: VGA <16 virtual consoles, flags=0x200> > mcclock0: at port 0x70-0x71 on isa0 > sio0 at port 0x3f8-0x3ff irq 4 on isa0 > sio0: type 16550A > sio0: interrupting at ISA irq 4 > sio1: reserved for low-level i/o > ppc0: at port 0x3bc-0x3bf irq 7 on isa0 > ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode > ppi0: on ppbus0 > lpt0: on ppbus0 > lpt0: Polled port > ppc0: interrupting at ISA irq 7 > Timecounter "alpha" frequency 333332018 Hz > IPv6 packet filtering initialized, default to accept, logging limited to 100 packets/entry > IP packet filtering initialized, divert enabled, rule-based forwarding enabled, default to deny, logging limited to 100 packets/entry by default > IP Filter: v3.4.8 initialized. Default = pass all, Logging = enabled > Waiting 15 seconds for SCSI devices to settle > de0: enabling 10baseT port > isp0: 0.0 get user period 0x19 offset 0xc flags 0xfd00 > isp0: 0.0 get current period 0x19 offset 0x0 flags 0xc500 > isp0: 0.0 set current period 0x19 offset 0xc flags 0xfd00 > isp0: 0.6 get user period 0x19 offset 0xc flags 0xfd00 > isp0: 0.6 get current period 0x19 offset 0x0 flags 0xc500 > isp0: 0.6 set current period 0x19 offset 0xc flags 0xdd00 > Mounting root from ufs:/dev/da0a > da1 at isp0 bus 0 target 6 lun 0 > da1: Fixed Direct Access SCSI-2 device > isp0: 0.6 get current period 0x19 offset 0xc flags 0xdd00 > da1: 10.000MB/s transfers (10.000MHz, offset 12), Tagged Queueing Enabled > da1: 4341MB (8890760 512 byte sectors: 255H 63S/T 553C) > da0 at isp0 bus 0 target 0 lun 0 > da0: Fixed Direct Access SCSI-2 device > isp0: 0.0 get current period 0x19 offset 0xc flags 0xfd00 > da0: 20.000MB/s transfers (10.000MHz, offset 12, 16bit), Tagged Queueing Enabled > da0: 4091MB (8380080 512 byte sectors: 255H 63S/T 521C) -- Marcin Gryszkalis or To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Aug 9 9:46: 0 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ED1FA37B400; Fri, 9 Aug 2002 09:45:48 -0700 (PDT) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id DFEC043E42; Fri, 9 Aug 2002 09:45:47 -0700 (PDT) (envelope-from ticso@cicely5.cicely.de) Received: from cicely5.cicely.de (cicely5.cicely.de [IPv6:3ffe:400:8d0:301:200:92ff:fe9b:20e7]) (authenticated bits=0) by srv1.cosmo-project.de (8.12.5/8.12.5) with ESMTP id g79GjVvo055390 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Fri, 9 Aug 2002 18:45:34 +0200 (CEST) (envelope-from ticso@cicely5.cicely.de) Received: from cicely5.cicely.de (localhost [IPv6:::1]) by cicely5.cicely.de (8.12.1/8.12.1) with ESMTP id g79GjUFJ059639 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 9 Aug 2002 18:45:31 +0200 (CEST)?g (envelope-from ticso@cicely5.cicely.de) Received: (from ticso@localhost) by cicely5.cicely.de (8.12.1/8.12.1/Submit) id g79GjTbM059638; Fri, 9 Aug 2002 18:45:29 +0200 (CEST)?g (envelope-from ticso) Date: Fri, 9 Aug 2002 18:45:28 +0200 From: Bernd Walter To: Marcin Gryszkalis Cc: freebsd-alpha , freebsd-scsi@FreeBSD.ORG, Matthew Jacob Subject: Re: da driver problem? Message-ID: <20020809164527.GW52932@cicely5.cicely.de> Reply-To: ticso@cicely.de References: <3D5280F4.8030706@cerint.pl> <20020808152922.A18763@panzer.kdm.org> <3D53BD58.1060600@cerint.pl> <20020809130749.GJ52932@cicely5.cicely.de> <3D53C01A.1050702@cerint.pl> <20020809151159.GV52932@cicely5.cicely.de> <3D53EEF2.2090602@cerint.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D53EEF2.2090602@cerint.pl> X-Operating-System: FreeBSD cicely5.cicely.de 5.0-CURRENT i386 User-Agent: Mutt/1.5.1i Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, Aug 09, 2002 at 06:33:54PM +0200, Marcin Gryszkalis wrote: > >Do you have bootlogs in /var/log/messages* from the old OS version? > > I forgot about 'daily' reports :) > here's old one: > > ldah.math.uni.lodz.pl kernel log messages: > > Copyright (c) 1992-2000 The FreeBSD Project. > > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > > The Regents of the University of California. All rights reserved. > > FreeBSD 4.2-BETA #8: Sat Nov 4 23:03:11 CET 2000 > > root@ldah.math.uni.lodz.pl:/usr/src/sys/compile/ldah > > AlphaStation 500 or 600 (KN20AA) > > Digital AlphaStation 500/333, 333MHz > > 8192 byte page size, 1 processor. > > CPU: EV5 (21164) major=5 minor=0 > > OSF PAL rev: 0x1000000020115 > > real memory = 64856064 (63336K bytes) > > avail memory = 57171968 (55832K bytes) > > Preloaded elf kernel "kernel" at 0xfffffc0000672000. > > md0: Malloc disk > > cia0: ALCOR/ALCOR2, pass 2 > > pcib0: <2117x PCI host bus adapter> on cia0 > > pci0: on pcib0 > > de0: port 0x10100-0x1017f mem > 0x82019000-0x8201907f irq 13 at device 6.0 on pci0 > > de0: interrupting at CIA irq 13 > > de0: DEC 21040 [10Mb/s] pass 2.4 > > de0: address 00:00:f8:24:19:eb > > pci0: at 8.0 irq 16 > > isp0: port 0x10000-0x100ff mem > 0x82018000-0x82018fff irq 12 at device 9.0 on pci0 > > isp0: interrupting at CIA irq 12 > > isp0: invalid NVRAM header This is a good reason for obscure things to happen. Do you have ispfw_load="YES" in /boot/loader.conf? > > isab0: at device 10.0 on pci0 > > isa0: on isab0 > > fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 > > fdc0: interrupting at ISA irq 6 > > fdc0: FIFO enabled, 8 bytes threshold > > fd0: <1440-KB 3.5" drive> on fdc0 drive 0 > > atkbdc0: at port 0x60,0x64 on isa0 > > atkbd0: irq 1 on atkbdc0 > > atkbd0: interrupting at ISA irq 1 > > psm0: irq 12 on atkbdc0 > > psm0: interrupting at ISA irq 12 > > psm0: model Generic PS/2 mouse, device ID 0 > > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > > sc0: on isa0 > > sc0: VGA <16 virtual consoles, flags=0x200> > > mcclock0: at port 0x70-0x71 on isa0 > > sio0 at port 0x3f8-0x3ff irq 4 on isa0 > > sio0: type 16550A > > sio0: interrupting at ISA irq 4 > > sio1: reserved for low-level i/o > > ppc0: at port 0x3bc-0x3bf irq 7 on isa0 > > ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode > > ppi0: on ppbus0 > > lpt0: on ppbus0 > > lpt0: Polled port > > ppc0: interrupting at ISA irq 7 > > Timecounter "alpha" frequency 333332018 Hz > > IPv6 packet filtering initialized, default to accept, logging limited to > 100 packets/entry > > IP packet filtering initialized, divert enabled, rule-based forwarding > enabled, default to deny, logging limited to 100 packets/entry by default > > IP Filter: v3.4.8 initialized. Default = pass all, Logging = enabled > > Waiting 15 seconds for SCSI devices to settle > > de0: enabling 10baseT port > > isp0: 0.0 get user period 0x19 offset 0xc flags 0xfd00 > > isp0: 0.0 get current period 0x19 offset 0x0 flags 0xc500 > > isp0: 0.0 set current period 0x19 offset 0xc flags 0xfd00 > > isp0: 0.6 get user period 0x19 offset 0xc flags 0xfd00 > > isp0: 0.6 get current period 0x19 offset 0x0 flags 0xc500 > > isp0: 0.6 set current period 0x19 offset 0xc flags 0xdd00 > > Mounting root from ufs:/dev/da0a > > da1 at isp0 bus 0 target 6 lun 0 > > da1: Fixed Direct Access SCSI-2 device > > isp0: 0.6 get current period 0x19 offset 0xc flags 0xdd00 > > da1: 10.000MB/s transfers (10.000MHz, offset 12), Tagged Queueing Enabled > > da1: 4341MB (8890760 512 byte sectors: 255H 63S/T 553C) > > da0 at isp0 bus 0 target 0 lun 0 > > da0: Fixed Direct Access SCSI-2 device > > isp0: 0.0 get current period 0x19 offset 0xc flags 0xfd00 > > da0: 20.000MB/s transfers (10.000MHz, offset 12, 16bit), Tagged Queueing > Enabled > > da0: 4091MB (8380080 512 byte sectors: 255H 63S/T 521C) -- B.Walter COSMO-Project http://www.cosmo-project.de ticso@cicely.de Usergroup info@cosmo-project.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Aug 9 12: 1:43 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9A73537B400; Fri, 9 Aug 2002 12:01:38 -0700 (PDT) Received: from noe.warszawa.mtl.pl (noe.warszawa.multinet.pl [213.241.3.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6EDBB43E5E; Fri, 9 Aug 2002 12:01:36 -0700 (PDT) (envelope-from mgryszkalis@cerint.pl) Received: by noe.warszawa.mtl.pl (Postfix, from userid 1007) id 181FC7DF37; Fri, 9 Aug 2002 21:01:46 +0200 (CEST) Received: from cerint.pl (systemy237.toya.net.pl [217.113.225.237]) by arka.warszawa.mtl.pl (Postfix) with ESMTP id 3D464EA77A; Fri, 9 Aug 2002 21:01:39 +0200 (CEST) Message-ID: <3D54118A.7050106@cerint.pl> Date: Fri, 09 Aug 2002 21:01:30 +0200 From: Marcin Gryszkalis Organization: Cerint Technology Group User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1b) Gecko/20020806 X-Accept-Language: en-us, en, pl MIME-Version: 1.0 To: freebsd-scsi@FreeBSD.ORG Cc: freebsd-alpha , Matthew Jacob Subject: Re: da driver problem? References: <3D5280F4.8030706@cerint.pl> <20020808152922.A18763@panzer.kdm.org> <3D53BD58.1060600@cerint.pl> <20020809130749.GJ52932@cicely5.cicely.de> <3D53C01A.1050702@cerint.pl> <20020809151159.GV52932@cicely5.cicely.de> <3D53EEF2.2090602@cerint.pl> <20020809164527.GW52932@cicely5.cicely.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus: Poczta jest monitorowana oprogramowaniem antywirusowym. Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Bernd Walter wrote: >>>isp0: port 0x10000-0x100ff mem >>0x82018000-0x82018fff irq 12 at device 9.0 on pci0 >>>isp0: interrupting at CIA irq 12 >>>isp0: invalid NVRAM header > This is a good reason for obscure things to happen. > Do you have ispfw_load="YES" in /boot/loader.conf? ldah:/boot/# grep -ir "ispfw_load" * defaults/loader.conf:ispfw_load="NO" # Qlogic ISP Firmware "invalid NVRAM header" was always there and as you can see below it makes no problem with disks (at least it didn't). Anyway - is there anything I can do? >>>da1 at isp0 bus 0 target 6 lun 0 >>>da1: Fixed Direct Access SCSI-2 device >>>isp0: 0.6 get current period 0x19 offset 0xc flags 0xdd00 >>>da1: 10.000MB/s transfers (10.000MHz, offset 12), Tagged Queueing Enabled >>>da1: 4341MB (8890760 512 byte sectors: 255H 63S/T 553C) >>>da0 at isp0 bus 0 target 0 lun 0 >>>da0: Fixed Direct Access SCSI-2 device >>>isp0: 0.0 get current period 0x19 offset 0xc flags 0xfd00 >>>da0: 20.000MB/s transfers (10.000MHz, offset 12, 16bit), Tagged Queueing >>>da0: 4091MB (8380080 512 byte sectors: 255H 63S/T 521C) regards marcin -- Marcin Gryszkalis or To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Aug 9 12: 4:47 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CC3F337B400; Fri, 9 Aug 2002 12:04:44 -0700 (PDT) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id E9C6943E4A; Fri, 9 Aug 2002 12:04:43 -0700 (PDT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id PAA07455; Fri, 9 Aug 2002 15:04:42 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id g79J4C505252; Fri, 9 Aug 2002 15:04:12 -0400 (EDT) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15700.4651.993515.112775@grasshopper.cs.duke.edu> Date: Fri, 9 Aug 2002 15:04:11 -0400 (EDT) To: Marcin Gryszkalis Cc: freebsd-scsi@FreeBSD.ORG, freebsd-alpha Subject: Re: da driver problem? In-Reply-To: <3D54118A.7050106@cerint.pl> References: <3D5280F4.8030706@cerint.pl> <20020808152922.A18763@panzer.kdm.org> <3D53BD58.1060600@cerint.pl> <20020809130749.GJ52932@cicely5.cicely.de> <3D53C01A.1050702@cerint.pl> <20020809151159.GV52932@cicely5.cicely.de> <3D53EEF2.2090602@cerint.pl> <20020809164527.GW52932@cicely5.cicely.de> <3D54118A.7050106@cerint.pl> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Marcin Gryszkalis writes: > Bernd Walter wrote: > >>>isp0: port 0x10000-0x100ff mem > >>0x82018000-0x82018fff irq 12 at device 9.0 on pci0 > >>>isp0: interrupting at CIA irq 12 > >>>isp0: invalid NVRAM header > > This is a good reason for obscure things to happen. > > Do you have ispfw_load="YES" in /boot/loader.conf? > > ldah:/boot/# grep -ir "ispfw_load" * > defaults/loader.conf:ispfw_load="NO" # Qlogic ISP Firmware > > "invalid NVRAM header" was always there and as you can see below it > makes no problem with disks (at least it didn't). > > Anyway - is there anything I can do? Put the following line into /boot/loader.conf: ispfw_load="YES" Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Aug 9 12:17: 0 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 38E3037B400 for ; Fri, 9 Aug 2002 12:16:56 -0700 (PDT) Received: from rootlabs.com (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 2370943E72 for ; Fri, 9 Aug 2002 12:16:45 -0700 (PDT) (envelope-from nate@rootlabs.com) Received: (qmail 23625 invoked by uid 1000); 9 Aug 2002 19:16:45 -0000 Date: Fri, 9 Aug 2002 12:16:45 -0700 (PDT) From: Nate Lawson To: Andrew Gallatin Cc: Marcin Gryszkalis , freebsd-scsi@FreeBSD.ORG, freebsd-alpha Subject: Re: da driver problem? In-Reply-To: <15700.4651.993515.112775@grasshopper.cs.duke.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org To be more specific, the Qlogic isp* cards ALWAYS require you to load firmware to give full access to the drive and do anything useful. In the x86 world, the isp boards only have enough code included on board to manage int 13h for bootstrapping the OS and attempting to use them without loading firmware is not defined. With the Qlogic 2xxx boards in particular, NetBSD and FreeBSD won't even boot without loading the firmware (kernel hangs after probing the card). Perhaps a comment should go into GENERIC above the isp entry saying to be sure to enable ispfw_load? Or perhaps the hardware notes that go in the release? -Nate On Fri, 9 Aug 2002, Andrew Gallatin wrote: > Marcin Gryszkalis writes: > > Bernd Walter wrote: > > >>>isp0: port 0x10000-0x100ff mem > > >>0x82018000-0x82018fff irq 12 at device 9.0 on pci0 > > >>>isp0: interrupting at CIA irq 12 > > >>>isp0: invalid NVRAM header > > > This is a good reason for obscure things to happen. > > > Do you have ispfw_load="YES" in /boot/loader.conf? > > > > ldah:/boot/# grep -ir "ispfw_load" * > > defaults/loader.conf:ispfw_load="NO" # Qlogic ISP Firmware > > > > "invalid NVRAM header" was always there and as you can see below it > > makes no problem with disks (at least it didn't). > > > > Anyway - is there anything I can do? > > Put the following line into /boot/loader.conf: > > ispfw_load="YES" > > Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Aug 9 12:25:34 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8A98E37B400; Fri, 9 Aug 2002 12:25:29 -0700 (PDT) Received: from beppo.feral.com (beppo.feral.com [192.67.166.79]) by mx1.FreeBSD.org (Postfix) with ESMTP id C044343E3B; Fri, 9 Aug 2002 12:25:28 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from mailhost.feral.com (mjacob@mailhost.feral.com [192.67.166.1]) by beppo.feral.com (8.11.3/8.11.3) with ESMTP id g79JPMY67966; Fri, 9 Aug 2002 12:25:22 -0700 (PDT) (envelope-from mjacob@feral.com) Date: Fri, 9 Aug 2002 12:25:22 -0700 (PDT) From: Matthew Jacob X-Sender: mjacob@beppo Reply-To: mjacob@feral.com To: Nate Lawson Cc: Andrew Gallatin , Marcin Gryszkalis , freebsd-scsi@FreeBSD.ORG, freebsd-alpha Subject: Re: da driver problem? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, 9 Aug 2002, Nate Lawson wrote: > To be more specific, the Qlogic isp* cards ALWAYS require you to load > firmware to give full access to the drive and do anything useful. In the > x86 world, the isp boards only have enough code included on board to > manage int 13h for bootstrapping the OS and attempting to use them without > loading firmware is not defined. With the Qlogic 2xxx boards in > particular, NetBSD and FreeBSD won't even boot without loading the > firmware (kernel hangs after probing the card). This isn't always the case. Also, if this is the case, where's the PR? Don't start rumours, please. ore precisely, there is f/w in flash that either the BIOS (x86) loads into the card SRAM and restarts the microsequencer. There is no clear spec where that f/w actually *is* in flash else I'd pull it out in the driver and load it myself. This is why in many cases it is really best to load firmware via ispfw. On alphas, SRM loads f/w into SRAM for models it understands. This is even more of a problem because for a Digital thought they knew better about doing isp f/w, so the f/w sets loaded cannot demonstrably be proven to even comply with QLOgic'c f/w interface specs. On sparcs/macs, OBP loads f/w (all SBus isp cards,select 2XXX cards). > > Perhaps a comment should go into GENERIC above the isp entry saying to > be sure to enable ispfw_load? Or perhaps the hardware notes that go in > the release? well, it would be better that: a) The install process puts ispfw on the 3rd floppy b) Only the f/w relevant to a card is pulled in c) freeing up and unloading modules and reclaiming memory actually worked To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Aug 9 12:29:47 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D304337B400; Fri, 9 Aug 2002 12:29:44 -0700 (PDT) Received: from noe.warszawa.mtl.pl (noe.warszawa.multinet.pl [213.241.3.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5499C43E65; Fri, 9 Aug 2002 12:29:44 -0700 (PDT) (envelope-from mgryszkalis@cerint.pl) Received: by noe.warszawa.mtl.pl (Postfix, from userid 1007) id 10BF67DF63; Fri, 9 Aug 2002 21:29:55 +0200 (CEST) Received: from cerint.pl (systemy237.toya.net.pl [217.113.225.237]) by arka.warszawa.mtl.pl (Postfix) with ESMTP id 048B4EA78D; Fri, 9 Aug 2002 21:29:44 +0200 (CEST) Message-ID: <3D54181F.1010309@cerint.pl> Date: Fri, 09 Aug 2002 21:29:35 +0200 From: Marcin Gryszkalis Organization: Cerint Technology Group User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1b) Gecko/20020806 X-Accept-Language: en-us, en, pl MIME-Version: 1.0 To: Nate Lawson Cc: Andrew Gallatin , freebsd-scsi@FreeBSD.ORG, freebsd-alpha Subject: Re: da driver problem? References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus: Poczta jest monitorowana oprogramowaniem antywirusowym. Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Nate Lawson wrote: > To be more specific, the Qlogic isp* cards ALWAYS require you to load > firmware to give full access to the drive and do anything useful. In the > x86 world, the isp boards only have enough code included on board to > manage int 13h for bootstrapping the OS and attempting to use them without > loading firmware is not defined. With the Qlogic 2xxx boards in > particular, NetBSD and FreeBSD won't even boot without loading the > firmware (kernel hangs after probing the card). I *think* I never had this - I didn't have loader.conf - and It worked without problems :) Now I got It but I cannot reboot the box from remote - so I'll test it tomorrow. Or - do you think it would be possible to kldload ispfw and reinitialize the system some magic way (w/o rebooting)? -- Marcin Gryszkalis or To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Aug 9 12:30:17 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A4EE937B400; Fri, 9 Aug 2002 12:30:13 -0700 (PDT) Received: from freebie.xs4all.nl (freebie.xs4all.nl [213.84.32.253]) by mx1.FreeBSD.org (Postfix) with ESMTP id A71E643E75; Fri, 9 Aug 2002 12:30:11 -0700 (PDT) (envelope-from wkb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (localhost [127.0.0.1]) by freebie.xs4all.nl (8.12.5/8.12.2) with ESMTP id g79JU4Fh020063; Fri, 9 Aug 2002 21:30:04 +0200 (CEST) (envelope-from wkb@freebie.xs4all.nl) Received: (from wkb@localhost) by freebie.xs4all.nl (8.12.5/8.12.5/Submit) id g79JU3hs020062; Fri, 9 Aug 2002 21:30:03 +0200 (CEST) Date: Fri, 9 Aug 2002 21:30:03 +0200 From: Wilko Bulte To: Nate Lawson Cc: Andrew Gallatin , Marcin Gryszkalis , freebsd-scsi@FreeBSD.ORG, freebsd-alpha Subject: Re: da driver problem? Message-ID: <20020809213003.A20020@freebie.xs4all.nl> References: <15700.4651.993515.112775@grasshopper.cs.duke.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from nate@root.org on Fri, Aug 09, 2002 at 12:16:45PM -0700 X-OS: FreeBSD 4.6-STABLE X-PGP: finger wilko@freebsd.org Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, Aug 09, 2002 at 12:16:45PM -0700, Nate Lawson wrote: > To be more specific, the Qlogic isp* cards ALWAYS require you to load > firmware to give full access to the drive and do anything useful. In the > x86 world, the isp boards only have enough code included on board to > manage int 13h for bootstrapping the OS and attempting to use them without > loading firmware is not defined. With the Qlogic 2xxx boards in > particular, NetBSD and FreeBSD won't even boot without loading the > firmware (kernel hangs after probing the card). Not true, in a generic sense. It depends on what the card has loaded in its flash as far as f/w goes. > Perhaps a comment should go into GENERIC above the isp entry saying to > be sure to enable ispfw_load? Or perhaps the hardware notes that go in > the release? 'man isp' -- | / o / /_ _ wilko@FreeBSD.org |/|/ / / /( (_) Bulte Arnhem, the Netherlands To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Aug 9 12:32: 9 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BAE0837B400; Fri, 9 Aug 2002 12:32:04 -0700 (PDT) Received: from freebie.xs4all.nl (freebie.xs4all.nl [213.84.32.253]) by mx1.FreeBSD.org (Postfix) with ESMTP id 870C843E6A; Fri, 9 Aug 2002 12:32:03 -0700 (PDT) (envelope-from wkb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (localhost [127.0.0.1]) by freebie.xs4all.nl (8.12.5/8.12.2) with ESMTP id g79JVuFh020089; Fri, 9 Aug 2002 21:31:56 +0200 (CEST) (envelope-from wkb@freebie.xs4all.nl) Received: (from wkb@localhost) by freebie.xs4all.nl (8.12.5/8.12.5/Submit) id g79JVuWX020088; Fri, 9 Aug 2002 21:31:56 +0200 (CEST) Date: Fri, 9 Aug 2002 21:31:56 +0200 From: Wilko Bulte To: Matthew Jacob Cc: Nate Lawson , Andrew Gallatin , Marcin Gryszkalis , freebsd-scsi@FreeBSD.ORG, freebsd-alpha Subject: Re: da driver problem? Message-ID: <20020809213156.B20020@freebie.xs4all.nl> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from mjacob@feral.com on Fri, Aug 09, 2002 at 12:25:22PM -0700 X-OS: FreeBSD 4.6-STABLE X-PGP: finger wilko@freebsd.org Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, Aug 09, 2002 at 12:25:22PM -0700, Matthew Jacob wrote: > > > On Fri, 9 Aug 2002, Nate Lawson wrote: > > > To be more specific, the Qlogic isp* cards ALWAYS require you to load > > firmware to give full access to the drive and do anything useful. In the > > x86 world, the isp boards only have enough code included on board to > > manage int 13h for bootstrapping the OS and attempting to use them without > > loading firmware is not defined. With the Qlogic 2xxx boards in > > particular, NetBSD and FreeBSD won't even boot without loading the > > firmware (kernel hangs after probing the card). > > This isn't always the case. Also, if this is the case, where's the PR? Don't > start rumours, please. > > ore precisely, there is f/w in flash that either the BIOS (x86) loads into > the card SRAM and restarts the microsequencer. There is no clear spec where > that f/w actually *is* in flash else I'd pull it out in the driver and load it > myself. This is why in many cases it is really best to load firmware via > ispfw. > > On alphas, SRM loads f/w into SRAM for models it understands. This is even > more of a problem because for a Digital thought they knew better about doing > isp f/w, so the f/w sets loaded cannot demonstrably be proven to even comply > with QLOgic'c f/w interface specs. Interestingly we always got the firmware from Qlogic. And threw quite a few Qlogic attempts at f/w in the bin before releasing a version. Ah well, ever after flashrom was invented f/w writer have become sloppier... -- | / o / /_ _ wilko@FreeBSD.org |/|/ / / /( (_) Bulte Arnhem, the Netherlands To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Aug 9 12:45:38 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A823737B477; Fri, 9 Aug 2002 12:45:27 -0700 (PDT) Received: from beppo.feral.com (unknown [192.67.166.79]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4B50343E5E; Fri, 9 Aug 2002 12:45:07 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from mailhost.feral.com (mjacob@mailhost.feral.com [192.67.166.1]) by beppo.feral.com (8.11.3/8.11.3) with ESMTP id g79JhaY68181; Fri, 9 Aug 2002 12:43:36 -0700 (PDT) (envelope-from mjacob@feral.com) Date: Fri, 9 Aug 2002 12:43:36 -0700 (PDT) From: Matthew Jacob X-Sender: mjacob@beppo Reply-To: mjacob@feral.com To: Marcin Gryszkalis Cc: Nate Lawson , Andrew Gallatin , freebsd-scsi@FreeBSD.ORG, freebsd-alpha Subject: Re: da driver problem? In-Reply-To: <3D54181F.1010309@cerint.pl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > - so I'll test it tomorrow. > > Or - do you think it would be possible to kldload ispfw and reinitialize > the system some magic way (w/o rebooting)? No, it only checks at startup. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Aug 9 13:51:42 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9055337B401 for ; Fri, 9 Aug 2002 13:51:36 -0700 (PDT) Received: from rootlabs.com (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 635F643E7B for ; Fri, 9 Aug 2002 13:51:35 -0700 (PDT) (envelope-from nate@rootlabs.com) Received: (qmail 23885 invoked by uid 1000); 9 Aug 2002 20:51:32 -0000 Date: Fri, 9 Aug 2002 13:51:32 -0700 (PDT) From: Nate Lawson To: Matthew Jacob Cc: Andrew Gallatin , Marcin Gryszkalis , freebsd-scsi@FreeBSD.ORG, freebsd-alpha Subject: Re: da driver problem? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, 9 Aug 2002, Matthew Jacob wrote: > On Fri, 9 Aug 2002, Nate Lawson wrote: > > > To be more specific, the Qlogic isp* cards ALWAYS require you to load > > firmware to give full access to the drive and do anything useful. In the > > x86 world, the isp boards only have enough code included on board to > > manage int 13h for bootstrapping the OS and attempting to use them without > > loading firmware is not defined. With the Qlogic 2xxx boards in > > particular, NetBSD and FreeBSD won't even boot without loading the > > firmware (kernel hangs after probing the card). > > This isn't always the case. Also, if this is the case, where's the PR? Don't > start rumours, please. I never filed a PR because I assumed this behavior was what was documented in ispfw(4). I don't currently have any isp hw so this may have been fixed after I used the cards (May-Sept 2001). ispfw(4): ... the isp(4) driver will notice that firmware is available to be downloaded onto Qlogic cards (to replace the usually out of date firmware on the cards). This will kick the f/w into getting unstuck. The problem I was referring to was the fact that for my 2100 and 2200, the card would get wedged after printing the probe message if a drive was attached and I didn't load firmware. Causing a LIP didn't help. Loading firmware did work. [good description of qlogic flash deleted] > > Perhaps a comment should go into GENERIC above the isp entry saying to > > be sure to enable ispfw_load? Or perhaps the hardware notes that go in > > the release? > > well, it would be better that: > > a) The install process puts ispfw on the 3rd floppy > > b) Only the f/w relevant to a card is pulled in > > c) freeing up and unloading modules and reclaiming memory actually worked All great suggestions. If b) was part of the probe routine, then ispfw_load could default to YES. -Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message