Welcome, Guest. Please login or register.

Author Topic: The Os 3.1.4 Thread  (Read 239063 times)

Description:

0 Members and 1 Guest are viewing this topic.

Offline kolla

Re: The Os 3.1.4 Thread
« Reply #569 from previous page: August 12, 2019, 09:09:56 AM »
Quote
was getting 1,638,400 with previous version

Really? That number looks way too, uhm... casual, to be real :)
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
---
A3000/060CSPPC+CVPPC/128MB + 256MB BigRAM/Deneb USB
A4000/CS060/Mediator4000Di/Voodoo5/128MB
A1200/Blz1260/IndyAGA/192MB
A1200/Blz1260/64MB
A1200/Blz1230III/32MB
A1200/ACA1221
A600/V600v2/Subway USB
A600/Apollo630/32MB
A600/A6095
CD32/SX32/32MB/Plipbox
CD32/TF328
A500/V500v2
A500/MTec520
CDTV
MiSTer, MiST, FleaFPGAs and original Minimig
Peg1, SAM440 and Mac minis with MorphOS
 

guest11527

  • Guest
Re: The Os 3.1.4 Thread
« Reply #570 on: August 12, 2019, 02:20:29 PM »
anyone else notice a slight slow down with the new FFS update? I'm now getting 1,310,720 bytes/sec but was getting 1,638,400 with previous version
The only thing that changed in the FFS was the disk validator, disk formatting and the mounting procedure. The I/O main loop and I/O operations in general did not change at all. So whatever this is (or not) is not due to the changes in the FFS.
 

guest11527

  • Guest
Re: The Os 3.1.4 Thread
« Reply #571 on: August 12, 2019, 02:29:14 PM »
Which input.device are you using? Poseidon comes with input.device backported from MorphOS (v50) to fix various issues with USB hidd and v40 input.device (multi-kbd/mouse support and more), so maybe you are using that?

That is not a "fix" of the input.device, it is an extension of its interface. The problem is that the USB hid class uses for input.devices below V50 IND_WRITEEVENT to propagade keyboard and mouse events to the chain of input device handlers. But this command only does this: Propagade events. Unfortunately, the USB hid class seems to expect that the input.device generates keyboard repeat events itself, which it does not (i.e. auto-repeat a key once it is kept pressed) - it is not the purpose of this command to interpret commands in any particular way. It would be the job of the usb hid class to synthetize such events. Thus, this is actually a defect in Poseidon. What V50 added was a new command (IND_ADDEVENT) Poseidon uses instead in case a V50 is detected, and this new command then takes over the job of creating synthetic events to generate keyboard repeat events - but as said, this is not a bug fix, it is an extended interface.
 
The following users thanked this post: Tygre

guest11527

  • Guest
Re: The Os 3.1.4 Thread
« Reply #572 on: August 12, 2019, 02:37:59 PM »
I did a lot more testing on this now and finally figured out that having the "Unmount partitions after removal" option enabled in the "LUN Defaults of the massstorage.class of the usb stack was causing issues.  I tried it with both the Deneb and a RapidRoad USB cards and both were doing the hang when that option was set.  Without this, it no longer hangs.  As a matter of fact, I actually started to see the issue in 3.9 as well when the option set.   
"Removing" mouted drives is not an obvious thing to do - in fact, this is not possible under AmigaDOS. Removable media should *always* be mounted with a mount list, and never over an RDB. As you observe, multiple bad things can happen if you just attempt to kill a running handler. Once FFS is running, it cannot be killed anymore - unfortunately, it does not support ACTION_DIE. 

In regards, to 3.1.4 multiview (v45.22) and the warp BMP datatype, I was trying to see if I could do some captures with MuForce and so attaching some of the dumps from the serial port.   What doesn't make sense is that this log shows input.device having issue...don't really understand that.
This is probably a side-effect of something else, i.e. the datatype probably stumps on memory that belongs to the input.device and by that kills it. There are two possible options: 1) There is an option to reduce the interface of the picture datatype to that of V40. This has the impact that true-color pictures are only rendered by dithering, but the interface remains then at the V40 level the datatype may expect. There is an ENV: varaiable to change that which is mentioned in the FAQ, but unfortunately I'm currently away so I cannot check right now. 2) Try to run MuGuardianAngel on top of MuForce. This may detect additional problems MuForce alone is not able to pick up.


With the 3.9 Multiview (v45.9) program in 3.1.4 env. I don't see graphic corruption issue -- when i did this comparison with v45.22 and v45.9, everything is exactly the same except for the multiview version.
There isn't really a substantial change between the versions. One thing you can try is to give multiview more stack. There is a stack check included, but maybe the stack is not sufficient for the datatype.


And for the RAM issue that I had, I haven't been able to reproduce exact same issue.  However, I have experienced 800 0004 GURU while deleting the files from the RAM disk.  I'm attaching a MuForce output for this crash.
This can be almost anything and is probably due to some other bad effect that happened earlier. I would need a long stack traceback to see anyhting there.
 

