From owner-freebsd-scsi@FreeBSD.ORG Sun Oct 31 14:10:32 2010 Return-Path: Delivered-To: freebsd-scsi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 831C1106564A for ; Sun, 31 Oct 2010 14:10:32 +0000 (UTC) (envelope-from emaste@FreeBSD.org) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by mx1.freebsd.org (Postfix) with ESMTP id 05A2D8FC18 for ; Sun, 31 Oct 2010 14:10:31 +0000 (UTC) Received: from labgw2.phaedrus.sandvine.com (192.168.222.22) by WTL-EXCH-1.sandvine.com (192.168.196.31) with Microsoft SMTP Server id 14.0.694.0; Sun, 31 Oct 2010 10:10:31 -0400 Received: by labgw2.phaedrus.sandvine.com (Postfix, from userid 10332) id 1EB0E33C00; Sun, 31 Oct 2010 10:10:31 -0400 (EDT) Date: Sun, 31 Oct 2010 10:10:31 -0400 From: Ed Maste To: Scott Long Message-ID: <20101031141031.GA14661@sandvine.com> References: <20101026160457.GA61133@sandvine.com> <9EC3B874-B089-4ED4-9A12-FA7A0E170A7B@samsco.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <9EC3B874-B089-4ED4-9A12-FA7A0E170A7B@samsco.org> User-Agent: Mutt/1.4.2.1i Cc: freebsd-scsi@FreeBSD.org Subject: Re: camcontrol rescan all fails if there is no bus 0 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, 31 Oct 2010 14:10:32 -0000 On Tue, Oct 26, 2010 at 10:41:11AM -0600, Scott Long wrote: > Ok, I guess I need to see if CAM_XPT_PATH_ID can get returned from the > devmatch. Is that not handled by this code that parses the returned XPT_DEV_MATCH results in in reset_or_rescan_bus: for (i = 0; i < matchccb.cdm.num_matches; i++) { struct bus_match_result *bus_result; ... bus_result = &matchccb.cdm.matches[i].result.bus_result; /* * We don't want to rescan or reset the xpt bus. * See above. */ if ((int)bus_result->path_id == -1) continue; That is, we do the actual rescan only on legitimate busses after the XPT_DEV_MATCH ioctl returns. > What happens with this patch if you run it with no real buses > registered (i.e. cam module present, but no SIMs present)? From the user's perspective, with the stock camcontrol and no registered busses I get: [root@edlaptop ~]# camcontrol rescan all camcontrol: CAMIOCOMMAND ioctl failed: Invalid argument With the patch: [root@edlaptop ~]# ./camcontrol rescan all [root@edlaptop ~]# And then with a umass device attached: [root@edlaptop ~]# ./camcontrol rescan all Re-scan of bus 0 was successful -Ed From owner-freebsd-scsi@FreeBSD.ORG Sun Oct 31 17:10:20 2010 Return-Path: Delivered-To: freebsd-scsi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EEF57106567A; Sun, 31 Oct 2010 17:10:20 +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 ABDA18FC0A; Sun, 31 Oct 2010 17:10:20 +0000 (UTC) Received: from [127.0.0.1] (pooker.samsco.org [168.103.85.57]) (authenticated bits=0) by pooker.samsco.org (8.14.4/8.14.4) with ESMTP id o9VHAHxi088149; Sun, 31 Oct 2010 11:10:17 -0600 (MDT) (envelope-from scottl@samsco.org) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Scott Long In-Reply-To: <20101031141031.GA14661@sandvine.com> Date: Sun, 31 Oct 2010 11:10:16 -0600 Content-Transfer-Encoding: 7bit Message-Id: <739687DC-7412-4FAB-A570-A2FD9DC3E06A@samsco.org> References: <20101026160457.GA61133@sandvine.com> <9EC3B874-B089-4ED4-9A12-FA7A0E170A7B@samsco.org> <20101031141031.GA14661@sandvine.com> To: Ed Maste X-Mailer: Apple Mail (2.1081) X-Spam-Status: No, score=-50.0 required=3.8 tests=ALL_TRUSTED, T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on pooker.samsco.org Cc: freebsd-scsi@FreeBSD.org Subject: Re: camcontrol rescan all fails if there is no bus 0 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, 31 Oct 2010 17:10:21 -0000 On Oct 31, 2010, at 8:10 AM, Ed Maste wrote: > On Tue, Oct 26, 2010 at 10:41:11AM -0600, Scott Long wrote: > >> Ok, I guess I need to see if CAM_XPT_PATH_ID can get returned from the >> devmatch. > > Is that not handled by this code that parses the returned XPT_DEV_MATCH > results in in reset_or_rescan_bus: > > for (i = 0; i < matchccb.cdm.num_matches; i++) { > struct bus_match_result *bus_result; > > ... > > bus_result = &matchccb.cdm.matches[i].result.bus_result; > > /* > * We don't want to rescan or reset the xpt bus. > * See above. > */ > if ((int)bus_result->path_id == -1) > continue; > > That is, we do the actual rescan only on legitimate busses after the > XPT_DEV_MATCH ioctl returns. > >> What happens with this patch if you run it with no real buses >> registered (i.e. cam module present, but no SIMs present)? > > From the user's perspective, with the stock camcontrol and no > registered busses I get: > > [root@edlaptop ~]# camcontrol rescan all > camcontrol: CAMIOCOMMAND ioctl failed: Invalid argument > > With the patch: > > [root@edlaptop ~]# ./camcontrol rescan all > [root@edlaptop ~]# > > And then with a umass device attached: > > [root@edlaptop ~]# ./camcontrol rescan all > Re-scan of bus 0 was successful > > -Ed That all looks entirely reasonable. Thanks for researching it. Scott From owner-freebsd-scsi@FreeBSD.ORG Sun Oct 31 19:16:36 2010 Return-Path: Delivered-To: freebsd-scsi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7A79B106564A for ; Sun, 31 Oct 2010 19:16:36 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 889A58FC0A for ; Sun, 31 Oct 2010 19:16:35 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id VAA05844; Sun, 31 Oct 2010 21:16:31 +0200 (EET) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1PCdOJ-000Pei-Jw; Sun, 31 Oct 2010 21:16:31 +0200 Message-ID: <4CCDC08E.7020506@icyb.net.ua> Date: Sun, 31 Oct 2010 21:16:30 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Ed Maste References: <20101026160457.GA61133@sandvine.com> <9EC3B874-B089-4ED4-9A12-FA7A0E170A7B@samsco.org> <20101031141031.GA14661@sandvine.com> In-Reply-To: <20101031141031.GA14661@sandvine.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-scsi@FreeBSD.org Subject: Re: camcontrol rescan all fails if there is no bus 0 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, 31 Oct 2010 19:16:36 -0000 on 31/10/2010 16:10 Ed Maste said the following: > On Tue, Oct 26, 2010 at 10:41:11AM -0600, Scott Long wrote: > >> Ok, I guess I need to see if CAM_XPT_PATH_ID can get returned from the >> devmatch. > > Is that not handled by this code that parses the returned XPT_DEV_MATCH > results in in reset_or_rescan_bus: > > for (i = 0; i < matchccb.cdm.num_matches; i++) { > struct bus_match_result *bus_result; > > ... > > bus_result = &matchccb.cdm.matches[i].result.bus_result; > > /* > * We don't want to rescan or reset the xpt bus. > * See above. > */ > if ((int)bus_result->path_id == -1) > continue; > > That is, we do the actual rescan only on legitimate busses after the > XPT_DEV_MATCH ioctl returns. > >> What happens with this patch if you run it with no real buses >> registered (i.e. cam module present, but no SIMs present)? > > From the user's perspective, with the stock camcontrol and no > registered busses I get: > > [root@edlaptop ~]# camcontrol rescan all > camcontrol: CAMIOCOMMAND ioctl failed: Invalid argument > > With the patch: > > [root@edlaptop ~]# ./camcontrol rescan all > [root@edlaptop ~]# > > And then with a umass device attached: > > [root@edlaptop ~]# ./camcontrol rescan all > Re-scan of bus 0 was successful Can you test a synthetic situation where you have e.g. bus 1, but no bus 0 ? E.g. by having two umass devices connected during boot and then removing one of them. -- Andriy Gapon From owner-freebsd-scsi@FreeBSD.ORG Sun Oct 31 20:29:17 2010 Return-Path: Delivered-To: freebsd-scsi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 53A51106564A; Sun, 31 Oct 2010 20:29:17 +0000 (UTC) (envelope-from emaste@freebsd.org) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by mx1.freebsd.org (Postfix) with ESMTP id 103448FC08; Sun, 31 Oct 2010 20:29:16 +0000 (UTC) Received: from labgw2.phaedrus.sandvine.com (192.168.222.22) by WTL-EXCH-1.sandvine.com (192.168.196.31) with Microsoft SMTP Server id 14.0.694.0; Sun, 31 Oct 2010 16:29:16 -0400 Received: by labgw2.phaedrus.sandvine.com (Postfix, from userid 10332) id 0C7C233C00; Sun, 31 Oct 2010 16:29:16 -0400 (EDT) Date: Sun, 31 Oct 2010 16:29:16 -0400 From: Ed Maste To: Andriy Gapon Message-ID: <20101031202915.GA23291@sandvine.com> References: <20101026160457.GA61133@sandvine.com> <9EC3B874-B089-4ED4-9A12-FA7A0E170A7B@samsco.org> <20101031141031.GA14661@sandvine.com> <4CCDC08E.7020506@icyb.net.ua> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <4CCDC08E.7020506@icyb.net.ua> User-Agent: Mutt/1.4.2.1i Cc: freebsd-scsi@FreeBSD.org, Ed Maste Subject: Re: camcontrol rescan all fails if there is no bus 0 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, 31 Oct 2010 20:29:17 -0000 On Sun, Oct 31, 2010 at 09:16:30PM +0200, Andriy Gapon wrote: > Can you test a synthetic situation where you have e.g. bus 1, but no > bus 0 ? E.g. by having two umass devices connected during boot and > then removing one of them. Yes, good idea - stock camcontrol: [root@edlaptop ~]# camcontrol rescan all camcontrol: CAMIOCOMMAND ioctl failed: Invalid argument With the patch: [root@edlaptop ~]# ./camcontrol rescan all Re-scan of bus 1 was successful -Ed From owner-freebsd-scsi@FreeBSD.ORG Mon Nov 1 06:59:52 2010 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1BA72106566B; Mon, 1 Nov 2010 06:59:52 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 2750D8FC08; Mon, 1 Nov 2010 06:59:50 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id IAA14111; Mon, 01 Nov 2010 08:59:49 +0200 (EET) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1PCoMu-0002c0-OJ; Mon, 01 Nov 2010 08:59:48 +0200 Message-ID: <4CCE6563.1090808@icyb.net.ua> Date: Mon, 01 Nov 2010 08:59:47 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Ed Maste References: <20101026160457.GA61133@sandvine.com> <9EC3B874-B089-4ED4-9A12-FA7A0E170A7B@samsco.org> <20101031141031.GA14661@sandvine.com> <4CCDC08E.7020506@icyb.net.ua> <20101031202915.GA23291@sandvine.com> In-Reply-To: <20101031202915.GA23291@sandvine.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-scsi@freebsd.org Subject: Re: camcontrol rescan all fails if there is no bus 0 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, 01 Nov 2010 06:59:52 -0000 on 31/10/2010 22:29 Ed Maste said the following: > On Sun, Oct 31, 2010 at 09:16:30PM +0200, Andriy Gapon wrote: > >> Can you test a synthetic situation where you have e.g. bus 1, but no >> bus 0 ? E.g. by having two umass devices connected during boot and >> then removing one of them. > > Yes, good idea - stock camcontrol: > > [root@edlaptop ~]# camcontrol rescan all > camcontrol: CAMIOCOMMAND ioctl failed: Invalid argument > > With the patch: > > [root@edlaptop ~]# ./camcontrol rescan all > Re-scan of bus 1 was successful Cool! Thank you. -- Andriy Gapon From owner-freebsd-scsi@FreeBSD.ORG Mon Nov 1 11:07:05 2010 Return-Path: Delivered-To: freebsd-scsi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 41DF3106566B for ; Mon, 1 Nov 2010 11:07:05 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 2EE488FC2E for ; Mon, 1 Nov 2010 11:07:05 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id oA1B75d6019286 for ; Mon, 1 Nov 2010 11:07:05 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id oA1B749N019284 for freebsd-scsi@FreeBSD.org; Mon, 1 Nov 2010 11:07:04 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 1 Nov 2010 11:07:04 GMT Message-Id: <201011011107.oA1B749N019284@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 freebsd-scsi@FreeBSD.org 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, 01 Nov 2010 11:07:05 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o docs/151336 scsi Missing documentation of scsi_ and ata_ functions in c o kern/149502 scsi [mpt] Latent buglet in debug print code o kern/148083 scsi [aac] Strange device reporting o kern/147704 scsi [mpt] sys/dev/mpt: new chip revision, partially unsupp o kern/146287 scsi [ciss] ciss(4) cannot see more than one SmartArray con o kern/145768 scsi [mpt] can't perform I/O on SAS based SAN disk in freeb o kern/144648 scsi [aac] Strange values of speed and bus width in dmesg o kern/144301 scsi [ciss] [hang] HP proliant server locks when using ciss o kern/142351 scsi [mpt] LSILogic driver performance problems o kern/141934 scsi [cam] [patch] add support for SEAGATE DAT Scopion 130 o kern/134488 scsi [mpt] MPT SCSI driver probes max. 8 LUNs per device o kern/132250 scsi [ciss] ciss driver does not support more then 15 drive o kern/132206 scsi [mpt] system panics on boot when mirroring and 2nd dri o kern/130621 scsi [mpt] tranfer rate is inscrutable slow when use lsi213 o kern/129602 scsi [ahd] ahd(4) gets confused and wedges SCSI bus o kern/128452 scsi [sa] [panic] Accessing SCSI tape drive randomly crashe o kern/128245 scsi [scsi] "inquiry data fails comparison at DV1 step" [re o kern/127927 scsi [isp] isp(4) target driver crashes kernel when set up o kern/124667 scsi [amd] [panic] FreeBSD-7 kernel page faults at amd-scsi o kern/123674 scsi [ahc] ahc driver dumping o sparc/121676 scsi [iscsi] iscontrol do not connect iscsi-target on sparc o kern/120487 scsi [sg] scsi_sg incompatible with scanners o kern/120247 scsi [mpt] FreeBSD 6.3 and LSI Logic 1030 = only 3.300MB/s o kern/119668 scsi [cam] [patch] certain errors are too verbose comparing o kern/114597 scsi [sym] System hangs at SCSI bus reset with dual HBAs o kern/110847 scsi [ahd] Tyan U320 onboard problem with more than 3 disks o kern/99954 scsi [ahc] reading from DVD failes on 6.x [regression] o kern/94838 scsi Kernel panic while mounting SD card with lock switch o o kern/92798 scsi [ahc] SCSI problem with timeouts o kern/90282 scsi [sym] SCSI bus resets cause loss of ch device o kern/76178 scsi [ahd] Problem with ahd and large SCSI Raid system o kern/74627 scsi [ahc] [hang] Adaptec 2940U2W Can't boot 5.3 s kern/61165 scsi [panic] kernel page fault after calling cam_send_ccb o kern/60641 scsi [sym] Sporadic SCSI bus resets with 53C810 under load o kern/60598 scsi wire down of scsi devices conflicts with config s kern/57398 scsi [mly] Current fails to install on mly(4) based RAID di o bin/57088 scsi [cam] [patch] for a possible fd leak in libcam.c o kern/52638 scsi [panic] SCSI U320 on SMP server won't run faster than o kern/44587 scsi dev/dpt/dpt.h is missing defines required for DPT_HAND o kern/40895 scsi wierd kernel / device driver bug o kern/39388 scsi ncr/sym drivers fail with 53c810 and more than 256MB m o kern/35234 scsi World access to /dev/pass? (for scanner) requires acce 42 problems total. From owner-freebsd-scsi@FreeBSD.ORG Mon Nov 1 21:19:00 2010 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8D7E8106566C for ; Mon, 1 Nov 2010 21:19:00 +0000 (UTC) (envelope-from bsdboot@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 580A48FC2A for ; Mon, 1 Nov 2010 21:18:59 +0000 (UTC) Received: by pwi8 with SMTP id 8so1390929pwi.13 for ; Mon, 01 Nov 2010 14:18:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=QrAX5GdH15D/cfAmjbjOVMAnCICwuN/KRBRAQY6wGkM=; b=CouzcMguXT7OQwC49jlKkW6j8kMQF/Dt7Px0eV7vkeuCg6aE9nQvspxdSuFwHMf6ym JXfNVHjerKz6cfwN1wqFWEJVf6Vk02Y+pEBkJF4kYH/eZcPnULzbGqcpQSTy8iSsr/3D J69o6PAzkPo0DIrWZPmUaLmuaYcUsI7rkSaHg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=oFoteKXRZZ80HcHoCBrAzDm2MVkfKldyQzpJp5JuxICNQrEhGULdsgJZwdubfwZAQh 3kF8c8dVY0n+pHLL4Yn7gUqDSlgnnO+RsPGhLNO+weSSArfOoxRkwCjkOF8JVtgOyN0I CSbj1Rz0fOT7HfLWfUzJnlblbKvNNOs7xv7No= MIME-Version: 1.0 Received: by 10.142.163.20 with SMTP id l20mr4540685wfe.265.1288646339698; Mon, 01 Nov 2010 14:18:59 -0700 (PDT) Received: by 10.143.13.19 with HTTP; Mon, 1 Nov 2010 14:18:59 -0700 (PDT) In-Reply-To: References: <4CC75FAE.9060708@feral.com> <4CC7AB7E.3050705@feral.com> <4CC8B62E.1090506@feral.com> Date: Tue, 2 Nov 2010 02:48:59 +0530 Message-ID: From: Penta Upa To: Matthew Jacob Content-Type: multipart/mixed; boundary=000e0cd2dc0a51a1fa0494045b61 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-scsi@freebsd.org Subject: Re: Problems getting target mode to work with isp driver 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, 01 Nov 2010 21:19:00 -0000 --000e0cd2dc0a51a1fa0494045b61 Content-Type: text/plain; charset=ISO-8859-1 Hi Matthew, I attached the Freebsd target and the linux initiator to a Brocade silkworm 3200. Additionally i have moved the 24xx card to the freebsd target. The current setup on the target and initiator is freebsd (8.1) -> 2340 and 2460 hba's linux (RHEL) -> 2342 HBA Device hints used are hint.isp.0.fullduplex="1" hint.isp.0.iid=75 With the switch configuration target mode for 24xx works nicely. No issues so far. However point to point doesn't work with the 24xx target too. Using the 23xx card for the target i have seen device timeouts on the initiator side after which target mode stops working. I have yet to get a scenario where i can simulate the problem consistently. Attached (iniitatorerrors.txt) contains the errors reported on the linux side. On the FreeBSD side no errors were reported. I did find the following warnings reported by the target (both with and with the switch configuration) after every port logout (done by removing the qla2xxx linux driver) by the initiator Oct 31 20:00:13 scache kernel: isp0: isp_del_wwn_entry: Chan 0 IID 0x2100001b320f3212 N-Port Handle 0x0000 Port ID 0xffffff cannot be found to be cleared Oct 31 20:00:13 scache kernel: isp0: Chan 0 [0]: hdl 0x0 PROB al0 tgt --- INI 0x011000 => UNK 0x000000; WWNN 0x2000001b320f3212 WWPN 0x2100001b320f3212 Oct 31 20:00:13 scache kernel: isp0: Chan 0 [126]: hdl 0x7e PROB al0 tgt --- UNK 0xfffffe => UNK 0xfffffe; WWNN 0x1000006069c0766f WWPN 0x2002006069c0766f Oct 31 20:00:13 scache kernel: isp0: Chan 0 [511]: hdl 0x0 NIL al0 tgt --- UNK 0xffffff => UNK 0x000000; WWNN 0x0000000000000000 WWPN 0x2100001b320f3212 Oct 31 20:00:57 scache kernel: isp0: isp_del_wwn_entry: Chan 0 IID 0x2100001b320f3212 N-Port Handle 0x0000 Port ID 0xffffff cannot be found to be cleared Oct 31 20:00:57 scache kernel: isp0: Chan 0 [0]: hdl 0x0 PROB al0 tgt --- INI 0x011000 => UNK 0x000000; WWNN 0x2000001b320f3212 WWPN 0x2100001b320f3212 Oct 31 20:00:57 scache kernel: isp0: Chan 0 [126]: hdl 0x7e PROB al0 tgt --- UNK 0xfffffe => UNK 0xfffffe; WWNN 0x1000006069c0766f WWPN 0x2002006069c0766f Is there anything else i could try out ? Thanks, Penta On Fri, Oct 29, 2010 at 1:52 AM, Penta Upa wrote: > > > On Thu, Oct 28, 2010 at 5:00 AM, Matthew Jacob wrote: > >> Since this was all point to point, my guess is that it's a soft loop id >> issue. >> >> You can try your original setup again (linux to FreeBSD), but for the >> FreeBSD box add this to loader.conf: >> >> set hint.isp.0.iid=75 >> >> > target mode doesn't work by setting the above hint in the loader.conf. > (even with the solaris box) The earlier linux setup doesn't work. I also > tried with another linux box (RHEL 5.5) which had both qla2340 and qla2460 > cards and with windows 2003 (which is the same as the solaris box). But they > dont work with or without the hint. Once i removed the hint from the > loader.conf, solaris works but not linux or windows > > I'll attach the the initiators and target to a switch over the weekend and > narrow it down to a point to point issue. Thanks a lot for the help and many > apologies for the delay in response. I'm trying out target mode as a > personal project which i do after work. > > Thanks, > Penta > --000e0cd2dc0a51a1fa0494045b61 Content-Type: text/plain; charset=US-ASCII; name="initiatorerrors.txt" Content-Disposition: attachment; filename="initiatorerrors.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gfzuiqv10 Tm92ICAyIDAyOjI3OjE2IHNjYWNoZTEga2VybmVsOiBxbGEyeHh4IDAwMDA6MDY6MDEuMTogTE9P UCBVUCBkZXRlY3RlZCAoMiBHYnBzKS4KTm92ICAyIDAyOjI3OjE3IHNjYWNoZTEga2VybmVsOiAg IFZlbmRvcjogRnJlZUJTRCAgIE1vZGVsOiBFbXVsYXRlZCBEaXNrICAgICBSZXY6IDAuMSAKTm92 ICAyIDAyOjI3OjE3IHNjYWNoZTEga2VybmVsOiAgIFR5cGU6ICAgRGlyZWN0LUFjY2VzcyAgICAg ICAgICAgICAgICAgICAgICBBTlNJIFNDU0kgcmV2aXNpb246IDAzCk5vdiAgMiAwMjoyNzoxNyBz Y2FjaGUxIGtlcm5lbDogU0NTSSBkZXZpY2Ugc2RnOiAyMDQ4MDAgNTEyLWJ5dGUgaGR3ciBzZWN0 b3JzICgxMDUgTUIpCk5vdiAgMiAwMjoyNzoxNyBzY2FjaGUxIGtlcm5lbDogc2RnOiB0ZXN0IFdQ IGZhaWxlZCwgYXNzdW1lIFdyaXRlIEVuYWJsZWQKTm92ICAyIDAyOjI3OjE3IHNjYWNoZTEga2Vy bmVsOiBzZGc6IGNhY2hlIGRhdGEgdW5hdmFpbGFibGUKTm92ICAyIDAyOjI3OjE3IHNjYWNoZTEg a2VybmVsOiBzZGc6IGFzc3VtaW5nIGRyaXZlIGNhY2hlOiB3cml0ZSB0aHJvdWdoCk5vdiAgMiAw MjoyNzoxNyBzY2FjaGUxIGtlcm5lbDogU0NTSSBkZXZpY2Ugc2RnOiAyMDQ4MDAgNTEyLWJ5dGUg aGR3ciBzZWN0b3JzICgxMDUgTUIpCk5vdiAgMiAwMjoyNzoxNyBzY2FjaGUxIGtlcm5lbDogc2Rn OiB0ZXN0IFdQIGZhaWxlZCwgYXNzdW1lIFdyaXRlIEVuYWJsZWQKTm92ICAyIDAyOjI3OjE3IHNj YWNoZTEga2VybmVsOiBzZGc6IGNhY2hlIGRhdGEgdW5hdmFpbGFibGUKTm92ICAyIDAyOjI3OjE3 IHNjYWNoZTEga2VybmVsOiBzZGc6IGFzc3VtaW5nIGRyaXZlIGNhY2hlOiB3cml0ZSB0aHJvdWdo Ck5vdiAgMiAwMjoyNzoxNyBzY2FjaGUxIGtlcm5lbDogIHNkZzogdW5rbm93biBwYXJ0aXRpb24g dGFibGUKTm92ICAyIDAyOjI3OjE3IHNjYWNoZTEga2VybmVsOiBzZCA5OjA6MDowOiBBdHRhY2hl ZCBzY3NpIGRpc2sgc2RnCk5vdiAgMiAwMjoyNzoxNyBzY2FjaGUxIGtlcm5lbDogc2QgOTowOjA6 MDogQXR0YWNoZWQgc2NzaSBnZW5lcmljIHNnNiB0eXBlIDAKTm92ICAyIDAyOjI4OjE5IHNjYWNo ZTEga2VybmVsOiBxbGEyeHh4IDAwMDA6MDY6MDEuMTogc2NzaSg5OjA6MCk6IEFib3J0IGNvbW1h bmQgaXNzdWVkIC0tIDEgMTkgMjAwMi4KTm92ICAyIDAyOjI4OjMwIHNjYWNoZTEga2VybmVsOiBx bGEyeHh4IDAwMDA6MDY6MDEuMTogc2NzaSg5OjA6MCk6IEFib3J0IGNvbW1hbmQgaXNzdWVkIC0t IDEgMTkgMjAwMi4KTm92ICAyIDAyOjI4OjMwIHNjYWNoZTEga2VybmVsOiBxbGEyeHh4IDAwMDA6 MDY6MDEuMTogc2NzaSg5OjA6MCk6IERFVklDRSBSRVNFVCBJU1NVRUQuCk5vdiAgMiAwMjoyODoz MCBzY2FjaGUxIGtlcm5lbDogcWxhMnh4eCAwMDAwOjA2OjAxLjE6IHNjc2koOTowOjApOiBERVZJ Q0UgUkVTRVQgU1VDQ0VFREVELgpOb3YgIDIgMDI6Mjg6MzUgc2NhY2hlMSBrZXJuZWw6IHFsYTJ4 eHggMDAwMDowNjowMS4xOiBzY3NpKDk6MDowKTogTE9PUCBSRVNFVCBJU1NVRUQuCk5vdiAgMiAw MjoyODozNiBzY2FjaGUxIGtlcm5lbDogcWxhMnh4eCAwMDAwOjA2OjAxLjE6IHFsYTJ4eHhfZWhf YnVzX3Jlc2V0OiByZXNldCBzdWNjZWVkZWQKTm92ICAyIDAyOjI4OjQ2IHNjYWNoZTEga2VybmVs OiBxbGEyeHh4IDAwMDA6MDY6MDEuMTogc2NzaSg5OjA6MCk6IEFEQVBURVIgUkVTRVQgSVNTVUVE LgpOb3YgIDIgMDI6Mjg6NDYgc2NhY2hlMSBrZXJuZWw6IHFsYTJ4eHggMDAwMDowNjowMS4xOiBQ ZXJmb3JtaW5nIElTUCBlcnJvciByZWNvdmVyeSAtIGhhPSBmZmZmODEwMDZlMWIwNGY4LgpOb3Yg IDIgMDI6Mjg6NDYgc2NhY2hlMSBrZXJuZWw6IHFsYTJ4eHggMDAwMDowNjowMS4xOiBMSVAgcmVz ZXQgb2NjdXJlZCAoZjdmNykuCk5vdiAgMiAwMjoyODo0NyBzY2FjaGUxIGtlcm5lbDogcWxhMnh4 eCAwMDAwOjA2OjAxLjE6IExPT1AgVVAgZGV0ZWN0ZWQgKDIgR2JwcykuCk5vdiAgMiAwMjoyODo0 NyBzY2FjaGUxIGtlcm5lbDogcWxhMnh4eCAwMDAwOjA2OjAxLjE6IHFsYTJ4eHhfZWhfaG9zdF9y ZXNldDogcmVzZXQgc3VjY2VlZGVkCk5vdiAgMiAwMjoyODo1NyBzY2FjaGUxIGtlcm5lbDogc2Qg OTowOjA6MDogc2NzaTogRGV2aWNlIG9mZmxpbmVkIC0gbm90IHJlYWR5IGFmdGVyIGVycm9yIHJl Y292ZXJ5Ck5vdiAgMiAwMjoyODo1NyBzY2FjaGUxIGtlcm5lbDogc2QgOTowOjA6MDogcmVqZWN0 aW5nIEkvTyB0byBvZmZsaW5lIGRldmljZQpOb3YgIDIgMDI6Mjg6NTcgc2NhY2hlMSBrZXJuZWw6 IEJ1ZmZlciBJL08gZXJyb3Igb24gZGV2aWNlIHNkZywgbG9naWNhbCBibG9jayAyNTU5MgpOb3Yg IDIgMDI6Mjg6NTcgc2NhY2hlMSBrZXJuZWw6IHNkIDk6MDowOjA6IHJlamVjdGluZyBJL08gdG8g b2ZmbGluZSBkZXZpY2UK --000e0cd2dc0a51a1fa0494045b61-- From owner-freebsd-scsi@FreeBSD.ORG Tue Nov 2 00:36:59 2010 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3AAA5106566C for ; Tue, 2 Nov 2010 00:36:59 +0000 (UTC) (envelope-from mj@feral.com) Received: from ns1.feral.com (ns1.feral.com [192.67.166.1]) by mx1.freebsd.org (Postfix) with ESMTP id 03B468FC13 for ; Tue, 2 Nov 2010 00:36:58 +0000 (UTC) Received: from [192.168.1.100] (m206-63.dsl.tsoft.com [198.144.206.63]) by ns1.feral.com (8.14.4/8.14.3) with ESMTP id oA20atE8007475 for ; Mon, 1 Nov 2010 16:36:56 -0800 (PST) (envelope-from mj@feral.com) Message-ID: <4CCF5D29.7070307@feral.com> Date: Mon, 01 Nov 2010 17:36:57 -0700 From: Matthew Jacob Organization: Feral Software User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: freebsd-scsi@freebsd.org References: <4CC75FAE.9060708@feral.com> <4CC7AB7E.3050705@feral.com> <4CC8B62E.1090506@feral.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Default is to whitelist mail, not delayed by milter-greylist-4.2.6 (ns1.feral.com [192.67.166.1]); Mon, 01 Nov 2010 16:36:56 -0800 (PST) Subject: Re: Problems getting target mode to work with isp driver 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: Tue, 02 Nov 2010 00:36:59 -0000 > Is there anything else i could try out ? Nope. I guess I'll have to check up on point to point configurations again. From owner-freebsd-scsi@FreeBSD.ORG Tue Nov 2 00:48:49 2010 Return-Path: Delivered-To: freebsd-scsi@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6A6F2106564A; Tue, 2 Nov 2010 00:48:49 +0000 (UTC) (envelope-from arundel@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 3FE8E8FC12; Tue, 2 Nov 2010 00:48:49 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id oA20mnjj073231; Tue, 2 Nov 2010 00:48:49 GMT (envelope-from arundel@freefall.freebsd.org) Received: (from arundel@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id oA20mniO073227; Tue, 2 Nov 2010 00:48:49 GMT (envelope-from arundel) Date: Tue, 2 Nov 2010 00:48:49 GMT Message-Id: <201011020048.oA20mniO073227@freefall.freebsd.org> To: arundel@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-scsi@FreeBSD.org From: arundel@FreeBSD.org Cc: Subject: Re: bin/151871: [cam] camcontrol(8): incorrect standby timer calculation 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: Tue, 02 Nov 2010 00:48:49 -0000 Old Synopsis: camcontrol(8): incorrect standby timer calculation New Synopsis: [cam] camcontrol(8): incorrect standby timer calculation Responsible-Changed-From-To: freebsd-bugs->freebsd-scsi Responsible-Changed-By: arundel Responsible-Changed-When: Tue Nov 2 00:47:55 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=151871 From owner-freebsd-scsi@FreeBSD.ORG Tue Nov 2 01:07:37 2010 Return-Path: Delivered-To: freebsd-scsi@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C2ACF106566C; Tue, 2 Nov 2010 01:07:37 +0000 (UTC) (envelope-from arundel@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 9841C8FC15; Tue, 2 Nov 2010 01:07:37 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id oA217bh8095228; Tue, 2 Nov 2010 01:07:37 GMT (envelope-from arundel@freefall.freebsd.org) Received: (from arundel@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id oA217bKe095224; Tue, 2 Nov 2010 01:07:37 GMT (envelope-from arundel) Date: Tue, 2 Nov 2010 01:07:37 GMT Message-Id: <201011020107.oA217bKe095224@freefall.freebsd.org> To: arundel@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-scsi@FreeBSD.org From: arundel@FreeBSD.org Cc: Subject: Re: kern/127717: [ata] [patch] [request] - support write cache toggling per device 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: Tue, 02 Nov 2010 01:07:37 -0000 Old Synopsis: [ata] [patch] - support write cache toggling per device New Synopsis: [ata] [patch] [request] - support write cache toggling per device Responsible-Changed-From-To: freebsd-bugs->freebsd-scsi Responsible-Changed-By: arundel Responsible-Changed-When: Tue Nov 2 01:02:06 UTC 2010 Responsible-Changed-Why: Although this PR is related to ATA and not CAM, I think developers reading the freebsd-scsi@ mailinglist will have an opinion about this request. http://www.freebsd.org/cgi/query-pr.cgi?pr=127717 From owner-freebsd-scsi@FreeBSD.ORG Thu Nov 4 15:27:00 2010 Return-Path: Delivered-To: freebsd-scsi@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 78FE21065670; Thu, 4 Nov 2010 15:27:00 +0000 (UTC) (envelope-from brucec@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 4F21D8FC1B; Thu, 4 Nov 2010 15:27:00 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id oA4FR0jW079609; Thu, 4 Nov 2010 15:27:00 GMT (envelope-from brucec@freefall.freebsd.org) Received: (from brucec@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id oA4FR0MT079605; Thu, 4 Nov 2010 15:27:00 GMT (envelope-from brucec) Date: Thu, 4 Nov 2010 15:27:00 GMT Message-Id: <201011041527.oA4FR0MT079605@freefall.freebsd.org> To: brucec@FreeBSD.org, brucec@FreeBSD.org, freebsd-scsi@FreeBSD.org, brucec@FreeBSD.org From: brucec@FreeBSD.org Cc: Subject: Re: bin/151871: [cam] camcontrol(8): incorrect standby timer calculation 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, 04 Nov 2010 15:27:00 -0000 Synopsis: [cam] camcontrol(8): incorrect standby timer calculation State-Changed-From-To: open->patched State-Changed-By: brucec State-Changed-When: Thu Nov 4 15:26:29 UTC 2010 State-Changed-Why: Fixed in r214781. Responsible-Changed-From-To: freebsd-scsi->brucec Responsible-Changed-By: brucec Responsible-Changed-When: Thu Nov 4 15:26:29 UTC 2010 Responsible-Changed-Why: Take. http://www.freebsd.org/cgi/query-pr.cgi?pr=151871 From owner-freebsd-scsi@FreeBSD.ORG Fri Nov 5 01:29:02 2010 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 5B11A106566B; Fri, 5 Nov 2010 01:29:02 +0000 (UTC) Date: Fri, 5 Nov 2010 01:29:02 +0000 From: Alexander Best To: freebsd-scsi@freebsd.org Message-ID: <20101105012902.GA27499@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: panic with high kern.cam.boot_delay value 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, 05 Nov 2010 01:29:02 -0000 hi there, i just stumbled upon a panic in connection with a very high kern.cam.boot_delay value (=100000). this is on HEAD (r214809; amd64). unfortunately i couldn't enter the debugger, because the panic occured before my usb keyboard attached. the panic however occured in sched_priority(). can anybody reproduce this? just before the panic i saw some xpt_* message in connection with a 60 second delay. cheers. alex -- a13x From owner-freebsd-scsi@FreeBSD.ORG Fri Nov 5 03:37:25 2010 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CE015106564A; Fri, 5 Nov 2010 03:37:25 +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 56B808FC0A; Fri, 5 Nov 2010 03:37:24 +0000 (UTC) Received: from [127.0.0.1] (pooker.samsco.org [168.103.85.57]) (authenticated bits=0) by pooker.samsco.org (8.14.4/8.14.4) with ESMTP id oA53bMfu030993; Thu, 4 Nov 2010 21:37:22 -0600 (MDT) (envelope-from scottl@samsco.org) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Scott Long In-Reply-To: <20101105012902.GA27499@freebsd.org> Date: Thu, 4 Nov 2010 21:37:22 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <580A1CEB-4217-4BE6-89BF-BF309C9EF2A4@samsco.org> References: <20101105012902.GA27499@freebsd.org> To: Alexander Best X-Mailer: Apple Mail (2.1081) X-Spam-Status: No, score=-50.0 required=3.8 tests=ALL_TRUSTED, T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on pooker.samsco.org Cc: freebsd-scsi@freebsd.org Subject: Re: panic with high kern.cam.boot_delay value 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, 05 Nov 2010 03:37:25 -0000 On Nov 4, 2010, at 7:29 PM, Alexander Best wrote: > hi there, >=20 > i just stumbled upon a panic in connection with a very high = kern.cam.boot_delay > value (=3D100000). this is on HEAD (r214809; amd64). unfortunately i = couldn't > enter the debugger, because the panic occured before my usb keyboard = attached. >=20 options DDB options KDB options KDB_UNATTENDED Do you have the ability to attach a serial console? > the panic however occured in sched_priority(). can anybody reproduce = this? just > before the panic i saw some xpt_* message in connection with a 60 = second delay. >=20 The 60 second message might have something to do with the = config_intrhook service complaining about the long delay that you've = imposed on the boot process. It'll panic if you have INVARIANTS set and = it waits for five 60 second intervals. Scott From owner-freebsd-scsi@FreeBSD.ORG Fri Nov 5 13:48:03 2010 Return-Path: Delivered-To: freebsd-scsi@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E3EB91065675; Fri, 5 Nov 2010 13:48:03 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 9B67B8FC08; Fri, 5 Nov 2010 13:48:02 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id PAA13898; Fri, 05 Nov 2010 15:48:01 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <4CD40B10.5090205@icyb.net.ua> Date: Fri, 05 Nov 2010 15:48:00 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.11) Gecko/20101021 Lightning/1.0b2 Thunderbird/3.1.5 MIME-Version: 1.0 To: freebsd-current@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Alexander Motin Subject: stuck in cam with bad optical media 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, 05 Nov 2010 13:48:04 -0000 [I am probably just having an unlucky day.] I tried to burn (with growisofs) a DVD+RW disk which seems to have developed some problems. First, the burning process got stuck at the same percentage and the drive started to make unusual sounds. Then, the following messages appeared in system log: kernel: (cd0:ahcich5:0:0:0): READ(10). CDB: 28 0 0 0 0 0 0 0 1 0 kernel: (cd0:ahcich5:0:0:0): CAM status: SCSI Status Error kernel: (cd0:ahcich5:0:0:0): SCSI status: Check Condition kernel: (cd0:ahcich5:0:0:0): SCSI sense: MEDIUM ERROR asc:2,0 (No seek complete) kernel: (cd0:ahcich5:0:0:0): READ(10). CDB: 28 0 0 0 0 0 0 0 1 0 kernel: (cd0:ahcich5:0:0:0): CAM status: SCSI Status Error kernel: (cd0:ahcich5:0:0:0): SCSI status: Check Condition kernel: (cd0:ahcich5:0:0:0): SCSI sense: MEDIUM ERROR asc:2,0 (No seek complete) kernel: (cd0:ahcich5:0:0:0): READ(10). CDB: 28 0 0 0 0 0 0 0 1 0 kernel: (cd0:ahcich5:0:0:0): CAM status: SCSI Status Error kernel: (cd0:ahcich5:0:0:0): SCSI status: Check Condition kernel: (cd0:ahcich5:0:0:0): SCSI sense: MEDIUM ERROR asc:2,0 (No seek complete) kernel: (cd0:ahcich5:0:0:0): READ(10). CDB: 28 0 0 0 0 0 0 0 1 0 kernel: (cd0:ahcich5:0:0:0): CAM status: SCSI Status Error kernel: (cd0:ahcich5:0:0:0): SCSI status: Check Condition kernel: (cd0:ahcich5:0:0:0): SCSI sense: Deferred error: MEDIUM ERROR asc:2,0 (No seek complete) kernel: ahcich5: Timeout on slot 7 kernel: ahcich5: is 00000000 cs 00000180 ss 00000000 rs 00000180 tfd 58 serr 00000000 kernel: (cd0:ahcich5:0:0:0): cddone: got error 0x5 back After that growisofs either remained or became stuck in the following state: 42433 100119 growisofs initial thread mi_switch+0x1de sleepq_switch+0xdb sleepq_wait+0x45 _sleep+0x295 cam_periph_ccbwait+0x40 cam_periph_runccb+0x68 passioctl+0x260 devfs_ioctl_f+0xf8 kern_ioctl+0x262 ioctl+0x168 syscallenter+0x3be syscall+0x41 Xfast_syscall+0xe2 Any commands that tried to access the device (cdcontrol eject, camcontrol reset 5:0:0) also got stuck. Only reboot helped to recover the device. I understand that bad media is bad, but it happens. I think that cam and ahci typically recover from errors/timeouts, so somehting must have gone wrong in this case. P.S. I have already thrown out the bad disk - irritation won over reason when that happened, unfortunately :( -- Andriy Gapon From owner-freebsd-scsi@FreeBSD.ORG Fri Nov 5 16:11:59 2010 Return-Path: Delivered-To: freebsd-scsi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ACFFD1065672; Fri, 5 Nov 2010 16:11:59 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id EF8508FC19; Fri, 5 Nov 2010 16:11:57 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA16519; Fri, 05 Nov 2010 18:11:56 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <4CD42CCC.6060005@icyb.net.ua> Date: Fri, 05 Nov 2010 18:11:56 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.11) Gecko/20101021 Lightning/1.0b2 Thunderbird/3.1.5 MIME-Version: 1.0 To: Garrett Cooper References: <4CD40B10.5090205@icyb.net.ua> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-scsi@FreeBSD.org, Alexander Motin , freebsd-current@FreeBSD.org Subject: Re: stuck in cam with bad optical media 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, 05 Nov 2010 16:11:59 -0000 on 05/11/2010 18:06 Garrett Cooper said the following: > On Fri, Nov 5, 2010 at 6:48 AM, Andriy Gapon wrote: >> >> [I am probably just having an unlucky day.] >> >> I tried to burn (with growisofs) a DVD+RW disk which seems to have developed some >> problems. >> First, the burning process got stuck at the same percentage and the drive started >> to make unusual sounds. Then, the following messages appeared in system log: >> kernel: (cd0:ahcich5:0:0:0): READ(10). CDB: 28 0 0 0 0 0 0 0 1 0 >> kernel: (cd0:ahcich5:0:0:0): CAM status: SCSI Status Error >> kernel: (cd0:ahcich5:0:0:0): SCSI status: Check Condition >> kernel: (cd0:ahcich5:0:0:0): SCSI sense: MEDIUM ERROR asc:2,0 (No seek complete) >> kernel: (cd0:ahcich5:0:0:0): READ(10). CDB: 28 0 0 0 0 0 0 0 1 0 >> kernel: (cd0:ahcich5:0:0:0): CAM status: SCSI Status Error >> kernel: (cd0:ahcich5:0:0:0): SCSI status: Check Condition >> kernel: (cd0:ahcich5:0:0:0): SCSI sense: MEDIUM ERROR asc:2,0 (No seek complete) >> kernel: (cd0:ahcich5:0:0:0): READ(10). CDB: 28 0 0 0 0 0 0 0 1 0 >> kernel: (cd0:ahcich5:0:0:0): CAM status: SCSI Status Error >> kernel: (cd0:ahcich5:0:0:0): SCSI status: Check Condition >> kernel: (cd0:ahcich5:0:0:0): SCSI sense: MEDIUM ERROR asc:2,0 (No seek complete) >> kernel: (cd0:ahcich5:0:0:0): READ(10). CDB: 28 0 0 0 0 0 0 0 1 0 >> kernel: (cd0:ahcich5:0:0:0): CAM status: SCSI Status Error >> kernel: (cd0:ahcich5:0:0:0): SCSI status: Check Condition >> kernel: (cd0:ahcich5:0:0:0): SCSI sense: Deferred error: MEDIUM ERROR asc:2,0 (No >> seek complete) >> kernel: ahcich5: Timeout on slot 7 >> kernel: ahcich5: is 00000000 cs 00000180 ss 00000000 rs 00000180 tfd 58 serr 00000000 >> kernel: (cd0:ahcich5:0:0:0): cddone: got error 0x5 back >> >> After that growisofs either remained or became stuck in the following state: >> 42433 100119 growisofs initial thread mi_switch+0x1de sleepq_switch+0xdb >> sleepq_wait+0x45 _sleep+0x295 cam_periph_ccbwait+0x40 cam_periph_runccb+0x68 >> passioctl+0x260 devfs_ioctl_f+0xf8 kern_ioctl+0x262 ioctl+0x168 syscallenter+0x3be >> syscall+0x41 Xfast_syscall+0xe2 >> >> Any commands that tried to access the device (cdcontrol eject, camcontrol reset >> 5:0:0) also got stuck. >> Only reboot helped to recover the device. >> >> I understand that bad media is bad, but it happens. >> I think that cam and ahci typically recover from errors/timeouts, so somehting >> must have gone wrong in this case. >> >> P.S. I have already thrown out the bad disk - irritation won over reason when that >> happened, unfortunately :( > > I think we are in the same boat (I've run into this problem on two > different machines with my revisions of CURRENT) :(... I resorted to > using an external DVD writer to write media (which is in and of itself > a PITA): > > $ camcontrol devlist; uname -a > at scbus1 target 0 lun 0 (cd0,pass0) > at scbus2 target 0 lun 0 (pass1,ada0) > FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #2 r214347M: > Mon Oct 25 04:38:54 PDT 2010 root@:/usr/obj/usr/src/sys/BAYONETTA > amd64 > > Have you tried non-rewritable CDs and DVDs yet (something that I > need to try too)? Not sure if you refer to exactly the same problem. I regularly successfully burn various media (re-writable and write-once). This time this was definitely a bad (degraded) disk. -- Andriy Gapon From owner-freebsd-scsi@FreeBSD.ORG Fri Nov 5 16:28:54 2010 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E7CBA1065674 for ; Fri, 5 Nov 2010 16:28:53 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 77BFF8FC0A for ; Fri, 5 Nov 2010 16:28:53 +0000 (UTC) Received: by wyb34 with SMTP id 34so1272486wyb.13 for ; Fri, 05 Nov 2010 09:28:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=53nmMSbbi9ew6ArtNSWWqSHC+PLYLWrDSKuV2zth0tc=; b=goDMt2zU3yrXX4bYGf3w5M1c6U5XMBy4ByjHYvhoiuM5l3j9MFmGhJpE5+kPg8XyK9 d611quv7IKAL2qds12qa6HPNJ4JXb6DYTKAzL+cn9W78KxgacDQiN9eYqa2mX19GUgoU IWpwqmUjIU2Hx3LUzaSRflwRBMHkfw6XazqUI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=LFqP2r4kalq112G3Y9VXAJonrDiuFj2wRzxMmCahyxNyBHsrcdHzGoCCFa3Y8hJkdf 6jMvgZ6DsRxOyzJhOnqNvUKAwX7D15WTnFAEAxwCWLcvKVjfplBvOeMlOiJN5RNbbrP6 NIuirSB5hPaZa4n70LSQFl0hcOc1f/I0NZfUo= MIME-Version: 1.0 Received: by 10.216.7.210 with SMTP id 60mr1367146wep.30.1288973209982; Fri, 05 Nov 2010 09:06:49 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.216.198.27 with HTTP; Fri, 5 Nov 2010 09:06:49 -0700 (PDT) In-Reply-To: <4CD40B10.5090205@icyb.net.ua> References: <4CD40B10.5090205@icyb.net.ua> Date: Fri, 5 Nov 2010 09:06:49 -0700 X-Google-Sender-Auth: pGKIji4qq0p0cRCknyOkWnY0I1k Message-ID: From: Garrett Cooper To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-scsi@freebsd.org, Alexander Motin , freebsd-current@freebsd.org Subject: Re: stuck in cam with bad optical media 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, 05 Nov 2010 16:28:54 -0000 On Fri, Nov 5, 2010 at 6:48 AM, Andriy Gapon wrote: > > [I am probably just having an unlucky day.] > > I tried to burn (with growisofs) a DVD+RW disk which seems to have develo= ped some > problems. > First, the burning process got stuck at the same percentage and the drive= started > to make unusual sounds. =A0Then, the following messages appeared in syste= m log: > kernel: (cd0:ahcich5:0:0:0): READ(10). CDB: 28 0 0 0 0 0 0 0 1 0 > kernel: (cd0:ahcich5:0:0:0): CAM status: SCSI Status Error > kernel: (cd0:ahcich5:0:0:0): SCSI status: Check Condition > kernel: (cd0:ahcich5:0:0:0): SCSI sense: MEDIUM ERROR asc:2,0 (No seek co= mplete) > kernel: (cd0:ahcich5:0:0:0): READ(10). CDB: 28 0 0 0 0 0 0 0 1 0 > kernel: (cd0:ahcich5:0:0:0): CAM status: SCSI Status Error > kernel: (cd0:ahcich5:0:0:0): SCSI status: Check Condition > kernel: (cd0:ahcich5:0:0:0): SCSI sense: MEDIUM ERROR asc:2,0 (No seek co= mplete) > kernel: (cd0:ahcich5:0:0:0): READ(10). CDB: 28 0 0 0 0 0 0 0 1 0 > kernel: (cd0:ahcich5:0:0:0): CAM status: SCSI Status Error > kernel: (cd0:ahcich5:0:0:0): SCSI status: Check Condition > kernel: (cd0:ahcich5:0:0:0): SCSI sense: MEDIUM ERROR asc:2,0 (No seek co= mplete) > kernel: (cd0:ahcich5:0:0:0): READ(10). CDB: 28 0 0 0 0 0 0 0 1 0 > kernel: (cd0:ahcich5:0:0:0): CAM status: SCSI Status Error > kernel: (cd0:ahcich5:0:0:0): SCSI status: Check Condition > kernel: (cd0:ahcich5:0:0:0): SCSI sense: Deferred error: MEDIUM ERROR asc= :2,0 (No > seek complete) > kernel: ahcich5: Timeout on slot 7 > kernel: ahcich5: is 00000000 cs 00000180 ss 00000000 rs 00000180 tfd 58 s= err 00000000 > kernel: (cd0:ahcich5:0:0:0): cddone: got error 0x5 back > > After that growisofs either remained or became stuck in the following sta= te: > 42433 100119 growisofs =A0 =A0 =A0 =A0initial thread =A0 mi_switch+0x1de = sleepq_switch+0xdb > sleepq_wait+0x45 _sleep+0x295 cam_periph_ccbwait+0x40 cam_periph_runccb+0= x68 > passioctl+0x260 devfs_ioctl_f+0xf8 kern_ioctl+0x262 ioctl+0x168 syscallen= ter+0x3be > syscall+0x41 Xfast_syscall+0xe2 > > Any commands that tried to access the device (cdcontrol eject, camcontrol= reset > 5:0:0) also got stuck. > Only reboot helped to recover the device. > > I understand that bad media is bad, but it happens. > I think that cam and ahci typically recover from errors/timeouts, so some= hting > must have gone wrong in this case. > > P.S. I have already thrown out the bad disk - irritation won over reason = when that > happened, unfortunately :( I think we are in the same boat (I've run into this problem on two different machines with my revisions of CURRENT) :(... I resorted to using an external DVD writer to write media (which is in and of itself a PITA): $ camcontrol devlist; uname -a at scbus1 target 0 lun 0 (cd0,pass0) at scbus2 target 0 lun 0 (pass1,ada0) FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #2 r214347M: Mon Oct 25 04:38:54 PDT 2010 root@:/usr/obj/usr/src/sys/BAYONETTA amd64 Have you tried non-rewritable CDs and DVDs yet (something that I need to try too)? HTH, -Garrett From owner-freebsd-scsi@FreeBSD.ORG Fri Nov 5 18:51:03 2010 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7D55F106566B; Fri, 5 Nov 2010 18:51:03 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id A50328FC1D; Fri, 5 Nov 2010 18:51:02 +0000 (UTC) Received: by bwz3 with SMTP id 3so2930031bwz.13 for ; Fri, 05 Nov 2010 11:51:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:x-enigmail-version:content-type :content-transfer-encoding; bh=TKPZQ4B/pYcWI+c0Jv3uhc3o4lpVrFV8bm/BjjSEveU=; b=QCooEPeu5hR2Dd1olNCcaH/t8t4A73h731tOp/KgeMPdgmwBMa0fSfNTc1TqTdfBdA 2FjZ9HfEEOqi4moKS0yf1g8lj8FTCIBAQnnckkx1NMiEwZppuq3O9h7oezWyLXdZXC05 +pxhgOIiYxdSJATnOxdkx5a/xlWegyJ+fkN/I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :x-enigmail-version:content-type:content-transfer-encoding; b=B+hLhEM/W247tAT0gszapiOSMYEhx0HqFYsXzd8O8FVvltJNo+aoGbG1NlkSshtAUA X1VsuWRir7dz2t5NYzC60+k9ttbHNntrUqUfN0Un7qMIn4pLPIHPIDBpFGg1Lr7Ytsip r5A86otQ3zrTXNCuktb2kphe5FB6IysX55OhE= Received: by 10.204.79.142 with SMTP id p14mr2170956bkk.175.1288983061541; Fri, 05 Nov 2010 11:51:01 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id d12sm1251680bkw.19.2010.11.05.11.50.59 (version=SSLv3 cipher=RC4-MD5); Fri, 05 Nov 2010 11:51:00 -0700 (PDT) Sender: Alexander Motin Message-ID: <4CD45209.5010607@FreeBSD.org> Date: Fri, 05 Nov 2010 20:50:49 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: FreeBSD-Current , FreeBSD Stable , freebsd-scsi@freebsd.org X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: Subject: Sense fetching [Was: cdrtools /devel ...] 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, 05 Nov 2010 18:51:03 -0000 Hi. I've reviewed tests that scgcheck does to SCSI subsystem. It shown combination of several issues in both CAM, ahci(4) and cdrtools itself. Several small patches allow us to pass most of that tests: http://people.freebsd.org/~mav/sense/ ahci_resid.patch: Add support for reporting residual length on data underrun. SCSI commands often returns results shorter then expected. Returned value allows application to know/check how much data it really has. It is also important for sense fetching, as ATAPI and USB devices return sense as data in response to REQUEST_SENSE command. sense_resid.patch: When manually requesting sense data (ATAPI or USB), request only as much data as user requested (not the fixed structure size), and return respective sense residual length. pass_autosence.patch: Unless CAM_DIS_AUTOSENSE is set, always fetch sense if not done by SIM, independently of CAM_PASS_ERR_RECOVER. As soon as device freeze released before returning to user-level, user-level application by definition can't reliably fetch sense data if some other application (like hald) tries to access device same time. cdrtools.patch: Make libscg (part of cdrtools) on FreeBSD to submit wanted sense length to CAM and do not clear sense return buffer. It is mostly cosmetics, important probably only for scgcheck. Testers and reviewers welcome. I am especially interested in opinion about pass_autosence.patch -- may be we should lower sense fetching even deeper, to make it work for all cam_periph_runccb() consumers. -- Alexander Motin From owner-freebsd-scsi@FreeBSD.ORG Fri Nov 5 19:06:24 2010 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8E94A106566C; Fri, 5 Nov 2010 19:06:24 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id DF0F38FC08; Fri, 5 Nov 2010 19:06:23 +0000 (UTC) Received: by bwz3 with SMTP id 3so2943221bwz.13 for ; Fri, 05 Nov 2010 12:06:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=87ZGXPNDXEV13IqnecJ37c2JDxm/Mbgv6npzrThIC14=; b=RPGGmqbE2pIs585VPi/mM/inlzqAbv4ysWRwRLYxkdpfAVcQl4ioXq9vZPJlBqrLiB q4tC9HFR2g4zAMFwNA0/gJoSBpqFwPHPr3aSm3xAfoq0DykfgfclDBEDROqVEtGNYFSD W0r6mxWRgzh4p0TbFjBFglG7DXJC1wvLcBZrY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; b=iZRoEmpJjTolIrF5rBk7P5a4LcSQVELeP0R3br1pREtSaoP6fzF7pB4YEizkfvvufM WK6bLkugG0OkWMNpS2V0NSzBr+RLb4e5nYMw2gDwAjfxsq3ZztkecdfQskRtI8Tb+I7a mFPCtlI/3sg/YDUXl0GYzF+Dr9NTeCHxSnJAQ= Received: by 10.204.72.144 with SMTP id m16mr2156245bkj.39.1288983982498; Fri, 05 Nov 2010 12:06:22 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id r21sm1266243bkj.10.2010.11.05.12.06.20 (version=SSLv3 cipher=RC4-MD5); Fri, 05 Nov 2010 12:06:21 -0700 (PDT) Sender: Alexander Motin Message-ID: <4CD455A3.2010803@FreeBSD.org> Date: Fri, 05 Nov 2010 21:06:11 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Alexander Best , freebsd-scsi@freebsd.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Re: panic with high kern.cam.boot_delay value 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, 05 Nov 2010 19:06:24 -0000 Hi. Alexander Best wrote: > i just stumbled upon a panic in connection with a very high kern.cam.boot_delay > value (=100000). this is on HEAD (r214809; amd64). unfortunately i couldn't > enter the debugger, because the panic occured before my usb keyboard attached. > > the panic however occured in sched_priority(). can anybody reproduce this? just > before the panic i saw some xpt_* message in connection with a 60 second delay. I have feeling that it is related not to CAM, but to new event timers infrastructure and SCHED_ULE. I have one report about panic in sched_priority() on virtual machine. Unluckily, I can't reproduce any of cases. -- Alexander Motin From owner-freebsd-scsi@FreeBSD.ORG Fri Nov 5 19:34:43 2010 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ACB35106566B; Fri, 5 Nov 2010 19:34:43 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 3E0318FC1C; Fri, 5 Nov 2010 19:34:42 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.4/8.14.4/ALCHEMY.FRANKEN.DE) with ESMTP id oA5JKSXw068846; Fri, 5 Nov 2010 20:20:28 +0100 (CET) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id oA5JKSWu068845; Fri, 5 Nov 2010 20:20:28 +0100 (CET) (envelope-from marius) Date: Fri, 5 Nov 2010 20:20:28 +0100 From: Marius Strobl To: Alexander Motin Message-ID: <20101105192028.GA68728@alchemy.franken.de> References: <4CD45209.5010607@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CD45209.5010607@FreeBSD.org> User-Agent: Mutt/1.4.2.3i Cc: Joerg.Schilling@fokus.fraunhofer.de, freebsd-scsi@freebsd.org, FreeBSD-Current , FreeBSD Stable Subject: Re: Sense fetching [Was: cdrtools /devel ...] 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, 05 Nov 2010 19:34:43 -0000 On Fri, Nov 05, 2010 at 08:50:49PM +0200, Alexander Motin wrote: > Hi. > > I've reviewed tests that scgcheck does to SCSI subsystem. It shown > combination of several issues in both CAM, ahci(4) and cdrtools itself. > Several small patches allow us to pass most of that tests: > http://people.freebsd.org/~mav/sense/ > > ahci_resid.patch: Add support for reporting residual length on data > underrun. SCSI commands often returns results shorter then expected. > Returned value allows application to know/check how much data it really > has. It is also important for sense fetching, as ATAPI and USB devices > return sense as data in response to REQUEST_SENSE command. > > sense_resid.patch: When manually requesting sense data (ATAPI or USB), > request only as much data as user requested (not the fixed structure > size), and return respective sense residual length. > > pass_autosence.patch: Unless CAM_DIS_AUTOSENSE is set, always fetch > sense if not done by SIM, independently of CAM_PASS_ERR_RECOVER. As soon > as device freeze released before returning to user-level, user-level > application by definition can't reliably fetch sense data if some other > application (like hald) tries to access device same time. > > cdrtools.patch: Make libscg (part of cdrtools) on FreeBSD to submit > wanted sense length to CAM and do not clear sense return buffer. It is > mostly cosmetics, important probably only for scgcheck. Please don't commit this to the port directly but let it loop back via upstream (CC'ed) instead, otherwise we would need to obey the following, which is undesirable, especially if these really are mostly cosmetic issues: /* * Warning: you may change this source, but if you do that * you need to change the _scg_version and _scg_auth* string below. * You may not return "schily" for an SCG_AUTHOR request anymore. * Choose your name instead of "schily" and make clear that the version * string is related to a modified source. */ > > Testers and reviewers welcome. I am especially interested in opinion > about pass_autosence.patch -- may be we should lower sense fetching even > deeper, to make it work for all cam_periph_runccb() consumers. > Marius