Welcome, Guest. Please login or register.

Author Topic: Hyperion announces OS 3.1 update  (Read 91238 times)

Description:

0 Members and 1 Guest are viewing this topic.

Offline kolla

Re: Hyperion announces OS 3.1 update
« Reply #224 from previous page: January 04, 2018, 06:58:10 AM »
Quote from: TrashyMG;834672

And as far as I know the sagasd device driver is working properly.


Except that it's slow, unreliable and you cannot boot from it. Yes, I suppose that passes as "properly" :)

Glad you find entertainment value in my Apollo Core slamming.
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
---
A3000/060CSPPC+CVPPC/128MB + 256MB BigRAM/Deneb USB
A4000/CS060/Mediator4000Di/Voodoo5/128MB
A1200/Blz1260/IndyAGA/192MB
A1200/Blz1260/64MB
A1200/Blz1230III/32MB
A1200/ACA1221
A600/V600v2/Subway USB
A600/Apollo630/32MB
A600/A6095
CD32/SX32/32MB/Plipbox
CD32/TF328
A500/V500v2
A500/MTec520
CDTV
MiSTer, MiST, FleaFPGAs and original Minimig
Peg1, SAM440 and Mac minis with MorphOS
 

Offline sean_sk

  • Newbie
  • *
  • Join Date: Aug 2017
  • Posts: 26
    • Show only replies by sean_sk
Re: Hyperion announces OS 3.1 update
« Reply #225 on: January 04, 2018, 11:54:35 AM »
Quote from: TrashyMG;834672
And as far as I know the sagasd device driver is working properly.


Unfortunately it's not working properly and is in dire need of fixing. The issue is that it causes some Micro SD card brands to throw a lot of CRC errors and the only solution is to slow transfer speed. I bought a Kingston 32MB and Patriot 32MB Micro SD card, nothing wrong with them, and yet both of them throw a ton of CRC errors.  Can't use them until it's fixed.
 

Offline psxphill

Re: Hyperion announces OS 3.1 update
« Reply #226 on: January 05, 2018, 02:17:33 PM »
Quote from: Thomas Richter;834662
The only difference between eight 512 byte transfers in row and a 4096 block transfer is in the low-level signalling of the IDE transfer, so the benefit of larger block transfers is not clear at all. The scsi device, if transfering 8 blocks in a row, already uses a block-transfer command for IDE - but this already holds for the V40 version out in the wild.


In theory some drives can only do 4k transfers. In practice most of them offer 512 byte sector emulation & you might not find a PATA drive that only does 4k.

However even with 512 byte sector emulation you have a potential performance problem, especially if you are doing a lot of unaligned writes. Writing 512 bytes into a 4k sector requires a read modify write. However this might not be that bad when you consider how long it will take an amiga to transfer those extra bytes.
 

guest11527

  • Guest
Re: Hyperion announces OS 3.1 update
« Reply #227 on: January 05, 2018, 06:49:20 PM »
Quote from: psxphill;834729
However even with 512 byte sector emulation you have a potential performance problem, especially if you are doing a lot of unaligned writes. Writing 512 bytes into a 4k sector requires a read modify write. However this might not be that bad when you consider how long it will take an amiga to transfer those extra bytes.

This problem is avoidable if you align partition boundaries correctly. Arguably, this is harder than necessary with the current HDToolBox.
 

Offline psxphill

Re: Hyperion announces OS 3.1 update
« Reply #228 on: January 05, 2018, 08:55:18 PM »
Quote from: Thomas Richter;834736
This problem is avoidable if you align partition boundaries correctly.


Alignment helps, you also need to make sure you always write in multiples of 4k. Even when appending data to the end of a file.
 

Offline gregthecanuck

  • Full Member
  • ***
  • Join Date: Feb 2003
  • Posts: 169
  • Country: ca
    • Show only replies by gregthecanuck
Re: Hyperion announces OS 3.1 update
« Reply #229 on: January 21, 2018, 02:38:01 AM »
Hey guys -

Any news on this OS3.1 update?

Thanks
 

Offline Gulliver

