AmigaOS 3.2 released!

[mfilos]

Originally Posted by Olaf Barthel

Which version of the scsi.device are you using, specifically? I expect it will be part of the AmigaOS 3.2 ROM, but you never know until you've checked.

Yes I'm using the OS3.2 ROM scsi.device

Originally Posted by Olaf Barthel

Which mode of operations are you using PFS3 with? Direct SCSI mode

Using PDS\3 (identifier 0x50445303) with the Direct SCSI flag enabled as well on HDToolbox (I guess it doesn't matter anyway), Max Transfer of 0x1FE00 and Block size of 512.

Originally Posted by Olaf Barthel

Careful, please. You do have a backup of your data, don't you?

I have backups everywhere (I already stated in my post that I after the validation errors, I booted from another partioned, reformatted and recopied everything back.

The thing though is:
- I have issues with FFS despite wanting to go with it as part of the new OS3.2 system (validation errors probably due to the fact of deleting Hard Links).
- SFS is not advised by ThoR (saw a post from an older thread - as it's old not supported product with some issues)
- PFS3 is fast and stable and but doesn't support 4kb block size (which kinda sux for large volumes but it is what it is) and it has that kinda annoying delay.

I dont' see much options concerning my setup... and when I have issues but no answers, I have to go with whatever I have...
If I can help in any way, troubleshooting anything (as I always do) I'm all ears

[Thomas Richter]

I haven't seen much issues using hard links as I'm also using them - but as always, any instruction as how to reproduce it would certainly be appreciated.

[mfilos]

Originally Posted by Thomas Richter

I haven't seen much issues using hard links as I'm also using them - but as always, any instruction as how to reproduce it would certainly be appreciated.

Certainly Thomas.

So in startup:
- I delete ENVARC:Sys/ScreenMode.prefs and then
- based on detection of WinUAE, WinUAE with RTG, my Vampire V2, my Vampire V4SA or plain Amiga I'm hardlinking the actual saved file into ENVARC:Sys/ScreenMode.prefs
- The same happens for DEVS:Picasso96Settings file (where I have multiple saved configs)

Other files I have hardlinked (that never produced a problem as they don't interact in startup) are:
ENVARC:MagicMenu.prefs
ENVARC:TitleShadow.prefs
ENVARC:Sys/Font.prefs
ENVARC:Sys/FullPalette.prefs
ENVARC:Sys/GUI.prefs
ENVARC:Sys/WBPattern.prefs
...which are all part of my Theme application scripts.

I can share files or evern hdf file if needed.

The patches I use are:
- StackAttack2 (not needed but many apps request bigger stack and I have to add it manually)
- SaferPatches
- PoolMem
- CopyMem080 (from Apollo Team) or CopyMemAIO (on non Vampire)
- MCP with minimum patches enabled (but can analyze if needed)
- MemTrailer

For Visuals I use:
- TitleShadow
- VisualPrefs
- Birdie
- MagicMenu (ye I know you don't like it)
- ReqAttack
- SwazInfo (ye I know we have RAWBInfo but still prefer it due to some reasons)
- ToolsDaemon (will replace in the future with MenuTools)
- WBDock2

[Olaf Barthel]

Originally Posted by mfilos

Yes I'm using the OS3.2 ROM scsi.device


Using PDS\3 (identifier 0x50445303) with the Direct SCSI flag enabled as well on HDToolbox (I guess it doesn't matter anyway), Max Transfer of 0x1FE00 and Block size of 512.

Just to be sure, what does the "MountInfo" command tell you, which ships with AmigaOS 3.2 and beyond, e.g. "mountinfo dh0: debug" (with dh0: being the file system device name)?

I have backups everywhere (I already stated in my post that I after the validation errors, I booted from another partioned, reformatted and recopied everything back.

The thing though is:
- I have issues with FFS despite wanting to go with it as part of the new OS3.2 system (validation errors probably due to the fact of deleting Hard Links).

I for one would be surprised if there were issues with hard links. Deleting a hard link, however, is one of the more involved operations to begin with and there is no comparable procedure in the FFS design.

Basically, if you delete a hard link, the file system has to make sure that any remaining hard links referencing the same "real" file/directory will be consistent. If your volume's metadata blocks are corrupted for one reason or another, this could shake the tree and something might drop out

- SFS is not advised by ThoR (saw a post from an older thread - as it's old not supported product with some issues)
- PFS3 is fast and stable and but doesn't support 4kb block size (which kinda sux for large volumes but it is what it is) and it has that kinda annoying delay.

4K block support at this level may need further work in the direct SCSI layer, using the more modern SCSI commands (as in: not yet available in 1993/1994) which enable the detection and the use of the device's preferred sector sizes. Because this also depends upon the SCSI command emulation within the IDE/ATA scsi.device to be supported, it may be a tall order to get all the necessary pieces into place.

512 byte blocks might just be the sweet (and sour) spot for now...

[tomcat666]

Originally Posted by mfilos

based on detection of WinUAE, WinUAE with RTG

How does one detect winuae and winuae with RTG ?

[mfilos]

Originally Posted by tomcat666

How does one detect winuae and winuae with RTG ?

I guess there are other ways to do so, but I use Showboards command which is part of BoardsLib (you can get on Aminet).

To detect WinUAE you just detect "UAE - Magic Device Emulation" with ID 82

C:ShowBoards MID=2011 PID=82 >NIL
If NOT WARN
 <commands as WinUAE detected>
Else
 <commands as WinUAE NOT detected>
EndIf

To detect WinUAE you just detect "UAE - RTG Graphics Expansion" with ID 96

C:ShowBoards MID=2011 PID=96 >NIL
If NOT WARN
 <commands as WinUAE RTG detected>
Else
 <commands as WinUAE NOT RTG detected>
EndIf

[tomcat666]

Originally Posted by mfilos

I guess there are other ways to do so, but I use Showboards command which is part of BoardsLib (you can get on Aminet).

To detect WinUAE you just detect "UAE - Magic Device Emulation" with ID 82

C:ShowBoards MID=2011 PID=82 >NIL
If NOT WARN
 <commands as WinUAE detected>
Else
 <commands as WinUAE NOT detected>
EndIf

To detect WinUAE you just detect "UAE - RTG Graphics Expansion" with ID 96

C:ShowBoards MID=2011 PID=96 >NIL
If NOT WARN
 <commands as WinUAE RTG detected>
Else
 <commands as WinUAE NOT RTG detected>
EndIf

Thank you! Most usefull

[mfilos]

Originally Posted by Olaf Barthel

Just to be sure, what does the "MountInfo" command tell you, which ships with AmigaOS 3.2 and beyond, e.g. "mountinfo dh0: debug" (with dh0: being the file system device name)?

There you go. I mounted the CF to WinUAE, but I can send the same info from my Vampire as well

7.System:> MountInfo DH0: debug
dol_Type = DLT_DEVICE
dol_Task = 0x400026EC
dol_Lock = NULL
dol_Handler = NULL
dol_StackSize = 2048
dol_Priority = 10
fssm_Device = "uaehf.device"
fssm_Unit = 1
fssm_Flags = 0
de_TableSize = 16
de_SizeBlock = 512 bytes
de_SecOrg = 0
de_Surfaces = 16
de_SectorPerBlock = 1
de_BlocksPerTrack = 63
de_Reserved = 2
de_PreAlloc = 0
de_Interleave = 65536
de_LowCyl = 2
de_HighCyl = 1017
de_NumBuffers = 200
de_BufMemType = MEMF_PUBLIC
de_MaxTransfer = 130560
de_Mask = 0x7FFFFFFE
de_BootPri = 4
de_DosType = PDS\3 0x50445303
             (different signature on disk = PFS\1 0x50465301)
dol_SegList = 0x4001B0C4
dol_GlobVec = -1
dol_Name = "DH0"

[Thomas Richter]

Originally Posted by mfilos

The patches I use are:
- StackAttack2 (not needed but many apps request bigger stack and I have to add it manually)
- SaferPatches
- PoolMem
- CopyMem080 (from Apollo Team) or CopyMemAIO (on non Vampire)
- MCP with minimum patches enabled (but can analyze if needed)
- MemTrailer

For Visuals I use:
- TitleShadow
- VisualPrefs
- Birdie
- MagicMenu (ye I know you don't like it)
- ReqAttack
- SwazInfo (ye I know we have RAWBInfo but still prefer it due to some reasons)
- ToolsDaemon (will replace in the future with MenuTools)
- WBDock2

Frankly, with the amount of patches you have in the system, it is hard to tell where the issue is coming from. I'm particularly sceptical about MCP, I do not know MemTrailer, and I would certainly leave all the "CopyMem" "improvements" away as those are more often not even helpful, but buggy. Birdy is also a dangerous patch.


Thus, please run a clean system, try again.

[Thomas Richter]

Originally Posted by Olaf Barthel

4K block support at this level may need further work in the direct SCSI layer, using the more modern SCSI commands (as in: not yet available in 1993/1994) which enable the detection and the use of the device's preferred sector sizes. Because this also depends upon the SCSI command emulation within the IDE/ATA scsi.device to be supported, it may be a tall order to get all the necessary pieces into place.

512 byte blocks might just be the sweet (and sour) spot for now...

Things aren't quite as bad, really. The FFS is smart enough to request blocks in larger chunks if it can, i.e. if the (FFS) block is 4K, it will also pull in 4K in one go through the SCSI layer, and if the user has a large read to make, and the file is continuous on disk, it will also perform the read in one go.


Thus, if partition bounds are aligned to 4K boundaries, which is what HDToolBox does by default now anyhow, it should be good.


The SCSI (actually "IDE") device translates the SCSI-Read command directly into an IDE command, but there is probably a weak spot because which IDE command to use is a bit tricky as there are multiple ones, and some have a maximum block size limit they can read in one go, so the scsi.device has to break up the transfer into multiple transfers. This is were all the problems with MAXTRANSFER and the scsi.device in 3.1 (and even 3.1.4) came from.

[mfilos]

Originally Posted by Thomas Richter

Frankly, with the amount of patches you have in the system, it is hard to tell where the issue is coming from. I'm particularly sceptical about MCP, I do not know MemTrailer, and I would certainly leave all the "CopyMem" "improvements" away as those are more often not even helpful, but buggy. Birdy is also a dangerous patch.


Thus, please run a clean system, try again.

When I had the problems the earlier days, I disabled EVERYTHING and still had issues.

Your reply was expected and it's clearly understandable so I will disable all of these and stay for a few days and see if something goes wrong.
Then again, I'm on PFS3 now anyway...

MemTrailer is a shell command for the startup-sequence by PeterK which patches the AllocMem() and the FreeMem() exec functions. It adds 16 to 96 bytes as a trailer to prevent trashed memory.

[Thomas Richter]

Originally Posted by mfilos

MemTrailer is a shell command for the startup-sequence by PeterK which patches the AllocMem() and the FreeMem() exec functions. It adds 16 to 96 bytes as a trailer to prevent trashed memory.

Again - dangerous, don't do that.

You find a lot of information on what particular system components expect from AllocMem() in the PoolMem readme, and this not quite according to the rules. In particular, it may interact badly with various "AllocAligned()" implementations. If you want to *test* for bad memory allocations or overruns, please use tools such as WipeOut by Olaf (without an MMU) or MuGuardianAngel (if an MMU is available) as those will in many cases tell you which program to blame.

[Olaf Barthel]

Originally Posted by mfilos

There you go. I mounted the CF to WinUAE, but I can send the same info from my Vampire as well

Thank you! Your PFS3 partition is using a software driver which is talking directly to WinUAE, so there should be no constraints regarding the maxtransfer settings, etc. which are caused by limitations of the V37-V43 IDE scsi.device.

Now, what about your FFS partitions? Did they use the same setup?

[Olaf Barthel]

Originally Posted by Thomas Richter

The SCSI (actually "IDE") device translates the SCSI-Read command directly into an IDE command, but there is probably a weak spot because which IDE command to use is a bit tricky as there are multiple ones, and some have a maximum block size limit they can read in one go, so the scsi.device has to break up the transfer into multiple transfers. This is were all the problems with MAXTRANSFER and the scsi.device in 3.1 (and even 3.1.4) came from.

This is what makes me wonder: which IDE scsi.device version is really in use here? The 255 * 512 = 0x1FE00 partition maxtransfer value magically resolving cryptic behaviour is a very odd result.

[Olaf Barthel]

Originally Posted by mfilos

MemTrailer is a shell command for the startup-sequence by PeterK which patches the AllocMem() and the FreeMem() exec functions. It adds 16 to 96 bytes as a trailer to prevent trashed memory.

If you need a tool for this purpose, you may put yourself into deeper troubles. Memory corruption almost always has a hard to detect source on the Amiga. This is how it is, and trying to paper it over will not resolve it. It will come back at you in a different and even more irritating form. Do not go there, it will only serve to make you miserable.

[mfilos]

Originally Posted by Olaf Barthel

Thank you! Your PFS3 partition is using a software driver which is talking directly to WinUAE, so there should be no constraints regarding the maxtransfer settings, etc. which are caused by limitations of the V37-V43 IDE scsi.device.

Now, what about your FFS partitions? Did they use the same setup?

I attach a screenshot from the same CF under my Vampire V4SA using the scsi.device.

When I was using FFS I was using exactly the same partitions (only changed the Filesystem, Blocksize and Buffers)

Originally Posted by Olaf Barthel

If you need a tool for this purpose, you may put yourself into deeper troubles. Memory corruption almost always has a hard to detect source on the Amiga. This is how it is, and trying to paper it over will not resolve it. It will come back at you in a different and even more irritating form. Do not go there, it will only serve to make you miserable.

Tbh, I didn't put it cause I wanted, but because I thought it will help with errors.
I'm no programmer, but I'm a long time enthusiast trying to understand and troubleshoot my problems without busting other people's balls.
Sometimes and if not reading through forums help, I tend to ask in case I get helped and that's all.

Not trying to play the smartass, or being disrespectful... On the contrary! Just feeling rather weird having issues while AmiKit with 100+ patches watches me and laughs :P

[Olaf Barthel]

Originally Posted by mfilos

Attachment 77429

I attach a screenshot from the same CF under my Vampire V4SA using the scsi.device.

When I was using FFS I was using exactly the same partitions (only changed the Filesystem, Blocksize and Buffers)

Thank you, here it matters with scsi.device and the maxtransfer setting. What does "version scsi.device" say?

Tbh, I didn't put it cause I wanted, but because I thought it will help with errors.
I'm no programmer, but I'm a long time enthusiast trying to understand and troubleshoot my problems without busting other people's balls.
Sometimes and if not reading through forums help, I tend to ask in case I get helped and that's all.

Not trying to play the smartass, or being disrespectful... On the contrary! Just feeling rather weird having issues while AmiKit with 100+ patches watches me and laughs :P

The risk of something affecting the performance and overall stability of the FFS stacks up the more changes are applied to the operating system in the hope of rendering it less crash-prone.

When the FFS validation process is running, it will keep the bitmap blocks in memory, which indicate the locations of the on-disk data structures that still need to be looked over.

Now imagine that there is a program running on your Amiga which accidentally corrupts the bitmap contents while the validation is in progress. That corruption may have the effect of telling the validator to look into on-disk data structures which are simply not there. It will stop and complain, never finishing the process.

This kind of memory corruption is very hard to spot and trace back to its origin. I myself spent more than a year trying to find the cause of what made my Amiga Samba 2.0.4 port crash & burn. It turned out that I had made a mistake when implementing the clib2 library which enabled the port to be made. That mistake corrupted data structures which Samba needed when processing its configuration files on startup.

The reason why I'm bringing this up is that the more runtime patches your system carries, the harder it becomes to gauge where memory corruption may have been responsible for random behaviour. In software development, especially on the Amiga, chasing down a memory corruption bug starts with dialing down the number of dependencies which may cause the havoc, such as the Amiga OS runtime patches. Then you enable them one at a time, retesting, etc. until you either manage to reproduce the problem or find a different angle to identify the cause of the problem.

Certain software, such as the file systems, are particularly vulnerable to memory corruption because the corrupted data in memory may find its way back to disk, causing persistent corruption.

What you wrote so far on the issues with the FFS suggests to me that because it is so vulnerable, something may be corrupting your memory.

[aros-sg]

Originally Posted by Thomas Richter

In particular, it may interact badly with various "AllocAligned()" implementations.

Which implementation? I don't think it would break the "Forbid -> FreeMem -> AllocAbs" one.

[mfilos]

Originally Posted by Olaf Barthel

Thank you, here it matters with scsi.device and the maxtransfer setting. What does "version scsi.device" say?

scsi.device 47.4 (30/12/2019)


I also found some weird behavior concerning the Title Bar change feature of Workbench Prefs.

I have a CPU/FPU/Chipset/VideoMode ENVARC variable set by AmigaT (thanks @Romanujan for the idea).
(I know that OS3.2.1 has embedded variables for CPU/FPU but it shows FPGA for my Vampire and wanted to change that)

I want to assign the variables to the TitleBar using the new Workbench Prefs feature.
Using %e identifier I can pass ENV variables just fine but ONLY if they have SPACE between them.
If I use them without SPACE then they aren't previewed.

Maybe using a smarter way of defining the ENV variable ( like MCP does with Start and Stop characters like %ev<variable>? ) then it wouldn't be a problem... just a hint

Check screenshot bellow:

[wiser3]

Originally Posted by mfilos

Maybe using a smarter way of defining the ENV variable ( like MCP does with Start and Stop characters like %ev<variable>? ) then it wouldn't be a problem... just a hint

Check screenshot bellow:
Attachment 77438

I've also noticed this. My solution of sometimes having a space where i don't want one is to add a space somewhere else so things look balanced. Result isn't how i want it to be but it looks better then having a space in an odd spot.