Falcon SCSI write issues

[mikro]

Almost same result as @mikro, basically (my 8MB purports to complete -- haven't checked the contents)

This one alone is quite interesting. My file size was also 8 388 608 bytes and it did hang. However I was copying using the desktop copier (and also using the latest HD Driver) so that could introduce some difference.

[SteveBagley]

I think @SteveBagley's code archeology was spot on.

It's fascinating piecing the development together…

Amazing. I guess any long term Falcon SCSI users settled on AHDI by experimentation, with its secret DMA size limits, or were not getting very much done productively? 8MB+ files weren't exactly rare even when this would have been a typical setup.

It would have to be a >8MB continuous chunk of clusters being read into ST RAM to trigger this, so any disk fragmentation or memory fragmentation that reduces the transfer below 8MB would stop the bug from happening. And that's assuming the hard disk driver had been modified to do large transfers rather than just doing multiple small ones.

There was some muttering earlier in the thread about seasoned Cubase users' rule of thumb was that HDDriver 8 was the best. Perhaps that and versions prior didn't do the same 'all the ST-RAM' trick so the problem was less of an issue back in the day?</speculation>

I don't think this bug would be that likely to fire in D2D audio applications. While they will create big files, they are almost certainly not doing large read/writes to the SCSI drives. If I were to code such an app, I'd have a ring buffer of reasonably sized buffers that I'd use to record/play audio in turn, while also reading/writing the buffers from/out to disk as they fill. The end result is a big file, but would avoid large SCSI transfers.

Steve

[SteveBagley]

Interesting.. Wonder what DMA chips they was actually referring to though.. Assume falcon going by the dates..

Yep, the file is specifically for the Sparrow SCSI.

The Falcon040 would have had more TT like SCSI:

SCSI.S - Set up the TT SCSI channel for either programmed or
DMA I/O.

The Falcon 040 SCSI should be able to use most of the
TT SCSI code. There are a couple of fixes that I know
of now. First, there is no need to use the residue
register anymore, the hardware will flush the FIFO.
I think the register will stay for compatibility.
Second, the TT SCSI now bus errors if you try to DMA
to the end of memory. That should be fixed in the
Falcon 040 SCSI. For the most up-to-date information
about these issues, contact John Hoenig.

SPSCSI.S - Set up the Sparrow SCSI channel for either programmed
or DMA I/O.

Sparrow SCSI is accessed by talking through the ACSI
DMA chip. Refer to the macros in SPSCSI.H to access
the SCSI registers.

When the standard _rcvspscsi() and _wrtspscsi() routines
(e.g. the format routine) are not used to do the I/O,
remember to set and clear "flock" appropiately. If
not, the floppy activities may interfere with the hard
disk activities.

The Linux guys must have known about all this as well then... But how.. Unless just experimenting..

Doesn't Linux have a disk cache, and so transfers will initially be to that, and then copied from their to RAM. In which case, the bug will never fire. Edited to add: There's also paged memory in Linux which will break up continuous transfers…

Steve

[exxos]

Seems people have overtaken me a bit

This is @jookie's new sector test program.

tst_manu.zip

(6.41 KiB) Downloaded 4 times

"Rough test"

IMG_3725.JPG (242.82 KiB) Viewed 129 times

"Single sector tests"

IMG_3726.JPG (250.23 KiB) Viewed 129 times

[mikro]

@exxos that's pretty surprising that you could read all the 16383 sectors = ~7.99 MB after all (i.e. way after the 3 MB limit which didn't work for you in the first place).

[stephen_usher]

The Linux guys must have known about all this as well then... But how.. Unless just experimenting..

Doesn't Linux have a disk cache, and so transfers will initially be to that, and then copied from their to RAM. In which case, the bug will never fire. Edited to add: There's also paged memory in Linux which will break up continuous transfers…

Steve

The other issue is that large block reads/writes would cause the system to hang in I/O wait for far too long for an interactive, multi-user, multi-tasking OS. Linux would most likely use the normal UNIX system 4K or, in exceptional cases, 8K chunks.

[exxos]

@exxos that's pretty surprising that you could read all the 16383 sectors = ~7.99 MB after all (i.e. way after the 3 MB limit which didn't work for you in the first place).

Jookie just said there was a bug in his first program which had a 3 second timeout.. So that explains the confusion..

Also as I mentioned originally, I could copy files about 6.7MB or there abouts.. Just I didn't know if the data was verified after copy..

Now I can go back to the problem I had before I got distracted with this problem!

Now if cubase uses its own SCSI routines..

[SteveBagley]

The other issue is that large block reads/writes would cause the system to hang in I/O wait for far too long for an interactive, multi-user, multi-tasking OS. Linux would most likely use the normal UNIX system 4K or, in exceptional cases, 8K chunks.

Yep and there's also this bit I found in the kernel driver:

Code: Select all

	/* Last step: apply the hard limit on DMA transfers */
	limit = (atari_dma_buffer && !STRAM_ADDR(virt_to_phys(NCR5380_to_ncmd(cmd)->ptr))) ?
		    STRAM_BUFFER_SIZE : 255*512;

and this comment:

Code: Select all

	/* ST DMA chip is stupid -- only multiples of 512 bytes! (and max.
	 * 255*512 bytes, but this should be enough)

So Linux on the Falcon is safe (since 255 < 16383 )

Steve

[Badwolf]

The other issue is that large block reads/writes would cause the system to hang in I/O wait for far too long for an interactive, multi-user, multi-tasking OS. Linux would most likely use the normal UNIX system 4K or, in exceptional cases, 8K chunks.

Interestingly the cursor continued to flash during my tests. Including when it hung, so interrupts must still have been working implying the bus isn’t relinquished for the entire duration of the transfer.

Does it work a bit like blitter nohog mode, I wonder?

Anyway point being I don’t see why multitasking would be unduly affected. Or perhaps I’ve misunderstood your point?

BW

[exxos]

So due to the other SCSI issue thread I started..
viewtopic.php?f=23&t=7983

We need to know now if cubase has its own SCSI driver.. And if so.. Does it suffer from the same "8MB bug"..