OS 3.2, force validation?

[Jope]

Published by Commodore:
3.0 = v39
3.1 = v40

Published by Haage-Partner:
3.5 = v44, ReAction GUI introduced, ended up being an intermediate version
3.9 = v45, supersedes everything in 3.5, ended up in rights limbo and development stopped in 2002

Published by Hyperion:
3.1.4.x = v46, development resumes in 2016, has as much 3.9 code as possible, some 4.0 backports included, and more fixes/development done, no ReAction
3.2.x = v47, ReAction came back, most recent versions of everything

The PPC only 4.x was a different fork of the code base, but thankfully something came back to 68k eventually. You can run 4.x on your Blizzard PPC. I guess 4.1 final edition would be the way to go. Be sure to max out your RAM and all that.

[Thomas Richter]

Originally Posted by Malakie

OK, first off, 3.2 not supported was what I was told.

By whom? The 2091 is a CBM design, and of course, CBM does not support anything anymore, it's dead as a dodo. But that doesn't mean that anything in the 2091 prevents usage under 3.2. For the boot ROM, I guess nobody is able to provide an update, probably due to the lack of hardware, but as far as I know, the ROM-based scsi.device (actually, IDE) and the 2091 boot ROM share some common code.

Originally Posted by Malakie

I had asked others about updates to the SCSI.device, in EITHER the OS or rom based code and was told 3.2 is no longer officially supported or under development. If that is not correct, then by all means whomever is responsible for it, needs to make that clear because my understanding was 3.5/3.9 and the 4.x versions were now the primary focus.

There was neither an update for the 2091 as part of 3.5 or 3.9, and whoever made that claim that the device is "not supported" is wrong. It is not under maintenance by anyone, but there is nothing different in 3.2 that would prevent its usage.

Originally Posted by Malakie

BUT IF I then swap it out with all 3.2 stuff at which time even that machine, then exhibits all these same problems. So 4 machines I have tried. Three are setup with either A2091 or GVP, from 1.3, 2.04 and a PI-Raspberry 3.9 install. This fourth machine I wanted to use 3.2.

