@kas1e

Quote:
You've seen the "Nemo revision 2.1 Motherboard Firmware re-flash guide", right? (Per this post you have a copy.) It has details on the rescue flash chip and how to use it to restore the main chip if it gets corrupted.

@328gts

Quote:
That's what I have, too. Try opening a shell window and typing "Python" then pressing Return. If you get a short message from Python and then the '>>>' Python prompt then the Python interpreter is running. Press Ctrl and '\' to exit Python.

Quote:
As joerg noted, AutoInstall files are AmigaDOS scripts, not Python. The 'install.py' file in your earlier screenshot is the Python script. Per that screenshot it looks like you downloaded a number of different updates at the same time, and I suspect there's some confusion on which install script goes with which update (in particular, I wonder if the Python script doesn't belong to the SuperStarBlast1.11Update rather than WarpDT).

@328gts

Quote:
Python comes with OS 4.1 too, so you should already have it as well. Python has several parts: There's a small program called Python that lives in Sys:C. There's also libpython25.so, which lives in Sys:SObjs. Finally, there's a Python directory in Sys:System that has a bunch of other files that Python uses. Check to see if any of these have also gone missing.

@328gts

Quote:
It's part of OS4.1, as is the older Installer, so you should already have both. They both live in Sys:Utilities, though only the Installation Utility has an icon.

@328gts

Quote:
OS4 also has the old OS3-style installer (SYS:Utilities/Installer). Since WarpDT is cross-Amiga-platform, it's more likely that it uses this installer rather than the Python-based installation utility, which is OS4 only.

@smarkusg

Quote:
If the OS4 debug kernel fills freed memory with DEADBEEF, then it looks like either a packet is being sent after the buffer containing it has been freed, or the buffer was allocated from memory that was previously freed, and then sent without having anything put into it.

@trixie

Quote:
With all the weird symptoms, I'm curious what the problem turned out to be.

@derfs

Quote:
There's still a recoverable DSI at startup, though it looks to be at a different place in the code:


Quote:
Yes, it does.

Quote:
That's just what I was looking for- thanks! It would be good if the same information was in the documentation too, to make it easier to compare what the different tests do without having to bring up the description window over and over.

A minor thing- the test description window, as well as the other windows, opens in the upper left corner of the screen. It would be nicer if the windows opened in the center of the screen instead.

@derfs

First, thanks for a very nice looking, full-featured and useful program (though it would be helpful to have a bit more detail on what the different benchmark tests do, so one knows what exactly is being benchmarked).

However, I get a recoverable DSI when I run the two most recent versions of AmigaDiskBench (v. 2.5.3 and 2.5.2) on my X1000 running FE Update 3. The DSI occurs soon after I start the program, apparently while it's scanning the drives. I can click on 'Ignore DSI Errors' and the program then appears to run normally (but see below for a different problem).


There is also a second, more fatal, crash. Because it's very similar to a crash in the most recent version of Rave, I posted the details of this crash in the Rave thread, where the problem has been discussed at some length.

@trixie

