balaton wrote:@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,
How to check memory? There is memtester on os4depot but it I wonder if the test itself is any good as it can not test the whole memory I suppose. At least not the part already used by the OS and Kickstart.
There is some memory test in CFE, but I never really understand how to make it work for all the installed memory. it just hangs.
Here i am sharing the Part 4 of VHS video of Amiga Deluxe Paint Video titleing Cartoon Style Animations ads overlay on 1990s Indian VHS Movies in Pakistan and India.
They all commercial ads animations are made with Amiga Deluxe Paint Animation Software. So please appreciate the creativity of those hardwork animators in 1990s.
Here is the link of the youtube video part 4, i made from Old VHS tape:
Are you using the RTL driver versions from os4welt.de with the workarounds for the QEmu RTL emulation bugs? The public versions (for real hardware) are unlikely to work without problems.
Yes, I use this driver. It works quite well for my purposes, and I have no complaints about it. But it can also crash. For example, if you start copying a large number of very small files (such as program sources via RNOXfer), the driver will stop working. But I've learned how to use it. Quote:
You may manually have to reduce the MTU/MRU sizes as a router adds some overhead causing packet splits for connections outside of the LAN if you use the max. MTU/MRU sizes supported by your LAN. IIRC MTU path discovery doesn't work or isn't even implemented in RoadShow and the only AmigaOS TCP/IP stack supporting it was the "Deluxe" version of Miami (MiamiDx)
MTU cannot be changed to AOS4 above the value of 1500. Above this value, e.g., 9000, they change to 1500. It is possible to change something using Roadshowcontrol. Changing the tcp.sendspace/tcp.recvspace value to the minimum value with the virtio-net.device driver causes a very quick “TransmitPacket: TX timout ..” error. I don't really know where this comes from and where the value 1000000 comes from.
I tried on the qemu side and with the virtio-net-pci options to limit the RX buffer and speed, but it didn't help. But as I wrote, after the error “TransmitPacket: TX timout ..” appeared, the driver It still works. Something has stifled it.
I have no idea how to quickly clear buffers in AOS4, reset certain things like in Linux. It's hard to find any documentation for AOS4.
The virtio-net.device driver is definitely faster than RTL8139. Maybe the symptoms show up faster, but is that a problem with the early version of the virtio-net.device driver?
@Tuvok Are you referring to being dumped in an AmigaDOS shell? If you're using a KVM switch it may be the KVM switch reporting false initial state of mouse buttons. That may lead AmigaOS to think you're holding down mouse buttons to either enter Early Startup or "Boot Without Startup-Sequence". I have that on my ATEN KVM sometimes. The bootmouse driver has a bios environment variable, "use_mouse_btn_check" you can set to "0" or "no" to disable initial reading of mouse buttons to avoid this specific problem.
@afxgroup Btw. regarding "the Sirion stack's tendency to report the same physical device multiple times at different USB addresses" you mention: Please tell me more. I've never myself experienced anything like this, but if there's some underlying bug there which needs to be fixed in Sirion I'm all ears :)
So it looks like just my x1000 acts like this .. Maybe some power issues or so ..
My X1000 also act a bit strange : not always re-startup (i mean just to X1000 logo) after reset, and i should doing another one. Like it not fully initialized. I remember Raziel (user who were here some time ago) report same ..Do you have this kind of issue ? On serial when i can't boot i usually have:
[HELO][DRAM]
Sometimes mine stops booting too or it just opens a shell and then I have to "reboot fast sync". I can't remember this to happen before update 3. But then I have connected a new SSD and can't go back to previous config to check it.
I will connect the x1000 with 0-modem cable and let you know.
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.
So can ping, telnet, and even something loadup in browser, but, still have some problem with whole thing, awfull pings (sometime good enough like 0.5ms, sometime 1000(!) ms), and so all the data load up like "load fast -> stall for a while -> load fast".
@all 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 ?).
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 ..
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 ..
just in case original linux source code of x1000 driver here:
But it's a little different than RTL8139. Small packets still get through. On RTL8139, access is completely cut off.
Are you using the RTL driver versions from os4welt.de with the workarounds for the QEmu RTL emulation bugs? The public versions (for real hardware) are unlikely to work without problems.
Quote:
The INTERNET speed is poor. You can get some good values on the LAN. Is there a problem there?
You may manually have to reduce the MTU/MRU sizes as a router adds some overhead causing packet splits for connections outside of the LAN if you use the max. MTU/MRU sizes supported by your LAN. IIRC MTU path discovery doesn't work or isn't even implemented in RoadShow and the only AmigaOS TCP/IP stack supporting it was the "Deluxe" version of Miami (MiamiDx).
Quote:
I don't currently know how packets are transmitted through QEMU. QEMU definitely emulates network cards, but what if a guest (AOS4 with an old TCP/IP stack) gets a “large packet” exceeding some limit (10Mb/100Mb/1Gb)? It will try to limit it, but it won't be able to handle it... will it crash?
It's not possible to receive too large packets like jumbo frames, IPv6, or anything else modern not supported by the ancient AmigaOS TCP/IP stacks (nearly all are based on the BSD 4.3 lite TCP/IP stack, incl. AmiTCP, Miami/MiamiDx and RoadShow, only the Commodore AS225 TCP/IP stack with it's socket.library, and some tiny TCP/IP stacks with minimal functionality on Aminet, use other code bases): The max. packet sizes, features supported, etc., are configured by the TCP/IP stack and it's SANA-II device drivers.
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
