OS 3.2, force validation?

[Malakie]

Hi,

With OS 3.2, is there a way to force validation of a SCSI drive?

Diskdoctor is no help since I can't seem to find a way to actually make it do anything except read the drive without fixing it.

The HD is a Quantum LPS 540 internal.

[thomas]

Originally Posted by Malakie

without fixing it.

Validation won't fix anything, too. It just rebuilds the bitmap of used and unused blocks. If the file system structure is damaged, validation will fail and the partition will stay locked.

[Malakie]

Originally Posted by thomas

Validation won't fix anything, too. It just rebuilds the bitmap of used and unused blocks. If the file system structure is damaged, validation will fail and the partition will stay locked.

The current error is that the drive is not validated. I.E. unable to delete a file even due to that. The problem is tied to another problem where the thing keeps getting into some kind of copy loop where it just suddenly gets stuck on one file that is being copied and bloats the size to the entire size of the HD. Deleting that file usually then allows full validation, the drive size returns to normal.

So I am troubleshooting two issues. That file copy bloat issue and the drive being unvalidated and not doing so on its own like it should.

[shaf]

it sounds like you have a few bad blocks on the drive, if you can transfer data to another drive i would then suggest a low level format of the drive. That is the only time an Amiga Drive requires low level formatting to verify bad blocks, and if there are more than 10% of the drive its likely to be one of the heads that is bad. Its time to throw out the drive.
I've had problems like this with some Conner drives.

[thomas]

Originally Posted by Malakie

The problem is tied to another problem

You are probably referring to this thread on Amiga.org: https://forum.amiga.org/index.php?topic=75441.msg854064

So your initial mistake was to place a RAM boad the wrong way. By that probably some of the RAM got damaged and now gives random results.

IMHO there is nothing wrong with the HDD or file system, it's all caused by the bad RAM.

[Malakie]

Originally Posted by shaf

it sounds like you have a few bad blocks on the drive, if you can transfer data to another drive i would then suggest a low level format of the drive. That is the only time an Amiga Drive requires low level formatting to verify bad blocks, and if there are more than 10% of the drive its likely to be one of the heads that is bad. Its time to throw out the drive.
I've had problems like this with some Conner drives.

In this case, nope. Drive tests out with no bad sectors at all on BOTH Amiga and PC.

The drive works just fine on the PC. On the Amiga, everything is set correctly for size, heads etc (which are marked on drive label). Formats just fine. Verifies just fine.

[Malakie]

Originally Posted by thomas

You are probably referring to this thread on Amiga.org: https://forum.amiga.org/index.php?topic=75441.msg854064

So your initial mistake was to place a RAM boad the wrong way. By that probably some of the RAM got damaged and now gives random results.

IMHO there is nothing wrong with the HDD or file system, it's all caused by the bad RAM.

Uh no.. I worked for Commodore Amiga and am playing catch up with the new hardware and OS's just getting back into the scene.

Plugging a memory board, the A2058, is impossible first off but it is also I would not do even if I could. I tear these things down to component level.

Ram is fine. Tests fine. This is an issue I only see under OS 3.2 which is why I asked. The last OS I used back in the day was 2.04. And that works perfectly on this machine without this issue and using the older kickstart.

This started with the new kickstart and OS 3.2, which I am now learning as I said.

[Thomas Richter]

Originally Posted by Malakie

Hi,

With OS 3.2, is there a way to force validation of a SCSI drive?

Diskdoctor is no help since I can't seem to find a way to actually make it do anything except read the drive without fixing it.

The HD is a Quantum LPS 540 internal.

The solution is to read the manual. Diskdoctor will not fix anything on your drive - this will b too dangerous. It will copy and salvage files to another drive.

[Thomas Richter]

Originally Posted by Malakie

Uh no.. I worked for Commodore Amiga and am playing catch up with the new hardware and OS's just getting back into the scene.

Sorry, but Thomas is right. The 3.2 FFS is not substantial different from the 2.04 FFS. What happens however quite regularly with aging hardware are problems on data transfer to and from RAM, in particular with A2000 boards and Zorro-based RAM expansions. Depending on the board revision, Zorro II transfers are flaky, and aging components do not improve the situation.

Note that your average RAM test does not test very much, and particular failure patterns will not be detected - many tests are not very sophisticated. Just because it used to work with 2.04 several years ago does not mean that it will work now.

[Malakie]

Originally Posted by Thomas Richter

