Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
27 user(s) are online (21 user(s) are browsing Forums)

Members: 0
Guests: 27

more...

Headlines

Forum Index


Board index » All Posts (MigthyMax)




Re: Command "Dir" 54.5 (c) 2022 AmigaKit, command not working from AUX:
Just popping in
Just popping in


@LiveForIt

I added

Quote:
newshell aux:


to my user-startup too, but hwo does it help with

Quote:
gfx is lockuped up.. (its also useful for copy & paste.)


I don't see an effect or differnce after a reboot. Shouldn't there pop up somewhere a shell additional to the workbench?

Go to top


Re: SDK 54.16
Just popping in
Just popping in


@walkero

Quote:
I actually have one for personal use. The thing is that if something is going to be released by someone has to have some minimum standards, i.e. that the libs are created for both clib2 and newlib, they pass all the tests that are possible to pass etc. To do that you have either to do it yourself for all these libraries, or the people who port them have to follow those standards. Again a big task to do, but if anyone would like to step up for it would be awesome.


Would it be smart to just document that, what a developer hast to fulfill, to make as easy as possible for you to include it in the SDK. Including the test cases, because there might more than me that have no clue what actually a linked library an AmigaOS has to "support" be be best usable by other developers.

Go to top


Re: Porting to AmigaOS4 thread
Just popping in
Just popping in


@Raziel

In your case, you have to migrate the code to use the now official method to create an IORequest

timerio IExec->AllocSysObjectTags(ASOT_IOREQUEST,
  
ASOIOR_Sizesizeof(struct IORequest),
  
TAG_DONE);


and for freeing (deleting)

IExec->FreeSysObject(ASOT_LIST,(APTR)timerio );


For MsgPprt it's the same pattern, like ASOT_PORT.

The issue with the TimerIFace, i have no currently no clue

Go to top


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


Documentation how a gfx driver could be developed would be great.

Go to top


Re: RadeonHD V.5 driver
Just popping in
Just popping in


@Spectre660

Quote:
By the way are any X5000 users planning to purchase the RadeonHD 5.x driver ?


If i decoded all product/technical names correctly, i think i have a FGX card which benefits from the driver. So yes, I'm going to buy it, if I'm able to do it digital with Amistore.

Go to top


Re: Read() on OS4
Just popping in
Just popping in


@afxgroup

Do you mean something like the bahvior described in the first answer of this question?

Go to top


Re: RadeonHD V.5 driver
Just popping in
Just popping in


@hans

The naming is all very confusing. But can it be stated that the RaedonHD.chip is for Southern Island cards and the ReadonRX.chio for Polaris cards?

Go to top


Re: What happened to Exec interface
Just popping in
Just popping in


@colinw

You are right, that's another workarounds for the missing reschedule method. But still a workarounds.

@salass00

This might work. Depends on why you are calling IExec->Reschedule() from an application?.

My personal meaning is, if we take a wider look at where IExec->Reschedule is used and how, I think 99%
of the usage is not correct, and the remaining 1% usage is probably just for os/kernel related stuff.

Let me explain why i think that 99% of the usage is wrong. First of all from an application point of view,
what to you gain from a call to IExec->Reschedule()? BTW i couldn't find any documentation about it in any
of the available SDKs. So i assume it does something similar as the side effect of calling SetTaskPri;

Quote:
A reschedule is performed, and a context switch may result.


The reschedule per se is transparent for the calling application, but the optional context switch can be
misused to synchronized task/process. Like the implementation of pthread_once method of the gcc compiler at
https://github.com/sba1/adtools/ uses it:

