Date: Tue, 2 Dec 2003 22:52:33 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: Soren Schmidt <sos@spider.deepcore.dk> Cc: current@freebsd.org Subject: Re: ATAPI CD still not detected, verbose boot logs available Message-ID: <20031202212408.I10852@gamplex.bde.org> In-Reply-To: <200312020738.hB27ceLl034349@spider.deepcore.dk> References: <200312020738.hB27ceLl034349@spider.deepcore.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 2 Dec 2003, Soren Schmidt wrote: > It seems Christoph Sold wrote: > > FreeBSD 5.2-B still does not detect my ATAPI DVD-ROM drive. This used t= o > > work until S=F8ren's ATAng commits. Other OSes (Win, Linux, Solaris) > > detect the drive appropriately. > > Hmm from the bootlogs it seems that your drive does not set the proper > ATAPI signature, thats why detection fails: > > atapci0: <VIA 82C686A UDMA66 controller> port 0xd800-0xd80f at device 4.1= on pci0 > ata0: reset tp1 mask=3D03 ostat0=3D50 ostat1=3D50 > ata0-master: stat=3D0x80 err=3D0x80 lsb=3D0x80 msb=3D0x80 !!!!!!!!! bit 0x80 set says that the master is busy > ata0-slave: stat=3D0x00 err=3D0x01 lsb=3D0x14 msb=3D0x80 > ^^^^^^^^ should be 0xeb > ata0-master: stat=3D0x50 err=3D0x01 lsb=3D0x00 msb=3D0x00 !!!!!!!!! now the master is unbusy > ata0: reset tp2 mask=3D03 stat0=3D50 stat1=3D00 devices=3D0x1<ATA_MASTER> > ata0: at 0x1f0 irq 14 on atapci0 > ata0: [MPSAFE] Accessing the slave while the master is busy is invalid. I believe the failure mechanism is that the master keeps driving the bus while it is busy, so reads of the slave registers give garbage. This isn't a problem unless the slave becomes ready first and it manages to write a success code to the "err" register. Then we trust the garbage. It doesn't help that the master eventually becomes ready, since we don't read the slave registers again. > There isn't much I can do about that one except you experimenting with > the device and finding out why it fails setting the right signature.... Er, I sent patches for this a few months ago. After reanalysing their debugging putput combined with the above debugging output, I think this bug is is the usual case if there are 2 drives and the drives' timing after reset is as follows: =09o The master must take more than 100 msec to become ready. =09 Otherwise the 100 msec initial delay hides the bug. =09o The slave must become ready before the master. Otherwise =09 there is no problem with using garbage slave registers, =09 although accessing them is strictly invalid. The bug is just not often seen since most drives don't take 100 msec to become ready. I only see it on a system with an 8-9 year old pre-ATA IDE drive that takes 574 msec to become ready. For a quick fix, try increasing the initial delay of 100 msec to a second or more. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031202212408.I10852>