Sorry, but Thomas is right. The 3.2 FFS is not substantial different from the 2.04 FFS. What happens however quite regularly with aging hardware are problems on data transfer to and from RAM, in particular with A2000 boards and Zorro-based RAM expansions. Depending on the board revision, Zorro II transfers are flaky, and aging components do not improve the situation.

Note that your average RAM test does not test very much, and particular failure patterns will not be detected - many tests are not very sophisticated. Just because it used to work with 2.04 several years ago does not mean that it will work now.

The ram is fine. The problem is the either the 7.0 roms on the A2091 or the 3.2 kickstart scsi.device changes.

3.2 had more changes than I think you realize over 2.04.

If I remove all ram except what is on the main board and use my old test stuff I still have, the mainboard ram tests just fine. If your system is "flaky" moving data to ram, you have some other problems happening not related to this. I have more than one Amiga here that I have now restored. This unit happens to be 3.2 based.

I am asking questions here because 3.2 was not around when I was still with Commodore and as I said I am playing catchup. I am trying to get ideas and opinions on what people have found with 3.2 because I am running into a buttload of SCSI problems.

If I run IDE only, everything works perfectly including large HD sizes. But once I got to SCSI only, things then start falling apart no matter what I use, 270 meg drive or 4 gb drive, CF cards or anything CD rom drives.

Someone else in another post mirrored what I think is going on.. I think there is still a major bug in the 7.0 roms and/or the 3.2 Kickstart in relation to the SCSI.DEVICE.

I am probably going to switch this machine to IDE and the next machine, which will be 3.5 or 3.9, I will try again.

Since 3.2 is not supported at all and I doubt anyone is going to take the time to pull the code from both the 7.0 roms and kickstart 3.2 rom and look through it line by line, I am not going to waste any additional time trying to resolve it.

My ultimate goal was to have one machine for each and every OS running default. I will have to alter that for a 3.2 system now.

[Malakie]

Originally Posted by Thomas Richter

Sorry, but Thomas is right. The 3.2 FFS is not substantial different from the 2.04 FFS. What happens however quite regularly with aging hardware are problems on data transfer to and from RAM, in particular with A2000 boards and Zorro-based RAM expansions. Depending on the board revision, Zorro II transfers are flaky, and aging components do not improve the situation.

Note that your average RAM test does not test very much, and particular failure patterns will not be detected - many tests are not very sophisticated. Just because it used to work with 2.04 several years ago does not mean that it will work now.

FFS is not the problem in this one, it has to be tied to SCSI.device.

[Malakie]

Originally Posted by Thomas Richter

The solution is to read the manual. Diskdoctor will not fix anything on your drive - this will b too dangerous. It will copy and salvage files to another drive.

Someone else let me know that the diskdoctor in 3.2 works differently. And I did what I was able to find but what I had found and read did not clarify that.

Someone else linked me to a good source.

BTW, there was nothing wrong with the old diskdoctor. 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.

[indigolemon]

Originally Posted by Malakie

Since 3.2 is not supported at all ...

Actually, it's the only version still in support (and still on sale). But then you'll know that because you bought it right?

PS - I've never worked for Commodore btw. Just thought I'd get that in there in case it was relevant.

[Malakie]

Originally Posted by indigolemon

Actually, it's the only version still in support (and still on sale). But then you'll know that because you bought it right?

PS - I've never worked for Commodore btw. Just thought I'd get that in there in case it was relevant.

Yea everything I am getting I buy. But so far the OS 3.2 has not impressed me at all when it comes to large disk support.

[Thomas Richter]

Originally Posted by Malakie

BTW, there was nothing wrong with the old diskdoctor.

There is a lot wrong with the old diskdoctor. The most elementary things, even. Just to name one, it only checks the root directory, but nothing in subdirectories. In practice, it does more harm to disks than it helped. The diskdoctor was "designed" back then for 880K floppies, flat disk hierarchy (as in "none at all").

[Thomas Richter]

Originally Posted by Malakie

The ram is fine. The problem is the either the 7.0 roms on the A2091 or the 3.2 kickstart scsi.device changes.

The A2091 is not driven by the scsi.device in the kickstart. It has its own device driver in its autoconfig boot ROM. Thus, it is certainly not 3.2 that is causing your problem.

Originally Posted by Malakie

3.2 had more changes than I think you realize over 2.04.

I beg your pardon, but I don 't need to "realize" something. I was one of the persons that actually worked on 3.2. So yes, I do know the code, and I do know what changed.

