Boot Problem on 4000T Cyberstorm PPC Scsi Bus

[Doobrey]

thewalrus wrote:
The problem does seem to be in Set Patch!!
....
1. If I disable Set patch what other effect would it have on the system.

Setpatch fixes some bugs in the ROM,loads the parts of ROM Update that match the machine it's running on, and does the NSD patch (allows use of >4GB)..oh, and it also enables AGA mode on the A1200/A4000.

Have you tried removing/renaming the romupdate from DEVS: to see if Setpatch still fails? as others have reported problems with parts of the romupdate (although I've had no problems with 3.9bb2 in my A4000 with a CSmkII)

[thewalrus]

thanks for all of your help will try these things later in the day: kind regards the walrus

[thewalrus]

Fixed - Not really!! the problem was the Rom updates. Both updates have to be disabled and the computer will boot off the Cheetah drive attached to the Cyberstorm This leaves the question:
Do I disable the Rom Updates and install the system partition on the Cyberstorm Scsi Bus or do install the system partition on the 4000T Scsi bus to take advantage of the rom updates.
Does anybody know if the rom updates provide any real benefits?

Thanks to those who helped me find the problem!

[doctorq]

It's just a matter of finding out which module causes the problem. You can disable a module by writing SKIPROMMODULES "modulename" in the setpatch command line. I'm betting on either scs.device or exec.library to be the problem.

[Vanilla]

I know it's old but I just found it by Googling for "CyberStorm SCSI" as a friend has this exact problem. Then I encountered the symptoms myself but with a WarpEngine SCSI.Including the BB patch causing my machine display a blank screen and lose the drives when booting. I knewe it wanted to boot but just stood there with the floppy drive clicking.

Now I eventually also got hold of a CyberStorm SCSI myself. And when I set it up I read the mamual through and made sure both my hardware and software were set up correctly. That said, you guys missing something! I did not see one mention of what is highly important device driver settings: MaxTransfer and Mask!

These, though they are technical, MUST be set up correctly as per the instructions!! Otherwise you can expect missing drives, crashes and gerneal unstability! :-o

I don't know why they designed it this way and not so the device driver did all these techncal settiings itself but all controllers differ and they must be set correctly.

Ergo, you cannot pull a HD from your A4091 and stick it on your CyberSCSI, without adjusting the settings and at least setting MaxTransfer to the smallest safest value supported by both controllers.

[danbeaver]

I'm afraid changing the mask and the size of the transfer really doesn't matter; I won't cite references but I did an extensive search recently and found this to be an "old wives tale.". The CSPPC SCSI (cybppc.device) is a 68-pin UWSCSI bus supporting 15 devices with up to 8 logical units and one controller defaulted to #7; unlike the Blizzard SCSI device that HAS internal termination, the CSPPC needs two (2) "Active, Wide, LVD/SE powered terminators."  These correct for signal irregularities at UW speeds. Without them you are prone to hobgoblin of bus errors -- odd, irregular, unpredictable errors. On top of that, the SCSI controller does not play nice with a bunch of hard drives. It also does not like having U160 and U320 HDDs on the same bus.

The bus should look like:  TERM---CSPPC---Drive---Drive---TERM.

Look on EBay or the Internet for "female, active, wide, LVD or SE 68-pin terminators."  They run about 5 to 10 US, not 40 to 60 US.

The truth is out there, just search for it (and take notes).

[Vanilla]

The CSPPC SCSI is a different affair but on a CyberStorm 060 68K SCSI and WarpEngine I had problems! As one example my CD0 device kept crashing. I checked and I had an overflown MaxTransfer. IIRC it was set to 0x7FFFFFFF but CS SCSI has max of 0xFFFFFF! I cut it back and I could read CDs without crashing.

AFAIK it must reside in the area of 24-bit DMA.

So in my experience it is not an old wife tale but a fact!

[danbeaver]

We were talking about hard disk drives

[Vanilla]

Yes I know it was about HDDs but the settiings still matter for the controller. That was just an example. On my A4000D I have a CyberStom MkII with SCSI with correct settings.

On previous setups where Max and Mask were not set correctly I experenced immediate crash at power on due to installing FFS into the RDB. I also experienced drives going missing in the bootup process after applying the OS3.9 Boing patches where all I could see was a black screen and hear my floppy drive clicking.

So you can understand why I place importance on it. It may not affect all drive problems but I found it's better to set it up correctly and cross it off the list than ignoring it and hoping all the problems will go away.

[danbeaver]

That said, you guys missing something! I did not see one mention of what is highly important device driver settings: MaxTransfer and Mask! These, though they are technical, MUST be set up correctly as per the instructions!! Otherwise you can expect missing drives, crashes and gerneal unstability!  Ergo, you cannot pull a HD from your A4091 and stick it on your CyberSCSI, without adjusting the settings and at least setting MaxTransfer to the smallest safest value supported by both controllers.

From http://www.amiga-stuff.com/text/filesystems/SFS158.guide

"The MaxTransfer field"
The MaxTransfer field can be used to tell a filesystem that the device which comes with your (harddisk) controller can't handle more than a specific amount of data in a single access.  This problem usually occurs with IDE drives, which usually have a limit of 64 or 128 kB which can be transfered at once.  When a device has been properly written it should be able to cope with any amount of data being transfered.  These devices can have a MaxTransfer value of 0x7FFFFFFF.  Only badly written or very old devices need to set a smaller value in MaxTransfer -- in other words, the MaxTransfer value is a compatibility kludge to fix broken devices.  In any case, if you have a SCSI drive, then a MaxTransfer value of 0x7FFFFFFF should be just fine.  For IDE drives, you probably need to set it to 0x1FFFE or to 0xFFFE.  Those values represent 128 kB minus 2 bytes and 64 kB minus 2 bytes respectively.  An incorrect MaxTransfer value can usually be detected by copying a few large files (more than 200 kB) to such a partition.  If the large files are damaged while smaller files are undamaged then this is usually an indication that the MaxTransfer value is too large."

"The Mask field"  The Mask field can be used to tell a filesystem that the device which comes with your (harddisk) controller cannot directly access its data in all regions of memory available on your system.  When a device has been properly written it should be able to cope with data located anywhere in memory.  For those devices the Mask should be set to 0xFFFFFFFF.  Only badly written or very old devices need a different Mask -- in other words, the Mask value is a compatibility kludge to fix broken devices.  For example, some devices can't access data starting at an uneven address in memory.  Some even can only access data when it starts at an address which can be divided by four.  In the first case you would set the Mask field to end in 'FFFE', and in the second case to 'FFFC'. If your controller can handle addresses without alignment restrictions then you can set it to 'FFFF' (which is of course the preferred value).  There are also devices which can only access memory in the 24-bit memory area (everything below the 16 MB boundary).  Usually these are Zorro-II controllers which cannot directly access memory located on, for example, an accelerator card.  For these devices you set the mask to 0x00FFFFFF, indicating that the device can only access data in the 24-bit address space.  Devices which can access data located anywhere in memory (a SCSI controller which is embedded on an accelerator card, or a Zorro-III IDE or SCSI controller) should have a mask of 0xFFFFFFFF."