@white
With openssh all this including hostfws should not be necessary if you use ssh -Y or ssh -X but you may need to enable X11Forwarding in the sshd_config on your host machine then ssh with -Y or -X option will forward port 6010 to 6000 and set up xauth and DISPLAY itself so you don't need to do all the steps by hand and in that case you also not need hostfwd only -netdev user. If you don't use ssh X11Forwarding then you do the same by hand as above. These are two alternatives that should not be mixed, either do one or the other.

@white
[quote]
2)SSHTerm=IP user=white
3)password OK (I'm inside the terminal)
4)export DISPLAY=:10
5)xhost
access control enabled, only authorized clients can connect
YES:localuser:white


launch:
Firefox or FFPlay

is I get:
Invalid MIT-MAGIC-COOKIE-1 key
Error: cannot open display: :10
[/qiote]

so this means network part is now sorted but you need to set up X authentication to allow client to connect your AmiCygnix screen. The easiest but least secure is to just disable authentication in AmiCignyx that you have to do in guest not in the ssh window so _before_ you run SSHTerm do xhost + still on the AmiCygnix side to allow anybody to connect. If you want to do this more properly and securely search for the Invalid MIT-MAGIC-COOKIE error message and find some docs on how to use xauth to set up X authentication.

@MartinW
All PCI devices are mapped to IRQ 9 and AFIAK this is also how it is on real machine so maybe we have some problem with emulating the interrupt controller or the AmigaOS driver for it expects something that works differently on real hardware. That's why I'm interested if this can be reproduced with Linux because then we may understand better what is happening or if Linux works it may be AmigaOS specific.

@derfs
I see nothing at the qtext.io link.

@derfs
Not sure that using VGA and x-vga=on together is a good idea as both of those would use the same ports so just forget VGA and use bochs-display,romfile="" instead. This probably does not matter for the freeze though. To me that sounds like maybe something with shared interrupts as all PCI devices use IRQ9, this is how the firmware sets it up so maybe that's expected but I'd like to see output from real machine to check that. Can the same freeze be reproduced with Linux? It seems to happen when using multiple PCI devices such as network, usb, sound and a passed through card. I don't know however how to find more about this, I hope Linux may give us more info or at least be able to debug better with that as we have the sources to check.

Also including info qtree, info registers and info irq output from QEMU monitor at the hang may have some more info about the state of the machine so try to get that. You can use -serial mon:stdio and switch between serial of the quest and QEMU monitor with Ctrl-A c

@kas1e
Yes just cat /proc/interrupts should be enough (there's also /proc/ioports and /proc/iomem but not sure if that has anything useful but while you're there you could ge those too).

echo >/dev/ttyS0 should work but maybe you need to make sure you use the right baud setting, check dmesg | grep serial to see what it set or around those lines in dmesg. Maybe you can use " /failsafe" io even on real peagsos to set console to serial before boot and then maybe the Linux output will be on serial too at least that happens on QEMU but maybe because it does not recognise video).

@joerg
Quote:
At least Linux displays info in text which is easier to handle than Ranger or can you get a text report that you can easily post with ranger? Also Linux may give error messages in log, we have its source to check what is happening if a problem can be reproduced with Linux. And finally it's not irrelevant because we don't emulate AmigaOS but emulate pegasos2 so if we can find a difference between real machine and emulation under any OS that helps to improve emulation (even for AmigaOS).

Also I don't know what shell PCI tools are available for AmigaOS so if you have more info on those that might help.

@kas1e
You don't need to install Linux just boot a live CD or rescue system and get the info needed which should not need a full install. I don't know what's the best distro but I think this should at least boot with 'boot install/pegasos':
https://cdimage.debian.org/cdimage/archive/8.11.0/powerpc/iso-cd/ I used the netinstall CD for testing, select rescue in boot menu then you either go through the questins it asks just accepting defaults or Tab to the Back button then select run a shell from the menu (or somthing similat, I write from memory).

@MartinW
I don't know if it would help with interrupts and it's possible something is wrong with interrupts still after trying to fix this in QEMU 8.0. Before that PCI interrupts did not work at all for pegasos2. The firmware configures all PCI devices to use IRQ 9 but don't know what it does for the AGP port or if that's wired up correctly at all. Somebody needs to test this and maybe getting lspci -v and /proc/interrupts contents from a real pegasos2 under Linux and comparing that to emulated machine might help to see if there are any differences.

@kas1e
Can you boot Linux on real pegasos2 and get lspci -v and /proc/interrupts from it?

