Forums - All Posts - The Amigans website

Forum Index

Board index » All Posts (Georg)

Bottom

(1) 2 3 4 »

Georg

Re: What the fastest possible x64 emulation way of OS4 today ?

Posted on: 7/26 9:58 #1

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

Topic | Forum

Georg

Re: What the fastest possible x64 emulation way of OS4 today ?

Posted on: 7/11 7:36 #2

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).

Topic | Forum

Georg

Re: What the fastest possible x64 emulation way of OS4 today ?

Posted on: 7/9 11:14 #3

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).

Topic | Forum

Georg

Re: Is this a glitch or is it normal?

Posted on: 7/2 14:52 #4

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).

Topic | Forum

Georg

Re: Task scheduler

Posted on: 5/25 19:04 #5

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.

Topic | Forum

Georg

Re: Task scheduler

Posted on: 5/23 8:24 #6

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?

Topic | Forum

Georg

Re: ImageFx 4.1 crashes with debug kernel

Posted on: 5/13 17:02 #7

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.

Topic | Forum

Georg

Re: ImageFx 4.1 crashes with debug kernel

Posted on: 5/13 16:53 #8

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.

Topic | Forum

Georg

Re: ImageFx 4.1 crashes with debug kernel

Posted on: 5/13 6:57 #9

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".

Topic | Forum

Georg

Re: NVMe device driver

Posted on: 5/4 14:52 #10

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.

Topic | Forum

Georg

Re: NVMe device driver

Posted on: 5/3 19:29 #11

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 ...

Topic | Forum

Georg

Re: NVMe device driver

Posted on: 5/3 7:48 #12

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.

Topic | Forum

Georg

Re: Lsof AmigaDOS?

Posted on: 4/12 7:27 #13

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?).

Topic | Forum

Georg

Re: Lsof AmigaDOS?

Posted on: 4/11 7:29 #14

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

[...]

#

Topic | Forum

Georg

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).

Topic | Forum

Georg

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)

Topic | Forum

Georg

Re: I like to write graphic-card.chip file of my own, how do I start?

Posted on: 2022/9/30 14:12 #17

Just popping in

On this page

http://wiki.icomp.de/wiki/P96#Hardware_manufacturer_archive

it's possible to download "CardDevelop.lha" which seems to contain headers and sample driver source code.

Topic | Forum

Georg

Re: I like to write graphic-card.chip file of my own, how do I start?

Posted on: 2022/9/27 9:35 #18

Just popping in

68k P96 driver development infos and docs are public since some time:

http://wiki.icomp.de/wiki/P96_Driver_Development

Topic | Forum

Georg

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.

Topic | Forum

Georg

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"

Topic | Forum

Top

(1) 2 3 4 »