Amiga.org
Amiga computer related discussion => Amiga Software Issues and Discussion => Topic started by: Michele31415 on October 07, 2021, 05:47:45 PM
-
I'm now (finally) running OS 3.9 on my 2000 thanks to the help I've gotten here, so now I wanted to get my DKB 2632 activated. It is maxed out with 112 MB of RAM and used to work fine with OS 3.2. But now I find that when I give the "2632" command, I get a pop-up error "FS3 has a read error on disk block 10nnnnn" (the last five digits vary). FS3 is my SCSI2SD boot drive. But even worse is that once I dismiss that message, I can't run any other DOS commands - dir, list, avail, time, etc. all bring up the same pop-up. All I can do is a cold reboot - a warm boot just produces the animated "insert a floppy disk" screen. I don't get any disk errors on any commands before giving the "2632" command.
Other difference: before I was using an A2091 SCSI controller and now I have a GVP 2000 HC+8 with 4 MB of RAM on it.
FWIW, this is what I get before giving the 2632 command:
> avail
Type Available In-Use Maximum Largest
chip 1706368 374400 2080768 1584424
fast 4973696 3414912 8388608 4968368
total 6680064 3789312 10469376 4968368
Then when I say
> 2632 -d
2632 Resident Module
Getting banksize
Banksize= 02000000
Priority= 5
Base = 04000000 Size = 04000000
Base = 01000000 Size = 01000000
2632 ResMod: Size 01BC, From 005229F0, To 00036770, Offset FFB13D80
2632 Resident Module relocation complete
2632 Resident Module Added
2632 memory configured
As a test, I booted from a 3.1 floppy and gave the 2632 command there. It worked fine, avail reports the extra 112M of RAM, and all the DOS commands still work.
Is there some trick to getting the 2632 working in OS 3.9? (Or is this even possible).
-
I guess your issue is not the DKB but the HC+8. And it has nothing to do with OS 3.9.
The SCSI controller does DMA into FastRAM. As soon as you add the 2632's memory, it uses that for buffers. But a Zorro card can only do DMA into Zorro memory. When it tries to do DMA into the 2632's memory, it fails.
You say when you enter the 2632 command from a floppy, it works. But does it still allow to access the FS3 partition after you entered the command? Probably not.
I guess you can tweak the FS3 partition with special values for Mask and BufMemType. However, there is no public tool to edit BufMemType AFAIK.
-
I guess your issue is not the DKB but the HC+8. And it has nothing to do with OS 3.9.
The SCSI controller does DMA into FastRAM. As soon as you add the 2632's memory, it uses that for buffers. But a Zorro card can only do DMA into Zorro memory. When it tries to do DMA into the 2632's memory, it fails.
You say when you enter the 2632 command from a floppy, it works. But does it still allow to access the FS3 partition after you entered the command? Probably not.
No, if I boot the 3.1 floppy and run the 2632 command from there, the extra 112M of memory gets added and I can still access FS3: (dir, read, write, etc.) from a 3.1 shell.
So far I've tried adding the 2632 command into my FS3 startup-sequence right after IPrefs which is where it is in the example startup-sequence provided in the 2632 documentation but that doesn't help. The command returns but then every command following it gives an error 42.
My next test was to boot from the 3.9 Emergency floppy. I gave the 2632 command form there and it worked. The extra RAM showed up, I could still use all the DOS commands, and I could access FS3:. The only difference I can think of is that FS3: has BoingBags 1 and 2 applied but the Emergency floppy does not. Is there some way to undo BB2?
UPDATE:
I did some more searching and discovered this post: https://forum.amiga.org/index.php?topic=62988.msg712034#msg712034 by me in fact, nine years ago. I had completely forgotten about this. Apparently I had trouble with 2632 back then too. Anyway I tried one of the suggestions there
I have found that the 2632 program has a resident module which seems to be incompatible with 3.x but it only fails on reboot. Its possible (but unlikely) that this resident is not compatible with some older RTG software.
You can test this by booting with no startup-sequence via bootmenu and then run 2632 from the Shell. You could also use 2632 -r to add memory without the resident module.
If that doesn't help try 2632 -m0 which lowers the priority of 2632 memory to the same as auto-config fast memory. It won't be accessed until the auto-config fast memory is used up. This will help determine if the DKB2632 memory is failing itself.
« Last Edit: October 15, 2012, 04:32:24 PM by SpeedGeek »
I booted directly into FS3 and tried 2632 -m0 from a shell window. And it worked! The extra RAM shows up and I don't get any errors from subsequent DOS commands. So I guess this one is solved, or at least a work-around. I guess I need to try an experiment to run something that uses up all the auto-config fast RAM and then see what happens.
-
Hmm - my update to my last post doesn't seem to have taken. I did the experiment. I tried running NetSurf, which wouldn't run with the amount of RAM I had before. Then I did 2632 -m0 and tried it again. And it failed with the same FS3 device error as before. So now I need to try NetSurf after booting from the OS9 Emergency disk, which might be hard since there's no room on that disk for NetSurf. I'll have to boot form the floppy and then reassign all the directories to FS3 and then try to run NetSurf.
-
The 2632 tool's "Resident Module" code doesn't like OS3.x. It was developed for OS2.x and DKB never released an update for this.
The work around is to use 2632 -r (which skips the resident module code install).
I don't know about the filesystem and SCSI2SD issues, but they are likely unrelated to the resident module issue. ;)
-
The 2632 tool's "Resident Module" code doesn't like OS3.x. It was developed for OS2.x and DKB never released an update for this.
The work around is to use 2632 -r (which skips the resident module code install).
Seems like a reasonable idea but it didn't work. IN OS 3.9 booted from FS3 (the SCSI2SD drive), 2632-r from a shell immediately brings up the "error in block 10nnnnn" error 42 pop-up.
Booting from the 3.9 Emergency floppy and giving the 2632 -r command from a shell does work and then avail shows the extra RAM but then weird things happen. If I try to open FS3, I get a whole series of Error 42's until I end up with the FS3 window with just one icon in it. But that only happens after giving the 2632 command.
I saw a post somewhere else suggesting that the 2632 command in general was buggy, even pre OS 3.x. Perhaps the thing to do is Thomas' suggestion (if I knew how to do that):
"I guess you can tweak the FS3 partition with special values for Mask and BufMemType. However, there is no public tool to edit BufMemType AFAIK."
So maybe the boingBag updates are not to blame after all.
I don't know about the filesystem and SCSI2SD issues, but they are likely unrelated to the resident module issue. ;)
Are there any tools to help diagnose that?
-
The 2632 tool's "Resident Module" code doesn't like OS3.x. It was developed for OS2.x and DKB never released an update for this.
The work around is to use 2632 -r (which skips the resident module code install).
I don't know about the filesystem and SCSI2SD issues, but they are likely unrelated to the resident module issue. ;)
Wow, thanks for your research on this. I abandoned trying to get my 2632 to work years ago... I wonder if this was the problem?
Apparently this is one of those rare pieces of software that works on 2.x but not 3.x!
-
It seems like a shame to have to give up 112 MB of RAM just like that (though it seems funny to be saying that as I'm typing this on a Sun T4-1 with 64 GB of RAM). I'll play with it a while longer. I pulled the 2630 board and cleaned its contacts with my Mars Staedtler acid-free plastic eraser, then wiped them with DeOxit Gold. Did the same to all four SIMM's on the 2632. Then I booted a 1.3 floppy and gave the 2632 command. Worked fine. The photo shows what 2732 -d thinks. Then I ran memcheck and it instantly froze the machine - no mouse, no keyboard. I'm not sure if that means the 2632 is bad or if memcheck doesn't know what to do with it.
-
I tried a different memory tester, this one also named, confusingly enough, memcheck (actually memcheck 37.13, R 1.2). Started up the DKB with 2632 -m0 in 3.9 so I'd be able to issue further commands. And it looks like it ran through the entire 112 M and found nothing wrong. And after presumably having touched all the DKB RAM with memcheck, I was still able to issue shell commands without triggering an error 42. So I'm going to have to assume the 2632 itself is OK.
Sorry for the moire - my camera and monitor are fighting. I tried different distances and contrast levels. This was about the best I could do. I'd have redirected the output to a file but it took about two hours to run the test.
-
I tried a different memory tester, this one also named, confusingly enough, memcheck (actually memcheck 37.13, R 1.2). Started up the DKB with 2632 -m0 in 3.9 so I'd be able to issue further commands. And it looks like it ran through the entire 112 M and found nothing wrong. And after presumably having touched all the DKB RAM with memcheck, I was still able to issue shell commands without triggering an error 42. So I'm going to have to assume the 2632 itself is OK.
Sorry for the moire - my camera and monitor are fighting. I tried different distances and contrast levels. This was about the best I could do. I'd have redirected the output to a file but it took about two hours to run the test.
When doing a memory test always use CPU NODATACACHE first, otherwise you typically get mixed results (but you want all the results to be from physical memory).
I would suggest not trying to use the OS 3.9 ROM update unless you skip the exec.library and scsi.device updates. The OS 3.9 ROM update has buggy model detection code which can cause the wrong versions to be installed.
-
When doing a memory test always use CPU NODATACACHE first, otherwise you typically get mixed results (but you want all the results to be from physical memory).
OK, I ran memcheck again with that CPU command first. Exact same result - 0 errors.
I would suggest not trying to use the OS 3.9 ROM update unless you skip the exec.library and scsi.device updates. The OS 3.9 ROM update has buggy model detection code which can cause the wrong versions to be installed.
Except that I've already applied both BoingBag 1 and 2, as per someone's previous suggestion. Is there a way to undo those?
I also tried using "addmem 1000000 7000000" instead of the 2632 command. The command worked but then I got the same Error 41 when trying to give any further DOS commands. What is Error 41 anyway? I can't seem to find it anywhere.
-
Except that I've already applied both BoingBag 1 and 2, as per someone's previous suggestion. Is there a way to undo those?
You can either:
a. Go to Devs: and rename "AmigaOS-ROMUpdate" (or whatever the file is called) to, e.g., "AmigaOS-ROMUpdate.off"
b. Edit your startup-sequence. Find the line with the SetPatch command and add the argument "NOROMUPDATE"
I recommend b. Ultimately, later, you'll want to narrow down which particular module is causing problems and skip that module while keeping the other ones. That's all done with SetPatch arguments, so it's good to keep the ROMUpdate file in Devs: as-is.
-
You can either:
a. Go to Devs: and rename "AmigaOS-ROMUpdate" (or whatever the file is called) to, e.g., "AmigaOS-ROMUpdate.off"
b. Edit your startup-sequence. Find the line with the SetPatch command and add the argument "NOROMUPDATE"
I recommend b. Ultimately, later, you'll want to narrow down which particular module is causing problems and skip that module while keeping the other ones. That's all done with SetPatch arguments, so it's good to keep the ROMUpdate file in Devs: as-is.
OK, I took option b. And it certainly made a difference. First of all, I found that I no longer get those two yellow "Recoverable alert, click left to continue" boxes on booting. Then I did "2632 -m0" and it worked. The extra RAM appeared and I could still give DOS commands. Then I started trying to use it. I started up Poseidon, AmiTCP, ftp, AWebII, AmiMail, DPaintIV in high res overscan mode, a bunch of WB windows, and 15 shell windows without encountering any errors. I was using almost 10 MB by that point. However, trying to start NetSurf still gives that FS3 bad block error. On the 16th shell window, the entire system hung, but possibly because there was just too much stuff going on by then.
But at least this is progress. It looks like the BB2 ROM Update is causing problems.
-
OK, I took option b. And it certainly made a difference. First of all, I found that I no longer get those two yellow "Recoverable alert, click left to continue" boxes on booting. Then I did "2632 -m0" and it worked. The extra RAM appeared and I could still give DOS commands. Then I started trying to use it. I started up Poseidon, AmiTCP, ftp, AWebII, AmiMail, DPaintIV in high res overscan mode, a bunch of WB windows, and 15 shell windows without encountering any errors. I was using almost 10 MB by that point. However, trying to start NetSurf still gives that FS3 bad block error. On the 16th shell window, the entire system hung, but possibly because there was just too much stuff going on by then.
But at least this is progress. It looks like the BB2 ROM Update is causing problems.
Well, you still forgot about the 2632 resident module code issue. The problem occurs not when the resident module code is installed, but rather when it is executed (e.g. the next reboot). Now, what happens after you install the Amiga OS ROM update? ::)
-
Well, you still forgot about the 2632 resident module code issue. The problem occurs not when the resident module code is installed, but rather when it is executed (e.g. the next reboot). Now, what happens after you install the Amiga OS ROM update? ::)
Sorry to be so dense but are we talking about the 2632 resident module? Because AFAIK that goes away on the next reboot. The 2632 isn't autoconfig so you have to give the 2632 command on every boot.
I don't understand what you mean by "after you install the Amiga OS ROM update". Do you mean I should now remove the NOROMUPDATE option from SetPatch? I assume we'd just go back to the previous state where adding the 2632 causes all commands to fail with error 41.
-
Sorry to be so dense but are we talking about the 2632 resident module? Because AFAIK that goes away on the next reboot. The 2632 isn't autoconfig so you have to give the 2632 command on every boot.
I don't understand what you mean by "after you install the Amiga OS ROM update". Do you mean I should now remove the NOROMUPDATE option from SetPatch? I assume we'd just go back to the previous state where adding the 2632 causes all commands to fail with error 41.
Yes, we are talking about the 2632 resident module and no, it does not go away after the next reboot. You will have to power down (cold boot) to remove it.
The observed behavior with using the OS 3.9 ROM update was supposed to be an "Auto reboot". Hence, I saw no need to explain it any further. Now, there are 2 possibilities here:
1) 2362 command before Setpatch = resident module conflict with OS 3.9 ROM update auto reboot
2) 2362 command after Setpatch = resident module conflict with next user reboot
So either way you still have the problem, it just a matter of when.
-
Moving along, I replaced the BB2 AimgaOS ROM Update file (length 321768) with the original one (length 127956) and re-enabled it in startup-sequence, then cold-booted. I also discovered the magic words "newcli aux:" and connected a serial cable form the Amiga to my Sun so now it's super easy to post output here. I wanted to see what memory looked like before giving the 2632 command. Right now I have
1.FS3:> showconfig
PROCESSOR: CPU 68030/68882fpu/68030mmu
CUSTOM CHIPS: ECS NTSC Agnus (id=$0030), ECS Denise (id=$00FC)
VERS: Kickstart version 40.63, Exec version 40.10, Disk version 45.3
RAM: Node type $A, Attributes $605 (FAST), at $200000-$9FFFFF (8.0 meg)
Node type $A, Attributes $703 (CHIP), at $400-$1FFFFF (~2.0 meg)
BOARDS:
CBM A2630 68030/RAM card: Prod=514/81($202/$51) (@$200000 4meg Mem)
Board + ROM (HD?) (Great Valley Products): Prod=2017/11($7E1/$B) (@$E90000 64K)
RAM (Great Valley Products): Prod=2017/10($7E1/$A) (@$600000 4meg Mem)
Board (Individual Computers): Prod=4626/23($1212/$17) (@$EA0000 64K)
Board (unidentified): Prod=3643/18($E3B/$12) (@$EB0000 64K)
Board + ROM (HD?) (unidentified): Prod=3643/19($E3B/$13) (@$EC0000 64K)
The Prod 2017 boards are the GVP 2000.
The Prod 4626/23 board is the DKB 2632.
The Prod 3643/18 board is the x-surf.
The Prod 3643/19 is the Deneb.
I'm also not getting the two "recoverable alert" errors on booting. Then
1.FS3:> 2632 -m0
1.FS3:> showconfig
PROCESSOR: CPU 68030/68882fpu/68030mmu
CUSTOM CHIPS: ECS NTSC Agnus (id=$0030), ECS Denise (id=$00FC)
VERS: Kickstart version 40.63, Exec version 40.10, Disk version 45.3
RAM: Node type $A, Attributes $605 (FAST), at $200000-$9FFFFF (8.0 meg)
Node type $A, Attributes $5 (FAST), at $1000000-$7FFFFFF (112.0 meg)
Node type $A, Attributes $703 (CHIP), at $400-$1FFFFF (~2.0 meg)
BOARDS:
CBM A2630 68030/RAM card: Prod=514/81($202/$51) (@$200000 4meg Mem)
Board + ROM (HD?) (Great Valley Products): Prod=2017/11($7E1/$B) (@$E90000 64K)
RAM (Great Valley Products): Prod=2017/10($7E1/$A) (@$600000 4meg Mem)
Board (Individual Computers): Prod=4626/23($1212/$17) (@$EA0000 64K)
Board (unidentified): Prod=3643/18($E3B/$12) (@$EB0000 64K)
Board + ROM (HD?) (unidentified): Prod=3643/19($E3B/$13) (@$EC0000 64K)
1.FS3:> avail
Type Available In-Use Maximum Largest
chip 1492352 603776 2096128 1441184
fast 121851352 3977768 125829120 117440480
total 123343704 4581544 127925248 117440480
So it looks like the 2632 RAM got added in the right place (1000000 - 7000000). Or am I reading this wrong?
In any event I then started Poseidon, AmiTCP, AWeb 3.5, DPaintIV, two instances of Cygnus Ed, memacs, Excellence!, AmigaMail, and calculator. They're all working, all the DOS commnads are working, I'm not getting any Error 41's and now I have:
1.FS3:> avail
Type Available In-Use Maximum Largest
chip 342784 1753344 2096128 273728
fast 67427184 58401936 125829120 67108832
total 67769968 60155280 127925248 67108832
We're now well into using the 2632 RAM and things seem stable enough. So perhaps the 2632 can be used with OS 3.9 after all. Unless there's some important reason not to, I'm just going to continue using the original AmigaOS ROM Update file from the 3.9 CD instead of the one from BB-2. How say ye, oh great Gods of Amiga?
-
Well it looks like I spoke too soon. The 2632 is back to causing Error 41's (whatever that is) on random files that work perfectly before either 2632 or addmem are invoked. I've tried every combination of switches, tried booting different OS's, nothing helps. So I've had it. Adios, 2632. I'm now considering getting a BigRAM 2630 Standard (http://wiki.icomp.de/wiki/BigRAM2630), My 2630 is a rev. 9 so this should work. I think. I hope.
-
Error 41's (whatever that is)
41 means DMA error.
http://amigadev.elowar.com/read/ADCD_2.1/Includes_and_Autodocs_2._guide/node0043.html
This is well understandable if the HC-8+ tries to do DMA into the DKB's memory, which is not possible.
-
Oh! So would a different SCSI controller help? Or wou;ld I encounter the same problem if I tried the BigRAM? So how does the 2632 ever work? Is it limited to PIO SCSI controllers?
I see in the 2632 manual it says:
The 32Bit memory that is installed on the 2632 is configured in 32Bit
address space and considered Extended memory. This is placed above the
Amiga's normal Zorro II Auto-config space which only allows a maximum of 8
Megabytes of 16Bit fast ram expansion. With the Ram on the 2632 placed in
32Bit address space you will still be able to use the CBM bridgecards as long as
you do not have more than 6 Megabytes of 16Bit Zorro II expansion memory.
The main hardware difference between the Zorro II auto-config Ram and
the 2632 Extended Ram is that any DMA Peripherals such as SCSI controllers
that are plugged into the Zorro II expansion bus (any one of the five 100 pin
expansion connectors on the A2000 motherboard) cannot directly DMA to or
from Extended Ram. This memory is outside the 8 megabytes of address space
that is defined by the Zorro II bus specifications. The software drivers for these
type of peripherals must be able to recognize the 32Bit Ram installed in the
system in order to mask out these addresses, so that they will not try to DMA to
or from this Ram.
So does this mean I need an updated gvpscsi.device? And what is this mask of which they speak?
-
You might remember that I told you about this problem already in my very first reply: https://forum.amiga.org/index.php?topic=75365.msg853537#msg853537
In the meantime I change one of my programs to support BufMemType. It's attached to this post. Copy that lha file to your Amiga and unpack it somewhere where it can be found by the CLI, for example to the C directory of your boot partition. (remove the .zip extension, it was only added because the forum software does not allow .lha files)
It's a command line program. It takes the partition to act on and the parameters which shall be changed as argutments. If no parameters are given it just outputs the current values.
So open an Shell window and enter
changebootpri fs3:
Check the values for Mask and BufMemType.
Now enter
changebootpri fs3: mask ffffff bufmemtype 200
Repeat that step for all partitions on the HC+8.
Now reboot. It's probably a bit slower than before, because it has to copy buffers forth and back. But it should no longer throw DMA errors.
-
You might remember that I told you about this problem already in my very first reply: https://forum.amiga.org/index.php?topic=75365.msg853537#msg853537
Ah yes, quite right - I guess I did not appreciate the significance of that at the time. Sorry about that.
changebootpri fs3: mask ffffff bufmemtype 200
Repeat that step for all partitions on the HC+8.
Now reboot. It's probably a bit slower than before, because it has to copy buffers forth and back. But it should no longer throw DMA errors.
Uh - now it throws that error immediately during boot. I canceled it four times and then got an empty WB screen. I rebooted, got the same error, canceled it four times again but then this time if continued booting to my normal Spectrum display with the usual icons. But if I do ordinary things like opening the FS3: icon, the error pops up three times. If I cancel it each time though, it eventually continues, I was able to say "2632 -m0" and then start Genesis and AWeb 3.5. Genesis started OK but AWeb threw two of those errors, but then continued after I canceled them.
So this is different anyway. Before, I wasn't able to continue at all after getting one of those errors after starting 2632. Now I can, but I can't really use the system this way. I used your value for mask = FFFFFF (that's six F's).
UPDATE
Now this is very odd. I let the machine sit idle for about an hour. When I returned, I tried a bunch of different programs - and they all worked. In another hour of playing around I ran just about everything on the disk and they all worked fine. I'm not getting that "FS3 has a read error" at all anymore. I'm wondering if this could be a heat issue somewhere.
-
It's rather a cold issue than a heat issue :P
Next time you get a read error please use Retry first and check if you get exactly the same error again or if the block number changes.
If you get a read error at first but on retry can read the block and fail on another one which also is successful on retry and so on, then it's probably a hardware error. Maybe a loose contect on the cable or bad termination.
Although I would have expected that the mask / bufmemtype changes would not show any difference without the DKB memory. Those changes just tell the system that if a buffer is not in 24bit memory then allocate a new buffer in that memory and copy the data across. If there is no other memory than the 24bit memory on the HC+8, there should not be any difference whether these settings are active or not.
-
It's rather a cold issue than a heat issue :P
Next time you get a read error please use Retry first and check if you get exactly the same error again or if the block number changes.
If you get a read error at first but on retry can read the block and fail on another one which also is successful on retry and so on, then it's probably a hardware error. Maybe a loose contect on the cable or bad termination.
No, I did multiple retries on each error and they all came back with the same error on the same block.
Although I would have expected that the mask / bufmemtype changes would not show any difference without the DKB memory. Those changes just tell the system that if a buffer is not in 24bit memory then allocate a new buffer in that memory and copy the data across. If there is no other memory than the 24bit memory on the HC+8, there should not be any difference whether these settings are active or not.
There's 2 MB on the HC+8, 4 MB on the 2630, and 2 MB on the Spectrum. I got the same pattern today on a cold boot. Four errors very early in the boot process, three more bringing up my initial WB screen, and then thre more when opening the DF3: icon, all with different block numbers. I just cancel them all and then after that I can run "2632" from a shell and everything works normally. I get no further errors, even when running a variety of large programs. It's puzzling. I don't have 2632 anywhere in my startup-sequence or user-startup.