int __gthread_once (__gthread_once_t *__oncevoid (*__func) (void)) { 
  
__internal_gthread_once_t *once = (__internal_gthread_once_t *)__once
  
  if (
__once == NULL || __func == NULL)
    return 
EINVAL;

  if (
__atomic_load_1(&once->u.i.done__ATOMIC_SEQ_CST))
    return 
0;

  if (!
__atomic_test_and_set(&once->u.i.started__ATOMIC_SEQ_CST)) {
    
/* Started flag was not set so call func now */
    
__func();

    
/* Remember that we are done now. And make all effects prior to this
     * store visible to all the other clients that will read that we are
     * actually done.
     */
    
__atomic_store_1(&once->u.i.done1__ATOMIC_SEQ_CST);
  }
  else {
    while (!
__atomic_load_1(&once->u.i.done__ATOMIC_SEQ_CST)) {
      
/* Allow the other thread to progress quickly but iexec may be not available */ 
      
struct ExecBase *SysBase = *(struct ExecBase **)4;
      
struct ExecIFace *ie = (struct ExecIFace *)SysBase->MainInterface;
      
ie->Reschedule();
    }
  } 

  return 
0;
}


To understand what it does the man page of pthread_once might help. It ensures that the __func method gets only called once,
regardless how many tasks/processes/threads simultaneously or each after another calls pthread_once. The trickiest part of
the implementation is if more than one task/process/thread calls pthread_once simultaneously, or better said, if task/process/thread A
still executes __func and during that additional tasks/processes/threads calls pthread_once. Because currently with one CPU core no real
multitasking is possible, one of the additional tasks/processes/threads would starve task/process/thread A. To avoid that the author
used IExec->Reschedule to give process A time on the CPU. Mainly relaying on that the optional context switch is performed, and A gets
process time on the CPU. With lowering the task pri it makes this even more likely, especially if A has a higher priority.

If in a future the AmigaOS kernel can utilize multiple CPU/Cores, the solution could break. With missing documentation of
IExec->Reschedule there are a lot of question raising in my head for a future multi core system, what a call of
Reschedule will result in...

a) just reschedule the tasks on the core where my calling tasks run?
b) all cores?
c) any other core expect the core my task runs on
d) randomly one core of all available

Some of them don't sound reasonable, but if the behavior isn't a/b you can build scenarios where the implementation above won't work.
And i might think a solution b wouldn't be good to overall performance of the os on a multiple core setup.

For the above implementation a better solution for replacing IExec->Reschedule would be to have the calling task to go to "sleep". But
there isn't a sleep function in Exec, just the Delay method in DOS, which again might not be callable if the calling task isn't a Process
or at least hasn't setup a MsgPort as mention on in the AutoDoc of DOS.

And for me i think it is correct that the SDK doesn't publicly offer the Reschedule function. It should be use by normal applications.

