Date: Tue, 20 Aug 1996 09:11:05 -0400 (WST) From: e8917523@antares.linf.unb.br (Daniel C. Sobral) To: hackers@freefall.freebsd.org Subject: 2.1.5R and ATAPI CD-ROM problems Message-ID: <9608201310.AA19668@antares.linf.unb.br> In-Reply-To: <199608192352.QAA28222@freefall.freebsd.org> from "owner-hackers-digest@freefall.freebsd.org" at Aug 19, 96 04:52:41 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> Thanks Jan, I *did* get your response. It just took me a while > to do the actual patching & testing. Following your advice, I > send the results to Bill Paul who wrote: > > > Tonight I blew a few hours playing with the ATAPI support. The result > > was the small patch appended to this message, which seems to make the > > detection of ATAPI devices happen much more reliably. This patch is > > for 2.2-current. > > So Bill, I applied your patches by hand since I only have 2.1.5R. > Hopefully, this is what you would expect : > > - - The probes still said > wdc0 at 0x1f0-0x1f7 irq 14 on isa > wdc0: unit 0 (wd0): <QUANTUM FIREBALL1080A> > wd0: 1039MB (2128896 sectors), 2112 cyls, 16 heads, 63 S/T, 512 B/S > wdc1 at 0x170-0x177 irq 15 on isa > wdc1: unit 0 (wd2): <ST3250A-XR> > wd2: 204MB (417792 sectors), 1024 cyls, 12 heads, 34 S/T, 512 B/S > wdc1: unit 1 (atapi): <HITACHI CDR-7730/0008a>, removable, iordy > wcd0: 689Kb/sec, 128Kb cache, audio play, 128 volume levels, ejectable > tray > wcd0: medium type unknown, unlocked ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Does this line appear _every_ time? > - - doing 'mount_cd9660 /dev/wcd0c /mnt' still responded > mount_cd9660: /dev/wcd0c: Device not configured Well, the problem is _not_ with detection. I have the same drive and, though I haven't had time yet to read 8020+8028 (ATAPI CD-ROM doc and errata), I made some experiences. The most interesting discovery is that, by enabling the DEBUG define (at least in the patched atapi.c), the drive start working! Not always, but most of the time anyway. The sheer amount of messages generated prevent the use of this as a "solution". Anyway, the "medium type unknown" message is what it should display. Lack of this message is caused by the same problem that prevents the drive use. I don't have any log with me now (I have already posted them to hackers anyway), but they seem to indicate that a command was received before completion of the latest command. This, and the fact that the drive works when DEBUG option is enabled in atapi.c, led me to believe that there is a problem with flow control/ handshaking protocol. I inserted DELAYs before every "print" in atapi.c and before the debug check in wcd.c, and tested with many values, but none of them worked. My current guess is that the disk access "print" causes somehow makes the driver interact with the drive correctly. -- Daniel C. Sobral (8-DCS) e8917523@linf.unb.br "Master, do we seek victory in contention?" "Seek rather not to contend, for without contention there can be neither victory nor defeat."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9608201310.AA19668>