Welcome, Guest. Please login or register.

Author Topic: The Os 3.1.4 Thread  (Read 239043 times)

Description:

0 Members and 1 Guest are viewing this topic.

Offline my_pc_is_amiga

Re: The Os 3.1.4 Thread
« Reply #614 from previous page: August 18, 2019, 08:29:09 PM »
If you see a stack warning from PC0:, then you are not using the crossdosfilesystem from 3.1.4. (or 3.1.4.1) because this has an automatic stack extension to at least 2K. You can always check the mounts by downloading "Devices" from Aminet and then running "Devices PC0:" on the shell.

It looks like I'm running 45.36 according to "version l:crossdosfilesystem"   It looks like the "StackSize" mount option overrides the automatic extension...when mount it with StackSize=600 (Mount file default), I get this. 

Code: [Select]
DeviceName : PC0
Type       : Device
Task       : 79A0190 PC0
Handler    : L:CrossDOSFileSystem
Stacksize  : 600 BYTEs
Priority   : 10
Segment    : 0x1E68213
FirstHunk  : 0x79A0850
GlobalVec  : do not create GlobVec
Startup    : 0x799FC3C
ExecDevice       : mfm.device
Unit             : 0
Flags            : 0x1
Environment      :
TableSize        : 0x13
BytesPerSector   : 512
FirstLong        : 0
Surfaces         : 2
SectorsPerBlock  : 1
SectorsPerTrack  : 9
Reserved         : 1
PreAlloc         : 0
Interleave       : 0
Direct SCSI      : no
Superfloppy      : no
Disable NSD      : no
LowCyl           : 0
HighCyl          : 79
Buffers          : 5
BufMemType       : 0x1
MaxTransfer      : 0x7FFFFFFF
Mask             : 0xFFFFFFFE
BootPri          : 0
DosType          : MSD0x0
Baud             : 1200
Control          : 0x0
Bootblocks       : 0


When I mount it while removing the StackSize option altogether, I get 2400 bytes stack size.
 

Offline my_pc_is_amiga

Re: The Os 3.1.4 Thread
« Reply #615 on: August 18, 2019, 09:05:41 PM »
Not reproducable here. Note that the RAM: task is only detecting the problem, not necessarily causing it. Are you using the original RAM: disk, or some replacement? Also, what was the size of the file you had copied (how) and how did you delete it?

From the pattern observed in the rear mungwall, only a single bit was changed from 1 to 0. This looks more like an indication of bad RAM and a hardware problem.

I'm using the original RAM: disk.   I was copying entire directory and so not sure exactly file size to when I saw errors.  When I got to RAM: disk full, I did a cancel and then did a workbench delete.   
 

guest11527

  • Guest
Re: The Os 3.1.4 Thread
« Reply #616 on: August 18, 2019, 09:09:22 PM »

It looks like I'm running 45.36 according to "version l:crossdosfilesystem"   It looks like the "StackSize" mount option overrides the automatic extension...when mount it with StackSize=600 (Mount file default), I get this. 
This extension cannot be overridden, I checked. I can only assume that the initial memory allocation of CrossDos allows MuGa to pick this up. One way or another, the stack is extended later on, so this is not a problem.
 
The following users thanked this post: my_pc_is_amiga

guest11527

  • Guest
Re: The Os 3.1.4 Thread
« Reply #617 on: August 18, 2019, 09:10:17 PM »
I'm using the original RAM: disk.   I was copying entire directory and so not sure exactly file size to when I saw errors.  When I got to RAM: disk full, I did a cancel and then did a workbench delete.
The error pattern - namely individual bits in wrong position in the MuGa fence - is a strong indicator that this is some form of hardware problem.
 

Offline trekiej

Re: The Os 3.1.4 Thread
« Reply #618 on: August 18, 2019, 09:12:12 PM »
Does 3.1.4 do anything in particular for an A2000?
Amiga 2000 Forever :)
Welcome to the Planar System.
 

guest11527

  • Guest
Re: The Os 3.1.4 Thread
« Reply #619 on: August 18, 2019, 09:26:54 PM »
Does 3.1.4 do anything in particular for an A2000?
What do you mean "in particular"? There is no "particular" A2000 ROM, just one common for the A500,A600 and A2000 (i.e. ECS machines).
 

Offline my_pc_is_amiga

Re: The Os 3.1.4 Thread
« Reply #620 on: August 18, 2019, 09:51:51 PM »
I've noticed that if I do a "remove object" from the requester after the RAM: disk is full, the #?.info drawer that was  created in RAM: does not get deleted.  The dir. gets deleted but not the #?.info.   This is when I drag an entire disk into the RAM: window and the directory get's created.
 

Offline my_pc_is_amiga

Re: The Os 3.1.4 Thread
« Reply #621 on: August 18, 2019, 09:57:27 PM »
I'm using the original RAM: disk.   I was copying entire directory and so not sure exactly file size to when I saw errors.  When I got to RAM: disk full, I did a cancel and then did a workbench delete.
The error pattern - namely individual bits in wrong position in the MuGa fence - is a strong indicator that this is some form of hardware problem.

I turned off the SimpleSCSI flag in Trident and seems to be working okay now.  But I'm crossing my fingers -- need to check more (hopefully it is not some heated related thing and I was lucky not to hit issue).   But I turned SimpleSCSI back on and then started to see hits.   I also did a copy from my SCSI hard disk to RAM: and didn't see any hits.
 

Offline my_pc_is_amiga

Re: The Os 3.1.4 Thread
« Reply #622 on: August 18, 2019, 10:02:07 PM »
No. There was some other reason why we had the screen not larger than the image. I believe this was due to the CDXL datatype which required this. So at this point, there is no fix. What multiview could do is use a smaller font, but that does not need to work either if the screen is just too small. Use the shortcuts from the menu.