This does not sound very logical to me. Just to let you know, I have here an A2000 with a GVP HC+8 SCSI, and that runs very happily with 3.2 (or rather, a precursor of, but that shouldn't matter). All I can say is that you should only change one thing at a time, take a known working machine, and change the ROM there. I'm not clear from your description what you have changed, and I'm also not clear what else is in the machine (e.g. turbo board, what ever...)

Originally Posted by Malakie

As for termination. It is not a termination problem. I would think by now with my posts, people would realize things like that most of us are fully aware of when it comes to SCSI.

So where is the SCSI bus terminated? Yes, I know I'm annoying, but I still ask - a hung SCSI bus is really a typical indicator of bad termination. And what exactly do you observe?

Originally Posted by Malakie

The file size and type being copied, does NOT matter. It randomly happens during a copy, either CLI, desktop drag and drop or using a tool like DOPUS.

Sometimes it just hangs, other times it loops to the point it bloats the file to fill the entire HD. If you catch it fast enough, you can stop it before it fills the drive and are then able to delete it which then restores the HD to full space available. If you don't catch, your only option is to format the drive.

What "hangs"? If the drive LED stays lit, but you can still move the cursor, that's a hardware problem of some sort, and a typical issue of bad drive termination. If the drive fills, it's a software problem, not a hardware problem, but one I have never seen before.


Which file system is that, and which variant? (Say "version dh0:" in the shell to find out).


Then, how do you copy files? From the shell, or from the workbench? DOpus does have a couple of issues, so let's not complicate matters.

[Malakie]

Originally Posted by Jope

Published by Commodore:
3.0 = v39
3.1 = v40

Published by Haage-Partner:
3.5 = v44, ReAction GUI introduced, ended up being an intermediate version
3.9 = v45, supersedes everything in 3.5, ended up in rights limbo and development stopped in 2002

Published by Hyperion:
3.1.4.x = v46, development resumes in 2016, has as much 3.9 code as possible, some 4.0 backports included, and more fixes/development done, no ReAction
3.2.x = v47, ReAction came back, most recent versions of everything

The PPC only 4.x was a different fork of the code base, but thankfully something came back to 68k eventually. You can run 4.x on your Blizzard PPC. I guess 4.1 final edition would be the way to go. Be sure to max out your RAM and all that.

Thanks for the list. That helps a lot.

[Malakie]

Originally Posted by Thomas Richter

By whom? The 2091 is a CBM design, and of course, CBM does not support anything anymore, it's dead as a dodo. But that doesn't mean that anything in the 2091 prevents usage under 3.2. For the boot ROM, I guess nobody is able to provide an update, probably due to the lack of hardware, but as far as I know, the ROM-based scsi.device (actually, IDE) and the 2091 boot ROM share some common code.

There was neither an update for the 2091 as part of 3.5 or 3.9, and whoever made that claim that the device is "not supported" is wrong. It is not under maintenance by anyone, but there is nothing different in 3.2 that would prevent its usage.

This does not sound very logical to me. Just to let you know, I have here an A2000 with a GVP HC+8 SCSI, and that runs very happily with 3.2 (or rather, a precursor of, but that shouldn't matter). All I can say is that you should only change one thing at a time, take a known working machine, and change the ROM there. I'm not clear from your description what you have changed, and I'm also not clear what else is in the machine (e.g. turbo board, what ever...)

So where is the SCSI bus terminated? Yes, I know I'm annoying, but I still ask - a hung SCSI bus is really a typical indicator of bad termination. And what exactly do you observe?

What "hangs"? If the drive LED stays lit, but you can still move the cursor, that's a hardware problem of some sort, and a typical issue of bad drive termination. If the drive fills, it's a software problem, not a hardware problem, but one I have never seen before.

Which file system is that, and which variant? (Say "version dh0:" in the shell to find out).

Then, how do you copy files? From the shell, or from the workbench? DOpus does have a couple of issues, so let's not complicate matters.

Are you not reading what I clearly wrote? I pretty much answered every single question you just asked again. I can't be more clear in what I wrote in the previous post/reply.

What do I need to do? Create a video of step by step testing? You even asked which version I am running, how many versions on CD of 3.2 are sold? If there are multiple versions being sold, then most likely 3.2 IS the problem. You even stated it by saying "if the drive fills, it's a software problem...." WHICH is what I original said might be a possibility.

You need to go back and read what I wrote because I am not going to repeat ALL of that again here in another reply.. Every single one of your questions, I answered clearly and with details.

[Thomas Richter]

Originally Posted by Malakie

Are you not reading what I clearly wrote? I pretty much answered every single question you just asked again.

I beg your pardon, but this is not the Hyperion support here. I'm not related to them, I do not work for them, I'm only trying to help. No, you have not clearly written what you are using. You wrote about "a 2091", which I understand is a component that is included.


You haven't clearly written about other components. "A GVP" is a lot of things. GVP provided turbo boards (if so, which one, and which processor) and they provided SCSI host adapters (if, so which one?).



You also wrote about a Raspi. There are certainly some experimental turbo boards based on raspi, though whether they support DMA correctly I doubt, and the 2091 does DMA, which is another unknown in the equation. It would certainly be helpful to try without it first.

Originally Posted by Malakie

What do I need to do? Create a video of step by step testing? You even asked which version I am running, how many versions on CD of 3.2 are sold?

No, but an output of "ShowConfig" for starters, the output of "version DH0:". Then, please download "Devices" from Aminet, you'll find here:


http://aminet.net/package/dev/misc/Devices


and please also provide the output of "Devices DH0:", which will fill in the required information for the version of the filing system you are using. Warning, the above assumes that your harddisk is named "DH0:", please substitute to whatever name it actually has.



I certainly do not care about how many 3.2 disks have been sold as it is irrelevant to narrow down your problem, but SCSI bus termination *is* very relevant, so allow me to ask this again. In particular termination power can be tricky, so please also check this on your drive - it may have jumpers for it, as many host adapters are pre-SCSI-II and do not provide term power.
Sorry to mention this again, but I haven't seen a clear answer.

Originally Posted by Malakie

You need to go back and read what I wrote because I am not going to repeat ALL of that again here in another reply.. Every single one of your questions, I answered clearly and with details.

I don't need anything repeated. I just need more precise information in order to help you, that is, what exactly is in your system, which models, etc. The brand of the harddisk is not relevant at this point. I understand this is annoying, but I cannot help you without.


In worst case, if nothing helps, and if we narrow down the problem to the 2091, I can have a look at the software side support for it. As the 2091 does DMA, and DMA interacts with CPU caches, there is a slight possibility that something interacts badly with it, and at this point I can provide more detailed help. This, however, is mostly relevant for the combinations of the 2091 with the 68040 or 68060 processor, but to some degree to the 68030 as well. If nothing else helps, I would require a 2091 for reproduction for a couple of weeks - and I would of course return it back as soon as the problem has been narrowed. I do not need a harddisk, only a 2091 on a short time. But first things first.



Please understand, we are all hobbiysts here. If you want first level Os support, that's not here, and that's not my job.

[gulliver]

AmigaOS 3.2 comes in only ONE CD-ROM (no alternative variants exists). I know that because I mastered the CD-ROM and was consulted when subsequent batches were ordered.

Contrary to your beliefs AmigaOS 3.2 is fully supported. In fact, a free update dubbed "3.2.1" has been released just yesterday. Furthermore, the two very prolific and talented developers that answered your post, are in fact offering you support and they are both officially qualified to do so as they are part of the team that made AmigaOS 3.2 in the first place.

I suggest you to re-read their answers and take advantage of the advice they offer and understand that they are investing their time and will to help you out, so a less hostile attitude would certainly be apreciated.

[Malakie]

Originally Posted by gulliver

AmigaOS 3.2 comes in only ONE CD-ROM (no alternative variants exists). I know that because I mastered the CD-ROM and was consulted when subsequent batches were ordered.

Contrary to your beliefs AmigaOS 3.2 is fully supported. In fact, a free update dubbed "3.2.1" has been released just yesterday. Furthermore, the two very prolific and talented developers that answered your post, are in fact offering you support and they are both officially qualified to do so as they are part of the team that made AmigaOS 3.2 in the first place.

I suggest you to re-read their answers and take advantage of the advice they offer and understand that they are investing their time and will to help you out, so a less hostile attitude would certainly be apreciated.

YOU should have read what I wrote before jumping down my throat.. I could care less about who works for who but I AM tired of the contradictory replies.

Second, you like him are stuck on this ONE LINE I stated about OS 3.2 WHICH I CLARIFIED CLEARLY in another postr. I clearly stated it was WHAT I HAD BEEN TOLD BY OTHERS and if that was NOT the case, then clear that up, WHICH WAS ALREADY DONE.

Don't throw the hostile crap my way. I am frustrated because all I am getting is the same loop of comments and replies to something I CLEARLY EXPLAINED IN DETAIL.

Since YOU did not read it, I will post it again and I QUOTE:

"OK, first off, 3.2 not supported was what I was told. I had asked others about updates to the SCSI.device, in EITHER the OS or rom based code and was told 3.2 is no longer officially supported or under development. If that is not correct, then by all means whomever is responsible for it, needs to make that clear because my understanding was 3.5/3.9 and the 4.x versions were now the primary focus."

Don't come in here and try going after me and thinking I am just going to sit here while you throw mud because you did not read what I said.

Now because you and he are all upset by ONE COMMENT, you are stuck on that instead of paying attention to what I am actually writing and explaining, what I have done, the changes I have made, the things I have tried. And the other guy is doing the same thing.

So here, I will AGAIN REPEAT WHAT I WROTE EARLIER IN DETAIL:

OK, first off, 3.2 not supported was what I was told. I had asked others about updates to the SCSI.device, in EITHER the OS or rom based code and was told 3.2 is no longer officially supported or under development. If that is not correct, then by all means whomever is responsible for it, needs to make that clear because my understanding was 3.5/3.9 and the 4.x versions were now the primary focus.

I have clearly stated, I am playing 30 year catch up here. After working for Commodore, I went back military active duty. After my injuries retired me, I decided to pull my own Amiga gear out of long term storage to find most of it destroyed.

SO I am rebuilding what I can and replacing what I cannot. I am updating one machine to 3.2 (I have an A1200 using 3.9) and this machine is a rev 6.3 board. I have 2 other A2000's running, one that is using 2.04 with SCSI on an A2091 and original kickstart without ANY problems at all. None. No read write issues, no lockups of copying files... I have another machine with a rev 6 board using GVP scsi. No problems what so ever with it, including all the drives I have attempted to use in the build for 3.2 on the A2091 system.

BUT IF I then swap it out with all 3.2 stuff at which time even that machine, then exhibits all these same problems. So 4 machines I have tried. Three are setup with either A2091 or GVP, from 1.3, 2.04 and a PI-Raspberry 3.9 install. This fourth machine I wanted to use 3.2.

The machine I am wanting to run 3.2 is a separate machine, v6.3 motherboard, 1 meg ECS Agnus and an ECS Denise. It has 6 meg ram along with the A2091, which has been updated and tried with BOTH 7.0 roms and never released 8.0 roms.

I have also swapped out the SCSI chip itself to the 08 version. I have 4 of these cards, 6.6 roms, two with 7.0 roms and one with the 8.0 roms. I also have a A2091 modded back in the day for allowing max transfers and other needs for the A4000 I had which was destroyed in storage by condensation (the A4000 was, not sure on the A2091/4xxx yet as I have not gone through it).

As for IDE, the A2091 does support and is able to use IDE however it is the XT version IDE, not the more common modern IDE used today.

So I am not sure what is "inconsistent" with what I am saying? I figured most people were aware the IDE support was there and usable, just with XT interfaced drives.

As for termination. It is not a termination problem. I would think by now with my posts, people would realize things like that most of us are fully aware of when it comes to SCSI.

In my latest testing I am moving more toward this being a problem with the SCSI.device not being able to process things fast enough, especially with high speed drives and devices. The problem occurs repeatedly when trying to use anything like a CF card or more modern HD on the buss. Go back to the older drives like a 270 meg or so, and the problem still occurs but MUCH much less often.

I don't know if it is a buffer or cache issue, a validation on copy issue or something else, but with all the work I have done, my hardware is not the issue at all and I can reproduce this on 4 other machines here, two with rev 4.x boards, two with rev 6.x boards.

The file size and type being copied, does NOT matter. It randomly happens during a copy, either CLI, desktop drag and drop or using a tool like DOPUS.

Sometimes it just hangs, other times it loops to the point it bloats the file to fill the entire HD. If you catch it fast enough, you can stop it before it fills the drive and are then able to delete it which then restores the HD to full space available. If you don't catch, your only option is to format the drive.

BTW, note this is WITH a second device on the buss OR NOT. For example, I use a single 1 GB HD, partition to 500 meg over two partitions. I then go to copy files and it will still happen.

I have also tried to send files to external devices. Same result.

[Malakie]

Originally Posted by Thomas Richter

I beg your pardon, but this is not the Hyperion support here. I'm not related to them, I do not work for them, I'm only trying to help. No, you have not clearly written what you are using. You wrote about "a 2091", which I understand is a component that is included.

You haven't clearly written about other components. "A GVP" is a lot of things. GVP provided turbo boards (if so, which one, and which processor) and they provided SCSI host adapters (if, so which one?).

You also wrote about a Raspi. There are certainly some experimental turbo boards based on raspi, though whether they support DMA correctly I doubt, and the 2091 does DMA, which is another unknown in the equation. It would certainly be helpful to try without it first.

No, but an output of "ShowConfig" for starters, the output of "version DH0:". Then, please download "Devices" from Aminet, you'll find here:

http://aminet.net/package/dev/misc/Devices

and please also provide the output of "Devices DH0:", which will fill in the required information for the version of the filing system you are using. Warning, the above assumes that your harddisk is named "DH0:", please substitute to whatever name it actually has.

I certainly do not care about how many 3.2 disks have been sold as it is irrelevant to narrow down your problem, but SCSI bus termination *is* very relevant, so allow me to ask this again. In particular termination power can be tricky, so please also check this on your drive - it may have jumpers for it, as many host adapters are pre-SCSI-II and do not provide term power.
Sorry to mention this again, but I haven't seen a clear answer.

I don't need anything repeated. I just need more precise information in order to help you, that is, what exactly is in your system, which models, etc. The brand of the harddisk is not relevant at this point. I understand this is annoying, but I cannot help you without.

In worst case, if nothing helps, and if we narrow down the problem to the 2091, I can have a look at the software side support for it. As the 2091 does DMA, and DMA interacts with CPU caches, there is a slight possibility that something interacts badly with it, and at this point I can provide more detailed help. This, however, is mostly relevant for the combinations of the 2091 with the 68040 or 68060 processor, but to some degree to the 68030 as well. If nothing else helps, I would require a 2091 for reproduction for a couple of weeks - and I would of course return it back as soon as the problem has been narrowed. I do not need a harddisk, only a 2091 on a short time. But first things first.

Please understand, we are all hobbiysts here. If you want first level Os support, that's not here, and that's not my job.

Are you bothering to read what I wrote? I asked that already because here you replied and once again, asked me the SAME QUESTION I ALREADY ANSWERED.

1) YOU SAID: You wrote about "a 2091", which I understand is a component that is included.

WRONG, what I SAID was: "SO I am rebuilding what I can and replacing what I cannot. I am updating one machine to 3.2 (I have an A1200 using 3.9) and this machine is a rev 6.3 board. I have 2 other A2000's running, one that is using 2.04 with SCSI on an A2091 and original kickstart without ANY problems at all. None. No read write issues, no lockups of copying files... I have another machine with a rev 6 board using GVP scsi. No problems what so ever with it, including all the drives I have attempted to use in the build for 3.2 on the A2091 system."

2) YOU SAID: You haven't clearly written about other components. "A GVP" is a lot of things. GVP provided turbo boards (if so, which one, and which processor) and they provided SCSI host adapters (if, so which one?).

