I experimented some more with my boot loader and I think the problem is that AmigaOS does not seem to scan and map PCI devices itself but relies on the firmware to do that. Both Linux and MorphOS would do that themselves so they work with current virtual open firmware but for AmigaOS looks like I'll need to do that from the boot loader also. This is more work but if I do that patching 64bit bars at the same time will be easy so I had to do this anyway sometimes just hoped it would work without this but it seems it doesn't. The kernel probably starts but does not find the gfx card when it does not have mapped BARs. This might also be similar issue when a PCIe card is not mapped by the firmware so you may need to take care of that from the Forth sctipt or wait for me to finish this in the boot loader.

@MartinW
I also have no idea why it won't work on pci.0 as all PCI interrupts are tied together but the twp are different buses (these are created in hw/pci-host/mv64361.c that models the Marvell Discovery II system controller which has two PCI buses). So maybe the current way of keeping track of interrupts that relies on the irq counter in PCI fails. If you read the links in post #812 it was discussed there how we got to this solution but maybe it's not quite clear from all the emails. I wanted to test my original solution what I first posted but that does not apply any more so I had to port that to current master or maybe you can go back to the version before th ecurrent fix was committed and try to apply the original series on that, this was somewhere this January I think but if you can't do this easily then don't spend too much time with it as that series would need to be rewritten anyway so maybe I should do that first and only test that. But it's not likely to get that in 8.1 so either it will stay as it is or I can try to submit the work around you're using now as that may still be better tha nleaving this broken. If we found this eariler we could have try to rewrite this but that's now only possible after the freeze for 8.1 is over so I don't bother much but maybe if I'll have some time I'll try to make a patch to test and see if that can be submitted still.

@white
I won't reply to this any more. I've tried to explain this to you very extensively and I believe I've told you everything multiple times but I just can't get the information through so maybe somebody who got what I said and can translate to Italian could help you further with this.

Just as a last attempt: DISPLAY=:0 means the local display where the app is running so when you want it to appear on a remote display then can't use DISPLAY=:0, must use DISPLAY=localhost:10 which is the step you always seem to be missing.

Just as a quick update: In the past days I've put together a proof of concept of the replacement boot loader I'm working on and now I could just boot AmigaOS with it but at the moment only using the pegasos2.rom not yet with QEMU's virtual OF. This at least proves that it could work but something is likely missing from QEMU's virtual OF so I still need to find that out and work on fixing that to be able to reach the goal to be able to use pegasos2 without the rom binary.

I also wanted to ask to test some patches for the IRQ issue but currently osdn.net seems to have some network problems from here so I can't upload them there and also did not prepare the patches yet as I was spending my free time with tho boot loader. Does the current patch solve the issue or is there still a problem when using that patch? Maybe I'll just submit this for the 8.1 release if it works as I may not have time to do a more proper fix now.

@MartinW
I also think that the DSI errors are not related to the IRQ issue but there could well be multiple issues not just one, this is all rally new and still in development so nobody said it would be rock solid. But testing is reveals these problems so they can be fixed.

I'd like to see others who could reproduce the problem also check the patch for the IRQ issue and see if it helps. We still have a week or two to get bugfixes in QEMU 8.1.

