Amiga.org
Amiga computer related discussion => Amiga Hardware Issues and discussion => Topic started by: thewalrus on November 19, 2005, 02:06:26 AM
-
Can anybody help? I have a 4000T with Cyberstorm PPC and are having problems making a hard drive with a bootable System partition boot from the Cyberstorm Scsi Bus. I have no problem booting with another HDD attached to the 4000T's own Scsi Bus however when using another drive attached to the Cyberstorm Scsi Bus with a bootable System partition installed on it I get the error "program failed error #80000008" right at the start of the boot process. I have tried a fresh install of 3.9 1&2 and nothing else but the Cyberstorm sofware installed and only that one drive attached to the computer. I also tried a fresh install with nothing else but the 3.9 warp PPC software but still the same problem. I have tried copying over my existing system partition attached to the drive on the 4000T Scsi Bus with the Cyberstorm software installed but still the same. I have taken out zerro cards and checked the settings in the Cyberstorm boot menu. The drive attached to the Cyberstorm comes up fine when booting from the 4000T Scsi bus Its only when I make the other drive on the Cyberstorm Scsi bus bootable the problem arrises. I could leave the system partition on the drive attached to the 4000T own Scsi bus and use the drive attached to the Cyberstorm for other partitions and software but would like to solve the problem Can anybody help
-
I have a similar setup working well. The only difference between yours and mine is my card is only CS MK III 060, however I think the SCSI portion is the same.
Make sure you have proper cabling and termination on the CS SCSI side (IE the upper 8 address lines).
I am currently not using the SCSI on the A4000T motherboard so I have A4000D 40.68 roms installed which drastically reduces the boot up time. Also make sure no hard drives with a bootable partition are on the IDE buss. Mine only has a CDRW drive as master currently and that also helps. It seems that 40.70 roms and the A4000T IDE are a less than ideal combination.
Sorry if none of this helps but it's all I can think of at the moment.
-
@Jeff:
Interesting to know that A4000T works well with A4000D roms. I guess the only difference between 40.68 and 40.70 roms is the addition of the SCSI controller driver in 40.70 and removal of the workbench.library so that the SCSI driver could fit instead. :-)
-
It actually works much better with 40.68 if you can live without the onboard SCSI. Even the IDE buss works correctly with a Hard Drive and CDR (master and Slave).
-
When I copied over my System partition to the drive on the Cyberstorm Scsi bus (with cyberstorm software installed) and booted with that drive the error came up. If I soft booted I got a red screen which suggests a rom failure however booting up the other drive on the 4000T Scsi bus with still the drive attached on the Cyberstorm (non bootable)everyting works fine. As mentioned the problem only arises if I make the Cyberstorm Scsi drive bootable. I have tried another Scsi drive on the Cyberstorm side with nothing else attached bar CD rom on IDE side as well with a clean install and still the same problem. I even tried another Scsi cable termimated at each end. After a fresh install of 3.9 1&2 the red screen does not appear on a soft boot anymore however it still crashes after starting to boot. I even reformatted one of the drives before reinstall. The problem seems to be with the scsi bus or it not liking some software on boot. maybe some one could give me there Cyberstorm boot menu settings so I can check against mine
regards the Walrus
-
What are the SCSI setting set to in the CSPPC SCSI menu? Try setting them all to auto, to see if it helps.
About the computer crashing on boot; have you remembered to install the 040 and 060 libraries?
-
Done all of those things
Thanks for your help though!
-
Recently a guy had a similar problem because of the filesystem. He had a FFS on the plain SCSI side, and formatted a drive SFS on the Cyberstorm side, and then he had the same problem you have. Long shot, but are the filesystems the same (you formatted both drives the same filesystem) or you have saved filesystem changes to the Cyberstorm drive?
-
Try disabling SetPatch. Your board may not like one or more of the libraries that is being patched. I've had this problem with 3.9 and other accelerator's SCSI ports. Also, have you upgraded the install to BB2?
Mike
-
Hi there yes I have installed BB2. Thanks for your suggestion regarding Spatch as it gives me the impresssion it is a problem such as this Kind regards
the walrus
-
Hi thanks for your suggestion but FFS is installed. What I did was copy my existing files over after setting up new partitions on the new drive My existing files include 3.9 BB1 and BB2 I had also installed the Cyberstorm software before copying the existing files. When that did not work I started again by formatting the drive from scratch and installing 3.9 BB1 and BB2 with no other software I then just installed the Warp PPC fron the 3.9 CD thinking they might have later 060 PPC libaries than the older Cyberstorm disks I also tried reinstalling the Cyberstorm software but no change. Also I had another 4 gig HDD and did a fresh install thinking the Cheeath drive might be the problem and as I have a spare 4000T tried that machine as well. It sort of leaves me with a 3.9 software problem as it is at the very start of the boot process the machine crashes or the Cyberstorm card itself. regards the walrus
-
If it does it with two drives them I'm stumped :-?
-
The problem does seem to be in Set Patch!! If I disable it the computer does boot to a blank WB screen after stating I need a newer IDE Fix version (however I had not installed that software) I have just tried reinstalling 3.9 BB1 BB2 without updating the Rom part in BB2 (thinking that might work). It did'nt
Mike as you have had this problem some questions:
1. If I disable Set patch what other effect would it have on the system.
2.Did you use a older set patch
3. I note in the 3.9 S Startup file it states you can set SCSI device a no scsi update command or variable to something (how is that done,what is the something as stated in the S Startup file and would that make a difference I did try changing the "set ScsiUpdate 1" command to "set ScsiUpdate 0"
4. In your opinion do I just leave the system patition on the 4000T scsi controller and have my nice new Cheetah drive on the Cyberstorm controller just with other partitions because It just seems to hard!!
I would appreicate your thoughts and answers and anybody elses for that matter
-
If you want to use ONLY the CSPPC UWSCSI chain, disable the A4KT controller from the CSPPC BootMenu (hit the ESC key during the boot)
goto System, ENABLE MapROM and set the "NCR SCSIPatch" option (this switch, disable the A4KT onboard SCSI).
btw . . . do a:
version cybppc.device FULL
to see wich version of CSPPC FlashUpdate you have currently installed.
Take a look also to the "FlashBios.doc" in this archive
http://grex.amigaworld.de/daten/driver/FlashUpdateCSPPC.lha
to know all the options in the CSPPC BootMenu.
-
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)
-
thanks for all of your help will try these things later in the day: kind regards the walrus
-
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!
-
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.
-
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.
-
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).
-
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! ;)
-
We were talking about hard disk drives
-
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. :)
-
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."