WRONG: ALL I said was I had a GVP HD SCSI IN ANOTHER MACHINE, NOT THIS ONE. AND I said NO PROBLEMS USING IT, JUST like the 2.04 machine setup. I.E. NEITHER exhibit the issue with their hardware and the version OS installed. The GVP machine, also exhibits the same issue if I use 3.2 on it. So for now it is running 3.1. The 2.04 machine has NO issues unless I swap the drive and with the 3.2 installed on it and the kickstart chip at which point it does the same error issues.

3) YOU SAID: You also wrote about a Raspi. There are certainly some experimental turbo boards based on raspi, though whether they support DMA correctly I doubt, and the 2091 does DMA, which is another unknown in the equation. It would certainly be helpful to try without it first.

WHAT I SAID: I have FOUR machines, the set up I am doing was as follows... One that includes raspberry pi. It is NOT RELEVANT to this issue. I was laying out the systems I have here, the rev of those mainboards and that they all function but I went ahead and SWAPPED PARTS with those boards to see if the problem was reproducible with ALL motherboard versions. Common sense would dictate that I did not just throw stuff together from one box to the next without removing things to make sure the test platform uses the same components as the primary system.

The COMMON PART is the mainboard, A2091 card and 3.2 kickstart and OS.

4) You again, completely ignored what I said about the A2091, roms and what I HAVE TRIED, and again I QUOTE:

"The machine I am wanting to run 3.2 is a separate machine, v6.3 motherboard, 1 meg ECS Agnus and an ECS Denise. It has 6 meg ram along with the A2091, which has been updated and tried with BOTH 7.0 roms and never released 8.0 roms.

I have also swapped out the SCSI chip itself to the 08 version. I have 4 of these cards, 6.6 roms, two with 7.0 roms and one with the 8.0 roms.

I ALSO stated CLEARLY, and again I QUOTE: "I am updating one machine to 3.2 (I have an A1200 using 3.9) and this machine is a rev 6.3 board. I have 2 other A2000's running, one that is using 2.04 with SCSI on an A2091 and original kickstart without ANY problems at all. None. No read write issues, no lockups of copying files... I have another machine with a rev 6 board using GVP scsi. No problems what so ever with it, including all the drives I have attempted to use in the build for 3.2 on the A2091 system.

NO PROBLEMS WHAT SO EVER ON THE OTHER MACHINES REGARDLESS OF THEIR CONFIGURATIONS with the hardware they have. I.E. ALL those machines run perfectly fine with other OS's and hardware without ANY copy problems, lockups, loops or anything else. ONLY when I try 3.2 does that problem rise up.

I have ALSO found as of last night, that there IS a different revision of 3.2 Kickstart versions out there. I have two kickstart chips here, both labeled 3.2. Yet both have different actual build version numbers. Had I not looked specifically at that, I would have continued to assume that both used the same revision.

