This is so annoying! And it has annoyed me for years. I have a Workbench setup for UAE. But I cannot do anything under the emulation that writes to the harddisk because of the old stupid bug that crashes on write! Argh!!

Honestly I don't know how we've put up with it for so long. It makes any serious work under the emulation useless! Everytime I try and install something or modify some Workbench setting I am reminded of this bug that freezes UAE on OS4 and risks invalidating my harddisk.

I used PPC UAE over the years on Linux, Mac and OS4. Yet it is only on OS4 that I see this bug. And it must have existed for nearly ten years!

I have my volumes setup up as filesystem devices. I am emulating an Amiga on AmigaOS after all and it helps if I need to transfer files. Which I need to do a lot as I can't write from inside the emulation.

I tested all versions of UAE for OS4 and they all contain the bug. Does anyone use a filesystem drive? Does it also happen for HD images?

Is there some max transfer setting in UAE I can change? Small writes tend to miss the bug. Or is the only solution to use an image if that works?

@Hypex

Strange. E-UAE works OK for me, but I use 68k version.

@Hypex

It doesn't lock up with hardfiles for me, if you need to add anything to the hardfiles from the amiga side just mount them as a floppy (IDFx:) with diskimage.

Use Make_HDF to create an empty file then mount it under OS4 and copy your existing filesystem devices across.

Use the SDL version if you want to do any serious work so you will have access to RTG once you've instaled picasso96.

_________________
OS4 Rocks
X1000 beta tester, Sam440 Flex (733)

Visit the Official OS4 Support Site for more help.

It may be that your sole purpose is to serve as a warning to others.

@pavlor

Well I don't want to run an emulator on another emulator even if it would work with JIT.

@Severin

I was hoping to avoid a hardfile but it looks like I can't as long it crashes.

This will have to be dealt with sometime I think as RunInUAE with WB3.1 is now an OS4 contribution. And that is setup as a directory so if the user attempts to write to it under UAE it will eventually crash.

@Hypex

Quote:

Hypex wrote: @Severin I was hoping to avoid a hardfile but it looks like I can't as long it crashes. This will have to be dealt with sometime I think as RunInUAE with WB3.1 is now an OS4 contribution. And that is setup as a directory so if the user attempts to write to it under UAE it will eventually crash.

Not really, RunInUAE is for playing games, the only saves are 'save disk' style so using an adf file works fine. The UAE used is the amiga graphics version so you can't use RTG at all so not a lot of use for doing anything serious with it anyway.

_________________
OS4 Rocks
X1000 beta tester, Sam440 Flex (733)

Visit the Official OS4 Support Site for more help.

It may be that your sole purpose is to serve as a warning to others.

@Hypex

This problem / bug writing on Euae shared directory is present on AmigaOs version ,
look like there is a kind of bug or on .device or in filesystem.
On MacOsX everything is working good

I think the AmigaOs dev team have to gave a look on this.
I dont know on morphos if this bug is present too.

_________________
I love Amiga and new hope by AmigaNG
A 500 + ; CDTV; CD32;
PowerMac G5 Quad 8GB,SSD,SSHD,7800gtx,Radeon R5 230 2GB;
MacBook Pro Retina I7 2.3ghz;
#nomorea-eoninmyhome

@Hypex

No problem using a "filesystem" device under OS4. I use it pretty rarely though.
Does it happen very often for you?

_________________
Philippe 'Elwood' Ferrucci
Sam460 1.10 Ghz
AmigaOS 4 betatester
Amiga Translator Organisation

@elwood

what file system is on your partition where Euae/Emulation is present?
I have SSF and there crash when copy or install something

_________________
I love Amiga and new hope by AmigaNG
A 500 + ; CDTV; CD32;
PowerMac G5 Quad 8GB,SSD,SSHD,7800gtx,Radeon R5 230 2GB;
MacBook Pro Retina I7 2.3ghz;
#nomorea-eoninmyhome

@elwood

It happens a lot. A small write can escape it, the average write will kill it. Here's how to reproduce it. You can use RunInUAE to do it. And BootWB from the menu which should give a Workbench\ as virtual HD. Or UAE with a virtual volume setup.

Locate and drag MultiView to RAM. Now drag it from RAM to the Workbench or your virtual volume, in the root for instance. It starts to copy and then UAE freezes. Or it does here.

@Hypex

Quote:

This is so annoying! And it has annoyed me for years. I have a Workbench setup for UAE. But I cannot do anything under the emulation that writes to the harddisk because of the old stupid bug that crashes on write! Argh!!

I'm not a heavy EUAE user as it's so slow but I can't say I've noticed any crash on write issues.

I just started it (waited a day for it to boot in an aproximatin of my old a1200) and coppied a whole directory of pictures to a new location, no crashing here.

How does this crash manifest for you? With a particular app? Perhaps there is an emulation issue with that app?


Quote:

risks invalidating my harddisk.

Your running on FFS? Mine in on SFS2 a partition as are my "harddisks" (directory on the main disk mapped as hardisk in EUAE). Might be an important difference.

