From owner-freebsd-scsi@FreeBSD.ORG Mon May 28 11:08:42 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 DE0B916A4A0 for ; Mon, 28 May 2007 11:08:42 +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 CDA7913C45D for ; Mon, 28 May 2007 11:08:42 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id l4SB8gNF068616 for ; Mon, 28 May 2007 11:08:42 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l4SB8fcT068612 for freebsd-scsi@FreeBSD.org; Mon, 28 May 2007 11:08:41 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 28 May 2007 11:08:41 GMT Message-Id: <200705281108.l4SB8fcT068612@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats 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, 28 May 2007 11:08:42 -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 Fri Jun 1 00:39:09 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 6B60F16A421 for ; Fri, 1 Jun 2007 00:39:09 +0000 (UTC) (envelope-from freebsd@gm.nunu.org) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.176]) by mx1.freebsd.org (Postfix) with ESMTP id 307B913C43E for ; Fri, 1 Jun 2007 00:39:09 +0000 (UTC) (envelope-from freebsd@gm.nunu.org) Received: by py-out-1112.google.com with SMTP id a29so653347pyi for ; Thu, 31 May 2007 17:39:08 -0700 (PDT) Received: by 10.35.128.1 with SMTP id f1mr1915898pyn.1180656684619; Thu, 31 May 2007 17:11:24 -0700 (PDT) Received: by 10.35.79.1 with HTTP; Thu, 31 May 2007 17:11:24 -0700 (PDT) Message-ID: <626eb4530705311711h69322a54ga7c49aea3fe4ab27@mail.gmail.com> Date: Fri, 1 Jun 2007 09:11:24 +0900 From: "Hidetoshi Shimokawa" Sender: freebsd@gm.nunu.org To: "Robert Watson" In-Reply-To: <20070601010212.F77697@fledge.watson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070531183719.B77697@fledge.watson.org> <20070531180555.GA10910@kobe.laptop> <20070601010212.F77697@fledge.watson.org> X-Google-Sender-Auth: 5f71d64cf34d4f6e Cc: Giorgos Keramidas , current@freebsd.org, scsi@freebsd.org Subject: Re: watch(8) stuck in devdrn 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, 01 Jun 2007 00:39:09 -0000 The problem doesn't seem specific to tty sub system. I have similar problem with scsi_target. On 6/1/07, Robert Watson wrote: > > On Thu, 31 May 2007, Giorgos Keramidas wrote: > > > On 2007-05-31 18:38, Robert Watson wrote: > >> I was using watch(8) this afternoon, and on trying to quit, ran into this: > >> > >> peppercorn:~> ps axl | grep watch > >> 0 14200 14194 0 -8 0 3416 1056 devdrn D p2- 0:00.01 watch -W tt > >> > >> It was running on a pty, but the target tty was ttyv1. > > > > If you have kern.pts.enable=1 you may have to use: > > http://hg.hellug.gr/freebsd/src-keramida/file/944ac3982de1/pty-devdrn > > > > Without this patch and kern.pts.enable=1 all ptys seem to get stuck in > > devdrn on process exit. AFAIK, Kostik Belousov and Tor Egge know this and > > are already working on a fix: > > I'm not using pts.enable on this box. > > Robert N M Watson > Computer Laboratory > University of Cambridge > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > -- /\ Hidetoshi Shimokawa \/ simokawa@FreeBSD.ORG From owner-freebsd-scsi@FreeBSD.ORG Fri Jun 1 02:12:32 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 90A6A16A400 for ; Fri, 1 Jun 2007 02:12:32 +0000 (UTC) (envelope-from leafy7382@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.180]) by mx1.freebsd.org (Postfix) with ESMTP id 323B013C448 for ; Fri, 1 Jun 2007 02:12:31 +0000 (UTC) (envelope-from leafy7382@gmail.com) Received: by py-out-1112.google.com with SMTP id a29so687557pyi for ; Thu, 31 May 2007 19:12:30 -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=d6RkIFTvZXq3KjKjRrw4nSU1sOp0pIrE3XabFXhdfhTfUBQ6gI+GpCd0qNZte4cVgvegqrxMTOV4j0jCoeq7bimre3OWWHM9AnpKhI5aCCQfIJVqSazEBOax62fW5nFOlRdZw1XkcakzdgZs9uvJcfVn67iuB51wWV2l/Pmdk7A= 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=IErDW+6brLn88kEMyzZugoDr7De40+yzV145w3/8aB/J7iAveXFNVOUymlSEyozDIgCDGkPHyH8ZUszRLN5R+VBZc+1FJLE3RKw88X1MWL0zptAzDILlGxiP5iYK9H7guiFhxFtbDVQAL/2NJO04q3tLxjKqiVjO8dLWtr+rsKA= Received: by 10.65.250.11 with SMTP id c11mr2143747qbs.1180662425595; Thu, 31 May 2007 18:47:05 -0700 (PDT) Received: by 10.65.250.20 with HTTP; Thu, 31 May 2007 18:47:05 -0700 (PDT) Message-ID: Date: Fri, 1 Jun 2007 09:47:05 +0800 From: "Jiawei Ye" To: "Hidetoshi Shimokawa" In-Reply-To: <626eb4530705311711h69322a54ga7c49aea3fe4ab27@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070531183719.B77697@fledge.watson.org> <20070531180555.GA10910@kobe.laptop> <20070601010212.F77697@fledge.watson.org> <626eb4530705311711h69322a54ga7c49aea3fe4ab27@mail.gmail.com> Cc: Giorgos Keramidas , Robert Watson , current@freebsd.org, scsi@freebsd.org Subject: Re: watch(8) stuck in devdrn 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, 01 Jun 2007 02:12:32 -0000 On 6/1/07, Hidetoshi Shimokawa wrote: > The problem doesn't seem specific to tty sub system. > I have similar problem with scsi_target. > > On 6/1/07, Robert Watson wrote: > > > > On Thu, 31 May 2007, Giorgos Keramidas wrote: > > > > > On 2007-05-31 18:38, Robert Watson wrote: > > >> I was using watch(8) this afternoon, and on trying to quit, ran into this: > > >> > > >> peppercorn:~> ps axl | grep watch > > >> 0 14200 14194 0 -8 0 3416 1056 devdrn D p2- 0:00.01 watch -W tt > > >> > > >> It was running on a pty, but the target tty was ttyv1. > > > > > > If you have kern.pts.enable=1 you may have to use: > > > http://hg.hellug.gr/freebsd/src-keramida/file/944ac3982de1/pty-devdrn > > > > > > Without this patch and kern.pts.enable=1 all ptys seem to get stuck in > > > devdrn on process exit. AFAIK, Kostik Belousov and Tor Egge know this and > > > are already working on a fix: > > > > I'm not using pts.enable on this box. > > > > Robert N M Watson > > Computer Laboratory > > University of Cambridge > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > mount_smbfs has been having this problem for quite a while too. Jiawei Ye -- "If it looks like a duck, walks like a duck, and quacks like a duck, then to the end user it's a duck, and end users have made it pretty clear they want a duck; whether the duck drinks hot chocolate or coffee is irrelevant." From owner-freebsd-scsi@FreeBSD.ORG Fri Jun 1 03:10:52 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 EEA5216A400 for ; Fri, 1 Jun 2007 03:10:52 +0000 (UTC) (envelope-from simokawa@freebsd.org) Received: from mail3.ecc.u-tokyo.ac.jp (mail3.ecc.u-tokyo.ac.jp [133.11.205.99]) by mx1.freebsd.org (Postfix) with ESMTP id B501B13C458 for ; Fri, 1 Jun 2007 03:10:52 +0000 (UTC) (envelope-from simokawa@freebsd.org) Received: from mail1.ecc.u-tokyo.ac.jp (mail1.ecc.u-tokyo.ac.jp [133.11.50.203]) by mail3.ecc.u-tokyo.ac.jp (Postfix) with ESMTP id A18B72C669 for ; Fri, 1 Jun 2007 11:47:45 +0900 (JST) Received: from spam004.ecc.u-tokyo.ac.jp (spam004.ecc.u-tokyo.ac.jp [133.11.50.197]) by mail1.ecc.u-tokyo.ac.jp (Postfix) with ESMTP id AEEC71006F for ; Fri, 1 Jun 2007 11:47:44 +0900 (JST) Received: from maru5.nunu.org (157.82.169.72 [157.82.169.72]) by spam004.ecc.u-tokyo.ac.jp (SpamBlock.pst 3.4.97) with ESMTP id <86wsyopf0t.wl%simokawa@FreeBSD.ORG> for ; Fri, 1 Jun 2007 11:47:15 +0900 Date: Fri, 01 Jun 2007 11:47:14 +0900 Message-ID: <86wsyopf0t.wl%simokawa@FreeBSD.ORG> From: Hidetoshi Shimokawa To: scottl@samsco.org User-Agent: Wanderlust/2.15.2 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.0.50 (i386-unknown-freebsd5.4) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-IP: 157.82.169.72 X-FROM-DOMAIN: freebsd.org X-FROM-EMAIL: simokawa@freebsd.org Cc: freebsd-scsi@freebsd.org Subject: CAM locking 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, 01 Jun 2007 03:10:53 -0000 Hi Scott, Thank you for your work on CAM. I have some questions about lock assertion. 1. Now, xpt_done() should be called with a sim lock for QUEUED ccbs. Why don't you add an assertion in xpt_done()? 2. CAMDEBUG seems useless with WITNESS because xpt_path_path_id() requires a sim lock. Can we safely drop the assertion? I have some problem with scsi_target and I'll describe it in another mail. Regards, ============================================= (cd /usr/src && patch -p6) < diff_to_current ============================================= --- //depot/vendor/freebsd/src/sys/cam/cam_xpt.c 2007/05/16 17:02:05 +++ //depot/user/simokawa/firewire_lock/sys/cam/cam_xpt.c 2007/05/23 08:44:59 @@ -4222,7 +4222,9 @@ path_id_t xpt_path_path_id(struct cam_path *path) { +#if 0 mtx_assert(path->bus->sim->mtx, MA_OWNED); +#endif return(path->bus->path_id); } @@ -4840,6 +4842,7 @@ sim = done_ccb->ccb_h.path->bus->sim; switch (done_ccb->ccb_h.path->periph->type) { case CAM_PERIPH_BIO: + mtx_assert(sim->mtx, MA_OWNED); TAILQ_INSERT_TAIL(&sim->sim_doneq, &done_ccb->ccb_h, sim_links.tqe); done_ccb->ccb_h.pinfo.index = CAM_DONEQ_INDEX; /\ Hidetoshi Shimokawa \/ simokawa@FreeBSD.ORG From owner-freebsd-scsi@FreeBSD.ORG Fri Jun 1 03:20:49 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 213B116A477 for ; Fri, 1 Jun 2007 03:20:49 +0000 (UTC) (envelope-from simokawa@freebsd.org) Received: from mail1.ecc.u-tokyo.ac.jp (mail1.ecc.u-tokyo.ac.jp [133.11.50.203]) by mx1.freebsd.org (Postfix) with ESMTP id DC7C213C487 for ; Fri, 1 Jun 2007 03:20:48 +0000 (UTC) (envelope-from simokawa@freebsd.org) Received: from spam002.ecc.u-tokyo.ac.jp (spam002.ecc.u-tokyo.ac.jp [133.11.50.195]) by mail1.ecc.u-tokyo.ac.jp (Postfix) with ESMTP id 445DD10079 for ; Fri, 1 Jun 2007 12:20:48 +0900 (JST) Received: from maru5.nunu.org (157.82.169.72 [157.82.169.72]) by spam002.ecc.u-tokyo.ac.jp (SpamBlock.pst 3.4.97) with ESMTP id <86tztspdil.wl%simokawa@FreeBSD.ORG> for ; Fri, 1 Jun 2007 12:19:47 +0900 Date: Fri, 01 Jun 2007 12:19:46 +0900 Message-ID: <86tztspdil.wl%simokawa@FreeBSD.ORG> From: Hidetoshi Shimokawa To: freebsd-scsi@freebsd.org User-Agent: Wanderlust/2.15.2 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.0.50 (i386-unknown-freebsd5.4) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-IP: 157.82.169.72 X-FROM-DOMAIN: freebsd.org X-FROM-EMAIL: simokawa@freebsd.org Subject: scsi_target with multiple luns 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, 01 Jun 2007 03:20:49 -0000 I have not fully analyzed the problem but I'll describe it just for a note. I'd like to ask maintainers of scsi_target for further analysis. I experiance a problem with small number(1) of simq and multiple scsi_target(8) instances. As far as I understand, the following situation could occur under a fairly heavy load. 1. process A send a request -> cam send to sim 2. process B send a request -> blocked because the simq is full 3. the request of process A is finished (in the context of process A) 4. cam/scsi_target tries to send the request of process B. But the mapped memory is of process A, and scsi_target send wrong ccb to sim. Maybe, we should rewrite scsi_target in kernel space with GEOM support.. /\ Hidetoshi Shimokawa \/ simokawa@FreeBSD.ORG From owner-freebsd-scsi@FreeBSD.ORG Fri Jun 1 03:21:19 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 3026516A421; Fri, 1 Jun 2007 03:21:19 +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 DC0CE13C483; Fri, 1 Jun 2007 03:21:18 +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 l513LFDw079451; Thu, 31 May 2007 21:21:16 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <465F90A9.7080608@samsco.org> Date: Thu, 31 May 2007 21:21: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: Hidetoshi Shimokawa References: <86wsyopf0t.wl%simokawa@FreeBSD.ORG> In-Reply-To: <86wsyopf0t.wl%simokawa@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]); Thu, 31 May 2007 21:21:16 -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: CAM locking 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, 01 Jun 2007 03:21:19 -0000 Hidetoshi Shimokawa wrote: > Hi Scott, > > Thank you for your work on CAM. > I have some questions about lock assertion. > > 1. Now, xpt_done() should be called with a sim lock for QUEUED ccbs. > Why don't you add an assertion in xpt_done()? Accessing the sim_lock from the CCB requires enough dereferences that if the lock isn't already held, you'll probably run into problems just doing the derefs in the assertion. Adding a sim_lock field to the CCB has crossed my mind, but I don't want to pollute the CCB with more kernel-only fields if I can. I need to think some more on it. > > 2. CAMDEBUG seems useless with WITNESS because xpt_path_path_id() requires > a sim lock. Can we safely drop the assertion? Yes, this is an area that I didn't clean up very well. A lot of code in periphs and SIMs wants to be able to use CAMDEBUG functions in random places without the lock held, and I don't know of a good way to safely fix this without rewriting a lot of code. I don't know if it's better to just drop the assertion or to audit all of the code provide locked and unlocked versions of the CAMDEBUG functions. Scott From owner-freebsd-scsi@FreeBSD.ORG Fri Jun 1 03:41: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 8D96316A400; Fri, 1 Jun 2007 03:41: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 463DF13C465; Fri, 1 Jun 2007 03:41: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 l513fLu4079537; Thu, 31 May 2007 21:41:21 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <465F955E.7050103@samsco.org> Date: Thu, 31 May 2007 21:41:18 -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: Hidetoshi Shimokawa References: <86tztspdil.wl%simokawa@FreeBSD.ORG> In-Reply-To: <86tztspdil.wl%simokawa@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]); Thu, 31 May 2007 21:41:21 -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_target with multiple luns 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, 01 Jun 2007 03:41:24 -0000 Hidetoshi Shimokawa wrote: > I have not fully analyzed the problem but I'll describe it just for a note. > I'd like to ask maintainers of scsi_target for further analysis. > > I experiance a problem with small number(1) of simq and multiple > scsi_target(8) instances. > > As far as I understand, the following situation could occur under a fairly > heavy load. > > 1. process A send a request -> cam send to sim > 2. process B send a request -> blocked because the simq is full > 3. the request of process A is finished (in the context of process A) > 4. cam/scsi_target tries to send the request of process B. > But the mapped memory is of process A, and scsi_target send wrong > ccb to sim. > > Maybe, we should rewrite scsi_target in kernel space with GEOM support.. I'm unclear on how GEOM would fix this. Also, scsi targets aren't always DA devices. I dedicated scsi_da_target device that is backed by GEOM might be interesting, though. Even more interesting would be a direct DMA method that required no KVA mappings for the data. Scott From owner-freebsd-scsi@FreeBSD.ORG Fri Jun 1 04:43:12 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 BA9B916A41F for ; Fri, 1 Jun 2007 04:43:12 +0000 (UTC) (envelope-from freebsd@gm.nunu.org) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.178]) by mx1.freebsd.org (Postfix) with ESMTP id 84DAB13C44B for ; Fri, 1 Jun 2007 04:43:12 +0000 (UTC) (envelope-from freebsd@gm.nunu.org) Received: by py-out-1112.google.com with SMTP id a29so740542pyi for ; Thu, 31 May 2007 21:43:12 -0700 (PDT) Received: by 10.35.88.17 with SMTP id q17mr2295296pyl.1180672568057; Thu, 31 May 2007 21:36:08 -0700 (PDT) Received: by 10.35.79.1 with HTTP; Thu, 31 May 2007 21:36:07 -0700 (PDT) Message-ID: <626eb4530705312136n6aa78a96t45aa19a0c9912863@mail.gmail.com> Date: Fri, 1 Jun 2007 13:36:07 +0900 From: "Hidetoshi Shimokawa" Sender: freebsd@gm.nunu.org To: "Scott Long" In-Reply-To: <465F90A9.7080608@samsco.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <86wsyopf0t.wl%simokawa@FreeBSD.ORG> <465F90A9.7080608@samsco.org> X-Google-Sender-Auth: 1d598d044e7ed63a Cc: freebsd-scsi@freebsd.org Subject: Re: CAM locking 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, 01 Jun 2007 04:43:12 -0000 On 6/1/07, Scott Long wrote: > Hidetoshi Shimokawa wrote: > > Hi Scott, > > > > Thank you for your work on CAM. > > I have some questions about lock assertion. > > > > 1. Now, xpt_done() should be called with a sim lock for QUEUED ccbs. > > Why don't you add an assertion in xpt_done()? > > Accessing the sim_lock from the CCB requires enough dereferences that if > the lock isn't already held, you'll probably run into problems just > doing the derefs in the assertion. Adding a sim_lock field to the CCB > has crossed my mind, but I don't want to pollute the CCB with more > kernel-only fields if I can. I need to think some more on it. If the lock isn't already held, we have a problem sooner or later. The assertion doesn't add extra dereference except for mtx itself. I don't see any problem with adding this assertion, though it may be not perfect. I think it useful for detecting programming error and describing interface. > > 2. CAMDEBUG seems useless with WITNESS because xpt_path_path_id() requires > > a sim lock. Can we safely drop the assertion? > > Yes, this is an area that I didn't clean up very well. A lot of code in > periphs and SIMs wants to be able to use CAMDEBUG functions in random > places without the lock held, and I don't know of a good way to safely > fix this without rewriting a lot of code. I don't know if it's better > to just drop the assertion or to audit all of the code provide locked > and unlocked versions of the CAMDEBUG functions. Yes, it's very complicated to lock all debug codes. Can you document somewhere that CAMDEBUG is not usable with INVARIANTS(or WINTNESS??). -- /\ Hidetoshi Shimokawa \/ simokawa@FreeBSD.ORG From owner-freebsd-scsi@FreeBSD.ORG Fri Jun 1 04:47:08 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 8B0D716A421 for ; Fri, 1 Jun 2007 04:47:08 +0000 (UTC) (envelope-from lydianconcepts@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.176]) by mx1.freebsd.org (Postfix) with ESMTP id 660C713C447 for ; Fri, 1 Jun 2007 04:47:08 +0000 (UTC) (envelope-from lydianconcepts@gmail.com) Received: by wa-out-1112.google.com with SMTP id m33so523433wag for ; Thu, 31 May 2007 21:47:08 -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=MhH8W/cmKSeAv1svWITf9JLHaX18yZGRmgmK2DSaPj3EUASx/2l00i6Lei94flr7nRUPDfiwUdx2YmluV572D7OLrIW/lBHW2i501i1K1flOhQpS5vwGtQ8lmnuq0KGaltValRxuxglqzmTlQRJEEAQ5K4HyJ87yjugqRsRkBW0= 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=K7tFcVbxrY7/bq3TExkfKIvixY9czBNYGLerlAD0nCOPdRmlOcrLK/PFNm5r/0lXHEDaxYiCRH+VdymhlkejpVqwGNNYC61H9ScsAzA6uSH+A1Cb7BZYlfQjBKlS6WqiqriA5ufvnFupHgpk+uGvyQBaUg0uPCzKAyk8dsnrB8w= Received: by 10.114.209.1 with SMTP id h1mr1435140wag.1180673228096; Thu, 31 May 2007 21:47:08 -0700 (PDT) Received: by 10.114.24.2 with HTTP; Thu, 31 May 2007 21:47:08 -0700 (PDT) Message-ID: <7579f7fb0705312147p60255cf2r9eac5d5eb8aa5236@mail.gmail.com> Date: Thu, 31 May 2007 21:47:08 -0700 From: "Matthew Jacob" To: "Hidetoshi Shimokawa" In-Reply-To: <465F955E.7050103@samsco.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <86tztspdil.wl%simokawa@FreeBSD.ORG> <465F955E.7050103@samsco.org> Cc: freebsd-scsi@freebsd.org Subject: Re: scsi_target with multiple luns 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, 01 Jun 2007 04:47:08 -0000 Remember that scsi_target is an example. A fine example, but an example. Having a single user process that can be shot and killed, no matter how multithreaded or AIO'd, is not necessarily the wisest choice for building a target device. On 5/31/07, Scott Long wrote: > Hidetoshi Shimokawa wrote: > > I have not fully analyzed the problem but I'll describe it just for a note. > > I'd like to ask maintainers of scsi_target for further analysis. > > > > I experiance a problem with small number(1) of simq and multiple > > scsi_target(8) instances. > > > > As far as I understand, the following situation could occur under a fairly > > heavy load. > > > > 1. process A send a request -> cam send to sim > > 2. process B send a request -> blocked because the simq is full > > 3. the request of process A is finished (in the context of process A) > > 4. cam/scsi_target tries to send the request of process B. > > But the mapped memory is of process A, and scsi_target send wrong > > ccb to sim. > > > > Maybe, we should rewrite scsi_target in kernel space with GEOM support.. > > I'm unclear on how GEOM would fix this. Also, scsi targets aren't > always DA devices. I dedicated scsi_da_target device that is backed > by GEOM might be interesting, though. Even more interesting would be > a direct DMA method that required no KVA mappings for the data. > > Scott > > _______________________________________________ > 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 Fri Jun 1 04:53:25 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 ACC7A16A46C for ; Fri, 1 Jun 2007 04:53:25 +0000 (UTC) (envelope-from freebsd@gm.nunu.org) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.181]) by mx1.freebsd.org (Postfix) with ESMTP id 755E413C458 for ; Fri, 1 Jun 2007 04:53:25 +0000 (UTC) (envelope-from freebsd@gm.nunu.org) Received: by py-out-1112.google.com with SMTP id a29so744162pyi for ; Thu, 31 May 2007 21:53:24 -0700 (PDT) Received: by 10.35.101.1 with SMTP id d1mr2360622pym.1180672097101; Thu, 31 May 2007 21:28:17 -0700 (PDT) Received: by 10.35.79.1 with HTTP; Thu, 31 May 2007 21:28:17 -0700 (PDT) Message-ID: <626eb4530705312128x503bf613q740cbe855d225346@mail.gmail.com> Date: Fri, 1 Jun 2007 13:28:17 +0900 From: "Hidetoshi Shimokawa" Sender: freebsd@gm.nunu.org To: "Scott Long" In-Reply-To: <465F955E.7050103@samsco.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <86tztspdil.wl%simokawa@FreeBSD.ORG> <465F955E.7050103@samsco.org> X-Google-Sender-Auth: cffe76d2f07746ba Cc: freebsd-scsi@freebsd.org Subject: Re: scsi_target with multiple luns 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, 01 Jun 2007 04:53:25 -0000 On 6/1/07, Scott Long wrote: > > Maybe, we should rewrite scsi_target in kernel space with GEOM support.. > > I'm unclear on how GEOM would fix this. Also, scsi targets aren't > always DA devices. I dedicated scsi_da_target device that is backed > by GEOM might be interesting, though. Even more interesting would be > a direct DMA method that required no KVA mappings for the data. > > Scott I don't say GEOM fixes the problem. I just say if it's implemented in kernel, we don't need to care about the context of userland. Though it's true that it's not only for DA device, I think using GEOM would be useful for applications such as iSCSI. -- /\ Hidetoshi Shimokawa \/ simokawa@FreeBSD.ORG From owner-freebsd-scsi@FreeBSD.ORG Fri Jun 1 05:32:25 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 D277E16A468; Fri, 1 Jun 2007 05:32:25 +0000 (UTC) (envelope-from avatar@mmlab.cse.yzu.edu.tw) Received: from www.mmlab.cse.yzu.edu.tw (www.mmlab.cse.yzu.edu.tw [140.138.150.166]) by mx1.freebsd.org (Postfix) with ESMTP id 94FD013C46E; Fri, 1 Jun 2007 05:32:25 +0000 (UTC) (envelope-from avatar@mmlab.cse.yzu.edu.tw) Received: by www.mmlab.cse.yzu.edu.tw (qmail, from userid 1000) id 7B2308C9BB3; Fri, 1 Jun 2007 13:01:08 +0800 (CST) Received: from localhost (localhost [127.0.0.1]) by www.mmlab.cse.yzu.edu.tw (qmail) with ESMTP id 361F88C9A9A; Fri, 1 Jun 2007 13:01:08 +0800 (CST) Date: Fri, 1 Jun 2007 13:01:08 +0800 (CST) From: Tai-hwa Liang To: Jiawei Ye In-Reply-To: Message-ID: <07060112584613.12429@www.mmlab.cse.yzu.edu.tw> References: <20070531183719.B77697@fledge.watson.org> <20070531180555.GA10910@kobe.laptop> <20070601010212.F77697@fledge.watson.org> <626eb4530705311711h69322a54ga7c49aea3fe4ab27@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Giorgos Keramidas , Robert Watson , current@freebsd.org, scsi@freebsd.org Subject: Re: watch(8) stuck in devdrn 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, 01 Jun 2007 05:32:26 -0000 On Fri, 1 Jun 2007, Jiawei Ye wrote: > On 6/1/07, Hidetoshi Shimokawa wrote: >> The problem doesn't seem specific to tty sub system. >> I have similar problem with scsi_target. >> >> On 6/1/07, Robert Watson wrote: >> > >> > On Thu, 31 May 2007, Giorgos Keramidas wrote: >> > >> > > On 2007-05-31 18:38, Robert Watson wrote: >> > >> I was using watch(8) this afternoon, and on trying to quit, ran into >> this: >> > >> >> > >> peppercorn:~> ps axl | grep watch >> > >> 0 14200 14194 0 -8 0 3416 1056 devdrn D p2- 0:00.01 >> watch -W tt >> > >> >> > >> It was running on a pty, but the target tty was ttyv1. >> > > >> > > If you have kern.pts.enable=1 you may have to use: >> > > http://hg.hellug.gr/freebsd/src-keramida/file/944ac3982de1/pty-devdrn >> > > >> > > Without this patch and kern.pts.enable=1 all ptys seem to get stuck in >> > > devdrn on process exit. AFAIK, Kostik Belousov and Tor Egge know this >> and >> > > are already working on a fix: >> > >> > I'm not using pts.enable on this box. >> > > mount_smbfs has been having this problem for quite a while too. By any chance you can give following patches a try? http://people.freebsd.org/~kib/misc/destroy_dev_sched.6.patch http://people.freebsd.org/~avatar/destroy_dev_sched_addon.2.patch -- Thanks, Tai-hwa Liang From owner-freebsd-scsi@FreeBSD.ORG Fri Jun 1 06:00:09 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 3BD7416A468 for ; Fri, 1 Jun 2007 06:00:09 +0000 (UTC) (envelope-from freebsd@gm.nunu.org) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.177]) by mx1.freebsd.org (Postfix) with ESMTP id DD24013C4AE for ; Fri, 1 Jun 2007 06:00:08 +0000 (UTC) (envelope-from freebsd@gm.nunu.org) Received: by py-out-1112.google.com with SMTP id a29so767077pyi for ; Thu, 31 May 2007 23:00:08 -0700 (PDT) Received: by 10.35.91.10 with SMTP id t10mr2419782pyl.1180677608257; Thu, 31 May 2007 23:00:08 -0700 (PDT) Received: by 10.35.79.1 with HTTP; Thu, 31 May 2007 23:00:08 -0700 (PDT) Message-ID: <626eb4530705312300n177e677cyac2e8ba69039160d@mail.gmail.com> Date: Fri, 1 Jun 2007 15:00:08 +0900 From: "Hidetoshi Shimokawa" Sender: freebsd@gm.nunu.org To: "Matthew Jacob" In-Reply-To: <7579f7fb0705312147p60255cf2r9eac5d5eb8aa5236@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <86tztspdil.wl%simokawa@FreeBSD.ORG> <465F955E.7050103@samsco.org> <7579f7fb0705312147p60255cf2r9eac5d5eb8aa5236@mail.gmail.com> X-Google-Sender-Auth: ebc36b884d9d4b40 Cc: freebsd-scsi@freebsd.org Subject: Re: scsi_target with multiple luns 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, 01 Jun 2007 06:00:09 -0000 Yes, scsi_target(8) is an example. But the problem I described is actually a problem of targ(4) (scsi_target.c). The userland can do nothing about this problem. Or do you mean targ(4) is also an example? On 6/1/07, Matthew Jacob wrote: > Remember that scsi_target is an example. A fine example, but an > example. Having a single user process that can be shot and killed, no > matter how multithreaded or AIO'd, is not necessarily the wisest > choice for building a target device. > > > On 5/31/07, Scott Long wrote: > > Hidetoshi Shimokawa wrote: > > > I have not fully analyzed the problem but I'll describe it just for a note. > > > I'd like to ask maintainers of scsi_target for further analysis. > > > > > > I experiance a problem with small number(1) of simq and multiple > > > scsi_target(8) instances. > > > > > > As far as I understand, the following situation could occur under a fairly > > > heavy load. > > > > > > 1. process A send a request -> cam send to sim > > > 2. process B send a request -> blocked because the simq is full > > > 3. the request of process A is finished (in the context of process A) > > > 4. cam/scsi_target tries to send the request of process B. > > > But the mapped memory is of process A, and scsi_target send wrong > > > ccb to sim. > > > > > > Maybe, we should rewrite scsi_target in kernel space with GEOM support.. > > > > I'm unclear on how GEOM would fix this. Also, scsi targets aren't > > always DA devices. I dedicated scsi_da_target device that is backed > > by GEOM might be interesting, though. Even more interesting would be > > a direct DMA method that required no KVA mappings for the data. > > > > Scott > > > > _______________________________________________ > > 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" > > > > -- /\ Hidetoshi Shimokawa \/ simokawa@FreeBSD.ORG From owner-freebsd-scsi@FreeBSD.ORG Fri Jun 1 06:12:49 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 7A9A916A400; Fri, 1 Jun 2007 06:12:49 +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 15CD113C447; Fri, 1 Jun 2007 06:12:48 +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 l516CgmZ080083; Fri, 1 Jun 2007 00:12:42 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <465FB8D7.9010102@samsco.org> Date: Fri, 01 Jun 2007 00:12:39 -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: Hidetoshi Shimokawa References: <86tztspdil.wl%simokawa@FreeBSD.ORG> <465F955E.7050103@samsco.org> <7579f7fb0705312147p60255cf2r9eac5d5eb8aa5236@mail.gmail.com> <626eb4530705312300n177e677cyac2e8ba69039160d@mail.gmail.com> In-Reply-To: <626eb4530705312300n177e677cyac2e8ba69039160d@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]); Fri, 01 Jun 2007 00:12:43 -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_target with multiple luns 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, 01 Jun 2007 06:12:49 -0000 Many companies use the scsi_target and targ code as a basis for prototyping and developing target code that is more suited to their needs. Scott Hidetoshi Shimokawa wrote: > Yes, scsi_target(8) is an example. > But the problem I described is actually a problem of targ(4) > (scsi_target.c). > The userland can do nothing about this problem. > Or do you mean targ(4) is also an example? > > On 6/1/07, Matthew Jacob wrote: >> Remember that scsi_target is an example. A fine example, but an >> example. Having a single user process that can be shot and killed, no >> matter how multithreaded or AIO'd, is not necessarily the wisest >> choice for building a target device. >> >> >> On 5/31/07, Scott Long wrote: >> > Hidetoshi Shimokawa wrote: >> > > I have not fully analyzed the problem but I'll describe it just >> for a note. >> > > I'd like to ask maintainers of scsi_target for further analysis. >> > > >> > > I experiance a problem with small number(1) of simq and multiple >> > > scsi_target(8) instances. >> > > >> > > As far as I understand, the following situation could occur under >> a fairly >> > > heavy load. >> > > >> > > 1. process A send a request -> cam send to sim >> > > 2. process B send a request -> blocked because the simq is full >> > > 3. the request of process A is finished (in the context of process A) >> > > 4. cam/scsi_target tries to send the request of process B. >> > > But the mapped memory is of process A, and scsi_target send wrong >> > > ccb to sim. >> > > >> > > Maybe, we should rewrite scsi_target in kernel space with GEOM >> support.. >> > >> > I'm unclear on how GEOM would fix this. Also, scsi targets aren't >> > always DA devices. I dedicated scsi_da_target device that is backed >> > by GEOM might be interesting, though. Even more interesting would be >> > a direct DMA method that required no KVA mappings for the data. >> > >> > Scott >> > >> > _______________________________________________ >> > 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 Fri Jun 1 06:13:03 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 3CC8A16A400 for ; Fri, 1 Jun 2007 06:13:03 +0000 (UTC) (envelope-from lydianconcepts@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.227]) by mx1.freebsd.org (Postfix) with ESMTP id DD73D13C468 for ; Fri, 1 Jun 2007 06:13:02 +0000 (UTC) (envelope-from lydianconcepts@gmail.com) Received: by nz-out-0506.google.com with SMTP id 14so364250nzn for ; Thu, 31 May 2007 23:13:02 -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=Nq5vAzoTS67C6goaKansjJpt4afy2ztZnIt3j4UunPoWVD61/bJTx8L5+IfdaC0sPMabAvw/NHsSRffoiGfyA6pWtf/XFovFCVY8cJe1JuMdGaBsDdZdKBjnIW7T/zOvM8uxbp6FLY7pSEW5AAngSoFzn7y19RM/jWLhE/8g/6o= 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=d479HOdGQA0Uwvm7X9fHr5OyxiEmDUvkdQGh1VGqSLtNJqyfvhaN6XKrq5YscqwxqJYNdvMlAcz1nnPmWAV5qUPwbZLTWQzEiZz4K9SK6BpZAevwj7QX7IZJPm43VwEIji6Ykta8flbk7BqyBcas+44g6eAtj3YOh+qx027d9c4= Received: by 10.114.89.1 with SMTP id m1mr1449993wab.1180678381818; Thu, 31 May 2007 23:13:01 -0700 (PDT) Received: by 10.114.24.2 with HTTP; Thu, 31 May 2007 23:13:01 -0700 (PDT) Message-ID: <7579f7fb0705312313p5c766887s1c2e598884513d6e@mail.gmail.com> Date: Thu, 31 May 2007 23:13:01 -0700 From: "Matthew Jacob" To: "Hidetoshi Shimokawa" In-Reply-To: <626eb4530705312300n177e677cyac2e8ba69039160d@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <86tztspdil.wl%simokawa@FreeBSD.ORG> <465F955E.7050103@samsco.org> <7579f7fb0705312147p60255cf2r9eac5d5eb8aa5236@mail.gmail.com> <626eb4530705312300n177e677cyac2e8ba69039160d@mail.gmail.com> Cc: freebsd-scsi@freebsd.org Subject: Re: scsi_target with multiple luns 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, 01 Jun 2007 06:13:03 -0000 Yes. None of the extant stuff is deployable as solid solution without reworking. On 5/31/07, Hidetoshi Shimokawa wrote: > Yes, scsi_target(8) is an example. > But the problem I described is actually a problem of targ(4) (scsi_target.c). > The userland can do nothing about this problem. > Or do you mean targ(4) is also an example? > > On 6/1/07, Matthew Jacob wrote: > > Remember that scsi_target is an example. A fine example, but an > > example. Having a single user process that can be shot and killed, no > > matter how multithreaded or AIO'd, is not necessarily the wisest > > choice for building a target device. > > > > > > On 5/31/07, Scott Long wrote: > > > Hidetoshi Shimokawa wrote: > > > > I have not fully analyzed the problem but I'll describe it just for a note. > > > > I'd like to ask maintainers of scsi_target for further analysis. > > > > > > > > I experiance a problem with small number(1) of simq and multiple > > > > scsi_target(8) instances. > > > > > > > > As far as I understand, the following situation could occur under a fairly > > > > heavy load. > > > > > > > > 1. process A send a request -> cam send to sim > > > > 2. process B send a request -> blocked because the simq is full > > > > 3. the request of process A is finished (in the context of process A) > > > > 4. cam/scsi_target tries to send the request of process B. > > > > But the mapped memory is of process A, and scsi_target send wrong > > > > ccb to sim. > > > > > > > > Maybe, we should rewrite scsi_target in kernel space with GEOM support.. > > > > > > I'm unclear on how GEOM would fix this. Also, scsi targets aren't > > > always DA devices. I dedicated scsi_da_target device that is backed > > > by GEOM might be interesting, though. Even more interesting would be > > > a direct DMA method that required no KVA mappings for the data. > > > > > > Scott > > > > > > _______________________________________________ > > > 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" > > > > > > > > > > -- > /\ Hidetoshi Shimokawa > \/ simokawa@FreeBSD.ORG > From owner-freebsd-scsi@FreeBSD.ORG Fri Jun 1 06:50:27 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 3090D16A468 for ; Fri, 1 Jun 2007 06:50:27 +0000 (UTC) (envelope-from freebsd@gm.nunu.org) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.183]) by mx1.freebsd.org (Postfix) with ESMTP id D9FBB13C457 for ; Fri, 1 Jun 2007 06:50:26 +0000 (UTC) (envelope-from freebsd@gm.nunu.org) Received: by py-out-1112.google.com with SMTP id a29so785000pyi for ; Thu, 31 May 2007 23:50:26 -0700 (PDT) Received: by 10.35.70.2 with SMTP id x2mr2492652pyk.1180680625716; Thu, 31 May 2007 23:50:25 -0700 (PDT) Received: by 10.35.79.1 with HTTP; Thu, 31 May 2007 23:50:25 -0700 (PDT) Message-ID: <626eb4530705312350n53e97987sff099c3bbd5f9f3a@mail.gmail.com> Date: Fri, 1 Jun 2007 15:50:25 +0900 From: "Hidetoshi Shimokawa" Sender: freebsd@gm.nunu.org To: "Matthew Jacob" In-Reply-To: <7579f7fb0705312313p5c766887s1c2e598884513d6e@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <86tztspdil.wl%simokawa@FreeBSD.ORG> <465F955E.7050103@samsco.org> <7579f7fb0705312147p60255cf2r9eac5d5eb8aa5236@mail.gmail.com> <626eb4530705312300n177e677cyac2e8ba69039160d@mail.gmail.com> <7579f7fb0705312313p5c766887s1c2e598884513d6e@mail.gmail.com> X-Google-Sender-Auth: d7a2167b4ddb31cd Cc: freebsd-scsi@freebsd.org Subject: Re: scsi_target with multiple luns 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, 01 Jun 2007 06:50:27 -0000 OK. Now I understand that they are prototypes... Actually, sbp_targ(4) is the hardest part to lock the firewire stack. On 6/1/07, Matthew Jacob wrote: > Yes. None of the extant stuff is deployable as solid solution without reworking. > > On 5/31/07, Hidetoshi Shimokawa wrote: > > Yes, scsi_target(8) is an example. > > But the problem I described is actually a problem of targ(4) (scsi_target.c). > > The userland can do nothing about this problem. > > Or do you mean targ(4) is also an example? > > > > On 6/1/07, Matthew Jacob wrote: > > > Remember that scsi_target is an example. A fine example, but an > > > example. Having a single user process that can be shot and killed, no > > > matter how multithreaded or AIO'd, is not necessarily the wisest > > > choice for building a target device. > > > > > > > > > On 5/31/07, Scott Long wrote: > > > > Hidetoshi Shimokawa wrote: > > > > > I have not fully analyzed the problem but I'll describe it just for a note. > > > > > I'd like to ask maintainers of scsi_target for further analysis. > > > > > > > > > > I experiance a problem with small number(1) of simq and multiple > > > > > scsi_target(8) instances. > > > > > > > > > > As far as I understand, the following situation could occur under a fairly > > > > > heavy load. > > > > > > > > > > 1. process A send a request -> cam send to sim > > > > > 2. process B send a request -> blocked because the simq is full > > > > > 3. the request of process A is finished (in the context of process A) > > > > > 4. cam/scsi_target tries to send the request of process B. > > > > > But the mapped memory is of process A, and scsi_target send wrong > > > > > ccb to sim. > > > > > > > > > > Maybe, we should rewrite scsi_target in kernel space with GEOM support.. > > > > > > > > I'm unclear on how GEOM would fix this. Also, scsi targets aren't > > > > always DA devices. I dedicated scsi_da_target device that is backed > > > > by GEOM might be interesting, though. Even more interesting would be > > > > a direct DMA method that required no KVA mappings for the data. > > > > > > > > Scott > > > > > > > > _______________________________________________ > > > > 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" > > > > > > > > > > > > > > > > -- > > /\ Hidetoshi Shimokawa > > \/ simokawa@FreeBSD.ORG > > > > -- /\ Hidetoshi Shimokawa \/ simokawa@FreeBSD.ORG From owner-freebsd-scsi@FreeBSD.ORG Fri Jun 1 10:55:41 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 109C216A46D; Fri, 1 Jun 2007 10:55:41 +0000 (UTC) (envelope-from avatar@mmlab.cse.yzu.edu.tw) Received: from www.mmlab.cse.yzu.edu.tw (www.mmlab.cse.yzu.edu.tw [140.138.150.166]) by mx1.freebsd.org (Postfix) with ESMTP id C82DF13C468; Fri, 1 Jun 2007 10:55:40 +0000 (UTC) (envelope-from avatar@mmlab.cse.yzu.edu.tw) Received: by www.mmlab.cse.yzu.edu.tw (qmail, from userid 1000) id F11008C9FD3; Fri, 1 Jun 2007 18:55:39 +0800 (CST) Received: from localhost (localhost [127.0.0.1]) by www.mmlab.cse.yzu.edu.tw (qmail) with ESMTP id EE2778C9FB4; Fri, 1 Jun 2007 18:55:39 +0800 (CST) Date: Fri, 1 Jun 2007 18:55:39 +0800 (CST) From: Tai-hwa Liang To: Kostik Belousov In-Reply-To: <20070601084859.GL2268@deviant.kiev.zoral.com.ua> Message-ID: <07060118545413.14036@www.mmlab.cse.yzu.edu.tw> References: <20070531183719.B77697@fledge.watson.org> <20070531180555.GA10910@kobe.laptop> <20070601010212.F77697@fledge.watson.org> <626eb4530705311711h69322a54ga7c49aea3fe4ab27@mail.gmail.com> <07060112584613.12429@www.mmlab.cse.yzu.edu.tw> <20070601084859.GL2268@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: current@freebsd.org, scsi@freebsd.org, Robert Watson , Giorgos Keramidas , Jiawei Ye Subject: Re: watch(8) stuck in devdrn 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, 01 Jun 2007 10:55:41 -0000 On Fri, 1 Jun 2007, Kostik Belousov wrote: > On Fri, Jun 01, 2007 at 01:01:08PM +0800, Tai-hwa Liang wrote: >> On Fri, 1 Jun 2007, Jiawei Ye wrote: >>> On 6/1/07, Hidetoshi Shimokawa wrote: >>>> The problem doesn't seem specific to tty sub system. >>>> I have similar problem with scsi_target. >>>> >>>> On 6/1/07, Robert Watson wrote: >>>>> >>>>> On Thu, 31 May 2007, Giorgos Keramidas wrote: >>>>> >>>>>> On 2007-05-31 18:38, Robert Watson wrote: >>>>>>> I was using watch(8) this afternoon, and on trying to quit, ran into >>>> this: >>>>>>> >>>>>>> peppercorn:~> ps axl | grep watch >>>>>>> 0 14200 14194 0 -8 0 3416 1056 devdrn D p2- 0:00.01 >>>> watch -W tt >>>>>>> >>>>>>> It was running on a pty, but the target tty was ttyv1. >>>>>> >>>>>> If you have kern.pts.enable=1 you may have to use: >>>>>> http://hg.hellug.gr/freebsd/src-keramida/file/944ac3982de1/pty-devdrn >>>>>> >>>>>> Without this patch and kern.pts.enable=1 all ptys seem to get stuck in >>>>>> devdrn on process exit. AFAIK, Kostik Belousov and Tor Egge know >>>> this and >>>>>> are already working on a fix: >>>>> >>>>> I'm not using pts.enable on this box. >>>>> >>> mount_smbfs has been having this problem for quite a while too. >> >> By any chance you can give following patches a try? >> >> http://people.freebsd.org/~kib/misc/destroy_dev_sched.6.patch > http://people.freebsd.org/~kib/misc/destroy_dev_sched.8.patch >> http://people.freebsd.org/~avatar/destroy_dev_sched_addon.2.patch > At least snp(4) change potentially opens the races. Could you be more specific on this issue? -- Thanks, Tai-hwa Liang