From owner-freebsd-scsi@FreeBSD.ORG Thu Aug 6 22:57:08 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 12CFF1065670 for ; Thu, 6 Aug 2009 22:57:08 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: from smtp.kn-bremen.de (gelbbaer.kn-bremen.de [78.46.108.116]) by mx1.freebsd.org (Postfix) with ESMTP id C7C858FC1B for ; Thu, 6 Aug 2009 22:57:07 +0000 (UTC) Received: by smtp.kn-bremen.de (Postfix, from userid 10) id C8F811E0030E; Fri, 7 Aug 2009 00:40:30 +0200 (CEST) Received: from triton.kn-bremen.de (noident@localhost [127.0.0.1]) by triton.kn-bremen.de (8.14.3/8.14.3) with ESMTP id n76Mc6De006516; Fri, 7 Aug 2009 00:38:06 +0200 (CEST) (envelope-from nox@triton.kn-bremen.de) Received: (from nox@localhost) by triton.kn-bremen.de (8.14.3/8.14.3/Submit) id n76Mc6Pv006515; Fri, 7 Aug 2009 00:38:06 +0200 (CEST) (envelope-from nox) From: Juergen Lock Date: Fri, 7 Aug 2009 00:38:06 +0200 To: Juergen Lock Message-ID: <20090806223806.GA6332@triton.kn-bremen.de> References: <20090806184510.GA12039@triton.kn-bremen.de> <4A7B3328.5020307@FreeBSD.org> <20090806200715.GA16313@triton.kn-bremen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090806200715.GA16313@triton.kn-bremen.de> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-scsi@FreeBSD.org, Alexander Motin , freebsd-current@FreeBSD.org Subject: Re: cd(4) vs bluray ... 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, 06 Aug 2009 22:57:08 -0000 On Thu, Aug 06, 2009 at 10:07:15PM +0200, Juergen Lock wrote: > On Thu, Aug 06, 2009 at 10:46:48PM +0300, Alexander Motin wrote: > > Juergen Lock wrote: > > > So I put the problematic optical drive on a siis pcie card now because > > > I wanted to play with esata too which seems to be kinda broken on the > > > jmicron that I used before at least with _this_ esata drive (hw issue > > > most likely, has been reported by users of other OSes too) - and I > > > noticed two things: > > > > > > 1. cd(4) (which the new ahci and siis drivers now also use) fails to do > > > any reads when a drive fails the read toc command as seems to happen > > > with bluray (data) discs at least; I was able to work around this > > > by moving the bailout: label up a few lines in scsi_cd.c:cdcheckmedia(): > > > > > > Index: sys/cam/scsi/scsi_cd.c > > > @@ -2868,12 +2868,18 @@ > > > } > > > > > > softc->flags |= CD_FLAG_VALID_TOC; > > > + > > > +bailout: > > > softc->disk->d_maxsize = DFLTPHYS; > > > softc->disk->d_sectorsize = softc->params.blksize; > > > softc->disk->d_mediasize = > > > (off_t)softc->params.blksize * softc->params.disksize; > > > > > > +/* if > > > bailout: > > > + * is here read requests will fail when the toc cant be read although > > > + * CD_FLAG_VALID_MEDIA is set. > > > + */ > > > > > > /* > > > * We unconditionally (re)set the blocksize each time the > > > > > > (I say work around because I don't know if there might be stuff > > > somewhere that depends on the old behaviour, although thats probably > > > unlikely; also acd(4) seems to behave similarly.) > > > > I have no idea about this, ... > > > Btw with `acd(4) seems to behave similarly' I meant a drive on acd > _can_ read bluray. Ok what do the -scsi folks say about this? Should it check for the disc (or drive?) to be bluray on only accept read toc failure in that case? Or is the patch fine as it is? As I said the old acd(4) driver seems not to care i.e. reads from bluray discs just fine... Wondering, Juergen