And the reason I looked, I installed one of them and found a different problem on one board versus a second board. Swapping the KS changed the symptoms of the problem. Which means there is a major difference in the code between those two 3.2 kickstart chips.

BOTH chips I bought from dealers. yet they have two different sets of code in them? What else is different that I am still not aware of because this is a pretty major difference to be dealing with when someone is trying to troubleshoot a problem.

[Thomas Richter]

Originally Posted by Malakie

Don't throw the hostile crap my way. I am frustrated because all I am getting is the same loop of comments and replies to something I CLEARLY EXPLAINED IN DETAIL.

Sorry, to repeat: this is not "official support here". Even if it would, it requires collecting some informationon your side, and I beg for some patience. I provided instructions above for how to collect this information above and how to provide it. Please understand that without that information, we are down to speculation.



I wouldn't ask for the output for the progams if the information provided by these programs would not be required, as they are missing from your post.

[Thomas Richter]

Originally Posted by Malakie

Are you bothering to read what I wrote? I asked that already because here you replied and once again, asked me the SAME QUESTION I ALREADY ANSWERED.

Third time, last try: Please kindly provide the output of the above programs and please kindly post them here, on the affected machine. Yes, please, that's really needed.

[Michael]

A few people are reading this, and it is a bit overcomplicated and easy to get lost. I fully agree with Thomas that vital info is missing and the way it is currently presented confuses a bit. Like A1200, rev 6.3 and 2091 in one line An impossible combo.

