Qemu Pegasos II interrupts issue

	Bottom Previous Topic Next Topic
Register To Post

« 1 2 3 4 (5) 6 7 »

balaton

Re: Qemu Pegasos II interrupts issue

Posted on: 4/13 13:59 #81

Quite a regular

@joerg
Quote:

incomplete hardware initialization may be the reason for other problems as well, for example the RTL8139 driver not working.

That was debugged to be caused by some values not appearing in emulation the same way as on real hardware which the driver could not handle so nothing to do with hardware init or firmware. The emulation was also checked by the driver author and he said it confirms to the documentation so it's not clear where to fix it but there should be a way to fix it eventually either by making the driver to work with QEMU or make QEMU work more like real hardware. But I'm not the best person to do that as I don't have the driver sources and don't know how real hardware works so the driver author may know better.

afxgroup

Re: Qemu Pegasos II interrupts issue

Posted on: 4/13 17:26 #82

Amigans Defender

@balaton

I don't think official changes was never pushed to uboot repo.. It is not in "amiga style" publishing changes open source..
So the only way is try to find something can help. That's why we are in such big troubles..

i'm really tired...

joerg

Re: Qemu Pegasos II interrupts issue

Posted on: 4/13 18:18 #83

Just can't stay away

@balaton
Quote:

The first thing AmigaOS kernel does on amigaone is this:
...
AFAIK 0xff masks out all interrupts then 0x11 resets the PIC at which point it does not matter what the firmware has set as it needs to be reprogrammed which the AmigaOS kernel does.

According to the hw/intc/i8259 patch for MorphOS level triggered interrupts are used if LTIM or ELCR enable it