Re: Hyperion announces OS 3.1 update
« Reply #230 on: January 21, 2018, 03:48:10 AM »
Yes, it would nice to know how is it going.
 

guest11527

  • Guest
Re: Hyperion announces OS 3.1 update
« Reply #231 on: January 21, 2018, 09:31:15 AM »
Quote from: gregthecanuck;835231
Any news on this OS3.1 update?

What do you want to hear? It's down to the "tedious bug finding - bug fixing" part. Yes, that's the boring stuff.

The latest thing I have done is having spend around 12 hours of not finding a non-existing bug in icon/workbench that, in the end, turned out to be a bug in MungWall. The story itself is funny (well, not so much after having missed 7h of sleep, but...), so here we go.

One of our fellow betatesters reported MungWall hits from icon. I could not reproduce. He went that far of supplying a winUAE snapshot which allows to reproce them (yuck. I like the real stuff. Yuck, Windows! Eeek.). Anyhow, hits show up. It looked like icon was damaging the rear mungwall of memory allocations. After 4h of debugging, it looked like icon was writing into non-allocated memory. Strangely, the bug went away also after downgrading layers to v40. A bug in V45 layers? Really?

Debugging went on... I could see the allocations. Of course, every time you boot allocations are a bit different, so it is *really really hard* to reproduce the problem such that you could set a breakpoint at a specific place. After another 7h of debugging, it turned out that the memory was allocated ok, there was no corruption due to task switching or inter-task dependency, and all the hits were "bogus". After another hour of debugging I finally found the culprit, and the reason.

MungWall! Layers V37!

