@Rogue

A1XEG4 unfixed 512MB and radeon 9200SE did not shown any problem after the installation of this Quickfix (did not have any particular one before either, except some very sporadic freezes but can't say for sure if it was due to system or not

_________________
OS 4.1 : I dream it, Hyperion did it
Thank you to all devs involved for this great job !

@cha05e90
I has seeing the same problem as well before I disabled the window backdrop.

My system normally booked okay and with do sine of problems but as you opened and closed more and more folders each opening there own windows the screen corruption started as shown in the earlier screen shot by another sam440 user with the quick fix and would end in a lockup with the "copper-like" screen.

In fact you can make it happen consistently on my by selecting the default OS4.1 theme and just opening as directory's from there icons under workbench without launching any other programs.

I don't have any third party applications applications in my workbench startup folder and I only have assigns in my user-startup So it looks like a problem with a standard OS4.1 component causing problems. Unless its a problem with a 3rd part datatype, library or device driver casing problems.

The only third party data-types I can think of that I have installed are the WarpDT ones as I am a registered user but I think I only installed the datatypes for file types that OS4.1 dose not come supplied with datatypes for so they should not be able to cause any problems I would have thought.

_________________
Sam440ep 667mhz, 512MB, 120GB 2.5" HD, OS4.1
WinUae 2.0.1, OS 3.9, BB2, Catweasel MkIV
Amiga 1200, Blizzard 040/40 (BlizzardPPC 060/200 with SCSI removed at present), mediatorSX pci, Voodoo3, PCI network card os 3.9BB2

I discovered a problem with the Ram Disk on my 800MHZ SAM Flex with 1GB memory. If I copy more than approximately 450MB of data to the Ram Disk, I can't start any programs from WorkBench or a shell. Programs that are already running continue to do so but no new programs can be started. Occasionally, one small program will start after the copy to Ram Disk but that's it until I reboot. It doesn't matter if I copy directories of small files or several large files. If I exceed about half of available memory on my 1GB SAM with copied files to Ram Disk, no new programs will start. This makes no sense since there is still more than 400MB system memory available. I tried to determine if this was a memory availability issue by using "Allocmem" (from OS4Depot) to allocate most of the available memory to see if program opening was affected. I can use Allocmem to allocate over 800MB of memory and the system still functions normally. I can open more programs after the allocation. In fact, I've been able to allocate all but about 50MB of the available system memory and the system appears unaffected. Therefore it looks like there is a bug in the Ram Disk that prevents normal operation if too much data is copied to the Ram Disk. If there is a reason for this Ram Disk behavior then it should report "Disk Full" when it reaches full capacity.

Last edited by Xenic on 03-Jul-2009 at 12:26 AM.
Last edited by Xenic on 03-Jul-2009 at 12:25 AM.

I've also noticed that if I attempt to copy a directory that is larger than the available system memory to Ram Disk it crashes instead of reporting "Disk Full" or something similar. Does the same thing occur on other hardware (A1, SAM440ep etc.)??

@Xenic

That problem appears to be related to the fact that your DOS library is now about 1 year old.

In the meanwhile this issue was corrected but since the new DOS library was not included in the Quickfix package, you are observing this behavior.

New ISO's for each supported platform are becoming a necessity in view of the substantial work on a wide number of system components.

@Hyperionmp
Quote:

That problem appears to be related to the fact that your DOS library is now about 1 year old. In the meanwhile this issue was corrected but since the new DOS library was not included in the Quickfix package, you are observing this behavior.

Why wasn't it included? Why don't you publish a list of known bugs if your're not going to release fixes. Then some of us could stop trying to get problems confirmed and struggling to figure out what's wrong. I'm getting weary of Booting from the OS4.1CD, disabling programs, removing and replacing memory, connecting and disconnecting components etc. because I think I've done something wrong. Sorry to sound negative but I've just experienced far to many problems with my new SAM Flex system.

@Xenic

There is a very significant reason why the SAM version of OS4.1 is labelled as beta, as you are finding out.

If a list of all known bugs was known and existed, the bugs could be fixed, as it is, the "beta" system has been thrown open to the wider public audience in an effort to try and collate as much information as possible with these problems.

What makes it even harder is that some systems exhibit these problems, and some dont. Some users experience a lot of the problems, others only a few.

I'm afraid the bottom line is that you knowingly bought an OS which was in beta state, and as such there are going to be problems.

As HyperionMP has suggested, new distribution ISos would certainly cure the dependency problems we have here with the older dos.library, but there is still much work to do in finding all the problems that have arisen. That said, work is underway, as you will see....

_________________
Simon

@rigo
O.K. I think I'll reconnect my µA1 until I see....
I'm suffering from beta exhaustion and need a break

@rigo
I was backing up my SAM Flex before switching to uA1 and had yet another "beta experience". I dragged several partitions into the window for my 16GB SFS formatted flash drive, turned off the monitor and went to bed. I have performed lots of similar backups on my µA1. When I awoke the next morning and turned on the monitor, there was a Grim Reaper for USB, the system was frozen and the flash drive was trashed with bad blocks. I noticed that all the memory was gone in the WorkBench toolbar and proceeded to perform some tests after I rebooted. It turns out that USB eats huge amounts of memory when copying to a flash drive. Here are my results for some simple copy tests:
70MB of memory was consumed for a 221 MB copy.
158MB of memory was consumed for an 881MB copy.
15MB of memory was consumed for a 47MB copy.
44MB of memory was consumed for a 678MB copy.
38MB of memory was consumed for a 255MB copy.
The results seem inconsistant because the memory loss seems to depend on the size of the files being copied. Copying several huge files eats much less memory than copying hundreds of small files. I also noted that USB eats about 8KB of memory every five seconds whenever a flash drive is plugged into one of the USB ports. Moving the mouse pointer also eats about 8KB of memory for each move. I've tested the memory consumption when a flash drive is plugged in for several hours and it looks like all the memory in a 512MB system would be consumed withing 48 hours. Large unattended copies to a flash drive are probably not a good idea on the SAM Flex because the target drive seems to get trashed when memory runs low.

@Xenic

Hmm, so do you have logging switched on? For USB that is. Check your USB prefs and if selected switch of Log Information. Might not be the reason but if ti is slected then the log file in T: will grow continuosly till all your memory is gone....

@broadblues
Or you could just change assign T: ram:T to assign T: sys:T.
I'd be interested in seeing the content of your usb log tho. The mouse moving problem seems worse. .

But my buest guess is that its actively using ram when copying files, which is a good trick, the original amitcp ncftp does this, resulting in transfer speeds across LAN of 5-600 kbs

Last edited by mike on 06-Jul-2009 at 09:07 AM.

_________________
C= Amiga addict
,,,
(Oo)
⎛☮ໄ
ﮑὠՀ

@rigo

Quote:

If a list of all known bugs was known and existed, the bugs could be fixed, as it is, the "beta" system has been thrown open to the wider public audience in an effort to try and collate as much information as possible with these problems.

Could you explain what you mean by this?
Trouble shooting threads and irc conversations discussing same have always existed here. Are you saying something more by indicating the "beta" system has been thrown open to the wider public?
Can anyone apply to become a beta tester? I'm asking on behalf of others who constantly ask what they can do to help. If there is some official procedure they should follow, I'm sure it would be helpful for them to know.

In conjunction with the above I asked on the previous page of this thread:
Quote:

@Rogue Would it be practical to put together a list with name and contact info for developers along with the elements they are working on specifically, in order to encourage users to make reports outside of the forum venue?

We have a forum here...for a LONG time:
Quote:

Developer Projects Forum

Quote:

The 'official' place for hardware and software developers to post factual information on their projects, ask for betatesters, and for users to report bugs to existing project threads. Developers, post your project info here!

I'm just reminding you of this forum, because we created it for YOUR use too, not just 3rd party developers. If you want to draft a post for Hyperion as to what you need and how to go about it, please take advantage of it.

#6

Last edited by number6 on 06-Jul-2009 at 02:02 PM.

_________________
This posting, in its entirety, represents solely the perspective of the author

@broadblues

On the other hand mouse movement logging should not be activated in a release version (even a beta) without a functionnal log size limiting function else it's obvious that memory will run away quickly. But I doubt this is the problem else it would have affected every SAM user (as everybody is using USB mouse).

_________________
OS 4.1 : I dream it, Hyperion did it
Thank you to all devs involved for this great job !

@number6

Even something as simple as a form to fill out, or a button to click to submit standard details for logging a bug report with a central place would be good. I wonder, can someone paste the proforma that the beta testing team use? Might make a good template for us.

_________________
Suffering pains from the belly laugh.

@broadblues
I've put the SAM away for now and am using my µA1. I have the advantage of being able to compare the operation of both systems. I checked the USB settings for SAM on the backup drive I made and the settings are the same as for the my µA1. When I originally reported the problem of 8k memory loss with mouse movements in the OS4 ML, a USB developer explained that new buffers are constantly allocated and deallocated with the expectation that the new memory management system would clean up the flagged memory when it's needed. However, I see no evidence that the memory is ever freed (on the SAM) and the system eventually locks up. He did state that they planned to change to reusing buffers which should fix the problem. I was happy with his explanation because I could live with the small chunks of memory that were being lost to mouse movements (I turn my computer off every day). However, my recently discovered USB memory loss for copies to a flash drive and the constant loss just from having a flash drive plugged in cast a different light on the problem. You can end up with a frozen system and trashed flash drive if you do a large unattended copy to a flash drive.
By comparison, the USB on my µA1 shows no memory loss for mouse movements or from having a flash drive plugged in. That indicates that SAM USB is acting differently and needs to be fixed. This evening I will try some large file copies on my µA1 but I suspect there will not be a problem. If the memory system worked as described I wonder how long it would take to check the flags for 100,000 8k memory deallocations and return the memory to the free pool. It seems like relinquishing memory to the free pool as it is deallocated would result smoother system operation with no pauses.

@abalaban
Quote:

On the other hand mouse movement logging should not be activated in a release version (even a beta) without a functionnal log size limiting function else it's obvious that memory will run away quickly. But I doubt this is the problem else it would have affected every SAM user (as everybody is using USB mouse).

As I pointed out to broadblues, the settings on my SAM are the same as for my µA1. When I checked the debug buffer when troubleshooting other problems on the SAM, I saw no evidence of mouse movements or any other USB info in the debug buffer after initial boot. I've only been back on the µA1 for a day now but installing the Quickfix on the uA1 doesn't seem to have created any problems and the system seems more stable than previously. Here are a few differences between SAM and µA1 that I noted so far:
No USB memory eating on the µA1 like I have on the SAM.
No graphics corruption in the OS4 splash screen (boot screen) like I have on the SAM.
AmiPDF does not freeze the system when reading certain PDF files like on the SAM.
The µA1 serial port works with hardware handshaking (RTS/CTS) but not on SAM (so far).
EDIT: SAM audio problem appears to be fixed by a new driver release by Davey
The SAM video output (Radeon) seems crisper and clearer than builtin µA1 video.

I'm going to stick with the µA1 for a while to see how it operates with the Quickfix installed. I'll get the SAM out again after I see reports of fixes or updates.

Last edited by Xenic on 07-Jul-2009 at 12:58 AM.

@abalaban

> On the other hand mouse movement logging should not be activated in a release > version (even a beta) without a functionnal log size limiting function else
> it's obvious that memory will run away quickly. But I doubt this is the
> problem else it would have affected every SAM user (as everybody is using USB
> mouse).

But it is a problem! Rapidly moving the mouse on my SAM uses up about 2MB per minute. At least now I know why.

Is there any way to switch this mouse movement logging off?

Kind regards,

Dennis

@abalaban

It was an idea of something to check. An easily eliminated possibilty. At one point if info logging was enabled on my A1 then the log grew continuosly.


@A3000T

*If* this is the reason look at the file T:usb.log if it is growing as you use the mouse or when a usb device is left attached, then try changing the options in Prefs/USB

@A3000T

I'm an *not* saying that mouse movements aren't eating memory on SAM (I don't know, I have an A1XE and using a ps/2 mouse) but what I put in doubt was the fact that the mouse movements were logged in the t:usb.log because if it was the case every SAM user would have experienced this problem which does not seem to be the case.
I was also emphazing the fact that logging mouse movements is something really dangerous without a limitating log size automatic procedure.

_________________
OS 4.1 : I dream it, Hyperion did it
Thank you to all devs involved for this great job !

@abalaban

A1XEG4 unfixed 512MB and radeon 9200SE did not shown any problem after the installation of this Quickfix (did not have any particular one before either...

Same here A1xeG4/256Mb ATI9250PCI;sii0680ide. The only thing i would say is the USBoptical is not playing nice with SDL. PS2 is always solid.

_________________
A1-XE/G4 + OS4 =
Amiga OS4.1 is the one to play with now!