Re: cd(4) vs bluray and cdda (dae) on ahci(4) and siis(4)

From: Juergen Lock <nox_at_jelal.kn-bremen.de>
Date: Thu, 6 Aug 2009 22:07:15 +0200
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
> > _at__at_ -2868,12 +2868,18 _at__at_
> >  	}
> >  
> >  	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.

> > 2. cdda/dae seems to be broken entirely with ahci(4) as well as
> > siis(4) (I remember a report about it being broken for usb optical
> > drives too so maybe this is related?) - I tested with the
> > audio/cdparanoia port as well as with
> > 	mplayer -cdrom-device /dev/cd{0,1} cdda://...
> > (mplayer needs to be built with the libparanoia knob on for this) - this
> > does work with atapicam(4) without ahci/siis so it can't be cd(4)'s
> > fault alone.  On siis(4) it seems to just fail while on ahci(4) (I still
> > have another optical drive on there, it's on the board's amd sb700)
> > it causes the sata channel to be reset endlessly until I ^C mplayer:
> > 
> > ahcich1: AHCI reset...
> > ahcich1: hardware reset ...
> > ahcich1: SATA connect time=0ms status=00000113
> > ahcich1: ready wait time=144ms
> > ahcich1: AHCI reset done: devices=00000001
> > ahcich1: AHCI reset...
> > ahcich1: hardware reset ...
> > ahcich1: SATA connect time=0ms status=00000113
> > ahcich1: ready wait time=144ms
> > ahcich1: AHCI reset done: devices=00000001
> > 
> > (Remeber if you want to reproduce this libparanoia needs permissions
> > on the optical drive's pass(4) device node and possibly /dev/xpt0 too.
> > And of course you need an audio cd. :)
> > 
> >  Soo, anyone have ideas/patches/things they want me to check for this?
> 
> But this appeared to to be really trivial. cdparanoia uses extremely 
> simple method for detecting ATAPI devices - it checks that SIM is named 
> "ata". Trivial single line hack made it successfully play some old 
> AudioCD in SATA drive on SiI3132 controller for me, while I am typing 
> this. Probably we should invent better way to do this.

Oooh! :)  I need to test this...

 Thanx,
	Juergen
Received on Thu Aug 06 2009 - 18:10:18 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:53 UTC