From owner-freebsd-scsi@FreeBSD.ORG Mon Apr 16 10:21:32 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 5E5AE16A404 for ; Mon, 16 Apr 2007 10:21:32 +0000 (UTC) (envelope-from email@welcomeoffice.emv1.net) Received: from emailer99-225.emv1.net (emailer99-225.emv1.net [84.14.99.225]) by mx1.freebsd.org (Postfix) with ESMTP id F233713C4B0 for ; Mon, 16 Apr 2007 10:21:31 +0000 (UTC) (envelope-from email@welcomeoffice.emv1.net) Date: Mon, 16 Apr 2007 12:19:56 +0200 (CEST) From: Welcome Office To: "freebsd-scsi@freebsd.org" Message-ID: <4520581233.1096155.1176718796609@sch3.emv2.com> MIME-Version: 1.0 X-EMV-CampagneId: 1096155$ X-EMV-MemberId: 4520581233$ Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Un avertisseur de radar offert avec votre premiere commande ! X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "clientele@welcomeoffice.com" List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2007 10:21:32 -0000 WELCOME OFFICE n°1 DU DISCOUNT AUX ENTREPRISES Message invisible, cliquez ici Offre réservée à votre société, Un avertisseur de radar INFORAD V2 offert pour toute première commande supérieure à 400¤ HT ! Le 1er avertisseur de radar légal. Préservez les points de votre permis ! Contient : - le récepteur GPS, - le câble de liaison USB, - 1 adaptateur allume cigare 12/24 Volts, - 2 pastilles velcro, - le manuel d'utilisation - Antenne Magnétique Auto Pour bénéficier de cette offre, rien de plus simple : - connectez vous sur notre site http://as1.emv2.com/I?a=A9X7Cqgr_6me8TCE66L8vEPiGQ - dans la section "Ma commande", inscrivez le code suivant : M16KRADP17 ou copiez-collez le lien suivant dans votre navigateur web http://as1.emv2.com/I?a=A9X7Cqgr_6me8TCE66L8vEDiGg Bonne journée. L'équipe WELCOME OFFICE From owner-freebsd-scsi@FreeBSD.ORG Mon Apr 16 11:08:48 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 3AEB016A401 for ; Mon, 16 Apr 2007 11:08:48 +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 2B88113C4C1 for ; Mon, 16 Apr 2007 11:08:48 +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 l3GB8mui042973 for ; Mon, 16 Apr 2007 11:08:48 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l3GB8k95042968 for freebsd-scsi@FreeBSD.org; Mon, 16 Apr 2007 11:08:46 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 16 Apr 2007 11:08:46 GMT Message-Id: <200704161108.l3GB8k95042968@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, 16 Apr 2007 11:08:48 -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) 14 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 Mon Apr 16 13:22: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 0FBDF16A404 for ; Mon, 16 Apr 2007 13:22:02 +0000 (UTC) (envelope-from tcheek@pixelfish.com) Received: from mail01.vmatrixmail.com (mail01.vmatrixmail.com [216.219.244.230]) by mx1.freebsd.org (Postfix) with ESMTP id 77EB213C448 for ; Mon, 16 Apr 2007 13:22:01 +0000 (UTC) (envelope-from tcheek@pixelfish.com) Received: (vmatrix@mail01.vmatrixmail.com) by vmatrixmail.com id S6077437AbXDPNWA for ; Mon, 16 Apr 2007 06:22:00 -0700 To: scsi@freebsd.org MIME-Version: 1.0 X-Mailer: Rich Media Mail V4. Vmatrix, (C) 2003 From: "Tammie Cheek" Sender: "Tammie Cheek" Message-Id: Date: Mon, 16 Apr 2007 06:22:00 -0700 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Technology Industry Moves To Video X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: tcheek@pixelfish.com List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2007 13:22:02 -0000 Greetings!

Are you happy with your results from the Southern California Linux Expo 2007? Did you have what it takes to make the difference between creating excitement and blending in with the competition, between lots of hot leads and a few hard sells ... between success and failure?

Did you have video?

Why video? Video vividly demonstrates the features and benefits of your products. Video captures the praises of your most enthusiastic customers. Video instills interest, reaction and trust. Video sells.

In just 45 days, PixelFish creates marketing videos that become an integral part of your marketing and sales efforts when it streams from your Web site, launches from multimedia email newsletters, plays from CD video brochures and loops from a DVD at your tradeshow booth.

We are PixelFish. We deliver “The Evolution of Video”. And we guarantee results. Click on the videos to the right to see samples of our work.

Contact us today for a free evaluation of your video marketing needs.