For the about requester and the ASL requester, maybe a suggestion would be to pop up on workbench if not able to open on its own pubscreen.   If in full screen mode there is no shortcut to go back to window mode -- and so only option as of now would be to quit program with Amiga-Q.
 

Offline TribbleSmasher

Re: The Os 3.1.4 Thread
« Reply #623 on: August 18, 2019, 10:04:16 PM »
Does 3.1.4 do anything in particular for an A2000?

Please note that the new 3.1.4 requires a little more resources than the older 3.1 due to recent improvements. So with an unexpanded A2000 it is not that good choice.
 

guest11527

  • Guest
Re: The Os 3.1.4 Thread
« Reply #624 on: August 18, 2019, 11:06:06 PM »
I've noticed that if I do a "remove object" from the requester after the RAM: disk is full, the #?.info drawer that was  created in RAM: does not get deleted.  The dir. gets deleted but not the #?.info.   This is when I drag an entire disk into the RAM: window and the directory get's created.
Not reproducable here. If you drag an entire disk onto RAM:, diskcopy will complain that the object is of wrong type and cannot be copied (which is true, RAM: is a handler without underlying device). If you drag the contents of a volume onto a disk, everything can be removed again. If you drag contents onto RAM: and RAM: gets full, you can either answer to remove the incomplete object, which it always does completely, or leave the incomplete object on disk. In this case, you may end up with a .info without a corresponding file or directory, but in any case, they could be deleted fine.
 

guest11527

  • Guest
Re: The Os 3.1.4 Thread
« Reply #625 on: August 18, 2019, 11:08:17 PM »
I turned off the SimpleSCSI flag in Trident and seems to be working okay now.  But I'm crossing my fingers -- need to check more (hopefully it is not some heated related thing and I was lucky not to hit issue).   But I turned SimpleSCSI back on and then started to see hits.   I also did a copy from my SCSI hard disk to RAM: and didn't see any hits.
SimpleSCSI? I'm not aware of this flag, what is it supposed to do? One way or another, if you see bitflips like this, something is wrong. Before you seem to believe that everything is right, give the system some time to warm up and then try again. Such bus errors do not get away easily - they indicate a hardware problem that is in general not solvable by software.
 

Offline my_pc_is_amiga

Re: The Os 3.1.4 Thread
« Reply #626 on: August 19, 2019, 05:53:57 AM »
Not reproducable here. If you drag an entire disk onto RAM:, diskcopy will complain that the object is of wrong type and cannot be copied (which is true, RAM: is a handler without underlying device). If you drag the contents of a volume onto a disk, everything can be removed again. If you drag contents onto RAM: and RAM: gets full, you can either answer to remove the incomplete object, which it always does completely, or leave the incomplete object on disk. In this case, you may end up with a .info without a corresponding file or directory, but in any case, they could be deleted fine.

To clarify, I am opening up the RAM: disk to show its window on workbench.  I then drag a disk icon into the window of the RAM: disk and do the copy (this is not a diskcopy).  As you mentioned there are 2 ways to delete files in workbench after I get the "disk is full" prompt:

1) Cancel the operation and say no to "remove incomplete object"  Then use the menu item to delete entire directory by selecting it within the RAM: window.  This one deletes the directory and the *.info file.
2) Cancel the operation and say yes to "remove incomplete object"   In this situation, the *.info file is left in the RAM: disk.  Not a big deal as I can delete the *info if need to manually. 
 

Offline my_pc_is_amiga

Re: The Os 3.1.4 Thread
« Reply #627 on: August 19, 2019, 06:03:42 AM »
SimpleSCSI? I'm not aware of this flag, what is it supposed to do? One way or another, if you see bitflips like this, something is wrong. Before you seem to believe that everything is right, give the system some time to warm up and then try again. Such bus errors do not get away easily - they indicate a hardware problem that is in general not solvable by software.

The only description I have is this from the manual:

"- Simple SCSI:
  Filter out or emulate most SCSI commands that are not used by Windows and
  hence, a lot of devices will drop dead on these (or just return junk). It
  will also intercept  all  calls  to  MODE_SENSE  and  returns  faked  but
  accurate geometry data."

I had this option enabled for the massstorage.class and now I have it disabled.
 

Offline my_pc_is_amiga

Re: The Os 3.1.4 Thread
« Reply #628 on: August 19, 2019, 06:13:43 AM »
This extension cannot be overridden, I checked. I can only assume that the initial memory allocation of CrossDos allows MuGa to pick this up. One way or another, the stack is extended later on, so this is not a problem.


Thanks -- I had a MuGa enabled as I was using trackdisk.device (stack issue) and CMD (Mung-wall damaged) -- not sure the sequence of events for these but thought in case it is any use, I'm attaching them.
 

guest11527

  • Guest
Re: The Os 3.1.4 Thread
« Reply #629 on: August 19, 2019, 12:58:11 PM »
Thanks -- I had a MuGa enabled as I was using trackdisk.device (stack issue) and CMD (Mung-wall damaged) -- not sure the sequence of events for these but thought in case it is any use, I'm attaching them.
trackdisk wasn't changed for 3.1.4, and as far as CMD is concerned, I cannot reproduce this here. The hit comes from a call into AllocEntry()/FreeEntry(), and neither of the two are called by CMD itself. The dos.library calls them when initializing a new process, but the size of the allocation does not fit the size the dos.library uses. So this comes from somewhere else. If you run MuGA, please try to reproduce the CMD issue, but for MuGA, add to the command line "STACKCHECK STACKLINES=32" to get a larger stack dump.