The latest version of AmigaDiskBench (v. 2.5.3) seems to have a very similar bug as Rave: When I run the program, select the Disk Info tab, and then click on "Fixed Drives/sb600sata.device" in the listview the program stops responding, along with much of the OS. (There is a recoverable DSI when I first run the program; that DSI doesn't seem related to the lockup bug.)

Like Rave, the crash happens when the program is working with ReAction gadgets, and the stack trace shows the crash occurs during a series of nested calls to the layout.gadget, followed by a call to the button.gadget. The first part of the crash log, including the general info and the register dump, seems to go missing. But what remains is enough to get an idea what was happening when the crash occurred:


The exact code where the crash occurs is different than Rave. There are some other differences as well: unlike Rave, the crash occurs under FE Update 2, as well as under Update 3. And unlike Rave, the crash occurs even if AmigaDiskBench is run from the RAM disk. While the crash occurs most of the time, it occasionally doesn't, unlike Rave where it is always repeatable. Since I have only an X1000, I can't say if the crash only occurs on the X1000, as it does with Rave.

AmigaDiskBench isn't your responsibility, but the fact that a very similar bug occurs there is some evidence that it's not caused by your code doing anything wrong, and may in fact be a system problem of some sort. And perhaps the differences between the Rave crash and the AmigaDiskBench crash provide some clues as to where the problem lies.

@tao

Quote:
The crash prevented the Grim Reaper window from opening, and I don't have another machine handy to capture serial debug output. So I use Sashimi to redirect the serial output to a console window, or in this case a disk file. That won't work if the system goes down completely, but that wasn't the case here.

@trixie

Quote:
Standing by...

@trixie

We may be getting a bit off-topic here, but this thread has become kind of a place to discuss Rave in particular, as well as the blog in general. So...

Quote:
I was afraid of that- you do quality work, and it was hard to imagine you missing something like this. Nonetheless, it's entirely repeatable on my system (which is an X1000 running Update 3 and Enhancer 2.2).

I spent some time investigating the problem today, and it's rather bizarre.

First, I booted up my Update 2 partition -- which I made for just such a purpose prior to installing Update 3 -- and confirmed that Rave 1.9 works fine under Update 2- clicking on "File Requester" or "Advanced" just brings up the expected page of controls.

Back under Update 3, I unpacked the Rave 1.9 archive into RAM:, and discovered that Rave 1.9 works properly when run from the RAM disk, even under Update 3.

Thinking that perhaps my hard disk installation got corrupted somehow, I then drug the Rave drawer from RAM: to the hard drive (a different partition than my normal installation), and when run from the hard drive Rave once again hung when I tried to display the same two settings pages.

I next (after rebooting) installed Rave 1.8 to the same partition on the hard drive, and confirmed that it worked properly, even when run from the hard disk.

So, to summarize:

- Rave 1.8 works properly under Update 2 and Update 3, from RAM: or from the hard drive.

- Rave 1.9 works properly under Update 2 from the hard drive (I didn't try RAM:), and works properly under Update 3 when run from RAM:.

- Rave 1.9 does not work properly under Update 3 when run from the hard drive. (I use SFS2 on my hard drive partitions, not that the file system should make any difference.)

Some experimentation with Sashimi revealed that there is in fact a GR when Rave crashes, but due to side effects of the crash the GR window never appears. I was able to capture the crash log to disk:


It looks like the crash occurs while setting up the gadgets for the selected page, which makes sense. No idea why it occurs when run from the hard disk and not when run from RAM:.

At this point I'll toss the ball back to you, and see if the crash log provides any clues.

@trixie

Quote:
Unless I'm doing something wrong, there seems to be a bug in the new version of Rave. If I bring up the Settings requester and then click on either "File Requester" or "Advanced" the program stops responding, along with much of the OS. I have to reboot to recover.

@Gregor

I gave it a try with AllKeys, and it seems to work for me (tested with MultiEdit). Here's what I did:

Open AllKeys, then click the 'Add' button. When it opens the "Key learning window" press and release the 'Insert' key. There should be two entries in the window, one when the key was pressed, and one when it was released. Click the first one with the mouse, then click the 'Use Code' button. The key should show up in the main AllKeys window as "eat $80000047 RAWKEY Insert", with 'Translate into' blank. Select 'Use' or 'Save'. Voila! (Note that I have AllKeys configured to 'Eat all configured keys' and 'Flush upstroke of configured keys'.)

Of course, this will disable the Insert key for all programs, not just the one you're having trouble with- I don't know of any way to disable it only for specific programs.

To re-enable the key, open the AllKeys window, select the line for the Insert key, then click the 'Remove' button and then 'Save' or 'Use'.

@AmigaOldskooler

Count me among those who like the addition of headlines to the roundup. They make it easier to read and more professional-looking. I appreciate the time you put into researching and writing these every month.

One minor correction: It's "depscan" (one 'e'), not "deepscan".

@Skateman

Quote:
Would it be possible to break the blog into multiple pages? (One per month, perhaps?) It's become so big, with so many large images, that it takes a long time to load, and I can no longer view it with Odyssey as it runs out of memory trying to load all the images.

@redfox

That's nothing new with update 3; I've had the same thing happen with MakeCD and older versions of OS4. I think the problem is that MakeCD doesn't understand file links, and so crashes when it encounters one. The Sys:SObjs directory, at least, contains file links, so trying to make images of Sys: fails.

@trixie

Excellent news, and thanks for taking this on! I suppose this will mean less frequent updates for your other stuff like Rave, but that's a small price to pay for new OS4 development.

@turbo41

Version 1.4 of the MouseDriver package also fixes my problem with the scroll wheel not working (see post #62). Thanks!

It would be great if the latest driver could also be uploaded to OS4Depot, as the version there is quite old.