From owner-freebsd-scsi@FreeBSD.ORG Mon Nov 30 11:07:01 2009 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 67FED1065696 for ; Mon, 30 Nov 2009 11:07:01 +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 4B9288FC18 for ; Mon, 30 Nov 2009 11:07:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nAUB71Mp043545 for ; Mon, 30 Nov 2009 11:07:01 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nAUB708c043543 for freebsd-scsi@FreeBSD.org; Mon, 30 Nov 2009 11:07:00 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 30 Nov 2009 11:07:00 GMT Message-Id: <200911301107.nAUB708c043543@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, 30 Nov 2009 11:07:01 -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 kern/140091 scsi [da] [patch] allow for da(4) large block transfer than o kern/138789 scsi [cam] [patch] cd(4) patch for drives/discs failing the o kern/134488 scsi [mpt] MPT SCSI driver probes max. 8 LUNs per device o amd64/132394 scsi [isp] - bad underruns with QLogic qla2300 and amd64 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/131032 scsi [panic] hald causing panic in scsi_sg o kern/130735 scsi [cam] [patch] pass M_NOWAIT to the malloc() call insid 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 f kern/123666 scsi [aac] attach fails with Adaptec SAS RAID 3805 controll 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 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/38828 scsi [dpt] [request] DPT PM2012B/90 doesn't work o kern/35234 scsi World access to /dev/pass? (for scanner) requires acce 38 problems total. From owner-freebsd-scsi@FreeBSD.ORG Mon Nov 30 20:15:06 2009 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 4E38A1065670 for ; Mon, 30 Nov 2009 20:15:03 +0000 (UTC) (envelope-from erich@fuujingroup.com) Received: from fluorine.fuujinnetworks.com (fluorine.fuujinnetworks.com [64.90.67.234]) by mx1.freebsd.org (Postfix) with ESMTP id DF1188FC1D for ; Mon, 30 Nov 2009 20:15:02 +0000 (UTC) Received: from [10.168.1.8] (copper.fuujinnetworks.com [64.90.67.254]) by fluorine.fuujinnetworks.com (Postfix) with ESMTPA id 9A0E643B26C for ; Mon, 30 Nov 2009 13:57:33 -0600 (CST) Message-ID: <4B1423AB.30107@fuujingroup.com> Date: Mon, 30 Nov 2009 13:57:31 -0600 From: Erich Jenkins User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: freebsd-scsi@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: updated isp(4) driver available 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, 30 Nov 2009 20:15:06 -0000 I see that there were great steps forward with the isp(4) driver back in June! :) Has this been committed to any of the stable releases as of yet, or is this still a patch? We've not been able to get some Qlogic isp2310's (single port, 2gb FC) cards working for quite a while now in one of our Sun mail clusters. Any input would be great! -- Erich M. Jenkins Fuujin Group Limited Visit us on the web at http://www.fuujingroup.com "You should never, never doubt what no one is sure about." -- Gene Wilder From owner-freebsd-scsi@FreeBSD.ORG Tue Dec 1 18:25:02 2009 Return-Path: Delivered-To: scsi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 52641106566B for ; Tue, 1 Dec 2009 18:25:02 +0000 (UTC) (envelope-from jh@FreeBSD.org) Received: from gw03.mail.saunalahti.fi (gw03.mail.saunalahti.fi [195.197.172.111]) by mx1.freebsd.org (Postfix) with ESMTP id 163A98FC17 for ; Tue, 1 Dec 2009 18:25:01 +0000 (UTC) Received: from a91-153-117-195.elisa-laajakaista.fi (a91-153-117-195.elisa-laajakaista.fi [91.153.117.195]) by gw03.mail.saunalahti.fi (Postfix) with SMTP id 757E4216626 for ; Tue, 1 Dec 2009 20:05:25 +0200 (EET) Date: Tue, 1 Dec 2009 20:05:25 +0200 From: Jaakko Heinonen To: scsi@FreeBSD.org Message-ID: <20091201180524.GB7961@a91-153-117-195.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.19 (2009-01-05) Cc: Subject: cd(4) M_WAITOK allocations with periph lock held 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, 01 Dec 2009 18:25:02 -0000 Hi, There are some M_WAITOK malloc invocations with periph lock held in cd(4). Below is a link to a patch which drops the periph lock while doing those allocations. Comments/review? --- Drop periph lock while allocating memory with M_WAITOK flag in cdreportkey(), cdsendkey() and cdreaddvdstructure(). PR: kern/130735 Tested by: Eygene Ryabinkin The patch against head: http://people.freebsd.org/~jh/patches/scsi_cd-M_WAITOK-fixes.diff -- Jaakko From owner-freebsd-scsi@FreeBSD.ORG Tue Dec 1 21:02:35 2009 Return-Path: Delivered-To: scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3C7AE106566B for ; Tue, 1 Dec 2009 21:02:35 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (skuns.zoral.com.ua [91.193.166.194]) by mx1.freebsd.org (Postfix) with ESMTP id 9FFC38FC0C for ; Tue, 1 Dec 2009 21:02:34 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id nB1Kho12001302 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Dec 2009 22:43:50 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id nB1KhoQb038037; Tue, 1 Dec 2009 22:43:50 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id nB1KhoGc038036; Tue, 1 Dec 2009 22:43:50 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 1 Dec 2009 22:43:50 +0200 From: Kostik Belousov To: Jaakko Heinonen Message-ID: <20091201204350.GD2368@deviant.kiev.zoral.com.ua> References: <20091201180524.GB7961@a91-153-117-195.elisa-laajakaista.fi> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VZLKKa0PG5KXlQhV" Content-Disposition: inline In-Reply-To: <20091201180524.GB7961@a91-153-117-195.elisa-laajakaista.fi> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: scsi@freebsd.org Subject: Re: cd(4) M_WAITOK allocations with periph lock held 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, 01 Dec 2009 21:02:35 -0000 --VZLKKa0PG5KXlQhV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Dec 01, 2009 at 08:05:25PM +0200, Jaakko Heinonen wrote: >=20 > Hi, >=20 > There are some M_WAITOK malloc invocations with periph lock held in > cd(4). Below is a link to a patch which drops the periph lock while > doing those allocations. Comments/review? >=20 > --- >=20 > Drop periph lock while allocating memory with M_WAITOK flag in > cdreportkey(), cdsendkey() and cdreaddvdstructure(). >=20 > PR: kern/130735 > Tested by: Eygene Ryabinkin >=20 > The patch against head: >=20 > http://people.freebsd.org/~jh/patches/scsi_cd-M_WAITOK-fixes.diff Would be useful for non-CAM people to put a little education into the commit log, describing why it is safe to drop the lock. --VZLKKa0PG5KXlQhV Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAksVgAUACgkQC3+MBN1Mb4hDDgCfUKlTf4vaEtkgLi4QmXwbC7/P xQ4AoJJRwmIyztDzdIIQ6BCZPCD3RRXh =5x7l -----END PGP SIGNATURE----- --VZLKKa0PG5KXlQhV-- From owner-freebsd-scsi@FreeBSD.ORG Tue Dec 1 21:30:40 2009 Return-Path: Delivered-To: scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2ABA4106566C; Tue, 1 Dec 2009 21:30:40 +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 2BD768FC13; Tue, 1 Dec 2009 21:30:39 +0000 (UTC) Received: from pooker.samsco.home (pooker.samsco.home [192.168.254.1]) by pooker.samsco.org (8.14.2/8.14.2) with ESMTP id nB1LUVdt069895; Tue, 1 Dec 2009 14:30:31 -0700 (MST) (envelope-from scottl@samsco.org) Date: Tue, 1 Dec 2009 14:30:31 -0700 (MST) From: Scott Long To: Jaakko Heinonen In-Reply-To: <20091201180524.GB7961@a91-153-117-195.elisa-laajakaista.fi> Message-ID: <20091201142930.I99667@pooker.samsco.org> References: <20091201180524.GB7961@a91-153-117-195.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-2138113359-1259703031=:99667" X-Spam-Status: No, score=-4.4 required=3.8 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: scsi@freebsd.org Subject: Re: cd(4) M_WAITOK allocations with periph lock held 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, 01 Dec 2009 21:30:40 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-2138113359-1259703031=:99667 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed How about the attached match instead. It refactors the code so that unlocks aren't needed. Scott On Tue, 1 Dec 2009, Jaakko Heinonen wrote: > > Hi, > > There are some M_WAITOK malloc invocations with periph lock held in > cd(4). Below is a link to a patch which drops the periph lock while > doing those allocations. Comments/review? > > --- > > Drop periph lock while allocating memory with M_WAITOK flag in > cdreportkey(), cdsendkey() and cdreaddvdstructure(). > > PR: kern/130735 > Tested by: Eygene Ryabinkin > > The patch against head: > > http://people.freebsd.org/~jh/patches/scsi_cd-M_WAITOK-fixes.diff > > -- > Jaakko > _______________________________________________ > 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" > --0-2138113359-1259703031=:99667 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=scsi_cd.c.WAITOK.diff Content-Transfer-Encoding: BASE64 Content-ID: <20091201143031.W99667@pooker.samsco.org> Content-Description: Content-Disposition: attachment; filename=scsi_cd.c.WAITOK.diff SW5kZXg6IHNjc2lfY2QuYw0KPT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KUkNT IGZpbGU6IC91c3IxL25jdnMvc3JjL3N5cy9jYW0vc2NzaS9zY3NpX2NkLmMs dg0KcmV0cmlldmluZyByZXZpc2lvbiAxLjExMg0KZGlmZiAtdSAtcjEuMTEy IHNjc2lfY2QuYw0KLS0tIHNjc2lfY2QuYwkxNCBOb3YgMjAwOSAyMDoxMzoz OCAtMDAwMAkxLjExMg0KKysrIHNjc2lfY2QuYwkxIERlYyAyMDA5IDIxOjI4 OjAwIC0wMDAwDQpAQCAtMjY3MywxMiArMjY3MywxMCBAQA0KIA0KIAkJYXV0 aGluZm8gPSAoc3RydWN0IGR2ZF9hdXRoaW5mbyAqKWFkZHI7DQogDQotCQlj YW1fcGVyaXBoX2xvY2socGVyaXBoKTsNCiAJCWlmIChjbWQgPT0gRFZESU9D UkVQT1JUS0VZKQ0KIAkJCWVycm9yID0gY2RyZXBvcnRrZXkocGVyaXBoLCBh dXRoaW5mbyk7DQogCQllbHNlDQogCQkJZXJyb3IgPSBjZHNlbmRrZXkocGVy aXBoLCBhdXRoaW5mbyk7DQotCQljYW1fcGVyaXBoX3VubG9jayhwZXJpcGgp Ow0KIAkJYnJlYWs7DQogCQl9DQogCWNhc2UgRFZESU9DUkVBRFNUUlVDVFVS RTogew0KQEAgLTI2ODYsOSArMjY4NCw3IEBADQogDQogCQlkdmRzdHJ1Y3Qg PSAoc3RydWN0IGR2ZF9zdHJ1Y3QgKilhZGRyOw0KIA0KLQkJY2FtX3Blcmlw aF9sb2NrKHBlcmlwaCk7DQogCQllcnJvciA9IGNkcmVhZGR2ZHN0cnVjdHVy ZShwZXJpcGgsIGR2ZHN0cnVjdCk7DQotCQljYW1fcGVyaXBoX3VubG9jayhw ZXJpcGgpOw0KIA0KIAkJYnJlYWs7DQogCX0NCkBAIC0zNzMyLDggKzM3Mjgs NiBAQA0KIAlkYXRhYnVmID0gTlVMTDsNCiAJbGJhID0gMDsNCiANCi0JY2Ni ID0gY2RnZXRjY2IocGVyaXBoLCBDQU1fUFJJT1JJVFlfTk9STUFMKTsNCi0N CiAJc3dpdGNoIChhdXRoaW5mby0+Zm9ybWF0KSB7DQogCWNhc2UgRFZEX1JF UE9SVF9BR0lEOg0KIAkJbGVuZ3RoID0gc2l6ZW9mKHN0cnVjdCBzY3NpX3Jl cG9ydF9rZXlfZGF0YV9hZ2lkKTsNCkBAIC0zNzU5LDkgKzM3NTMsNyBAQA0K IAkJbGVuZ3RoID0gMDsNCiAJCWJyZWFrOw0KIAlkZWZhdWx0Og0KLQkJZXJy b3IgPSBFSU5WQUw7DQotCQlnb3RvIGJhaWxvdXQ7DQotCQlicmVhazsgLyog Tk9UUkVBQ0hFRCAqLw0KKwkJcmV0dXJuIChFSU5WQUwpOw0KIAl9DQogDQog CWlmIChsZW5ndGggIT0gMCkgew0KQEAgLTM3NjksNiArMzc2MSw4IEBADQog CX0gZWxzZQ0KIAkJZGF0YWJ1ZiA9IE5VTEw7DQogDQorCWNhbV9wZXJpcGhf bG9jayhwZXJpcGgpOw0KKwljY2IgPSBjZGdldGNjYihwZXJpcGgsIENBTV9Q UklPUklUWV9OT1JNQUwpOw0KIA0KIAlzY3NpX3JlcG9ydF9rZXkoJmNjYi0+ Y3NpbywNCiAJCQkvKiByZXRyaWVzICovIDEsDQpAQCAtMzg3MCwxMSArMzg2 NCwxMiBAQA0KIAkJYnJlYWs7IC8qIE5PVFJFQUNIRUQgKi8NCiAJfQ0KIGJh aWxvdXQ6DQorCXhwdF9yZWxlYXNlX2NjYihjY2IpOw0KKwljYW1fcGVyaXBo X3VubG9jayhwZXJpcGgpOw0KKw0KIAlpZiAoZGF0YWJ1ZiAhPSBOVUxMKQ0K IAkJZnJlZShkYXRhYnVmLCBNX0RFVkJVRik7DQogDQotCXhwdF9yZWxlYXNl X2NjYihjY2IpOw0KLQ0KIAlyZXR1cm4oZXJyb3IpOw0KIH0NCiANCkBAIC0z ODg5LDggKzM4ODQsNiBAQA0KIAllcnJvciA9IDA7DQogCWRhdGFidWYgPSBO VUxMOw0KIA0KLQljY2IgPSBjZGdldGNjYihwZXJpcGgsIENBTV9QUklPUklU WV9OT1JNQUwpOw0KLQ0KIAlzd2l0Y2goYXV0aGluZm8tPmZvcm1hdCkgew0K IAljYXNlIERWRF9TRU5EX0NIQUxMRU5HRTogew0KIAkJc3RydWN0IHNjc2lf cmVwb3J0X2tleV9kYXRhX2NoYWxsZW5nZSAqY2hhbGxlbmdlX2RhdGE7DQpA QCAtMzk0MiwxMSArMzkzNSwxMiBAQA0KIAkJYnJlYWs7DQogCX0NCiAJZGVm YXVsdDoNCi0JCWVycm9yID0gRUlOVkFMOw0KLQkJZ290byBiYWlsb3V0Ow0K LQkJYnJlYWs7IC8qIE5PVFJFQUNIRUQgKi8NCisJCXJldHVybiAoRUlOVkFM KTsNCiAJfQ0KIA0KKwljYW1fcGVyaXBoX2xvY2socGVyaXBoKTsNCisJY2Ni ID0gY2RnZXRjY2IocGVyaXBoLCBDQU1fUFJJT1JJVFlfTk9STUFMKTsNCisN CiAJc2NzaV9zZW5kX2tleSgmY2NiLT5jc2lvLA0KIAkJICAgICAgLyogcmV0 cmllcyAqLyAxLA0KIAkJICAgICAgLyogY2JmY25wICovIGNkZG9uZSwNCkBA IC0zOTYzLDExICszOTU3LDEyIEBADQogDQogYmFpbG91dDoNCiANCisJeHB0 X3JlbGVhc2VfY2NiKGNjYik7DQorCWNhbV9wZXJpcGhfdW5sb2NrKHBlcmlw aCk7DQorDQogCWlmIChkYXRhYnVmICE9IE5VTEwpDQogCQlmcmVlKGRhdGFi dWYsIE1fREVWQlVGKTsNCiANCi0JeHB0X3JlbGVhc2VfY2NiKGNjYik7DQot DQogCXJldHVybihlcnJvcik7DQogfQ0KIA0KQEAgLTM5ODUsOCArMzk4MCw2 IEBADQogCS8qIFRoZSBhZGRyZXNzIGlzIHJlc2VydmVkIGZvciBtYW55IG9m IHRoZSBmb3JtYXRzICovDQogCWFkZHJlc3MgPSAwOw0KIA0KLQljY2IgPSBj ZGdldGNjYihwZXJpcGgsIENBTV9QUklPUklUWV9OT1JNQUwpOw0KLQ0KIAlz d2l0Y2goZHZkc3RydWN0LT5mb3JtYXQpIHsNCiAJY2FzZSBEVkRfU1RSVUNU X1BIWVNJQ0FMOg0KIAkJbGVuZ3RoID0gc2l6ZW9mKHN0cnVjdCBzY3NpX3Jl YWRfZHZkX3N0cnVjdF9kYXRhX3BoeXNpY2FsKTsNCkBAIC00MDA0LDEzICsz OTk3LDcgQEANCiAJCWxlbmd0aCA9IHNpemVvZihzdHJ1Y3Qgc2NzaV9yZWFk X2R2ZF9zdHJ1Y3RfZGF0YV9tYW51ZmFjdHVyZXIpOw0KIAkJYnJlYWs7DQog CWNhc2UgRFZEX1NUUlVDVF9DTUk6DQotCQllcnJvciA9IEVOT0RFVjsNCi0J CWdvdG8gYmFpbG91dDsNCi0jaWZkZWYgbm90eWV0DQotCQlsZW5ndGggPSBz aXplb2Yoc3RydWN0IHNjc2lfcmVhZF9kdmRfc3RydWN0X2RhdGFfY29weV9t YW5hZ2UpOw0KLQkJYWRkcmVzcyA9IGR2ZHN0cnVjdC0+YWRkcmVzczsNCi0j ZW5kaWYNCi0JCWJyZWFrOyAvKiBOT1RSRUFDSEVEICovDQorCQlyZXR1cm4g KEVOT0RFVik7DQogCWNhc2UgRFZEX1NUUlVDVF9QUk9URElTQ0lEOg0KIAkJ bGVuZ3RoID0gc2l6ZW9mKHN0cnVjdCBzY3NpX3JlYWRfZHZkX3N0cnVjdF9k YXRhX3Byb3RfZGlzY2lkKTsNCiAJCWJyZWFrOw0KQEAgLTQwMjcsMjEgKzQw MTQsOSBAQA0KIAkJbGVuZ3RoID0gc2l6ZW9mKHN0cnVjdCBzY3NpX3JlYWRf ZHZkX3N0cnVjdF9kYXRhX3NwYXJlX2FyZWEpOw0KIAkJYnJlYWs7DQogCWNh c2UgRFZEX1NUUlVDVF9STURfTEFTVDoNCi0JCWVycm9yID0gRU5PREVWOw0K LQkJZ290byBiYWlsb3V0Ow0KLSNpZmRlZiBub3R5ZXQNCi0JCWxlbmd0aCA9 IHNpemVvZihzdHJ1Y3Qgc2NzaV9yZWFkX2R2ZF9zdHJ1Y3RfZGF0YV9ybWRf Ym9yZGVyb3V0KTsNCi0JCWFkZHJlc3MgPSBkdmRzdHJ1Y3QtPmFkZHJlc3M7 DQotI2VuZGlmDQotCQlicmVhazsgLyogTk9UUkVBQ0hFRCAqLw0KKwkJcmV0 dXJuIChFTk9ERVYpOw0KIAljYXNlIERWRF9TVFJVQ1RfUk1EX1JNQToNCi0J CWVycm9yID0gRU5PREVWOw0KLQkJZ290byBiYWlsb3V0Ow0KLSNpZmRlZiBu b3R5ZXQNCi0JCWxlbmd0aCA9IHNpemVvZihzdHJ1Y3Qgc2NzaV9yZWFkX2R2 ZF9zdHJ1Y3RfZGF0YV9ybWQpOw0KLQkJYWRkcmVzcyA9IGR2ZHN0cnVjdC0+ YWRkcmVzczsNCi0jZW5kaWYNCi0JCWJyZWFrOyAvKiBOT1RSRUFDSEVEICov DQorCQlyZXR1cm4gKEVOT0RFVik7DQogCWNhc2UgRFZEX1NUUlVDVF9QUkVS RUNPUkRFRDoNCiAJCWxlbmd0aCA9IHNpemVvZihzdHJ1Y3Qgc2NzaV9yZWFk X2R2ZF9zdHJ1Y3RfZGF0YV9sZWFkaW4pOw0KIAkJYnJlYWs7DQpAQCAtNDA0 OSwxMyArNDAyNCw3IEBADQogCQlsZW5ndGggPSBzaXplb2Yoc3RydWN0IHNj c2lfcmVhZF9kdmRfc3RydWN0X2RhdGFfZGlzY19pZCk7DQogCQlicmVhazsN CiAJY2FzZSBEVkRfU1RSVUNUX0RDQjoNCi0JCWVycm9yID0gRU5PREVWOw0K LQkJZ290byBiYWlsb3V0Ow0KLSNpZmRlZiBub3R5ZXQNCi0JCWxlbmd0aCA9 IHNpemVvZihzdHJ1Y3Qgc2NzaV9yZWFkX2R2ZF9zdHJ1Y3RfZGF0YV9kY2Ip Ow0KLQkJYWRkcmVzcyA9IGR2ZHN0cnVjdC0+YWRkcmVzczsNCi0jZW5kaWYN Ci0JCWJyZWFrOyAvKiBOT1RSRUFDSEVEICovDQorCQlyZXR1cm4gKEVOT0RF Vik7DQogCWNhc2UgRFZEX1NUUlVDVF9MSVNUOg0KIAkJLyoNCiAJCSAqIFRo aXMgaXMgdGhlIG1heGltdW0gYWxsb2NhdGlvbiBsZW5ndGggZm9yIHRoZSBS RUFEIERWRA0KQEAgLTQwNjcsOSArNDAzNiw3IEBADQogCQlsZW5ndGggPSA2 NTUzNTsNCiAJCWJyZWFrOw0KIAlkZWZhdWx0Og0KLQkJZXJyb3IgPSBFSU5W QUw7DQotCQlnb3RvIGJhaWxvdXQ7DQotCQlicmVhazsgLyogTk9UUkVBQ0hF RCAqLw0KKwkJcmV0dXJuIChFSU5WQUwpOw0KIAl9DQogDQogCWlmIChsZW5n dGggIT0gMCkgew0KQEAgLTQwNzcsNiArNDA0NCw5IEBADQogCX0gZWxzZQ0K IAkJZGF0YWJ1ZiA9IE5VTEw7DQogDQorCWNhbV9wZXJpcGhfbG9jayhwZXJp cGgpOw0KKwljY2IgPSBjZGdldGNjYihwZXJpcGgsIENBTV9QUklPUklUWV9O T1JNQUwpOw0KKw0KIAlzY3NpX3JlYWRfZHZkX3N0cnVjdHVyZSgmY2NiLT5j c2lvLA0KIAkJCQkvKiByZXRyaWVzICovIDEsDQogCQkJCS8qIGNiZmNucCAq LyBjZGRvbmUsDQpAQCAtNDE2NiwxMSArNDEzNiwxMiBAQA0KIAl9DQogYmFp bG91dDoNCiANCisJeHB0X3JlbGVhc2VfY2NiKGNjYik7DQorCWNhbV9wZXJp cGhfdW5sb2NrKHBlcmlwaCk7DQorDQogCWlmIChkYXRhYnVmICE9IE5VTEwp DQogCQlmcmVlKGRhdGFidWYsIE1fREVWQlVGKTsNCiANCi0JeHB0X3JlbGVh c2VfY2NiKGNjYik7DQotDQogCXJldHVybihlcnJvcik7DQogfQ0KIA0K --0-2138113359-1259703031=:99667-- From owner-freebsd-scsi@FreeBSD.ORG Wed Dec 2 11:15:19 2009 Return-Path: Delivered-To: scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B8D261065676 for ; Wed, 2 Dec 2009 11:15:19 +0000 (UTC) (envelope-from thomas@FreeBSD.ORG) Received: from melamine.cuivre.fr.eu.org (unknown [IPv6:2001:470:1f15:1531:224:e8ff:fe3d:60a5]) by mx1.freebsd.org (Postfix) with ESMTP id 80E7E8FC1C for ; Wed, 2 Dec 2009 11:15:19 +0000 (UTC) Received: by melamine.cuivre.fr.eu.org (Postfix, from userid 1000) id C04222F4D; Wed, 2 Dec 2009 12:15:18 +0100 (CET) Date: Wed, 2 Dec 2009 12:15:18 +0100 From: Thomas Quinot To: scsi@freebsd.org Message-ID: <20091202111518.GA93985@melamine.cuivre.fr.eu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-message-flag: WARNING! Using Outlook can damage your computer. User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Subject: RDAC driver port? 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: Wed, 02 Dec 2009 11:15:19 -0000 All, Did anyone ever attempt a FreeBSD port of the Linux RDAC (Redundant Dual Active Controller) multipath driver? More generally, does anyone have experience in how best to set up a Dell PowerVault MD3000i iSCSI array with dual controllers on a FreeBSD host? Thanks! Thomas. From owner-freebsd-scsi@FreeBSD.ORG Wed Dec 2 13:59:23 2009 Return-Path: Delivered-To: scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 59959106566B for ; Wed, 2 Dec 2009 13:59:23 +0000 (UTC) (envelope-from jh@FreeBSD.org) Received: from gw01.mail.saunalahti.fi (gw01.mail.saunalahti.fi [195.197.172.115]) by mx1.freebsd.org (Postfix) with ESMTP id 1BCD38FC15 for ; Wed, 2 Dec 2009 13:59:23 +0000 (UTC) Received: from a91-153-117-195.elisa-laajakaista.fi (a91-153-117-195.elisa-laajakaista.fi [91.153.117.195]) by gw01.mail.saunalahti.fi (Postfix) with SMTP id 202D1151339; Wed, 2 Dec 2009 15:59:19 +0200 (EET) Date: Wed, 2 Dec 2009 15:59:19 +0200 From: Jaakko Heinonen To: Scott Long Message-ID: <20091202135919.GA3675@a91-153-117-195.elisa-laajakaista.fi> References: <20091201180524.GB7961@a91-153-117-195.elisa-laajakaista.fi> <20091201142930.I99667@pooker.samsco.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091201142930.I99667@pooker.samsco.org> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: scsi@freebsd.org Subject: Re: cd(4) M_WAITOK allocations with periph lock held 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: Wed, 02 Dec 2009 13:59:23 -0000 Hi, On 2009-12-01, Scott Long wrote: > How about the attached match instead. It refactors the code so that > unlocks aren't needed. Looks OK to me. Some nits below. > bailout: > + xpt_release_ccb(ccb); > + cam_periph_unlock(periph); > + The file seems to have an empty line after labels in other places. Maybe put one here too. > bailout: > > + xpt_release_ccb(ccb); > + cam_periph_unlock(periph); You can remove the now unused "bailout:" label from cdsendkey(). Do you want to commit it? Thanks. -- Jaakko From owner-freebsd-scsi@FreeBSD.ORG Wed Dec 2 16:08:52 2009 Return-Path: Delivered-To: scsi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7366410656C0; Wed, 2 Dec 2009 16:08:52 +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 26A498FC1A; Wed, 2 Dec 2009 16:08:51 +0000 (UTC) Received: from [IPv6:::1] (pooker.samsco.org [168.103.85.57]) (authenticated bits=0) by pooker.samsco.org (8.14.2/8.14.2) with ESMTP id nB2G8mpJ074474; Wed, 2 Dec 2009 09:08:49 -0700 (MST) (envelope-from scottl@samsco.org) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Scott Long In-Reply-To: <20091202135919.GA3675@a91-153-117-195.elisa-laajakaista.fi> Date: Wed, 2 Dec 2009 09:08:48 -0700 Content-Transfer-Encoding: 7bit Message-Id: <060A52A1-CFD0-4866-AD23-A1B47A2E79B5@samsco.org> References: <20091201180524.GB7961@a91-153-117-195.elisa-laajakaista.fi> <20091201142930.I99667@pooker.samsco.org> <20091202135919.GA3675@a91-153-117-195.elisa-laajakaista.fi> To: Jaakko Heinonen X-Mailer: Apple Mail (2.1076) X-Spam-Status: No, score=-4.4 required=3.8 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: scsi@FreeBSD.org Subject: Re: cd(4) M_WAITOK allocations with periph lock held 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: Wed, 02 Dec 2009 16:08:52 -0000 Done, thanks! Scott On Dec 2, 2009, at 6:59 AM, Jaakko Heinonen wrote: > > Hi, > > On 2009-12-01, Scott Long wrote: >> How about the attached match instead. It refactors the code so that >> unlocks aren't needed. > > Looks OK to me. Some nits below. > >> bailout: >> + xpt_release_ccb(ccb); >> + cam_periph_unlock(periph); >> + > > The file seems to have an empty line after labels in other places. > Maybe > put one here too. > >> bailout: >> >> + xpt_release_ccb(ccb); >> + cam_periph_unlock(periph); > > You can remove the now unused "bailout:" label from cdsendkey(). > > Do you want to commit it? > > Thanks. > -- > Jaakko From owner-freebsd-scsi@FreeBSD.ORG Wed Dec 2 17:02:23 2009 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 656AE1065670; Wed, 2 Dec 2009 17:02:23 +0000 (UTC) (envelope-from jh@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 39ECD8FC18; Wed, 2 Dec 2009 17:02:23 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nB2H2N6d053077; Wed, 2 Dec 2009 17:02:23 GMT (envelope-from jh@freefall.freebsd.org) Received: (from jh@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nB2H2Ls1053069; Wed, 2 Dec 2009 17:02:21 GMT (envelope-from jh) Date: Wed, 2 Dec 2009 17:02:21 GMT Message-Id: <200912021702.nB2H2Ls1053069@freefall.freebsd.org> To: scottl@freebsd.org, rea-fbsd@codelabs.ru, jh@FreeBSD.org, freebsd-scsi@FreeBSD.org From: jh@FreeBSD.org Cc: Subject: Re: kern/130735: [cam] [patch] pass M_NOWAIT to the malloc() call inside cdreaddvdstructure() 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: Wed, 02 Dec 2009 17:02:23 -0000 Synopsis: [cam] [patch] pass M_NOWAIT to the malloc() call inside cdreaddvdstructure() State-Changed-From-To: open->patched State-Changed-By: jh State-Changed-When: Wed Dec 2 17:00:16 UTC 2009 State-Changed-Why: Patched in head (r200036). http://www.freebsd.org/cgi/query-pr.cgi?pr=130735 From owner-freebsd-scsi@FreeBSD.ORG Fri Dec 4 23:05:30 2009 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 18EF31065670 for ; Fri, 4 Dec 2009 23:05:30 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: from mail-yx0-f171.google.com (mail-yx0-f171.google.com [209.85.210.171]) by mx1.freebsd.org (Postfix) with ESMTP id C18EA8FC0C for ; Fri, 4 Dec 2009 23:05:29 +0000 (UTC) Received: by yxe1 with SMTP id 1so2611333yxe.3 for ; Fri, 04 Dec 2009 15:05:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=Zj7xDlnu4zsVjeoNsOo4MlfLu5YWaoCggczWVjIMcv0=; b=NomGlt1xap+fpASL0MNDd4XCGt77RvoGsxTNgVtz/e0VG3NhtzGEgPHiCJfJRrUjp0 WzyHPZHGnATG3NT/wxyeEUI8QcyCoTD5jMTLHl9iGx/dolvxcK41ARMc5M7JAoAqqKJr 9tlbojFLoEtFh9ozG021HEUX19iWq6Mt4N3IQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=xPNflSjCO/kJhKmrTxL4iOSfexAy9vuA5QucV6Pi9awwrLslNNDLh0RTVUqGE+gTkM H7b9v5ksGepjuWhlMWtH5DhngUKWezUshBJt5pUN+2mYagUCqqAnMmZMp3zZ1Wy7DIbp rFDWUASxYTHX58AAtdWskbN6GPiiz2RfLer9o= MIME-Version: 1.0 Received: by 10.101.165.14 with SMTP id s14mr4819731ano.186.1259966556753; Fri, 04 Dec 2009 14:42:36 -0800 (PST) Date: Fri, 4 Dec 2009 17:42:36 -0500 Message-ID: <3c0b01820912041442q27c6f28fpbf53a6523945d77d@mail.gmail.com> From: Alexander Sack To: freebsd-scsi@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Adaptec aac(4) FIB starvation issues on BUS scan 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, 04 Dec 2009 23:05:30 -0000 Hey Everyone: I am running into several issues with the Adaptec aac(4) driver and FIB starvation during the probe PATH on xpt_bus_scan(). I am on right on a 6.1-amd64 machine with two Adaptec 5085s (6 channel) controllers connected to external JBODs as well as an MFI controller for the OS itself. Though this is legacy 6.1, I feel (have to test!) this might also be indicative on HEAD, RELENG_7-8, etc. Let me explain: aac_cam_action() (aac_cam.c): 250 case XPT_PATH_INQ: 251 { 252 struct ccb_pathinq *cpi = &ccb->cpi; 253 254 cpi->version_num = 1; 255 cpi->hba_inquiry = PI_WIDE_16; 256 cpi->target_sprt = 0; 257 258 /* Resetting via the passthrough causes problems. */ 259 cpi->hba_misc = PIM_NOBUSRESET; 260 cpi->hba_eng_cnt = 0; 261 cpi->max_target = camsc->inf->TargetsPerBus; The number of FIBs allocated to this card is 512 (older cards are 256). The max_target per bus is 287 (0x11F). On a six channel controller with a BUS scan done in parallel I see a lot of this: ... (probe501:aacp1:0:214:0): Request Requeued (probe501:aacp1:0:214:0): Retrying Command (probe520:aacp1:0:233:0): Request Requeued (probe520:aacp1:0:233:0): Retrying Command (probe528:aacp1:0:241:0): Request Requeued (probe528:aacp1:0:241:0): Retrying Command (probe540:aacp1:0:253:0): Request Requeued (probe540:aacp1:0:253:0): Retrying Command (probe541:aacp1:0:254:0): Request Requeued (probe541:aacp1:0:254:0): Retrying Command .... Now, this occurs because during the normal XPT_SCSI_IO request path during INQUIRY's (I didn't check but its out of the cam_periph_alloc()/probeXXX() stuff, I'm still debugging it). It runs out of FIBS as per: 311 /* Async ops that require communcation with the controller */ 312 313 mtx_lock(&sc->aac_io_lock); 314 if (aac_alloc_command(sc, &cm)) { WE ARE HERE, aac_alloc_command returned EBUSY 315 struct aac_event *event; 316 317 xpt_freeze_simq(sim, 1); 318 ccb->ccb_h.status = CAM_REQUEUE_REQ; 319 xpt_done(ccb); 320 event = malloc(sizeof(struct aac_event), M_AACCAM, 321 M_NOWAIT | M_ZERO); 322 if (event == NULL) { 323 device_printf(sc->aac_dev, 324 "Warning, out of memory for event\n"); 325 /* XXX Yuck, what to do here? */ 326 mtx_unlock(&sc->aac_io_lock); 327 return; 328 } 329 event->ev_callback = aac_cam_event; 330 event->ev_arg = camsc; 331 event->ev_type = AAC_EVENT_CMFREE; 332 aac_add_event(sc, event); 333 mtx_unlock(&sc->aac_io_lock); 334 return; 335 } The aac_alloc_command() function tries to grab a free FIB that has been released back to the driver but none are available (aac_dequeue_free returned NULL). So what it does is attempt to wakeup its internal working ktrhead, aac_command_thread(), to go allocate more FIBs. In the meantime, it freezes the SIMQ and sets CAM_REQUEUE_REQ (unconditionally force CAM to retry the request) and then allocate an internal event which will free the simq provided it can allocate a fresh batch of FIBs (iff under the maximum allowed by the controller). Questions: 1) What is the downside of this change: 259 cpi->hba_misc = PIM_NOBUSRESET | PIM_SEQSCAN; This makes the BUS scan an ORDER OF MAGNITUDE faster with no forced retries. I mean it. Instead of waiting for many many seconds, I wait for less than a second for targets to come back. 2) Why is CAM_REQUEUE_REQ appropriate? Isn't the driver banking on the fact that more FIBs will be allocated when at this point you have hit a resource starvation issue and something like CAM_RESRC_UNAVAIL to throttle jobs and give time for the either FIBs to be released back and or the command threads to allocate it. I am going to test this change anyway. 3) In the a similar topic of question 2, FIBs are indeed preallocated: 579 while (sc->total_fibs < AAC_PREALLOCATE_FIBS) { 580 if (aac_alloc_commands(sc) != 0) 581 break; 582 } AAC_PREALLOCATE_FIBS is set to 128. Any reason why not to preallocate all of them or at least HALF of them (256 of 512)? :D FIBS are 2k in size so 256 of them, 512k, is not THAT much to ask the kernel these days on most modern systems. By this change does not solve problem one (still too many requests). I want to point out that we've seen hangs during probe in our internal labs but its very hard to reproduce (I'm pretty sure now its due to commands eternally being retried by CAM due to FIB resource starvation but I am still trying to prove it). Any feedback would be most welcomed, -aps