Offline my_pc_is_amiga

Re: The Os 3.1.4 Thread
« Reply #573 on: August 13, 2019, 05:28:18 AM »
Thanks Thomas!

Once FFS is running, it cannot be killed anymore - unfortunately, it does not support ACTION_DIE. 
I assume this is also true of the crossdosfilesystem?

Quote
1) There is an option to reduce the interface of the picture datatype to that of V40. This has the impact that true-color pictures are only rendered by dithering, but the interface remains then at the V40 level the datatype may expect. There is an ENV: varaiable to change that which is mentioned in the FAQ, but unfortunately I'm currently away so I cannot check right now. 2) Try to run MuGuardianAngel on top of MuForce. This may detect additional problems MuForce alone is not able to pick up.

I'll have to check out the ENV variables some more.  I was trying them sometime ago but at that time I didn't see it helping.  I haven't been able to get MuGuardianAngel to work -- seems to hang system.  I have put it after MuForce.

Quote
One thing you can try is to give multiview more stack.
I tried changing to 94096k stack and still saw issue.


Quote
This can be almost anything and is probably due to some other bad effect that happened earlier. I would need a long stack traceback to see anyhting there.
Attached is a longer stack trace -- hopefully this is long enough.  If not I can try to do another capture. This time when it failed I got 800 0005.
« Last Edit: August 13, 2019, 06:17:14 AM by my_pc_is_amiga »
 

Offline my_pc_is_amiga

Re: The Os 3.1.4 Thread
« Reply #574 on: August 13, 2019, 05:29:32 AM »
Which input.device are you using? Poseidon comes with input.device backported from MorphOS (v50) to fix various issues with USB hidd and v40 input.device (multi-kbd/mouse support and more), so maybe you are using that?

I've been using the 3.1.4.1 version of input.device.
 

Offline kolla

Re: The Os 3.1.4 Thread
« Reply #575 on: August 13, 2019, 02:28:52 PM »
this is not a bug fix, it is an extended interface.

Well, from users' perspective, that is rather irrelevant distinction.

For me, the particular "issue" is that with original input.device, I cannot click on links in IBrowse using USB mouse, as if IBrowse doesn't get the mouse-button release event properly... with input.device v50 it works. As apparently there is no interest in maintaining Poseidon for Amiga OS, and all development taking place for MorphOS and AROS.. perhaps I should just switch to anaiis for AmigaOS and see how that works.

Anyways - the point here was just to give a heads up to make my_pc_is_amiga, that when installing Poseidon, a different input.device may also have been installed.
« Last Edit: August 13, 2019, 02:32:01 PM by kolla »
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
---
A3000/060CSPPC+CVPPC/128MB + 256MB BigRAM/Deneb USB
A4000/CS060/Mediator4000Di/Voodoo5/128MB
A1200/Blz1260/IndyAGA/192MB
A1200/Blz1260/64MB
A1200/Blz1230III/32MB
A1200/ACA1221
A600/V600v2/Subway USB
A600/Apollo630/32MB
A600/A6095
CD32/SX32/32MB/Plipbox
CD32/TF328
A500/V500v2
A500/MTec520
CDTV
MiSTer, MiST, FleaFPGAs and original Minimig
Peg1, SAM440 and Mac minis with MorphOS
 

Offline my_pc_is_amiga

Re: The Os 3.1.4 Thread
« Reply #576 on: August 13, 2019, 03:16:21 PM »
perhaps I should just switch to anaiis for AmigaOS and see how that works.
Thanks -- I didn't know about Anaiis.  I looks like it only supports subway / highway as of now.  Sirion USB stack for OS4 I guess it out of the question as of now for 3.x -- I'm not aware of any 68k version and assume there isn't any drivers for the classic zorro cards.

Quote
Anyways - the point here was just to give a heads up to make my_pc_is_amiga, that when installing Poseidon, a different input.device may also have been installed.

Thanks for letting me know.
 

guest11527

  • Guest
Re: The Os 3.1.4 Thread
« Reply #577 on: August 13, 2019, 04:20:34 PM »
Well, from users' perspective, that is rather irrelevant distinction.
Not really. It is a defect of the delivered USB stack, and it should have been done correctly in the stack in first place. Delivering an alternative input.device was never the right solution in first place - this was the kludge to begin with. One way or another, this issue has been addressed, but in how far an updated Poseidon stack can be delivered is something I cannot decide. All I can say is that I took precautions to address the problem, and I did my best to provide a solution.

 
The following users thanked this post: Tygre

Offline Matt_H

Re: The Os 3.1.4 Thread
« Reply #578 on: August 13, 2019, 05:04:47 PM »
perhaps I should just switch to anaiis for AmigaOS and see how that works.
Thanks -- I didn't know about Anaiis.  I looks like it only supports subway / highway as of now.  Sirion USB stack for OS4 I guess it out of the question as of now for 3.x -- I'm not aware of any 68k version and assume there isn't any drivers for the classic zorro cards.

