Re: SOLVED: mesh SCSI bus locks hard on 7500 when burning a CD-R in

User Michael Schmitz said:

Disconnect and reselect are implemented in the ESP driver which was used
as template for the 68k Mac 53C9x driver at one time. Maybe take a
page or two from these drivers to implement disconnect. That driver uses a
trick that might help avoiding the data direction lockup with MESH as
well: the chip is programmed for the whole arbitration/selection/command
phases but will interrupt right before data phase, at which point you
could check the data direction before setting up the DMA (assuming the
target asserts the data direction after seeing the command byte). One
additional interrupt taken. No additional overhead if you skip this step
for some well known commands like WRITE_* and READ_* :-)

This data direction table thing rings a bell. I helped implement a
scsi driver on SVR4 for the DPT (EATA) and it had the tables.
By SVR4.2 they were gone.

I noticed the same problems as Daniel writing dao CD's on my 7500.
I have the hard drive on the mesh and the tape drive and cdrw on
the 53c94.

In a post about 6 months ago I noted that the 53c94 didn't appear to
do disconnect because I couldn't write a CD even at 1x on a 7200.

As expected though, the cdrw will write on the 7500 on the 53c94
(not in dao) because the hard drive being on the mesh doesn't have to
wait for the 53c94 cd data transfer to finish before doing another read.

The tape drive was another clue. It did endless start/stops on the
7200 53c94 but on the 7500 53c94 by itself, streams nicely.

Thanks Daniel for digging this stuff out. A fix for the 53c94
disconnect problem would sure make the 7200 a  better platform.

Bob
--
Robert E. Brose II    N0QBJ
http://www.jriver.com/~bob/
bob@kunk.jriver.com

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Thanks Daniel for digging this stuff out. A fix for the 53c94
disconnect problem would sure make the 7200 a  better platform.

Unless Paul had specific reasons not to use the generic NCR53C9x driver
code for the mac53c94 driver, I'd say we should start from scratch using
the generic driver code base. I know it looks messy and a lot of the Sparc
cruft should be stripped out (IIRC Sparc still uses esp.c) but it might be
worth the trouble.

Problem is, the only Powermacs I could use for testing are a 7100 and a G3
(233 MHz desktop). Which one of these does use the 53C94?

	Michael


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

User Michael Schmitz says:

Unless Paul had specific reasons not to use the generic NCR53C9x driver
code for the mac53c94 driver, I'd say we should start from scratch using
the generic driver code base. I know it looks messy and a lot of the Sparc
cruft should be stripped out (IIRC Sparc still uses esp.c) but it might be
worth the trouble.

Problem is, the only Powermacs I could use for testing are a 7100 and a G3
(233 MHz desktop). Which one of these does use the 53C94?

I just did some online searching and wasn't able to find out. I
think the easiest way to find out would be to boot a kernel on each
machine and check the dmesg. You could just use a YDL or LPPC install
CD on the G3-233 but the 7100 is NuBus so you'd need to try the
experimental NuBus kernel.

I have a spare 7200 which I can use for testing as well.

Bob
--
Robert E. Brose II    N0QBJ
http://www.jriver.com/~bob/
bob@kunk.jriver.com


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

On Mon, 5 Feb 2001 20:28:21 +0100 (CET), Michael Schmitz
[off-list ref] wrote:

Problem is, the only Powermacs I could use for testing are a 7100 and a
G3
(233 MHz desktop). Which one of these does use the 53C94?

7100.  G3 desktop comes with mesh.


Takashi Oe

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/