BTW on the pthread branch of afxgroup clib2 there is different implementation of pthread_once, which don't use a sleep of reschedule
kind of mechanism to handle the task/.. synchronization. Instead it's solution builds upon a look. Which in my opinion is even nicer,
because of no looping (and the threads gets put to sleep and just gets wake up from the os
than they can continue there work.

Go to top


Re: What happened to Exec interface's Reschedule function?
Just popping in
Just popping in


@rwo

You probably right. So to make sure that the task prio is really different, the work around solution should be:

struct Task *task FindTask(NULL); 
// changing the priority will trigger a reschedule
// TODO - User IExec->Reschedule() 
BYTE oldpri SetTaskPri(task, -10); 
if( 
oldpri == -10 )
  
SetTaskPri(task, -11 ); 
SetTaskPri(taskoldpri );

Go to top


Re: What happened to Exec interface's Reschedule function?
Just popping in
Just popping in


I found a workaround how to trigger a reschedule with exec without the official Reschedule method:

struct Task *task FindTask(NULL);
// changing the priority will trigger a reschedule
// TODO - User IExec->Reschedule()
oldpri SetTaskPri(task, -10);
SetTaskPri(taskoldpri);


From the autodocs fro SetTaskPri

Quote:

...
FUNCTION
This function changes the priority of a task regardless of its
state. The old priority of the task is returned. A reschedule is
performed, and a context switch may result.
...


I just wanted to document it here, in search for an answer.

Go to top


Re: Strange AllocVec Problem
Just popping in
Just popping in


@all

During writing my own post, i thought i switch AllocVecTag to calloc. And that seems to work. Why?

Go to top


Re: Strange AllocVec Problem
Just popping in
Just popping in


@all

now i have the crash reproducible. And it crashes during a call to AllocVecTags.

Here the binary version, which crashes and the sources

The line which case the crash is in the file smb2_tree_connect.c in line 105:

...
struct SMB_Tree_Connect_Response *message IExec->AllocVecTags(
    
size,
    
AVT_Type,        MEMF_SHARED,
    
AVT_ClearWithValue,    0,
    
TAG_DONE );
if( 
message != NULL ) {
...


if i modified the source to this, which works as long you try to connect to an invalid share name:

...
struct SMB_Tree_Connect_Response *message = (struct SMB_Tree_Connect_Response *)header// IExec->AllocVecTags(
//    size,
//    AVT_Type,        MEMF_SHARED,
//    AVT_ClearWithValue,    0,
//    TAG_DONE );
if( message != NULL ) {
...


If you use a valid share name it can crash because of other circumstances.

Anyway i don't understand why/what on earth the call crashes. I even changed the memory type to MEMF_SHARED from MEMF-PRIVATE, maybe the bsdsocket library requires that?

Go to top


Re: Strange AllocVec Problem
Just popping in
Just popping in


I'm starting to really giving up on this. I've rewritten a lot of my code to clean it up and so on.
Now it just crashes without any hint what the cause could be. Now it even doesn't relate anymore to an nearby AllocVec call.
If I run my current program with debuglevel=20 the crash output looks like this:

[SMB2DEBUG ‘start’ Wait for network and signals 0x80008000 
[HAL_DfltTrapHandler] *** WarningFatal exception in task 0x6D664900 (Workbenchetask 0xEFF37CD0at ip 0x0183AD54
[HAL_AlertALERT0x80000003
[HAL_SuspendTaskWithUpdateSuspending 0x6D664900 with state=2DAR=0x0FDC6932at IP=0x0183AD54LR=0x0183AE8C 
[HAL_SuspendTaskWithUpdateAdding to suspend list 
[
HAL_SuspendTaskWithUpdateSetting Workbench to crashed 
[HAL_SuspendTaskWithUpdateContext 0xEFF21000 
kernel 54.30 
(1.1.2021AmigaOne X5000 debug 
Machine model
(AmigaOne X5000/20
Dump of context at 0xEFF21000 
Trap type
DSI exception 
DSISR
: 00800000  
DAR0FDC6932 
No matching page found 
Machine State 
(raw): 0x0002F030 
Machine State 
(verbose): [Critical Ints on] [ExtInt on] [User] [IAT on] [DAT on]  
Instruction pointerin module kernel.debug+0x0003AD54 (0x0183AD54
Crashed processWorkbench (0x6D664900
DSI verbose error descriptionAccess to address 0x0FDC6932 not allowed by page protection in user state (protection violation
Access was a store operation 
Exception Syndrome Register
0x00800000  
 0
: 01868B90 6CF35BC0 00000002 66F1DFDC 66F1DFDC 00000000 00000050 6CF35D28  
 8
: 018417B0 66F1DFDC 0FDC692E 80000001 35933593 0000000D 6FF0756C 02009E34 
16
02010000 02158BD8 02012AFC 02012AE8 01879228 02160000 020107E4 0201084
24
00000000 EFFFADC4 020000A0 02160000 01868B90 02160000 66F1D430 66F1DFDC 
CR
55933993   XERC000006F  CTR: 0183AE1C  LR: 0183AE8C  

Disassembly of crash site

[
_impl_GetInterfaceGetting interface mmu of library exec.library 
[_impl_GetInterfaceFound interface at 0x6FF9F000checking version 
[_impl_GetInterfaceReturning interface 0x6FF9F000 
[_impl_LockMemNot all memory was locked  
0183AD44A92A8B98   lha               r9,-29800(r10
[
_impl_LockMemNot all memory was locked  
0183AD48815E0000   lwz               r10,0(r30
[
_impl_LockMemNot all memory was locked  
0183AD4C2F890000   cmpwi             cr7,r9,
[_impl_LockMemNot all memory was locked  
0183AD50813E0004   lwz               r9,4(r30
[
_impl_LockMemNot all memory was locked 
>0183AD54912A0004   stw               r9,4(r10
[
_impl_LockMemNot all memory was locked  
0183AD5840DE0018   bne-              cr7,0x183AD70 
[_impl_LockMemNot all memory was locked  
0183AD5C83E1000C   lwz               r31,12(r1
[
_impl_LockMemNot all memory was locked  
0183AD607FC3F378   mr                r3,r30 
[_impl_LockMemNot all memory was locked  
0183AD6483C10008   lwz               r30,8(r1
[
_impl_LockMemNot all memory was locked  
0183AD6838210010   addi              r1,r1,16 
msr
0x0002B032 
TLB1 
(64 entries): 
 * [ 
50]: size=7 tid 0 TS 1 epn=0xFE000000 rpn=0x0000000F_FE000000 WIMG=0x5 XXWWRR=0xF protected 
 * [ 
51]: size=6 tid 0 TS 1 epn=0x01000000 rpn=0x00000000_01000000 WIMG=0x0 XXWWRR=0x5 protected 
 * [ 
52]: size=6 tid 0 TS 1 epn=0x01400000 rpn=0x00000000_01400000 WIMG=0x0 XXWWRR=0x5 protected 
 * [ 
53]: size=6 tid 0 TS 1 epn=0x01800000 rpn=0x00000000_01800000 WIMG=0x0 XXWWRR=0x33 protected 
 * [ 
54]: size=6 tid 0 TS 1 epn=0x01C00000 rpn=0x00000000_01C00000 WIMG=0x0 XXWWRR=0x33 protected 
 * [ 
55]: size=5 tid 0 TS 1 epn=0x02000000 rpn=0x00000000_02000000 WIMG=0x0 XXWWRR=0xF protected 
 * [ 
56]: size=5 tid 0 TS 1 epn=0x02100000 rpn=0x00000000_02100000 WIMG=0x0 XXWWRR=0xF protected 
 * [ 
57]: size=5 tid 0 TS 1 epn=0x02200000 rpn=0x00000000_02200000 WIMG=0x0 XXWWRR=0xF protected 
 * [ 
58]: size=4 tid 0 TS 1 epn=0x02300000 rpn=0x00000000_02300000 WIMG=0x0 XXWWRR=0xF protected 
 * [ 
59]: size=4 tid 0 TS 1 epn=0x02340000 rpn=0x00000000_02340000 WIMG=0x0 XXWWRR=0xF protected 
 * [ 
60]: size=3 tid 0 TS 1 epn=0x02380000 rpn=0x00000000_02380000 WIMG=0x0 XXWWRR=0xF protected 
 * [ 
61]: size=7 tid 0 TS 0 epn=0xFE000000 rpn=0x0000000F_FE000000 WIMG=0x5 XXWWRR=0xF protected 
 * [ 
62]: size=A tid 0 TS 0 epn=0x00000000 rpn=0x00000000_00000000 WIMG=0x0 XXWWRR=0x3F protected 
 * [ 
63]: size=A tid 0 TS 0 epn=0x40000000 rpn=0x00000000_40000000 WIMG=0x0 XXWWRR=0x3F protected HAL_MaxTLB 49HAL_NextTLB 
MMUCFG 
0x064809C4 
mas0 
0x103F0000 
mas1 
0xC0000A00 
mas2 
0x40000000 
mas3 
0x4000003F 
mas4 
0x00000100 
mas5 
0x00000000 
mas6 
0x00000001 
mas7 
0x00000000 
mas8 
0x00000000  

Kernel command line
serial munge debuglevel=10  

Registers pointing to code

[
_impl_OpenLibraryTrying to open dos.libraryversion 53 
[_impl_OpenLibraryFound library at 0x6FEA3228 
[_impl_OpenLibraryCalling Open vector of dos.library 
[_impl_OpenLibraryReturned from open vector 
[_impl_OpenLibraryLibrary node at 0x6FEA3228 
[_impl_OpenLibraryTrying to open elf.libraryversion 53 
[_impl_OpenLibraryFound library at 0x6FF02154 
[_impl_OpenLibraryCalling Open vector of elf.library 
[_impl_OpenLibraryReturned from open vector 
[_impl_OpenLibraryLibrary node at 0x6FF02154 
[_impl_GetInterfaceGetting interface main of library dos.library 
[_impl_GetInterfaceFound interface at 0x6F86E000checking version 
[_impl_GetInterfaceReturning interface 0x6F86E000 
[_impl_GetInterfaceGetting interface main of library elf.library 
[_impl_GetInterfaceFound interface at 0x6FFAB780checking version 
[_impl_GetInterfaceReturning interface 0x6FFAB780 
[SMB2DEBUG ‘start’ Wake up from WaitSelect with 0x00000001 ready descriptors and signals 0x00000000 
[SMB2DEBUG ‘start’ Reading from socket request 
[SMB2DEBUG ‘network’ NETWORK_processByteson socket 0 
[SMB2DEBUG ‘smbv2’ SMB2_Decoderheader address 0x66388B10 
[SMB2DEBUG ‘smbv2’ SMB2_DecoderCHECK ITFrame length is81 
[SMB2INFO ‘smbv2’ SMB2_DecoderDecoding SessionSetup Reponse Message ‘SMB2_COMMAND_SESSION_SETUP’ (1
[
SMB2DEBUG ‘smbv2’ decodeSessionSetupResponseheader address 0x66388B10 
[SMB2ERROR ‘smbv2’ decodeSessionSetupResponseGoing to allaocte 85 bytes


It looks like the crash is in parallel to the executing of my program and that workbench crashed, and thus my program continues to tun? But interaction is not possible because of the crashed workbench.

Obviously it must be something in my program, which causes the crash. But currently I'm out of ideas.

Anyone any idea how to further track down the cause?

Here is the current executable and the source.

Go to top


Re: New verson of CLiB2 from Andrea (afxgroup)
Just popping in
Just popping in


@afxgroup

Even better. I will update my clib2

Go to top


Re: New verson of CLiB2 from Andrea (afxgroup)
Just popping in
Just popping in


@afxgroup

I tried to port a Linux project and switch to your clib2 implementation, which gave way longer flow than newlib/old clib2.

Now i stumble over missing <err.h> include file. During a google search found out that isn't part of the POSIX standard. But
nevertheless often encounter in Linux project and part of Linux.

So I'm wondering if you plan to even include common encounters Linux stuff into your clib2 project, to ease porting even further.
And if not planing by yourself, would integrate contributions going that way?

Go to top


Re: Strange AllocVec Problem
Just popping in
Just popping in


@jabirulo

Whenever you make your next test run. If you can give the debug output and maybe even the a wireshark capturing would be nice.

Go to top


Re: Strange AllocVec Problem
Just popping in
Just popping in


@trgswe

Good to know that i don't need to swap the data. That was a little question in back mind, which got answered now.
Will see that i rewrite the network read/write stuff.

Go to top


Re: Strange AllocVec Problem
Just popping in
Just popping in


@flash

The sources can be downloaded here https://drive.google.com/file/d/1VgN9h ... yRKq-bNf/view?usp=sharing

Something like that might it be, but currently i have no idea where to look. But i have the fleeing it might be wrong format string for some output and/or 64 ints alignment stuff.

Go to top


Re: Strange AllocVec Problem
Just popping in
Just popping in


@jabirulo

I had access to an Win10 Server and could test my implementation and ran in the same bug as you discovered in my implementation. Here is a fixed version, please if you like test it again:

https://drive.google.com/file/d/1YYpF6 ... xFRS3YCf/view?usp=sharing

@all

Even that the strange AllocBehavior disappars more and more. i got output on the shell, which isn't programmed. Anyone an idea what could cause that. See the image and the zeros:

Quote:

Connecting to '172.16.0.122:445'...connected
Negotiating dialect....accepted by server
Authenticating user....0000000000000000000000000000000000000000000000000000000000000000sucees


(Well don't how to add an image, so typed out) It seems to be exactly 64 zeros.

Go to top


Re: Strange AllocVec Problem
Just popping in
Just popping in


@trgswe

Well smbv1 doesn’t bother me. There is already a client available for it, but it doesn’t support smbv2. Thus I just targeting to implement a smbv2 client with NTLMv2 authentication. So that a samba share can be accessed from the amiga without playing around at the server.

Go to top



TopTop
(1) 2 3 4 »




Powered by XOOPS 2.0 © 2001-2016 The XOOPS Project