Date: Thu, 31 Aug 1995 11:24:03 -0500 From: Jon Loeliger <jdl@chrome.onramp.net> To: Bruce Evans <bde@zeta.org.au> Cc: hackers@freebsd.org Subject: Re: More ATAPI -- possible insight into probe problems...? Message-ID: <199508311624.LAA02661@chrome.onramp.net> In-Reply-To: Your message of "Thu, 31 Aug 1995 05:17:15 %2B1000." <199508301917.FAA18876@godzilla.zeta.org.au>
next in thread | previous in thread | raw e-mail | index | archive | help
Apparently, Bruce Evans scribbled:
> I asked:
> >So who can tell me any details about that lovely weak check for R/W
> >registers that appears to be failing for me? Simple things like:
>
> > - Is this a valid register for a CDROM drive too? Ie, is this check
> > tacitly assuming a hard disk beneath it?
> > - Is it subject to timing problems?
> > - It *claims* to be "too weak", however it appears to be too strong!
>
> It's too weak for ST506...EIDE controllers with normal drives attached.
> These all have read/write registers, so the inb() should return what
> was written. That used to be tested for, but someone weakened the
> test without documenting why.
Why not test agains the value written then instead of a 0xff...?
> I don't know what happens for CDROM drives.
Er, I wonder too. In particular, when it is on a bus that also
has a disk on it, it appears to work fine. When on a bus as the
sole device, it appears to fail (for me).
> The point of the test is to attempt to limit the damage if there is
> a device other than an ST506...EIDE controller behind the port. It
> is far too weak for that (if 0xff wasn't so magic, then the test
> would have much less than a 1/256 chance of detecting conflicts).
> Even if it tested for `== 0xa5', then any device with a read/write
> port at the probed address would pass the test.
I looked at the ATAPI spec, and there is supposed to be a R/W address
there. Even for the CDROM, it appears like 0x170 + 4 was R/W. I
wonder, however, if it was subject to timing and/or validity checks
that prevent it from being arbitrarily read/written.
Is the ST506 on the motherboard or on a drive? Do I have one? I
looked on the motherboard, and I can find a Big Chip (tm) near the
ribbon cables labled FDC37C665GT made by SMC. Floppy Disc Controller?
Couldn't find anything with ST506 on it.
This is a DELL P90 Dimension XPS. It's got a "PCIset" of chips on it too...
BTW, I see:
fdc0: NEC 72065B
chip0 <Intel 82434NX (Neptune) PCI cache memory controller> rev 17 on pci0:0
chip1 <Intel 82378IB PCI-ISA bridge> rev 67 on pci0:2
> The test is very sloppy. It should do something like:
Looks like you've been here before! :-) Should your code be
added to the driver? Or, perhaps, why *shouldn't* your code
be added?
> Then the test would be stronger and your CDROM would be sure to fail :-).
I laughed out loud at this point!
Removing this test does allow the device to be recognized and probe()-able.
However, it still totally fails to attach(). I noticed this comment in
the TODO section of wd.c:
/* TODO:
* o Satisfy ATA timing in all cases.
*
* o Don't use polling except for initialization. Need to
* reorganize the state machine. Then "extra" interrupts
* shouldn't happen (except maybe one for initialization).
It's this last one that worries me, because I think that is the one
that is stopping this code from working for myself and at least one
other person (Steve).
The debug trace shows:
wdc1 at 0x170-0x177 irq 15 on isa
atapi1.0 at 0x170: attach called
wdc1: unit 0 (atapi): <NEC CD-ROM DRIVE:260>, removable, cmd16
[info deleted]
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: send cmd 5a-0-2a-0-0-0-0-0-18-0-0-0-0-0-0-0
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
atapi1.1 at 0x170: attach called
atapi.1 at 0x170: no device
Here, I think the problem is a joint bobbling by atapi_request_immediate(),
atapi_send_cmd() and atapi_io(). If a_r_i() is doing the a_s_c() call,
why does wait_io() think it should too?
/* Start packet command, wait for DRQ. */
if (atapi_start_cmd (ata, ac) >= 0 && atapi_wait_cmd (ata, ac) >= 0) {
/* Send packet command. */
atapi_send_cmd (ata, ac);
/* Do all needed i/o. */
while (atapi_io (ata, ac))
/* Wait for DRQ deassert. */
for (cnt=2000; cnt>0; --cnt)
if (! (inb (ata->port + AR_STATUS) & ARS_DRQ))
break;
}
Might there be a needed "wait for clear flags" before the atapi_io()
happens? Is this atapi_send_cmd() just simply not needed here?
I removed the call to atapi_send_cmd() and got this instead:
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
atapi1.1 at 0x170: attach called
atapi.1 at 0x170: no device
So, that clearly isn't the straight up answer... Oh well.
Well then, all this begs the simple questions...
- Anyone else fixed this one yet?
- Am I the only one who sees a problem with the IDE CDROM?
- Will 2.1 contain this driver code -- fixed or broken?
I personally am at a bit of a loss to actually change this code
in any significant way.
jdl
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199508311624.LAA02661>