Who's Online |
72 user(s) are online ( 62 user(s) are browsing Forums)
Members: 1
Guests: 71
rjd324,
more...
|
|
Headlines |
-
amiarcadia.lha - emulation/gamesystem
Sep 25, 2023
-
soniccd-rsdk.lha - game/platform
Sep 25, 2023
-
avalanche.lha - utility/archive
Sep 25, 2023
-
gifanimdt.lha - datatype/anim
Sep 22, 2023
-
giflib-extras.lha - development/library/graphics
Sep 22, 2023
-
dtconvert.lha - utility/filetool
Sep 22, 2023
-
libx264.lha - development/library/misc
Sep 20, 2023
-
amissl-sdk.lha - development/misc
Sep 20, 2023
-
mce.lha - game/utility
Sep 20, 2023
-
amissl.lha - library/misc
Sep 20, 2023
|
|
|
|
Re: What the fastest possible x64 emulation way of OS4 today ?
|
|
Just popping in 
|
@joergQuote: Additionally to per task CPU usage my "top" tool displays the number of IExec->SuperState() calls per second, i.e. the number of switches from user to supervisor mode and back per second, and if that's a very high number there is definitely a problem (maybe not QEmu related, can be kernel or AmigaOS hardware drivers, or even user software, related as well).
There are cases where you can get unexpected high number of taskswatches in AOS or clones even if there's no problem (assuming problem = bug). For example when multiple tasks use the same semaphore a lot (for example it could be some memory allocation lock, or something gfx related like OwnBlitter()) and ~"bad luck" causes the semaphore to get in what I call "pingpong state". If you ran a test program like this:
for(;;)
{
ObtainSem sem;
dosomething();
print taskname;
ReleaseSem sem;
}
two times, then you would expect/hope to get output like this:
task1
task1
task1
task1
...
task2
task2
task2
...
But sooner or later it will get into ping pong state and then output will be:
task1
task2
task1
task2
task1
task2
task1
task2
...
Happens when one of the test programs gets preempted while holding the semaphore. From then one at every ReleaseSem() time there will always be the other task in the wait queue causing switch to this other task (when thistask calls ObtainSem()).
Edited by Georg on 2023/7/26 14:13:39
|
|
|
|
Re: What the fastest possible x64 emulation way of OS4 today ?
|
|
Just popping in 
|
@Hypex Quote: ...
01947B7C: 4E800020 blr 01947B80: 5469103B rlwinm. r9,r3,2,0,29 01947B84: 7C832378 mr r3,r4 01947B88: 4D820020 beqlr- >01947B8C: 8069000C lwz r3,12(r9) 01947B90: 4E800020 blr 01947B94: 9421FFE0 stwu r1,-32(r1) 01947B98: 7CA802A6 mflr r5 01947B9C: 90A10024 stw r5,36(r1) 01947BA0: 93A10014 stw r29,20(r1)
...
It destroys r3 by moving r4 into it to test but r3 should have been 0x2963703B before that. And then this:
I don't really know or want to know PPC asm (it's sooo ugly), but after a bit of google'ing, maybe the "beqlr" tests r9, because the "." suffix causes the rlwinm to update condition registers while no such suffix used for "mr" instruction, so condition registers does not change after that. Quote: It falls through and executes the next instruction.
Theoretically you can't be sure that the execution sequence was as shown in the disassembly above (rlnwim -> mr -> beqlr -> lwz -> crash). Could also be (even if unlikely) a jump from somewhere else to 01947B8C (the lwz instruction).
|
|
|
|
Re: What the fastest possible x64 emulation way of OS4 today ?
|
|
Just popping in 
|
@joergQuote: joerg wrote:@kas1e
... but it doesn't disable the interrupt ...
Maybe there's something wrong with irq disabling/enabling. Passthrough IRQs being ~"delivered"/~"executed" by qemu even when guest OS did do those things it does, to set the computer/hw/irq controller/whatever to a state which prevents that (on real hw).
|
|
|
|
Re: Is this a glitch or is it normal?
|
|
Just popping in 
|
Looking at the grab, random wild guess: concurrent access to same rastport / tmpras (if antialiased font rendering in AOS4 uses that or a similar buffer connected to rastport). Like if app and Intuition (input.device task) were rendering to same rastport (maybe some rp cloning missing or optimized away?) at the same time and access to tmpras (or similar buffer) is outside or before other concurrent access protection (like layer locking).
|
|
|
|
Re: Task scheduler
|
|
Just popping in 
|
@joergQuote:
@Georg Quote:Wouldn't it make sense to make AllocVecTags() itself simply auto-change it's defaults to wait=false and noexpunge if it finds itself being called by someone in forbid and/or disabled state? No.
Why not. Note that I said "auto-change *defaults*". AllocVecTags() caller would still be able to override it. I know there are times/cases where one intenionally and correctly (not bug) wants to (or even has to) go into forbid/disabled state and then calls something which breaks that foribd/disabled state.
|
|
|
|
Re: Task scheduler
|
|
Just popping in 
|
Quote: joerg wrote:
tasklist.c example code in the wiki is completely broken, it's using IExec->AllocVecTags() without AVT_Wait,FALSE and AVT_NoExpunge,TRUE inside Disable()!
Wouldn't it make sense to make AllocVecTags() itself simply auto-change it's defaults to wait=false and noexpunge if it finds itself being called by someone in forbid and/or disabled state?
|
|
|
|
Re: ImageFx 4.1 crashes with debug kernel
|
|
Just popping in 
|
Quote: Fortunately, the Grim reaper allows the user to "Ignore DSI Errors" Okay, if it is a real bug of accessing ln_Succ after Remove(). But if it isn't (the user doesn't know) then some code supposed to be executed on maybe all list's node isn't being done as the ln_Succ Poking by Remove() prevents that.
|
|
|
|
Re: ImageFx 4.1 crashes with debug kernel
|
|
Just popping in 
|
@joerg Well, but then basically you break backwards compatibility with older code which may rely on the fact that previously Remove was known and sort of documented not to modify ln_Succ/ln_Pred. Accessing ln_Succ/ln_Pred is/was not automatically a bug. It could still be correct/non-broken/non-crashing code, maybe something like this (of course not doing it like this is always better).
node = list->lh_Head;
while (node->ln_Succ)
{
Remove(node);
/* do something (but not dealloc node) */
node = node->ln_Succ;
}
So there will be code out there in the wild accessing ln_Succ/ln_Pred which is really buggy, but also code out there in the wild accessing ln_Succ/ln_Pred which is not buggy at all. I don't know the ratio. But you now will get this crash/DSI thing, which sometime may "prevent disaster" and sometime just be a false alarm or maybe even "create disaster" as the formerly safe code no longer can traverse through the whole list as ln_Succ/ln_Pred after Remove() no longer points to the (former) next/previous node.
|
|
|
|
Re: ImageFx 4.1 crashes with debug kernel
|
|
Just popping in 
|
@tonywQuote: It just shows what sloppy code we got away with back in those days. In this case, accessing the Prev/Next pointers in a node that has just been removed from a list. Another frequent coding error ... Actually it is not necessarily a bug/coding error. Docs do not say that accessing Prev/Next after removing from list is forbidden (for example on a private list, not some shared msgport list like window userport) and furthermore the internal implementation of list functions is exposed in assembly header "exec/lists.i".
|
|
|
|
Re: NVMe device driver
|
|
Just popping in 
|
@geennaamQuote: geennaam wrote:@Georg
You are right. It's indeed using UNIT_VBLANK.
Yeah, but thinking again about it, GetSysTime()/TR_GETSYSTIME probably is always the same no matter what unit. Especially GetSysTime() as it would not get the unit as parameter. And it's unlikely that TR_GETSYSTIME behaves differently.
|
|
|
|
Re: NVMe device driver
|
|
Just popping in 
|
@geennaamQuote: geennaam wrote: But a microseconds resolution is sufficient to time these kind of transfers. If it uses UNIT_VBLANK it will not have that resolution ...
|
|
|
|
Re: NVMe device driver
|
|
Just popping in 
|
Looked around a bit in filesysbox sources, and it's a bit suspicious that it has a 100 ms timer (FBX_TIMER_MICROS) and in FbxHandleTimerEvent() it then may possibly call FbxFlushAll(). Susicious because 500 and 400 is multiple of 100.
|
|
|
|
Re: Lsof AmigaDOS?
|
|
Just popping in 
|
@joergQuote: for example the funny AROS file system API 🤣
Was removed and replaced with std. AOS classic packet filesystem API long ago. Quote: the AmigaOS 4.x dos.library did that as well - but using a better solution. It's easy to get into trouble when trying to replace something old/bad even if intentions are good. For example are there rules in the "better solution", when filesystems now run stuff in app task which used to run in filesystem task, for things like signal/msgport alloction (app is allowed to theoretically use up all the dynamically allocatable ones). Or stack usage? Are filesystems now supposed to check for potential low free stack and then stackswap?).
|
|
|
|
Re: Lsof AmigaDOS?
|
|
Just popping in 
|
@joergQuote: joerg wrote:@Capehill Hosted versions like the Linux one even more so, AFAIK the AROS tasks are simply host tasks in such hosted versions (for example Linux tasks), i.e. there is 0% compatibility to any AmigaOS exec task scheduler.
No, that's wrong. Linux does not see or know about Exec tasks inside AROS hosted. Everything is still basically the same as AROS native. What AROS hosted does is to basically emulate/implement interrupts using Unix signal handlers. And for task switches in the Unix signal handler it simply pokes the sigcontext (containsing cpu/fpu context state) structure, so that after the return from the signal handler, the Linux process "AROS" continues executing code from a different AROS Exec task. A bit like early Linux user lever threading libraries. Disable()/Enable() for example then works by simply blocking/unblocking Unix signals. Quote: The big advantage of hosted AROS versions is that they don't have to implement any hardware drivers, they can simply use the ones of the host OS instead.
Btw, it's really "can use", but does not mean "has to use" at the same time. Some native gfx drivers were developed under hosted version. Btw2: there are several other big advantages. It "boots" extremely fast, takes up almost no host cpu time/resources. You could run big number of instances at the same time ( https://vimeo.com/191163338 - each blue amiga-style window appearing is a newly booted/running AROS instance, running intermixed with Linux windows). Then if you run one (big) program in once instance, and other (big) programs in other instance, you basically get some kind of memory protection/resource tracking/etc. for free. You can do symbolic debug of the whole OS including all system libs/tasks and app tasks/libs with gdb, as if it was one single application.
// run AROS through gdb, later press ctrl-z
(gdb) p IntuitionBase->ActiveWindow
$4 = (struct Window *) 0xe9429c10
(gdb) watch IntuitionBase->ActiveWindow->LeftEdge
Hardware watchpoint 1: IntuitionBase->ActiveWindow->LeftEdge
(gdb) cont
Continuing.
Thread 2.1 "AROSBootstrap" hit Hardware watchpoint 1: IntuitionBase->ActiveWindow->LeftEdge
Old value = 353
New value = 316
DoMoveSizeWindow (targetwindow=0xe9429c10, NewLeftEdge=316, NewTopEdge=207, NewWidth=318, NewHeight=340, send_newsize=0, IntuitionBase=0xe8b3fee0) at /home/georg/aros/arosdeadwoodaltabiv0/AROS/rom/intuition/./inputhandler_actions.c:445
445 targetwindow->TopEdge += pos_dy;
(gdb) thistask
Task SigWait SigRecvd StkSize StkUsed Pri Type Name
-----------------------------------------------------------------------------
0xe8b31640 0x3f0000 0x400000 51200 832 20 1 input.device
(gdb) bt
#0 DoMoveSizeWindow (targetwindow=0xe9429c10, NewLeftEdge=316, NewTopEdge=207, NewWidth=318, NewHeight=340, send_newsize=0, IntuitionBase=0xe8b3fee0)
at /home/georg/aros/arosdeadwoodaltabiv0/AROS/rom/intuition/./inputhandler_actions.c:445
#1 0xe7a5cd42 in int_movewindow (msg=0xe8b3d9a0, IntuitionBase=0xe8b3fee0) at /home/georg/aros/arosdeadwoodaltabiv0/AROS/rom/intuition/./movewindow.c:89
#2 0xe7a869b5 in DoASyncAction (func=0xe7a5ccb3 <int_movewindow>, msg=0xe8b3d9a0, size=32, IntuitionBase=0xe8b3fee0)
at /home/georg/aros/arosdeadwoodaltabiv0/AROS/rom/intuition/./inputhandler_actions.c:653
#3 0xe7a5ccb0 in Intuition_28_MoveWindow (window=0xe9429c10, dx=-37, dy=-1, IntuitionBase=0xe8b3fee0)
at /home/georg/aros/arosdeadwoodaltabiv0/AROS/rom/intuition/./movewindow.c:75
#4 0xe7a7db79 in __inline_Intuition_MoveWindow (__arg1=0xe9429c10, __arg2=-37, __arg3=-1, __IntuitionBase=0xe8b3fee0)
at /home/georg/aros/arosdeadwoodaltabiv0/alt-abiv0-linux-i386-d/bin/linux-i386/gen/rom/intuition/intuition/include/inline/intuition.h:366
#5 0xe7a7f2e8 in DragBarClass__GM_GOINACTIVE (cl=0xe8b69fa0, g=0xe8b6a10c, msg=0xe8b3daf0)
at /home/georg/aros/arosdeadwoodaltabiv0/AROS/rom/intuition/./windowclasses.c:886
[...]
#
|
|
|
|
Re: Does AOS4 continue to keep the pointer to Exec library at address 0x4?
|
Posted on: 1/26 13:44
#15
|
Just popping in 
|
@tonywQuote: tonyw wrote:@rjd324 So you must have the address of exec.library first of all.
Since it can change at any time (could be loaded in a different place since it's not in ROM any more), the address is stored in a known place, ie 0x4. It's always possible to write things in such a way that this is never necessary. Libraries/Devices get SysBase as param in init call and can store it somewhere else for future use. Similiar thing when creating new processes. There's always some way to pass knowledge about SysBase along. In AROS/hosted for example there is no SysBase at 0x4. Instead trying to access that address causes segfault (AROS/hosted is really just a normal linux process/program but still 99% identical to the native version).
|
|
|
|
Re: Qt 6 progress
|
Posted on: 1/13 15:29
#16
|
Just popping in 
|
How much sense do this funny shared objs make anyway, with something as big as the QT libs? They are not really shared anyway in most important place (memory), only in least important place nowadays (disk). Only advantage is, that if new version of libs come out, the exe using them does not need to be re-linked statically.
How big is a simple QT gui sample program if linked statically? Size in memory will be somewhat similiar.
If you have same sample program but linked with shared objects then complete huge (I guess) QT shared objs used by program will end up in memory. If some stuff in the shared obj is referenced. Unlike static linking where parts (.o files) in the lib which are not needed do not end up in exe and later in memory. And if you start program twice or have other QT programs running then each will have their own copy of huge (I guess) QT shared objs in memory.
I think ... (I'm no AOS4 guy)
|
|
|
|
Re: System crashes in loop
|
Posted on: 2022/6/22 7:43
#19
|
Just popping in 
|
@RazielQuote: Raziel wrote:@LiveForIt The infamous "soft reboot gfx card crash", see also here for some more detail.
Nothing can be done about it... is being said ... but has anyone ever tested this under Linux? I never tried but it seems to be actually possible to have an Amiga-like soft-reboot in Linux using kexec or kexec-reboot. So nothing goes through hardware/BIOS/whatever initialization. Also in Linux and other OSes you have virtual machines which allow gfx card pass through. Starting/quitting/restarting virtual machine would then for the gfx card be like a soft reboot, where it is not re-hw-initialized in BIOS/whatever. If "nothing can be done about it", it would mean you could start virtual machine only once and second and future starts it would fail, too.
|
|
|
|
Re: Why call to or any "empty" functions cause different results of the other code execution ? FIXED!
|
Posted on: 2022/3/12 17:24
#20
|
Just popping in 
|
@Daytona675xQuote: @kas1e As I said: there's no word about that in the OpenGL ES 2 specs (unless I'm totally blind). So an implementation may chose whichever ID generation algorithm it may like.
I'm not sure and I don't know OpenGL but https://www.khronos.org/registry/OpenG ... /2.0/es_full_spec_2.0.pdf in chapter "2.10.1" says: "The name space for shader objects is the unsigned integers, with zero reserved for the GL. This name space is shared with program objects"
|
|
|
|