From owner-freebsd-scsi@FreeBSD.ORG Sat Aug 24 22:24:27 2013 Return-Path: Delivered-To: scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id CD53499 for ; Sat, 24 Aug 2013 22:24:27 +0000 (UTC) (envelope-from prvs=1948296411=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6CEC9273D for ; Sat, 24 Aug 2013 22:24:27 +0000 (UTC) Received: from r2d2 ([82.12.17.95]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50005673002.msg for ; Sat, 24 Aug 2013 23:23:45 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Sat, 24 Aug 2013 23:23:45 +0100 (not processed: message from valid local sender) X-MDDKIM-Result: neutral (mail1.multiplay.co.uk) X-MDDNSBL-Result: mail1.multiplay.co.uk, Sat, 24 Aug 2013 23:23:45 +0100 zen.spamhaus.org returned result of 127.0.0.11 X-MDRemoteIP: 82.12.17.95 X-Return-Path: prvs=1948296411=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: scsi@freebsd.org Message-ID: From: "Steven Hartland" To: "Will Andrews" , References: Subject: Re: 8K quirks & making quirk table more structured Date: Sat, 24 Aug 2013 23:24:53 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Aug 2013 22:24:27 -0000 That currently breaks the main reason for the output of quirks in xpt_announce_quirks Also it appears that the new method of setting lbppbe in scsi would make the result dependent on block_len which makes it potentially hard to predict the value needed to set a drive to 4 etc. In ata you use a different method entirely which its not good for consistency as ideally we should have just one set of quirks which work for scsi and ata. Also in ata you appear to have lost the output of quirks. Regards Steve ----- Original Message ----- From: "Will Andrews" To: Sent: Saturday, August 24, 2013 12:32 AM Subject: 8K quirks & making quirk table more structured > Hi, > > We have seen 8K blocksize devices in our lab, which require quirks to > behave properly. Rather than simply add another quirk for a different > size, we made the quirk entries more structured, and changed blocksize > to be a fixed-size integer element. > > Please review: http://people.freebsd.org/~will/head-convert-cam-quirk-tables-to-structs.diff > > The naming isn't particularly intuitive, but I'd like to check this in > as primarily a structural change, and follow up with other > improvements later. > > Thanks! > --Will. > _______________________________________________ > 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" > ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk.