DKB 2632 won't start in OS 3.9

[Michele31415]

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).

[Thomas]

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.

[Michele31415]

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.

[Michele31415]

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.

[SpeedGeek]

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.     

[Michele31415]

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?

[Matt_H]

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!

[Michele31415]

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.

[Michele31415]

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.

[SpeedGeek]

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.
       

[Michele31415]

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.

[Matt_H]

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.

[Michele31415]

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.

[SpeedGeek]

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?     

[Michele31415]

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.