Date: Sat, 30 Sep 1995 00:23:16 -0500 From: Jon Loeliger <jdl@chrome.onramp.net> To: freebsd-current@freebsd.org Subject: The Saga of the ATAPI Woes Message-ID: <199509300523.AAA18793@chrome.jdl.com>
next in thread | raw e-mail | index | archive | help
I finally caught it in the act of being bad!
Gory ATAPI details and problems follow, so make the right choice now... :-)
I've got:
----------------
controller wdc0 at isa? port "IO_WD1" bio irq 14 vector wdintr
disk wd0 at wdc0 drive 0
controller wdc1 at isa? port "IO_WD2" bio irq 15 vector wdintr
options ATAPI #Enable ATAPI support for IDE bus
device wcd0 #IDE CD-ROM
I'm using a -current from Before the Pre-Sig-11 Wars, but I've just
plopped down a fresh wcd-1.3 and applied the 4 recent <vak@cronyx.ru>
patches to it to get:
atapi.c: * Version 1.5, Thu Sep 21 23:08:11 MSD 1995
atapi.h: * Version 1.4, Tue Sep 5 20:59:48 MSD 1995
wcd.c: * Version 1.6, Fri Sep 22 21:40:12 MSD 1995
wd.c: * $Id: wd.c,v 1.84 1995/09/07 08:20:18 swallace Exp $
At boot, I find:
----------------
wdc0 at 0x1f0-0x1f7 irq 14 on isa
wdc0: unit 0 (wd0): <WDC AC31000H>
wd0: 1033MB (2116800 sectors), 2100 cyls, 16 heads, 63 S/T, 512 B/S
atapi0.1 at 0x1f0: attach called
atapiX.1 at 0x1f0: identify not ready, status=1<check>
wdc1 at 0x170-0x177 irq 15 on isa
atapi1.0 at 0x170: attach called
wdc1: unit 0 (atapi): <NEC CD-ROM DRIVE:260/4.23>, removable, cmd16
wcd0: info 85-80-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-34-2e-32-33-0-0-0-0-4e-45-43-20-20-20-20-20-20-20-20-20-20-20-20-20-20-20-20-20-43-44-2d-52-4f-4d-20-44-52-49-56-45-3a-32-36-30-0-0-0-0-0-0-0-0-a-0-0-0-3-0-0-0-0-3-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-b4-0-b4-0-0-0-0-0-0-0-0-0-0-0
atapi1.0: req im 5a-0-2a-0-0-0-0-0-1c-0-0-0-0-0-0-0 len=28
atapi1.0: start
atapi1.0: send cmd 5a-0-2a-0-0-0-0-0-1c-0-0-0-0-0-0-0
atapi1.0: intr ireason=0x3, len=28, status=41<ready,check>, error=64<abort>
atapi1.0: req im 5a-0-2a-0-0-0-0-0-1c-0-0-0-0-0-0-0 len=28
atapi1.0: start
atapi1.0: send cmd 5a-0-2a-0-0-0-0-0-1c-0-0-0-0-0-0-0
atapi1.0: intr ireason=0x2, len=24, status=48<ready,drq>, error=0
atapi1.0: intr ireason=0x3, len=24, status=40<ready>, error=0
atapi1.0: recv data underrun, 4 bytes left
wcd0: 344Kb/sec, 256Kb cache, audio play, 256 volume levels, ejectable tray
wcd0: no disc inside, unlocked
wcd0: cap 0-16-70-0-0-0-0-0-2a-e-0-0-71-65-29-3-61-1-0-1-0-1-61-1-0-0-0-0
atapi1.1 at 0x170: attach called
atapiX.1 at 0x170: no device
Now, the only odd thing here is that there was yet another change to the
handling of the reversing of the identify string. Now, it only reverses
the model, serial and revision bytes. Note that this does NOT affect
the 85-80 bytes.
In earlier mail, Serge indicated that this should be 80-85. Reversing
the entire buffer achieves this result. This produces the effect of:
current:
wdc1: unit 0 (atapi): <NEC CD-ROM DRIVE:260/4.23>, removable, cmd16
supposed correct from before:
wdc1: unit 0 (atapi): <NEC CD-ROM DRIVE:260>, removable, iordy
Flags iordy vs cmd16 have now changed. Which is correct? I suspect
that this is NOT a cmd16 CDROM drive, but don't really know.
Both before (with flag iordy) and now (with flag cmd16), there was
occasional failure reading large files from the CDROM file system.
I've captured a failure mode from the current configuration. BTW,
this is very repeatable, but not reliably at the exact same spot
of the same file or anything. This example comes from ftp'ing
a jpg image off the CDROM.
Here's what happened:
atapi1.0: send cmd 28-0-0-2-69-91-0-0-1-0-0-0-0-0-0-0
atapi1.0: req cb 28-0-0-2-69-92-0-0-1-0-0-0-0-0-0-0 len=2048
atapi1.0: intr ireason=0x2, len=2048, status=48<ready,drq>, error=0
atapi1.0: intr ireason=0x3, len=2048, status=40<ready>, error=0
atapi1.0: start
atapi1.0: send cmd 28-0-0-2-69-92-0-0-1-0-0-0-0-0-0-0
atapi1.0: intr ireason=0x2, len=2048, status=48<ready,drq>, error=0
atapi1.0: intr ireason=0x3, len=2048, status=40<ready>, error=0
atapi1.0: req cb 28-0-0-2-69-93-0-0-1-0-0-0-0-0-0-0 len=2048
atapi1.0: start
atapi1.0: send cmd 28-0-0-2-69-93-0-0-1-0-0-0-0-0-0-0
atapi1.0: intr ireason=0x1, len=60180, status=0, error=1<ili>
atapi1.0: unknown phase
wcd0: i/o error, status=0, error=1<ili>
atapi1.0: req cb 28-0-0-2-69-93-0-0-1-0-0-0-0-0-0-0 len=2048
atapi1.0: start
atapi1.0: send cmd 28-0-0-2-69-93-0-0-1-0-0-0-0-0-0-0
atapi1.0: req cb 28-0-0-2-69-94-0-0-1-0-0-0-0-0-0-0 len=2048
atapi1.0: intr ireason=0x3, len=2048, status=41<ready,check>, error=64<abort>
wcd0: media changed
atapi1.0: start
atapi1.0: send cmd 28-0-0-2-69-94-0-0-1-0-0-0-0-0-0-0
atapi1.0: intr ireason=0x3, len=2048, status=41<ready,check>, error=24<abort>
wcd0: cannot read audio disc
There were many sucessful transfers of 2k. Then suddenly we
got the error=1 report, and it fell apart.
One other thing that's been noticed (by a few):
- In atapi.c:263, the redeclaration of wcdattach() uses a return
value that isn't returned:
atapi.c: 265 if (wcdattach (ata, unit, ap, ata->debug, parent) < 0)
wcd.c:246 void wcdattach (struct atapi *ata, int unit, struct ...
Any insight as to why the IO transfer failedor which flags should be set?
Thanks for wading through this gunk!
jdl
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199509300523.AAA18793>