Tammie Cheek
PixelFish, Inc.
800.503.3020 x7110
tcheek@pixelfish.com
http://www.pixelfish.com
Interim Video
Empire Stat Group Video
Columbia Healthcare Analytics Video
------------------------------------------------ Unsubscribe to safely remove yourself from this email list, please send email to info@pixelfish.com. Powered by Pixelfish http://www.pixelfish.com From owner-freebsd-scsi@FreeBSD.ORG Fri Apr 20 09:04:08 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 4BA0416A400 for ; Fri, 20 Apr 2007 09:04:08 +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 ED02213C44B for ; Fri, 20 Apr 2007 09:04:07 +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 l3K9423S051827 for ; Fri, 20 Apr 2007 03:04:02 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <462881F1.3020001@samsco.org> Date: Fri, 20 Apr 2007 03:03:45 -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: scsi@freebsd.org 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]); Fri, 20 Apr 2007 03:04:02 -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: Subject: MPSAFE CAM, MPSAFE drivers 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: Fri, 20 Apr 2007 09:04:08 -0000 All, I'm happy to announce that CAM is now MPSAFE, thanks to the help of many people and sponsorship by Yahoo! The work is in FreeBSD CVS now and can be obtained by checking out the HEAD/7-CURRENT branch. It will be part of the upcoming FreeBSD 7.0 release this year. Only the AHC and AHD drivers are MPSAFE at the moment, but hopefully more will follow in the coming months. Below is a document describing the locking approach, and instructions for locking CAM/SIM drivers that are not yet MPSAFE. Locking theory -------------- The following describes the basics of the locking strategy in CAM itself and how that applies to the SIM drivers (SCSI hardware drivers) underneath it. While CAM is MPSAFE, only a few SIMs have been made MPSAFE so far. The rest are mostly unchanged and are allowed continue to operate just as they did before. I hope that other developers and interested users will step in and help make these drivers MPSAFE, as it's too much work for me alone. Being MPSAFE doesn't necessarily make the CAM subsystem itself faster. The locking is still fairly monolithic on a per SIM instance level, and there isn't much parallelism for operations within each instance. Multiple SIM instances, i.e. multiple buses, do operate almost completely independently of each other now, so there is full parallelism there. However, being MPSAFE does eliminate contention with the other parts of the OS that are still under Giant, and this is still a huge win. Testing moderate to heavy loads on multi-core systems has shown a significant decrease in contention on the Giant lock, while showing only minimal new contention on the CAM locks. This lowered contention translates into less system time wasted by the CPUs, and thus more cycles for useful work as well as less latency. There are now 4 basic locks in CAM, 3 of which are: xpt_lock - Protects the XPT softc, periph, and SIM instances xpt_topo_lock - Protects the global peripheral and bus lists cam_simq_lock - Protects the list of SIMs to be processed in the camisr These 3 locks are internal to the CAM core and have little bearing on the operation of SIMs. None of these locks will be held when calling into a SIM, and the SIM has no need to access to them either. The 4th lock is the SIM lock. This is a non-recursive sleep mutex (MTX_DEF) that the SIM instance uses to protect its internal data structures and operations. It is also exported up to CAM when calling cam_sim_alloc(), and is used by CAM to protect target, device, and peripheral objects, as well as SIM and device queues. Every entry from CAM into the SIM will be done with this lock held. The SIM is welcome to unlock it when it needs, but it must be held when calling back into most CAM functions. It is the primary lock for normal I/O flow throughout CAM starting at the top of the stack in the periph driver. The flow looks like this: periph_strategy sim->mtx | | xpt_schedule | | | periph_start | | | xpt_action | | | sim_action + On completion: sim_isr sim->mtx | | xpt_done |cam_simq_lock | | swi_sched + camisr cam_simq_lock | camisr_runqueue sim->mtx | | periph_done + A SIM that is not MPSAFE exports the the Giant mutex (&Giant) in cam_sim_alloc(). Giant is then treated as a normal mutex by CAM and is locked and unlocked in the same place as for MPSAFE SIMs. This does not put all of CAM back under Giant; multiple SIMs instances can be registered, some MPSAFE and some not, and CAM will treat the locking of each instance separately. Driver changes -------------- For non-MPSAFE drivers, a single change was made to the API in the cam_sim_alloc() function. The function now looks like this: struct cam_sim * cam_sim_alloc(sim_action_func sim_action, sim_poll_func sim_poll, const char *sim_name, void *softc, u_int32_t unit, struct mtx *mtx, int max_dev_transactions, int max_tagged_dev_transactions, struct cam_devq *queue); For the "mtx" argument, "&Giant" is used. Everything else in the SIM stays the same. Some structures have also changed sizes, most notable "cam_sim", but that is not an issue since source level compatibility is already affected. MPSAFE drivers must do the following things: 1. Provide a pointer to a MTX_DEF mutex in cam_sim_alloc(). The mutex must be allocated and initialized before calling cam_sim_alloc(), and must not be destroyed until after calling cam_sim_free(). It should not be held while calling cam_sim_alloc(). 2. The timeout_ch field in the ccb_hdr structure is no longer available for use by the SIM. SIMs must now allocate, initialize, and manage their own callout structures. All uses of the timeout() API must be switched to the callout() API. See the callout manpage for details on this. 3. Add the INTR_MPSAFE flag to bus_setup_intr(). This will prevent Giant from being automatically acquired before the driver interrupt handler is called. 4. Any busdma tags that allow load deferrals (i.e. return EINPROGRESS) must register a non-Giant mutex in bus_dma_tag_create(). This field is not inherited from parent tags. 5. If the driver registers a character device with make_dev(), the D_NEEDSGIANT flag should be dropped, and appropriate locking added to the device entry vectors. 6. If the driver registers any sysctls, all locks must be dropped and Giant must be held explicitly when registering and deregistering the sysctl nodes. Sysctl handlers will be called with Giant held, and appropriate locking should be added under that. No calls into CAM should be made from these contexts. 7. Provide appropriate locking in the interrupt handler as well as any taskqueue handlers, callout handlers, kthreads, or other detached contexts, as appropriate. 8. Ensure that the registered SIM mutex is held when calling all CAM entry points. Until recently, the xpt_done() entry point provided its own locking and did not require Giant to be held. It still does not require Giant, but it does require the SIM lock to be held when calling it. 9. Do not hold the SIM mutex or any other mutex when calling malloc(M_WAITOK), bus_dmamem_alloc(), and bus_dmamap_create(). 10. Any uses of tsleep must be changed to msleep. For multi-function PCI devices where each function represents a bus, a separate SIM and SIM mutex should be allocated and managed for each function. Functions that register multiple SIMs should coordinate locking between those SIMs as needed; the same lock can be registered for these separate SIMs, at the cost of reduced parallelism between SIMs. Functions that register a single SIM for multiple buses will have all of those buses under a single mutex as far as CAM is concerned. The simplest strategy is to use a single lock per SIM instance. More complex multi-level or pipelined locking is allowed; the registered SIM lock can be dropped by the SIM at any point without disrupting the rest of CAM, so long as no CAM entry points are called with it unlocked. This will be an area for further research. Userland changes ---------------- Efforts were made to keep the userland API and ABI unchanged. Thus, there are no source level changes needed for any tools, libraries, or apps, nor any need to recompile any of these either. Future work ----------- The CAM API will likely undergo some more small changes to support future work with newbus integration and SAS/SATA/FC transport modularization. These changes will hopefully be done before FreeBSD 7.0 is released. From owner-freebsd-scsi@FreeBSD.ORG Fri Apr 20 15:49:07 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 0A74E16A401 for ; Fri, 20 Apr 2007 15:49:07 +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 C1BCE13C4B0 for ; Fri, 20 Apr 2007 15:49:06 +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 l3KFn3u8053777 for ; Fri, 20 Apr 2007 09:49:03 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <4628E0DE.2090103@samsco.org> Date: Fri, 20 Apr 2007 09:48:46 -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: scsi@freebsd.org 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]); Fri, 20 Apr 2007 09:49:03 -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: Subject: 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: Fri, 20 Apr 2007 15:49:07 -0000 All, Now that the MPSAFE work is mostly done and settled, it's time to move onto the next phase of the overall work. NEWBUS integration + Transport modularization: ---------------------------------------------- CAM is centered around parallel SCSI. It has detailed knowledge of how buses, targets, and LUNs work in SCSI. Besides this knowledge being embedded in the core of CAM, it is not exported out to the NEWBUS framework. Running the "devinfo" command only shows the controller devices, not any of the topology underneath it. Camcontrol does show the topology, but that's a privileged command. My plan is to move the bus scanner and device probe functionality out of cam_xpt.c and into the scsi/scsi_xpt.c. As part of this move, buses, targets, devices, and peripherals will become newbus drivers, with the normal probe, attach, and detach vectors and semantics. The opaque cam_path, cam_eb, cam_et structures will become private to these newbus drivers. Access to the internals of these objects will be done through newbus interface methods. The XPT will retain knowledge of the cam_ed structure; keeping it opaque and accessible only though newbus methods would significantly slow down normal I/O operations. Topology will be built by parent objects allowing children to probe and attach themselves to child devices. Children will probe attributes such as bus type and device type to decide if they want to claim the device. Multiple peripheral devices will still be allowed to attach to devices, just as today. Topology will look something like this: nexus0 pcib0 pci0 sim0 scsibus0 target0 device0 da0 pass0 target1 device1 cd0 pass1 sim1 scsibus1 target2 device2 da1 pass2 I haven't decided yet if the newbus names of the bus, target, and devices will correspond to actual B:T:L enumeration numbers of if they'll just be assigned sequentially as they are discovered. Camcontrol will still show actual B:T:L enumeration, regardless of what newbus sees. The end result is that the XPT will be divided into 2 parts, one that manages topology and advertises devices, and another that manages the sim and device queues. This split will not affect the /dev/xpt0 device. Applications will still only see 1 XPT node, but xptioctl() will redirect transport-specific commands as needed. I expect most of this work to be transparent to userland CAM apps. There will likely be a small API change to SIMs to export the SIM newbus device node up so that children can be attached to it. 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? The SIM drivers for IDE/SATA will use the same interface as SCSI. They will be responsible for programming the controller, managing command timeouts, and performing transport level error detection and recovery, just like SCSI SIMs. Instead of a single monolithic driver that knows how to talk to dozens of very different controllers, support will be broken down into multiple SIMs, each targeted to individual controller families. I plan to write SIMs for AHCI, ICH2/3/4, and ICH5/6 controllers. There are no plans to retire the existing ATA driver anytime soon. It still contains the best support for tricky, buggy hardware, as well as older hardware. The future of these drivers will depend on how well they serve the community. Please let me know if you have any questions, objections, or suggestions. SCott From owner-freebsd-scsi@FreeBSD.ORG Fri Apr 20 18:59:39 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 7182B16A401 for ; Fri, 20 Apr 2007 18:59:39 +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 0E50713C4B0 for ; Fri, 20 Apr 2007 18:59:38 +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); Fri, 20 Apr 2007 20:47:34 +0200 Message-ID: <46290AC6.9020608@ask-us.at> Date: Fri, 20 Apr 2007 20:47:34 +0200 From: Bernard Buri User-Agent: Thunderbird 1.5.0.10 (X11/20070309) MIME-Version: 1.0 References: <4628E0DE.2090103@samsco.org> In-Reply-To: <4628E0DE.2090103@samsco.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Apr 2007 18:47:34.0779 (UTC) FILETIME=[5C1AC4B0:01C7837C] 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: Fri, 20 Apr 2007 18:59:39 -0000 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* ? From owner-freebsd-scsi@FreeBSD.ORG Fri Apr 20 20:28: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 E71F016A401 for ; Fri, 20 Apr 2007 20:28: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 92DE713C45D for ; Fri, 20 Apr 2007 20:28:14 +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 l3KKS7TW058797; Fri, 20 Apr 2007 14:28:07 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <46292245.3030900@samsco.org> Date: Fri, 20 Apr 2007 14:27:49 -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> In-Reply-To: <46290AC6.9020608@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]); Fri, 20 Apr 2007 14:28:07 -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: Fri, 20 Apr 2007 20:28:15 -0000 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 From owner-freebsd-scsi@FreeBSD.ORG Fri Apr 20 20:45:22 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 377F216A401 for ; Fri, 20 Apr 2007 20:45:22 +0000 (UTC) (envelope-from lydianconcepts@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.225]) by mx1.freebsd.org (Postfix) with ESMTP id EC77013C44B for ; Fri, 20 Apr 2007 20:45:21 +0000 (UTC) (envelope-from lydianconcepts@gmail.com) Received: by wr-out-0506.google.com with SMTP id 70so1075872wra for ; Fri, 20 Apr 2007 13:45:21 -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=bAvXFDy7UuMb/mmtOFuzkFTuuhwcbN+Xx6C0E+KkSuQlloVxJqNIRoS4Ka00fZmXBvaF+guBkr7AEUUY0vdECoyAs18B3W89+JBt0IYm9GL2M0NOqzRAYCLQesX8UgzmAtXQm9btyGb8PlBqi7DD1MxKCqigZrAJz20ldFTpy3I= 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=M3GerFISxizv0dHV76hr7DBI99FepBgQBOhk6gggnJJIOSQbgKww8MXHgrnx9P5bSi6wzm6mpIlqcy8h5w8rRyeQ32AbNPQTC7vBbijxregIPoT8buvnkan6TOLW1A2RSqSLs8YMgIIwS1ci2U0/8/7bNYykAM0ZSnjWi52qS5A= Received: by 10.114.173.15 with SMTP id v15mr1412322wae.1177100258565; Fri, 20 Apr 2007 13:17:38 -0700 (PDT) Received: by 10.114.24.2 with HTTP; Fri, 20 Apr 2007 13:17:38 -0700 (PDT) Message-ID: <7579f7fb0704201317y41c56b88y3aeb158474d16bad@mail.gmail.com> Date: Fri, 20 Apr 2007 13:17:38 -0700 From: "Matthew Jacob" To: "Scott Long" In-Reply-To: <462881F1.3020001@samsco.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <462881F1.3020001@samsco.org> Cc: scsi@freebsd.org Subject: Re: MPSAFE CAM, MPSAFE drivers 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: Fri, 20 Apr 2007 20:45:22 -0000 An excellent writeup- thanks!