Please specify exactly the specs of the machine and installed hardware

A2000 with 3.1 (40.68)or 3.2 (47.96 ?) physical rom
What CPU card is in use and it's config
Any other expansions connected

Does the system enter BootMenu without issues ?
Booting with no startup and doing setpatch and loadwb manually ?
Any issues ?

Is it a clean 3.2 install or over some previous installation ?
Any hacky/patchy software running ?
A lot is history now and not required and could cause issues.

PS: don't mix questions, stay to the point and provide details as requested if you wish to get help

[Olaf Barthel]

Originally Posted by Malakie

BTW, there was nothing wrong with the old diskdoctor.

Let's say the old Disk Doctor had its limitations, the documentation did not go into detail as to what to expect, documentation was not even available when Disk Doctor first shipped with Workbench 1.2 and Disk Doctor had bugs which did not help either. The documentation and implementation never could even answer if Disk Doctor could be used with FFS-formatted volumes.

Too many people did not understand how it actually worked and with that, caused more problems for themselves than anything else. Used properly, the old diskdoctor was actually a nice tool for CERTAIN errors but so many people tried to use it as a fix all for everything.

Having looked at the source code of the Workbench 1.x Disk Doctor, I would say that as implemented, there was no way to use it safely or properly on account of the bugs alone. You might get lucky, as I did back in the day when there was no comparable tool available and ejecting a floppy disk before the file system had written back its cache and spun down the drive made it so easy to get into trouble. Luck should not be a factor in this.

As far as I can tell the purpose of the original Workbench 1.x Disk Doctor is to make it sufficiently safe for the validation to proceed and to render the directory structure sufficiently consistent to allow you to copy data off the volume. It did not attempt to render the volume wholly consistent again. And the file system validation process could still get stuck and accomplish nothing.