@white
Almost there but still not doing what I said. With -netdev user,hostfwd like in the second attempt in the video in pos #6 but you should use export DISPLAY=localhost:10 in the ssh window. Some explanation:
- you can't accesss 10.0.2.15 from your host as that's behind the user/slirp NAT, that's why we use hostfwd to forward localhost:5010 to port 6000 of the guest and since 6010 corresponds to display 10 you'd use DISPLAY=localhost:10 but this will be forwarded to guest port 6000 so it's the same as :0 in the guest but accessed as localhost:10 from the host. If you set display to :0 on host it will connect to local display as seen in the second video.
- Ping doesn't work with -netdev user, this is mentioned in the QEMU docs so don't use that for testing
- If it still does not work with hostfwd and DISPLAY=localhost:10 it may be a problem with failed authentication that you can disable in AmiCygnix shell with xhost + but that allows everybody who can access the forwarded port to connect.

@MartinW
Or alternatively to using addr you could connect the gfx card to the AGP port/other PCI bus with -device vfio-pci,bus=pci.0 where it is alone as other devices are on bus=pci.1 so it won't change when addding devices to other bus. The memory windows for pci.0 are different so you have to cahnge the numbers once but then they should be stable. Using pci.0 for the gfx card also matches real machine better and may fit larger BARs as you won't share the memory window with other cards.

@MartinW
If you want to make sure a device always have the same address you can add addr property to the -device command line such as -device vfio-pci,addr=2 to make sure it won't change when adding more devices. If you don't specify any address QEMU will pick a free one.

I can't help with debugging the hangs, it's more a problem of how to debug AmigaOS and not much different from debugging a hang on real hardware except that with QEMU you can inspect the machine state from QEMU monitor such as info registers info irq and some other things or even attach a debugger for more detailed analysis but if you don't know what to look for then that's not much help and to know what to look for knowledge about AmigaOS is needed not knowledge about QEMU.

A hang might be related to interrupts not delivered as expected so maybe that's where we need to check it, I hope you're using the latest QEMU version for this, at least 8.0 or even better QEMU master just to make sure we're not debugging a problem that was already fixed. It might also be possible that the network card driver has a bug that does not happen on real hardware because for example there are delays there but the emulated card is much faster so events may happen that trigger a bug not otherwise seen on real machine. Or some registers behave a bit different than the driver expects or whatever, it's impossible to guess without being able to find out what's happening which should point in the direction what could cause the issue. So some help from somebody who can debug such issues on real hardware could help to debug the same on emulated hardware as the debuggging itself is no different.

@joerg
Also QEMU emulates a lot of systems and all of them can use rtl8139. While it may not be the default and because of that less tested it should work with all other guest OS drivers in Windows, linux and I know people used it with MacOS on qemu-system-ppc too so then it's more likely to either something with AmigaOS driver or with the pegasos2 emulation than the rtl8139 emulation.