Now, here is the story. The CBM developers of layers had the "great" idea to allocate the cliprects of layers in one continuous memory chunk ("AllocMem(sizeof(struct ClipRect) * 5,...);)" and then split this chunk into pieces, and release them individually. Which is a bit against the protocol of exec/AllocMem, and which is a really stupid thing to do as it really throws another fragmentation bomb on the system. But anyhow... MungWall would scream about this b*llsh*t, and for that reason, MungWall includes a workaround by not munging memory if the allocation comes from layers, just to be tolerant. Which is all nice, except that V45 doesn't have this problem. Actually, even layers V40 doesn't have it. So the workaround is not even actually needed in first place.

But how could this impact icon? I'm not debugging layers here, right? Due to a matter of bad luck and just coincidence, MungWall now believed that the icon.library allocation code comes from layers, though classified the icon.library (actually exec) memory release call as regular. This is because icon as well as layers are "loadmodule'd" and for that reason, the resident list, which is checked by MungWall, is a bit "unusal", so the mungwall heuristics of detecting "this PC belongs to layers" failed.

Now, what happend now is that MungWall did not create a mungwall upon allocation (as, this was supposed to be layers) but checked the mungwall upon the memory release (as it looked harmless). Result? No Mungwall on memory release, as none was created in first place -> Big bad warning!

Morale of the story: Choose debugging tools wisely, and select tools that are still maintained. MuGA is aware of the layers problem, and includes a workaround, which is of course disabled for later releases of layers. Wipeout is also still maintained, and doesn't have the problem. The problem wouldn't have popped up if it would have been one of the two.

Old legacy debugging tools with bugs suck big time. 8h to be precise.
 

Offline Niding

  • Hero Member
  • *****
  • Join Date: Sep 2004
  • Posts: 566
    • Show only replies by Niding
Re: Hyperion announces OS 3.1 update
« Reply #232 on: January 21, 2018, 09:54:24 AM »
Thanks for sharing the process Thomas.

Its something people should have in mind when they nag about the pace of development, whatever it might be.
I dont think people appriciate this timethief when they make comments about dev-team set deadlines that comes and goes.
 

Offline gregthecanuck

  • Full Member
  • ***
  • Join Date: Feb 2003
  • Posts: 169
  • Country: ca
    • Show only replies by gregthecanuck
Re: Hyperion announces OS 3.1 update
« Reply #233 on: January 21, 2018, 10:13:31 AM »
Quote from: Thomas Richter;835241
What do you want to hear? It's down to the "tedious bug finding - bug fixing" part. Yes, that's the boring stuff.


Thanks for the good explanation on the latest bug fix. We have all been there before. Makes you want to take up raising Llamas or something.

But seriously, each of those old nasty bugs that is found and exterminated is a great thing - one less source of instability and pain for all developers going forward.

If you have a beer fund or something I would happily kick in.

Cheers!
Greg
 

Offline gregthecanuck

  • Full Member
  • ***
  • Join Date: Feb 2003
  • Posts: 169
  • Country: ca
    • Show only replies by gregthecanuck
Re: Hyperion announces OS 3.1 update
« Reply #234 on: January 21, 2018, 01:09:37 PM »
On a related note, I would like to add.....

Stefan "bebbo" Franke continues to work on his 68K gcc6 port. He appears to be getting close to a working compiler. At the moment he is working on debugging his code optimizer.
 
There are a couple of developers filing some good bug reports and helping to iron out the last few issues.
 
I think now is a good time for some donations to keep Stefan motivated. He has mentioned he would like to get a working debugger as well (gdb) which would be very good.
 
Come on folks, pull out some spare change. A good base gcc compiler is important for many reasons. Let's give him some more motivation to keep going. I have done my part for now.
 
His PayPal donation link is part way down this page: https://github.com/bebbo/amigaos-cross-toolchain
 
Let's keep the party going!  :)
 

Offline olsen

Re: Hyperion announces OS 3.1 update
« Reply #235 on: January 21, 2018, 01:29:14 PM »
Quote from: gregthecanuck;835247
On a related note, I would like to add.....

Stefan "bebbo" Franke continues to work on his 68K gcc6 port. He appears to be getting close to a working compiler. At the moment he is working on debugging his code optimizer.
 
There are a couple of developers filing some good bug reports and helping to iron out the last few issues.
 
I think now is a good time for some donations to keep Stefan motivated. He has mentioned he would like to get a working debugger as well (gdb) which would be very good.
 
Come on folks, pull out some spare change. A good base gcc compiler is important for many reasons. Let's give him some more motivation to keep going. I have done my part for now.
 
His PayPal donation link is part way down this page: https://github.com/bebbo/amigaos-cross-toolchain
 
Let's keep the party going!  :)


I for one would really, really like to see a decent source-level debugger become available. While we can make do with SAS/C and the CodeProbe debugger, if it's going to be GCC, there has to be a debugger to go along with it.
 

guest11527

  • Guest
Re: Hyperion announces OS 3.1 update
« Reply #236 on: January 21, 2018, 05:22:43 PM »
BTW, while we are at it. The big "thank you" note goes to Olaf for contributing an updated disk-doctor which has just been released to our beta testers. Yes, the one that speaks long file names that will come with 3.1.4.

I still need to see on which disk we can possibly fit it since it gained some weight - while it also gained a lot of knowledge. It is hard to believe, but the old "barely translated from BCPL" disk doctor didn't even know a lot about subdirectories...

But maybe I should leave it to Olaf to tell this story.
 

Offline LoadWB

  • Hero Member
  • *****
  • Join Date: Jul 2006
  • Posts: 2901
  • Country: 00
    • Show only replies by LoadWB
Re: Hyperion announces OS 3.1 update
« Reply #237 on: January 21, 2018, 06:55:05 PM »
Quote from: Thomas Richter;835253
BTW, while we are at it. The big "thank you" note goes to Olaf for contributing an updated disk-doctor which has just been released to our beta testers. Yes, the one that speaks long file names that will come with 3.1.4.

I still need to see on which disk we can possibly fit it since it gained some weight - while it also gained a lot of knowledge. It is hard to believe, but the old "barely translated from BCPL" disk doctor didn't even know a lot about subdirectories...

But maybe I should leave it to Olaf to tell this story.


FANTASTIC!  Indeed, thank you, Olaf.  You know we all want to hear about it.
 

Offline nicholas

Re: Hyperion announces OS 3.1 update
« Reply #238 on: January 21, 2018, 07:46:25 PM »
Quote from: Thomas Richter;835241
What do you want to hear? It's down to the "tedious bug finding - bug fixing" part. Yes, that's the boring stuff.

The latest thing I have done is having spend around 12 hours of not finding a non-existing bug in icon/workbench that, in the end, turned out to be a bug in MungWall. The story itself is funny (well, not so much after having missed 7h of sleep, but...), so here we go.

One of our fellow betatesters reported MungWall hits from icon. I could not reproduce. He went that far of supplying a winUAE snapshot which allows to reproce them (yuck. I like the real stuff. Yuck, Windows! Eeek.). Anyhow, hits show up. It looked like icon was damaging the rear mungwall of memory allocations. After 4h of debugging, it looked like icon was writing into non-allocated memory. Strangely, the bug went away also after downgrading layers to v40. A bug in V45 layers? Really?

Debugging went on... I could see the allocations. Of course, every time you boot allocations are a bit different, so it is *really really hard* to reproduce the problem such that you could set a breakpoint at a specific place. After another 7h of debugging, it turned out that the memory was allocated ok, there was no corruption due to task switching or inter-task dependency, and all the hits were "bogus". After another hour of debugging I finally found the culprit, and the reason.

MungWall! Layers V37!

Now, here is the story. The CBM developers of layers had the "great" idea to allocate the cliprects of layers in one continuous memory chunk ("AllocMem(sizeof(struct ClipRect) * 5,...);)" and then split this chunk into pieces, and release them individually. Which is a bit against the protocol of exec/AllocMem, and which is a really stupid thing to do as it really throws another fragmentation bomb on the system. But anyhow... MungWall would scream about this b*llsh*t, and for that reason, MungWall includes a workaround by not munging memory if the allocation comes from layers, just to be tolerant. Which is all nice, except that V45 doesn't have this problem. Actually, even layers V40 doesn't have it. So the workaround is not even actually needed in first place.

But how could this impact icon? I'm not debugging layers here, right? Due to a matter of bad luck and just coincidence, MungWall now believed that the icon.library allocation code comes from layers, though classified the icon.library (actually exec) memory release call as regular. This is because icon as well as layers are "loadmodule'd" and for that reason, the resident list, which is checked by MungWall, is a bit "unusal", so the mungwall heuristics of detecting "this PC belongs to layers" failed.

Now, what happend now is that MungWall did not create a mungwall upon allocation (as, this was supposed to be layers) but checked the mungwall upon the memory release (as it looked harmless). Result? No Mungwall on memory release, as none was created in first place -> Big bad warning!

Morale of the story: Choose debugging tools wisely, and select tools that are still maintained. MuGA is aware of the layers problem, and includes a workaround, which is of course disabled for later releases of layers. Wipeout is also still maintained, and doesn't have the problem. The problem wouldn't have popped up if it would have been one of the two.

Old legacy debugging tools with bugs suck big time. 8h to be precise.


Now this is the stuff I like to read about!

You protest but you know you loved every minute Thomas. ;)
“Een rezhim-i eshghalgar-i Quds bayad az sahneh-i ruzgar mahv shaved.” - Imam Ayatollah Sayyed  Ruhollah Khomeini
 

Offline olsen

Re: Hyperion announces OS 3.1 update
« Reply #239 on: January 22, 2018, 11:50:40 AM »
Quote from: LoadWB;835255
FANTASTIC!  Indeed, thank you, Olaf.  You know we all want to hear about it.


Bit of a dry subject, I suppose... Well, somebody asked for it ;)

