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>