Today the lockup issue disappeared. Both with compositing on and off.
Sounds like updater or one of its components might use an uninitialized variable or pointer.

Hard or soft reset will not clear the memory. Powering off the X5000 did the trick apparently. So it might fail again at random.

@Skateman

When I enable the effects in prefs/gui, intuition tries to close all windows. Somehow it fails to do so, so the requester retries a couple of times until it remains open. But during this time, I am able to start Updater. After I pressed cancel to close the intuition requester, Updater continues to start fine until the next reset.

This doesn't work for me the other way around.

With effects enables, the system locks up before the Updater window is opened.
With effects disabled, the Updater window opens but fails to complete because of a lockup.

I don't have V3 of the RadeonHD driver yet. Maybe that is the issue. I will buy it tomorrow to find out.

I have the same issue as Paul describes.
Updater locks up for me as well. Worked fine on on the pre-hotfix installation.

@kas1e

Quote:

I spend a day creating a cross compiler environment. First tried several times with msys2. But that didn't work out. Got it working with ADTOOLS on cygwin following your step by step guide here: https://www.amigans.net/modules/xforum/viewtopic.php?post_id=116486

As expected, the SFDC script runs fine in this environment. Unfortunately it produced unusable files that gave a lot of compiler errors.

So I followed your advice and tried to compile the Envy24HT source files one by one.

But it almost feels like the sources are sabotaged.
Envy24HT.c includes pci_wrapper.h and proto/expansions.h
proto/expansions.h includes expansion/pci.h.
In pci.h, we can for example find:

enum enPCIConfigSpace{
PCI_VENDOR_ID = 0x00,
PCI_DEVICE_ID = 0x02,
.. and so on
};

But pci_wrapper.h continues with an #undef PCI_DEVICE_ID
and #define PCI_DEVICE_ID 2

Not only is this useless considering the enum in pci.h. The compiler also punishes me with a "error: expected identifier before numeric constant".

So I have a lot of cleanup to do. Not only fix all compiler errors, but also remove the Morphos and Aros code until I get a clean AmigaOS4 AHI driver framework. (hint: Coffee prices will go up in the coming weeks )

It feels like it will only compile out of the box on the target which was last in line to port the driver to.

@Raziel

I tried to build from ram: as well. I noticed path errors in the log that started with /disk/.
Turns out that binutils has a problem with ram: because it is an assign to "Ram Disk"
So it cannot cope with spaces in paths.
Moved the project to work: and everything compiled as expected.
Maybe this explains your mkdir issue.

@kas1e

Problem is that the AHI makefiles create Os4 specific files with SFDC. So I have to run it at least once.

@salass00

Good idea. That is worth a try

@kas1e

The unix path in the sfdc script raised the suspicion that AHI was build with a cross compiler anyways. So I am now creating the cross compiler environment using your blog post

@trixie

Thanks, I will need it.
Both Morphos and Aros use the available library.c and h. Why Amigaos4 ifdefs to the missing library_card instead is a mystery to me.

All I need is a AHI driver source for a "modern" chipset that can actually produce a working driver with the latest SDK to act as a template for my own driver. Because AHI driver development is not/poorly documented.

I read everywhere that the Envy24ht is the most stable driver. Hence this effort.

Found this thread with google:
https://os4coding.net/comment/2378
A guy called Hypex tried to compile the Emu10kx driver with help from the original coder but eventually gave up. Best quote in the thread: "I had to agree with Davy (Wentzler) in the end, that compiling an AHI driver is a bitch! "

@Thematic

Solved with correcting the path in the script self. Apparantly it wasn't fully configured for Amigaos4 or maybe it was expected to run with some cross compiler.

@NinjaCyborg

Thanks. The first line had some unix path to perl in place. Replaced it with #!/SDK/Local/C/perl and now it runs.

Next issue is that perl throws me a script failure. But I will try this next week on AmigaOSFE with the latest SDK. See if this helps.

The Envy24HT driver seems to missing library_card.c and h.
It is supposed to be located in /Drivers/Common and is only needed for the amigaos4 driver.

Going to create dummies and see what happens.

I am trying to build the AHI source from aminet. "unfortunately" it is multiplatform so the source needs to be configured for amigaos4.
So I run the configure script to create the makefiles for the device and drivers but it fails on a missing component called SFDC.

Found SFDC master on aminet. It claims to "convert SFD files into something useful". It is created by the same programmer as the one who created AHI so this must be the component that I am looking for.

After config and make install it creates the following three files:
/SDK/local/C/sfdc
/SDK/POSIX/usr/local/bin/sfdc
/SDK/POSIX/usr/local/share/man/man1/sfdc.1

So I run the the configuration script of AHI again and SFDC is found. Configuration was successfull and the makefiles are now succesfully created.

But when I try to make AHI I get the following error:

SFDC --target=powerpc-unknown-amigaos --mode=gatestubs ../Include/SFD/ahi_lib.sfd --output gatestubs.c \
--gateprefix=gw --libprefix=_ --libarg=last --addvectors=device
T:gmake.sh.1843.WFIUPW[2]: SFDC: No such file or directory
gmake[1]: *** [gatestubs.c] Error 1


Apparently SFDC is not found. So nothing "useful" is created as promised. Upon inspection of the sfdc created in the SDK, sfdc is not a binary but some kind of perl script.
Anybody knows what I am doing wrong here?

@NinjaCyborg

I replied to this part of your post:

"Note however there's no dependency management in Amiga OS anywhere"

@NinjaCyborg

correct me if I am wrong but if you open a library then you should check for the version. This is afaik how it is supposed to be done on amigaos. Don't know how this works with classes and shared object (.so). Under the assumption that using classes and shared object work in a similar fashion then the program should exit in a clean manner with an error message if the minimum version of a dependancy is missing.

@trixie

I would have expected that software still checks for the minimum version of dependancies.
Amiupdate also pushed Ibrowse 2.5.4. This version terminated with an message that my installion lacks graphics library V54.0. (So FE as minimum)

Maybe it is time to cleanup Amistore as well. I came across several other software that claim update 6 as minimum requirement.

Anyways, if eveything goes well then my X5000 will arrive on monday.

The cost of FE for the sam440ep might be only 30 euro. But it is almost everywhere out if stock. Alinea Computer in germany was the only one out of 6 stores that I tried who was able to supply this version.

@Spectre660

I returned to the amiga scene just two weeks ago. Been away for at least 5 years. Now waiting for my X5000 and aoa4.1 Fe sam440ep edition to arrive. So for the time being I am stuck with 4.1 update 6. Will buy the enhancer software plus and other software as soon as I have the X5000 up and running.

But that aside. The Enhancer Software Core V1.1 requires 4.1 update 6 as minimum according to the readme. But that is clearly not the case. Unless the issue is located in the backend of the amisphere and updater software or there are unlisted/overlooked dependancies of the Enhancer core edition components.
I am not trying to blame anyone. Just writing down the observations and issues that I experience with the enhancer software core edition in the hope that it would solve my issue and help others who experience the same issue. And naturally there is also some frustration that my problem was ignored on both amigaworld and amigans until today.

In my opinion we are all in this together to try to make the best of the current situation.

@Skateman

Did you order a bare motherboard or a complete system? Because it takes up to 2 weeks for a complete system according to their website.

@trixie

I ordered the bare motherboard without memory. Maybe they need to prepare the microSD card for each order. But writing such a small image to a microsd card in windows takes less than a minute.

I am not sure what you mean with all sorts of quality testing but I surely hope that they didn't order those X5000 boards without factory testing (AOI, boundary scan, FPT/ICT), functional test). Because this is a huge quality risk given the complexity of the board. You cannot cover such a board with just functional testing afterwards. Maybe just filter out the DOA ones. But the ones that cause random lockups or grimreapers will most likely slip through. And the manual handeling (especially in a non-ESD safe environment) will also add significantly to the failure rate.

Upon ordering, the shipment was shown to be 2-5 days. I counted extra for "after brexit" customs clearance. But it looks like that it already might take 5 days before it will be shipped.

I guess I am too impatient for the amiga world. Or spoiled by the non-amiga world. But likely a combination of both.

@Spectre660

I was under the impression that the issue started after an upgrade to FE update 2 in combination with updater 53.65. Some user report that the issue is gone after an update to 53.7.

Apparentlly I am a unique case with the combination of 4.1 update 6 and updater 53.7. I also get a grimreaper instead of a freeze.

For what it is worth, the freeze of amishpere disappears when I disconnect the network cable. Maybe this helps nto arrow down the root cause.
Grimreaper on Updater remains.

@Spectre660

Apparently there are dependancies that you have have and others don't.

I run a clean reinstall of Amigaos4.1 update 6 on a sam440.
Installed Enhancer Software Core V1.1 with the following version numbers:
- Updater 53.7
- AmiSphereServer 53.37
- AmiSphere 53.37
- kernel 53.58 (received through amiupdate)

AmiSphere locks and updater gives a grimreaper.
I know that I do not run FE yet (Ordered 440ep version from Alinea and will arrive once DHL decides that they took enough preparation time to finally send it "international" within a "borderless" europe (5 days and counting); Amigakit warehouse is this huge that it already takes 3 days to pick the X5000 order) but it is supposed to run on 4.1 update 6. I also know that the core edition is free of charge. Is it free because it doesn't run anyways? Was it not tested but just assumed to work on 4.1 update 6? Nobody involved on amigans or amigaworld care to comment on this issue. But from what I read in this thread, FE will not solve the issue either.
I am a returning user, so i knew that it wouldn't be a walk in the park. But try to imagine the frustration of new users.