The new Disk Doctor is the result of some hairy research into how the original version worked and why it failed. Commodore stopped shipping it with Workbench 2.1, and since then no file system repair or data recovery tool has been included with subsequent Workbench versions for Amigas with 68000 family CPUs.

The new Disk Doctor should solve a couple of hairy problems. Volumes can be much larger than they used to be in the 1980'ies and 1990'ies. Not only do you have to deal with storage media much larger than 4 Gigabytes, the number of files, directories and the associated management data structures have to be analyzed and their contents need to be kept in memory. Memory constraints are the biggest problem here, actually. The original Disk Doctor needed about 1.5% the size of the volume as working memory (RAM). For example, in order to "repair" a 20 Megabyte hard disk partition, you would have to have at least 330 Kilobytes of free RAM available. This would not fly on the original Amiga 500/1000/2000. Now imagine how the math would work out for a 1 Gigabyte hard disk partition. For the new Disk Doctor I developed a special type of data structure which lowers the memory requirements to around 0.1% of the volume size. Which means that about 1 Megabyte may be sufficient to deal with a 1 Gigabyte partition, and 8 Megabytes for an 8 Gigabyte partition. At least, this is what testing revealed so far.

Unlike the original Disk Doctor, the new version does not currently modify the contents of the volume. It only does two things: 1) examine the contents of the volume, looking for defects and 2) copy the contents of the directory tree to a different volume. It does what Dave Haynie's DiskSalv program did 32 years ago, but of course it does a lot more than that ;)