@geennaam
To debug the DMA issue further maybe we would need at least this info:
- command line you used to start qemu
- the output you got
- info mtree and info pci output after booting AmigaOS where the errors happen.
I know you've posted these before but never all of them from one run so I have some command lines but don't know which one used when saw the errors (in particular did you have VGA or not x-vga or not, if you still using VGA and x-vga=off then I believe that's an invalid config that can't work because the card ROM can't talk to the VGA part of the card that way). And bacause of the previous ambiguities I don't know if for example vga parts shown in an info mtree output comes from where.

Since x-vga does not work with older Radeons you can't use that so you should try without x-vga but also not adding VGA and see if the driver can init the card. If that does not work then try fixing x-vga so the card's VGA regs show up in the guest. I don't think other way might work. What I think might be happening is that unlike the RadeonHD/RX driver the Radeon driver can't init the card because these cards predate AtomBIOS so there's no other way to do the init than running the card ROM. The card ROM can't run because it may need the VGA regs that x-vga would solve but that needs to be fixed. You were able to get past the ROM by adding VGA device but that results writes to VGA regs go to the emulated VGA card and writes to PCI regs go to the passed through card and if writes to VGA regs are also needed to propetly init the card then this won't work until x-vga is fixed. Fixing that may not be that hard if all it needs to do is to use BAR1 for the io BAR instead of BAR4 so you may try that for testing even if it breaks HD cards then if that works come up with a patch that works with both. Hope this makes sense and I could explain what I think.

@Maijestro
You can get more info from QEMU on what the driver tries to do with -trace enable="ne2000*" then find some docs of RTL8029 and try to make sense of the communication and see if some error can be spotted there. This could be easier if the AmigaOS driver source was available but it could be similar to other open source drivers for this card like that found in some BSD unices. QEMU emulates a generic NE2000 which the the RTL8029 should be compatible with but maybe the Realtek device has some peculiarity that the driver expects but QEMU does not emulate. If we find what is that it might be added to QEMU.

@MartinW
Also I think later @geennaam said the sam460ex worked with an HD card but was too unstable but maybe I've lost some of the info. I don't know what unstable means though and now I wonder if it could be the same network issues that you saw which would mean it may be related to rtl8139 emulation or the AmigaOS driver for it. We'd need more info about these to understand it better.
The primary goal for now is probably the pegasos2 because sam460ex is slower due to different CPU in that so those who can should use pegasos2 now but for completeness and to have an alternative I'd like to also improve sam460ex eventually if time allows.

@kas1e
radeon9250 does not have 64 bit BARs so all this is not needed for that. If you connect an HD card with a PCI to PCIe bridge to the PCI bus that will show up in /pci but your AGP card is on the other PCI bus. Try ls / and check the other bus which may be /pci@80000000 or something where display should show up.

@MartinW
About sam460ex and DMA errors, I assume you tested that with passed through card connected as PCI as PCIe does not work at all at the moment because of missing memory windows as wrote above. I'm aware of that. Then that probably means 64 bit BARs is not a problem on sam460ex maybe because it has to handle it for PCIe cards too. So that also means the AmigaOS kernel can handle 64bit bars just not in the version for pegasos2. So code is there and maybe could be fixed for pegasos2 too within AmigaOS in an update if they wanted to do that but we can patch it at the firmware before AmigaOS loads so we can work around that.
I'm not sure what the DMA errors mean although I've seen these logs before we did not know at that time where this problem could come from. Now that same cards works with pegasos2 it probably is related to sam460ex emulation then. What's the command -device option used to passed through the card and what shows in QEMU info mtree and info pci after booting?

@MartinW
Quote:
Just for correctness BAR stands for Base Address Register so it's really the config register that configures these regions but since they are closely related often the regions are just called BARs too. These can be either in memory space or io space but on PPC they'll all end up mapped somewhere in memory because PPC does not have io like x86 in/out ops so these will just be mapped either in memory window or io window of the PCI bus where the card is connected. (Or even more correctly they are mapped to the memory or io space of PCI and the windows in system memory provide a view to part of those PCI spaces.) Those windows are configured in the PCI bridge and this is what's not emulated correctly for the sam460ex PCIe controller currently and that's why the card connected to there does not show up.

I'll eventually fix PCIe emulation for sam460ex but after this testing with pegasos2 I wonder if the same could work with sam460ex? But I don't know how u-boot handles these BARs and if there's a way to patch that from u-boot prompt. It may be in the device tree passed from u-boots so not sure that can be patched the same way as it's possible with OpenFirmware. As u-boot for sam460ex is open source it can be patched there but I don't think I should break the distributed ROM image too much for this. But if somebody really wants to experiment it should be possible to build the ROM for sam460ex in QEMU sources after git submodule init roms/u-boot-sam460ex; cd roms; make u-boot.sam460 but it needs a ppc cross compiler.

Just to test this is the case, what shows with an HD card conneected to PCI bus with QEMU sam460ex? Does it have missing BARs like with pegasos2 so it may be the same 64 bit BAR issue? If enabling debug logs does the same Cannot handle SS=3 message show up? The proper fix for sam460ex would be to emulate the PCIe controller correctly which is a bit difficult without documentation but not impossible and eventually will do so maybe not worth patching the sam460ex firmware for this.

@MartinW
If there's no rom contents then it probably does not matter if there's a ROM area listed or not as it will also need the rom data not only the BAR so does not matter if romfile="" only disables loading the ROM or also the ROM area. If you look at the numbers in the .properties output the 3rd one is the BAR offset, the ROM BAR is 0x30 while BAR0 starts from 0x10 and each reg is 4 bytes so BAR1 is 0x14. With 64 bit BARs using 2 32BARs so if you have 64 bit BAR0 then you can't have BAR1 only BAR2 at 0x18.

Edit: That's why these newer cards moved the IO regs BAR from BAR1 to BAR4 which is causing problems with the x-vga=on option so this is what needs to be fixed for older Radeons that @geennaam tried with the 9250 as that driver may depend more on the card ROM than the newer ones. I'm not sure when the AtomBIOS that the drivers can parse was introduced, it's mentioned for HD2000 here: https://en.wikipedia.org/wiki/Radeon_HD_2000_series so cards before that may need the ROM to run but later probably just need the BARs to be visible for AmigaOS and apparently AmigaOS is not prepared to handle 64 bit BARs but fi they are shown as 32 bit and fit in 32 bit space then it should be OK.