Who's Online |
117 user(s) are online ( 71 user(s) are browsing Forums)
Members: 1
Guests: 116
smf,
more...
|
|
|
|
|
Re: What the fastest possible x64 emulation way of OS4 today ?
|
Posted on: 2023/7/25 12:01
#7621
|
Quite a regular 
|
@batalon There was no bboot output. Just those two lines. But I've upgraded ubuntu to 23.04. Installed the dependancies and rebuild qemu 8.1.2 rc0 again. And guess what? Error gone at first and QEMU boots with bboot 0.4. RX 560 shows an image on my monitor. Everything runs stable. With and without interrupt. With and without compositing. Only spoiler is that the GUI is dead slow. But it works and that's a start  I've attached the RX 560 to AGP bus. So bus=pci.0 Interrupt line is 0x0B Pin A. Interrupt number is 27. Unfortunately the "Assertion `next <= PCIE_CONFIG_SPACE_SIZE - 8' failed" error returns randomly after a restart of QEMU. So it looks related to missing reset of the RX 560 GPU. Edit1: GPU doesn't work on pci.1. So that must be the shared interrupt bug in the RX driver.
|
|
|
|
|
|
Re: What the fastest possible x64 emulation way of OS4 today ?
|
Posted on: 2023/7/25 10:54
#7622
|
Quite a regular
|
@balatonQuote: balaton wrote:@Maijestro
Just type info jit or info irq in QEMU monitor. You can redirect the monitor to stdout with -monitor stdio in which case leave out -serial stdio or you can use -serial mon:stdio to multiplex both on the same window. You need to switch the recording to HD playback then you can see and read it better Thanks for the help, I'll run some tests later to see if I'm right with my theory.
|
|
MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE / AmigaOne A1222plus AmigaOs4.1 FE
|
|
|
|
Re: What the fastest possible x64 emulation way of OS4 today ?
|
Posted on: 2023/7/25 10:42
#7623
|
Quite a regular
|
@Maijestro If in doubt read documentation: https://www.qemu.org/docs/master/system/monitor.htmlJust type info jit or info irq in QEMU monitor. You can redirect the monitor to stdout with -monitor stdio in which case leave out -serial stdio or you can use -serial mon:stdio to multiplex both on the same window. Your scren shot is not readable at all, it's two low resolution and your color scheme does not help either so can't somment on that.
|
|
|
|
|
|
Re: What the fastest possible x64 emulation way of OS4 today ?
|
Posted on: 2023/7/25 9:34
#7624
|
Quite a regular
|
@balatonQuote: balaton wrote:@Maijestro
info irq and info jit are QEMU monitor commands that print statistics about how many interrupts or events during jit happened that could impact performance. You should do about the same thing once when it's fast and once when it's slow and after the same code has been run in the guest check the stats to see if there's a difference that could show where the slowness could come from. Could you please give me an example how to include info irq and info jit under Qemu ? I would then test it with a good and bad session, I do not know how to use info irq and info jit together with Qemu. In the meantime I did another benchmark with SDLBench under AmigaOs4.1, it shows the result of a good and bad session. Since I couldn't save the output as history because Qemu fails completely after the benchmark, I made a screenshot and packed both results side by side. On the left the good Qemu session, on the right the bad Qemu session.  @smarkusg Quote: You need to check the load monitor to see if something is eating up your resources. Usually an mds process related to Spotlight or other system related processes.
Maybe qemu is pointing to a core that is currently busy/used. I took this into account in my tests and the CPU host was always occupied with 5% CPU last when the tests took place.System-heavy processes like mdworker or spotlight were not active during the test. You can also see it in my video above.
Edited by Maijestro on 2023/7/25 9:59:25
Edited by Maijestro on 2023/7/25 10:07:58
|
|
MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE / AmigaOne A1222plus AmigaOs4.1 FE
|
|
|
|
Re: What the fastest possible x64 emulation way of OS4 today ?
|
Posted on: 2023/7/25 9:23
#7625
|
Quite a regular
|
Also apparently this problem of using graphics cards connected with a bridge was already solved in MoprhOS according to this thread: https://morph.zone/modules/newbb_plus/ ... d=1215&forum=11&start=175so that could help checking if the problem is with pass through, the bridge or AmigaOS. When you think you have a working setup with a card that MorphOS should support, preferably one that was tested in above thread (These are probably only some HD cards) then try with the MorphOS demo iso to see if that works which then mean it's probably something missing from AmigaOS that we might be able to patch up in BBoot or if it does not work then maybe it's somehting with the bridge or QEMU or your host setup that needs to be solved.
|
|
|
|
|
|
Re: What the fastest possible x64 emulation way of OS4 today ?
|
Posted on: 2023/7/25 9:17
#7626
|
Quite a regular
|
@geennaam
That's not enough info to see whu it fails. At least the BBoot output would also be needed. Other than that the error tells you where in QEMU source it failed: qemu/hw/pci/pcie.c line 92 so you could try to find out what does that do why it might not work. Likely getting unexpected values from where it's called and from where it's called can be found from a back trace that you can get with gdb either running QEMU under gdb or enabling coredumps with ulimit then analyse it with gdb after the crash. I can't tell any more from that error alone.
|
|
|
|
|
|
Re: What the fastest possible x64 emulation way of OS4 today ?
|
Posted on: 2023/7/25 9:16
#7627
|
Not too shy to talk 
|
@Maijestro
I think this is not a qemu problem.
You need to check the load monitor to see if something is eating up your resources. Usually an mds process related to Spotlight or other system related processes.
Maybe qemu is pointing to a core that is currently busy/used.
Check on a freshly booted system: reboot, start the monitor - see what happens or wait a while for all startup processes and startup programs to finish.
start Qemu.
Check a couple of times on a cleanly booted system - I know this may be silly advice for you.
|
|
|
|
|
|
Re: What the fastest possible x64 emulation way of OS4 today ?
|
Posted on: 2023/7/25 9:12
#7628
|
Quite a regular
|
@Maijestro
info irq and info jit are QEMU monitor commands that print statistics about how many interrupts or events during jit happened that could impact performance. You should do about the same thing once when it's fast and once when it's slow and after the same code has been run in the guest check the stats to see if there's a difference that could show where the slowness could come from.
|
|
|
|
|
|
Re: What the fastest possible x64 emulation way of OS4 today ?
|
Posted on: 2023/7/25 9:09
#7629
|
Quite a regular
|
@MartinW
Both RedHat and Debian have ppc cross compiler so any distro based on those would also likely have it. Arch only seems to have binutils for ppc, installing that is one prerequisite but gcc has some others then it takes a while to compile. There are some scripts to build a cross compiler that you could seearch for.
Maybe even the compiler included in the AmigaOS SDK should work so if you have that (even on AmigaOS) you could try. Only other tool used is make so that should be available anywhere.
|
|
|
|
|
|
Re: Pegasos2 with RadeonHD/RX via bridge
|
Posted on: 2023/7/25 9:04
#7630
|
Quite a regular
|
@kas1e
I wanted to ask you to send .properties of that bridge to check its ranges property but you did that above already. What if you cd to /pci/pci and do ls? Does a display device node appear there? Then you can also get .properties of that to see how the firmware sees this. You could get all info from SmartFirmware with dump-all but that's too long to post here, maybe send it to me or upload somewhere. There's also a dump-pciconfig word in SmartFirmware but I don't know what that does but sounds like it can get some info from a card.
BBoot currently only lists devices attached to the internal PCI buses of Pegasos2, it won't go down in bridges. I'll need to change that but don't know yet how to access devices behind the bridge on pegasos2 so I'll also have to read some docs on these bridges. At least now I have the device node for the bridge so I can see if there's some info on this there.
|
|
|
|
|
|
Re: What the fastest possible x64 emulation way of OS4 today ?
|
Posted on: 2023/7/25 8:56
#7631
|
Quite a regular
|
@balaton Rebuild QEMU 8.1.0 rc0 without patches. Used bboot 0.4 This is what I get with a RX560
qemu-system-ppc: ../hw/pci/pcie.c:927: pcie_find_capability_list: Assertion `next <= PCIE_CONFIG_SPACE_SIZE - 8' failed.
Aborted (core dumped)
|
|
|
|
|
|
Re: qemu and tap network on Windows
|
Posted on: 2023/7/25 8:37
#7632
|
Not too shy to talk
|
@white If you use tun/tap it is very simple - you are combining too much why are you running in qemu? (,net=192.168.0.1/24,dhcpstart=192.168.0.1) you are doing yourself unnecessary network separeation and have to combine with some fw ports. configure this for your network on Linuxe , leave qemu alone. set up a transparent interface example: set on amigaos static ip number ip: 10.0.2.15/24 route: 10.0.2.2 linux: ip addr add 10.0.2.2/24 dev tap0 in qemu "-netdev tap,id=mynet0,ifname=tap0,script=no,downscript=no -device rtl8139,netdev=mynet0" remember how they write it - tcpdump is your friend tcpdump -i tap0 -n check yourself what is going on, ping 10.0.2.15 from linux and you will see that it works set yourself the address masking with SNAT or MASQUARADE for 10.0.2.0/24 if you want to have the output to the world and that's it https://ibb.co/3f66cBy
Edited by smarkusg on 2023/7/25 8:56:58
Edited by smarkusg on 2023/7/25 10:29:28
|
|
|
|
|
|
Re: Pegasos2 with RadeonHD/RX via bridge
|
Posted on: 2023/7/25 8:06
#7633
|
Home away from home 
|
@joerg Quote:
vendor and device names? That's just from the pci.ids file.
You probably have an older one, or none, on the Pegasos2.
You can download the current version from https://pci-ids.ucw.cz/
Updated pci.ids on peg2 to the latest one, and even copy the same version of Ranger binary as on x5000 : and after reboot, it still shows the same "N/A" things. I tried SysMon tool, and this one reads all correctly on Peg2. So it can be Ranger's general issue (or some os4 components) @All Interesting that when i go to the OF, and type:
cd /pci@80000000/pci@6
.properties
I had:
vendor-id 0x10B5 (4277)
device-id 0x8112 (33042)
revision-id 0xAA (170)
class-code 0x60400 (394240)
subsystem-id 0x0 (0)
subsystem-vendor-id 0x0 (0)
.vendor-name "PLX"
.class "Bridge Device"
.subclass "PCI/PCI"
interrupts 0x1 (1)
devsel-speed 0x1 (1)
66mhz-capable
device_type "pci"
#address-cells 0x3 (3)
#size-cells 0x2 (2)
clock-frequency 0x1FCA055 (33333333)
name "pci"
reg 6:0
xp6,0,10,0:10000
assigned-addresses xp6,0,10,80000000:10000
bus-range 1:1
ranges
Even OF know that vendor name is PLX :) And that i have when i put RadeonHD in:
ok cd /pci@80000000/pci@6
ok .properties
vendor-id 0x10B5 (4277)
device-id 0x8112 (33042)
revision-id 0xAA (170)
class-code 0x60400 (394240)
subsystem-id 0x0 (0)
subsystem-vendor-id 0x0 (0)
.vendor-name "PLX"
.class "Bridge Device"
.subclass "PCI/PCI"
interrupts 0x1 (1)
devsel-speed 0x1 (1)
66mhz-capable
device_type "pci"
#address-cells 0x3 (3)
#size-cells 0x2 (2)
clock-frequency 0x1FCA055 (33333333)
name "pci"
reg 6:0
xp6,0,10,0:10000
assigned-addresses xp6,0,10,80000000:10000
bus-range 1:1
ranges [0x40 bytes]
[000] 01000000 00000000 FE002000 01000000
[010] 00000000 FE002000 00000000 00001000
[020] 02000000 00000000 80100000 02000000
[030] 00000000 80100000 00000000 1FF00000
ok
So we can see that when video card added, the ranges surely added, so bridge do see that things inserted.
Edited by kas1e on 2023/7/25 8:22:16
Edited by kas1e on 2023/7/25 8:32:30
Edited by kas1e on 2023/7/25 16:51:36
|
|
|
|
|
|
Re: What the fastest possible x64 emulation way of OS4 today ?
|
Posted on: 2023/7/25 7:52
#7634
|
Quite a regular
|
@balaton Quote: balaton wrote:@Maijestro
Quote:So this should be checked under Qemu.
AS this seems to be dependent on some changes between boots maybe it's related to memory layout but I still can't find out what could be different. Try at least gather some info from QEMU monitor about the two cases such as info jit info irq and see if there are some differences there or if you can get a memory map or other statisctics from AmigaOS that can be compared then maybe some difference can be identified from those. I can't help with debugging these but I also can't find and fix anyhing in QEMU until the issue is identified a bit more exaclty. How do I use "info jit info irq" ? I could examine both sessions where it runs sometimes faster and sometimes slower with the same CPU. That there is a big performance drop is already confirmed by my video also other benchmark tests inside AmigaOs4.1 show this behavior. It occurs with all CPU's that are available to us. As already mentioned there are no other programs running on the host system that could affect the CPU performance. It doesn't matter if Peg2.rom or BBoot is used I've observed this problem since Qemu 7.2 when I started to do benchmarks. I would like to investigate this problem to get a more stable and clean Qemu emulation. I just need some help on what to do with Qemu to see the differences.
|
|
MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE / AmigaOne A1222plus AmigaOs4.1 FE
|
|
|
|
Re: Pegasos2 with RadeonHD/RX via bridge
|
Posted on: 2023/7/25 6:28
#7635
|
Just can't stay away 
|
@kas1e Quote: See, we have more info in Device vendor and device names? That's just from the pci.ids file. You probably have an older one, or none, on the Pegasos2. You can download the current version from https://pci-ids.ucw.cz/
|
|
|
|
|
|
Re: Pegasos2 with RadeonHD/RX via bridge
|
Posted on: 2023/7/25 5:53
#7636
|
Home away from home
|
@All
So i put this PEX8112 into X5000, to see how it will react: Firstly i put it without GFX card, then in Ranger i have a little more info to compare with the info i got from Pegasos2. That how it looks like in X5000:
ID Bus 0x06 Device : 0x04 Function 0x00
Class Base: 0x06 Sub: 0x04 IFace: 0x00 (PCI-to-PCI Bridge)
Device 0x8112 Rev: 0xAA (PEX81212x1 Lane PCI Express-to-PCI Bridge)
Vendor 0x10B5 (PLX Tecnology. Inc)
Header Type Bridge
Cacheline Size 32 bytes
Status CapList 66MHZ MedDevSel
Capabilities BusMaster intercard Bridge
Command IO Mem Master Int
Interrupt Line 0x05 Pin: A Number: 16
See, we have more info in Device, then Cacheline Size 32bytes and not 0 and Capabilities have an also "Bridge" word. Minor things probably, but still.
The “resource ranges” also empty.
Next, i attach RadeonHD to it (btw had to comment hda.device loading, as it crashes in this combo).
And it didn't showups inside of that bridge tab, but instead in the defaults bridges of X5000, which is:
ID Bus 0x04 Device : 0x03 Function 0x00
Class Base: 0x06 Sub: 0x04 IFace: 0x00 (PCI-to-PCI Bridge)
Device 0x8092 Rev: 0x02 (N/A)
Vendor 0x111D (Integrated Device Technology. Inc[IDT])
Header Type Bridge
Cacheline Size 32 bytes
Status CapList FastDevSel
Capabilities BusMaster intercard Bridge
Command IO Mem Master Int
Interrupt Line 0x00 Pin: None, Number: N/A
And in this tab i do have both VGA Controller + Audio Device of my card. That without external power-riser, but then, this is X5000 with it's PCIs and not Pegasos2 , as well as this is UBOOT and not OF.
Will try on X1000 as well: It didn't have UBOOT, but SmartFirmware, maybe will give some more light on.
|
|
|
|
|
|
Re: Pegasos2 with RadeonHD/RX via bridge
|
Posted on: 2023/7/25 5:16
#7637
|
Home away from home
|
@balaton Quote:
But apart from that it seems we may also have a problem that if the pegaos2 firmware does not set up devices behind a bridge and AmigaOS only looks at devices that are set up by the firmware then it won't see the graphics card connected to the bridge unless BBoot would also do that. Is that the case or does AmigaOS try to drive the bridge and find devices behind it?
I think we will know for sure once i will test this PEX8112 based with power extender, and when i will test second adapter with PI7C9X111S chip in (with which most of ppls have success on SAM440 previously) If everything still will be the same in all cases, be it PEX8112 with power adapter, or PI7C9X111S (with or without adapter), then we can think that this is something about firmware/hardware indeed. Tomorrow i will receive power-riser, so at least we can check PEX8112 with it, and we can go further from this point.. EDIT: i also may try it in the X1000 or X5000 too, just to see how it configured (or not) via UBOOT, and how Ranger then looks like after i insert video card to it.
|
|
|
|
|
|
Re: Pegasos2 with RadeonHD/RX via bridge
|
Posted on: 2023/7/25 0:03
#7638
|
Quite a regular
|
@kas1e
Was using a single card. so no display.
Serial Debug indicated an endless loop.
Power was as is . No external power .
Based on some later success of others with the P17C9X and external power one can probably narrow the issue down to either power or the PEX 8112 or both in the case of the Sam440ep.
|
|
|
|
|
|
Re: What the fastest possible x64 emulation way of OS4 today ?
|
Posted on: 2023/7/24 23:29
#7639
|
Not too shy to talk
|
I'm just catching up after the weekend. Going back to the last thing that I was doing it looks like I need to experiment in bboot with what we are patching and what we are leaving alone. At the moment I'm struggling to get a working PPC cros compiler for the distro I picked (Arch linux). It doesn't have any pre-built packages that I can see and it's failing to build from source.
@balaton - to make life easier, what distro are you running?
|
|
Amiga x5040 ı 16GB ı RX580
GB-A1000 060@100,
A1200 PiStorm32-Lite CM4
|
|
|
|
Re: What the fastest possible x64 emulation way of OS4 today ?
|
Posted on: 2023/7/24 22:46
#7640
|
Quite a regular
|
@Maijestro Quote: So this should be checked under Qemu. What to check though? If we can't reproduce it and also don't know what's different between the cases when it's fast vs. when it's slow then what should we look for? We would need something to be able to find anything. So you would try to find out what's different between the two cases, if it can be also reproduced with other guest OSes (Linux, MorphOS) or something similar to be able to get an idea what could cause it. Otherwise we can only guess and have to be very lucky to find a problem that way. AS this seems to be dependent on some changes between boots maybe it's related to memory layout but I still can't find out what could be different. Try at least gather some info from QEMU monitor about the two cases such as info jit info irq and see if there are some differences there or if you can get a memory map or other statisctics from AmigaOS that can be compared then maybe some difference can be identified from those. I can't help with debugging these but I also can't find and fix anyhing in QEMU until the issue is identified a bit more exaclty.
|
|
|
|
|
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