The "examination" begins by looking into every single block of the volume, taking note of the contents, the type of data found, damage to the contents. This is followed by another pass to figure out what files, directories, hard links and soft links exist and can be reached through the root directory (if there is one). Finally, this information is tied together so that one can tell which files, directories, etc. are still "sound" and undamaged, which ones are deleted, damaged or "orphaned", i.e. have no valid parent directories.

This information can be stored in a "disk and block information" (DABI) database file (actually, it's just a gzip-compressed plain text file) which might just become useful later. Instead of rerunning the examination (which takes quite a while to complete on a large volume), you can reuse the information gathered later.

You can use the new Disk Doctor just to check if a volume is in good shape, and not bother with the DABI files or the copying operation. But there's a lot more you can do. For example, you could use the DABI file to have Disk Doctor show you what it would have copied and then narrow down the set of files to copy through very simple filter restrictions (e.g. copy only "sound" files, copy only damaged files, copy only deleted files, copy only files matching a wildcard pattern). The copy process itself works very much like a "copy all clone #? .." command would, preserving all the properties (comment, user/group ID, modification time) of the original directory entries. When damaged files are copied, the damaged sections are skipped. The copy will retain the entire directory tree structure, if possible.

The new Disk Doctor takes a very thorough look at the state of the volume and its data structures. This includes, for example, making sure that all directories are consistent. It's possible for directory entries to show up when you list the directory contents, yet remain inaccessible when you try to open or delete them. The linkage information underlying hard links to directories and files is validated, too. Cycles in the many list data structures which the file system uses are detected. The root directory and its associated data structures (e.g. the bookkeeping information on what blocks are still available for use) are examined, too, which covers the bitmap extension block information. The extension blocks were added in 1987 with the introduction of the FFS. Their "Achilles heel" is the lack of a checksum which would make detection of corruption easier. The directory cache lists which give the directory cache (DCFS) file system variant its name are validated, too, and any differences found between a directory and the cache contents are recorded.

All this information is in part intended for a repair operation which is currently not implemented. A repair strategy would be needed first, and I have yet to come up with one. The more I learned about what can go wrong the more alternatives to dealing with the defects revealed themselves. You may be able to correct the smaller problems, such as restoring the consistency of directories, but if the root directory is damaged, how do you rebuild its bookkeeping information without destroying other data that might still be recoverable? So, after four months of work, this is still a research project, I'm afraid.

Finally, in case you wondered, the new Disk Doctor supports all Amiga file system variants which stem from the 1986 ROM file system and the 1987 Fast file system. This includes the international mode (introduced with Workbench 2.1), the directory cache mode (introduced with Kickstart 3.0) and the long name mode (introduced with AmigaOS 4). Hard links and soft links are supported (currently only soft links are restored by the copy operation, restoring the hard links still needs work). Volume block sizes of 512..65535 bytes per block are supported, too.

I can't promise you that using the new Disk Doctor will be an enjoyable experience (ha!), but it should be a whole lot less exciting than it used to be with the old Disk Doctor. If you need a tool to check if your volumes are sound and in good shape, and which will help you to recover data from them when you really need it, the new Disk Doctor should get the job done.