Quote:

And it must have existed for nearly ten years!

Yet in all those years you never fixed it. EUAE is open source, you are a coder, wouldn't it be so much nicer to start a thread saying "Hey I fixed this long running bug at last!" Or even "I'm trying fix this bug but am a bit stuck, anyone got any ideas?"

_________________
BroadBlues On Blues BroadBlues On Amiga Walker Broad

@tlosm

I have tested with both FFS and SFS. On FFS it crashes the file-system on the file-system context. On SFS it crashes in SFS on the UAE context.

@Hypex

Quote:

It happens a lot. A small write can escape it, the average write will kill it. Here's how to reproduce it. You can use RunInUAE to do it. And BootWB from the menu which should give a Workbench\ as virtual HD. Or UAE with a virtual volume setup. Locate and drag MultiView to RAM. Now drag it from RAM to the Workbench or your virtual volume, in the root for instance. It starts to copy and then UAE freezes. Or it does here.

Okay I restart EUAE, waited another day, dragged afew things from a Workbench: then back to Workbench using the workbench, no issue.

I'm running euae with a dedicated config file and the roms from my a1200, whilst I don't use EUAE for "real work" I certainly would start it from RunInEUAE for that. Though as you say it been happening for ten years I guess RunInUSE is not a factor.

This is with

UAE> uae --version
E-UAE 0.8.28
Build date: Sep 20 2005 11:19:07

Wow didn't realise it was that old. Maybe it predates the bug you refer too!

I'll try with the more recent version later...

_________________
BroadBlues On Blues BroadBlues On Amiga Walker Broad

@broadblues

Quote:

Wow didn't realise it was that old. Maybe it predates the bug you refer too! I'll try with the more recent version later...

Okay used the 2011 build from my RunInUAE install. This time I had to wait a week, as it runs soo much slower!.

The copy via shell test worked fine again, but the copy via workbench crashed as you describe, though I got no GR or anything just a lock up in EUAE and a partial lockup (open apps worked no new porcesses would start) in the host amigaos4 which still required a reboot.

I could send you my prehistoric version if that would be of help.

Why the new version should be so much slower than the old version I don't know unless it wasn't built with optimisation or is doing a more accurate and hence slower chipset emulation or something.

_________________
BroadBlues On Blues BroadBlues On Amiga Walker Broad

@broadblues

Quote:

I'm not a heavy EUAE user as it's so slow

Have you setup RTG?

Quote:

How does this crash manifest for you?

Anything that writes a large enough amount. It can be moving a DOSDriver on the Workbench. Writing some config file. Or using the Installer in an attemmpt to install something. Such as a CaceCDFS DOSDriver.

Quote:

Your running on FFS?

On my main volume, yes. I've also tested it with SFS1 and it crashes that.

Quote:

Might be an important difference.

There can be for misusing DOS. For example if someone used OpenFromLock() and didn't know it unlocks on success and unlocked it later regardless it could be ignored or it could freeze thw whole system. DEpends how the filesystem handles lock management. I've seen this happen on both OS3 and OS4.

Quote:

Yet in all those years you never fixed it.

No, because the bug is fixed elsewhere. And I thought the point of EUAE was to grab the newest sources for UAE and compile it for our platform. But it seems not. We are using an old source, even for new UAE builds, and I don't know why they are doing this. Even the UAE-JIT prpoject is using an old buggy version of UAE which isn't good for all the hard work put into it.

Quote:

Though as you say it been happening for ten years

Depending on my memory.

RunInUAE as OS4 contrib uses E-UAE-amigfx which contians the old buggy code.
E-UAE 0.8.29
Build date: Jul 30 2011 03:59:51

My usual:
E-UAE 0.8.29-WIP4
Build date: Mar 27 2007 22:45:15

JIT:
Build date: Mar 27 2007 22:45:15
E-UAE 0.8.29-PPCJITBETA03

Quote:

irectory on the main disk mapped as hardisk in EUAE). Might be an important difference.

Yep! That's it. My system was usless after.

@tlosm

Quote:

what file system is on your partition where Euae/Emulation is present?

SFS2
I often mount the volumes in readonly to avoid the creation of many files __UAEDB__ or similar, everywhere on my HD. But when I enable read/write I didn't see a problem.
I'll give more details when I'm back home.

Last edited by elwood on 07-Jul-2014 at 04:55 PM.

_________________
Philippe 'Elwood' Ferrucci
Sam460 1.10 Ghz
AmigaOS 4 betatester
Amiga Translator Organisation

@thread

Oops, I have a crash as soon as UAE writes to the HD. So I was wrong.
This is on a beta system but it's probably the same on Update6 as you experienced. I'll report to Almos ASAP.

_________________
Philippe 'Elwood' Ferrucci
Sam460 1.10 Ghz
AmigaOS 4 betatester
Amiga Translator Organisation

I wonder where the problem lay. No such problems with 68k euae, regardless of file system using an ootb compile, nor do the aros or mos versions have said probs.

Im surprised no-one has bought up such a showstopping bug before now.