Who's Online |
70 user(s) are online ( 41 user(s) are browsing Forums)
Members: 0
Guests: 70
more...
|
|
Headlines |
-
waitfile.lha - utility/script
Mar 10, 2026
-
hwp_mp3enc.lha - library/hollywood
Mar 9, 2026
-
virtio9pfs.lha - driver/handler
Mar 7, 2026
-
iconecta.lha - network/misc
Mar 5, 2026
-
sfront.lha - utility/script
Mar 4, 2026
-
arabic_console_devicepro2.lha - driver/input
Mar 2, 2026
-
amiarcadia.lha - emulation/gamesystem
Mar 2, 2026
-
hwp_zip.lha - library/hollywood
Mar 2, 2026
-
amigadiskbench.lha - utility/benchmark
Mar 2, 2026
-
virtioscsi.lha - driver/storage
Mar 1, 2026
|
|
|
|
|
Re: working virtio-net.device for QEMU : no more issues with rtl drivers !
|
Posted on: Yesterday 20:23
#1
|
Just can't stay away 
|
@kas1e Quote: Why then on all machines include x5000 rtl8139 show no bugs ? Too slow in compare with qemu ? But imho x5000 faster than qemu emulation, shouldnt be issue with too many irqs ? CPU speed probably does not matter here more network speed. X5000 uses different kernel so problem may only be with pegasos2 or with IRQ sharing. If there's a problem with interrupt handling in AmigaOS it could explain a hang. Is it possible to get a stacktrace of a hung driver to see where it stopped? Quote: Also, all in all, we can try non interrupt way for virtionet.device , i mean this busy-waiting/polling by cpu instead of irqs ? I tried it on real x1000 now (i mean non interrupt way) and while have ai bugs it works, and i didnt see lot of cpu loading (if at all) probably because roadshow limited speed anyway .. maybe as test worth of try ? Polling is not an option as it would be very ineffifient so I don't think it's usable. It may only be used to test if the problem is in interrupt handling. With polling if you limit the number of polls to avoid high load it will limit the speed and if you do it too often it will generate constant load even if nothing is transferred. That's why these normally use interrupts which is a better way to handle these async events.
|
|
|
|
|
|
Re: working virtio-net.device for QEMU : no more issues with rtl drivers !
|
Posted on: Yesterday 20:17
#2
|
Just can't stay away
|
@smarkusg Quote: I also don't remember how MorphOS worked with RTL8139 and Qemu. I haven't heard reports from there but I don't usually hear anything from MorphOS people. Not many people use MorphOS with QEMU as you can't register only try the demo and maybe the few who do use it use mac99 with sungem instead.
|
|
|
|
|
|
Re: working virtio-net.device for QEMU : no more issues with rtl drivers !
|
Posted on: Yesterday 20:13
#3
|
Just can't stay away
|
@joerg Quote: Using RTL8139 with QEmu doesn't make any sense, instead you should always try to emulate the simplest hardware as it's less likely to have emulation bugs and emulating simple hardware is usually faster than emulating more complex hardware.
For example NE2000 (rtl8029.device), or if it's supported by QEmu the 3Com (AmigaOne) or VIA Rhine (Pegasos2). There are limited number of cards emulated by QEMU and limited number of cards with AOS4 drivers. The rtl8139 seems to be the only common in both that mostly works. I did not write any of these just used what's already available. There's also ne2k_pci but I don't know what's with that. It seems to work with AROS but others here said it does not work with AmigaOS4. Since no driver source available I have no idea why. Quote: Also very important: Make sure the IRQ used for the network card (emulation) isn't shared with other PCI devices.
Ethernet I/O causes a huge number of IRQs per second anyway, with fast emulation maybe more than the kernel, other parts of the OS or drivers can handle, but if the same IRQ is shared with other PCI devices as well it's nearly guarantied to fail...
It may be a problem on the Pegasos2 which AFAIK uses a single IRQ for all PCI devices, but on the AmigaOne you have 4 IRQs which are freely configurable for each PCI port.
In case there is a problem in the kernel, the TCP/IP stack or the SANA-II drivers handling thousands of IRQs per second it's getting worse with virtio: Less overhead -> more speed -> more IRQs and task switches per second. Amigaone also has specific IRQ mappings, see here so having more than 3 PCI devices could also share interrupts. To use the on-board ethernet card slot you can do -device rtl8139,addr=6 on amigaone which would use the IRQ reserved for this card and avoid potential sharing. I think this was tried before but did not help.
|
|
|
|
|
|
Re: working virtio-net.device for QEMU : no more issues with rtl drivers !
|
Posted on: Yesterday 20:02
#4
|
Just can't stay away
|
@joerg Quote: - The author of the OS4 RTL8139 driver found bugs in the QEmu emulation of it, that's why there were some special QEmu beta version of it. Maybe I missed something but I think he looked at the emulation but could not find anything that's not in accordance with the chip specification so we could not identify anything that could be fixed there. That's why he made changes to the driver instead. I'm not sure what the workarounds added in beta version were but apparently these did not fix all problems. If the problem is not in the rtl8139 emulation or driver (as it's seen with virtio-net too) then maybe no surprise it can't be fixed there. The rtl8139 in QEMU is not the most tested or maintained network card but seems to work with all other OSes apart from AmigaOS so this suggests problem is more likely on the AmigaOS side or in machine emulation not in actual network related stuff. Quote: - It's emulated. If your host has a 1 Gbit or even 10 Gbit ethernet controller that's the speed you get from the emulation as well. With the slow (every packet is copied several times around inside the TCP/IP stack while processing it) and ancient TCP/IP stacks on AmigaOS flooding it with that many packets and IRQs per second is similar to a DDoS attack 
Limiting the host ethernet controller to 10 or 100 Mbit might help, at least while developing a network driver and beta testing it.
If you can't do that on your host computer itself most routers have such an option, usually called "ECO mode" or similar. I'm not sure this would help much as QEMU sends packets through the host OS so it may be taken by host OS before it's sent or packets received could be buffered by host OS so guest might see faster speeds.
|
|
|
|
|
|
Re: x1000 onboard opensource driver in progress
|
|
Just can't stay away
|
@kas1e Quote: when i can't boot i usually have:
[HELO][DRAM]
If it hangs on DRAM did you check if memory is good? What is printed after that when it boots? Maybe check that too, Quote:
Checked x1000's net driver sources for linux, and find out that dma_alloc_coherent() is used all over the places for the all ring descriptors and stuff, but i currently just use AllocVecTags(MEMF_SHARED) just like Neil's prism and atheros5000 drivers do. But as we have no datasheet for pasemi seems so, and linux driver were written by PA-Semi itself (so kind of same datasheet) it mean that if they use dma_alloc_coherent() all over place, then i should for os4 do same too so setup MMU, etc ? I mean dma_alloc_coherent() on amigaos4 mean IMMU->SetMemoryAttrs(MEMATTRF_CACHEINHIBIT) which we can't call from user space (right ?).
To answer that you may first need to understand what dma_alloc_coherent() does, in other word what coherence refers to here and why would that be needed. Quote: I just find it strange that Neil's drivers didn't worry about, and all fine, but there with Pa-Semi on linux they use it a lot .. Maybe it does not matter as long as you only use one core. Coherence may refer to cache coherence between cores but maybe also be for PCI as was the case with graphics cards. That's why you have to find out the above first to get an answer. Quote: I just get strange result for now when packets stalls like busy with something , i.e. ping can be 0.5ms for few times, and then 1000ms few times, same for any other data , it start loads, then stalls for long, then back again. So thinking what can it be .. If this is AI generated code then who knows, could be anything and nobody could guess without trying to make sense of the code.
|
|
|
|
|
|
Re: working virtio-net.device for QEMU : no more issues with rtl drivers !
|
|
Just can't stay away
|
The rtl8139 AmigaOS driver author has looked at it before and also checked the emulation in QEMU and could not find any problem in either of those so it could well be the issue is somewhere else. It could be in AmigaOS common SANAII code or network stack too. That it works on real machines does not mean the AmigaOS side does not have race conditions that do not happen as long as things are slow as on real machine but could break when replies come faster than expected (sometimes instantly) on emulation that may never happen on real machines. It could also be in QEMU's Windows version as that's less tested but since all network cards use the same netdev backends in QEMU and a lot of people use those it should not be completely broken so it's more likely to be either in rtl8139 emulation (which does not seem to be the case), pegasos2 emulation (you could try with other machines to check) or somewhere on the AmigaOS side but not in other parts of QEMU.
|
|
|
|
|
|
Re: QEMU for Windows with working -virtfs ! (yes!)
|
|
Just can't stay away
|
@kas1e
No, that's the point. Image file is like a disk on which you have partitions and virtio-9p is like a network share that you mount. When the kernel boots it reads RDB from disks and looks for a boot partition which it can find with an image and virtio-scsi where the virtio-scsi driver is just like a disk driver otherwise everything is like on real machine with disks but what happens with a virio-9p driver? How does it know which share to mount and how does the kernel know it should boot from that when there's no RDB with partitions and a bootable flag anywhere? With Linux the 9p client is in kernel and there are options to tell it to mount and look for the root filesystem on a 9p share. But is there something similar in AmigaOS kernel or could just a virtio-9p driver provide that? A 9p driver may have an otion to tell it to mount a share but how do you tell the AmigaOS kernel that it should boot from that device if it has no RDB?
The difference between an emulated IDE and virtio-scsi is not in the image file, that's the same but emulated IDE goes through IO and interrupts which is slower than virtio that uses shared memory to communicate with QEMU with less emulation overhead.
|
|
|
|
|
|
Re: working virtio-net.device for QEMU : no more issues with rtl drivers !
|
|
Just can't stay away
|
@kas1e Quote: For one day it was some boring/AI cleaning to just start and make ping 127.0.0.1 to work, then bunch of crashes and issues (of course) of all sort, which were dealt only with Neil's code of drivers, then some debugging as always, and yeah ! So if you managed to clean AI cruft from the virtio part it's time to make that a virtio.library so others don't have to clean the other drivers one by one an won't have this code repeated in all drivers but can all use the same virtio.library so if one driver improves it all the others can benefit.
|
|
|
|
|
|
Re: QEMU for Windows with working -virtfs ! (yes!)
|
|
Just can't stay away
|
@kas1e
Virtfs root works with Linux guest as mentioned in the docs linked before but to boot from it you probably need the kernel to recognise it as a bootable partition and without a partition table that may be difficult. If you can set the root device somehow to boot from that may work. But virtio-scsi should also have similar speed and that should work better as it emulates whole disk with partitions.
|
|
|
|
|
|
Re: Virtio SCSI driver for AmigaOS4.1FE on QEMU
|
|
Just can't stay away
|
On QEMU the only difference between VRAM and MMIO is that one is backed by allocated memory while the MMIO has ops (callbacks) to handle read/write but they both are mapped to PCI memory space the same way so they are no different in that. After trying it I see this:
$ qemu-system-ppc -M amigaone -bios u-boot-a1xe.bin -monitor stdio -virtfs local,path=/tmp/share,mount_tag=share,security_model=mapped-file -S
(qemu) info pci
Bus 0, device 9, function 0:
Class 0002: PCI device 1af4:1009
PCI subsystem 1af4:0009
IRQ 0, pin A
BAR0: I/O (not mapped)
BAR4: 64 bit prefetchable memory (not mapped)
id ""
{qemu} info qtree
bus: pci.0
type PCI
dev: virtio-9p-pci, id ""
disable-legacy = "off"
disable-modern = false
ioeventfd = true
vectors = 0 (0x0)
virtio-pci-bus-master-bug-migration = false
modern-pio-notify = false
page-per-vq = false
ats = false
x-ats-page-aligned = true
x-pcie-pm-no-soft-reset = false
x-pcie-flr-init = true
aer = false
addr = 09.0
romfile = ""
romsize = 4294967295 (0xffffffff)
rombar = -1 (0xffffffffffffffff)
multifunction = false
x-pcie-lnksta-dllla = true
failover_pair_id = ""
acpi-index = 0 (0x0)
x-pcie-err-unc-mask = true
x-pcie-ari-nextfn-1 = false
x-max-bounce-buffer-size = 4096 (4 KiB)
sriov-pf = ""
x-pcie-ext-tag = true
busnr = 0 (0x0)
class Class 0002, addr 00:09.0, pci id 1af4:1009 (sub 1af4:0009)
bar 0: i/o at 0xffffffffffffffff [0x1e]
bar 4: mem at 0xffffffffffffffff [0x3ffe]
bus: virtio-bus
type virtio-pci-bus
dev: virtio-9p-device, id ""
mount_tag = "share"
fsdev = "share"
indirect_desc = true
event_idx = true
notify_on_empty = true
any_layout = true
iommu_platform = false
packed = false
queue_reset = true
in_order = false
use-started = true
use-disabled-flag = true
x-disable-legacy-check = false
(qemu) cont
...wait until firmware inits devices...
(qemu) stop
(qemu) info pci
Bus 0, device 9, function 0:
Class 0002: PCI device 1af4:1009
PCI subsystem 1af4:0009
IRQ 10, pin A
BAR0: I/O at 0x800220 [0x80023f]
BAR4: 64 bit prefetchable memory at 0x81004000 [0x81007fff]
id ""
(qemu) info qtree
class Class 0002, addr 00:09.0, pci id 1af4:1009 (sub 1af4:0009)
bar 0: i/o at 0x800220 [0x80023f]
bar 4: mem at 0x81004000 [0x81007fff]
So the memory BAR is mapped but it's a 64bit BAR which AmigaOS may have problems recognising. On pegasos2 we have some hacks to patch these in the device tree in BBoot so the kernel would see it as 32bit BAR but I don't know what happens on the amigaone. BBoot does nothing about it and the firmware seems to map it but I don't know what AmigaOS kernel does with it and as there's no device tree under U-Boot unlike on OpenFirmware I don't know where could it be patched. But maybe this isn't the problem and there's something else I still don't understand. EDIT: The BARs also show up in Ranger so I think the amigaone kernel has no problem with 64bit BARs unlike the pegasos2 (but I think that's also fixed in unreleased latest version). So it's not a problem with BAR visibility. Then what?
Edited by balaton on 2026/3/8 11:14:29
Edited by balaton on 2026/3/8 11:14:45
|
|
|
|
|
|
Re: My AmigaOs4.1 projects
|
|
Just can't stay away
|
@joerg
Oh, there's a star I did not notice. I think I never needed to redirect stderr on the Amiga so I did not know that.
|
|
|
|
|
|
Re: My AmigaOs4.1 projects
|
|
Just can't stay away
|
@joerg
Then how do you redirect stdout?
|
|
|
|
|
|
Re: QEMU for Windows with working -virtfs ! (yes!)
|
|
Just can't stay away
|
@kas1e
I don't know virtio but I doubt -virtfs would be legacy. According to the docs smarkusg linked (which seem quite outdated but maybe still there's some truth in it) it should be the same as -device virtio-9p-pci which should support both legacy and modern but maybe the driver need to do something to switch it to modern mode or is that the default?
|
|
|
|
|
|
Re: Virtio SCSI driver for AmigaOS4.1FE on QEMU
|
|
Just can't stay away
|
@derfs
I don't understand that explanation. Can you explain it or is it just what the AI generated? The sm501 has the whole vram memory mapped and you can certainly read and write it on both amigaone and pegasos2 so this should fundamentally work. If it doesn't there must be some other reason but I don't understand what.
Using legacy virtio devices is not recommended because they may be dropped in next release or soon after. You should really fix the driver to work with modern virtio.
One thing that modern virtio is different from legacy is that it's always little endian so more than byte access may need endian conversion. Is that handled in your driver? But if it works on pegasos2 it probably does. While the Marvell and Articia may have bits to do endian swap they are not emulated, you should get a log message with -d unimp,guest_errors if you try to use it. So the driver needs to handle it.
|
|
|
|
|
|
Re: Virtio SCSI driver for AmigaOS4.1FE on QEMU
|
|
Just can't stay away
|
@kas1e
If you want the virtual machine to appear on your network you still need TAP. If you just want to access a port like ssh into the guest you can use port forwarding with user/slirp. There's also an alternative to slirp called passt which is the modern way with more features but I don't know it. In QEMU the -device is the guest side part and -net is the host side so it works the same on the host side independent if you use -device rtl8139 or -device virtio-net which just sets what card the guest sees. Once the packets reach QEMU it's the -net option that decides where they go.
|
|
|
|
|
|
Re: Virtio SCSI driver for AmigaOS4.1FE on QEMU
|
|
Just can't stay away
|
@derfs Quote: I need to get the PCI-setup working for all machines without having to change the qemu device parameters but MMIO only works for pegasos2 which means I have stayed with legacy virtio for amigaone. Why is that? MMIO should work with amigaone too. Isn't it just a memory mapped BAR that should show up in the PCI window? Or does it need something else that pegasos2 has and amigaone lacks?
|
|
|
|
|
|
Re: Virtio SCSI driver for AmigaOS4.1FE on QEMU
|
|
Just can't stay away
|
@kas1e
As you see virtio is a whole family of devices that all use the same primitives to communicate with QEMU so if you make drivers for them you'll end up with duplicated code in these drivers that's best put in a library. Not only to make the drivers smaller but also to avoid having to fix the same bug in multiple drivers or have different bugs in different drivers. So you should really make the common part a virtio.library then base all drivers on that. That way improving the library would also improve all drivers without having to touch them.
|
|
|
|
|
|
Re: Virtio SCSI driver for AmigaOS4.1FE on QEMU
|
|
Just can't stay away
|
I don't know anything about these virtio devices but what is with the compatibility with different machines and new and old virtio? These should work the same on all machines. I guess this may be because these drivers (as most AmigaOS drivers) do nothing to configure the device and different firmwares configure it differently so if you just try to use it that way it may not work. I guess the driver should set up the device the way it needs (likely current virtio with memory mapped BAR) and not rely on the firmware to do it.
|
|
|
|
|
|
Re: QEMU for Windows with working -virtfs ! (yes!)
|
|
Just can't stay away
|
@kas1e
Of course you can't set Amiga protection bits on non-Amiga filesystems the same way you can't set Unix protection bits on FAT because there's no place to store it. But I wonder how are the protection bits stored on the install ISO? Maybe there's a mapping to Unix bits that's stored in RockRidge extensions? But even with that you may get problems on Windows where you don't even have Unix bits on a Windows filesystem.
|
|
|
|
|
|
Re: New to Sam460ex
|
Posted on: 12/20 22:22
#20
|
Just can't stay away
|
@jabirulo
Yes but 2015.d does not work with QEMU at all for some reason and I did not have time to find out why (maybe it now accesses something that's not emulated but I don't know what) so I went with the 2015.c version that works and should have all the fixes that are relevant for QEMU. The changelog for 2015.d only says that you can select between EHCI and OHCI but does not mention other USB fixes. It also only seems to be a problem with AROS, AmigaOS4 still works on QEMU with 2015.c U-Boot so it could also be an AROS issue. I'm not sure AROS works on real machine as nobody tried or replied with results so far.
|
|
|
|
|
|
News feed
OS4 Feedback forum
OS4Depot Feedback 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
