Who's Online |
57 user(s) are online ( 37 user(s) are browsing Forums)
Members: 1
Guests: 56
smarkusg,
more...
|
|
Headlines |
-
ffmpeg.lha - video/convert
Sep 10, 2026
-
ffmpeg_a1222.lha - video/convert
Sep 10, 2026
-
edgesnap.lha - utility/workbench
Sep 9, 2026
-
wormwars.lha - game/action
Sep 6, 2026
-
chaostheory.lha - demo/scene
Sep 5, 2026
-
telegramamiga.lha - network/chat
Sep 5, 2026
-
mcamigaxpe.lha - utility/filetool
Sep 5, 2026
-
departure.lha - demo/scene
Sep 3, 2026
-
nxengine-evo.lha - game/platform
Sep 3, 2026
-
videovortex.lha - video/play
Sep 3, 2026
|
|
|
|
|
Re: Did anyone use RadeonHD 3.7 with X1000 and Oland or Verde ?
|
|
Just popping in 
|
@pvanni Quote: I have probably the same setup and work fine at 1.9 Ghz, at 2.0 I have to wait till the CPU temperature (or GPU who knows) rise a bit before using my X1000 otherwise I have the same lockup.
I've noticed the same thermal effect- the warmer the system is, the less the chance of the freeze occurring. After the system has been running for some time and is fully warmed up, it will work at 2.0 GHz. But that's not a practical way to use it. On rare occasions I'll get the freeze soon after startup even at 1.8 GHz (fortunately it happens within a few minutes of starting, before I get really involved in anything). By the time I reset the system and boot up again it's warmed up enough to work reliably. But given that, I'm guessing that 1.9 GHz won't work on my system, so I haven't tried it.
|
|
|
|
|
|
Re: Did anyone use RadeonHD 3.7 with X1000 and Oland or Verde ?
|
|
Just popping in
|
@kas1e Quote: Is anyone use RadeonHD 3.7 (exactly 3.7) on their X1000, with Oland or Verde based cards ? I use RadeonHD 3.7 with an R7 250 card on my X1000. According to Ranger the R7 250 is Verde, and according to online sources it's Oland XT. It works fine for me. However... If you're running your X1000 at 2.0 GHz, you might want to try slowing it back to 1.8 GHz. I had to give up on overclocking my X1000, as the graphics would regularly freeze soon after booting to Workbench at 2.0 GHz. CFE works fine at 2.0 GHz (it doesn't use the RadeonHD driver, of course), but soon after Workbench starts the system freezes. Exec still seems to be running, so I assume the freeze is in the graphics subsystem.
|
|
|
|
|
|
Re: Issue with a blank Updater 53.73?
|
|
Just popping in
|
@ddni Quote: Anyone finding an issue with a blank Updater 53.73?
I just tried it (also an X1000 with Update 3) and it works fine for me- all the expected information showed up.
|
|
|
|
|
|
Re: SDK addon package
|
|
Just popping in
|
@walkero Quote: I did a fast check on the generated gcc packages as they come from adtools and there is no specs file included.
GCC does not come with an external specs file; it uses built-in specs (those which are printed by the '-dumpspecs' option). However, if it finds an external specs file when it's run, it will use that instead of/in addition to the built-in specs. This lets you create your own specs that add to or override the built-in ones. Typically you would do this by using '-dumpspecs' to get a copy of the built-in specs as joerg describes, and then modifying them as needed. The specs commands are described in the GCC docs. I have a non-standard SDK/GCC layout (I'm just weird that way), and have long used my own custom specs file to tell GCC about my layout. One issue I ran across -- which might not be a problem with a standard SDK layout -- is that GCC seems to look in different places for the specs file, depending on how it was run. If run from the shell it looks in one place, while if run from Make it looks in a different place. As a result, I have to have a copy of my specs file in both places. Quote: ...store [the specs file] to the appropriate path (sorry, I don't remember where it is, or should be, and it might be a different path in different versions of GCC)...
You can use Snoopy to discover where GCC looks for a specs file.
|
|
|
|
|
|
Re: scout: new os4 version
|
|
Just popping in
|
@kas1e Quote: Do you have any bugs to report and step-by-step reproduce so i can try to reproduce it with scout from 2006 and the new one ? Scout has been pretty stable as I've played with it recently, which makes me suspect that some of the crashes may not be readily reproducible, and may depend on things like the contents of some illegal address that's being read. One crash that is reproducible, at least on my system, has to do with the Resources window. A number of the resources displayed have suspicious numbers for the version and open count, but clicking 'More' for one of these doesn't cause any harm. An exception is clicking 'More' for the pager.resource, which causes a crash. (Same for the new Scout version.) The autodocs note that there is no standard "struct Resource" that all resources use; as long as there's a Node at the begnning they can use any layout they want. It's recommended that resources have a struct Library at the beginning, and Scout seems to depend on this. If this turns out to be wrong, Scout can crash (or at least, display strange numbers) when it accesses Library fields that aren't there. Looking at the Scout source, there's a table of "forbidden resources" that don't have a struct Library at the beginning, so Scout knows not to try to read them. At the least, this table needs to be updated to include newer resources. Even better would be if there's some way to figure out whether there's a valid struct Library without needing a table.
|
|
|
|
|
|
Re: scout: new os4 version
|
|
Just popping in
|
@kas1e Quote: Do you have any bugs to report and step-by-step reproduce so i can try to reproduce it with scout from 2006 and the new one ?
Not currently. I tend to trigger the crashes while just playing with Scout, pressing different buttons and seeing what it does. I've never bothered to write any of them down (or even see if they're reproducible) as there was nobody maintaining the program to investigate them. I'll play with it some in the coming days and see if I can stumble across any of the crashes again.
|
|
|
|
|
|
Re: What the fastest possible x64 emulation way of OS4 today ?
|
|
Just popping in
|
@kas1e Quote: i just loose hours to build scout over latest amigaos4 SDK, only to realize that even old os4 binary of scout from 2006 year runs fine and not hitting DSIs all over place a Joerg expect. The OS4 version of Scout does crash sometimes, and you need to be ready for that if using it, but more often it safely does nothing when asked to display things that no longer exist or aren't applicable on OS4. I regularly use it as a test and debug tool, though I make sure to save my work first. Quote: So not sure if there needs for releasing it ?
Just recompiling it using the latest SDK is unlikely to change anything; to fix the occasional crash you'd have to go through it and update any code that is not compliant with OS4 changes since 2006. Without doing that there's probably no point in releasing a newer version. Assuming you had to make some changes to get it to compile with the latest SDK/GCC, it wouldn't hurt to at least have that version of the source available in case anyone wants to take it on.
|
|
|
|
|
|
Re: adding a "by AI" tag?
|
|
Just popping in
|
I suspect that before very long the use of AI will simply be assumed. Having a field to mark the use of AI will seem as quaint as having one to mark the use of a high-level language would today. So, probably not worth the effort to update the site- the change would likely be obsolete before it could be implemented (unless maybe if you used AI to help with the implementation  ). That said, there's no harm in documenting the use of AI in the readme file, including specifics as to what AI was used for.
|
|
|
|
|
|
Re: Did anyone flash his cfe on x1000 with hw programmer ?
|
|
Just popping in
|
@kas1e Quote: So there 2 of same copy of cfe and if one die you simple set jumper to boot from second one ? 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.
|
|
|
|
|
|
Re: what do I need to do to get this install scirpt to run?
|
Posted on: 3/22 20:11
#10
|
Just popping in
|
@328gts Quote: just checked and I have those files dated December 18,2016 and in System folder it's dated Jan6/2021
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: tried using c:python in the installer script (as per Petrol's recommendation) instead of installation utility and got this error: 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).
|
|
|
|
|
|
Re: what do I need to do to get this install scirpt to run?
|
|
Just popping in
|
@328gts Quote: so where do I get the Rabbit hole...er Python now ? 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.
|
|
|
|
|
|
Re: what do I need to do to get this install scirpt to run?
|
|
Just popping in
|
@328gts Quote: where can I get this "Installation Utility" ? 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.
|
|
|
|
|
|
Re: what do I need to do to get this install scirpt to run?
|
|
Just popping in
|
@328gts Quote: Try "SYS:Utilities/Installation Utility" 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.
|
|
|
|
|
|
Re: working virtio-net.device for QEMU : no more issues with rtl drivers !
|
|
Just popping in
|
@smarkusg Quote: But out of curiosity, I see something like this in tcpdump
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.
|
|
|
|
|
|
Re: Introducing the Rear Window blog
|
|
Just popping in
|
@trixie Quote: ...the X1000-only crash has been fixed... With all the weird symptoms, I'm curious what the problem turned out to be.
|
|
|
|
|
|
Re: AmigaDiskBench Benchmark SSD/NVME/RAM
|
|
Just popping in
|
@derfs Quote: please can you test ... to see if it solves your issues?
There's still a recoverable DSI at startup, though it looks to be at a different place in the code:
AmigaOne X1000 release
Machine model: 6 (AmigaOne X1000)
Dump of context at 0xdfa76000
Trap type: DSI exception
Current kernel stack pointer: 0x296ff00
DSISR: 40000000 DAR: 153d5550
No matching page found
Machine State (raw): 0x100000000200b030
Machine State (verbose): [Hyper] [ExtInt on] [Super] [IAT on] [DAT on]
Instruction pointer: 0x7f797814
Crashed process: AmigaDiskBench (0x613b8210)
DSI verbose error description: Access to address 0x153d5550 not found in hash or BAT (page fault)
Access was a load operation
0: 7f797800 5cfeb220 ffb3b3b3 0000180f 153d5550 00000005 00000005 02006624
8: 02a8afa0 00000000 02a8eba0 0227fb88 00000794 5d9aa418 61179550 612f7748
16: 612f77f0 612f79b8 153d5550 5d9a2420 5cac5f78 5cac5f84 5cac5fb0 5cac5fa8
24: 5cac132c 5cac4fa0 80000006 5d9a0000 5d66cba0 5d9a0000 5d9a241c 6104aa10
CR: 59333333 XER: e0000033 CTR: 020360fc LR: 7f797800
V0 : 00000000000000000000000000000000 ffcfcfcfffcfcfcfffcfcfcfffcfcfcf
V2 : 01000100010001000100010001000100 ffcfcfcfffcfcfcfffcfcfcfffcfcfcf
V4 : ff01af51ff01bb45ff01a957ff018a76 00000000000000000000000000000000
V6 : ff01cf31ff01cf31ff01cf31ff01cf31 ff000000ff000000ff000000ff000000
V8 : 00000000000000000000000000000000 ffafafafffbbbbbbffa9a9a9ff8a8a8a
V10: 001002120414061608180a1a0c1c0e1e 01000100010001000100010001000100
V12: 01000100010001000100010001000100 ffcfcfcfffcfcfcfffcfcfcfffcfcfcf
V14: cf31cf31cf31cf31cf31cf31cf31cf31 ffcfcfcfffcfcfcfffcfcfcfffcfcfcf
V16: ce31ce31ce31ce31ce31ce31ce31ce31 ffcfcfcfffcfcfcfffcfcfcfffcfcfcf
V18: 01000100010001000100010001000100 ffffffffffffffffffffffffffffffff
V20: 00000000000000000000000000000000 00000000000000000000000000000000
V22: 00000000000000000000000000000000 00000000000000000000000000000000
V24: 00000000000000000000000000000000 00000000000000000000000000000000
V26: 00000000000000000000000000000000 00000000000000000000000000000000
V28: 00000000000000000000000000000000 00000000000000000000000000000000
V30: 00000000000000000000000000000000 00000000000000000000000000000000
VSCR: 00000000 VRSAVE: 00000000
Disassembly of crash site:
7f797804: 41a203f8 beq+ 0x7F797BFC
7f797808: 91e1012c stw r15,300(r1)
7f79780c: 92010130 stw r16,304(r1)
7f797810: 92210134 stw r17,308(r1)
>7f797814: 8a320000 lbz r17,0(r18)
7f797818: 2811001f cmplwi r17,31
7f79781c: 418104b8 bgt- 0x7F797CD4
7f797820: 38920001 addi r4,r18,1
7f797824: 7e258b78 mr r5,r17
7f797828: 386100c4 addi r3,r1,196
Kernel command line: DEBUGLEVEL=0 SERIAL
Registers pointing to code:
r0 : AmigaDiskBench:ScanSystemDrives()+0x188 (section 1 @ 0x1D748)
r7 : native kernel module kernel+0x00006624
r8 : native kernel module kernel+0x00a8afa0
r10: native kernel module kernel+0x00a8eba0
r11: native kernel module newlib.library.kmod+0x00008fc8
r13: AmigaDiskBench:collapsed_buf.1()+0x5c98 (section 14 @ 0x7F24)
r19: AmigaDiskBench:IExec()+0x0 (section 13 @ 0x4)
r20: module AmigaDiskBench at 0x5CAC5F78 (section 1 @ 0x4F54)
r21: module AmigaDiskBench at 0x5CAC5F84 (section 1 @ 0x4F60)
r22: module AmigaDiskBench at 0x5CAC5FB0 (section 1 @ 0x4F8C)
r23: module AmigaDiskBench at 0x5CAC5FA8 (section 1 @ 0x4F84)
r24: module AmigaDiskBench at 0x5CAC132C (section 1 @ 0x308)
r25: module AmigaDiskBench at 0x5CAC4FA0 (section 1 @ 0x3F7C)
r30: AmigaDiskBench:IDOS()+0x0 (section 13 @ 0x0)
ip : AmigaDiskBench:ScanSystemDrives()+0x19c (section 1 @ 0x1D75C)
lr : AmigaDiskBench:ScanSystemDrives()+0x188 (section 1 @ 0x1D748)
ctr: native kernel module kernel+0x000360fc
Stack trace:
(0x5cfeb220) AmigaDiskBench:ScanSystemDrives()+0x19c (section 1 @ 0x1D75C)
(0x5cfeb390) AmigaDiskBench:ScanSystemDrives()+0x188 (section 1 @ 0x1D748)
(0x5cfeb900) AmigaDiskBench:StartGUI()+0xbfc (section 1 @ 0x6180)
(0x5cfebd40) native kernel module newlib.library.kmod+0x00002614
(0x5cfebd90) native kernel module newlib.library.kmod+0x000032f0
(0x5cfebf40) native kernel module newlib.library.kmod+0x00003864
(0x5cfebf70) AmigaDiskBench:_start()+0x1e0 (section 1 @ 0x1E0)
(0x5cfebfc0) native kernel module kernel+0x0005a1a4
(0x5cfebfd0) native kernel module kernel+0x0005a21c
Disassembly of crash site:
7f797804: 41a203f8 beq+ 0x7F797BFC
7f797808: 91e1012c stw r15,300(r1)
7f79780c: 92010130 stw r16,304(r1)
7f797810: 92210134 stw r17,308(r1)
>7f797814: 8a320000 lbz r17,0(r18)
7f797818: 2811001f cmplwi r17,31
7f79781c: 418104b8 bgt- 0x7F797CD4
7f797820: 38920001 addi r4,r18,1
7f797824: 7e258b78 mr r5,r17
7f797828: 386100c4 addi r3,r1,196
Stack pointer (0x5cfeb220) is inside bounds
Redzone is OK (4)
Quote: The 2nd crash will probably still happen for now.
Yes, it does. Quote: On the Benchmarking tab, if you right-click on a test name you can now use the menu to see a full description of that test.
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.
|
|
|
|
|
|
Re: AmigaDiskBench Benchmark SSD/NVME/RAM
|
|
Just popping in
|
@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).
AmigaOne X1000 release
Machine model: 6 (AmigaOne X1000)
Dump of context at 0xdfac23e0
Trap type: DSI exception
Current kernel stack pointer: 0x296ff00
DSISR: 40000000 DAR: 153d5550
No matching page found
Machine State (raw): 0x100000000200b030
Machine State (verbose): [Hyper] [ExtInt on] [Super] [IAT on] [DAT on]
Instruction pointer: 0x7fa26144
Crashed process: AmigaDiskBench (0x5ea010c0)
DSI verbose error description: Access to address 0x153d5550 not found in hash or BAT (page fault)
Access was a load operation
0: 7fa260c0 5e457220 00000000 5e457304 153d5550 00000005 00000005 02006624
8: 02816968 5e457240 00000000 0227fb88 00000794 5d873418 5e7332ac 5e733280
16: 61046a10 5def0018 5d870000 5d86b6fc 5d870000 5e733274 5e7332a4 5e73032c
24: 5e73229c 80000006 5da5c634 5d870000 5d870000 5e8a5120 5d86b41c 6fcdd350
CR: 48222224 XER: 20000000 CTR: 00000000 LR: 7fa260c0
V0 : 00000000000000000000000000000000 ffcfcfcfffcfcfcfffcfcfcfffcfcfcf
V2 : 01000100010001000100010001000100 ffcfcfcfffcfcfcfffcfcfcfffcfcfcf
V4 : ff01b947ff01b947ff01b947ff01b947 00000000000000000000000000000000
V6 : ff01cf31ff01cf31ff01cf31ff01cf31 ff000000ff000000ff000000ff000000
V8 : 00000000000000000000000000000000 ffb9b9b9ffb9b9b9ffb9b9b9ffb9b9b9
V10: 001002120414061608180a1a0c1c0e1e 01000100010001000100010001000100
V12: 01000100010001000100010001000100 ffcfcfcfffcfcfcfffcfcfcfffcfcfcf
V14: cf31cf31cf31cf31cf31cf31cf31cf31 ffcfcfcfffcfcfcfffcfcfcfffcfcfcf
V16: ce31ce31ce31ce31ce31ce31ce31ce31 ffcfcfcfffcfcfcfffcfcfcfffcfcfcf
V18: 01000100010001000100010001000100 ffffffffffffffffffffffffffffffff
V20: 00000000000000000000000000000000 00000000000000000000000000000000
V22: 00000000000000000000000000000000 00000000000000000000000000000000
V24: 00000000000000000000000000000000 00000000000000000000000000000000
V26: 00000000000000000000000000000000 00000000000000000000000000000000
V28: 00000000000000000000000000000000 00000000000000000000000000000000
V30: 00000000000000000000000000000000 00000000000000000000000000000000
VSCR: 00000000 VRSAVE: 00000000
Disassembly of crash site:
7fa26134: 92410138 stw r18,312(r1)
7fa26138: 9261013c stw r19,316(r1)
7fa2613c: 92810140 stw r20,320(r1)
7fa26140: 93410158 stw r26,344(r1)
>7fa26144: 8b440000 lbz r26,0(r4)
7fa26148: 281a001f cmplwi r26,31
7fa2614c: 41810404 bgt- 0x7FA26550
7fa26150: 7f45d378 mr r5,r26
7fa26154: 38840001 addi r4,r4,1
7fa26158: 386100c4 addi r3,r1,196
Kernel command line: DEBUGLEVEL=0 SERIAL
Registers pointing to code:
r0 : AmigaDiskBench:ScanSystemDrives()+0x190 (section 1 @ 0x1D008)
r7 : native kernel module kernel+0x00006624
r8 : native kernel module dos.library.kmod+0x006e0308
r11: native kernel module newlib.library.kmod+0x00008fc8
r13: AmigaDiskBench:collapsed_buf.1()+0x5ca8 (section 14 @ 0x7F24)
r14: module AmigaDiskBench at 0x5E7332AC (section 1 @ 0x3288)
r15: module AmigaDiskBench at 0x5E733280 (section 1 @ 0x325C)
r18: AmigaDiskBench:collapsed_buf.1()+0x2890 (section 14 @ 0x4B0C)
r19: AmigaDiskBench:ui()+0xbc (section 14 @ 0x208)
r20: AmigaDiskBench:collapsed_buf.1()+0x2890 (section 14 @ 0x4B0C)
r21: module AmigaDiskBench at 0x5E733274 (section 1 @ 0x3250)
r22: module AmigaDiskBench at 0x5E7332A4 (section 1 @ 0x3280)
r23: module AmigaDiskBench at 0x5E73032C (section 1 @ 0x308)
r24: module AmigaDiskBench at 0x5E73229C (section 1 @ 0x2278)
r26: AmigaDiskBench:s_part_vol.11()+0x0 (section 14 @ 0x1F1140)
r27: AmigaDiskBench:collapsed_buf.1()+0x2890 (section 14 @ 0x4B0C)
r28: AmigaDiskBench:collapsed_buf.1()+0x2890 (section 14 @ 0x4B0C)
r30: AmigaDiskBench:IDOS()+0x0 (section 13 @ 0x0)
ip : AmigaDiskBench:ScanSystemDrives()+0x214 (section 1 @ 0x1D08C)
lr : AmigaDiskBench:ScanSystemDrives()+0x190 (section 1 @ 0x1D008)
ctr: unknown (0x0)
Stack trace:
(0x5e457220) AmigaDiskBench:ScanSystemDrives()+0x214 (section 1 @ 0x1D08C)
(0x5e457390) AmigaDiskBench:ScanSystemDrives()+0x190 (section 1 @ 0x1D008)
(0x5e457900) AmigaDiskBench:StartGUI()+0xbfc (section 1 @ 0x60F0)
(0x5e457d40) native kernel module newlib.library.kmod+0x00002614
(0x5e457d90) native kernel module newlib.library.kmod+0x000032f0
(0x5e457f40) native kernel module newlib.library.kmod+0x00003864
(0x5e457f70) AmigaDiskBench:_start()+0x1e0 (section 1 @ 0x1E0)
(0x5e457fc0) native kernel module kernel+0x0005a1a4
(0x5e457fd0) native kernel module kernel+0x0005a21c
Disassembly of crash site:
7fa26134: 92410138 stw r18,312(r1)
7fa26138: 9261013c stw r19,316(r1)
7fa2613c: 92810140 stw r20,320(r1)
7fa26140: 93410158 stw r26,344(r1)
>7fa26144: 8b440000 lbz r26,0(r4)
7fa26148: 281a001f cmplwi r26,31
7fa2614c: 41810404 bgt- 0x7FA26550
7fa26150: 7f45d378 mr r5,r26
7fa26154: 38840001 addi r4,r4,1
7fa26158: 386100c4 addi r3,r1,196
Stack pointer (0x5e457220) is inside bounds
Redzone is OK (4)
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.
|
|
|
|
|
|
Re: Introducing the Rear Window blog
|
|
Just popping in
|
@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:
Kernel command line: DEBUGLEVEL=0 SERIAL
Registers pointing to code:
r0 : native kernel module kernel+0x000375ac
r3 : native kernel module kernel+0x00009dd4
r5 : native kernel module kernel+0x0000b030
r6 : native kernel module kernel+0x00a8418c
r13: AmigaDiskBench:collapsed_buf.1()+0x5ca8 (section 14 @ 0x7F24)
r27: module DEVS:printer.device at 0x00000001 (section 0 @ 0xFFFFFFDC)
r28: native kernel module kernel+0x00a87032
r31: native kernel module kernel+0x009724f0
ip : native kernel module kernel+0x00009dbc
lr : native kernel module kernel+0x000375b4
ctr: native kernel module kernel+0x00035e60
Stack trace:
(0x5e456660) native kernel module kernel+0x00009dbc
(0x5e456690) native kernel module kernel+0x000375b4
(0x5e4566b0) native kernel module kernel+0x00033b70
(0x5e4566d0) module CLASSES:gadgets/button.gadget at 0x7FDC0234 (section 0 @ 0x3210)
(0x5e4567d0) native kernel module intuition.library.kmod+0x000250d4
(0x5e456820) native kernel module intuition.library.kmod+0x00025530
(0x5e4568a0) module CLASSES:gadgets/layout.gadget at 0x7FDE9394 (section 0 @ 0x4370)
(0x5e456950) module CLASSES:gadgets/layout.gadget at 0x7FDED740 (section 0 @ 0x871C)
(0x5e456a70) native kernel module intuition.library.kmod+0x000250d4
(0x5e456ac0) native kernel module intuition.library.kmod+0x00025530
(0x5e456b40) module CLASSES:gadgets/layout.gadget at 0x7FDE9394 (section 0 @ 0x4370)
(0x5e456bf0) module CLASSES:gadgets/layout.gadget at 0x7FDED740 (section 0 @ 0x871C)
(0x5e456d10) native kernel module intuition.library.kmod+0x000250d4
(0x5e456d60) native kernel module intuition.library.kmod+0x00025530
(0x5e456de0) module CLASSES:gadgets/layout.gadget at 0x7FDF15B0 (section 0 @ 0xC58C)
(0x5e456e70) native kernel module intuition.library.kmod+0x000250d4
(0x5e456ec0) native kernel module intuition.library.kmod+0x00025530
(0x5e456f40) module CLASSES:gadgets/clicktab.gadget at 0x7FB33968 (section 0 @ 0x5944)
(0x5e457040) module CLASSES:gadgets/clicktab.gadget at 0x7FB35030 (section 0 @ 0x700C)
(0x5e4570f0) native kernel module intuition.library.kmod+0x000250d4
(0x5e457140) native kernel module intuition.library.kmod+0x00025530
(0x5e4571c0) module CLASSES:gadgets/layout.gadget at 0x7FDE9394 (section 0 @ 0x4370)
(0x5e457270) module CLASSES:gadgets/layout.gadget at 0x7FDED740 (section 0 @ 0x871C)
(0x5e457390) native kernel module intuition.library.kmod+0x000250d4
(0x5e4573e0) native kernel module intuition.library.kmod+0x00025530
(0x5e457460) module CLASSES:gadgets/layout.gadget at 0x7FDE9FB0 (section 0 @ 0x4F8C)
(0x5e457570) module CLASSES:window.class at 0x7FDF5300 (section 0 @ 0x22DC)
(0x5e457590) module CLASSES:window.class at 0x7FDF74E8 (section 0 @ 0x44C4)
(0x5e4575f0) module CLASSES:window.class at 0x7FDFEEF8 (section 0 @ 0xBED4)
(0x5e4577c0) native kernel module intuition.library.kmod+0x000250d4
(0x5e457810) native kernel module intuition.library.kmod+0x00025530
(0x5e457890) native kernel module intuition.library.kmod+0x0000b3e4
(0x5e457900) AmigaDiskBench:StartGUI()+0x1294 (section 1 @ 0x6788)
(0x5e457d40) native kernel module newlib.library.kmod+0x00002614
(0x5e457d90) native kernel module newlib.library.kmod+0x000032f0
(0x5e457f40) native kernel module newlib.library.kmod+0x00003864
(0x5e457f70) AmigaDiskBench:_start()+0x1e0 (section 1 @ 0x1E0)
(0x5e457fc0) native kernel module kernel+0x0005a1a4
(0x5e457fd0) native kernel module kernel+0x0005a21c
Disassembly of crash site:
02009dac: 7c641b78 mr r4,r3
02009db0: 3c600200 lis r3,512
02009db4: 60639dd4 ori r3,r3,40404
02009db8: 44000022 .word 0x44000022
>02009dbc: 4e800020 blr
02009dc0: 7c641b78 mr r4,r3
02009dc4: 3c600200 lis r3,512
02009dc8: 60639f3c ori r3,r3,40764
02009dcc: 44000022 .word 0x44000022
02009dd0: 4e800020 blr
Stack pointer (0x5e456660) is inside bounds
Redzone is OK (4)
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.
Edited by msteed on 2026/3/4 2:18:35
|
|
|
|
|
|
Re: Introducing the Rear Window blog
|
|
Just popping in
|
@tao Quote: I hadn't realized there was still a need for Sashimi (or even an OS4 port) in the era of Grim Reapers and serial output. 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.
|
|
|
|
|
|
Re: Introducing the Rear Window blog
|
|
Just popping in
|
@trixie Quote: Let me contact you off-forum and send you a debug build for more information.
Standing by...
|
|
|
|
|
News feed
OS4 Feedback forum
OS4Depot Feedback forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
