From owner-freebsd-scsi@FreeBSD.ORG Sun May 6 01:56:00 2007 Return-Path: X-Original-To: freebsd-scsi@freebsd.org Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A610D16A400; Sun, 6 May 2007 01:56:00 +0000 (UTC) (envelope-from mjacob@freebsd.org) Received: from ns1.feral.com (ns1.feral.com [192.67.166.1]) by mx1.freebsd.org (Postfix) with ESMTP id 6EE2C13C448; Sun, 6 May 2007 01:56:00 +0000 (UTC) (envelope-from mjacob@freebsd.org) Received: from ns1.feral.com (localhost [127.0.0.1]) by ns1.feral.com (8.13.8/8.13.8) with ESMTP id l461tqJj031466; Sat, 5 May 2007 18:56:00 -0700 (PDT) (envelope-from mjacob@freebsd.org) Received: from localhost (mjacob@localhost) by ns1.feral.com (8.13.8/8.13.8/Submit) with ESMTP id l461tplw031463; Sat, 5 May 2007 18:55:52 -0700 (PDT) (envelope-from mjacob@freebsd.org) X-Authentication-Warning: ns1.feral.com: mjacob owned process doing -bs Date: Sat, 5 May 2007 18:55:51 -0700 (PDT) From: mjacob@freebsd.org To: Scott Long In-Reply-To: <463CEC79.5030502@pooker.samsco.org> Message-ID: <20070505185532.U31442@ns1.feral.com> References: <20070505112730.H93632@ns1.feral.com> <463CEC79.5030502@pooker.samsco.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-scsi@freebsd.org, mjacob@freebsd.org Subject: Re: MP safe CAM && sparc? X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mjacob@freebsd.org List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 May 2007 01:56:00 -0000 On Sat, 5 May 2007, Scott Long wrote: > mjacob@freebsd.org wrote: >> Anyone tried any of the 'safe' drivers on sparc64 yet? >> > > I haven't tried it myself, but there's no reason why they shouldn't > work. Have you tried? I did, and had problems, but traced them down to my own pointy hat. From owner-freebsd-scsi@FreeBSD.ORG Sun May 6 09:06:58 2007 Return-Path: X-Original-To: scsi@freebsd.org Delivered-To: freebsd-scsi@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5BD5416A408 for ; Sun, 6 May 2007 09:06:58 +0000 (UTC) (envelope-from berni@ask-us.at) Received: from luxus.ask-us.at (luxus.ask-us.at [213.235.218.3]) by mx1.freebsd.org (Postfix) with ESMTP id E7B6613C4B0 for ; Sun, 6 May 2007 09:06:57 +0000 (UTC) (envelope-from berni@ask-us.at) Received: from [192.168.0.129] ([213.129.242.166]) by luxus.ask-us.at with Microsoft SMTPSVC(6.0.3790.1830); Sun, 6 May 2007 11:06:56 +0200 Message-ID: <463D9AAF.4070006@ask-us.at> Date: Sun, 06 May 2007 11:06:55 +0200 From: Bernard Buri User-Agent: Thunderbird 1.5.0.10 (X11/20070309) MIME-Version: 1.0 To: Scott Long References: <4628E0DE.2090103@samsco.org> <46290AC6.9020608@ask-us.at> <46292245.3030900@samsco.org> In-Reply-To: <46292245.3030900@samsco.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 May 2007 09:06:56.0086 (UTC) FILETIME=[E53C1760:01C78FBD] Cc: scsi@freebsd.org Subject: Re: Upcoming plans for CAM X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 May 2007 09:06:58 -0000 Scott Long wrote: > Bernard Buri wrote: >> Scott Long wrote: >>> All, >>> >>> Now that the MPSAFE work is mostly done and settled, it's time to move >>> onto the next phase of the overall work. >>> >> this is great news! >> I've been working with the CAM layer in my last project, and I loved >> it. It is the most advanced scsi stack I've seen, so I'm glad it gets >> some refinement now. >> >>> ... >>> SATA and IDE transports, ATA protocol >>> ------------------------------------- >>> >>> The transport modularization work described above will allow non-SCSI >>> transports to be easily added. So, the next step is the long-promised >>> unification with IDE and SATA. Instead of hacks like atapicam and >>> atacam that try to force IDE/SATA into the SCSI model, a whole new >>> subtransport will be written that understands the topology and nature of >>> the devices, as well as natively understanding the ATA command set. >>> >>> There are still some interesting design questions that need to be >>> answered here. SATA controllers essentially use a star topology instead >>> of a bus topology. So does it make sense to treat all devices as each >>> having a private bus, or is it better to have a single virtual bus? >>> Also, ATAPI devices basically speak the SCSI protocol so they'll attach >>> to things like the 'cd' driver, but ATA disks speak ATA, which is very >>> different from SCSI. Should they get their own unique peripheral >>> device, or should they be part of the 'da' device? If they get their >>> own peripheral device, should they still generate '/dev/da' device >>> nodes, or should they retain the current '/dev/ad' naming? >>> >> I think that for the user, the device name doesn't really make a >> difference. Like with network interface cards, it is not a problem >> that some of them show up as fxp*, while others show up as myk*. As >> long as there is not a separate fxpconfig and mykconfig tool. >> >> I think for the way cam is desigend right now, it is more intuitive to >> have separate device names. >> >> In fact, I don't know much about ATA disks. I recognized recently, >> that SATA disks show up as /dev/sdX on linux while PATA disks show up >> as /dev/hdX. And SATA disks are said to be compatible to serial >> attached scsi. Does it mean that only PATA disks will be /dev/ad* ? >> > > First of all, a distinction needs to be recognized between the transport > and the protocol. The transport basically describes how the device is > connected to the system. It could be a SATA bus, it could be a SAS > expander, it could be a parallel SCSI bus, etc. The protocol describes > what language the device speaks. That could be SBC (SCSI Block > commands), MMC, ATA, etc. Both IDE and SATA disks speak the ATA command > protocol, regardless of how they are attached to the system. However, > SATA disks can be on a SATA transport or on a SAS transport. The > changes I'm proposing address exactly this; no longer will CAM be purely > parallel SCSI specific with hacks to support other things, it'll > recognize the different transports and protocols and allow them to be > mixed together in whatever way the SIM allows. > > On the Linux side of things, they're basically kinda sorta doing the > same thing, though less elegantly. They wrote a SATA shim for SCSI a > few years ago (libata), and are now in the process of trying to expand > that to do the same modularization of the transport that I'm proposing. > However, they're stopping at only supporting SATA under this new scheme, > leaving all IDE to the old hd driver. I intend to support IDE since > it's still a very common transport, especially for CDROMs. > > As for the device naming issue, one of the original intentions of CAM > was to unifying the naming scheme. A disk should be a disk, it > shouldn't matter what the transport or protocol is. Those are details > that should get handled transparently. At the same time, the situation > in linux is showing that users are getting unhappy with traditional > device names changing. Linux is making it harder than it needs to be > because of how they name IDE CDROMs, but that's baggage that is unique > to Linux, not FreeBSD. But, it's still a consideration that should not > be overlooked. > > Scott Ok, but I think currently, there is no peripheral device driver that really handles fundamentally different protocols right now ? One example: The ch driver handles one protocol (media changer). I did work with cd jukeboxes and wrote my own drivers, using the pass driver. Though there are some differences (quirks), all these jukeboxes are talking the same protocol. On the other hand, there is another protocol for LUN based cd changers that are not supported by my code because they talk a fundamentally different protocol. With CAM, it's the same: ch driver handles "multi-target" changers and cd driver handles "multi-lun" changers. The impression I have (concerning CAM) is that: One SCSI Peripheral Device Type (Standard Inquiry Data) gets one peripheral device driver: 0x00 = da, 0x01 = sa, 0x05 = cd, ... The impression I have (concerning SCSI) is that: One SCSI Peripheral Device Type (Standard Inquiry Data) corresponds to one "set of protocols", the device is supposed to talk. I think the main question for the non-kernel-developer (me) concerning the integration of (S)ATA disks into CAM is: Would it even be possible to work with ATA disk commands via the cam(3) API ? I think if it is physically possible to transport SATA disk commands via SAS, it should definitely be possible to use the cam(3) API to send these commands (via pass). For this, it doesn't really matter which peripheral drivers are attached to the device beside the pass driver. Whether the da driver handles (S)ATA commands directly is only a matter of modularization, but I agree now, that the (S)ATA disk should get a /dev/daX device entry. From owner-freebsd-scsi@FreeBSD.ORG Sun May 6 14:48:24 2007 Return-Path: X-Original-To: scsi@freebsd.org Delivered-To: freebsd-scsi@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3877E16A402 for ; Sun, 6 May 2007 14:48:24 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id A8FF013C4B9 for ; Sun, 6 May 2007 14:48:23 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.samsco.home (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.8/8.13.8) with ESMTP id l46ENcUR083866; Sun, 6 May 2007 08:23:39 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <463DE4E7.1070506@samsco.org> Date: Sun, 06 May 2007 08:23:35 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.2pre) Gecko/20070111 SeaMonkey/1.1 MIME-Version: 1.0 To: Bernard Buri References: <4628E0DE.2090103@samsco.org> <46290AC6.9020608@ask-us.at> <46292245.3030900@samsco.org> <463D9AAF.4070006@ask-us.at> In-Reply-To: <463D9AAF.4070006@ask-us.at> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (pooker.samsco.org [168.103.85.57]); Sun, 06 May 2007 08:23:39 -0600 (MDT) X-Spam-Status: No, score=-1.4 required=5.5 tests=ALL_TRUSTED autolearn=failed version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: scsi@freebsd.org Subject: Re: Upcoming plans for CAM X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 May 2007 14:48:24 -0000 Bernard Buri wrote: > Scott Long wrote: >> Bernard Buri wrote: >>> Scott Long wrote: >>>> All, >>>> >>>> Now that the MPSAFE work is mostly done and settled, it's time to move >>>> onto the next phase of the overall work. >>>> >>> this is great news! >>> I've been working with the CAM layer in my last project, and I loved >>> it. It is the most advanced scsi stack I've seen, so I'm glad it gets >>> some refinement now. >>> >>>> ... >>>> SATA and IDE transports, ATA protocol >>>> ------------------------------------- >>>> >>>> The transport modularization work described above will allow non-SCSI >>>> transports to be easily added. So, the next step is the long-promised >>>> unification with IDE and SATA. Instead of hacks like atapicam and >>>> atacam that try to force IDE/SATA into the SCSI model, a whole new >>>> subtransport will be written that understands the topology and >>>> nature of >>>> the devices, as well as natively understanding the ATA command set. >>>> >>>> There are still some interesting design questions that need to be >>>> answered here. SATA controllers essentially use a star topology >>>> instead >>>> of a bus topology. So does it make sense to treat all devices as each >>>> having a private bus, or is it better to have a single virtual bus? >>>> Also, ATAPI devices basically speak the SCSI protocol so they'll attach >>>> to things like the 'cd' driver, but ATA disks speak ATA, which is very >>>> different from SCSI. Should they get their own unique peripheral >>>> device, or should they be part of the 'da' device? If they get their >>>> own peripheral device, should they still generate '/dev/da' device >>>> nodes, or should they retain the current '/dev/ad' naming? >>>> >>> I think that for the user, the device name doesn't really make a >>> difference. Like with network interface cards, it is not a problem >>> that some of them show up as fxp*, while others show up as myk*. As >>> long as there is not a separate fxpconfig and mykconfig tool. >>> >>> I think for the way cam is desigend right now, it is more intuitive >>> to have separate device names. >>> >>> In fact, I don't know much about ATA disks. I recognized recently, >>> that SATA disks show up as /dev/sdX on linux while PATA disks show up >>> as /dev/hdX. And SATA disks are said to be compatible to serial >>> attached scsi. Does it mean that only PATA disks will be /dev/ad* ? >>> >> >> First of all, a distinction needs to be recognized between the transport >> and the protocol. The transport basically describes how the device is >> connected to the system. It could be a SATA bus, it could be a SAS >> expander, it could be a parallel SCSI bus, etc. The protocol describes >> what language the device speaks. That could be SBC (SCSI Block >> commands), MMC, ATA, etc. Both IDE and SATA disks speak the ATA command >> protocol, regardless of how they are attached to the system. However, >> SATA disks can be on a SATA transport or on a SAS transport. The >> changes I'm proposing address exactly this; no longer will CAM be purely >> parallel SCSI specific with hacks to support other things, it'll >> recognize the different transports and protocols and allow them to be >> mixed together in whatever way the SIM allows. >> >> On the Linux side of things, they're basically kinda sorta doing the >> same thing, though less elegantly. They wrote a SATA shim for SCSI a >> few years ago (libata), and are now in the process of trying to expand >> that to do the same modularization of the transport that I'm proposing. >> However, they're stopping at only supporting SATA under this new scheme, >> leaving all IDE to the old hd driver. I intend to support IDE since >> it's still a very common transport, especially for CDROMs. >> >> As for the device naming issue, one of the original intentions of CAM >> was to unifying the naming scheme. A disk should be a disk, it >> shouldn't matter what the transport or protocol is. Those are details >> that should get handled transparently. At the same time, the situation >> in linux is showing that users are getting unhappy with traditional >> device names changing. Linux is making it harder than it needs to be >> because of how they name IDE CDROMs, but that's baggage that is unique >> to Linux, not FreeBSD. But, it's still a consideration that should not >> be overlooked. >> >> Scott > > Ok, but I think currently, there is no peripheral device driver that > really handles fundamentally different protocols right now ? > > One example: The ch driver handles one protocol (media changer). I did > work with cd jukeboxes and wrote my own drivers, using the pass driver. > Though there are some differences (quirks), all these jukeboxes are > talking the same protocol. > > On the other hand, there is another protocol for LUN based cd changers > that are not supported by my code because they talk a fundamentally > different protocol. > > With CAM, it's the same: ch driver handles "multi-target" changers and > cd driver handles "multi-lun" changers. > > The impression I have (concerning CAM) is that: One SCSI Peripheral > Device Type (Standard Inquiry Data) gets one peripheral device driver: > 0x00 = da, 0x01 = sa, 0x05 = cd, ... > > The impression I have (concerning SCSI) is that: One SCSI Peripheral > Device Type (Standard Inquiry Data) corresponds to one "set of > protocols", the device is supposed to talk. > > I think the main question for the non-kernel-developer (me) concerning > the integration of (S)ATA disks into CAM is: > > Would it even be possible to work with ATA disk commands via the cam(3) > API ? > > I think if it is physically possible to transport SATA disk commands via > SAS, it should definitely be possible to use the cam(3) API to send > these commands (via pass). > > For this, it doesn't really matter which peripheral drivers are attached > to the device beside the pass driver. Whether the da driver handles > (S)ATA commands directly is only a matter of modularization, but I agree > now, that the (S)ATA disk should get a /dev/daX device entry. > > Yes, a new CCB will be created to encapsulate ATA commands, analogous to how the XPT_SCSI_IO CCB works today. Some of the other CCBs that have SCSI-specific info in them will also be extended or augmented to accommodate other protocols and transports. Scott From owner-freebsd-scsi@FreeBSD.ORG Sun May 6 17:04:02 2007 Return-Path: X-Original-To: scsi@freebsd.org Delivered-To: freebsd-scsi@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AD85916A406 for ; Sun, 6 May 2007 17:04:02 +0000 (UTC) (envelope-from lydianconcepts@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.228]) by mx1.freebsd.org (Postfix) with ESMTP id 58E5213C483 for ; Sun, 6 May 2007 17:04:02 +0000 (UTC) (envelope-from lydianconcepts@gmail.com) Received: by nz-out-0506.google.com with SMTP id s1so1397904nze for ; Sun, 06 May 2007 10:04:01 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=dlTV5/Ru94Fp4c+35ct5Qw1SPq/tqeMIZG1zpKVk9571a2joA5Jvyd+S48N8NVOsifFbhLLKKpW1gBXiOJBcLWWA2ZVy20uX4CHJd97ZLeiAoXK6OwSGMyZT0cxBTv+oM9wFqLmEpMPXsHuyadBrMLFUKtp2LSGq8FjYaolXuag= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=MkRV7aAUEG0H9F1CsH2qKHlx7vwx+GrATvohbiScVJBdred5d8bYGVo+7tKKU5OiIUaOZHPRAjiKImRj8bPBCqHhP2lwYSu+zm5/PFTiYtR4Vidzycgbu/16uMcG/4l5z0fT893CnD4/8TT8tpDQj7QOfndba7p3Cy1NzCa4b/g= Received: by 10.115.92.2 with SMTP id u2mr1819377wal.1178471041242; Sun, 06 May 2007 10:04:01 -0700 (PDT) Received: by 10.114.25.18 with HTTP; Sun, 6 May 2007 10:04:01 -0700 (PDT) Message-ID: <7579f7fb0705061004p2c460887w227aad91795604cd@mail.gmail.com> Date: Sun, 6 May 2007 10:04:01 -0700 From: "Matthew Jacob" To: "Scott Long" In-Reply-To: <463DE4E7.1070506@samsco.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4628E0DE.2090103@samsco.org> <46290AC6.9020608@ask-us.at> <46292245.3030900@samsco.org> <463D9AAF.4070006@ask-us.at> <463DE4E7.1070506@samsco.org> Cc: Bernard Buri , scsi@freebsd.org Subject: Re: Upcoming plans for CAM X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 May 2007 17:04:02 -0000 A couple of comments here from me...... a) Other than architectural cleanliness, what advantages to FreeBSD will accrue to replacing the ata driver with CAM access? b) The NEW_TRAN code stuff is a way (not necessarily the cleanest) to try and be able to carry transport related metadata related to a periph. By and large the periph driver doesn't need to know transport related details. The exceptions to this are quirks which can only be safely derived from transport types and transport related values and identifiers that system management (or GEOM0 wants to know about (and really can only ask the periph driver about). c) All of #b is orthogonal to whether you have one periph driver or multiple periph drivers for the same fundamental 'type'. Perhaps the Win2K approach of allowing for selective binding (filter drivers) might be appropriate and would extend the current 'main' periph driver (e.g., "sa") plus the pass driver. d) Don't expect that ATA specific commands will just automatically tunnel, no matter what CAM changes are made. Different direct SATA controllers may have different requirements for being able to do arbitrary non-read/write commands. Tunneling HBAs (like mpt(4)) don't support the ATA passthrough CDB at all and instead require a special request structure. just a few random comments.... From owner-freebsd-scsi@FreeBSD.ORG Mon May 7 01:19:14 2007 Return-Path: X-Original-To: scsi@freebsd.org Delivered-To: freebsd-scsi@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6308716A402 for ; Mon, 7 May 2007 01:19:14 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 05B7813C448 for ; Mon, 7 May 2007 01:19:13 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.samsco.home (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.8/8.13.8) with ESMTP id l471HfZw086629; Sun, 6 May 2007 19:17:42 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <463E7E32.2030603@samsco.org> Date: Sun, 06 May 2007 19:17:38 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.2pre) Gecko/20070111 SeaMonkey/1.1 MIME-Version: 1.0 To: Matthew Jacob References: <4628E0DE.2090103@samsco.org> <46290AC6.9020608@ask-us.at> <46292245.3030900@samsco.org> <463D9AAF.4070006@ask-us.at> <463DE4E7.1070506@samsco.org> <7579f7fb0705061004p2c460887w227aad91795604cd@mail.gmail.com> In-Reply-To: <7579f7fb0705061004p2c460887w227aad91795604cd@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (pooker.samsco.org [168.103.85.57]); Sun, 06 May 2007 19:17:42 -0600 (MDT) X-Spam-Status: No, score=-1.4 required=5.5 tests=ALL_TRUSTED autolearn=failed version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: Bernard Buri , scsi@freebsd.org Subject: Re: Upcoming plans for CAM X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2007 01:19:14 -0000 Matthew Jacob wrote: > A couple of comments here from me...... > > a) Other than architectural cleanliness, what advantages to FreeBSD > will accrue to replacing the ata driver with CAM access? SAS controllers that expose SATA devices through STP need the upper SCSI layers to understand ATA. MPT is a bit unique in that it hides the STP, SATA, and ATA details and pretends that all the world is SCSI/SAS (for normal operation, I know that there's a special passthrough mode), but many other controllers do not. Secondly, I have plans for more transport independence than just ATA/SATA. iSCSI, SAS, and FC can all benefit from not being treated like SPI. ATA/SATA just provides a quick and high-bang-for-buck demonstration of the merit splitting up the transport and protocol support in CAM. There are other reasons as well that are better discussed in private. > > b) The NEW_TRAN code stuff is a way (not necessarily the cleanest) to > try and be able to carry transport related metadata related to a > periph. By and large the periph driver doesn't need to know transport > related details. The exceptions to this are quirks which can only be > safely derived from transport types and transport related values and > identifiers that system management (or GEOM0 wants to know about (and > really can only ask the periph driver about). My intention is to continue to use and extend the NEW_TRAN code. Transport details that need to be worked out involve things like the GET_TRANS and SET_TRANS operations. I'm still thinking through that in terms of cleanliness in the periphs. > > c) All of #b is orthogonal to whether you have one periph driver or > multiple periph drivers for the same fundamental 'type'. Perhaps the > Win2K approach of allowing for selective binding (filter drivers) > might be appropriate and would extend the current 'main' periph driver > (e.g., "sa") plus the pass driver. Right now, just about any periph can attach to a device. The pass driver isn't really a special case, it just allows itself to attach to all devices, whereas the other periphs look at the INQ info and are selective. I plan to allow this to continue. I don't know a whole lot about how filter drivers work in Windows, though. Do the filters stack on top of each other, or are they all peers on top of the same device? It might be interesting to better encapsulate the periph API and allow periphs to be loaded as modules (something that is close to working already). If filters are peers in Windows, so Windows provide any arbitration or protection between peers? > > d) Don't expect that ATA specific commands will just automatically > tunnel, no matter what CAM changes are made. Different direct SATA > controllers may have different requirements for being able to do > arbitrary non-read/write commands. Tunneling HBAs (like mpt(4)) don't > support the ATA passthrough CDB at all and instead require a special > request structure. If you're talking about STP, then that's basically the kind of thing that SIMs will have to support on their own. The periph will send an XPT_SCSI_IO or XPT_SATA_IO (or whatever other protocols come along) CCB to the SIM, and it'll be up to the SIM to either accept the CCB or not. The encapsulation details will be left to the SIM. Helper functions might be developed for common schemes like STP, just like there are helper functions for SBP now. Specifically for SATA controllers, all I'm expecting the driver to support is the IDENTIFY command and the various basic read/write commands. I don't know of any standard way for an ATA controller to support ATAPI without supporting the PACKET command, but that might be a detail left to the SIM anyways, I don't know yet. These are just my random thoughts as well, so don't take any oversights or misunderstandings from me as deliberate =-) Scott From owner-freebsd-scsi@FreeBSD.ORG Mon May 7 11:08:45 2007 Return-Path: X-Original-To: freebsd-scsi@FreeBSD.org Delivered-To: freebsd-scsi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 889D516A47E for ; Mon, 7 May 2007 11:08:45 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id 7390D13C459 for ; Mon, 7 May 2007 11:08:45 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id l47B8j2j078782 for ; Mon, 7 May 2007 11:08:45 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l47B8id5078778 for freebsd-scsi@FreeBSD.org; Mon, 7 May 2007 11:08:44 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 7 May 2007 11:08:44 GMT Message-Id: <200705071108.l47B8id5078778@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: linimon set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-scsi@FreeBSD.org Cc: Subject: Current problem reports assigned to you X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2007 11:08:45 -0000 Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/39388 scsi ncr/sym drivers fail with 53c810 and more than 256MB m o kern/40895 scsi wierd kernel / device driver bug o kern/52638 scsi [panic] SCSI U320 on SMP server won't run faster than s kern/57398 scsi [mly] Current fails to install on mly(4) based RAID di o kern/60598 scsi wire down of scsi devices conflicts with config o kern/60641 scsi [sym] Sporadic SCSI bus resets with 53C810 under load s kern/61165 scsi [panic] kernel page fault after calling cam_send_ccb o kern/74627 scsi [ahc] [hang] Adaptec 2940U2W Can't boot 5.3 o kern/81887 scsi [aac] Adaptec SCSI 2130S aac0: GetDeviceProbeInfo comm o kern/90282 scsi [sym] SCSI bus resets cause loss of ch device o kern/92798 scsi [ahc] SCSI problem with timeouts o kern/93128 scsi [sym] FreeBSD 6.1 BETA 1 has problems with Symbios/LSI o kern/94838 scsi Kernel panic while mounting SD card with lock switch o o kern/99954 scsi [ahc] reading from DVD failes on 6.x (regression) o kern/110847 scsi [ahd] Tyan U320 onboard problem with more than 3 disks 15 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/23314 scsi aic driver fails to detect Adaptec 1520B unless PnP is o kern/35234 scsi World access to /dev/pass? (for scanner) requires acce o kern/38828 scsi [feature request] DPT PM2012B/90 doesn't work o kern/44587 scsi dev/dpt/dpt.h is missing defines required for DPT_HAND o kern/76178 scsi [ahd] Problem with ahd and large SCSI Raid system o kern/96133 scsi [scsi] [patch] add scsi quirk for joyfly 128mb flash u o kern/103702 scsi [cam] [patch] ChipsBnk: Unsupported USB memory stick 7 problems total. From owner-freebsd-scsi@FreeBSD.ORG Thu May 10 15:07:24 2007 Return-Path: X-Original-To: freebsd-scsi@freebsd.org Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A236716A405; Thu, 10 May 2007 15:07:24 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 5C14813C45B; Thu, 10 May 2007 15:07:24 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.samsco.home (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.8/8.13.8) with ESMTP id l4AF7KeG017785; Thu, 10 May 2007 09:07:20 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <46433521.5080800@samsco.org> Date: Thu, 10 May 2007 09:07:13 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.2pre) Gecko/20070111 SeaMonkey/1.1 MIME-Version: 1.0 To: Pawel Jakub Dawidek References: <20070505182849.GC16398@garage.freebsd.pl> In-Reply-To: <20070505182849.GC16398@garage.freebsd.pl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (pooker.samsco.org [168.103.85.57]); Thu, 10 May 2007 09:07:20 -0600 (MDT) X-Spam-Status: No, score=-1.4 required=5.5 tests=ALL_TRUSTED autolearn=failed version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: freebsd-scsi@freebsd.org Subject: Re: SCSI disk serial number. X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2007 15:07:24 -0000 Pawel Jakub Dawidek wrote: > Hi. > > Can someone confirm this is the right thing to do to get SCSI disk > serial number? > > http://people.freebsd.org/~pjd/patches/scsi_da_ident.patch > > Thanks in advance! > > Can someone help me with other drivers? > The serial number that CAM obtains comes from a page 0x80 inquiry. It is known to be rather unreliable in its uniqueness. The SCSI spec allows the target to return a non-zero length of all 0x20 characters if it so desires. Most applications that need a unique drive identifier try to obtain the WWN from page 0x83 instead, and fall back to hueristics with page 0x80 if that fails. Scott From owner-freebsd-scsi@FreeBSD.ORG Sat May 12 11:03:46 2007 Return-Path: X-Original-To: freebsd-scsi@FreeBSD.org Delivered-To: freebsd-scsi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5E89D16A400; Sat, 12 May 2007 11:03:46 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.freebsd.org (Postfix) with ESMTP id EF3D113C43E; Sat, 12 May 2007 11:03:45 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 0F45048807; Sat, 12 May 2007 13:03:44 +0200 (CEST) Received: from localhost (pjd.wheel.pl [10.0.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 1A88E487F0; Sat, 12 May 2007 13:03:39 +0200 (CEST) Date: Sat, 12 May 2007 13:03:38 +0200 From: Pawel Jakub Dawidek To: freebsd-scsi@FreeBSD.org Message-ID: <20070512110338.GA88520@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FCuugMFkClbJLl1L" Content-Disposition: inline X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 User-Agent: mutt-ng/devel-r804 (FreeBSD) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.9 required=3.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: Subject: isp(4) mutex recursion. X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 May 2007 11:03:46 -0000 --FCuugMFkClbJLl1L Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I've this panic on isp.ko load with recent current: isp0: port 0x3000-0x30ff mem 0xfc400000= -0xfc400fff irq 27 at device 4.0 on pci2 registered firmware set isp0: [ITHREAD] isp0: Board Type 2300, Chip Revision 0x1, loaded F/W Revision 3.3.19 panic: _mtx_lock_sleep: recursed on non-recursive mutex isp @ /usr/home/src= /HEAD/src/sys/modules/isp/../../dev/isp/isp_freebsd.c:688 cpuid =3D 1 KDB: enter: panic [thread pid 560 tid 100030 ] Stopped at kdb_enter+0x2b: nop db> tr Tracing pid 560 tid 100030 td 0xc36ee870 kdb_enter(c06022ed) at kdb_enter+0x2b panic(c06014aa,c3c40298,c3c3fb2b,2b0,c04c636f,...) at panic+0x11c _mtx_lock_sleep(c3778690,c36ee870,0,c3c3fb2b,2b0) at _mtx_lock_sleep+0x3a _mtx_lock_flags(c3778690,0,c3c3fb2b,2b0,0,...) at _mtx_lock_flags+0x94 isp_intr_enable(c3778600,c0671a60,0,c0604304,47,...) at isp_intr_enable+0x20 run_interrupt_driven_config_hooks(0) at run_interrupt_driven_config_hooks+0= x43 config_intrhook_establish(c3778638,c3778638,c3778690,3e5b3000,0,...) at con= fig_intrhook_establish+0xb9 isp_attach(c3778600,c05f7a2a,1,c3c41560,30,...) at isp_attach+0x81 isp_pci_attach(c3789680) at isp_pci_attach+0x127d device_attach(c3789680,c3789680,c3789680,0,c37e4600,...) at device_attach+0= x58 device_probe_and_attach(c3789680,c3789680,c37e4600) at device_probe_and_att= ach+0xe0 pci_driver_added(c3789700,c3c414b0) at pci_driver_added+0xd1 devclass_add_driver(c36dac00,c3c414b0) at devclass_add_driver+0xd5 driver_module_handler(c3b152c0,0,c3c4149c,c066ca10,c0601132,7b) at driver_m= odule_handler+0x59 module_register_init(c3c41490) at module_register_init+0x66 linker_file_sysinit(c3bdd100,c3bdd100,c066c564,c05ffa8f,196,...) at linker_= file_sysinit+0x9d linker_load_file(c383a520,e2296c20) at linker_load_file+0x102 linker_load_module(0,c37e6000,0,0,e2296c58,c066c564,c05ffa8f,364) at linker= _load_module+0xdb kern_kldload(c36ee870,c37e6000,e2296c7c) at kern_kldload+0x92 kldload(c36ee870,e2296d00) at kldload+0x4f syscall(e2296d38) at syscall+0x242 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (304, FreeBSD ELF32, kldload), eip =3D 0x280c17ab, esp =3D 0xbfbfec1c, ebp =3D 0xbfbfec58 --- --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --FCuugMFkClbJLl1L Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFGRZ8KForvXbEpPzQRAinCAKCGcqSLRuZ7K5Cwh/iLpWdmHBKKGgCg246l EU4f9YNvyhwXuQZVW1jKxik= =CtF1 -----END PGP SIGNATURE----- --FCuugMFkClbJLl1L-- From owner-freebsd-scsi@FreeBSD.ORG Sat May 12 11:08:11 2007 Return-Path: X-Original-To: freebsd-scsi@FreeBSD.org Delivered-To: freebsd-scsi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4827316A407 for ; Sat, 12 May 2007 11:08:11 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.freebsd.org (Postfix) with ESMTP id B860313C45B for ; Sat, 12 May 2007 11:08:10 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id B4DA7487F3; Sat, 12 May 2007 13:08:09 +0200 (CEST) Received: from localhost (pjd.wheel.pl [10.0.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 7BCAF45683 for ; Sat, 12 May 2007 13:08:03 +0200 (CEST) Date: Sat, 12 May 2007 13:08:03 +0200 From: Pawel Jakub Dawidek To: freebsd-scsi@FreeBSD.org Message-ID: <20070512110802.GB88520@garage.freebsd.pl> References: <20070512110338.GA88520@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7iMSBzlTiPOCCT2k" Content-Disposition: inline In-Reply-To: <20070512110338.GA88520@garage.freebsd.pl> X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 User-Agent: mutt-ng/devel-r804 (FreeBSD) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.9 required=3.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: Subject: Re: Another isp(4) panic. X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 May 2007 11:08:11 -0000 --7iMSBzlTiPOCCT2k Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable It not always happens: da1 at isp0 bus 0 target 1 lun 0 da0 at isp0 bus 0 target 0 lun 0 da5 at isp0 bus 0 target 5 lun 0 da4 at isp0 bus 0 target 4 lun 0 da2 at isp0 bus 0 target 2 lun 0 da3 at isp0 bus 0 target 3 lun 0 da6 at isp0 bus 0 target 6 lun 0 da7 at isp0 bus 0 target 7 lun 0 da8 at isp0 bus 0 target 8 lun 0 da9 at isp0 bus 0 target 9 lun 0 da10 at isp0 bus 0 target 10 lun 0 panic: vm_fault: fault on nofault entry, addr: deadc000 cpuid =3D 0 KDB: enter: panic [thread pid 7 tid 100009 ] Stopped at kdb_enter+0x2b: nop db> tr Tracing pid 7 tid 100009 td 0xc36eb000 kdb_enter(c06022ed) at kdb_enter+0x2b panic(c0617a36,deadc000,0,0,676f6c51,...) at panic+0x11c vm_fault(c0c71000,deadc000,1,0) at vm_fault+0x1d9 trap_pfault(e2251934,0,deadc0f2) at trap_pfault+0x137 trap(e2251934) at trap+0x3de calltrap() at calltrap+0x6 --- trap 0xc, eip =3D 0xc043472a, esp =3D 0xe2251974, ebp =3D 0xe2251bf4 --- xptsetasyncfunc(c3b51a00,c3bc8070,e2251c20,c0434522,c3b51a00,...) at xptset= asyncfunc+0x26 xptdefdevicefunc(c3b51a00,e2251c9c) at xptdefdevicefunc+0x15 xptdevicetraverse(c383c940,0,c0434670,e2251c9c,e2251c54,...) at xptdevicetr= averse+0x2a xptdeftargetfunc(c383c940,e2251c9c) at xptdeftargetfunc+0x26 xpttargettraverse(c37e89c0,0,c0434648,e2251c9c,e2251c88,...) at xpttargettr= averse+0x2b xptdefbusfunc(c37e89c0,e2251c9c,c383e020,80,c3bc8070,...) at xptdefbusfunc+= 0x26 xptbustraverse(0,c0434620,e2251c9c,2,c0434704,...) at xptbustraverse+0x76 xpt_for_all_devices(c0434704,c3bc8070) at xpt_for_all_devices+0x29 xpt_action_sasync_cb(c383e020,1) at xpt_action_sasync_cb+0x20 taskqueue_run(c373e000) at taskqueue_run+0xc8 taskqueue_thread_loop(c0673370,e2251d38) at taskqueue_thread_loop+0x4a fork_exit(c04d6a3c,c0673370,e2251d38) at fork_exit+0xac fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip =3D 0, esp =3D 0xe2251d70, ebp =3D 0 --- --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --7iMSBzlTiPOCCT2k Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFGRaASForvXbEpPzQRAjDPAKCN08+Ca5WvJq1RkQQtAWZcQfV+tgCfVPqH ErmnlF4C2YEOzSfdbOBhsdo= =7a/C -----END PGP SIGNATURE----- --7iMSBzlTiPOCCT2k-- From owner-freebsd-scsi@FreeBSD.ORG Sat May 12 15:41:20 2007 Return-Path: X-Original-To: freebsd-scsi@freebsd.org Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B66E816A404; Sat, 12 May 2007 15:41:20 +0000 (UTC) (envelope-from mjacob@freebsd.org) Received: from ns1.feral.com (ns1.feral.com [192.67.166.1]) by mx1.freebsd.org (Postfix) with ESMTP id 77B5813C45B; Sat, 12 May 2007 15:41:20 +0000 (UTC) (envelope-from mjacob@freebsd.org) Received: from ns1.feral.com (localhost [127.0.0.1]) by ns1.feral.com (8.14.1/8.14.1) with ESMTP id l4CFfBhU037632; Sat, 12 May 2007 08:41:19 -0700 (PDT) (envelope-from mjacob@freebsd.org) Received: from localhost (mjacob@localhost) by ns1.feral.com (8.14.1/8.14.1/Submit) with ESMTP id l4CFfBnM037629; Sat, 12 May 2007 08:41:11 -0700 (PDT) (envelope-from mjacob@freebsd.org) X-Authentication-Warning: ns1.feral.com: mjacob owned process doing -bs Date: Sat, 12 May 2007 08:41:08 -0700 (PDT) From: mjacob@freebsd.org To: Pawel Jakub Dawidek In-Reply-To: <20070512110338.GA88520@garage.freebsd.pl> Message-ID: <20070512084036.U37624@ns1.feral.com> References: <20070512110338.GA88520@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-scsi@freebsd.org Subject: Re: isp(4) mutex recursion. X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mjacob@freebsd.org List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 May 2007 15:41:20 -0000 Interesting and noted. Try doing it not as a module. On Sat, 12 May 2007, Pawel Jakub Dawidek wrote: > I've this panic on isp.ko load with recent current: > > isp0: port 0x3000-0x30ff mem 0xfc400000-0xfc400fff irq 27 at device 4.0 on pci2 > registered firmware set > isp0: [ITHREAD] > isp0: Board Type 2300, Chip Revision 0x1, loaded F/W Revision 3.3.19 > panic: _mtx_lock_sleep: recursed on non-recursive mutex isp @ /usr/home/src/HEAD/src/sys/modules/isp/../../dev/isp/isp_freebsd.c:688 > > cpuid = 1 > KDB: enter: panic > [thread pid 560 tid 100030 ] > Stopped at kdb_enter+0x2b: nop > db> tr > Tracing pid 560 tid 100030 td 0xc36ee870 > kdb_enter(c06022ed) at kdb_enter+0x2b > panic(c06014aa,c3c40298,c3c3fb2b,2b0,c04c636f,...) at panic+0x11c > _mtx_lock_sleep(c3778690,c36ee870,0,c3c3fb2b,2b0) at _mtx_lock_sleep+0x3a > _mtx_lock_flags(c3778690,0,c3c3fb2b,2b0,0,...) at _mtx_lock_flags+0x94 > isp_intr_enable(c3778600,c0671a60,0,c0604304,47,...) at isp_intr_enable+0x20 > run_interrupt_driven_config_hooks(0) at run_interrupt_driven_config_hooks+0x43 > config_intrhook_establish(c3778638,c3778638,c3778690,3e5b3000,0,...) at config_intrhook_establish+0xb9 > isp_attach(c3778600,c05f7a2a,1,c3c41560,30,...) at isp_attach+0x81 > isp_pci_attach(c3789680) at isp_pci_attach+0x127d > device_attach(c3789680,c3789680,c3789680,0,c37e4600,...) at device_attach+0x58 > device_probe_and_attach(c3789680,c3789680,c37e4600) at device_probe_and_attach+0xe0 > pci_driver_added(c3789700,c3c414b0) at pci_driver_added+0xd1 > devclass_add_driver(c36dac00,c3c414b0) at devclass_add_driver+0xd5 > driver_module_handler(c3b152c0,0,c3c4149c,c066ca10,c0601132,7b) at driver_module_handler+0x59 > module_register_init(c3c41490) at module_register_init+0x66 > linker_file_sysinit(c3bdd100,c3bdd100,c066c564,c05ffa8f,196,...) at linker_file_sysinit+0x9d > linker_load_file(c383a520,e2296c20) at linker_load_file+0x102 > linker_load_module(0,c37e6000,0,0,e2296c58,c066c564,c05ffa8f,364) at linker_load_module+0xdb > kern_kldload(c36ee870,c37e6000,e2296c7c) at kern_kldload+0x92 > kldload(c36ee870,e2296d00) at kldload+0x4f > syscall(e2296d38) at syscall+0x242 > Xint0x80_syscall() at Xint0x80_syscall+0x20 > --- syscall (304, FreeBSD ELF32, kldload), eip = 0x280c17ab, esp = > 0xbfbfec1c, ebp = 0xbfbfec58 --- > > -- > Pawel Jakub Dawidek http://www.wheel.pl > pjd@FreeBSD.org http://www.FreeBSD.org > FreeBSD committer Am I Evil? Yes, I Am! > From owner-freebsd-scsi@FreeBSD.ORG Sat May 12 16:19:11 2007 Return-Path: X-Original-To: freebsd-scsi@freebsd.org Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 073A516A405; Sat, 12 May 2007 16:19:11 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id A8DFE13C522; Sat, 12 May 2007 16:19:10 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.samsco.home (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.8/8.13.8) with ESMTP id l4CG0G1B030535; Sat, 12 May 2007 10:00:17 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <4645E489.80705@samsco.org> Date: Sat, 12 May 2007 10:00:09 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.2pre) Gecko/20070111 SeaMonkey/1.1 MIME-Version: 1.0 To: mjacob@freebsd.org References: <20070512110338.GA88520@garage.freebsd.pl> <20070512084036.U37624@ns1.feral.com> In-Reply-To: <20070512084036.U37624@ns1.feral.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (pooker.samsco.org [168.103.85.57]); Sat, 12 May 2007 10:00:17 -0600 (MDT) X-Spam-Status: No, score=-1.4 required=5.5 tests=ALL_TRUSTED autolearn=failed version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: freebsd-scsi@freebsd.org, Pawel Jakub Dawidek Subject: Re: isp(4) mutex recursion. X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 May 2007 16:19:11 -0000 As you probably noticed, config_intrhooks get run synchronously if "cold" is not set, i.e. after boot. This really needs to be fixed so that they always run asynchronously. Scott mjacob@freebsd.org wrote: > Interesting and noted. Try doing it not as a module. > > > On Sat, 12 May 2007, Pawel Jakub Dawidek wrote: > >> I've this panic on isp.ko load with recent current: >> >> isp0: port 0x3000-0x30ff mem >> 0xfc400000-0xfc400fff irq 27 at device 4.0 on pci2 >> registered firmware set >> isp0: [ITHREAD] >> isp0: Board Type 2300, Chip Revision 0x1, loaded F/W Revision 3.3.19 >> panic: _mtx_lock_sleep: recursed on non-recursive mutex isp @ >> /usr/home/src/HEAD/src/sys/modules/isp/../../dev/isp/isp_freebsd.c:688 >> >> cpuid = 1 >> KDB: enter: panic >> [thread pid 560 tid 100030 ] >> Stopped at kdb_enter+0x2b: nop >> db> tr >> Tracing pid 560 tid 100030 td 0xc36ee870 >> kdb_enter(c06022ed) at kdb_enter+0x2b >> panic(c06014aa,c3c40298,c3c3fb2b,2b0,c04c636f,...) at panic+0x11c >> _mtx_lock_sleep(c3778690,c36ee870,0,c3c3fb2b,2b0) at _mtx_lock_sleep+0x3a >> _mtx_lock_flags(c3778690,0,c3c3fb2b,2b0,0,...) at _mtx_lock_flags+0x94 >> isp_intr_enable(c3778600,c0671a60,0,c0604304,47,...) at >> isp_intr_enable+0x20 >> run_interrupt_driven_config_hooks(0) at >> run_interrupt_driven_config_hooks+0x43 >> config_intrhook_establish(c3778638,c3778638,c3778690,3e5b3000,0,...) >> at config_intrhook_establish+0xb9 >> isp_attach(c3778600,c05f7a2a,1,c3c41560,30,...) at isp_attach+0x81 >> isp_pci_attach(c3789680) at isp_pci_attach+0x127d >> device_attach(c3789680,c3789680,c3789680,0,c37e4600,...) at >> device_attach+0x58 >> device_probe_and_attach(c3789680,c3789680,c37e4600) at >> device_probe_and_attach+0xe0 >> pci_driver_added(c3789700,c3c414b0) at pci_driver_added+0xd1 >> devclass_add_driver(c36dac00,c3c414b0) at devclass_add_driver+0xd5 >> driver_module_handler(c3b152c0,0,c3c4149c,c066ca10,c0601132,7b) at >> driver_module_handler+0x59 >> module_register_init(c3c41490) at module_register_init+0x66 >> linker_file_sysinit(c3bdd100,c3bdd100,c066c564,c05ffa8f,196,...) at >> linker_file_sysinit+0x9d >> linker_load_file(c383a520,e2296c20) at linker_load_file+0x102 >> linker_load_module(0,c37e6000,0,0,e2296c58,c066c564,c05ffa8f,364) at >> linker_load_module+0xdb >> kern_kldload(c36ee870,c37e6000,e2296c7c) at kern_kldload+0x92 >> kldload(c36ee870,e2296d00) at kldload+0x4f >> syscall(e2296d38) at syscall+0x242 >> Xint0x80_syscall() at Xint0x80_syscall+0x20 >> --- syscall (304, FreeBSD ELF32, kldload), eip = 0x280c17ab, esp = >> 0xbfbfec1c, ebp = 0xbfbfec58 --- >> >> -- >> Pawel Jakub Dawidek http://www.wheel.pl >> pjd@FreeBSD.org http://www.FreeBSD.org >> FreeBSD committer Am I Evil? Yes, I Am! >> > _______________________________________________ > freebsd-scsi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-scsi > To unsubscribe, send any mail to "freebsd-scsi-unsubscribe@freebsd.org" From owner-freebsd-scsi@FreeBSD.ORG Sat May 12 16:29:13 2007 Return-Path: X-Original-To: freebsd-scsi@freebsd.org Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DD76916A403; Sat, 12 May 2007 16:29:13 +0000 (UTC) (envelope-from mjacob@freebsd.org) Received: from ns1.feral.com (ns1.feral.com [192.67.166.1]) by mx1.freebsd.org (Postfix) with ESMTP id 5E72713C45E; Sat, 12 May 2007 16:29:13 +0000 (UTC) (envelope-from mjacob@freebsd.org) Received: from ns1.feral.com (localhost [127.0.0.1]) by ns1.feral.com (8.14.1/8.14.1) with ESMTP id l4CGT46k038012; Sat, 12 May 2007 09:29:12 -0700 (PDT) (envelope-from mjacob@freebsd.org) Received: from localhost (mjacob@localhost) by ns1.feral.com (8.14.1/8.14.1/Submit) with ESMTP id l4CGT3iX038009; Sat, 12 May 2007 09:29:03 -0700 (PDT) (envelope-from mjacob@freebsd.org) X-Authentication-Warning: ns1.feral.com: mjacob owned process doing -bs Date: Sat, 12 May 2007 09:29:03 -0700 (PDT) From: mjacob@freebsd.org To: Scott Long In-Reply-To: <4645E489.80705@samsco.org> Message-ID: <20070512092754.K38001@ns1.feral.com> References: <20070512110338.GA88520@garage.freebsd.pl> <20070512084036.U37624@ns1.feral.com> <4645E489.80705@samsco.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-scsi@freebsd.org, Pawel Jakub Dawidek Subject: Re: isp(4) mutex recursion. X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mjacob@freebsd.org List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 May 2007 16:29:13 -0000 On Sat, 12 May 2007, Scott Long wrote: > As you probably noticed, config_intrhooks get run synchronously if > "cold" is not set, i.e. after boot. This really needs to be fixed so > that they always run asynchronously. Yes. But a short term fix is to not hold locks when calling it.