Sirion was originally written for the Thylacine card, so a 68K version does exist. But even the OS4 version has extremely limited driver support (for both Amiga cards and USB peripherals) and the 68K version is even older and more limited. As far as I’m aware, none of the OS4 components were ever backported.
 
The following users thanked this post: my_pc_is_amiga

guest11527

  • Guest
Re: The Os 3.1.4 Thread
« Reply #579 on: August 14, 2019, 04:49:50 AM »
I assume this is also true of the crossdosfilesystem?
No, CrossDos does support ACTION_DIE, and then also goes away, but all provided that there are no locks left on any mounted volume. Then again, I do not know what Poseidon exactly attempts. Actually, the only file system where I did *not* add ACTION_DIE is the FFS.

I tried changing to 94096k stack and still saw issue.
I'll check the MuForce hit once I'm back home. Right now, it makes no sense - thanks.
 
The following users thanked this post: my_pc_is_amiga

Offline beller

  • S.A.C.C.
  • Hero Member
  • *
  • Join Date: Dec 2004
  • Posts: 657
    • Show only replies by beller
Re: The Os 3.1.4 Thread
« Reply #580 on: August 14, 2019, 06:13:14 AM »
Are there any known issues with the 3.1.4 serial device?  I have a GuruModem which worked fine on my A600 but on the A1200 with 3.1.4 I can receive characters like a list of available wifi sites, but I don't appear to be transmitting properly.  Checked all the settings and it should be working.

Also, I searched the Hyperion site and noticed a complaint about iPrefs crashing after changing a preference on an OS 4 machine.  The post on Hyperion said it was fixed.  I saw this same crash several times today.
 

Offline my_pc_is_amiga

Re: The Os 3.1.4 Thread
« Reply #581 on: August 14, 2019, 06:19:56 AM »

I tried changing to 94096k stack and still saw issue.
I'll check the MuForce hit once I'm back home. Right now, it makes no sense - thanks.

Just to clarify, the MuForce hit I posted recently was for when deleting files from RAM disk.   

For multiview (seperate issue), I haven't been able to get anything that makes sense from MuForce.   But there is still 1 thing that is different:

1) v40.8 (3.1) --> this is opening screen that is larger than the picture size (no issue)
2) v45.9  (3.9) -> this is opening screen that is larger than the picture size (no issue)
3) v45.22  (3.1.4) --> this one is scaling screen to match picture size (see graphic corruption and memory corruption).   Also, as noted previously, the other side affect is if the picture is very small then the menu/ASL requester cannot show on the very small screen.

Can it be something to do with the screen size change that is happening in v45.22?

 

Offline my_pc_is_amiga

Re: The Os 3.1.4 Thread
« Reply #582 on: August 14, 2019, 06:27:45 AM »
Are there any known issues with the 3.1.4 serial device?  I have a GuruModem which worked fine on my A600 but on the A1200 with 3.1.4 I can receive characters like a list of available wifi sites, but I don't appear to be transmitting properly.  Checked all the settings and it should be working.

I've been using serial.device on my A4000T with a null modem cable with 3.1.4 and haven't seen any issue when using the terminal program "Term"

Quote
Also, I searched the Hyperion site and noticed a complaint about iPrefs crashing after changing a preference on an OS 4 machine.  The post on Hyperion said it was fixed.  I saw this same crash several times today.

Is this a OS4 machine that you have or talking about crashes with 3.1.4.   Do you have sequence of how it crashes (i.e. what preference editor, etc) if on 3.1.4
 

Offline beller

  • S.A.C.C.
  • Hero Member
  • *
  • Join Date: Dec 2004
  • Posts: 657
    • Show only replies by beller
Re: The Os 3.1.4 Thread
« Reply #583 on: August 14, 2019, 01:56:00 PM »
No...it’s not an OS 4 machine it’s an A1200.  I noticed this error while searching for info on Hyperion’s web site.  I had iPrefs crash repeatedly on 3.1.4 which, just guessing, must share some of the same code as OS4.
 

guest11527

  • Guest
Re: The Os 3.1.4 Thread
« Reply #584 on: August 14, 2019, 01:57:19 PM »
For multiview (seperate issue), I haven't been able to get anything that makes sense from MuForce.   But there is still 1 thing that is different:

1) v40.8 (3.1) --> this is opening screen that is larger than the picture size (no issue)
2) v45.9  (3.9) -> this is opening screen that is larger than the picture size (no issue)
3) v45.22  (3.1.4) --> this one is scaling screen to match picture size (see graphic corruption and memory corruption).   Also, as noted previously, the other side affect is if the picture is very small then the menu/ASL requester cannot show on the very small screen.

Can it be something to do with the screen size change that is happening in v45.22?
There simply is no "scale to screen" option for background images in the current IPrefs. It was not part of 3.1, so it was not part of 3.1.4 either. This option will come again in 3.2.

I am unclear what you mean by "this is openening screen".