Originally Posted by Malakie

I am asking questions here because 3.2 was not around when I was still with Commodore and as I said I am playing catchup. I am trying to get ideas and opinions on what people have found with 3.2 because I am running into a buttload of SCSI problems.

The first thing to test if you have SCSI problems is termination of the SCSI bus. But again, the 2091 does DMA, and it does so over a Zorro bus, and the latter is a known source of issues. So, what's your board revision (of the mother board).

Originally Posted by Malakie

If I run IDE only, everything works perfectly including large HD sizes. But once I got to SCSI only, things then start falling apart no matter what I use, 270 meg drive or 4 gb drive, CF cards or anything CD rom drives.

Bad termination, problems on the SCSI bus, and DMA problems. IDE is "PIO only", the CPU does everything, and that is the easy part. Despite its name, the "scsi device" in Kickstart does IDE, except for the version for the A3000 and A4000T (and there only the "NCR scsi.device"), but the 2091 does not do IDE as far as I know, so something is not quite consistent with what you say.

Originally Posted by Malakie

Someone else in another post mirrored what I think is going on.. I think there is still a major bug in the 7.0 roms and/or the 3.2 Kickstart in relation to the SCSI.DEVICE.

Which board, which system? Again, the scsi.device does *not* do scsi for most of us (exception is the A3000, as said), and the 2091 does not use the scsi.device from 3.2. It cannot.

Originally Posted by Malakie

Since 3.2 is not supported at all and I doubt anyone is going to take the time to pull the code from both the 7.0 roms and kickstart 3.2 rom and look through it line by line, I am not going to waste any additional time trying to resolve it.

Since when is 3.2 "not supported"?

[Malakie]

Originally Posted by Thomas Richter

There is a lot wrong with the old diskdoctor. The most elementary things, even. Just to name one, it only checks the root directory, but nothing in subdirectories. In practice, it does more harm to disks than it helped. The diskdoctor was "designed" back then for 880K floppies, flat disk hierarchy (as in "none at all").

I said, "used as intended". It was not designed to fix "all" errors on a disk. It was designed to repair validation errors and directory structure errors.

[Malakie]

Originally Posted by Thomas Richter

The A2091 is not driven by the scsi.device in the kickstart. It has its own device driver in its autoconfig boot ROM. Thus, it is certainly not 3.2 that is causing your problem.

I beg your pardon, but I don 't need to "realize" something. I was one of the persons that actually worked on 3.2. So yes, I do know the code, and I do know what changed.

The first thing to test if you have SCSI problems is termination of the SCSI bus. But again, the 2091 does DMA, and it does so over a Zorro bus, and the latter is a known source of issues. So, what's your board revision (of the mother board).

Bad termination, problems on the SCSI bus, and DMA problems. IDE is "PIO only", the CPU does everything, and that is the easy part. Despite its name, the "scsi device" in Kickstart does IDE, except for the version for the A3000 and A4000T (and there only the "NCR scsi.device"), but the 2091 does not do IDE as far as I know, so something is not quite consistent with what you say.

Which board, which system? Again, the scsi.device does *not* do scsi for most of us (exception is the A3000, as said), and the 2091 does not use the scsi.device from 3.2. It cannot.

Since when is 3.2 "not supported"?

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.

[Rotareneg]

Originally Posted by Malakie

my understanding was 3.5/3.9 and the 4.x versions were now the primary focus.

3.5 and 3.9 are from 1999 and 2000 and are only for 68020 or better systems. AmigaOS 4 is PowerPC only and first came out in 2004 with the last major update (4.1 Final Edition) in 2014 with three smaller updates since then. 3.1.4 and 3.2 (from 2018 and 2021) are the newest AmigaOS versions that'll work with even an 68000.

[Malakie]

Originally Posted by Rotareneg

3.5 and 3.9 are from 1999 and 2000 and are only for 68020 or better systems. AmigaOS 4 is PowerPC only and first came out in 2004 with the last major update (4.1 Final Edition) in 2014 with three smaller updates since then. 3.1.4 and 3.2 (from 2018 and 2021) are the newest AmigaOS versions that'll work with even an 68000.

Ahh thanks for the info. So 3.5 I need to use only in a 020 or higher system then.. Good to know. Is there a list of the difference between 3.1.4 and 3.2? I wonder if reverting back would help in this situation?

And I have an A1200 with a blizzard PPC which I understand I can use 4.1? Is that correct.