For the DSI I don't think anybody could tell anything from that window which even does not show PPC regs but empty 68k emulator ones. If you see such a window always click write crash log on bottom right and post the whole log as @derfs did. Maybe also helps if you're running with debug kernel (just change kernel to kernel.debug in Kicklayout). A DSI is a Data Storage Interrupt exception which happens when something accesses unmapped memory like when dereferencing a wrong pointer. So the error that broke the pointer likely happened before this error so it may be a bit diffucult to find out where and likely needs some knowledge of the coda where this happens but more detailed info on that should be in the crash log so make sure to collect it for these crashes. (I don't remember if it asks for location or just puts it in RAM: but you should be able to find the log somewhere.)

@MartinW
Well at least we have a workaround. I'll wait for a few more people test it then I can try to submit it as a fix for 8.1 as the code freeze starts tomorrow so won't be able to rewrite this anyway until 8.1 is released. If this works I can think of a different fix or if the other approach would be better but if it does not cause noticable slow down then it could probably be good enough for now.

There are a lot of info on those links but if you're interested in QEMU internals then maybe an interesting read.

OK so what we know now is that is should not be related to the network card driver as it happens with other devices sharing the interrupt so maybe it's just network and passed through gfx card happen to generate the most interrupts so the problem happens more often when these are used. Since it's not related to any driver we can exclude those end problem is likely in emulation or kernel level.

The handling of PCI interrupts was added in this series:
https://patchew.org/QEMU/cover.1678188711.git.balaton@eik.bme.hu/
which is the final version that was accepted but this takes some shortcuts and only works with the setting everything sharing IRQ9. This is a simplified version of my original approach here:
https://patchew.org/QEMU/cover.1678188711.git.balaton@eik.bme.hu/
that kept track of individual interrupts and may have worked better but people did not like the complexity and we got to the simpler version which still seemed to work in testing. Later an alternative approach was suggested here:
https://patchew.org/QEMU/cover.1678105 ... 1.git.balaton@eik.bme.hu/
that returned to the original approach but relying on PCI addresses to identify sources rather than custom functions but it was too late in the release cycle to elaborate on that and nobody cared since.

The discussion and findings can be read at the above links and it also points to where and how this could be debugged further and what's the most likely place to fix it but I don't have time for it now so I'm posting it here in case somebody has time and wants to dig further into it. Since I don't have an easy way to reproduce it it eould also be a bit difficult for me to debug it now. I'd rather work on the boot loader first as that's something I at least have a clear path with and already made some progress with it so I'll finfish that first before trying to look at this which might take a few weeks so if anybody finds out something please let me know.

I'd like to add that even though this wasn't too far away I've already swapped out most of this from my brain so I'd have to reread the above and get back to it again too so not much better position to work on it than others (OK maybe I remember something about the devices emulation that I did before but other parts of QEMU I have to explore all the time too).

@derfs
Quote:
Does that actually make any difference or what makes a difference is using network or not?
Quote:
We already know that using the network d will freeze so that does not take us further. What do you mean by freeze at same point? Is that some identifiable point when it freezes related to some event happening or what? Also what I asked is to forget about the network for now and just remove -device rtl8139 and test other devices if they also cause a freeze together without the network to know it is related to the rtl8139 driver or not.
Quote:

If you check the Pegasos2 schematics you'll see that all INT lines from all PCI and AGP ports are connected together and the firmware programs the VT8231 to map all of these to IRQ9. We've checked that before and it's now emulated accordingly. I did not check APIC which I just realised might be needed when irq 25 was mentioned but I'm still not sure AmigaOS actually uses APIC but if it does that's not emulated currently. This could be verified by testing the same rtl8139 device with real hardware that I was also asking above. I'll check to see if anything accessses the APIC regs later when I'll have time but I'm not sure yet this would be the problem just some other thing to check.

@derfs
Were these values collected when it works or when it froze? Are you still have IRQ handler disabled for gfx so basically noting shuold use any interrupts now? If it works that way you can try enabling only two and see which combination causes problem. We know that anything involving network can freeze so you can test other combinations like usb+sound, gfx+sound, gfx+usb etc. to see if any combination is causing a freeze or it's related to one particluar driver.

After checking the docs looks like VT8231 has APIC which I don't think we emulate now but I don't know if it's used. I'd have to check if the regs are written, they are currently within the io range so likely could go unnoticed because of that. It does not help avoiding confusion that we have very similar acronyms in the same chip that handles PCI PIC APIC and ACPI so one has to be careful not to make typos.

@Maijestro MartinW
You can't remove the via-ac97 device as it is part of the VT8231 chip and is always emulated but if you don't load a driver for it then it should net generate interrutps. Actually the proper AmigaOs way to disable a driver is to copy it from Sys:Devs to Sys:Storage instead of renaming but both ways should work.
The problem Maijestro referred to was before via-ac97 was emulated so without disabling the driver it hung because it got no reply from the non-existing device. But another problem existed that PCI interrupts were not connected to VT8231 so even other devices like network card did not work. Then I've implemented PCI interrupts to VT8231 which fixed the network card and implemented via-ac97 to get sound but that's independent of IRQ problems. The ptoblem with multiple devices freezing under MorphOS was only happening because level sensitive mode o PIC was not implemented in the old way MorphOS wanted to use it but that should not affect other guests that don't use that and we didn't see a problem with those before getting the gfx card in the picture. Maybe the occasional network related hang is the same but with a GPU generating more interrupts it happens sooner. Or there's something with interrupt handling but I don't know what and first I'd like to check with other guests and also on real hardware if lossible to make sure it's something with emulation end not a guest side issue.

There's also the patch that lowers the interrupt and raises again when an unserviced one is pending to generate an edge in case the OS did not notice or expects level sensitive interrupts that I've first posted as a work around for the MorphOS issue which could be tested if it helps with this issue. I've posted a link in post #787 it should be possible to Download mbox from that page and apply that to QEMU git master with git am -3 patch.mbox. It wasn't needed after the level sensitive mode was fixed in PIC emulation but maybe it could help with this issue ot at least should not make it worse so may worth a try just to see it' may be related to that part of the code.

Edit: There's a lot of things going on here so to avoid getting lost if you report some test result plase make sure to describe exactly what you tested, real hardware or emulated, what devices what settings or QEMU version and patches you've used so we know what the test shows exactly.

@Georg
Quote:
I don't think that's likely because the pass thorugh is handled by Linux and QEMU and works with other emulated machines so I don't think there's a bug there. A bug is more likely within pegasos2 emulation that I wrote or in guest code but there isn't much in pagasos2 emulation relating this although the IRQ delivery in pegasos2 is a bit confusing as PCI interrupts are connected to both VT8231 and Marvell discovery and both of these can be programmed to raise a CPU interrupt. I think we emulate both as some guests use one way and others the other and beginning of this year before QEMU 8.0 we found that AmigaOS seems to use the VT8231 so maybe something is not emulated there correctly but it would be hard to debug because one could enable traces for IRQ state changes but since there are millions in a run it would be impossible to find anything in that unless we know what to look for. So first should locate the problem a bit more to be able to pinpoint what to check further.

@joerg
First of all what is IRQ 25? There are only 16 ISA interrupts in pegasos2 (it has no APIC I think only the two ISA PICs) and also Ranger lists IRQ line 0x9 so it's IRQ 9 that's shared between all PCI devices and it is how that's done on real hardware as well as you can see from logs ported here from real hardware. So this is supposed to work somwhow and sharing the interrupts is not the problem unless the rtl8139 driver has some problem with that which is what I start to suspect now. Maybe it was just not tested on real hardware because the pegasos2 has more than enough on board ethernet ports for a desktop. So we could test two things:

Could those who run emulation besides testing the same with Linux as I've asked above please try to test AmigaOS without network card for a while to see if the freeze happens that way too? You can also try using -device ES1370 for sound instead of via-ac97. This uses the same IRQ but different driver so maybe gets us closer the where the problem could be.

Those with real pegasos2 do you have an rtl8139 card to test that this at least works well on real hardware and not a problem with the driver?

@white
I think on the AmiCygnix side you have to add the key for :0 not :10. Even though you access it as :10 on the Linux side that's because we forward port 6010 to guest port 6000 so on the host it's display :10 but it's really display :0 for AmiCygnix.

@derfs
At least we have something to start from but it's not clear what the network card IEQ would be shared with if you disabled the gfx card IRQ. Do you use USB or sound or just the network when it freezes?
Does the same happen with Linux? Can you try to reproduce it wirh Linux too and see if that logs something.
Maybe also check info pic output in QEMU monitor when it hangs.

@white
The sm501 also supports 32bit with MorphOS but looks like it's a problem in AmigaOS graphics library that can't handle the pixel format the sm501 needs so it's a limitation of the AmigaOS driver not the sm501 or irs emulation in QEMU which works but AmigaOS cannot use it. So I can't do anything about that, this driver is the same on real hardware. We'd either need to emulate a different card or write AmigaOS driver for a card already emulated as I've deiscussed on the AmigaGfx page on my qmiga devel pages. But neither of these is somethng we can do in a short time so it may take a while unless somebody takes up the task of trying to write a display driver for a simple QEMU gfx card.

We saw freeze on QEMU with MorphOS before when multiple PCI devices were used and in that case the cause was quite clear because MorphOS uses an ancient feature of ISA PIC to use level sensitive mode that wasn't emulated. This was fixed in QEMU 8.0 but nothing else uses that and other OSes including AmigaOS and Linux use the default edge sensitive mode. There's some info on this topic and the baclground in the intro part of this book chapter https://www.oreilly.com/library/view/l ... s/0596000081/ch09s06.html so maybe there's something with emulating interrupts or this is something that would also happen on real hardware but for some reason less often to cause a problem. I don't know how to debug or improve this, the only thing in this area I had is a patch here: cd0b323bb88df202e36014f950c0eb ... 24.git.balaton@eik.bme.hu" rel="external" title="">cd0b323bb88df202e36014f950c0eb ... 24.git.balaton@eik.bme.hu" title="https://patchew.org/QEMU/cover.1677628524.git.balaton@eik.bme.hu/cd0b323bb88df202e36014f950c0eb13a9fafd54.1677628524.git.balaton@eik.bme.hu/#cd0b323bb88df202e36014f950c0eb ... 24.git.balaton@eik.bme.hu" rel="external">https://patchew.org/QEMU/cover.1677628 ... 24.git.balaton@eik.bme.hu that tried to make sure there's always an interrupt triggered when needed but this was replaced with implementing level sensitive mode so this patch wasn't needed any more but maybe worth a try to see if it makes any difference for this (likely not) but I have nothing better at the moment.

To get futther we should find out what the OS is waiting for when it appears frozen. Is there a way to get some debug info from AmigaOS when a hang happens? Like triggering some dump of all tasks or otherwise find out what is it doing?

@geennaam
I guess it froze much before any screen blanker started so it should not be related to that. Maybe it would freeze faster if you use more PCI devices simultanously such as network, sound and a usb mouse (add -device usb-mouse) and move it around while playing sound and see if that freezes or also using network. The gfx card may use interrupts that the emulated sm501 doesn't so maybe that's why we get freezes with a passed through card but I still don't know so just want to verify this theory because I don't have any better one at the moment.

@white
You can copy your .Xauthority file from the Linux host and that should allow to use the same magic cookie but you need to do that every time you restart your host as it's generated when you log in to Linux.

I did not check this but I think again you have two choices:

USe the same magic cookie on host and guest so to do that copy .Xauthority from Linux to AmiCygnix

Or add AmiCygnix's cookie on Linux to be used when you connect to localhost:10 so you would have two cookies in authlist, one for :0 that comes from .Xauthority in host and one for :10 that comes from AmiCygnix.

Maybe just copying the host file and use that also on guest is simpler.

@derfs
Without knowing anything about this rhe log mentioning Spiral.blanker looks like to me a screen saver starting. So likely to OS still works but some parts are frozen like graphics output waiting for some event to happen that does not happen such as an IRQ which probably happens on real hardware but somehow missed on emulation. Without knowing more about this it would be hard to find out. If the same can be reproduced with Linux that may at least give as some log messages to point some direction because the AmigaOS logs don't seem to have any error that could help. I may also be wrong with the theory that it's caused by a missed interrupt but that seems to be a plausible reason but we would need some help from somebody who can debug AmigaOS and find out what is happening. I don't have access to AmigaOS source and don't know what it does so I can't really debug it.

Although I wonder if the network problem reported before is the same issue. Can that be reproduced some way so I can try to look at it?

@kas1e
Missing detailed PCI infos from lspci -vvv and maybe you can also include full dmesg as well in case there's some interesting log message there.