Date: Fri, 01 Sep 1995 02:32:09 -0500 From: Jon Loeliger <jdl@chrome.onramp.net> To: hackers@freebsd.org Subject: Guess what? More ATAPI questions... Message-ID: <199509010732.CAA07281@chrome.onramp.net>
next in thread | raw e-mail | index | archive | help
Well folks,
I'm not getting too much further into solving the ATAPI problems,
but I've not given up yet...
I've now also read through the better part of the ATAPI driver from
the other camp too, and I now think I have a better understanding
of what should be going on. I think I can explain the apparent
"double interrupt" now. Here's the sequence of events as *I* think
they should happen:
- Decide to issue a MODE_SENSE request with immediate answers
as a packet command.
- Start a packet command
- set up port's register set to expect a packet command
upon writing the AR_COMMAND port, the drive is now expecting
the driver to send it the packet command.
- Drive acknowledges its willingness to accept the command
by doing the interrupt thang
- Meanwhile, the driver hit atapi_io() waiting for that interrupt
- atapi_io() correctly hits PHASE_CMDOUT and calls atapi_send_cmd()
- Wait for the controller to go idle
- Write the packet control info to the ports
==> This step is different in the FreeBSD code and the L-word camp <==
They *also* write a control word to the 0x3f6 port where we do NOT.
I have no idea if this is critical or not, but, it appears to me
to have something to do with "reseting" the status bits. Hmmm....
Continuing. It gets real fuzzy here, and I could easily be
making this up...
- Our code then waits for the next interrupt in atapi_io(), expecting
the results, I think, of the MODE_SENSE.
- However, due to potentially bad or not-reset status, we get a bad
interrupt reason and things degenerate.
Are we supposed to get another interrupt at the end of the command transfer?
Manipulation of the Device Control Register (0x3f6) seems to be totally
missing from this ATAPI code. It's that handling of things like
section 6.3.10 and 7.2.6 of the ATA Spec rev 4c that appears to be
missing.
Here's the debug trace:
mode capabilites len 24
sense page bytes
atapi1.0: req im 5a-0-2a-0-0-0-0-0-18-0-0-0-0-0-0-0 len=24
atapi1.0: start
atapi1.0: intr ireason=0x1, len=24, status=48<ready,drq>, error=0
atapi1.0: phase cmdout
atapi1.0: send cmd 5a-0-2a-0-0-0-0-0-18-0-0-0-0-0-0-0
atapi1.0: intr ireason=0x3, len=24, status=41<ready,check>, error=64<abort>
atapi1.0: phase complete
wcd1: result of mode sense is code=100, error=0xf01df474
If we believe the error code = 64 that I see, the spec says:
- UNC (Uncorrectable Data Error) indicates an uncorrectable data error
has been encountered.
Can anyone place more interpretation or insight into that problem?
Actually, I noticed that the other camp's code does a couple of odd
things with the error code. In particular, the fancy printing of an
error code is guarded by a dev->type == disk test. Hmmm... Then,
the routine ide_error() drops this hint:
if (dev->type == disk && (stat & ERR_STAT)) {
/* err has different meaning on cdrom */
if (err & BBD_ERR) /* retries won't help this! */
rq->errors = ERROR_MAX;
else if (err & TRK0_ERR) /* help it find track zero */
rq->errors |= ERROR_RECAL;
}
Am I confused or what? Did anyone really read all this?
jdl
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199509010732.CAA07281>