-    if (s->elcr & mask) {

+    if (s->ltim || (s->elcr & mask)) {

         /* level triggered */

and for example https://github.com/torvalds/linux/blob ... r/arch/x86/kernel/i8259.c doesn't seem to mess around with ELCR in it's init function either. It just saves/restores it when required in other parts. Probably means even Linux uses the firmware/BIOS configured settings for it.
In the 8259 docs I found writing 0x11 is called "initializing the PIC", but doesn't mention that that does a complete HW reset of it clearing/setting to default values all registers of it.
Therefore it shouldn't matter at all what the AmigaOS kernel does with LTIM as long as the firmware has set up ELCR correctly and using your BBoot as firmware replacement obviously doesn't.
Maybe U-Boot and CFE (unlikely) or SmartFirmware (more likely) don't configure it correctly to level, as required by AmigaOS, either, but that's no excuse for doing it wrong/not at all in BBoot.

Quote:

That (rtl8139.device) was debugged to be caused by some values not appearing in emulation the same way as on real hardware which the driver could not handle so nothing to do with hardware init or firmware.

Yes, but the bug using edge instead of level triggered interrupts has to cause additional problems with it, as well as with any other hardware driver.
With high frequency IRQ hardware/drivers (high data transfer speed but only a few bytes per IRQ), for example Hans' VirtioGPU and any ethernet >= 100Mbit/s (on AmigaOS worse because the TCP/IP stacks don't support jumbo frames), the problem with missing IRQs just happens more often than with hardware/drivers usually transferring several KB or even MB per IRQ such as SATA.

balaton

Re: Qemu Pegasos II interrupts issue

Posted on: 4/13 19:01 #84

Quite a regular

@joerg
Quote:

for example https://github.com/torvalds/linux/blob ... r/arch/x86/kernel/i8259.c doesn't seem to mess around with ELCR in it's init function either. It just saves/restores it when required in other parts. Probably means even Linux uses the firmware/BIOS configured settings for it.

I can't tell if Linux doesn't do that elsewhere or it does not need to because it can handle shared edge triggered interrupts (probably the latter) but this also does not matter for AmigaOS on an uncommon PPC board what does Linux do on x86.

Quote:

In the 8259 docs I found writing 0x11 is called "initializing the PIC", but doesn't mention that that does a complete HW reset of it clearing/setting to default values all registers of it.
Therefore it shouldn't matter at all what the AmigaOS kernel does with LTIM as long as the firmware has set up ELCR correctly

The docs also say that after 0x11 you have to write a few init values which contain the LTIM bit so it will reset that and neither amigaone/pegasos2 firmware nor AmigaOS on those systems set the LTIM bit. I don't know about ELCR as I don't know how to trace that but the U-Boot sources we have don't have anything that would set it. Maybe it could be verified with info pic or printing the value from QEMU. But I'm not even sure if ELCR is supported on real VIA chips, I could not find it mentioned in the VIA chip docs so maybe that's why MorphOS uses the LTIM bit instead.

Quote:

using your BBoot as firmware replacement obviously doesn't.
Maybe U-Boot and CFE (unlikely) or SmartFirmware (more likely) don't configure it correctly to level, as required by AmigaOS, either, but that's no excuse for doing it wrong/not at all in BBoot.

Well I think that's a good excuse because if BBoot aims to replace the firmware then it should do the same as the firmware. If those firmwares don't set this then BBoot does not have to either. Since AmigaOS overwrites at least the LTIM bit and we have no evidence that ELCR is used or works on real hardware I think this should be set up by the AmigaOS kernel the way it likes, which Hans seems to also found and tried and said it works so then it's solved. I can try to patch things up in BBoot, like I do for 64 bit BARs for AmigaOS but probably it's better to fix things where they are best handled. I'll see if an update with a fix will be available before I try to patch things in BBoot.

Quote:

Yes, but the bug using edge instead of level triggered interrupts has to cause additional problems with it, as well as with any other hardware driver.

That's another unrelated issue and it's fixed as above also for RTL8139. It's possible that there are still further unrelated problems somewhere in QEMU netwrok handling, libslirp or macOS or wherever else but we need to debug them and solve them one by one not mixing everything because then we just get confused. We identified two issues so far and working on fixing those. If there are more they will be fixed too eventually once we understand what are those issues.

joerg

Re: Qemu Pegasos II interrupts issue

Posted on: 4/13 19:22 #85

Just can't stay away

@balaton
Quote:

Since AmigaOS overwrites at least the LTIM bit and we have no evidence that ELCR is used or works on real hardware I think this should be set up by the AmigaOS kernel the way it likes, which Hans seems to also found and tried and said it works so then it's solved.

We have no evidence that ELCR works on real hardware (yet), but according to Hans changing the two 0x4D0/0x4D1 registers to the correct values does work with QEmu.

If that's the case it would be much better if BBoot does that, instead of each driver having to do it.

balaton

Re: Qemu Pegasos II interrupts issue

Posted on: 4/13 19:58 #86

Quite a regular

@joerg
I've added some logging to elcr and did some tests. The amigaone firmware writes some values there then the amigaone kernel replaces them with mostly the same values on its own so it should also work without BBoot doing anything with that. On pegasos2 the firmware also writes some values but it only inits the first PIC for interrupts that the firmware itself uses and sets elcr of second pic to 0. The AmigaOS kernel on pegasos2 does not write elcr unlike on amigaone so it will use the values set by firmware which is wrong. Sounds like a pegasos2 kernel bug to me as this won't work with real machine either.

I could set values from BBoot but on amigaone it will be replaced by AmigaOS so does not matter and on pegasos2 writing the same value as the firmware does not work and writing other values from amigone does not match real machine. I may still try to do it for pegasos2 in a later BBoot release just to avoid some problems with older kernels and maybe this could also be useful on real machine before an update with the fix comes out but the problem still seems to be unrelated to BBoot or QEMU on pegasos2 and likely also broken on real machine.

balaton

Re: Qemu Pegasos II interrupts issue

Posted on: 4/13 20:03 #87

Quite a regular

@Hans
What should ELCR be set on pegasos2 or how did you fix it in AmigaOS kernel so I can do the same in BBoot so it would work with current kernels until an updated one is avaiable (which might take long due to burocracy or legal issues so maybe until then a fix in BBoot could help but then it should do the same as the updated kernel will do).

smarkusg

Re: Qemu Pegasos II interrupts issue

Posted on: 4/13 20:38 #88

Not too shy to talk

@balatonQuote:

I can't tell if Linux doesn't do that elsewhere or it does not need to because it can handle shared edge triggered interrupts (probably the latter) but this also does not matter for AmigaOS on an uncommon PPC board what does Linux do on x86.

I checked the stability of the network connection on QEMU (8.1 as I remember correctly ) Linux/debian pegasos2 and A1XE. The kernels were from the 3.x and 4.x series.
I even compiled one myself under A1XE (I wanted to check sm502).
Everything worked properly. Sessions of 2h using audio stream and running mplayer in the background.
Based on this, I can say that QEMU emulation with pegasos2 and A1Xe machines using orginal uboot/firmware worked.
The AOS4 system using the original uboot/firmware did not....

edit:
I found a post even on the forum

https://www.amigans.net/modules/newbb/ ... id=143474#forumpost143474

Then I also still had some fun with those Linux on Peg and A1

balaton

Re: Qemu Pegasos II interrupts issue

Posted on: 4/15 0:28 #89

Quite a regular

@all
I've uploaded BBoot 0.7 (see https://qmiga.codeberg.page/) that might fix this even on real pegasos2 or when using passed through GPU on Linux host. Please test and let me know of any problems found.

Hans

Re: Qemu Pegasos II interrupts issue

Posted on: 4/15 3:17 #90

Home away from home

@balaton
Quote:

I've uploaded BBoot 0.7 (see https://qmiga.codeberg.page/) that might fix this even on real pegasos2 or when using passed through GPU on Linux host. Please test and let me know of any problems found.

I've tested this with the original Pegasos2 kernel, and my lockup problems are gone. Nicely done!

Hans

http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more.
https://keasigmadelta.com/ - more of my work

Maijestro

Re: Qemu Pegasos II interrupts issue

Posted on: 4/15 18:19 #91

Quite a regular

@balaton

Quote:

I've uploaded BBoot 0.7 (see https://qmiga.codeberg.page/) that might fix this even on real pegasos2 or when using passed through GPU on Linux host. Please test and let me know of any problems found.

Thank you for the new version 0.7 which I am already using.

MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE

geennaam

Re: Qemu Pegasos II interrupts issue

Posted on: 4/18 18:57 #92

Quite a regular

@balaton

Quote:

when using passed through GPU on Linux host

I had a spare hour and still the hard file with the Pegasos2 install and the zip with Kickstart modules on my disk. So out of curiosity I gave it a try.

Same issues since I last touched qemu with vfio (a year ago?).

qemu 9.0.0rc4+bboot-0.7 (pre-build version in archive) +pegasos2

- hd4850: crash of RadeonHD driver during loading of wb
-R9 270x: complete freeze of Ubuntu during init of RadeonHD
- RX560/570: QEMU fails to start with some PCI error message which I forgot to note down.

All tested cards work fine with my pc and Ubuntu 23.10.

So without further diagnostics, you at least know that nothing changed for vfio with the irq fix.

balaton

Re: Qemu Pegasos II interrupts issue

Posted on: 4/18 22:09 #93

Quite a regular

@geennaam
Quote:

So without further diagnostics, you at least know that nothing changed for vfio with the irq fix.

For these cards at least. But if I remember correctly there were other cards which worked with PCI pass through but had to disable IRQ to avoid problems. For those cards the IRQ fix might help.

I wouldn't know what's the problem with these cards that you've tried but do these work with a real PegasosII? I've heard from @joerg that amigaone was better for using such cards but they did not work with Pegasos. So if you have amigone version of AmigaOS you might try that with vfio. Also it might need the board firmware to run the card's BIOS so you may try running BBoot from pegasos2.rom (see README in BBoot, instead of -kernel bboot copy Kickstart.zip, bboot and bboot.fth to your boot volume and use boot hd:0 bboot.fth with -bios pegasos2.rom) or use U-Boot with amigaone. BBoot will just truncate 64bit BARs and fix IRQ controller setup on pegasos2 but won't try to set up gfx cards instead of the firmware or OS (that would need a BIOS emulator in BBoot).

geennaam

Re: Qemu Pegasos II interrupts issue

Posted on: 4/19 14:53 #94

Quite a regular

@balaton

- Radeon9250 refused to work properly.
- HD4850 resulted in a guru during opening of WB.
- RX560 still give me the following error and then nothing:


qemu-system-ppc: ../hw/pci/pcie.c:991: pcie_find_capability_list: Assertion `next <= PCIE_CONFIG_SPACE_SIZE - 8' failed.

Aborted (core dumped)

- Radeon HD R9 270x pass-through works with bboot.fth

It is much better then the slideshow of a year ago. But it feels slower than my SAM440 + same R9 270x. Definitely limited by slow CPU emulation. (i5-10400). The CPU Dock of ztools seem to confirm this. It peaks to 100% when resizing a window for example)

Warp3D Nova works as well. Haven't tried anything else.

(Click Right mouse-button and open image in new tab or window)

Resized Image

geennaam

Re: Qemu Pegasos II interrupts issue

Posted on: 4/19 16:25 #95

Quite a regular

OK, weird, but I used a drawer mounted as USB drive to transfer data between QEMU and Linux.
Now what that disabled it is definitely a lot faster.

Window resizing is a lot smoother. (compositing enabled) Running at 2560x1440@32bit now

Cow3D W3DNova manages 251 fps. That is a bit faster my SAM440-FLEX 800 MHz with the same R9 270x

https://ftp.hdrlab.org.nz/benchmark/gf ... 2d/OS/AmigaOS/Result/2773

- Night of the zombies 24fps menu / 10fps game /CPU 100%

Edited by geennaam on 2024/4/19 16:46:06
Edited by geennaam on 2024/4/19 17:11:46

balaton

Re: Qemu Pegasos II interrupts issue

Posted on: 4/19 17:55 #96

Quite a regular

@geennaam
You aren't posting enough details to be able to guess what might still be some issues but it seems to be at least a step forward that it works now. To improve it we'd need more details and testing and debugging. Also it may help others who want to reproduce and furhter test this if you posted your QEMU command and host side setup needed for this. (Maybe go back to the old thread or open a new one for this topic.)
Quote:

- Radeon9250 refused to work properly.
- HD4850 resulted in a guru during opening of WB.

No idea but maybe rhese things would need to be fixed in QEMU for these cards: qemu/hw/vfio/pci-quirks.c (and there's another one further down below in the same file). Basically as far as I understand old cards with 32bit BARs had their registers in BAR1 but BAR0+BAR1 is needed for 64bit VRAM BAR so in newer cards the registers are moved to BAR4. QEMU does not try to detect the card just assumes BAR4 so it won't work with older cards unless somebody fixes those functions for older cards.
For the guru, we don't know unless you get and post a crash report at least.
Quote:

- RX560 still give me the following error and then nothing:
qemu-system-ppc: ../hw/pci/pcie.c:991: pcie_find_capability_list: Assertion `next <= PCIE_CONFIG_SPACE_SIZE - 8' failed. Aborted (core dumped)

No idea what this is either but maybe it would need PCIe extended config space that's not visible in PCI? Currently the PCIe ports of sam460ex aren't emulated (mainly because I don't have any docs on them) so you can only pass through cards as PCI. I've tried to emulate PCIe on sam460ex but haven't finished it yet. Maybe for QEMU 9.1 or later.
You could get a more detailed trace on where this error is coming from by running qemu-system-ppc under gdb (add gdb --args before your qemu command) and get a backtrace when it hits the assert. Maybe 'bt full' which also lists the function parameters rather than just the calls.

balaton

Re: Qemu Pegasos II interrupts issue

Posted on: 4/19 18:11 #97

Quite a regular

@geennaam
Quote:

OK, weird, but I used a drawer mounted as USB drive to transfer data between QEMU and Linux.
Now what that disabled it is definitely a lot faster.

I can't imagine how a USB drive could affect GPU especially when not used. The only thing these might have in common are IRQs so maybe try 'info irq' command in QEMU monitor with and without the USB drive to see if there are a lot of interrupts for the USB. Or maybe there's something with the interrupt handler chain checking the USB before the GPU and it causes some slow down? I have no idea how all this works so just guessing, maybe Hans knows more about what could this be or how to debug/resolve it.
Quote:

Window resizing is a lot smoother. (compositing enabled) Running at 2560x1440@32bit now

Cow3D W3DNova manages 251 fps. That is a bit faster my SAM440-FLEX 800 MHz with the same R9 270x

https://ftp.hdrlab.org.nz/benchmark/gf ... 2d/OS/AmigaOS/Result/2773

- Night of the zombies 24fps menu / 10fps game /CPU 100%

The gfxbench2d score is much better than on real PegasosII (which seems to reach about 3100) and about half of the best real machine so I'd say it's not bad for a start. It seems the large rectangle scores are comparable to real hardware but the small rectagle values are lower. Also the RAM access is much slower so maybe that's where the problem is. Again this is something that Hans could have some more info on. Maybe the copy routines aren't the best for QEMU. If you compare RageMem results with real machine then some methods that work well on real machine are slower on QEMU. If AmigaOS happens to use that it may not work the best. Also you may try -cpu 750cxe (or whatever matches real machine). In theory having AltiVec should help but maybe it's not emulated that well yet. At least testing if it has any effect may help finding where the limitation is coming from.
When you see 100% CPU in guest is it possible to find out what code is keeping the CPU busy? That's where we should look to find what's limiting performance.

geennaam

Re: Qemu Pegasos II interrupts issue

Posted on: 4/19 18:37 #98

Quite a regular

@balaton

First of all, I am working with the Pegasos2 target. Not AmigaOne XE or SAM460 because that would need me to do new installs. I had the pegasos2 target still on my disk.

I'm also working with the latest QEMU 9.0.0RC4 which i've compiled myself

There isn't much to post. And tbh, the Radeon9250 and HD4850 are not interesting anyways. So let's ignore those.

The HD7000 works fine in pass-through thanks to bboot.fth boot V0.7 and Kickstart.zip.
- "Fast" Workbench at 2560x1440@32. Experience is limited by the speed of PowerPC emulation on my old Core i5. Take a Ryzen 7700x and you'll definitely leave the X5020 in the dust.
- Warp3D Nova works
- Warp3D works
- Compositing works
- Internet is stable with old RTL8139 driver
- Audio works
- 500MB FAT USB disk emulation will greatly slowdown the machine so better share files with a network drive

So currently I have a QEMU which is usable with a real HD7000 card in pass-through and feels like sam460 speed.

When I connect my RX560 instead then QEMU fails to start with that error message described above. Apparently this has something to do with a bad reset of the RX card. Or at least that is what you said a year ago.

The info how to pass through and bind the VFIO kernel driver to the GFX card is well described on various sites. You can even use some helper scripts on Ubuntu to ease the pain https://github.com/pavolelsig/passthrough_helper_ubuntu_20

pegasos2.rom isn't capable of fully configuring a HD 7000 card so the " /failsafe" io trick is still needed to get the of prompt back.

My qemu commandline is as follows:


qemu-system-ppc -machine pegasos2 -rtc base=localtime -serial stdio -vga none -device VGA,romfile="" -drive media=disk,format=raw,file=hd.img -m 1024M -bios pegasos2.rom -device es1370,addr=0x08 -device rtl8139,addr=0x09,netdev=nic -netdev user,id=nic,hostname=pegasos-os4 -device vfio-pci,host=02:00.0,bus=pci.0,x-vga=on -device vfio-pci,host=02:00.1,bus=pci.0 -accel tcg

The pass-through parameters depend on where the card is located in your iommu tree of course.

Using bus=pci.0 makes sure that the card gets connected on the virtual AGP bus for the pegasos2.

For me is was just (my technical) curiosity if I could finally make it to work. I have no intention to run QEMU or write a tutorial.

Going to rebuild my machine back to original state so that my kids can play Fortnite on Windows again

Edited by geennaam on 2024/4/19 18:53:31

joerg

Re: Qemu Pegasos II interrupts issue

Posted on: 4/19 18:39 #99

Just can't stay away

@balaton
Quote:

When you see 100% CPU in guest is it possible to find out what code is keeping the CPU busy? That's where we should look to find what's limiting performance.

One of the best tools for checking CPU usage on AmigaOS4 should be Tequila (source), because a few parts of it are based on my 20 years old "top" tool

geennaam

Re: Qemu Pegasos II interrupts issue

Posted on: 4/19 18:50 #100

Quite a regular

@joerg @Batalon

Just to be clear.

The emulated system with HD R9 270X reacts just like a real machine The only difference is that the speed of emulated PowerPC is slow on my PC. Therefore the workload jumps to 100% faster then on my X5020. But when the emulated system is idling. The CPU load is also 0%-1% just like on real systems.

It was just an observation that the system became sluggish with the emulated USB drive as described here in the FAQ: http://zero.eik.bme.hu/~balaton/qemu/amiga/index.html

This can be caused by the fact that the shared drawer and ubuntu itself are installed on an old mechanical HDD.

Register To Post	« 1 2 3 4 (5) 6 7 »
	Top Previous Topic Next Topic

Currently Active Users Viewing This Thread: 1 ( 0 members and 1 Anonymous Users )